An issue has been opened for this before, and it was marked as "Will Not Fix" or whatever the JIRA equivalent is. The likelihood of that changing would only depend on a fundamental change to the way we think about sessions.
Currently single sign on sessions, as a convenience, can be initiated by just going to /login. One could imagine, however, that an appropriate use case for /login could merely be an informational page. Single Sign On sessions, and thus their validity, only become relevant when "used" where used generally means the generation of a service ticket or validation of a service ticket (though it also includes the generation of a proxied session). Because the validity only matters when we use the ticket, there's no exposed method for determining when a SSO session, on its own, its still valid. Thus, as an optimization, if we see the cookie, we just assume you have one, because in all honesty, other than what's displayed on the page, it doesn't really matter (we'll put aside the argument on whether what's displayed on the page really matters). Once you attempt to use the session, as you point out, the validity checks come into play. Going to /login and seeing you're logged in when you're not, and then being asked to log in when you go to use a service is the equivalent of your session being valid when you went to /login, and then it having expired in between requests (which I'll grant, the probability of you accessing the pages during the small period of time is rather small). I'd be interested in valid use cases for actually determining whether a session is valid or not. For example, if the page was going to become some form of "informational" page about you, you'd only want to do it if they were logged in :-). There's obvious issues with making it an informational page (i.e. if you forgot to log out on a public computer). The point is I'm interested in exploring doing the validity checks in the absence of a service request when their are obvious benefits to doing the check. In the meantime, we'd probably stick with our simple check, because other than the message displayed, it doesn't really matter. Wow, its been a long time since I've written that much in a CAS-related email ;-) Cheers, Scott On Wed, Sep 1, 2010 at 6:28 PM, Jennifer Bourey <[email protected]>wrote: > 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
