...
Authentification Mechanism | Used By | Description | Protection Level |
---|---|---|---|
Session Login | End-Users | Restricts the permission on specific routes by validating the session ID of a request. If an end-user does not hold an approved session ID he has to authenticate himself over a login page with a username and password. If the login was successful, the end-user's session ID becomes active. | Web pages with restricted functions. |
oAuth2 (RFC6749) | Applications | Restricts the permission on specific routes by validating an access token within the request's header. If an application does not hold an active access token it has to request a token from the oAuth2 authentication authorisation server. Each route is tagged with one or multiple 'scopes' which groups protected resources. An access token is related with a list of scopes and only provides access to correspondingly tagged resources. | Restricted REST resources. |
...
The central entity is the user which, by assumption, owns resources he grants access to. A client can then define reliable clients and administrate there grant as well as bearer (access) tokens. This workflow however is not defined by the above database schema nor oAuth2. Flarecast do not provide corresponding functionalities for managing users at the moment, so each user has to be manually added to the database. Furthermore, a fine-grained user management system may add some user roles which could then be mapped to specific scopes. An example may look likeis given by the following table:
User Role | Resource Scope | Example |
---|---|---|
Reader | read | Access to protected routes for querying configurations of prediction algorithms. |
Writer | write | Access to protected routes for adding prediction data to existing predictions. |
Moderator | read, write | Full (read and write) access to the prediction service. |
Administrator | read, write, execute | Full access to the workflow management service, including protected routes for running and stopping Docker containers. |