Ok. How about we raise our expectations for the user experience of this?
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?
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.
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.
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.
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]
> <mailto:[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]
> <mailto:[email protected]> as: [email protected]
> <mailto:[email protected]>
> > To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-dev
> --
> You are currently subscribed [email protected]
> <mailto:[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
