search

eosc-kc / keycloak

Open Source Identity and Access Management For Modern Applications and Services
https://www.keycloak.org
Apache License 2.0
4 stars 4 forks source link

Add support for different user identifiers #40

Open NicolasLiampotis opened 3 years ago

NicolasLiampotis commented 3 years ago

KC should be able to uniquely idenify users that authenticate via IdPs that release one or more of the following users identifiers:

cgeorgilakis commented 3 years ago

Is this only for SAML IdPs members of SAML federation? As I understand these values will be configured in SAML federation - list of ordered principal type and principal attribute. However, if Subject Persistent NameID exists for transient name ID format IdP we will not set Subject Persistent NameID, will we? Admin is not obliged to select principal type and principal attribute when updating SAML IdP member of SAML federation, is he? If admin configure principal type and principal attribute for SAML IdP member of SAML federation, we will search first for IdP attribute or for federation attribute? Keycloak - as it does now - will throw an exception if noone attribute exist in payload during authorization.

We must discuss what will be applied for SAML IdP belonging to more than one federation.

I propose not to change behaviour for single SAML IdP.

NicolasLiampotis commented 3 years ago

The primary use case is to support multiple identifiers in the context of an IdP federation. However, it might still make sense to support this for individual IdPs because this would be useful in case the IdP changes the attribute for identifying its users. Example: An IdP switches from eduPersonPrincipalName to subject-id. If the candidate list includes both attributes then Keycloak would still be able to allow users to authenticate from that IdP based on the released subject-id attribute.

NicolasLiampotis commented 3 years ago

Working document describing the proposed change: https://docs.google.com/document/d/1iqgVFD6Mm-ZUFy47Tbx9fXBrxddOe-LKkNl29HYCwdM/edit

NicolasLiampotis commented 3 years ago

@cgeorgilakis investigate if Username Template Imported can help for this task

cgeorgilakis commented 3 years ago

Username Template Imported SAML mapper may help if we succeed to extend it. However, this mapper purpose is not for find appropriate identifier. Firstly based on NameID Policy Format, Principal Type and Principal Attribute id and username are set. With these mapper user can select what user field will be affected. Available affected fields (target):

  1. modelUsername ( default)
  2. username (BROKER_USERNAME)
  3. id (BROKER_ID)

The provided template will change selected field. For example id can be {ALIAS}_{NAMEID}, where {ALIAS} is IdP alias and {NAMEID} is subjectNameId. Values can be from :

It will set empty value if Attribute does not exist. For SubjectNameId , this mapper does not chack if SubjectNameId does not exist.

Finally, search will be done via user id in database for find user ( or create new one if no user exists). With Username Template Imported SAML mapper you can change this id. However, I believe that it is not identical for this issue case.

cgeorgilakis commented 3 years ago

Investigate for having it as a mapper

NicolasLiampotis commented 3 years ago

@cgeorgilakis can you investigate the technical feasibility of a mapper that sets the username by using the first non-empty value from the following list of candidate identifier values:

  1. eduPersonUniqueId (attribute)
  2. eduPersonPrincipalName (attribute)
  3. Subject NameID (only if it's persistent)
cgeorgilakis commented 3 years ago

The problem is that Keycloak in first authorization step checks for finding in SAML IdP response the user identifier (based on SAML IdP configured Principal Type and Principal Attribute). If the user identifier does not exist, a BAD_REQUEST exception with INVALID_REQUESTER message was thrown. Mappers are executing after this.

Maybe we can bypass this problem. A solution could be that only a specific new type mapper can be executed during first authorization phase. However, this breaks Keycloak logic and I believe that Keycloak team will not accept such PR.

cgeorgilakis commented 3 years ago

Add firstly per IdP admin adding ordered user identifiers (Principal Type, Principal Attribute). When user logins from this IdP, Keycloak will search in the ordered list to find identifier(first identifier win). If noone identifier was found, an error will be trown.

cgeorgilakis commented 3 years ago

Different user identifiers are supported for SAML Identity Provider ( Principal Type, Principal Attribute or NameIdFormat based on Principal Type). Same configuration exists for SAML Federation. SAML Federation user identifiers are set as SAML Identity Providers user identifiers only for these IdPs that does not have any user identifier. At least one User Identifier is mandatory.

Need to see extra actions between SAML federation user identifiers and its members user identifier.