By default the adapters will require sticky sessions, please refer to http://keycloak.github.io/docs/userguide/keycloak-server/html/application... for more information On 22 January 2016 at 12:48, Christian Beikov <christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>> wrote: Hello, I am running some tests with my application cluster being secured by a single keycloak server instance and I encountered problems with the adapter. My application cluster contains 2 nodes and is load balanced by nginx. For testing purposes, I enabled round robin load balancing which is probably the "cause" for my issues. When I access a secured page, I get redirected to keycloak and everything is fine. When I then login, and keycloak redirects me back to the application, I get to a different application cluster node because of round robin. On that node, apparently the initial information of the client session is not available and I get redirected to keycloak login page again. Then keycloak redirects me back to the application, this time to the original node, and says that access is forbidden. I suppose the web session caches are not in sync but I just used the default cache containers as they are defined in standalone-ha.xml of my Wildlfy 10 CR4. Clustering with jgroups works, as I use other distributed caches too which work just fine. We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4 Regards, Christian _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev

Your issue doesn't have anything to do with the Keycloak server side user sessions, they don't require sticky sessions. Your issue is down to the http session on the adapter side not being replicated by default. For the adapter you've got 3 choices: sticky session, replicated session or stateless. Which is best depends on your application. On 25 January 2016 at 14:05, Christian Beikov <christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>> wrote: I don't have a problem with sticky sessions and I will definitively configure them, but I am curious. What is the reason for the problems with round robin in this test scenario? Are the infinispan caches not replicated fast enough or is there an implementation limitation in the adapters? Regards, Christian Am 25.01.2016 um 08:58 schrieb Stian Thorgersen: > By default the adapters will require sticky sessions, please > refer to > http://keycloak.github.io/docs/userguide/keycloak-server/html/application... > for more information > > On 22 January 2016 at 12:48, Christian Beikov > <christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>> > wrote: > > Hello, > > I am running some tests with my application cluster being > secured by a > single keycloak server instance and I encountered problems > with the adapter. > > My application cluster contains 2 nodes and is load balanced > by nginx. > For testing purposes, I enabled round robin load balancing > which is > probably the "cause" for my issues. > > When I access a secured page, I get redirected to keycloak and > everything is fine. When I then login, and keycloak redirects > me back to > the application, I get to a different application cluster > node because > of round robin. On that node, apparently the initial > information of the > client session is not available and I get redirected to > keycloak login > page again. Then keycloak redirects me back to the > application, this > time to the original node, and says that access is forbidden. > > I suppose the web session caches are not in sync but I just > used the > default cache containers as they are defined in > standalone-ha.xml of my > Wildlfy 10 CR4. Clustering with jgroups works, as I use other > distributed caches too which work just fine. > > We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4 > > Regards, > Christian > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >

HTTP session replicate is not enabled by default. You need to enable it for your application. On 25 January 2016 at 14:39, Christian Beikov <christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>> wrote: The documentation states, that the default token-store is "session" and as I wrote before, I have setup clustering on my Wildfly 10 CR4 like in standalone-ha.xml, so the session should already be replicated. Regards, Christian Am 25.01.2016 um 14:20 schrieb Stian Thorgersen: > Your issue doesn't have anything to do with the Keycloak server > side user sessions, they don't require sticky sessions. > > Your issue is down to the http session on the adapter side not > being replicated by default. For the adapter you've got 3 > choices: sticky session, replicated session or stateless. Which > is best depends on your application. > > > On 25 January 2016 at 14:05, Christian Beikov > <christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>> > wrote: > > I don't have a problem with sticky sessions and I will > definitively configure them, but I am curious. What is the > reason for the problems with round robin in this test > scenario? Are the infinispan caches not replicated fast > enough or is there an implementation limitation in the adapters? > > > Regards, > Christian > > > Am 25.01.2016 um 08:58 schrieb Stian Thorgersen: >> By default the adapters will require sticky sessions, please >> refer to >> http://keycloak.github.io/docs/userguide/keycloak-server/html/application... >> for more information >> >> On 22 January 2016 at 12:48, Christian Beikov >> <christian.beikov(a)gmail.com >> <mailto:christian.beikov@gmail.com>> wrote: >> >> Hello, >> >> I am running some tests with my application cluster >> being secured by a >> single keycloak server instance and I encountered >> problems with the adapter. >> >> My application cluster contains 2 nodes and is load >> balanced by nginx. >> For testing purposes, I enabled round robin load >> balancing which is >> probably the "cause" for my issues. >> >> When I access a secured page, I get redirected to >> keycloak and >> everything is fine. When I then login, and keycloak >> redirects me back to >> the application, I get to a different application >> cluster node because >> of round robin. On that node, apparently the initial >> information of the >> client session is not available and I get redirected to >> keycloak login >> page again. Then keycloak redirects me back to the >> application, this >> time to the original node, and says that access is >> forbidden. >> >> I suppose the web session caches are not in sync but I >> just used the >> default cache containers as they are defined in >> standalone-ha.xml of my >> Wildlfy 10 CR4. Clustering with jgroups works, as I use >> other >> distributed caches too which work just fine. >> >> We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4 >> >> Regards, >> Christian >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > >

Try google for wildfly replicate http sessions On 25 January 2016 at 15:53, Christian Beikov <christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>> wrote: I just wrote that I configured clustering for my application just like in the standlone-ha.xml of my Wildfly 10 CR4. I configured the jgroups subsystem and the distributed caches for web sessions as it is done in standalone-ha.xml of Wildfly. If there is anything else that should be configured, can you please point me to that configuration option? Regards, Christian Am 25.01.2016 um 15:45 schrieb Stian Thorgersen: > HTTP session replicate is not enabled by default. You need to > enable it for your application. > > On 25 January 2016 at 14:39, Christian Beikov > <christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>> > wrote: > > The documentation states, that the default token-store is > "session" and as I wrote before, I have setup clustering on > my Wildfly 10 CR4 like in standalone-ha.xml, so the session > should already be replicated. > > Regards, > Christian > > > Am 25.01.2016 um 14:20 schrieb Stian Thorgersen: >> Your issue doesn't have anything to do with the Keycloak >> server side user sessions, they don't require sticky sessions. >> >> Your issue is down to the http session on the adapter side >> not being replicated by default. For the adapter you've got >> 3 choices: sticky session, replicated session or stateless. >> Which is best depends on your application. >> >> >> On 25 January 2016 at 14:05, Christian Beikov >> <christian.beikov(a)gmail.com >> <mailto:christian.beikov@gmail.com>> wrote: >> >> I don't have a problem with sticky sessions and I will >> definitively configure them, but I am curious. What is >> the reason for the problems with round robin in this >> test scenario? Are the infinispan caches not replicated >> fast enough or is there an implementation limitation in >> the adapters? >> >> >> Regards, >> Christian >> >> >> Am 25.01.2016 um 08:58 schrieb Stian Thorgersen: >>> By default the adapters will require sticky sessions, >>> please refer to >>> http://keycloak.github.io/docs/userguide/keycloak-server/html/application... >>> for more information >>> >>> On 22 January 2016 at 12:48, Christian Beikov >>> <christian.beikov(a)gmail.com >>> <mailto:christian.beikov@gmail.com>> wrote: >>> >>> Hello, >>> >>> I am running some tests with my application cluster >>> being secured by a >>> single keycloak server instance and I encountered >>> problems with the adapter. >>> >>> My application cluster contains 2 nodes and is load >>> balanced by nginx. >>> For testing purposes, I enabled round robin load >>> balancing which is >>> probably the "cause" for my issues. >>> >>> When I access a secured page, I get redirected to >>> keycloak and >>> everything is fine. When I then login, and keycloak >>> redirects me back to >>> the application, I get to a different application >>> cluster node because >>> of round robin. On that node, apparently the >>> initial information of the >>> client session is not available and I get >>> redirected to keycloak login >>> page again. Then keycloak redirects me back to the >>> application, this >>> time to the original node, and says that access is >>> forbidden. >>> >>> I suppose the web session caches are not in sync >>> but I just used the >>> default cache containers as they are defined in >>> standalone-ha.xml of my >>> Wildlfy 10 CR4. Clustering with jgroups works, as I >>> use other >>> distributed caches too which work just fine. >>> >>> We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4 >>> >>> Regards, >>> Christian >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> <mailto:keycloak-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >> >> > >

What do you mean by you're "pretty sure clustering/session replication is configured correctly". Either its working or it isn't. Have you tested a simple application WITHOUT keycloak and with Round Robin to determine if replication is set? Because from what you are describing and what Stian said to you over and over again is that it does not look like HTTP session replication is working for you. Keycloak client adapter stores that you are authenticated within the HttpSession. It is possible that session replication is lagging I think...only if you have async replication turned on. I don't know what the default is in Wildfly 10. Also, a forbidden exception might mean that your web.xml requires a role set for the user for the URL you are accessing and the user does not have that role assigned to them. On 1/25/2016 2:33 PM, Christian Beikov wrote: > I don't want to be rude but you aren't helping me at all so I'd like > to ask someone else from the team about this. I tried to explain > multiple times that I already configured clustering in my Wildfly > server, thus I configured session replication. > Either I don't understand something about session replication or I > require a configuration that you don't mention anywhere. > I copied over the cache container from the standalone-ha > configurations and configured the JGroups Subsystem which is what is > described in the official documentation: > https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide > > I think I gave you enough information about my situation which you > seemed to ignore completely. I would very much appreciate if I got a > clear answer to my question especially since I am not asking for > general configuration help, but for this special case which to me > seems like a problem/limitation that should be explicitly documented. > > I am pretty sure clustering/session replication is configured > correctly since I am using a custom cache container with a similar > configuration like the web cache container which I know replicates > correctly. So here comes my question once again, is it possible that > the replication just lags behind which makes the usage of round robin > completely impossible in the login flow? Or is there some kind of > special configuration I have to do which differs from the standard > cluster configuration as provided by the wildfly distribution? Or is > this maybe even an implementation limiation of the server adapter? > > Regards, > Christian > > Am 25.01.2016 um 19:04 schrieb Stian Thorgersen: >> Try google for wildfly replicate http sessions >> >> On 25 January 2016 at 15:53, Christian Beikov >> <christian.beikov(a)gmail.com&gt; wrote: >> >> I just wrote that I configured clustering for my application >> just like in the standlone-ha.xml of my Wildfly 10 CR4. >> I configured the jgroups subsystem and the distributed caches >> for web sessions as it is done in standalone-ha.xml of Wildfly. >> If there is anything else that should be configured, can you >> please point me to that configuration option? >> >> Regards, >> Christian >> >> >> Am 25.01.2016 um 15:45 schrieb Stian Thorgersen: >>> HTTP session replicate is not enabled by default. You need to >>> enable it for your application. >>> >>> On 25 January 2016 at 14:39, Christian Beikov >>> <christian.beikov(a)gmail.com&gt; wrote: >>> >>> The documentation states, that the default token-store is >>> "session" and as I wrote before, I have setup clustering on >>> my Wildfly 10 CR4 like in standalone-ha.xml, so the session >>> should already be replicated. >>> >>> Regards, >>> Christian >>> >>> >>> Am 25.01.2016 um 14:20 schrieb Stian Thorgersen: >>>> Your issue doesn't have anything to do with the Keycloak >>>> server side user sessions, they don't require sticky >>>> sessions. >>>> >>>> Your issue is down to the http session on the adapter side >>>> not being replicated by default. For the adapter you've >>>> got 3 choices: sticky session, replicated session or >>>> stateless. Which is best depends on your application. >>>> >>>> >>>> On 25 January 2016 at 14:05, Christian Beikov >>>> <christian.beikov(a)gmail.com&gt; wrote: >>>> >>>> I don't have a problem with sticky sessions and I will >>>> definitively configure them, but I am curious. What is >>>> the reason for the problems with round robin in this >>>> test scenario? Are the infinispan caches not >>>> replicated fast enough or is there an implementation >>>> limitation in the adapters? >>>> >>>> >>>> Regards, >>>> Christian >>>> >>>> >>>> Am 25.01.2016 um 08:58 schrieb Stian Thorgersen: >>>>> By default the adapters will require sticky sessions, >>>>> please refer to >>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/application... >>>>> for more information >>>>> >>>>> On 22 January 2016 at 12:48, Christian Beikov >>>>> <christian.beikov(a)gmail.com&gt; wrote: >>>>> >>>>> Hello, >>>>> >>>>> I am running some tests with my application >>>>> cluster being secured by a >>>>> single keycloak server instance and I encountered >>>>> problems with the adapter. >>>>> >>>>> My application cluster contains 2 nodes and is >>>>> load balanced by nginx. >>>>> For testing purposes, I enabled round robin load >>>>> balancing which is >>>>> probably the "cause" for my issues. >>>>> >>>>> When I access a secured page, I get redirected to >>>>> keycloak and >>>>> everything is fine. When I then login, and >>>>> keycloak redirects me back to >>>>> the application, I get to a different application >>>>> cluster node because >>>>> of round robin. On that node, apparently the >>>>> initial information of the >>>>> client session is not available and I get >>>>> redirected to keycloak login >>>>> page again. Then keycloak redirects me back to >>>>> the application, this >>>>> time to the original node, and says that access >>>>> is forbidden. >>>>> >>>>> I suppose the web session caches are not in sync >>>>> but I just used the >>>>> default cache containers as they are defined in >>>>> standalone-ha.xml of my >>>>> Wildlfy 10 CR4. Clustering with jgroups works, as >>>>> I use other >>>>> distributed caches too which work just fine. >>>>> >>>>> We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4 >>>>> >>>>> Regards, >>>>> Christian >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

I don't see the need for this mail. I was actually trying to help you. I doubt you've even looked at what I've suggested though. As Bill points out get your HTTP session replication working first. It has nothing to do with Keycloak. If you want non-sticky sessions and not using the stateless option then you need that working. The reason why I told you to google it is that you do actually have to enable HTTP session replication on a per-war basis. It's not just a container config. The standalone-ha.xml config in WildFly should be fine by default, so you don't need to do anything there. On 25 January 2016 at 20:33, Christian Beikov <christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>> wrote: I don't want to be rude but you aren't helping me at all so I'd like to ask someone else from the team about this. I tried to explain multiple times that I already configured clustering in my Wildfly server, thus I configured session replication. Either I don't understand something about session replication or I require a configuration that you don't mention anywhere. I copied over the cache container from the standalone-ha configurations and configured the JGroups Subsystem which is what is described in the official documentation: https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide I think I gave you enough information about my situation which you seemed to ignore completely. I would very much appreciate if I got a clear answer to my question especially since I am not asking for general configuration help, but for this special case which to me seems like a problem/limitation that should be explicitly documented. I am pretty sure clustering/session replication is configured correctly since I am using a custom cache container with a similar configuration like the web cache container which I know replicates correctly. So here comes my question once again, is it possible that the replication just lags behind which makes the usage of round robin completely impossible in the login flow? Or is there some kind of special configuration I have to do which differs from the standard cluster configuration as provided by the wildfly distribution? Or is this maybe even an implementation limiation of the server adapter? Regards, Christian Am 25.01.2016 um 19:04 schrieb Stian Thorgersen: > Try google for wildfly replicate http sessions > > On 25 January 2016 at 15:53, Christian Beikov > <christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>> > wrote: > > I just wrote that I configured clustering for my application > just like in the standlone-ha.xml of my Wildfly 10 CR4. > I configured the jgroups subsystem and the distributed caches > for web sessions as it is done in standalone-ha.xml of Wildfly. > If there is anything else that should be configured, can you > please point me to that configuration option? > > Regards, > Christian > > > Am 25.01.2016 um 15:45 schrieb Stian Thorgersen: >> HTTP session replicate is not enabled by default. You need >> to enable it for your application. >> >> On 25 January 2016 at 14:39, Christian Beikov >> <christian.beikov(a)gmail.com >> <mailto:christian.beikov@gmail.com>> wrote: >> >> The documentation states, that the default token-store >> is "session" and as I wrote before, I have setup >> clustering on my Wildfly 10 CR4 like in >> standalone-ha.xml, so the session should already be >> replicated. >> >> Regards, >> Christian >> >> >> Am 25.01.2016 um 14:20 schrieb Stian Thorgersen: >>> Your issue doesn't have anything to do with the >>> Keycloak server side user sessions, they don't require >>> sticky sessions. >>> >>> Your issue is down to the http session on the adapter >>> side not being replicated by default. For the adapter >>> you've got 3 choices: sticky session, replicated >>> session or stateless. Which is best depends on your >>> application. >>> >>> >>> On 25 January 2016 at 14:05, Christian Beikov >>> <christian.beikov(a)gmail.com >>> <mailto:christian.beikov@gmail.com>> wrote: >>> >>> I don't have a problem with sticky sessions and I >>> will definitively configure them, but I am curious. >>> What is the reason for the problems with round >>> robin in this test scenario? Are the infinispan >>> caches not replicated fast enough or is there an >>> implementation limitation in the adapters? >>> >>> >>> Regards, >>> Christian >>> >>> >>> Am 25.01.2016 um 08:58 schrieb Stian Thorgersen: >>>> By default the adapters will require sticky >>>> sessions, please refer to >>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/application... >>>> for more information >>>> >>>> On 22 January 2016 at 12:48, Christian Beikov >>>> <christian.beikov(a)gmail.com >>>> <mailto:christian.beikov@gmail.com>> wrote: >>>> >>>> Hello, >>>> >>>> I am running some tests with my application >>>> cluster being secured by a >>>> single keycloak server instance and I >>>> encountered problems with the adapter. >>>> >>>> My application cluster contains 2 nodes and is >>>> load balanced by nginx. >>>> For testing purposes, I enabled round robin >>>> load balancing which is >>>> probably the "cause" for my issues. >>>> >>>> When I access a secured page, I get redirected >>>> to keycloak and >>>> everything is fine. When I then login, and >>>> keycloak redirects me back to >>>> the application, I get to a different >>>> application cluster node because >>>> of round robin. On that node, apparently the >>>> initial information of the >>>> client session is not available and I get >>>> redirected to keycloak login >>>> page again. Then keycloak redirects me back to >>>> the application, this >>>> time to the original node, and says that >>>> access is forbidden. >>>> >>>> I suppose the web session caches are not in >>>> sync but I just used the >>>> default cache containers as they are defined >>>> in standalone-ha.xml of my >>>> Wildlfy 10 CR4. Clustering with jgroups works, >>>> as I use other >>>> distributed caches too which work just fine. >>>> >>>> We are using Keycloak 1.8.0.CR2 on a Wildfly >>>> 10 CR4 >>>> >>>> Regards, >>>> Christian >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> <mailto:keycloak-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>> >>> >> >> > >

Hi, I've put some small note at the first paragraph of "Application clustering" chapter. Just a small note really, as setup of "distributable" in web.xml or configuration of infinispan are app. server specific steps and they are general to HttpSession replication and clustering, it's not Keycloak specific stuff. Marek On 26/01/16 12:55, Christian Beikov wrote: I am really sorry about the last mail, I just felt that my suggestions about a possible problem were ignored, especially since you just suggested to google it. In the end I found out that I was missing the <distributable/> tag in my web.xml to enable session replication properly. So you(Stian) were right after all. I didn't quite get the hint that "need to enable it for your application" actually meant that I had to change the web.xml. Could you maybe put a warning into the documentation? Sorry for the noise again. Regards, Christian Am 26.01.2016 um 08:49 schrieb Stian Thorgersen: I don't see the need for this mail. I was actually trying to help you. I doubt you've even looked at what I've suggested though. As Bill points out get your HTTP session replication working first. It has nothing to do with Keycloak. If you want non-sticky sessions and not using the stateless option then you need that working. The reason why I told you to google it is that you do actually have to enable HTTP session replication on a per-war basis. It's not just a container config. The standalone-ha.xml config in WildFly should be fine by default, so you don't need to do anything there. On 25 January 2016 at 20:33, Christian Beikov <christian.beikov(a)gmail.com&gt; wrote: > > I don't want to be rude but you aren't helping me at all so I'd like to > ask someone else from the team about this. I tried to explain multiple times > that I already configured clustering in my Wildfly server, thus I configured > session replication. > Either I don't understand something about session replication or I require > a configuration that you don't mention anywhere. > I copied over the cache container from the standalone-ha configurations > and configured the JGroups Subsystem which is what is described in the > official documentation: > https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide > > I think I gave you enough information about my situation which you seemed > to ignore completely. I would very much appreciate if I got a clear answer > to my question especially since I am not asking for general configuration > help, but for this special case which to me seems like a problem/limitation > that should be explicitly documented. > > I am pretty sure clustering/session replication is configured correctly > since I am using a custom cache container with a similar configuration like > the web cache container which I know replicates correctly. So here comes my > question once again, is it possible that the replication just lags behind > which makes the usage of round robin completely impossible in the login > flow? Or is there some kind of special configuration I have to do which > differs from the standard cluster configuration as provided by the wildfly > distribution? Or is this maybe even an implementation limiation of the > server adapter? > > Regards, > Christian > > > Am 25.01.2016 um 19:04 schrieb Stian Thorgersen: > > Try google for wildfly replicate http sessions > > On 25 January 2016 at 15:53, Christian Beikov <christian.beikov(a)gmail.com&gt; > wrote: >> >> I just wrote that I configured clustering for my application just like in >> the standlone-ha.xml of my Wildfly 10 CR4. >> I configured the jgroups subsystem and the distributed caches for web >> sessions as it is done in standalone-ha.xml of Wildfly. >> If there is anything else that should be configured, can you please point >> me to that configuration option? >> >> Regards, >> Christian >> >> >> Am 25.01.2016 um 15:45 schrieb Stian Thorgersen: >> >> HTTP session replicate is not enabled by default. You need to enable it >> for your application. >> >> On 25 January 2016 at 14:39, Christian Beikov >> <christian.beikov(a)gmail.com&gt; wrote: >>> >>> The documentation states, that the default token-store is "session" and >>> as I wrote before, I have setup clustering on my Wildfly 10 CR4 like in >>> standalone-ha.xml, so the session should already be replicated. >>> >>> Regards, >>> Christian >>> >>> >>> Am 25.01.2016 um 14:20 schrieb Stian Thorgersen: >>> >>> Your issue doesn't have anything to do with the Keycloak server side >>> user sessions, they don't require sticky sessions. >>> >>> Your issue is down to the http session on the adapter side not being >>> replicated by default. For the adapter you've got 3 choices: sticky session, >>> replicated session or stateless. Which is best depends on your application. >>> >>> >>> On 25 January 2016 at 14:05, Christian Beikov >>> <christian.beikov(a)gmail.com&gt; wrote: >>>> >>>> I don't have a problem with sticky sessions and I will definitively >>>> configure them, but I am curious. What is the reason for the problems with >>>> round robin in this test scenario? Are the infinispan caches not replicated >>>> fast enough or is there an implementation limitation in the adapters? >>>> >>>> >>>> Regards, >>>> Christian >>>> >>>> >>>> Am 25.01.2016 um 08:58 schrieb Stian Thorgersen: >>>> >>>> By default the adapters will require sticky sessions, please refer to >>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/application... >>>> for more information >>>> >>>> On 22 January 2016 at 12:48, Christian Beikov >>>> <christian.beikov(a)gmail.com&gt; wrote: >>>>> >>>>> Hello, >>>>> >>>>> I am running some tests with my application cluster being secured by a >>>>> single keycloak server instance and I encountered problems with the >>>>> adapter. >>>>> >>>>> My application cluster contains 2 nodes and is load balanced by nginx. >>>>> For testing purposes, I enabled round robin load balancing which is >>>>> probably the "cause" for my issues. >>>>> >>>>> When I access a secured page, I get redirected to keycloak and >>>>> everything is fine. When I then login, and keycloak redirects me back >>>>> to >>>>> the application, I get to a different application cluster node because >>>>> of round robin. On that node, apparently the initial information of >>>>> the >>>>> client session is not available and I get redirected to keycloak login >>>>> page again. Then keycloak redirects me back to the application, this >>>>> time to the original node, and says that access is forbidden. >>>>> >>>>> I suppose the web session caches are not in sync but I just used the >>>>> default cache containers as they are defined in standalone-ha.xml of >>>>> my >>>>> Wildlfy 10 CR4. Clustering with jgroups works, as I use other >>>>> distributed caches too which work just fine. >>>>> >>>>> We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4 >>>>> >>>>> Regards, >>>>> Christian >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> >>> >>> >> >> > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Yeah. The question is where is the exactly is the "border" to provide some hints, but not duplicate the info, which is not directly related to Keycloak. For application clustering, it's tricky as we support bunch of servers for adapter clustering. And each of them has some differences for cluster setup (and different infinispan version). So I've just added the note about <distributable /> in web.xml and the obligatory sentence "For more details look at your app server documentation" :-) Hope this will be sufficient for most of the cases. Marek On 26/01/16 18:10, Marko Strukelj wrote: > Maybe we should assume that people forget that stuff, and some don't > know it in the first place, and simply try to give all the info > necessary even for novice java developer to be successful setting it > all up. > > On Tue, Jan 26, 2016 at 5:36 PM, Marek Posolda <mposolda(a)redhat.com&gt; > wrote: > >> Hi, >> >> I've put some small note at the first paragraph of "Application >> clustering" >> chapter. Just a small note really, as setup of "distributable" in >> web.xml or >> configuration of infinispan are app. server specific steps and they are >> general to HttpSession replication and clustering, it's not Keycloak >> specific stuff. >> >> Marek >> >> >> On 26/01/16 12:55, Christian Beikov wrote: >> >> I am really sorry about the last mail, I just felt that my suggestions >> about >> a possible problem were ignored, especially since you just suggested to >> google it. >> >> In the end I found out that I was missing the <distributable/> tag in my >> web.xml to enable session replication properly. So you(Stian) were right >> after all. I didn't quite get the hint that "need to enable it for your >> application" actually meant that I had to change the web.xml. >> >> Could you maybe put a warning into the documentation? >> >> Sorry for the noise again. >> >> Regards, >> Christian >> >> Am 26.01.2016 um 08:49 schrieb Stian Thorgersen: >> >> I don't see the need for this mail. I was actually trying to help you. I >> doubt you've even looked at what I've suggested though. >> >> As Bill points out get your HTTP session replication working first. It >> has >> nothing to do with Keycloak. If you want non-sticky sessions and not >> using >> the stateless option then you need that working. The reason why I told >> you >> to google it is that you do actually have to enable HTTP session >> replication >> on a per-war basis. It's not just a container config. The >> standalone-ha.xml >> config in WildFly should be fine by default, so you don't need to do >> anything there. >> >> On 25 January 2016 at 20:33, Christian Beikov < >> christian.beikov(a)gmail.com&gt; >> wrote: >> >>> I don't want to be rude but you aren't helping me at all so I'd like to >>> ask someone else from the team about this. I tried to explain multiple >>> times >>> that I already configured clustering in my Wildfly server, thus I >>> configured >>> session replication. >>> Either I don't understand something about session replication or I >>> require >>> a configuration that you don't mention anywhere. >>> I copied over the cache container from the standalone-ha configurations >>> and configured the JGroups Subsystem which is what is described in the >>> official documentation: >>> https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide >>> >>> I think I gave you enough information about my situation which you >>> seemed >>> to ignore completely. I would very much appreciate if I got a clear >>> answer >>> to my question especially since I am not asking for general >>> configuration >>> help, but for this special case which to me seems like a >>> problem/limitation >>> that should be explicitly documented. >>> >>> I am pretty sure clustering/session replication is configured correctly >>> since I am using a custom cache container with a similar configuration >>> like >>> the web cache container which I know replicates correctly. So here >>> comes my >>> question once again, is it possible that the replication just lags >>> behind >>> which makes the usage of round robin completely impossible in the login >>> flow? Or is there some kind of special configuration I have to do which >>> differs from the standard cluster configuration as provided by the >>> wildfly >>> distribution? Or is this maybe even an implementation limiation of the >>> server adapter? >>> >>> Regards, >>> Christian >>> >>> >>> Am 25.01.2016 um 19:04 schrieb Stian Thorgersen: >>> >>> Try google for wildfly replicate http sessions >>> >>> On 25 January 2016 at 15:53, Christian Beikov < >>> christian.beikov(a)gmail.com&gt; >>> wrote: >>> >>>> I just wrote that I configured clustering for my application just like >>>> in >>>> the standlone-ha.xml of my Wildfly 10 CR4. >>>> I configured the jgroups subsystem and the distributed caches for web >>>> sessions as it is done in standalone-ha.xml of Wildfly. >>>> If there is anything else that should be configured, can you please >>>> point >>>> me to that configuration option? >>>> >>>> Regards, >>>> Christian >>>> >>>> >>>> Am 25.01.2016 um 15:45 schrieb Stian Thorgersen: >>>> >>>> HTTP session replicate is not enabled by default. You need to enable it >>>> for your application. >>>> >>>> On 25 January 2016 at 14:39, Christian Beikov >>>> <christian.beikov(a)gmail.com&gt; wrote: >>>> >>>>> The documentation states, that the default token-store is "session" >>>>> and >>>>> as I wrote before, I have setup clustering on my Wildfly 10 CR4 like >>>>> in >>>>> standalone-ha.xml, so the session should already be replicated. >>>>> >>>>> Regards, >>>>> Christian >>>>> >>>>> >>>>> Am 25.01.2016 um 14:20 schrieb Stian Thorgersen: >>>>> >>>>> Your issue doesn't have anything to do with the Keycloak server side >>>>> user sessions, they don't require sticky sessions. >>>>> >>>>> Your issue is down to the http session on the adapter side not being >>>>> replicated by default. For the adapter you've got 3 choices: sticky >>>>> session, >>>>> replicated session or stateless. Which is best depends on your >>>>> application. >>>>> >>>>> >>>>> On 25 January 2016 at 14:05, Christian Beikov >>>>> <christian.beikov(a)gmail.com&gt; wrote: >>>>> >>>>>> I don't have a problem with sticky sessions and I will definitively >>>>>> configure them, but I am curious. What is the reason for the >>>>>> problems with >>>>>> round robin in this test scenario? Are the infinispan caches not >>>>>> replicated >>>>>> fast enough or is there an implementation limitation in the adapters? >>>>>> >>>>>> >>>>>> Regards, >>>>>> Christian >>>>>> >>>>>> >>>>>> Am 25.01.2016 um 08:58 schrieb Stian Thorgersen: >>>>>> >>>>>> By default the adapters will require sticky sessions, please refer to >>>>>> >>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/application... >>>>>> for more information >>>>>> >>>>>> On 22 January 2016 at 12:48, Christian Beikov >>>>>> <christian.beikov(a)gmail.com&gt; wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am running some tests with my application cluster being secured >>>>>>> by a >>>>>>> single keycloak server instance and I encountered problems with the >>>>>>> adapter. >>>>>>> >>>>>>> My application cluster contains 2 nodes and is load balanced by >>>>>>> nginx. >>>>>>> For testing purposes, I enabled round robin load balancing which is >>>>>>> probably the "cause" for my issues. >>>>>>> >>>>>>> When I access a secured page, I get redirected to keycloak and >>>>>>> everything is fine. When I then login, and keycloak redirects me >>>>>>> back >>>>>>> to >>>>>>> the application, I get to a different application cluster node >>>>>>> because >>>>>>> of round robin. On that node, apparently the initial information of >>>>>>> the >>>>>>> client session is not available and I get redirected to keycloak >>>>>>> login >>>>>>> page again. Then keycloak redirects me back to the application, this >>>>>>> time to the original node, and says that access is forbidden. >>>>>>> >>>>>>> I suppose the web session caches are not in sync but I just used the >>>>>>> default cache containers as they are defined in standalone-ha.xml of >>>>>>> my >>>>>>> Wildlfy 10 CR4. Clustering with jgroups works, as I use other >>>>>>> distributed caches too which work just fine. >>>>>>> >>>>>>> We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4 >>>>>>> >>>>>>> Regards, >>>>>>> Christian >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >