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