Trace user identity throughout the system

[andriineronov]

Story #20099

INTEGRAL web analysis - Task #17084: control the access to the platform	New	Mohamed Meharga
Task #18436: Enable token generation for the use of API	Closed	Mohamed Meharga
Story #22906: enable drupal users, and pass the email+token to dispatch-data call	New	Mohamed Meharga
Task #23119: it is very important to extract selection of information from the task #20099 in a wiki page	Closed

[andriineronov]

History

#1 Updated by Volodymyr Savchenko about 1 year ago

Priority changed from Normal to High

I have come to think that this feature might be quite important for support. Its all good with issue detection and resolution in principle, but would be much nicer if I knew who sent the job and could send a message back like "thanks for revealing the bug". Otherwise the users are left unhappy.

#2 Updated by Volodymyr Savchenko 10 months ago

Related to Story #21161: allow large queries added
#3 Updated by Volodymyr Savchenko 10 months ago

Target version set to ODA 1.3
#4 Updated by Volodymyr Savchenko 7 months ago

Tracker changed from Feature to Story
Start date deleted (13 November 2019)
#5 Updated by Andrii Neronov 2 months ago

Assignee changed from Andrii Neronov to Mohamed Meharga

It looks like we want to start from a possibility to create Drupal accounts, which will go for approval to us. Mohamed, can you give it a try.

#6 Updated by Volodymyr Savchenko 2 months ago

To summarize discussion of the last meeting:

User identity is needed in order to:
long queries: so that user will get email when the interface is offline
demanding queries: so that users are accountable for consuming compute/store resources
private data: once identity is traced, we can give access to priority data
source of identity:
drupal user account can be used
github/gmail
unige ldap
unige ISIS?
switch?
edugain?
flow:
UI-based: email and token associated with drupal account (possibly just session id) can be sent by frontend to dispatcher. dispatcher will be able to verify that token are valid.
other (e.g. python) API client will send token and email to dispatcher. dispatcher will be able to verify token and email. in this case, source identity can be easily substituted with e.g. github.
backend will receive user identity and may send reports to the service.

[volodymyrss]

https://github.com/oda-hub/doc-multi-user/blob/main/README.md

[ferrigno]

Follow the above document to define the JWT token.

[volodymyrss]

(copied from redmine)

The following user roles have been created in Drupal (following the documents, doc-multi-user, roles and doc-multi-user/plan-roles-users.md :

general
integral-private-qla
magic
unige-hpc-full
public-pool-hpc
antares
sdss
apc
bitp

Once the user is logged in the cookie Drupal.visitor.token is defined and it contains a JWT token followint the document Introduction to JSON Web Tokens
The token is also provided as a paramter, token, in the URL for each request to the dispatcher as

Example of generated token:
Drupal.visitor.token = [REDACTED]
The payload part of the token contains the user email, name, roles and the expiration time of the token.
Example:
(
[email] => [email protected]
[name] => mmeharga
[roles] => authenticated user, content manager, general, magic
[exp] => 1613662947
)

exp is the expiration time of the token which can be defined in the Drupal administration GUI as a life time in minutes.

[volodymyrss]

this remains: #7
oda-hub/mmoda-frontend-module#1

[burnout87]

Token, if provided, is decoded within the dispatcher and also validated (checking expiration, user role etc etc).
How is the secrete key shared with the dispatcher?

• provided at login/start of a session?
• ... ?

Was ther already some ideas regarding this point?

[volodymyrss]

Token, if provided, is decoded within the dispatcher and also validated (checking expiration, user role etc etc).
How is the secrete key shared with the dispatcher?

* provided at login/start of a session?

* ... ?

Was ther already some ideas regarding this point?

Yes, it should be created on deployment, as a separate secret. It can be stored in the config, since it already has some secrets.

Here we have an issue for this: #7

As an addtional safety measure, we could read the secret from location pointed out in the config, instead of storing it in the config directly. see comment on oda-hub/dispatcher-app#13

[burnout87]

In abbc2ac I explained a bit the flow regarding the token