[keycloak-user] Identity broker login SAMLResponse handling

Thu Aug 3 08:48:52 EDT 2017

Hi Guys,

I’m revisiting this again and I think we found a solution.

I kept the same setup but instead of the post binding url being either the externalidp (non-keycloak-idp) or another keycloak identity broker i set the url’s to be our client application.  I basically ignore the saml response and voila the oidc javascript adapter handles the redirect, oidc token request, etc.

Here are some ideas… any sound like the right direction?
1) Add a custom authentication flow for “Post-Login” which handles the relay instead of saml client.
2) Somehow configure the Idp client to use “redirect binding” (it seems like after attaching debugger this is impossible because the client is doing a null check and this is an empty string?)
3) Setup our client application to have an endpoint which basically ignores the post binding.

I personally like the idea of #1 since this would give use some nice control over any other custom actions we may need to perform that can’t be handled by the standard flow.

— Phil

> On Jul 31, 2017, at 6:08 AM, Phillip Fleischer <pcfleischer at outlook.com> wrote:
> 
> Maybe we just have our client setup wrong and it’s possible to configure it to redirect to the “management url”??
> 
> We tried that for a while but it seemed that the client expected to only want to redirect or post another SAML Response to another endpoint.
> 
>> On Jul 31, 2017, at 5:53 AM, Phillip Fleischer <pcfleischer at outlook.com> wrote:
>> 
>> No problem,
>> 
>> Our application is angular js using keycloak oidc adapter with spring boot back end.  The native behavior to use keyclaok OIDC directly.
>> 
>> The Third Party (Non-kc-server) is the external SAML IdP which we wish to trust to authenticate in via SAMLResponse registering/linking and authenticating into the application.   We expect we may have many of these so we’re attempting to use KC for ease of use instead of rolling our own.
>> 
>> 1) Not-KC -> POST SAMLResponse to kc to authenticate.
>> 2) KC -> Idp broker - handle this saml response.
>> 3) KC -> SAML client - Idp Initiated 
>>  (cannot use broker directly - it appears to require that KC initated SAMLRequest with “code” to be sent in response??)
>> 4) KC -> SAML client - result in POST SAMLResponse to the ACS url.
>>  (SAMLResponse still does not have a code that could be handled directly by broker directly??)
>> 
>> Up to #3 seems to work, but I think we’d expect that #4 saml client would redirect us to our client (thru relaystate), but it results with a SAMLResponse POST to the ACS url in the client configuration.  This is basically back where we started… so hence the logical infinite loop (if we add more brokers and clients we just keep getting more and more saml responses without codes).
>> 
>> Hope that helps explain, 
>> 
>> — Phil
>> 
>>> On Jul 31, 2017, at 2:00 AM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>> 
>>> 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
>> 
> 
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user