Identity Brokering - linking multiple subjects from the same IdP

[Jim Culbert]

We have a need to link multiple accounts from the same IdP to a single keycloak account. Right now keycloak will only allow a single account per IdP to be linked to a keycloak account.

---------------------

Use Case:

We use a service called CILogon to bridge between SAML and OIDC for IdPs that are part of the InCommon federation.

CILogon does not link accounts; each logon from each university IdP to CILogon looks like a different user.

If I have accounts at MIT and Harvard, for example, and use CILogon to broker SAML-to-OIDC, keycloak will be presented with two different users (from the same IdP) when I use each of those accounts. I would like to be able to allow my application users to link their multiple university identities as presented from CILogon (i.e. multiple different CILogon subject ids) to a single keycloak account.

There are order thousand(s) of incommon IdPs so pulling them all into keycloak, while theoretically possible, seems an inadvisable solution.

[Lawrence Tarbox]

We have a similar problem.  For example, we would like to use InCommon, and by extension EduGain to allow individuals from thousands of research institutions to log into The Cancer Imaging Archive (TCIA - http://www.cancerimagingarchive.net) with their institutional credentials, rather than having to create a special TCIA account.  We would like to use Keycloak to do this; however, got stymied with what appears to be a requirement to enter each individual institution as an IdP, which is a daunting task.  Making matters worse, Keycloak seems to want to provide different SP metadata for each of the IdPs.  The InCommon Federation expects a single set of SP Metadata, registered with the InCommon Federation, that any IdP in the federation could then use to authenticate requests coming from the Keycloak SP.

The whole purpose of the InCommon federation was to avoid  having to do a many to many exchange of IdP and SP metadata.  InCommon themselves provides a registry of validated Identity Providers (IdP) and Service Providers (SP) that can be used.  It would be nice if Keycloak itself could communicate with Identity Federations such as InCommon for the list of possible IdPs (discovery), and answer to any of those IdP with a single SP service point in Keycloak.  

The CILogin (https://www.CILogin.org) approach described in the earlier message is one possible work around.  But using CILogin for discovery does add yet one more level of indirection when authenticating users, add an extra step that, in my opinion, should be handled by Keycloak itself.  

Regardless, we do have situations where we do have multiple accounts from the same IdP that could be tied to the same Keycloak account, as described above.