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

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