Hmm, I played around a little more, and it appears that once a CASTGC cookie has been issued for a given session (the JSESSION id cookie is constant), a second CASTGC cookie will not be issued for that same session and login ticket combination. It is possible to get a new CASTGC cookie with the same session, but for that to happen, the login ticket must change.
The behavior I am observing is that sometimes (and it's strange that it requires a variable number of attempts before it happens--sometimes it takes just 1 failed attempt before the next attempt gets a CASTGC cookie, sometimes it takes 15 failed attempts) for a session that doesn't yet have a CASTGC cookie, CAS seems to accept any login ticket (as long as it can decrypt it successfully, anyway), even if it wasn't issued for that session--it will go ahead and issue a CASTGC ticket anyway. Scott, I really appreciate your help. I've added some more information/questions to the "CAS 3.4.7 login fails with clustered CAS servers behind load balancer" thread. I'm even more interested to read your thoughts on that thread. Thanks again, --Jon On Wed, Apr 6, 2011 at 10:34 PM, Scott Battaglia <[email protected]>wrote: > I only have my phone with me while traveling so I'll reply with detail when > I get home. > On Apr 6, 2011 6:51 PM, "Jon Oler" <[email protected]> wrote: > > I think I may have found an issue with login tickets in CAS 3.4.7. To > replicate, do this: > > > > 1. Download the cas 3.4.7 distribution and copy the > cas-server-webapp-3.4.7.war file into the webapps directory of a clean > tomcat server installation. Start the tomcat server > ($TOMCAT_HOME/bin/catalina.sh run) > > 2. Open this url in a browser: > http://localhost:8080/cas-server-webapp-3.4.7/login. View the source and > copy the login token ("lt") in the source. Now enter foo/foo for the > username/password to get a successful login in the browser. > > 3. Run this from a shell, but insert your value for the "lt" parameter > from step #2: > > > > rm -f /tmp/cookies; for ((i=0;i<=25;i++)); do curl --location-trusted -b > /tmp/cookies -c /tmp/cookies -d > 'username=foo&password=foo<=D945AB83BB60A008D89DEE3D043D83F06D7868F54E78FA55A6611069E9AE4F4687F997BAAA48E410E1C8FF69A3564149&_eventId=submit&submit=LOGIN' > http://localhost:8080/cas-server-webapp-3.4.7/login; cat /tmp/cookies; > done > > > > What I'm seeing is that after the first iteration of this loop, the > output of /tmp/cookies will look like this: > > > > localhost FALSE /cas-server-webapp-3.4.7 FALSE 0 JSESSIONID > 47FEE56ACA603069F8E3E7E4789CC82B > > > > However, as the loop runs, and the funny thing is that sometimes the loop > just needs to run twice to see this, and the most I've seen is that it needs > to run 17 times, eventually CAS will issue a CASTGC ticket, so /tmp/cookies > looks like this: > > > > localhost FALSE /cas-server-webapp-3.4.7 FALSE 0 JSESSIONID > 47FEE56ACA603069F8E3E7E4789CC82B > > localhost FALSE /cas-server-webapp-3.4.7 FALSE 10 CASPRIVACY "" > > localhost FALSE /cas-server-webapp-3.4.7 TRUE 0 CASTGC > TGT-1-GE0EdTAcedboUA9jPykLmEmA4wc71A6UsumvQAoTiXMHkE4pnc-cas > > > > From my reading of the CAS protocol document ( > http://www.jasig.org/cas/protocol), section 3.5 on login tickets this > shouldn't happen: > > > > "Login tickets MUST only be valid for one authentication attempt. Whether > or not authentication was successful, CAS MUST then invalidate the login > ticket, causing all future authentication attempts with that instance of > that login ticket to fail." > > > > I have also seen this behavior in a staging server that I have that is > configured similar to what we want our production settings to be > (jdbc-backed user storage, actually redirecting to an actual app instead of > a direct CAS login, etc.). Am I correct that CAS shouldn't be behaving this > way? > > > > -- > > 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 > > -- > 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 > > -- 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
