It looks there might be issue with
session replication in your environment.
When you bootstrap your domain with cluster nodes, are you seeing message in the log similar to:
INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,shared=udp)
ISPN000094: Received new cluster view: [node1/web|1] (2) [node1/web, node2/web]
Does it help if you try to switch to
"token-store": "cookie"
in the adapter configuration of your application?
Thanks,
Marek
On 5.2.2015 06:45, Bappaditya Gorai (bgorai) wrote:
Please
find my response inline for your queries.
Hi,
I am not sure about the details of your environment. You
mentioned that you're not interested in clustering of
keycloak server.
So am I understand correctly that you
have just 1 node as keycloak server and 2 nodes with your
application deployed?
[[Bappaditya]]
Yes, only one instance of keycloak Server (Running in
standalone mode). My Application is deployed in 2 nodes
(cluster) and running in domain mode.
Are you using "distributable" tag in
web.xml of your app on both nodes to ensure session
replication?
[[Bappaditya]]
Yes, Application is using
“distributable”
tag in web.xml.
Are you using loadbalancer?
[[Bappaditya]]
We
are using mod_cluster & httpd. Sticky sessions
disabled.
Marek
On 4.2.2015 13:37, Bappaditya Gorai (bgorai) wrote:
Thanks
for the detailed description. Still, It seems in case of
Clustered Resource environment (distributable without
Sticky sessions) we are relying on session replication
to happen immediately between CODE_TO_TOKEN and Resource
Hit(302), which may or may not happen. We are now facing
the same issue where After CODE_TO_TOKEN client is
redirected to Login URL again.
Are
we addressing this scenario with 1.1.0 Final ?
-----Original
Message-----
From: Marek Posolda [mailto:mposolda@redhat.com]
Sent: Monday, February 02, 2015 2:00 PM
To: Bappaditya Gorai (bgorai); Stian Thorgersen
Cc: keycloak-dev@lists.jboss.org
Subject: Re: [keycloak-dev] Facing Issue with Resource
Server in Clustered Environment
it's
not stateless by default. Data about keycloak
authenticated principal are saved in HTTP session by
default and can be replicated across cluster nodes
(replication works as long as your application is marked
as "distributable" in web.xml).
However
we support stateless adapter, which won't save anything
in HTTP Session and won't create HTTP session and
JSESSIONID cookie at all (unless you're calling
httpRequest.getSession() in your own application).
Instead all the data are saved in cookie.
On
30.1.2015 11:26, Bappaditya Gorai (bgorai) wrote:
>
Thanks for clarifying. So, I think adapter has become
stateless in 1.1.0.Final. Is my understanding correct?
>
-----Original Message-----
>
Sent: Friday, January 30, 2015 1:18 PM
>
To: Bappaditya Gorai (bgorai)
>
Subject: Re: [keycloak-dev] Facing Issue with Resource
Server in
>
----- Original Message -----
>>
Sent: Friday, 30 January, 2015 8:38:49 AM
>>
Subject: RE: [keycloak-dev] Facing Issue with Resource
Server in Clustered Environment
>>
We are not talking about clustering for Keycloak server.
The setup is
>>
for Resource Server (Keycloak Adapter) in clustered
environment.
>>
-----Original Message-----
>>
Sent: Friday, January 30, 2015 12:57 PM
>>
To: Bappaditya Gorai (bgorai)
>>
Subject: Re: [keycloak-dev] Facing Issue with Resource
Server in
>>
1.0.4.Final had very limited support for clustering,
please upgrade
>>
to 1.1.0.Final and refer to chapter 24 and 25 in the
documentation
>>
----- Original Message -----
>>>
Sent: Friday, 30 January, 2015 8:22:26 AM
>>>
Subject: [keycloak-dev] Facing Issue with Resource
Server in Clustered
>>>
Please find the details on setup and observation below.
Please
>>>
provide your suggestion on how to overcome this issue.
We are using
>>>
Keycloak 1.0.4.Final (Adapter & Server).
>>>
1. We have brought up Jboss cluster ( Using mod_cluster,
httpd )
>>>
2 nodes in domain mode and enabled session replication
between these nodes.
>>>
2. Our Recourse server is deployed in this clustered
environment
>>>
with distributable and Sticky session Off.
>>>
During the Authorization/Authentication process ,when
Initial
>>>
Access) lands on master and next redirection (post Code
To token)
>>>
falls on slave Adapter is treating it as a new session
and
>>>
redirecting to login URL again. So we ended up with
circular redirection error.
>>>
After further investigation seems like session
replication delay is
>>>
causing adapter to behave this way. As the redirection
call happens
>>>
very quickly and this results in circular redirection
error.
>>>
NOTE: Sticky Session in mod_cluster environment solves
the issue but
>>>
it does not provide true load balancing. Therefore we
are not
>>>
considering Stick session option.
>>>
_______________________________________________
>>>
keycloak-dev mailing list
>
_______________________________________________
>
keycloak-dev mailing list