Shibboleth Developers

[Bradley Schwoerer <>]

UW-Madison has put out to bid to add a LOT of the functionality that you
have referenced.  We see the need to add this functionality for most of the
same reasons that you have stated.

One of the other main drivers moving forward is usability issues if we don't
do RBAC at the IdP.  There is no way we can expect an SP to give a friendly
message to a known group of users that the SP does not service.  Google Apps
is a perfect example for that.  Our affiliated hospital system has NetIDs,
but will never work for Google Apps and their message for un-provisioned
users is very unfriendly.

I am guessing that after UW-Madison has awarded the bid, the company picked
will be working with this list and the core developers to fill in the
details for the statement of work.
 
-Bradley 


On 9/7/10 6: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"
>