Not sure, but I like the focus on the user experience. The thing is, even right now, in the default deployment scenario there is no context for the SSO Session. Back in the day, RU provided one to students by linking CAS and the TGC to uPortal. The SSO Session started and ended with the portal, even though other applications were delegating authN to CAS. And of course there were other applications that were not CASified and obviously didn't participate.
This may come back to having specific branding/behavior in the CAS Login UX based on the Service metadata. Something like this is included in the "NISO Recommended Practice on Single Sign-On Authentication Available for Public Comment". (Not the SSO Domain stuff, but the Service branding). "Branding—for both the SP and IdP sites—is important for conveying to the user that s/he is looking at a page that is part of the natural access and authentication flow to reach the desired resource. If users are presented with a page that offers no context and no hints about the SP or IdP identities, they may conclude that they have been sent down a dead end or be concerned about phishing and decide not to pursue their search. Recommendations: Service provider branding should be inserted: 1) Within the Identity Discovery Page that is part of the SP site (see 4.4.2). 2) Within the Institution Login Page (see 4.5.1) to reinforce to the users that the appearance of the login page is related to their efforts to access information at that service provider." http://www.niso.org/workrooms/sso/ Perhaps users logging into a specific SSO Domain would have list of Services that are included in that domain on the login UX and have a way to hide/show it. For instance the CAS Login page for the myRutgers case could have providing some messaging about the context - "access to most student services". The concept is not Enterprise/Web Single-Sign On per se (as in SSO to all the Web applications available in a particular Enterprise). It's more like sign on to a particular context which includes logically related services such that one would have an expectation of not being challenged for credentials more than once. This probably even extends to the Federation and Virtual Organization use cases. SSO Domains for different collections of internal apps, external apps, mix of internal and external, collection of VO apps,...perhaps each SSO Domain requiring a different LoA, and having different expiration policies. Bill On Sun, Jun 12, 2011 at 8:39 PM, Scott Battaglia <[email protected]> wrote: > 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 -- 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
