I have the following situation: a user has an application (AppSource) for which he has
credentials and which can act as a SAML IdP.
He also uses another application (AppTarget) for which he has credentials and which can
act as a OIDC IdP.
Finally I have Keycloak which can give the user access to a number of other
applications.
[[AppSource]] ------ IdP-initiated SAML ------> [[Keycloak]]
<------ OIDC ------> [[AppTarget]]
I’ve got the basics running: I can login to Keycloak using both IdPs and can adjust the
behaviour using the Authentication Flows. The initial situation however is that the users
are not present in Keycloak yet.
I would like the following:
1. User access Keycloak from AppSource through the IdP-initiated SAML POST binding (the
only one AppSource supports). With this call, a unique ID is sent from AppSource.
AppSource is trusted (signed SAML etc);
2. Keycloak checks if this AppSource ID is known for a user. If so, it retrieves that user
and sets it in the context: we have a successful login!
3. If the AppSource ID is not known, it should present the user with some instructions and
methods for signing in, including signing in with their AppTarget account through OIDC.
The AppSource ID is somehow remembered;
4. The user clicks that IdP, enters his credentials and once he is redirected back to
Keycloak, Keycloak collects the user profile from AppTarget, creates a Keycloak user with
that data, sets the AppSource ID on this account and sets this user in the context: we
have login!
I’ve got steps 1 and 2 working using a scripted Authentication flow. If I set this one to
optional and add an alternative Username Password Form or Identity Provider Redirector, I
am able to continue to the AppTarget IdP when the AppSource ID is not known (using
context.attempted in the script). However I do not know how to link the two logins once
the user comes back from AppTarget to Keycloak. I tried storing the AppSource ID in the
session in the script (context.getSession.setAttribute), but this value is gone after
coming back from the AppTarget federated login.
Can anybody shed some light on how I am able to achieve what I want? Maybe my approach is
flawed? Thanks for any ideas!
Regards,
Chris Brandhorst