Relay State in IDP initiated SSO from external IDP

Getting advice
, ,
1

Hi,
I am implementing IDP(external IDP) initiated SSO with Keycloak as SP provider. Currently I am able to successfully configure the IDP initiated SSO from external IDP, but I see issue with RelayState url
Here is the flow

  • User logs into IDP
  • Click on app which is set for IDP initiated SSO
  • IDP sends SAML assertion along with post param RelayState
    (eg: RelayState → https://server.com/test?userId=123&service=hsia)
  • Keycloak verifies the assertion and logs the user and redirects to https://server.com/test

Seems like Keycloak is not using RelayState sent from external IDP. Anyone faced this issue before?

2

Hi @keycloak_user , did you get the IDP initiated SSO to work? If so, kindly let me know if your workflow is similar to the following:

  1. Login to my identity provider (like ping, okta, Azure AD etc)
  2. Click on the app that my admin has created
  3. Clicking on the app should SSO the user to keycloak (where I have created an Identity Provider and a client)
3

Hi, have you had any luck with setting up SAML IDP initiated login? I’ve tried to follow this article Keycloak with Okta IDP Initiated SSO Login | Lisenet.com :: Linux | Security | Networking but still can’t make it work properly.
As far as I understand, to make IDP initiated flow working we need to have one more “proxy” SAML client that forwards assertion to IDP broker in Keycloak that is integrated with 3rd party IDP (I use Okta). On other side Okta should target its SAML assertion to that SAML “proxy” client.
Finally I see SAML “handshake” is happening and Keycloak displays message “You are already logged in” and no redirect happens like in SP initiated flow.
Looks like some small piece is missing somewhere in configuration that will allow to redirect user to proper destination. Setting RelayState in “proxy” client settings does not help to redirect.
I’d appreciate any help. Thanks.

4

@shmatoid
I think your idea of a “proxy” is just about the only solution.
We had a somewhat similar situation - IDP initiated flow, but the end UI had to support orinary OIDC logins as well. However, you cannot redirect to OIDC-backed ui directly from IDP initiated flow.
As a result we had to make a simple redirect controller in that app to serve as SAML Assertion Consumer URL on the SP, essentially a “proxy” you describe.

The resulting flow for IDP initiated SSO looks like this:

  1. User logs in through external IDP into some external system
  2. User follows a link like this: http://localhost:8080/auth/realms/auth-realm/protocol/saml/clients/sso
  3. User is redirected to SP keycloak (alternatively that’s where user logs in and is redirected to SP) with SAML assertion
  4. SP keycloak has a client set up to handle requests from that url, and has Master SAML Processing URL set to a simple redirect page. This allows keycloak to handle incoming saml response, set up cookies, etc.
  5. User is redirected to OIDC-based app with all ther required session cookies, meaning he’s logged in.
1 Like
5

Thanks for the advice!

6

@shmatoid oh and btw, just tested this, if you are fine with using redirect flow you can drop the proxy client whatsoever - simply specify your oidc-app url in “Assertion Consumer Service Redirect Binding URL” of the service provider. In my case it was keycloak’s /account page. Admittedly you’ll have two open sessions that way - one for saml client and one for oidc application, but that’s better than a useless ui or endpoint.

1 Like
7

I faced this same issue but got IDP initiated SSO working - for anyone who comes across this thread, hopefully this guide is helpful.