You can change WEB-INF/spring-configuration/ticketGrantingTicketCookieGenerator.xml to set p:cookieSecure=false
That will allow cookies to be sent over http: instead of just https:. This is generally a good idea for test sandbox configurations where you want to test CAS without going to all the trouble of configuring SSL and installing a certificate. It is generally not regarded as a good idea for production systems, but then production systems typically do not expose non-SSL access. It makes no sense to JIRA something that is a configuration option. As to the other problem, I JIRA-ed it a few months back and was told that it was a duplicate of previously submitted issues that have been closed as "not going to fix". The real problem is that the CentralAuthenticationService interface does not expose a method that can be used to validate a TGTID directly. The TGTID is validated only in the call to create a ServiceTicket. Since changing this interface is an architectural change, two solutions present themselves. First, defer the test for a null service string until after the TGT has been validated. Alternately, create a special dummy service name that doesn't actually generate an ST. Without changes, you can accomplish the same thing from the Web Flow by attaching a dummy service to every request but then suppressing the service later on if it has the dummy value. This, however, leaves ST's sitting around in the TicketRegistry until they timeout unless you add logic to either the CentralAuthenticationServiceImpl to not generate them or to the TicketRegistry to not store them. However, in the scheme of local mods this is a very easy one to make. Obviously it is possible to create a bean in the WebFlow and inject yet another oddball reference to the TicketRegistry object. Then the bean can look for the ST directly, at the cost of yet another end run around the CentralAuthenticationService interface as the supposed only connection between the presentation layer and the business logic layer. Once you get over the problem of adding TGT validation to the interface, the actual validation is just an extra step in the presentation layer. So if enough people regard this as a serious problem, then maybe we can apply enough pressure to flip the current judgment that this is the way it is supposed to work. On a related note, we have found the You Have Successfully Logged On page to be the "lowest point below sea level" of CAS, where everything seems to roll to when something goes wrong. We had a CAS 2 client that when converted to CAS 3 ended up on that page instead of getting redirected back to the application. It turned out that they had coded "service=HTTP://" in their service string. The spec says this is illegal, but urges everyone to support it. However, Spring doesn't support uppercase HTTP:. When you pass this URL to the Spring "generate a redirect url" method, it decides that since the redirect target doesn't start http: or https: then this must be a local redirect to a relative URL on the same machine. It generates a "http://cas.server/cas/HTTP://..."; URL which goes back to CAS, and then because the rest of the URL is invalid ends up being mapped to login. Since the user is already logged on, however, the login is silent. Since the second time through CAS there is no service=, you end up at the You Have Successfully Logged On page. Everything happens so fast you don't see the intermediate steps which leads to a lot of head scratching. I am beginning to believe that treating every invalid URL in CAS as a /cas/login request is not really a good idea. This is, of course, a configuration option, but in most cases the missing 404 would probably be helpful. As long as /cas maps to /cas/login it may not be best practice for /cas/any/trash/you/generate to silently map to it. -----Original Message----- From: Jennifer Bourey [mailto:[email protected]] Sent: Wednesday, September 01, 2010 6:29 PM To: [email protected] Subject: [cas-dev] Login page behavior without a service parameter Hi all, I wanted to get some list input about the behavior users experience when visiting /cas/login with no service parameter. We've determined that the following somewhat confusing behaviors occur: 1. When accessing /cas/login over a non-SSL URL, users are always presented with the CAS login form, even if the user has a currently-valid CAS session. 2. When accessing /cas/login over SSL, once a user has logged into CAS, s/he always is presented with the generic login success page, even if the user's TGT has expired. This screen appears to be presented until the user's browser is restarted. Just to be clear, the behavior I'm describing doesn't seem to have any implications for security, and users are never successfully authenticated to services without a valid TGT. The concern is merely that the behavior might be confusing to users or implementers who visit the login URL without a service parameter. We've confirmed this behavior against the 3.4.2.1 release, though I would imagine the behavior occurs in other releases as well. >From my analysis of the code, it looks like both these behaviors result from the way cookies are handled in the browser. When you first visit /cas/login, the CAS webflow checks to see if you have a TGT (ticket granting ticket) ID saved as a cookie. If the cookie was found, the flow then checks to see if a service was specified. If no service parameter exists, the flow 1. Check presence of TGT cookie. If no cookie was found, send the user to the login page. If a cookie exists, check the service. 2. If no service was found, display the "generic success" page (that's the one that says your login was successful). If a service was found, attempt to get a service ticket for the service. The code doesn't check to see whether the TGT ID corresponds to a currently-valid TGT until it gets to the step of attempting to get a service ticket. Since the cookie sticks around until either you actively log out of CAS or close your browser, if you don't specify a service, you'll see the generic login success message even if your session has expired. The non-SSL (8080) version of CAS never displays the generic login message because the TGT cookie as marked as "secure." As a result, that ticket never gets set over an insecure connection. Is this behavior that the CAS community would consider a bug? Should I file a JIRA? - Jen -- Jen Bourey Software Developer Unicon, Inc. -- 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-dev -- 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-dev
