I was wrong about the problem below being related to EHCache timing. Our EHCache was already set to synchronous which is why we never saw this during a lot of load testing. Only now has this occurred because PeopleSoft was trying to validate the same ST twice which violates the CAS protocol which states that "Service tickets MUST only be valid for one ticket validation attempt. Whether or not validation was successful, CAS MUST then invalidate the ticket, causing all future validation attempts of that same ticket to fail." (http://www.jasig.org/cas/protocol).
So, the real issue is that PS should not be trying to validate twice after it has succeeded in the first ticket validation. I asked our PS group to up the logging and try again to see what is happening in the CAS plugin during authentication. Ted F. Fisher Server Administrator 323 Hayes Hall Information Technology Services Email: [email protected]<mailto:[email protected]> Phone: 419.372.1626 [cid:[email protected]] We have two CAS servers behind a load balancer (Cisco ACE) with EHCache implemented so Service tickets, etc. are available to both servers. For the client sessions coming in through the load balancer we use sticky selection of the back end server. But, when the application servers contact CAS to validate the ticket we do not have the connection sticky since it would do no good. The server is attempting to validate a ticket created by the client session so stickiness does nothing to direct the server connection to the "correct" CAS server. With one particular app (Peoplesoft) I see the ST created on our CAS node #2 and in the same second it is validated by the PS server. A second later the PS server tries to validate the ticket again and this time the load balancer sends it to our CAS node #1 which logs "ServiceTicket [ST... does not exist". I presume it is simply a matter that EHCache has not sent that particular ST yet so is really an issue of timing. I could make it sticky but that will not resolve the problem. Then if the PS server gets sent to the not yet aware of the ST CAS server it will just fail validation twice. That would make it a 50/50 chance that with both validations would succeed or both would fail. How are others dealing with this timing issue? Any suggestions how we can prevent the validation failures? I would presume that we could tweak EHCache to sync more quickly but at a cost in performance. How do we determine an appropriate balance of EHCache timing with ticket validation timing (if that is even the best way to address this)? Appreciate any help on this one? Ted F. Fisher Server Administrator 323 Hayes Hall Information Technology Services Email: [email protected]<mailto:[email protected]> Phone: 419.372.1626 [cid:[email protected]][cid:[email protected]] -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
<<inline: image001.gif>>
<<inline: image002.jpg>>
