Shibboleth Developers

["RL 'Bob' Morgan" <>]

In Shib/SAML, the model is that the IdP provides information (attributes) 
about a user that may be used by the SP (along with its local policy and 
user information) to make access decisions.  Normally this is a fine 
approach, but sometimes limitations of SPs or other considerations make 
doing some authorization or other processing at the IdP appealing.  We've 
recently had some requirements come up at UW for some IdP features along 
this line.

 * For Google Apps we need people to do a clickthrough agreement before 
starting to use the apps.  Hence there is a need to check a user attribute 
post-authentication and send the user to the agreement page (if needed) 
before redirecting them back to GA.

 * Another cloud-type service that we are working with has a policy that 
anyone who can authenticate at the IdP gets a dynamically-created account 
at the service (it's a consumer thing, eh?).  We don't want some accounts 
to have this privilege (eg temp or system accounts).  So we need to check 
a service-eligible user attribute post-authentication before redirecting 
to the SP, and give an appropriate can't-do-that UI page if the user isn't 
eligible.

 * There is a campus policy that for many admin apps the user has to sign 
a data-access-responsibilities agreeement before using the app.  This 
could be done in many ways but one way would be as above:  check a 
data-access-agreement-signed attribute post-authentication before 
redirecting to the app, and send the user to the agreement page if needed. 
This would let apps off the hook for implementing this requirement.

I think I've heard other sites express interest in IdP-side authorization 
(or filtering, or post-authentication processing) from time to time.  I 
know this can be contentious.  It seems to me that in some ways it's 
similar to the uApprove consent module in that it's IdP-side processing 
(and UI) that happens post-authentication and pre-return to SP.

It is most likely within the capabilities of a site-developed login 
handler to do this kind of thing.  It may be an issue that as far as I 
know a single login handler gets invoked per request, so having a 
potentially large set of post-authn checks would mean modifying the login 
handler for each one.  Perhaps some way of chaining handlers would be 
useful.

So, I wonder whether other sites have this sort of requirement.  Perhaps 
if it's common some IdP structure could be created (in v3) to make adding 
such checks more accessible.

 - RL "Bob"