Shibboleth Developers

["Cantor, Scott E." <>]

> 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