Affiliation information in Keycloak user profile

[NicolasLiampotis]

Affiliation information is released through the multi-valued eduPersonScopedAffiliation attribute (urn:oid:1.3.6.1.4.1.5923.1.1.1.9).

Specifies the person's affiliation within a particular security domain in broad categories such as student, faculty, staff, alum, etc. The values consist of a left and right component separated by an "@" sign. The left component is one of the values from the eduPersonAffiliation controlled vocabulary.This right-hand side syntax of eduPersonScopedAffiliation intentionally matches that used for the right-hand side values for eduPersonPrincipalName. The "scope" portion MUST be the administrative domain to which the affiliation applies. Multiple "@" signs are not recommended, but in any case, the first occurrence of the "@" sign starting from the left is to be taken as the delimiter between components. Thus, user identifier is to the left, security domain to the right of the first "@". This parsing rule conforms to the POSIX "greedy" disambiguation method in regular expression processing.

For more information see https://wiki.refeds.org/display/STAN/eduPerson+2020-01#eduPerson202001-eduPersonScopedAffiliation

Keycloak should store any eduPersonScopedAffiliation attribute values released by the Identity Provider in the user's profile under the voPersonExternalAffiliation attribute. This attribute should be updated every time the user logs in. The affiliation information should be made available to clients as follows:

• urn:oid:1.3.6.1.4.1.25178.4.1.11 attribute in the case of LDAP and SAML clients
• voperson_external_affiliation claim in the case of OIDC clients (only when the voperson_external_affiliation scope is requested)

[cgeorgilakis]

This is configuration. We could check it in https://synthesys-demo.rciam.grnet.gr/.

In the case of OIDC clients we could have voperson_external_affiliation in ID token, access token, userinfo. In which of them we want to be exposed?
Moreover, 'only when the voperson_external_affiliation scope is requested' need further investigation.

[cgeorgilakis]

Keycloak for OIDC clients only have two options for client scope:

• Default Client Scopes : client scope applied always
• Optional Client Scopes: client scope applied only when its name exists in scope parameter in the OpenID Connect authorization request

So if we named voperson_external_affiliation the OIDC client scope and add it as optional client scope in client, we can achieve what is described.

All configuration are done in https://login-demo.dissco.eu/. Test need to be done.

[cgeorgilakis]

Affiliation as described above is returned.
We need extra to make Multivalued true in mapper in order to being able to return multivalue attributes ( list ).
However, if User has single affiliation, client mapper will return single value.

[cgeorgilakis]

PR for multivalue always return List. No matter if user has one value.

[NicolasLiampotis]

Examples of multi-valued (lists/arrays of strings) claims:

1. groups, roles, entitlements claims from RFC9068 and RFC7643
2. aud and amr claims from OpenID Connect Specification: https://openid.net/specs/openid-connect-core-1_0.html#IDToken

[cgeorgilakis]

With the following congiguration we can achieve what we want :

• Identity Provider UserAttributeMapper with :

1. AttributeName : urn:oid:1.3.6.1.4.1.5923.1.1.1.9
2. FriedlyName : eduPersonScopedAffiliation
3. User Attribute Name: voPersonExternalAffiliation
4. Sync Mode Override import or force

• OIDC Client Scope with name voperson_external_affiliation. We can show this Client Scope in consent screen with a specific name ( default to voperson_external_affiliation). This Client Scope must have the UserAttributeMapper with the following configuration:

1. User Attribute Name: voPersonExternalAffiliation
2. Token claim name : voperson_external_affiliation
3. Claim Json type : String
4. Multivalued : true ( for return array)
5. access token, ID token, User info : decide when we want this mapper to be taken place

• In the OIDC Client configuration add previous Client Scope (voperson_external_affiliation) as Assigned Optional Client Scopes. This means that if scope = voperson_external_affiliation exists in Client request voperson_external_affiliation with related UserAttributeMapper will be executed.

• We can set Client Scope (voperson_external_affiliation) as Assigned Optional Client Scopes in the Default Client Scopes. This means that every new created OIDC Client will have this Client Scope.

• For Client Registration we can configure in the Client Registration Policies the Allowed Client Scopes for the Client Scopes added to a Client added with Client Registration. Configuration:

1. Allowed Client Scopes extra Client Scopes added.
2. Allow Default Scopes. If true mean that Realm Default Client Scopes will be added together with Allowed Client Scopes.

[cgeorgilakis]

Three first bullets configuration has been done in realm SynthesysPlus of https://login-demo.dissco.eu/