[keycloak-dev] Application and server in separate networks
Marek Posolda
mposolda at redhat.com
Thu Apr 26 09:06:21 EDT 2018
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