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
