[keycloak-dev] Application and server in separate networks
Christian Beikov
christian.beikov at gmail.com
Thu Apr 26 09:59:31 EDT 2018
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
>>>>
>>>>
>>
>>
>
More information about the keycloak-dev
mailing list