[keycloak-dev] Application and server in separate networks
Christian Beikov
christian.beikov at gmail.com
Sat Apr 28 13:16:40 EDT 2018
It seems that switching a client from OIDC to SAML is buggy as I just
tried to create a new client and now I get a different error I don't
understand.
I have configured "http://localhost:8080/*" as valid redirect URL but
get the error "invalid_redirect_uri". I inspected the Base64 encoded
SAML request and noticed that it doesn't contain a redirect URL. The
only URL the Keycloak server could redirect me to is the Referrer which
would match the pattern, but I guess I am simply missing some
configuration in the keycloak-saml.xml?
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 28.04.2018 um 18:33 schrieb Bill Burke:
> Also make sure that your client id matches the one configured for the
> client in the admin console. That might be the problem too.
>
> On Sat, Apr 28, 2018 at 12:32 PM, Bill Burke <bburke at redhat.com> wrote:
>> 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