[keycloak-user] Behind a reverse proxy using context path

[Andy Yar]

Oh, I am sorry. I have overlooked the notice about the need of changing the
root context manually in docs. The deployed Keycloak seems to be working
smoothly now.

I shall create issues for both problems I encountered.

Thanks a lot for your support.

On Wed, Jan 13, 2016 at 7:24 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> The clients are created with the initial context path. If you change the
> context path you currently have to manually go to the admin console and
> change it first. Both issues you've encountered are not ideal and you can
> create jira issues for those.
>
> On 13 January 2016 at 17:18, Andy Yar <andyyar66 at gmail.com> wrote:
>
>> OK, I forgot to mention I used to have the Keycloak set to run on the
>> root context. So I removed the root context mapping set the
>> "standalone.xml" to "sso" and customized the nginx settings accordingly.
>>
>> Now I am able to enter the admin/, although redirecting to the login form
>> for the master realm ends with an error - "Invalid parameter:
>> redirect_uri". Apparently the context path "sso/" is ignored by a security
>> pattern.
>>
>> Log dump:
>> 2016-01-13 17:06:21,858 DEBUG
>> [org.keycloak.protocol.oidc.utils.RedirectUtils] (default task-15)
>> replacing relative valid redirect with:
>> https://domain.foo/auth/admin/master/console/*
>> 2016-01-13 17:06:21,876 WARN  [org.keycloak.events] (default task-15)
>> type=LOGIN_ERROR, realmId=master, clientId=security-admin-console,
>> userId=null, ipAddress=x.x.x.x, error=invalid_redirect_uri,
>> response_type=code, redirect_uri=
>> https://domain.foo/sso/admin/master/console/, response_mode=fragment
>>
>> Thanks
>>
>>
>> On Wed, Jan 13, 2016 at 2:44 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Looks like it may be a bug caused by context-path on the server being
>>> different than context-path on the reverse proxy.
>>>
>>> Try setting web-context for urn:jboss:domain:keycloak-server:1.1 in
>>> standalone.xml to "sso". If that works please create a bug.
>>>
>>> On 13 January 2016 at 14:27, Andy Yar <andyyar66 at gmail.com> wrote:
>>>
>>>> Hello,
>>>> I'm stuck with Keycloak 1.7.0 Final on WildFly 9 behind a reverse proxy
>>>> (nginx). The WildFly is configured for proxying according to the Keycloak
>>>> guide and the proxy sends the needed custom HTTP headers.
>>>>
>>>> I have a public SSL secured domain and nginx proxying requests to
>>>> internal WildFly server. I would like to use URL:
>>>> https://domain.foo/sso/ to access the Keycloak (internal WildFly). I
>>>> guess the context path (sso/) is important here.
>>>>
>>>> Accessing the address I can reach the Keycloak default welcome page.
>>>> However, a GET https://domain.foo/sso/admin results in 302 to Location:
>>>> https://domain.foo/admin/master/console/. Obviously this redirect
>>>> fails because its Location misses the needed context path (sso/). Adding
>>>> the context path to a request manually results in a 200 but following
>>>> resources fail to download because of the missing context path part of URL.
>>>>
>>>> Is my configuration wrong? Is there a way how the original base URL can
>>>> be set? Is it even possible to have it behind a reverse proxy not running
>>>> at root context? Is the origin detection broken?
>>>>
>>>> Thanks in advance
>>>> Andy
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160114/0ebe43aa/attachment-0001.html