[cas-dev] CAS Client "Scoping"

[Smith, Matt]

All-

Apologies for the long email, but we've been trying to wrap our brains
around how mod-auth-cas should implement "renew" to properly handle
various cases where CAS'ified applications & hosts have sub-locations
that require renewal.  We've ended up with some questions about expected
behavior for CAS client "scoping":
  In a given application or multi-application host, where different
levels of URL may have different requirements (CAS-protected, renew,
gateway), and deep-linking is possible, how should the application
session (and the associated cookie's "path") be scoped?
  
Here are a few scenarios we've come up with.  Some may seem obvious, but
the implementation conflicts introduced by some of the obvious cases are
interesting.  I've withheld our answers for now, to encourage fresh
discussion.

*Scenario 1 ("Immediate family" scoping):
  An application is hosted at https://web.example.com/app1 . The whole
application requires authentication, and is therefore CAS protected at
"/app1".  Sub URLs "/app1/secure1" and "/app1/secure2" require stronger
protection, and so require "renew".  Sub URLs "/app1/subdir1" and
"/app1/subdir2" do not require "renew".

*Question 1a ("Parent" traversal):
  If a user deep-links to "/app1/secure1" or "/app1/subdir1", and
authenticates at the CAS server, should another (non-renew) SSO
roundtrip to the CAS server be required to access "/app1"?

*Question 1b ("Sibling" w/ renew traversal):
  If a user accesses "/app1/secure1", and renews at the CAS server,
should another renew roundtrip to the CAS server be required to access
"/app1/secure2" ?  Or, is one renew per application appropriate?

*Question 1c ("Sibling" w/o renew traversal):
  If a user deep-links to "/app1/subdir1", and authenticates at the CAS
server, should a (non-renew) roundtrip to the CAS server be required to
access "/app1/subdir2" ?  Or, is one authentication per application
appropriate?  Similar to Question 1b, but doesn't require "renew".

*Question 1d ("Child" traversal):
  If a user accesses  "/app1/secure1", and renews at the CAS server,
should another SSO+renew roundtrip be required for
"/app1/secure1/subsecure"?  Should it be possible to configure another
renewal for "/app1/secure1/subsecure"?

*Scenario 2 ("Family-you-don't-talk-about" scoping):
  Two departments host three applications at
https://web.example.com/department1/app1 ,
https://web.example.com/department1/app2 , and
https://web.example.com/department2/app1 .   Each is CAS protected at
the application root.

*Question 2a ("Half-Sibling" traversal):
  If a user accesses "/department1/app1" and authenticates, should a SSO
roundtrip be required for "/department1/app2" ? What if they both
require "renew"? Note that this is the same as Questions 1b & 1c with
URL names changed.

*Question 2b ("Cousin" traversal):
  If a user accesses "/department1/app1" and authenticates, should a SSO
roundtrip be required for "/department2/app1" ?

Recognizing that most CAS clients are implemented for the application
layer, and therefore the session boundaries can be scoped to the
application bundle, this may only be an issue for container-layer
clients like mod-auth-cas that are "location aware", and not application
aware.  But I'd like to ensure that the behavior is common.  For
mod-auth-cas, these scenarios impact the cookie "path", what is stored
in the user's session (keyed by the cookie), and the syntax/semantics of
<Location>,<Directory>, and .htaccess configuration, with a particular
eye to configuration inheritance.

We have tossed around the idea of a configuration parameter "CASScope"
or a set of parameters "CASScope" + "CASRenewScope" + "CASGatewayScope",
where a URL prefix could be specified to specify the scope, but we'd
like to get some feedback before proceeding down that path.

Any discussion is appreciated.  Thank you,
-Matt
-- 
Matthew J. Smith <matt.smith at uconn.edu>
University of Connecticut UITS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://tp.its.yale.edu/pipermail/cas-dev/attachments/20070809/70f75757/attachment.bin