Shibboleth Developers

[Andrew Petro <>]

Wisconsin has successfully navigated procurement and engaged with Unicon for a project to locally customize the Wisconsin IdP and to implement uApprove with customization, with the intent that the customizations and custom code developed become freely available through this effort.

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."

There's a lot packed into that sentence.  Here a couple use cases it can address:

1) Attribute release

You can think of some Attribute Release use cases as a special case of attribute-dependent user messages (where the messaging is non-terminating and happens to be about the release of attributes).

Attribute release is of course already a partially solved problem, but the specific itch to be scratched here is easing making the prompting for attribute release conditional not just on the identity of the service provider but also on the values of some attributes. 

As in, most concretely, users who set their FERPA bits experience much more prompting about attribute release than do users who do not set their FERPA bits.

2) Fast-failing the login process with sensible user messaging

Some applications require that users be pre-provisioned or have constraints on the values of user attributes in the SAML they consume, such that if the user is not pre-provisioned or doesn't have the expected attribute values, the application fails badly with a poor user experience.  In some cases the IdP is better equipped to provide an institutionally-contextually-appropriate failure experience.

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.

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.



There's a technical bias going into this effort that a good way to immediately enable implementing these use cases is to bridge to the Spring Web Flow framework and use configurations of Spring Web Flow to implement the attribute-based messaging rules and experiences.

Note that Jasig CAS uses Spring Web Flow and Unicon (and others) have had good experiences customizing its login workflow via custom configurations of Spring Web Flow.  Cf. this conference presentation and, more trivially, this blog post.

So going into it the default idea is to bridge to Spring Web Flow to implement the user login experience in the IdP, feed to that web flow the user attributes, and implement use cases involving special messaging on certain combinations of target SP and user attribute value as states in the flow.

Andrew