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