We had a use case like that come up at RU when I was still there. I'm not sure how much complexity you want to introduce to the user around single sign on though. Thoughts?
On Fri, Jun 10, 2011 at 9:18 PM, William G. Thompson, Jr. <[email protected]>wrote: > https://wiki.jasig.org/display/CAS/jasig-cas+IRC+Logs-2011-06-10 > [13:29:24 CDT(-0500)] <apetro> so the children of Sessions we're > talking about here are Sessions for proxying Principals aka Services, > right? > [13:29:24 CDT(-0500)] <battags> in 4 > [13:29:29 CDT(-0500)] <battags> yes > [13:29:38 CDT(-0500)] <battags> just like the normal TGT/PGT heirarchy > [13:29:45 CDT(-0500)] <apetro> yup > [13:29:55 CDT(-0500)] <apetro> those are convenient relationships to > model hierarchically > [13:30:13 CDT(-0500)] <apetro> since killing a Session anywhere in > that tree should kill all its children > [13:31:08 CDT(-0500)] <apetro> there's a loosely related side thought > to have here about ability to issue multiple Session cookies to a > single Browser, and the answer to that should be No, that you can only > have zero or one Sessions per Browser at a time. > > I've been think about the multiple SSO Domain support that was > discussed at Jasig. One of the ways to support this would be with > multiple CAS Sessions/Cookies. Each Session (aka TGT) would be > logically bounded by a defined set of Services (i.e. applications). > > This way a user could log out of one SSO Domain while still being > active in another. > > User logs onto collaboration portal (email, cal, wk, etc) which forms > one SSO Domain within the institution. > User then logs on to financial portal with access to W-2, paystub, > etc. (possibly requiring 2FA) and other related apps. > User the then logs out of financial portal, killing the Session in > that SSO Domain. > Collaboration portal (SSO Domain) still active. > > Department X wants to have a SSO Domain specific to their > users/application that doesn't interfere with other application login > behaviors. > > Bill > > -- > 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
