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(a)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(a)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(a)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(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
--Hynek