Shibboleth Developers

[Andrew Petro <>]

> Point being, this is very situational, not a hard and fast rule.

I agree completely.  The University of Wisconsin-Madison use cases 
around interrupting misadventures accessing specific SPs are highly 
situational.  There's no proposal here that the IdP behavior should 
change in a general case, only an intent to equip the University to make 
the best of current interactions and to make it more feasible to tailor 
the login experience to the situation.

That this is situational and that the rules and requirements are subject 
to change is part of the appeal in bridging to a domain-general web flow 
framework.  There are no immediate use cases to consider cookies or 
remote address or additional user preferences or... but Spring Web Flow 
is a pretty nice framework in which to access those features when it 
turns out they are required.

> Actually you can think of it as "the SP is deployed badly".

I'll readily agree to this. I'd also suggest that no matter how 
excellent SPs may become, this is so situational and in some ways a 
matter of user experience taste that it's probably true that some would 
want to be able to orchestrate login flows along the lines proposed 
regardless.

I don't want to make too much of blaming the SPs involved here.  Unicon 
aims to give the University flexible technical options with low marginal 
configuration cost for defining user messaging in the IdP in login flows 
to their SPs, without worrying too much about whether the SP should have 
made this unnecessary.  That is, there's likely interesting work to be 
done socially and politically, but the immediate project aims to be 
technical, tactical, and relieve near-term user experience pain.

Andrew



On 01/24/2011 10:03 AM, Cantor, Scott E. wrote:
> > The main feature to be implemented in Wisconsin's current IdP v2
> > environment is "attribute-dependent user messages" which amounts to:
> > "configurably, depending on the values of user attributes (and the identity of
> > the Relying Party to which the user seeks to authenticate), the login flow 
> > will
> > be interrupted with or terminate in messaging."
> I have something more or less similar to that implemented for OSU now. I 
> wrote a login handler that devolves control to a series of submodules that 
> process the request and either attempt authentication via specific modules 
> (currently wrapped around JAAS), or respond to the client with a form or a 
> message or whatever. I have one that also performs attribute resolution 
> during the login process. Then I can add submodules for authz based on SP and 
> attribute value(s) (one of your use cases), reporting impending password 
> expiration, etc.
>
> The UI is Velocity-based, so there's no reinstallation needed to alter the 
> presentation.
>
> My presumption is this should adapt easily to the 3.x login API, which I 
> think will be a pipeline, just as mine is.
>
> I have not attempted to integrate actual attribute release consent into the 
> model, but might explore that at some point if I decide I need something less 
> than uApprove before 3.x is done.
>
> > The idea here is rather than producing a valid but useless SAML assertion and
> > sending the user along to the Relying Party to have a Bad Experience, we
> > instead detect this circumstance (again based on attribute values and the
> > identity of the target Relying Party) and terminate the IdP login flow in
> > suitable user-facing messaging.
> I think I've noted before, and I don't want to overstate this, but there are 
> some communities, mainly eGov, where there's a real obsession with 
> guaranteeing users end up back at SPs in the case of errors. Point being, 
> this is very situational, not a hard and fast rule. (That doesn't conflict 
> with anything, just noting it.)
>
> > You can think of this as "access control" but it has a different flavor to 
> > it.  The
> > use case is less about preventing users from getting a SAML assertion they're
> > not permitted to have and much more about aborting their getting a SAML
> > assertion they are entitled to but which through out of band knowledge we
> > know to be useless, despite it technically seeming to be what the Relying
> > Party has requested.
> Actually you can think of it as "the SP is deployed badly".
>
> -- Scott