Shibboleth Developers

[Andrew Petro <>]

> Perhaps if it's common some IdP structure could be created (in v3) to 
make adding such checks more accessible.

+1. In Jasig CAS, we call this set of features (such as they are) the 
Services Registry.

> It is most likely within the capabilities of a site-developed login 
handler to do this kind of thing.

-1 for abusing LoginHandler to do something that's less about the user 
login and more about the service the user is trying to access.

Andrew





On 09/07/2010 04:48 PM, RL 'Bob' Morgan wrote:
> 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"