Client filter configuration may not be proper solution as a
non-responsive machine may break the loop or flooding of logout request.
Lekhnath
Roelof Jan Koekoek wrote:
Thanks, that's probably worth looking at. Having a RegisteredService
distinguish between a public service url and an accompanying clients
server validation url would have been nice. I was wondering if I could
implement this easily. Given it's architectural impact, as stated
below, I'll have to give up on that. Is there any info on this
behavior of the client filter and it's configuration?
RJ
Op 9 jan 2009, om 17:32 heeft Nathan Kopp het volgende geschreven:
Another alternative approach (which is implemented by the Java CAS
client filter, IIRC) is for the node the receives the logout
notification from the CAS server to rebroadcast it to the other
nodes in
the cluster. This avoids the need for session replication, and also
means that the CAS server doesn't need to know about the individual
nodes in the cluster.
Nathan Kopp
Applications Strategist
Information Technology Group
Campus Crusade for Christ, Int'l
407-826-2939 Office | 407-484-8485 Mobile | 407-826-2968 Fax
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Marvin S.
Addison
Sent: Friday, January 09, 2009 9:41 AM
To: Mailing list for CAS developers
Subject: Re: [cas-dev] Single sign-out in a loadbalancing environment
Can't we just use registered service improvement to register all the
machine in the load balancer?
No. The CAS server records the services visited by a user during a
CAS
session according to the initial entry point into the application that
requests a CAS service ticket. It is these URLs exactly that are
replayed at single sign-out time to end CAS client sessions. (This
behavior could, of course, be changed, but I imagine it would be a
signficant architectural change for the implementation of registered
services and/or single sign-out.)
Presumably the DNS entries for the cluster are different from those of
the nodes, so registering the nodes would be of no help since the user
would only ever visit the service by the cluster name. CAS would then
call back to the cluster address directly, and would be routed to a
cluster node that could be different from that used by the end user.
Again, the only obvious solution here is replicated session state
where
killing the session on one node is equivalent to killing them all.
M
_______________________________________________
cas-dev mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas-dev
_______________________________________________
cas-dev mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas-dev
_______________________________________________
cas-dev mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas-dev
PRIVACY NOTICE
This email and any attachments may be confidential and/or privileged. Use of
the information contained in this email by anyone other than the intended
recipient is strictly prohibited. If you have received this email in error,
please notify the sender by replying to this message and delete this email.
_______________________________________________
cas-dev mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas-dev
