[cas-dev] Multiple security levels (aka the circle of trust)

March, Andres amarch at soe.sony.com
Tue Nov 28 15:07:40 EST 2006


Working on activity diagrams but here are the major steps of a couple
use cases we need to handle:

 

I.                     Auto-login for low security realm

1.       Visit secure page at low security site and get forwarded to CAS

2.       Login to CAS and get forwarded back to low security site

3.       Visit secure page at medium security site - since user logged
in during current browser session, CAS will issue ST for the medium
security realm (the current CASTGC can accomplish this)

4.       After medium security site has validated the ticket, user views
site content

5.       Visit secure page at high security site - user required to
relogin because low security login didn't grant high security
authentication  (we can do this currently with the renew flag)

6.       Login to CAS and get forwarded back to high security site

7.       User closes browser

8.       User opens browser and visits secure page at low security site

9.       User is forwarded to CAS which issues an ST because the user
has logged in within some arbitrary time period (e.g. 1 month) 

10.   Visit secure page at medium security site - since user has not
logged in during current browser session, CAS will NOT issue ST for the
medium security realm

11.   User views site content

II.                   Inherited Authentication

1.       Visit secure page at high security site - user required to log
in

2.       Login to CAS and get forwarded back to high security site

3.       User closes browser

4.       User opens browser and visits secure page at low security site

5.       Forwarded to CAS - CAS will issue ST for the low security realm
because the high security realm authentication includes low security
auth

6.       User views site content

 

Notes:

*	While step 3 is currently possible, it conflicts with the need
to keep the user logged in past browser sessions for the low security
realm
*	Step 5 is also currently possible, it is there for completeness
and to reflect differences with case 2 where a high security auth will
grant low security auth.  Also, I'm not sure I have used the renew flag
with acegi yet but that is a different issue.

 

It appears that these 2 use cases would be easily accomplished with
multiple TGCs.  I have been trying to think of alternative
implementations to using multiple cookies but have not come up with any.
Maybe you have a suggestion.  The CAS webapp controllers appear to
depend on a single cookie implementation.  

 

________________________________

From: cas-dev-bounces at tp.its.yale.edu
[mailto:cas-dev-bounces at tp.its.yale.edu] On Behalf Of Scott Battaglia
Sent: Tuesday, November 28, 2006 11:31 AM
To: Mailing list for CAS developers
Subject: Re: [cas-dev] Multiple security levels (aka the circle of
trust)

 

Andres,

This is something that we could possibly be interested in supporting in
CAS.  I'd be interested in seeing your use cases and what modifications
(if any) would be needed in CAS to support this.

-Scott



On 11/20/06, March, Andres <amarch at soe.sony.com> wrote:

Driven out of the need for "remember me" functionality, my organization
is considering adding multiple levels of trust to our CAS
implementation.  The idea is that some authentications aren't as trusted
as others.  Basically, I want them to be able to be logged into a forums
type site for a very long time between browser sessions but not into a
billing info site.  The gateway and renew flags are very useful in this
respect but we need a bit more.  We would like some low security sites
to accept an auth created from previous browser sessions but for higher
security sites to not accept it.  Obviously we would like users going
from a higher security type site to a lesser one to be auth'd.

 

There are many issues and questions around the use cases for this type
of functionality but I wanted to ask the list if any thought has put
into this type of scenario.  Since my requirements are mainly drawn from
the need to keep around the TGC for varying periods of time, I have
considered using multiple TGC cookies to accomplish this need.  In
addition to a default TGC with a browser session expiry, I could add
others based upon the service parameter passed to /login.  Lower
security services would have one or more TGC added that would be used
during subsequent /login calls for other services.  If the browser
session has ended and the client did not still have a TGC that the
passed service required, then the user would have to reauth.

 

Basically, I have to implement multiple security realms where some
realms include others.  Thoughts?

 

-----------------------------------------

Andres March

Platform - Apps Engineering

Sony Online Entertainment

desk: 858.577.3373

cell:   619.519.1519

 


_______________________________________________
cas-dev mailing list
cas-dev at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas-dev



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20061128/57eac41d/attachment-0001.html


More information about the cas-dev mailing list