Hi,
If you enable the OAuth server support with multiple nodes, you must enable
the session replication via the following property:
*cas.authn.oauth.replicateSessions=true*.
In that case, the pac4j session will be stored via the
*DistributedJEESessionStore* component (which uses a cookie).
Thank
Hi all,
I confirm all work fine without replication session, with CAS protocol. The
replication is needed only by OIDC and more specifically by Oauth2
protocol.
Hal, i can just tell you, the package Pac4j store some information in
session. In my cas the Urls in cause (oidc/callbackAutorize and
oid
I am running a fairly recent 6.2 snapshot build. I have only seen a problem
with OIDC when using an active/active cluster rather than an active/standby
cluster. CAS and SAML protocols didn't have a problem. I don't have session
clustering configured but I may work on adding support for a Tomcat
Jerome, did you find out what specifically CAS is storing in the http
session for OIDC that needs to be replicated? I think I have seen the same
issue in my deployment where OIDC wasn't working in an active/active CAS
cluster but I haven't had a chance to track down the cause.
- Hal
On Monda
Jérôme,
If you are using tomcat, see
https://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html
Ray
On Mon, 2020-02-03 at 09:18 -0800, Jérôme Steve wrote:
Hi Ray,
After some investigation, I found the problem.
I Have to replicate the httpSession for Hight Avaibility (Multi node) when my
cas
Hi Ray,
After some investigation, I found the problem.
I Have to replicate the httpSession for Hight Avaibility (Multi node) when
my cas server act like an OpenID Connect Provider ...
If you know how to do it,you are my guess :) (I have my own view on that
but i'm curious to have an other view
Jérôme,
I have not used memcached so I do not know its workings. A problem we had with
ehcache (replicated cache) was that replication was too slow. The request for
validation came in before the ticket was replicated to the other servers, so it
was never found. We switched to hazelcast (not rep
Hi Ray,
Thanks for your reply (and sorry for my latency ...)
So I'm stored Ticket in a memcahced ticket registery (All work fine).
My log come from TWO different node (Exactly 2 container in a same stack
behind a load balancer).
I understand what you're saying about the round robin load blancer
Jérôme,
How are tickets being stored?
All CAS nodes need access to the tickets. In multi node architecture, request 1
goes to node 1, request 2 goes to node 2, etc (round robin load balancer). At
the load balancer, log in is request 1, but ticket validation is request 2
(comes from client appl
Hi ray,
Thanks for your reply. so you think the problem come from my OIDC client
app ? or maybe from my load balancer and/or my proxy ?
Becaus if i update cas servers configurtion to
cas.ticket.st.numberOfUses=10
The ST is validate 10 times and after is FAILED (of course is the normal flow)
Jérôme,
The failure on the node 2 is because the client application submitted the ST a
second time (in your case 5s later).
The ST was validated on node 1.
I have not used OIDC. There may be some further communication that happens
after the ST is validated (this happens with proxy tickets). Che
Hello,
Before all thanks for your works.
We are using CAS overlay in Multi node architecture (Docker container) behind a
load balancer and a proxy with a memcahced service registery.
All work fine but when we used it like an OIDC provider, i'm getting a
Validation Ticket Failed after called
12 matches
Mail list logo
