@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:
- User logs in through external IDP into some external system
- User follows a link like this: http://localhost:8080/auth/realms/auth-realm/protocol/saml/clients/sso
- User is redirected to SP keycloak (alternatively that’s where user logs in and is redirected to SP) with SAML assertion
- 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.
- User is redirected to OIDC-based app with all ther required session cookies, meaning he’s logged in.