Multiple IdP and unicity of username

[fstagni]

(from discussion happening in https://indico.cern.ch/event/893140/)

The uniqueness of the username (e.g. atsareg, or fstagni) need to be assured even in the presence of multiple IdP. Such uniqueness needs to also consider the previous users registered in the VO (should keep historical info)

[TaykYoku]

DIRAC username will stay unique. IdP in DIRAC user context is a DIRAC user parameter "IDs".

atsareg              # atsareg has
  IDs = 1234, ABCD   # multiple IdPs: Google with ID "1234" and GitHub with ID "ABCD"
  DN = ...

[atsareg]

The username uniqueness must be ensured by the administration procedures of the user management. For example, VO administrator checks username (nickname, preferred name, etc) of the VO user in ALL the IdP services an makes sure that this user attribute is unique and coherent across the board of IdPs. Then DIRAC can trust this choice of names and automatically register users whenever they come for the first time attributing the corresponding username to them.
Another possibility is that the first user registration in DIRAC is passing through the scrutiny by the VO administrator who verifies the request and assigns a unique username based on the user metadata received from the IdP service used for the user authentication when making the registration request. If a user wants to use also some other IdPs, then he will link the new IdP ID to the already registered DIRAC username with a special interface provided by DIRAC rather than making a new registration request. If, by mistake, a new registration request is made, this will be verified and rejected by the VO administrator. In any case, the problem is resolved by a human (VO administrator) intervention, there is no way to invent a generic algorithm to ensure username unicity and coherence across a number of IdPs.

[fstagni]

Simply, can we keep historical info? It's enough to have an active/inactive flag per user in DIRAC IdP registry.

[atsareg]

Yes, I think it can be as simple as that. The User accounts are never removed. If the user becomes inactive, naturally there will be no more active sessions for this user and the account will be inactive by definition.

[TaykYoku]

Returning to this question, I see that there are issues related to this (in the context of DN), e.g.: #4486.

As I see it: DIRAC can be roughly equated to Identity Provider (IdP), also take any VOMS, WLCG IAM and EGI CheckIn.

Each of them has a user ID, call them "primery UID" (pUID) and linked user IDs, call them "slave UIDs" (sUIDs).	name	Unique ID	can be linked
DIRAC	username	DNs, UIDs
VOMS	DN	DNs
IAM / EGI	UID	DNs, UIDs

Now when we register a user in DIRAC there are two main scenarios.

We create the user alytov in DIRAC, we add DN = /CN=oldDN. That is alytov - pUID, /CN=oldDN - sUID. alytov works with DIRAC for some time, databases are filled with records bound to /CN=oldDN. alytov adds a new DN + =/CN=newDN and starts performing some actions. Databases are populated with records bound to /CN=newDN, but operations that read old records (for /CN=oldDN) will not find them.

The nuance is that pUID is more stable, so it makes sense to use it instead to save long-term records, and keep sUIDs in the register if there are old records associated with it.

Here's how to try to deal with all of these IDs. Consider the main ways to interact with DB:

1. request information, such as the getRowByUsername method, which searches for an entry in the User field. If the user changes the DN and contacts the DB with it, getRowByUsername will not find the record, so we do the following, before interacting with the database interface, find the pUID and all sUIDs (<list IDs>). We replace the query WHERE 'User' = DN with WHERE 'User' in (<list IDs\>), now we are sure that even old records will be found. 1.1. I also think that need to add a check to see if the 'User' field contains a pUID, if not then overwrite it with a pUID.

2. write new information: it is worth writing with pUID as more stable.

3. rewriting old information. We get information by searching among the pUID and all sUIDs, and overwrite the 'User' field to pUID if necessary.

[aldbr]

I update this issue with what we agreed at our last "DIRAC Oauth2" meeting in December 2022:

• The username should be unique and composed as follows: subjectID@VO.
• The "same person" registered in more than 1 VO will effectively become more than 1 user in DIRAC.
• This should be the unique key for each user in each DB.
• Small caveat: the user path (e.g. /lhcb/user/c/chaen) still needs the nickname to have a human readable format and to avoid special characters in paths.

Latest PR going into this direction: https://github.com/DIRACGrid/DIRAC/pull/6566

Personal notes:

• Regarding the username: Currently there is no VO claim in the payload.

  • This could be the issuer claim, as long as we have one issuer per VO and not one issuer per IdP. We seem to be moving in that direction.
  • This could be extracted from the group-based claim (wlcg.groups, edu_entitlement), but we need to parse the values, and that means it should be in the token, which is not mandatory.

• Related to the readability of the username (cosmetic): as subjectID@VO may not be easy to read, we could have a "nickname" field, either provided by the user or fetched from the IdP's scim endpoint.

[fstagni]

* Small caveat: the user path (e.g. `/lhcb/user/c/chaen`) still needs the nickname to have a human readable format and to avoid special characters in paths.

We would anyway have /vo1/user/f/foo and /vo2/user/f/foo

* Regarding the username: Currently there is no `VO` claim in the payload.

Should there really be?

  * This could be the `issuer` claim, as long as we have one `issuer` per VO and not one `issuer` per IdP. We seem to be moving in that direction.

I hope so!

[aldbr]

I close the issue as this will not be handled in DIRAC.