[keycloak-user] Logouts / how to disable keycloak "user session" cache?

[Stian Thorgersen]

We had something similar, but we decided to drop persistence of session
data from the DB due to performance issues and that we didn't have the
resources to maintain two implementations for session storage.

On 7 April 2016 at 13:25, Christian Schwarz <christian at datek.no> wrote:

> On 07 Apr 2016, at 13:03, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>
>
>
> On 7 April 2016 at 12:56, Christian Schwarz <christian at datek.no> wrote:
>
>> Ok, thank you Stian for the fast reply!
>>
>> I will look into using jgroups S3_PING module that supports AWS, and that
>> I think will work with docker-cloud as well since it accepts system
>> properties where I can set the current IP address.
>>
>> Just plain old clustering with a database as shared data store and sticky
>> sessions to a keycloak instance would be a nice default clustering option
>> in the future (but I’m sure you have enough on your plate already :)
>>
>
> We're planning sticky session support in 2.x. The problem is that you need
> to make sure browser + all adapter requests go to the same node. So it's
> not quite as simple as just setting a cookie. See
> https://issues.jboss.org/browse/KEYCLOAK-2352
>
>
> When I implemented a custom OpenID Connect Authorization Server a couple
> of years ago (when the spec was fresh), we accepted that a single database
> request per HTTP request was OK performance wise. Then you can re-read the
> most volatile data on each HTTP request (e.g. logout status) and then use a
> local cache for the rest. If you got load-balanced to another node (e.g.
> during deployment or failover) then the other node would have to fetch more
> data from the database (we did not use JSESSION, we used a custom session
> mechanism with a custom cookie that was an ID to a login session stored in
> the database. Then you had transparent failover and instant logout from all
> authorization server nodes.
>
>
>
>>
>> Keep up the good work!
>>
>> Christian
>>
>> On 07 Apr 2016, at 12:40, Stian Thorgersen <sthorger at redhat.com> wrote:
>>
>> It is not currently possible to run multiple nodes without clustering.
>> However, it's possible to configure JGroups to work on AWS. I can't
>> remember the configuration required though, but if you search the user
>> mailing list you'll find instructions or google for JGroups and AWS.
>>
>> On 7 April 2016 at 10:22, Christian Schwarz <christian at datek.no> wrote:
>>
>>> Hi!
>>>
>>> I'm trying to setup a keycloak cluster on AWS, which does not support
>>> UDP multicast. IP addresses of the nodes are also not known in advance (I'm
>>> using docker-cloud), so Infinispan/JGroups ("keycloak-ha-posgres" docker
>>> image) for user session replication will not work (seems that it requires
>>> either UDP multicast or IP addresses known in advance).
>>>
>>> The main problem I have is that logout is not working propertly. I only
>>> get logged out from one of the two keycloak nodes.
>>>
>>> I have tried to disable the user cache (by setting
>>> userCache.default.enabled = false) and to disable infinispan (by using
>>> “keycloak-postgres” docker image), but to no avail. The “other” keycloak
>>> node still thinks that the user is logged in, it’s not refreshing the user
>>> session from the database even if user cache and infinispan cluster cache
>>> is disbled.
>>>
>>> => Is there a possibility of using the database as a synchronization
>>> point between keycloak nodes? (i.e. each node always checks logout status
>>> in the database)
>>> Or is there another way of getting a keycloak cluster up and running on
>>> AWS when IP addresses are not known in advance?
>>>
>>> I hope there is a way… :)
>>>
>>> Kind regards,
>>> Christian
>>>
>>> _______________________________________________
>>> 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/20160407/feae8b50/attachment-0001.html