| Status | In-Progress |
| Prepared-By | VS, MM, CF |
| Prepared-For | ODA developers |
To describe flow of the tokens in ODA and reference to roles and user definition
Users may fall in one of the two classes:
| anonymous | User that decides not to register to the website, we will try to discourage, but not ban. Will have access to the k8s cluster resources, no access to UNIGE HPC clusters or any kind of private data, described below. |
| authenticated | the same exact rights as those of anonymous, but will receive e-mail notification when job is submitted and completed, can be tracked by developers for requests and errors following specific consent. |
Note that priviledges are only set by roles, hence user types separation is orthogonal to role selection. I.e. in principle, any user type can have any role combination. Without explicit specification of roles, both authenticated and anonymous user have the same priveledges if roles are not set. However, since roles are set with user attributes in the user token, generally only authenticated users can have additional roles. Note that it is possible (and indeed necessary) to sometimes create different tokens with the same user id (email) but different role selection. It is not necessary to address this complexity with drupal.
Meaning of Roles and Source of Roles definition are described below.
Roles are defined as simple strings, case-insensitive, matching "[a-z][0-9]\-". They may be also referenced as URI, http://odahub.io/roles/XXXXX
The belonging to groups in the Drupal can be used adapted to reflect roles. In Drupal, groups characterize users inside the CMS. Besides anonymous (not logged and identified) and authenticated (identified by the compulsory user attributes), we define a collection of necessary groups. Note anonymous and authenticated are not roles since they do not provide any priviledge by default.
Roles can be also defined by other means, i.e in dispatcher. For most purposes, ultimate origin of roles is defined by the consumer of the role they are used: dispatcher plugins and backends (see below).
Note that roles define ability to act in certain way. Assigning a role means giving ability to act, while the basic usage of the infrastructure is exploited without a specific role. Roles should be designed not to overlap or inherit from each other.
- Roles assigned to user are strictly additive: user which has a collection of roles, has added priviledges given by all of them.
- Roles as used at validation are multiplicative: i.e. requesing a resource demanding a collection of roles needs each of them to be satistifed. Treatment of the roles is also often more complex, and uses a combination of request parameters with roles, as implemented by dispatcher and instrument plugins.
Roles can be used by the frontend to hide some parts of the interface.
Roles will be used by the dispatcher when filtering queries. The Dispatcher may associate each query with the required Roles, or establish filters for more complex request matching (e.g. restricting parameter ranges). We should be cautious to put too much configuration in dispatcher when other methods (below) are possible.
In general, the authority to demand roles should be given to plugins when possible. They should be able to control access to themselves by instructing the dispatcher, with default plugin roles set in plugin configuriation.
Dispatcher (and instrument plugin) treatment of the may be more complex, and uses combination of request parameters with roles by overriding dispatcher method.
Backends should be able to control access to themselves by instructing dispatcher. Dispatcher need not to bother about this particular case, it is treated in plugins end exposed through the same interface.
- Some Backends may declare which roles they require, and dispatcher plugins will respect these requests. General dispatcher needs not to be concerned with this.
- Some Backends (e.g. integral) will declare that they can operate in role-restricted mode, and will themselves perform additional filtering based on the Role information provided.
In the second case, a more restricted token may be provided to the backend, to prevent backend gaining entire rights of the user.
Roles are passed in user tokens.
We use JWT (also) to authentify users.
Example, showing minimal required set of fields in token payload:
{
"sub": "[email protected]",
"email": "[email protected]",
"name": "mmeharga",
"aud": "dispatcher",
"roles": "magic,antares",
"exp": 1613662947,
"iss": "drupal",
"iat": 1613662847,
"tem": 1800,
"mstout": true,
"intsub": 1800,
"mssub": true,
"msdone": true,
"msfail": true,
"mxdone": true,
"mxintsub": 1800,
"mxroomid": "!abcdefghi123456789:matrix.org",
"mxstout": true,
"mxsub": true,
"tmx": 1800,
"mxfail": true
}Where "sub" field is unique user identified, defined as email. In some cases, email may be passed
| Description | token field | drupal field |
|---|---|---|
| sub or email | ? | |
| full name | name | ? |
| roles, coma-separated | roles | ? |
| expiration | exp | ? |
| issued-at | iat | ? |
| issued-dy | iss | none |
| audience, issued-for | aud | none |
| email timeout for completed message | tem | none |
| email timeout from last email sent | intsub | none |
| email sent upon completion of a request that suceeded the established timeout | mstout | none |
| email sent once a query has been submitted | mssub | none |
| email sent once a query has completed | msdone | none |
| email sent once a query has failed | msfail | none |
| matrix room id | mxroomid | none |
| matrix message timeout from last matrix message sent | mxintsub | none |
| matrix message timeout for completed message | tmx | none |
| matrix message sent upon completion of a request that suceeded the established timeout | mxstout | none |
| matrix message sent once a query has been submitted | mxsub | none |
| matrix message sent once a query has completed | mxdone | none |
| matrix message sent once a query has failed | mxfail | none |
Specific sites may specify more roles, as needed.
We create JWT in drupal, using symmetric encryption (currently), secret injected at the deployment
Dispatcher may also create tokens for API, especially for creating reduced scope tokens for passing to backends.
JWT will be provided by frontend in each request, once the user is logged in. In particular:
- the cookie Drupal.visitor.token is defined and it contains a JWT
- the _oauth2_token will be defined for OAUTH2-secured API endpoints.
- the token is also provided as a paramter, token, within the URL for each request to the dispatcher
- the token is also sent in the request header Authorization.
In the event of a public request, so one executed with no user logged in, the token won't be provided.
JWT will be also made available to the user for use in the API
But they See current working definition of real roles here.
| Meetings | 2021-02-22 |