[keycloak-dev] Application and server in separate networks
Bill Burke
bburke at redhat.com
Thu Apr 26 10:50:41 EDT 2018
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 at gmail.com> 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 at redhat.com>
>>> 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/org/keycloak/protocol/oidc/endpoints/AuthorizationEndpoint.java#L227
>>>>
>>>>
>>>> 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 at gmail.com> 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/spring-security-jwt>
>>>>>>>
>>>>>>> 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 at gmail.com <mailto:christian.beikov at 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 at gmail.com
>>>>>>> <mailto:christian.beikov at gmail.com>
>>>>>>> <mailto:christian.beikov at gmail.com
>>>>>>> <mailto:christian.beikov at 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 at lists.jboss.org
>>>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>>>> <mailto:keycloak-dev at lists.jboss.org
>>>>>>> <mailto:keycloak-dev at 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 at lists.jboss.org
>>>>>>> <mailto:keycloak-dev at 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 at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>
>>>
>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
Red Hat
More information about the keycloak-dev
mailing list