[keycloak-dev] Application and server in separate networks

Christian Beikov christian.beikov at gmail.com
Sat Apr 28 12:40:53 EDT 2018


Thanks for the fast answer. There is no configuration for a flow in the 
administration for the client. The client id matches the entityID 
attribute. I actually used the generated configuration. Here is the list 
of configurable attributes for the client

  * Client ID
  * Name
  * Description
  * Enabled
  * Consent Required
  * Client Protocol
  * Client Template
  * Include AuthnStatement
  * Include OneTimeUse Condition
  * Sign Documents
  * Sign Assertions
  * Encrypt Assertions
  * Client Signature Required
  * Force POST Binding
  * Front Channel Logout
  * Force Name ID Format
  * Name ID Format
  * Root URL
  * Valid Redirect URIs
  * Base URL
  * Master SAML Processing URL
  * IDP Initiated SSO URL Name
  * IDP Initiated SSO Relay State
  * Assertion Consumer Service POST Binding URL
  * Assertion Consumer Service Redirect Binding URL
  * Logout Service POST Binding URL
  * Logout Service Redirect Binding URL


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