[keycloak-user] Identity broker login SAMLResponse handling

Hynek Mlnarik hmlnarik at redhat.com
Mon Jul 31 02:00:09 EDT 2017


I don't understand the scenario either. What exactly is the scenario?
The loop is between which parties? How does "another broker" fit into
the picture, is it even Keycloak? Why does your OIDC client not use
Keycloak OIDC capabilities directly? Is it necessary to relay the SAML
response to the client and process it there?

Can you rephrase it with explicitly labeling the parties (kc server,
non-kc-server (?), client, brokered idp, ...) when you mention them?

On Sun, Jul 30, 2017 at 2:12 PM, Phillip Fleischer
<pcfleischer at outlook.com> wrote:
> Yeah, I presume it’s a logical understanding error but to elaborate…
>
> We’re attempting to relay the succesful login response and client session to an OIDC client using the js adapter.
>
> - Idp Initiated broker seems to be succesful and gets to post login actions
> - Idp Initiated client POST another SAMLResponse to ACS POST Binding URL
> - This response is signed by KC, if we set up another broker we’ll endlessly be sending SAMLResponses.
>
> We were thinking we might just be relayed to our client after session and the app would check the session and kick of the OIDC flow. Maybe we need to implement saml adapter in our application to handle the final response?
>
> — Phil
>
>> On Jul 29, 2017, at 10:06 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>> I don't understand what the error is.  Your external IDP sends a login
>> response to
>>
>> https://{root}/auth/realms/{realm}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>>
>> And there is an infinite loop?
>>
>> On 7/29/17 5:03 AM, Phillip Fleischer wrote:
>>> Hi,
>>>
>>> We’re using keycloak for several authorization use cases already and are attempting to prototype some identity brokering with an external IdP application.
>>>
>>> Our current configuration the user is logged in the external IdP which sends a POST with the SAMLResponse directly to our broker. It looks the appropriate solution is idp initiated configuration in the examples.
>>>
>>> broker: external-idp-name
>>> client and url name: saml-idp-initiated
>>>
>>> https://{root}/auth/realms/{realm}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>>>
>>>
>>> The challenge is that our client the posts yet another SAMLResponse either back to our broker or to the realm saml service.
>>>
>>> These result in following results...
>>>
>>> 1 - {realmUrl}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>>> |—- infinite redirect loop POST SAMLResponses
>>> 2 - {realmUrl}/broker/{broker}/endpoint
>>> |—- handleSamlResponse fails to validate “code” set to “relayState”.
>>> 3 - {realmUrl}/protocol/saml
>>> |—- handles SAMLResponses as logout and fails.
>>>
>>>
>>>
>>>
>>> It feels like we’re either totally missing the mark or this is a use case totally
>>> not supported that we’re attempting to kluge together. Anyone have thoughts where we’re going conceptually wrong??
>>>
>>>
>>> — Phil
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 

--Hynek



More information about the keycloak-user mailing list