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 cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
