Provisioning both local and federated users to the same user type (schema)

[ThaminduDilshan]

In thunder, user schemas can have required and unique attributes.

• For the federated users, currently users should be provisioned with a sub claim which is the unique user identifier returned from the federated IDP. This requires having sub as a unique and required claim in the schema.
• Local users can have a unique attribute such as a username or a email. This requires having username/ email as a unique and required claim.

When both local and federated users can exist in the same user type (schema), it's challenging to define a unique and required attribute that matches both these scenarios.

For the fedarated scenario, we may not be able to consider email as an unique attribute always.

Initiated this discussion to get community ideas around this. I would see following as the possibilities to resolve this.

1. Allow mapping federated user sub claim to a existing local claim. I.e. federated user id may be mapped to the username. This might be challenging if we need to define a regex for the username.
2. Allow specifying multiple required attributes for the schema such that only one of the specified attributes requires to be provided. I.e. either username or sub needs to be provided to create a user. With this we also need to define both username and sub as unique attributes.

Open to any other suggestions.

Note: This will become an issue when we improve provision executor to honor user type (schema)

[darshanasbg]

User schema should primarily needs to be defined, based on the requirement of the usage of those users (like app in simple CIAM case, or employee data requirements in the EIAM case), not based on the sources those users are coming in.

So, based on the use case, one should define the user schema and their attributes, without being biased to the user sources.

And note, there is no differentiation of the federated users or local users here.. We need to think from the application side, if application should behave all the users same manner then there is only one user type, and those users may come from different sources. And when the application or the system requires different user segments where those different segments have different attributes, there behavior is different to each other, they should be two user types. Again those two user types are orthogonal to the source of those types where two user types may come from totally different sources, and it may come from same sources.

If there are any gaps of the user source and the application/system requirements, Thunder should have sufficient tools to bridge that gap. And there will not be one silver bullet to bridge these gaps, rather each has to determine case by case basis.

Regarding your proposal on the possible paths,

1. Yes, Thunder should have a way to map federated user sub claims to a attribute of the user schema.
   But, if the mapping is challenging and contradicts the attribute property, then most likely you are trying to map two things that shouldn't be mapped.. Just because the federated idp's unique immutable reference is their userid, we shouldn't map that to the unique immutable attribute of the user schema, violating its regex. You solution probably would be, showing the user a prompt and ask to pick a username in this scenario. (or if you expect the federated idps user-id is a valid username, then simply your username regex is wrong).

2. Ability to specify, one of these attributes should be non-empty/required is a nice to have capability.
   My take is that, this required only for very advanced cases, so depending on what you are trying to do, either you are trying to solve very complex use case, or for a common use case our approach/solution is wrong.. I think its the later..

So if you have any exact use case that lead to model the solution like this, lets go through the user schema requirement of the application and then the user sources, and how to match any gaps.

The best way to solve such situations would be through through on the further on the user experience and decide based path we need to provide user the user.

[johannnallathamby]

Agree with @darshanasbg completely. Just wanted to correct one point from the discussion. 'sub' is typically not considered a user attribute in the userstore. It is only a federation attribute in the JWT defined by the OAuth/OIDC specs. We need to be clear of this distinction. That is why we haven't defined sub as a user attribute even in Asgardeo under OIDC attributes but allow the developer to choose the sub value in the application configuration. Most of the OIDC attributes can be considered as userstore attributes; but 'sub' is a special attribute.

In case if the administrator who is setting up this scenario cannot find a way to unify local and federated users due to the differences in their attributes, that means the use case in fact requires to have two kinds of user accounts and we don't need to artificially try to hide it. The admin has to define two different user types IMO and that detail may have to be handled by the applications or at the adaptive authentication level.