This subject came up in the discussions of multi-factor authentication
too and I think it is worth reconsidering what it means to go to the
/login page. When multiple factors are in play it becomes much more
useful for the user to discover what credentials are currently valid
and which ones are expired or were never provided. Using the principal
of always providing the user accurate information about what's going
on, I would strongly urge that the "general success" page should give
the user information about whether or not the current TGT is valid or,
in MFA, which credentials are currently valid. Starting from this user
experience requirement - which is where Jen started - I think the
underlying behavior / application architecture needs to be adjusted to
accommodate validating credentials before presenting "success".
Susan
Scott Battaglia wrote:
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
--
Susan Bramhall ([email protected])
Enterprise Architect
Yale University Information Technology Services (ITS)
25 Science Park, 150 Munson St, New Haven, CT 06520
Phone: 203 432 6697
--
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
|
