[keycloak-dev] Application and server in separate networks
Bill Burke
bburke at redhat.com
Sat Apr 28 12:32:14 EDT 2018
Enable standard flow for the client. Its a switch in admin console
client config.
On Sat, Apr 28, 2018 at 11:11 AM, Christian Beikov
<christian.beikov at gmail.com> wrote:
> I can't get SAML to work. Everytime I try to access a protected page, I
> get the error "Client is not allowed to initiate browser login with
> given response_type. Standard flow is disabled for the client".
>
> In the logs I see "type=LOGIN_ERROR, realmId=LOCAL, clientId=null,
> userId=null, ipAddress=10.0.0.1, error=not_allowed"
>
> Is there anything I can do to further debug this? I'm using 3.3.0.Final
> and configured SAML via keycloak-saml.xml having roughly the following
> content
>
> <?xml version="1.0" encoding="UTF-8"?>
> <keycloak-saml-adapter xmlns="urn:keycloak:saml:adapter"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:keycloak:saml:adapter
> http://www.keycloak.org/schema/keycloak_saml_adapter_1_7.xsd">
> <SP entityID="myapp"
> sslPolicy="EXTERNAL"
> nameIDPolicyFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> logoutPage="/logout"
> forceAuthentication="false"
> isPassive="false"
> turnOffChangeSessionIdOnLogin="false">
> <IDP entityID="idp"
> signaturesRequired="false">
> <SingleSignOnService requestBinding="POST"
> bindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
> />
>
> <SingleLogoutService
> requestBinding="POST"
> responseBinding="POST"
> postBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
> redirectBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml"
> />
> </IDP>
> </SP>
> </keycloak-saml-adapter>
>
> Am I missing something or is having a SAML endpoint on Keycloak along
> with a SAML client not a supported scenario configuration?
>
> Mit freundlichen Grüßen,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 26.04.2018 um 16:50 schrieb Bill Burke:
>> 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
>>
>>
>
> _______________________________________________
> 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