Re: [keycloak-user] Identity broker login SAMLResponse handling
by Phillip Fleischer
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(a)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(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
>
6 years, 8 months
illegal character in path when testing email setup
by Tiemen Ruiten
Hello,
I get the following error when hitting the 'Test connection' button on the
email tab in Realm settings:
2017-07-10 15:55:27,316 INFO [org.jboss.as] (Controller Boot Thread)
WFLYSRV0025: *Keycloak 3.2.0.Final (WildFly Core 2.0.10.Final)* started in
21731ms - Started 449 of 824 services (561 services are lazy, passive or
on-demand)
2017-07-10 15:56:48,997 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-11) RESTEASY002130: Failed to parse request.:
javax.ws.rs.core.UriBuilderException: RESTEASY003330: Failed to create URI:
https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConnection/{
"port":null,"host":"mail.rdmedia.com
","ssl":"","starttls":"","auth":"","from":"account(a)rdmedia.com"}
at
org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValues(ResteasyUriBuilder.java:749)
at
org.jboss.resteasy.specimpl.ResteasyUriBuilder.build(ResteasyUriBuilder.java:721)
at
org.jboss.resteasy.spi.ResteasyUriInfo.initialize(ResteasyUriInfo.java:58)
at org.jboss.resteasy.spi.ResteasyUriInfo.<init>(ResteasyUriInfo.java:53)
at
org.jboss.resteasy.plugins.server.servlet.ServletUtil.extractUriInfo(ServletUtil.java:41)
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:200)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at
org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.URISyntaxException: Illegal character in path at index
67: https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConnection/{
"port":null,"host":"mail.rdmedia.com
","ssl":"","starttls":"","auth":"","from":"account(a)rdmedia.com"}
at java.net.URI$Parser.fail(URI.java:2848)
at java.net.URI$Parser.checkChars(URI.java:3021)
at java.net.URI$Parser.parseHierarchical(URI.java:3105)
at java.net.URI$Parser.parse(URI.java:3053)
at java.net.URI.<init>(URI.java:588)
at
org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValues(ResteasyUriBuilder.java:744)
... 40 more
The 67th character is the slash after testSMTPConnection. Is this a bug
and/or is there a workaround/fix?
--
Tiemen Ruiten
Systems Engineer
R&D Media
6 years, 8 months
When should auth_time claim be updated?
by Matt Evans
Hi
We are working with keycloak v3.2.0 and are using 'prompt=login' to initiate a re-authentication for sensitive actions, and we use the auth_time claim to determine if this should occur.
Ordinarily each time we redirect to the auth endpoint with 'prompt=login' the auth_time is updated to the time that the authentication occurred.
However, if we then redirect to the auth endpoint and the cookie is valid and used, any subsequent time after this authentication that we use the auth endpoint with 'prompt=login' the auth_time claim is not updated.
Is this intended behaviour?
Thanks
Matt
6 years, 8 months
Obtaining profile from AccessToken
by Richard van Duijn
I have an application that uses bearer-token validation of backend
requests. This Bearer token is an Accesstoken.
What API endpoint should i call to obtain the full User Profile including
IDToken and RefreshToken?
I know of the userInfo endpoint, but that only gives me basic user
information, not the IdToken or Refreshtoken?
Thanks in advance!
6 years, 8 months
Revokin an OAuth token
by Narendra Kadali
Hi,
I am wondering if Keycloak can support revoking an OAuth 's access/refresh tokens. I tried to look into Keycloak documentation and api guide but can't find any info on it.
I see there is an RFC for OAuth token revocation - RFC 7009 (https://tools.ietf.org/html/rfc7009) . Is there any plans for implementing this RFC in future?
Thanks!
Naren
6 years, 8 months
Help for Keycloak OpenID Connect integration with Apereo CAS
by Harshad Keluskar
Hi Team,
I would need to use Keycloak as IDP and CAS as a delegation authentication for Liferay 7 CE. It would be great, if anyone could help me with examples or step by step guide, if ready with anyone.
Thanks,
Harshad.
6 years, 8 months
Email verification timeout
by Thiago Presa
Hi,
We've noticed a change between 3.1.0.Final and 3.2.0.Final that we're not
sure is intentional. The e-mail verification time changed from 5 minutes
(User-Initiated Action Lifespan) to 12 hours (Default Admin-Initiated
Action Lifespan). It seems weird for us because it does not seem
admin-initiated, since it is part of the default user registration process
to verify his or her email. Is this a bug?
Best regards,
Thiago Presa
6 years, 8 months
Identity broker login SAMLResponse handling
by Phillip Fleischer
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
6 years, 8 months
SAML Identity Broker - First Login/Browser Flow - Password
by lason
Hi guys,
I am currently trying to implement the following SAML broker flow with KC
3.0.1.Final:
Assumption: User not known
User goes to App
User is redirected to KC
User is redirected to SAML IDP and is authenticated there with smartcard
User is redirected back to App
In KC user was created and the assertion attributes were mapped
Now user logs out
User goes to App
User is redirected to KC
User is redirected to SAML IDP and is authenticated there with smartcard
But now KC says invalid username or password
How can it be done, that on second time IDP brokering, the user is redirect
to the app without any password check by using the already existing KC user
info on username match (may updates the mapping beforehand in case saml
attributes changed)?
thanks
regards
lason
--
View this message in context: http://keycloak-user.88327.x6.nabble.com/SAML-Identity-Broker-First-Login...
Sent from the keycloak-user mailing list archive at Nabble.com.
6 years, 9 months
