[cas-dev] CAS Client "Scoping"

[Scott Battaglia]

I generally work with the individual cas clients and not with the ones to
protect application servers so I am not as familiar with them.

However, to my untrained eye ;-) this seems to make the most sense:

A CAS Directive (is that what they're called in Apache?) should apply to the
directory it has been applied to AND its subdirectories.

Thus if you have the following structure:
/department1/app1
/department1/app2
/department2/app3

If you apply "CASRequired" to "/" then they would all fall within the scope
of that authentication request.

If you apply CASRequired to "/department1" and "/department2" it would
probably be two authentication requests.

At least that makes sense to me.  But again, I don't really work with
Apache.

-Scott


On 8/9/07, Smith, Matt <matt.smith at uconn.edu> wrote:
>
> 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
>
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
>
>


-- 
-Scott Battaglia

LinkedIn: http://www.linkedin.com/in/scottbattaglia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20070810/e102f9c5/attachment.html