Re: [keycloak-dev] Application and server in separate networks

I can't get SAML to work. Everytime I try to access a protected page, I get the error "Client is not allowed to initiate browser login with given response_type. Standard flow is disabled for the client". In the logs I see "type=LOGIN_ERROR, realmId=LOCAL, clientId=null, userId=null, ipAddress=10.0.0.1, error=not_allowed" Is there anything I can do to further debug this? I'm using 3.3.0.Final and configured SAML via keycloak-saml.xml having roughly the following content <?xml version="1.0" encoding="UTF-8"?> <keycloak-saml-adapter xmlns="urn:keycloak:saml:adapter" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:keycloak:saml:adapter http://www.keycloak.org/schema/keycloak_saml_adapter_1_7.xsd"> <SP entityID="myapp" sslPolicy="EXTERNAL" nameIDPolicyFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" logoutPage="/logout" forceAuthentication="false" isPassive="false" turnOffChangeSessionIdOnLogin="false"> <IDP entityID="idp" signaturesRequired="false"> <SingleSignOnService requestBinding="POST" bindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml" /> <SingleLogoutService requestBinding="POST" responseBinding="POST" postBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml" redirectBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml" /> </IDP> </SP> </keycloak-saml-adapter> Am I missing something or is having a SAML endpoint on Keycloak along with a SAML client not a supported scenario configuration? Mit freundlichen Grüßen, ------------------------------------------------------------------------ *Christian Beikov* Am 26.04.2018 um 16:50 schrieb Bill Burke: > SAML would definitely work for your case so long as you don't need a > token to make other REST invocations. > > On Thu, Apr 26, 2018 at 9:59 AM, Christian Beikov > <christian.beikov(a)gmail.com&gt; wrote: >> Thanks for the hints. I'll try to see if I can get SAML to work and let >> you know of the result. Anyway, the POST response_mode sounds promising >> and would definitely work in our case. When I put the URL hash I got >> while testing into the query part of the URL, the authentication worked >> properly. So doing a form encoded POST would probably work as well. >> >> >> Mit freundlichen Grüßen, >> ------------------------------------------------------------------------ >> *Christian Beikov* >> Am 26.04.2018 um 15:06 schrieb Marek Posolda: >>> I think it works, but didn't tested that combination. And POST is not >>> supported by any of our adapters ATM, just by server. I know that some >>> of our users use Form POST with 3rd party adapters, but likely the >>> combination of FormPOST with standard flow. >>> >>> On 26/04/18 14:38, Bill Burke wrote: >>>> Cool, so POST mode works with Implicit? >>>> >>>> On Thu, Apr 26, 2018 at 4:16 AM, Marek Posolda <mposolda(a)redhat.com&gt; >>>> wrote: >>>>> We support response_mode parameter and we also support HTML POST mode >>>>> already on server side. But we specifically disallow "query" >>>>> response_mode >>>>> with implicit flow [1] . This is required per specification and OIDC >>>>> certification had a test exactly for this AFAIR. >>>>> >>>>> [1] >>>>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/o... >>>>> >>>>> >>>>> Marek >>>>> >>>>> >>>>> On 25/04/18 23:20, Bill Burke wrote: >>>>>> We should probably support response_mode parameter [1] and allow >>>>>> "query" mode for implicit invocations. IMO, the HTML POST mode [2] >>>>>> (like SAML does) would be better as with implicit mode, the access >>>>>> token is leaked to browser history. >>>>>> >>>>>> [1] https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>>> [2] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html >>>>>> >>>>>> On Wed, Apr 25, 2018 at 4:14 PM, Christian Beikov >>>>>> <christian.beikov(a)gmail.com&gt; wrote: >>>>>>> Hey all, >>>>>>> >>>>>>> we reached a point where we are not sure how to proceed with the PR >>>>>>> https://github.com/keycloak/keycloak/pull/5167 for >>>>>>> https://issues.jboss.org/browse/KEYCLOAK-7195 >>>>>>> >>>>>>> We added a client adapter configuration for the flow and that part >>>>>>> works >>>>>>> so far, but we noticed that when the Keycloak server encounters a >>>>>>> request for authetication via the implicit flow, it puts the token >>>>>>> into >>>>>>> the query fragment part which isn't sent to the application. This >>>>>>> is the >>>>>>> point where it becomes obvious this mechanism is intended for the JS >>>>>>> adapter :) >>>>>>> >>>>>>> To resolve the problem and make the flow usable for the Java >>>>>>> adapter as >>>>>>> well, we'd need some way to configure the response mode in the >>>>>>> OIDCLoginProtocol. My question is, how you think this should be done. >>>>>>> I was thinking of either allowing a query parameter to specify the >>>>>>> response mode or a configuration switch in the UI for the client. >>>>>>> I kind >>>>>>> of prefer the query parameter solution. >>>>>>> >>>>>>> Is this even a change/feature you would be interested in? We need the >>>>>>> implicit flow because the Keycloak server is in a private network >>>>>>> that >>>>>>> is separate from the application. Maybe there are other people out >>>>>>> there >>>>>>> that have similar needs? >>>>>>> >>>>>>> Mit freundlichen Grüßen, >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> *Christian Beikov* >>>>>>> Am 20.04.2018 um 09:15 schrieb Niels Bertram: >>>>>>>> Hi Christian, >>>>>>>> >>>>>>>> can't say for sure but the server side adapters always use standard >>>>>>>> authorization flow, which requires your Java app to connect via a >>>>>>>> back >>>>>>>> channel to (A) exchange code grant for access tokens and (B) to >>>>>>>> lookup >>>>>>>> jwks for token validation. >>>>>>>> >>>>>>>> The OpenID Connect specification does provide a pure browser based >>>>>>>> flow calledimplicit flow >>>>>>>> >>>>>>>> <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>but >>>>>>>> >>>>>>>> that one has a few drawbacks such as auth tokens delivered in the >>>>>>>> redirect URL and no refresh token capability. Using this flow could >>>>>>>> solve your problem (A) to shift login flow to the frontend but still >>>>>>>> poses the challenge for (B) validating the tokens at the backend. >>>>>>>> >>>>>>>> I could not find a way to configure the Java adapter to work in pure >>>>>>>> offline validation mode. We had a similar requirement some time ago >>>>>>>> and had to code our own auth module to validate incoming tokens >>>>>>>> with a >>>>>>>> pre-configured public key. The other common problem we ran into is >>>>>>>> wanting to validate tokens from different (including non-keycloak) >>>>>>>> issuers on the same backend. The Keycloak Java adapters do not >>>>>>>> support >>>>>>>> this use case either. We originally looked at the Spring JWT adapter >>>>>>>> >>>>>>>> <https://github.com/spring-projects/spring-security-oauth/tree/master/spri... >>>>>>>> >>>>>>>> as an alternative but this project is not properly patched and >>>>>>>> configuration is a wonderful garden of mystery like everything in >>>>>>>> Spring. >>>>>>>> >>>>>>>> Very curious though to see what others are doing. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Niels >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov >>>>>>>> <christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> As far as I see in the code, the Java Adapters always use the >>>>>>>> standard >>>>>>>> flow i.e. response_type=code >>>>>>>> >>>>>>>> Please tell me this observation is wrong and there is an >>>>>>>> undocumented >>>>>>>> setting I just didn't see that I can use to tell the >>>>>>>> adapter to >>>>>>>> use the >>>>>>>> implicit flow instead :| >>>>>>>> >>>>>>>> If this is really missing, where would you suggest this >>>>>>>> should be >>>>>>>> configured? I'd expect the setting to be in >>>>>>>> KeycloakDeployment and >>>>>>>> OAuthRequestAuthenticator#loginRedirect would then use the >>>>>>>> value >>>>>>>> instead >>>>>>>> of always using the "code" value. >>>>>>>> >>>>>>>> >>>>>>>> Mit freundlichen Grüßen, >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> *Christian Beikov* >>>>>>>> Am 18.04.2018 um 17:35 schrieb Christian Beikov: >>>>>>>> > >>>>>>>> > Is there any way to avoid the access code to access token >>>>>>>> exchange? >>>>>>>> > Since the Keycloak server is not accessible, I'm getting >>>>>>>> an error >>>>>>>> > during authentication: >>>>>>>> > >>>>>>>> > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] >>>>>>>> (default >>>>>>>> > task-54) failed to turn code into token: >>>>>>>> > java.net.UnknownHostException: blabla.local: unknown error >>>>>>>> > ... >>>>>>>> > at >>>>>>>> > >>>>>>>> >>>>>>>> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111) >>>>>>>> >>>>>>>> > at >>>>>>>> > >>>>>>>> >>>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330) >>>>>>>> >>>>>>>> > at >>>>>>>> > >>>>>>>> >>>>>>>> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275) >>>>>>>> >>>>>>>> > at >>>>>>>> > >>>>>>>> >>>>>>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139) >>>>>>>> >>>>>>>> > at >>>>>>>> > >>>>>>>> >>>>>>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) >>>>>>>> >>>>>>>> > at >>>>>>>> > >>>>>>>> >>>>>>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) >>>>>>>> >>>>>>>> > ... >>>>>>>> > >>>>>>>> > >>>>>>>> > Mit freundlichen Grüßen, >>>>>>>> > >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> > *Christian Beikov* >>>>>>>> > Am 18.04.2018 um 14:48 schrieb Thomas Darimont: >>>>>>>> >> Hello Christian, >>>>>>>> >> >>>>>>>> >> your application server needs to communicate with the >>>>>>>> Keycloak >>>>>>>> server >>>>>>>> >> to retrieve the realm public key referenced in the token to >>>>>>>> verify >>>>>>>> >> the token signature. >>>>>>>> >> The current implementation in Keycloak fetches & caches >>>>>>>> unknown >>>>>>>> >> public keys automatically. >>>>>>>> >> >>>>>>>> >> You could also use a fixed realm public key on the >>>>>>>> application >>>>>>>> server >>>>>>>> >> side but it would not support key rotation anymore. >>>>>>>> >> >>>>>>>> >> Cheers, >>>>>>>> >> Thomas >>>>>>>> >> >>>>>>>> >> 2018-04-18 13:45 GMT+02:00 Christian Beikov >>>>>>>> >> <christian.beikov(a)gmail.com >>>>>>>> <mailto:christian.beikov@gmail.com> >>>>>>>> <mailto:christian.beikov@gmail.com >>>>>>>> <mailto:christian.beikov@gmail.com>>>: >>>>>>>> >> >>>>>>>> >> Hi, >>>>>>>> >> >>>>>>>> >> is it necessary that an application secured by >>>>>>>> Keycloak can >>>>>>>> >> access the >>>>>>>> >> Keycloak server? Or is it enough if the Browser can >>>>>>>> access >>>>>>>> the >>>>>>>> >> Keycloak >>>>>>>> >> server? >>>>>>>> >> >>>>>>>> >> -- >>>>>>>> >> >>>>>>>> >> Mit freundlichen Grüßen, >>>>>>>> >> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> >> *Christian Beikov* >>>>>>>> >> _______________________________________________ >>>>>>>> >> keycloak-dev mailing list >>>>>>>> >> keycloak-dev(a)lists.jboss.org >>>>>>>> <mailto:keycloak-dev@lists.jboss.org> >>>>>>>> <mailto:keycloak-dev@lists.jboss.org >>>>>>>> <mailto:keycloak-dev@lists.jboss.org>> >>>>>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev> >>>>>>>> >> <https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>> >>>>>>>> >> >>>>>>>> >> >>>>>>>> > >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> keycloak-dev mailing list >>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>> <mailto:keycloak-dev@lists.jboss.org> >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev