Has there been any discussion on the CAS user list about what actual in the field requirements are? There are a lot of wasy this could be done but it would be nice to have reality based current requirements. Susan
On 6/12/2011 9:24 PM, William G. Thompson, Jr. wrote: > 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
<<attachment: susan_bramhall.vcf>>
