Shibboleth Developers

["Jones, Mark B" <>]

To me, coupling authentication and authorization seems like an idea to move
away from not towards.

Could you handle the Google agreement when users are credentialed?
Could you segregate temp and systems accounts such that they are not able to
use Shibboleth?  (perhaps a different topic:  should you be able to use a
system account to authenticate to my SP?)
I have implemented things (authorization checks) like what you suggest for
'centralizing' the check for a signed data access agreement and ended up
moving it back to the application level.  They seemed to continuously spawn
annoying problems such as not working for specific use cases or not being
compatible with a new technology or standards that we want to adopt.

It has been my experience that the fewest problems surface when
Authentication and authorization are each handled separately.  My choice
would be to look for ways to satisfy these types of requirements that do not
require that authorization decisions be made at the IdP.

-----Original Message-----
From: 

[mailto:]
 On Behalf Of RL 'Bob' Morgan
Sent: Tuesday, September 07, 2010 6:48 PM
To: Shibboleth Dev Team
Subject: [Shib-Dev] IdP-side authorization or other post-authn processing


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"

Attachment: smime.p7s
Description: S/MIME cryptographic signature