[keycloak-dev] Keycload Admin page Failed Executing GET /admin/serverinfo

Stian Thorgersen sthorger at redhat.com
Fri Feb 26 09:05:48 EST 2016


Unless we can use a header or cookie on the server-side to do sticky
sessions there as well. We could extend adapters to include it.

On 26 February 2016 at 14:56, Vlastimil Elias <velias at redhat.com> wrote:

> Sure thing, sticky session can cover requests from browsers only, KC state
> replication is always necessary to cover requests from server-side
> applications.
>
> Vl.
>
>
> On 26.2.2016 13:27, Stian Thorgersen wrote:
>
>
>
> On 26 February 2016 at 10:24, Vlastimil Elias < <velias at redhat.com>
> velias at redhat.com> wrote:
>
>> Hi,
>>
>> On 26.2.2016 09:33, Stian Thorgersen wrote:
>>
>> This should work just fine without sticky sessions.
>>
>>
>> Sure, but there may be latencies or so between nodes which may bring
>> problems, and it is always hard to troubleshoot this kind of problems.
>> Sticky session generally lowers probability of this kind of operational
>> problems, this is why I like them and use them ;-) But correctly configured
>> replication is necessary even in case of sticky sessions to have failover.
>>
>
> That's why we use sync, not async.
>
> But, I agree sticky sessions would be nice.
>
>
>>
>>
>> We also don't support sticky sessions at the moment as there's no cookie
>> to stick on. We're going to look into supporting sticky sessions soon.
>>
>>
>> Some loadbalancers are able to make sticky session on his owns, even if
>> application itself do not provide any cookie. We use this on RHD website,
>> we have F5 loadbalancer which handles sticky sessions for us (I think it
>> creates his own cookie), and is able correctly failover when keycloak node
>> dies.
>>
>
> What makes it non-trivial is that there are two different things using the
> same session and user. The users browser (for login redirects and also
> html5 apps) and also server-side applications. These will have different IP
> addresses. So simply setting up sticky sessions based on the source won't
> work.
>
>
>>
>> So don't tell your users that Keycloak doesn't support sticky sessions at
>> all, it works with sticky sessions correctly if provided by loadbalancer by
>> some way not relying on cookie provided by Keycloak itself. ;-)
>>
>
>>
>> Vlastimil
>>
>>
>>
>> On 26 February 2016 at 09:29, Vlastimil Elias < <velias at redhat.com>
>> velias at redhat.com> wrote:
>>
>>> What about configuring Loadbalancer to use sticky sessions?
>>>
>>> Vlastimil
>>>
>>> On 25.2.2016 16:10, Peter Krivansky wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> I have a Keycloak cluster with two servers, in front of each Keaycloak
>>> is Apache running.
>>>
>>>
>>>
>>> LB
>>>
>>> /\
>>>
>>>   Host A    Host B
>>>
>>>
>>>
>>> Now, Host-A and Host-B are in different subnets, due to this design we
>>> are running jGroups via TCP.
>>>
>>> Now everything is working fine, except for the Keycloak Admin console,
>>> once a user tries to log in, they get for a milisecond in to the Admin
>>> console, but then they get redirected to the login page immediately.
>>>
>>> When I disable Host-A or Host-B on the Loadbalancer, (new sessions will
>>> land only on Hst-A or Host-B) the Login to Keycloak Admin Console will work
>>> normally.
>>>
>>> During the immediate redirection there is only this one WARNING in the
>>> Server.log:
>>>
>>>
>>>
>>> 15:41:42,886 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default
>>> task-10) Failed executing GET /admin/serverinfo:
>>> org.jboss.resteasy.spi.UnauthorizedException: Bearer
>>>
>>>          at
>>> org.keycloak.services.resources.admin.AdminRoot.authenticateRealmAdminRequest(AdminRoot.java:156)
>>>
>>>          at
>>> org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:209)
>>>
>>>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>
>>>          at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>
>>>          at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>
>>>          at java.lang.reflect.Method.invoke(Method.java:498)
>>>
>>>          at
>>> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:81)
>>>
>>>          at
>>> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:60)
>>>
>>>          at
>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:102)
>>>
>>>          at
>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>>>
>>>          at
>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
>>>
>>>          at
>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
>>>
>>>          at
>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>>>
>>>          at
>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>>>
>>>          at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>>
>>>          at
>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
>>>
>>>          at
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
>>>
>>>          at
>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>>>
>>>          at
>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>>
>>>          at
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>>>
>>>          at
>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>>>
>>>          at
>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>>
>>>          at
>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>>
>>>          at
>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>>
>>>          at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>          at
>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>>
>>>          at
>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>>
>>>          at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>          at
>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>>
>>>          at
>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>>
>>>          at
>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>>>
>>>          at
>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
>>>
>>>          at
>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>>
>>>          at
>>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>>>
>>>          at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>          at
>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>>
>>>          at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>          at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>          at
>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
>>>
>>>          at
>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
>>>
>>>          at
>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
>>>
>>>          at
>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
>>>
>>>          at
>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
>>>
>>>          at
>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>>>
>>>          at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>>
>>>          at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>>
>>>          at java.lang.Thread.run(Thread.java:745)
>>>
>>>
>>>
>>> I attached my domain.xml
>>>
>>> Have I missed something, or what did I wrong?
>>>
>>>
>>>
>>> With Kind regards Peter
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> --
>>> Vlastimil Elias
>>> Principal Software Engineer
>>> Developer Portal Engineering Team
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer
>> Developer Portal Engineering Team
>>
>>
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160226/049bfe8b/attachment-0001.html 


More information about the keycloak-dev mailing list