Attribute mapper for generating user identifier

[NicolasLiampotis]

Add attribute mapper for generating an attribute based on the identifier released by the user's authenticating IdP and the identifier of that authenticating authority.

The generated identifiers should have the following form:

SHA-256(username!authenticating_authority!secret_salt)

or, if a scope has been specified:

SHA-256(username!authenticating_authority!secret_salt)@scope

Mapper configuration parameters:

• attribute. A string to use as the name of the newly added attribute. Defaults to subject-id.
• scope: A string to use as the scope portion of the generated user identifier. There is no default scope value; however, you should consider scoping the generated attribute for creating globally unique identifiers that can be used across infrastructures.
• secret_salt: Required - A secret combined with the original identifier information for generating the new identifier value
• skip_authority_list: Optional, an array of IdP entityIDs that should be excluded from the authority part of the user id source.
• idp_tag_whitelist: Optional, an array of tags that the auth process should be executed
• idp_tag_blacklist: Optional, an array of tags that the auth process should not be executed

[NicolasLiampotis]

@laskasn We nee to check the following:

1. How the attribute mapper behaves when the user links additional identities
2. What sync mode to use to ensure that the identifier is generated once - at registration time

[laskasn]

I have setup a keycloak instance to serve as SP (let's call it SP). I have also setup another 2 keycloak instances (let's call them IDP1 and IDP2), which serve as idps for the SP.
I have performed the following scenarios:

Scenario A:

1. Logged in SP through IDP1. A new user was created and a hashed id with value "c1d2c7b3ce0056e6875ff9a0598e8ebf0e96ad4d58a6a9e05b70544fc037cebc@idp1" was created.
2. While logged in, went to the user account management and selected the IDP2 to link the account.
3. After completing the additional login on IDP2, the user was linked with IDP2 as well. No mappers were fired, no modifications were done on the user account.
4. Logged out and tried to log in again this time on IDP2, with the credentials of the linked user. This was done successfully, and the user which i was mapped (amazingly) was the user from the other IDP1. So it "understands" that this user is actually the user from the other idp1. However, any mappers from idp2 are useless, since it sees that it's a linked user from an other idp and never runs them.

Scenario B:

1. Log in through IDP1. Creates user -say- A
2. Log in through IDP2. Creates user B.
3. Log in through IDP1, as user A. Go to the account profile editing and try to link with User B from IDP2. It fails, saying that "Federated identity returned by IDP2 is already linked to another user."

The problem is that the user cannot delete himself (user profile B) in order to recreate it by following the process of scenario A. That's bad.

Regarding the sync mode, if it's at "import", then it will not update the hash on any next logins after the first login.

[laskasn]

I created a pluggable hash-id mapper which can be found here: https://github.com/laskasn/keycloak-idp-hashedId-mapper

This first version does not contain any code to process the

• skip_authority_list: Optional, an array of IdP entityIDs that should be excluded from the authority part of the user id source.
• idp_tag_whitelist: Optional, an array of tags that the auth process should be executed
• idp_tag_blacklist: Optional, an array of tags that the auth process should not be executed

This is something which we have to discuss before doing the implementation.

[laskasn]

Created also a javascript idp mapper which can be found here: https://github.com/eosc-kc/keycloak/tree/63

Did a pull request on keycloak upstream https://github.com/keycloak/keycloak/pull/7918

And created the corresponding issue https://issues.redhat.com/browse/KEYCLOAK-17685