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(a)redhat.com
<mailto:velias@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(a)redhat.com
> <mailto:velias@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 list
>> keycloak-dev(a)lists.jboss.org
>> <mailto:keycloak-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@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