Hi Mark, I originally configured for Tomcat session clustering using multi-cast but then found out that the network here isn't configured for multi-cast and the network engineers would rather not do it. I did look at the Terracota setup but we thought we could avoid another technology stack (and all the associated learning curve) by using a JpaTicketRegistry and sticky sessions on the load balancing. This sticky sessions work fine in a single data centre but there are two data centres with a GSS router doing 50/50 round robin routing between the two and the network team are having problems implementing sticky at that level, hence wondering if we could remove the need for sticky by making CAS stateless in the way I suggested.
Regards, Matt ________________________________ From: Mark A Steddom [mark.sted...@nau.edu] Sent: 07 October 2011 17:05 To: cas-user@lists.jasig.org Subject: Re: [cas-user] Stateless CAS Hi Matt, Is there a reason your not attempting session replication? It seems to me that this would solve the issues your pointing out. We have been using Terracotta for quite some time now to accomplish this type of load balancing (with no client sticky sessions). Here is more information on the CAS Terracotta setup: https://wiki.jasig.org/display/CASUM/Terracotta But perhaps I'm not understanding some aspect of your requirements. --Mark Mark A Steddom mark.sted...@nau.edu +1 928/523-5945 Northern Arizona University Information Technology Svs Sys Programming & Supt Team Ld From: "Kirk, Matt" <matt.k...@bskyb.com<mailto:matt.k...@bskyb.com>> Reply-To: <cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org>> Date: Fri, 7 Oct 2011 15:54:36 +0000 To: <cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org>> Subject: RE: [cas-user] Stateless CAS Hi Andrew, Thanks for the reply. The bigger picture is the infrastructure having issues with a truly load balanced architecture and sticky sessions to CAS (I don't understand why) and we were seeing some redirects back to the start of the flow when the login form was posted back to the cluster because a different server was processing the flow which it didn't instigate. I was just thinking of this as an option given we already persist the TGT and ST tickets. Our cluster is not using any form of session replication hence me wondering what the lookup key would. I guess we could persist JSESSIONID and the LT and query for both when processing the form? Anyway, thanks again. Matt ________________________________ From: Andrew Petro [ape...@unicon.net<mailto:ape...@unicon.net>] Sent: 07 October 2011 16:42 To: cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> Subject: Re: [cas-user] Stateless CAS Hi Matt, I don't see a problem with clustering the login ticket state so long as it remains bound to a not-LT independently issued session cookie. You said "don't ask", so I won't. Without the larger context, not sure what's going on here. But it's essential to prevent a password-replay-through-browser abuse of the CAS login form/flow is that third parties cannot convince a user's browser to step through the CAS login flow. In CAS, the combination of the LT and the brief traditional JSESSIONID session for login form interaction accomplishes this. While a third party can independently get a valid LT and session ID paid) it can't get a user's browser to submit that pair, since the browser would acquire its own session identifier. I think that this means for your effort that LT should remain bound to the session, and you'll need to cluster the session, such that all the clustered CAS servers are continuing to enforce LT-and-session-id-pair when they handle the form submits. (Unless allowing third-party password replay through the CAS login form is acceptable.) I'd think of this less as stateless CAS and more as carefully clustering all of the state. :) Hope this helps, Andrew On 10/06/2011 01:04 PM, Kirk, Matt wrote: Hi Scott / Marvin, We may have a need to make CAS stateless such that in a cluster any server could process the login form submit even if that server didn't serve the page in the first place. (don't ask) I was wondering what your thoughts were on this. Having a look at the code I was wondering if there was any reasons why the Login Ticket couldn't be persisted into a database as is the case when using a JpaTicketRegistry solution for the other CAS tickets? I'm thinking there could be different configurable strategies for this. One which interacts with the web flow as it does now and another which interacts with a database. The only thing I'm not sure about is what could be used as the lookup key when retrieving the LT during the authentication process. It would essentially need to be some kind of session generated key, but then that would need to be included in the submit request (as the LT does currently). Or perhaps it simply selects on the LT value itself and if it finds a row, then allows the flow to continue (and then deletes the row for the one time use) and if it doesn't find the LT it redirects to the start of the flow as it currently does. I may have a play and see if I can get a working solution (which I would submit back to the community), but can you see any problems with this approach or any security implications? Regards, Matt Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trade marks of British Sky Broadcasting Group plc and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. -- You are currently subscribed to cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> as: ape...@unicon.net<mailto:ape...@unicon.net> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> as: matt.k...@bskyb.com<mailto:matt.k...@bskyb.com> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trade marks of British Sky Broadcasting Group plc and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. -- You are currently subscribed to cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> as: mark.sted...@nau.edu<mailto:mark.sted...@nau.edu> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: matt.k...@bskyb.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trade marks of British Sky Broadcasting Group plc and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
