Just one more tidbit. As mentioned previously, it appears that for a given session, once a CASTGC cookie has been issued with a given login ticket, a second CASTGC cookie will not be issued for the same login ticket with that session (tested by deleting the CASTGC cookie). However, for a given session, if there is a login failure (incorrect username/password) for a given session and login ticket combination, CAS will issue a CASTGC ticket for a subsequent login POST with the same session and login ticket combination. This would seem to violate the CAS protocol, section 3.5 on login tickets (http://www.jasig.org/cas/protocol):
"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." Steps to reproduce (with the same tomcat/cas war described in previous post on this thread): 1. rm -f /tmp/cookies; curl --location-trusted -b /tmp/cookies -c /tmp/cookies http://localhost:8080/cas-server-webapp-3.4.7/login 2. Examine the output from the curl command in step #1, find the login ticket (the "lt" hidden input), and replace the lt value in this command with the one you find (this will be a login failure since username and password don't match): curl --location-trusted -b /tmp/cookies -c /tmp/cookies -d 'username=foo&password=bar<=DFE7A62C5A5489E50C149\ 51B718290031B3B26044E504B3ED06440A6493C7F523802417752E483260585A4E7DA55392B&_eventId=submit&submit=LOGIN' http://localhost:8080/cas-server-webapp-3.4.7/login;\ cat /tmp/cookies 3. Note that there is no CASTGC cookie as expected, only a JSESSIONID cookie. Now, run the same command as in step #2, but with matching username/password (foo and foo): curl --location-trusted -b /tmp/cookies -c /tmp/cookies -d 'username=foo&password=foo<=DFE7A62C5A5489E50C149\ 51B718290031B3B26044E504B3ED06440A6493C7F523802417752E483260585A4E7DA55392B&_eventId=submit&submit=LOGIN' http://localhost:8080/cas-server-webapp-3.4.7/login;\ cat /tmp/cookies However, now we have a CASTGC cookie that we obtained from the same session using the same login ticket: localhost FALSE /cas-server-webapp-3.4.7 FALSE 0 JSESSIONID E568CBE73F307237031E9C22D04AB186 localhost FALSE /cas-server-webapp-3.4.7 FALSE 10 CASPRIVACY "" localhost FALSE /cas-server-webapp-3.4.7 TRUE 0 CASTGC TGT-23-zuqoGM6QBa4MXCiajfC74LdeYZS0236PRaTjRwDHbLgTUpM4zb-cas In this test case, the initial authentication attempt after the http GET to load the login page and obtain the login ticket was unsuccessful due to an incorrect username/password combination. However, the protocol doc says that the login ticket should be invalidated "whether or not authentication was successful". Is this a protocol violation? Thanks, --Jon On Wed, Apr 6, 2011 at 11:31 PM, Jon Oler <[email protected]> wrote: > 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
