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

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