KEYCLOAK-4509 Support IDP Initiated to OIDC RP

[gonzalad]

Mostly as a proof of concept, I'll add unit tests if the general idea is ok. I feel code can be improved, but I'm a bit too young on KC to know the good areas to extend

KC supports only SAML Clients for IDP Initiated login.

This commit adds IDP Initiated login to OIDC Clients.

To use this feature, the admin needs:

• in Client conf
  ** IDP Initiated SSO URL Name=
  ** IDP Initiated Target URL=
• in the external IDP configuration, set keycloak
  redirectURL=http:///auth/realms//broker//endpoint/clients/

The whole behaviour will be :

• the user is authenticated in external IDP.
• external IDP dashboard page list all available Client.
• user clicks on a Client.
• external IDP redirects to KC (using SAML).
• KC validates the authentication.
• KC redirects to the OIDC RP (IDP Initiated Target URL).
• OIDC RP initiates a OIDC authentication flow, and redirects to KC
• KC creates automatically a session and redirects back to OIDC RP.

[stianst]

I'm not really following the flow you are proposing here. It doesn't seem to consider OIDC at all and I don't see how it would actually work since OIDC clients are supposed to check state/nonce values they generate themselves. There's some mention in OIDC specs about third-party initiated logins (https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin), but not really enough to understand how it should be done safely.

The code here is also incredibly messy and is abusing the SAML code base.

[stianst]

Closing due to lack of feedback

[stianst]

If you are still interested in this please open a discussion on keycloak-dev around this

[gonzalad]

Hi @stianst, sorry for the lack of feedback on my part.

I've a new job, so I was quite busy on other topics. Alas, I won't have time in the near future to continue working on this PR - perhaps it's better: I'll stop doing ugly code :).

I'll just add some notes to have a better explanation (at least I hope !)

Use case

My need at the time I wrote the PR:

• I had a OIDC/OAuth RP application, let's call it ac-sandbox
• The application was secured with Keycloack
• I needed to include the application inside the end-user Okta dashboard (end-user was using okta as his IDP).
• When the end-user clicks on the application icon in Okta, I wanted the end-user to be automatically logged into the OIDC RP application (this means I needed some IDP initiated login for my OIDC application)

Okta was configured as SAML IDP in Keycloak.

PR usage

Configuration

With this PR, I configured the OIDC RP ac-sandbox in KC with these 2 new values:

• IDP initiated SSO URL Name=ac-sandbox
• IDP initiated target URL=http://localhost:8082
  In fact, this IDP initiated target URL is similar to the initiate_login_uri from the spec you mentioned: https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin

In KC side, I configured Okta as external SAML IDP with a name okta.
In Okta side, I configured the ac-sandbox app in the user dashboard with a redirectURL=http://localhost:8080/auth/realms/realm1/broker/okta/endpoint/clients/ac-sandbox.
my KC being installed on localhost:8080

In summary, Okta initiates a SAML IDP authentication flow with KC, and then KC simulates a 3rd party initiated login to the OIDC RP ac-sandbox.

I don't know if we can achieve a full OIDC flow (Okta -> KC and KC -> my OIDC RP), if yes, perhaps it will be easier and cleaner than a hald SAML / half OIDC.

Test it

• I went to the okta dashboard
• okta asked me to login to Okta before displaying the dashboard.
• I log into Okta, and see my dashboard
• I click on ac-sandbox link in the dashboard.
• Okta initiated SAML with KC
• KC detects from the URL (http://localhost:8080/auth/realms/realm1/broker/okta/endpoint/clients/ac-sandbox) that it needs to do a IDP initiated login to ac-sandbox.
  ** My hack detects that the target app is an OIDC application (not a SAML)
  ** My hack makes a plain redirect to the configured IDP initiated target URL (aka http://localhost:8082
  )
• the OIDC application handles the call if the index.html page requires authentication, it starts a OIDC authentication flow (hence redirects to KC).
• KC handles the OIDC authentication flow, since the user is already logged in, the OIDC flow continues (without asking the user to login), and KC redirects back to the sandbox-ac
• sandbox-ac retrieves the accessToken, the user is logged in automatically in KC and we have simulated a OIDC IDP initiated flow.

Conclusion

I completely agree about the code, it is hacky. but I didn't found a good way to implement it cleanly in a short timeframe.
This PR shows a way on how to achieve IDP initiated authentication in OIDC world.

[gonzalad]

Looking at https://support.okta.com/help/Documentation/Knowledge_Article/Using-the-App-Integration-Wizard-1111708899, Okta provides early access support for OIDC in their App Integration Wizard, and implements http://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin.

So a better way would be - as you pointed out - to have a third party initiated OIDC login (with full OIDC between IDP <-> KC <-> OIDC RP).
Perhaps having the same kind of support of http:///auth/realms/{realm}/broker/{idp}/endpoint/clients/{client} for OIDC IDP as the one KC provides for SAML.

This way, we could configure okta as a OIDC AS (instead of SAML) in KC and configure KC in Okta with:

• the initiate_login_uri http:///auth/realms/realm1/broker/okta/endpoint/login/ac-sandbox (for ac-sandbox app)
• redirectURL would be http:///auth/realms/realm1/broker/okta/endpoint/clients/ac-sandbox

The full flow would then be:

• end user goes to Okta dashboard
• end-user logins to Okta
• he clicks on ac-sandbox icon
• Okta redirects the user to http:///auth/realms/realm1/broker/okta/endpoint/login/ac-sandbox
• KC (acting as OIDC TP) initiates OIDC authentication flow with okta
• Okta redirects back the user to KC http:///auth/realms/realm1/broker/okta/endpoint/clients/ac-sandbox
• KC redirects the user to the initiate_login_uri of the registered ac-sanbox app (i.e. localhost:8082)
• ac-sandbox acts as OIDC RP and starts OIC authentication flow, redirects to KC
• KC redirects back to ac-sandbox redirect_url
• ac-sandbox gets the accessToken

[stianst]

Could you please open a discussion on keycloak-dev around this?

[gonzalad]

Just done, thanks Stian !

[ibauersachs]

For reference, I've implemented something very similar in December, also for use with Okta as a SAML IdP. See master...Xovis:kc4509

Unfortunately my message to the dev-list describing my use case never made it through. I'll try to follow up on @gonzalad's message on the list again.

[shankaryadavy9]

I have exactly the same requirement. Are some discussions going on somewhere..?
I had raised the same issue as well on this
https://issues.redhat.com/browse/KEYCLOAK-16527