Shibboleth Developers

[Mark John Rank <>]

Andrew:

When you say "Wisconsin", what institution do you mean?

Please advise,
Mark


------------------------------------------
Mark Rank, Middleware Architect
University Information Technology Services 
UW-Milwaukee                       
Email: 

            
Phn:  414-229-3706     
------------------------------------------

----- Original Message -----
From: "Andrew Petro" 
<>
To: 

Sent: Monday, January 24, 2011 8:45:19 AM
Subject: [Shib-Dev] Wisconsin attribute-dependent user messages project

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 <http://www.springsource.org/go-webflow2> 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 
<http://vimeo.com/11631079> and, more trivially, this blog post 
<http://www.unicon.net/blog/apetro/cas_aup_checkbox>.

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