On Wed, Aug 3, 2011 at 8:51 PM, Andrew Petro <[email protected]> wrote:
> ** > Ok. How about we raise our expectations for the user experience of this? > The user experience for a misconfigured site? How often do you expect this to be seen? (1) when the client forgets to set renew=true during the initial testing (they test, right?) and (2) if someone manually manipulates the url to remove renew=true? > > It's not the user's fault that their single sign on session won't be > honored. Do they expect to see an error message, or would they just as > happily immediately see the login form so they can accomplish login and get > into the application they're trying to access? > > So its better to not explain to them why they're being forced to log in when they expected single sign on? > If there should be a notice to the user that their SSO session will not be > honored, wouldn't it be better to adorn the CAS login experience with that > message? Saves the user a click. > > Possibly, though I would hope the user never sees this message at all unless they manipulate the URL manually. The only people I would realistically expect to see this is the client testing their integration and forgetting that someone in security deemed their application sensitive enough to have to use renew=true > Which is to say, why shouldn't an application's opting out of single sign > on via the services registry be exactly as if that application had always > set renew=true? renew=true doesn't yield a message to the user advising > them that they attempted to access a service requiring authentication > without yet being authenticated, it just sends them straight on to the login > screen. > > I think you're assuming the services management tool does something that it doesn't. That option exists to check client behavior . We still require the client to set the property on their end. > Like I tried to say in the other thread, how about services registry opting > out of SSO be refactored as simply an additional check here: > > <decision-state id="renewRequestCheck"> > <if test="externalContext.requestParameterMap['renew'] neq '' > && externalContext.requestParameterMap['renew'] neq null" > then="viewLoginForm" else="generateServiceTicket" /> > </decision-state> > > > such that if either renew=true or if !registeredService.isSsoEnabled() , > then viewLoginForm. That is, disabling SSO for the service via the registry > should have exactly the same effect as renew=true, achieved through plugging > in to the same decision logic / flow. > > You're assuming that setting that flag configures your client centrally. All it does (and is expected to do) is confirm that the client configured their stuff correctly. You and Bill appear to be working on something that involves heavy usage of the services management tool. Your usage appears to be beyond the original intention of the tool (which is funny because its modeled after the original whitelist we had at RU, which Bill had a hand in ;-)), and thus your belief that whenever it doesn't meet your use cases, its quite possibly a bug. Rather than us go back and forth on this list on whether every expectation that isn't satisfied is a bug or not, I'd rather this be a constructive conversation that moves the tool forward by solving your (and other's) use cases for the tool. It seems like now is as a good a time as any to move it beyond its original gatekeeper, configuration checker, and attribute releaser role. On the roadmap, revamping of the services management tool is coming up soon (unless we change the road map :-D). An opportunity for heavy collaboration and an awesome new services management tool? Cheers, Scott > Andrew > > > On 08/03/2011 08:30 PM, Scott Battaglia wrote: > > It's expected behavior. It's not a bug. > On Aug 3, 2011 8:26 PM, "William G. Thompson, Jr." <[email protected]> > wrote: > > Setup: > > Two services configured via Services Management (SM). > > One service (casapp) is configured to opt-out of SSO via SM. The > > other app is SM. > > > > Steps to reproduce: > > 1) login into SM (challenged for credentials, initiate SSO) > > 2) try to login to casapp - expected to get challenged for > > credentials, instead get a CAS screen that says: > > > > "You attempted to access a service that requires authentication > > without re-authenticating. Please try authenticating again." > > > > The link under "try authenticating again" is the original cas login > > redirect, but this time with renew=true tacked on the end. > > > > Is the expectation that the SM config be complemented with a client > > config of renew=true? > > > > I'd like to manage SSO with SM, but the current behavior leads me to > > believe no one is actually doing this (at least not without the > > renew=true also at the client). Why doesn't the CAS server simply > > challenge for credentials like renew=true? Am I missing something? > > > > 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 > > -- 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
