Existing EGI use cases for tokens

[chrisburr]

To be completed by @atsareg

The use cases have to be existing and really required (not "maybe in case of possibly this happens"). And the use cases should be actual requirements (as in "my jupyther notebook needs to talk to DIRAC") and not implementation specific (as in "my jupyther notebook should contact the TokenManager to retrieve a token with the device grant")

[atsareg]

Here is an initial list of requirements/cases of using tokens in various DIRAC operations that we considered for the EGI service but is not really specific to EGI. To be discussed and updated.

1. User registration
   a. User is registered with the Identity Provider/Community Management service, e.g. Check-In/Co-manage, WLCG IAM, CA/VOMS. User profile information from the Identity Provider should be sufficient for DIRAC to manage the user’s activities.
   b. It should be possible to serve user’s registered with different Identity Providers in the same DIRAC instance.

2. User interactive work: web portal
   a. Login to web portal with certificate loaded in the browser
   b. Login to web portal with token issued by an Identity Provider that can be chosen
   c. Choose a DIRAC group for the current working session

3. User interactive work: command line
   a. User should be able to start a working DIRAC session by getting valid temporary credentials: certificate proxy and/or token
   b. For the transient period of X.509 -> OIDC/OAuth2 migration, certificates and tokens must be possible to use interchangeably.
   c. Users not having the possibility to obtain X.509 certificates should be able to get temporary proxy certificates after OIDC/OAuth2 identification (RCAuth service). The temporary certificate proxy should allow for all the user activities as a normal X.509 certificate. This is a strong “would be nice to have” case.
   d. The validity of temporary credentials should be long enough for a working day. If the validity of credentials is less than a one-day working session, automated transparent procedure for the credential’s renewal should be applied.
   e. Temporary user credentials for interactive work are used to communicate with the DIRAC services. For that they should include enough information to:
   i. Map the user on unique user name assigned by DIRAC and used for displaying and accounting of the user activities managed by DIRAC
   ii. Contain unambiguous information to map the credentials onto a single DIRAC group.
   f. Jupyter notebook is one of the use cases of command line sessions to which all above applies.

4. User capabilities
   a. User rights with respect to DIRAC services are fully determined by the DIRAC group of the user’s working session.
   b. This concerns also all the entities created by the user (jobs, files, requests) should carry the DIRAC group that was used at the creation time.
   c. Existing DIRAC mechanisms to define user rights and privileges must continue to work (access to jobs info, file ACLs in the DFC, etc).

5. Asynchronous user operations
   a. Asynchronous user operations performed by DIRAC on the user’s behalf must be executed with the user’s credentials (proxy certificates and/or tokens) having the same information for the user identity and DIRAC group membership as for interactive sessions.

6. Pilot tokens
   a. Tokens used to submit pilots to sites must carry enough information for the resource providers to identify the community/VO for which the pilot is submitted. If sites will require additional information to distinguish various activities within the VO (e.g. testing, high priority activities), this should be available in the pilot credentials.
   b. Pilot tokens are used only at the submission time. Once running, pilots can perform their operations needing authenticated connections using other credentials and methods than initial pilot tokens as required by the pilot framework.
   c. Pilots execute user payloads always with user credentials (proxy certificates and/or tokens) which are obtained and renewed as necessary by the pilots/JobAgents before starting the payload execution.

7. Accessing storage resources
   a. Access rights to the storage resources must be determined by the access control bits defined in the File Catalog.
   b. Access right information should be embedded into the user’s token to be used for interaction with the storage services.

[chrisburr]

The aim of this issue isn't to summarise everything in DIRAC. During the last BiLD tokens were already being used in EGI in a few places. Please can you summarise how they're currently being used so we can think about making changes without breaking things.

[atsareg]

The general list of requirements is anyway necessary. We have discussed them on many occasions but we did not have it written down.

Tokens are not used in EGI in real production meaning that there are no VOs strongly depending on them. So, if you break everything, the consequences will be painful but not so dramatic. There are several cases that some pilot users are exploring:

1. Login to web portal with token and use it for job manipulation and file browsing
2. Getting dirac certificate proxies through OAuth2 authentication/authorization. This is suitable for the environments where the user certificate is not or can not be installed (Jupyter, interactive servers)
3. Submitting pilots to several test sites with tokens, using WLCG tokens for the moment

Users are not yet accessing DIRAC services from command line with tokens as we have not yet switched to https services interesting for the users (CS, WMS). But we are close to do that.
We are also discussing with EGI/Check-In and some VOs how they should be set up in order to use DIRAC. This is necessary in order to finalize how their tokens can be used with the DIRAC services, e.g. mapping onto the DIRAC groups. And this is the work in progress, so we have to have a stable solution on our side to let the VOs to proceed with their setup.