Burden of Authorization

[Alex Olson]

Understood. I’d like to avoid this if possible, but just in case, how do we configure our IdP to refuse to send an assertion back to the SP?
--
Alex K. Olson

From: Eric Goodman <Eric.Goodman at ucop.edu<mailto:Eric.Goodman at ucop.edu>>
Reply-To: Shib Users <users at shibboleth.net<mailto:users at shibboleth.net>>
Date: Thursday, December 18, 2014 at 12:30
To: Shib Users <users at shibboleth.net<mailto:users at shibboleth.net>>
Subject: RE: Burden of Authorization


I’ll second Nate’s comments. The only real enforcement the IdP can do is refuse to send an assertion or user attributes back to the SP, which is not recommended but can be done. Beyond that, the SP must do the enforcement.

But as to who tracks data that drives authorization, that’s negotiable. Some IdPs will release userid and tell the SP: “assign this guy whatever access you want”. In that sense, the authorization is almost 100% at the SP. Other IdPs  will agree to release attributes that indicate information about a person that can be used to derive or affect  authorization. E.g., “library patron”, “student”, “timesheet approver”.

As a general rule, if the granularity of the authorization is coarse enough and is well-enough understood -- that is, if you as an IdP actually have access to existing attributes that can express the user information required -- it’s no issue to send the source authorization  data from the IdP to the SP. However, SAML only addresses how to express attributes you have. It says nothing about how you manage or track those attributes. So it’s silent on who’s “job” it is.

In practice, fine-grained authorization or application-custom authorization logic is going to be very difficult for a random IdP because so many IdP’s don’t have access to any such data or systems for managing that data. My sense is that as a whole campuses are moving in the direction of having these capabilities, but at least today anyone that assumes IdPs have a low-friction method to provision and manage authorization for arbitrary applications is going to be frequently disappointed.

--- Eric


From: users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net> [mailto:users-bounces at shibboleth.net] On Behalf Of Alex Olson
Sent: Thursday, December 18, 2014 11:09 AM
To: Shib Users
Subject: Burden of Authorization

In Shibboleth/SAML protocol in general, who’s burden is it to determine whether or not principal X should be able to access some service, the IdP’s or the SP’s?

I’d be inclined to think that the IdP is simply the releaser of attributes and the SP has the burden to use those attributes to determine whether or not the principal should be allowed access, but now we are being asked by a vendor to have our IdP bear the burden of authorization. What do you think? Should I push back? Is it even possible to have the IdP bear the burden of authorization?


--
Alex K. Olson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20141218/637632ba/attachment-0001.html