Repository navigation
simple chaining of Keycloak #23599
Replies: 3 comments 8 replies
|
It sounds like you just want to configure Identity Brokers so it's not clear what isn't working. For instance there are Keycloak tests that configure a consumer realm and a provider realm for integration testing for the brokering. There's no relation here with using token exchange. |
|
Error message I am getting now: I checked the mappers again. They are correct I believe. The application only needs: email, firstname and lastname. I have configured it as basic. This is the SAML Token generated by the "inner" Keycloak instance (port 9443), just before the error occurs, trying to send it back to the "outer" Keycloak instance (port 8443). In the "outer" Keycloak instance the mapping is defined as: |
|
dont know if it has been solved, anyway I have been facing the same issue, the pb is that I have updated the alias of the IDP, when u change the alias, the redirect URI is changed automatically, so need to update the URL in the SAML IDP |
Uh oh!
There was an error while loading. Please reload this page.
I'm trying to do a simple chaining of Keycloak.
I tried first with two realms. Now trying with two instances of keycloak on the same server, but different ports.
Let's call them: inner-keycloak and outer-keycloak.
The inner-keycloak instance is configured with User Federation, where LDAP servers have been configured.
From this a SAML Token is generated. SAML client has been defined: this SAML Client is referring to Identity Provider defined in the outer-keycloak instance. Using the SP metadata from that Identity Provider definition in the outer-keycloak instance.
So, in the outer-keycloak instance, a SAML Identity Provider has been defined, using the Identity Provider metadata from the realm (containing corresponding client definition) in the inner-keycloak instance.
(Also Azure Active Directory is defined in a second Identity Provider in the outer-keycloak instance - this IDP works!)
An application has been defined as SAML client in this outer-keycloak instance. Users are to be authenticated by either Azure AD (doesn't contain all users) or the LDAP Server (contains the missing users).
Using a SAML tracer, we can see that the SAML Token gets correctly created from the LDAP server, in the inner-keycloak instance. But it doesn't get transferred to the IDP of the outer-keycloak instance.
Questions:
Any help/suggestions on this issue is very welcome.
All reactions