Burden of Authorization

[federator]

Alex,

It's an ongoing debate on whether authorization should be centralized 
(performed by the IdP) or localized (performed by the SP).  Technically, 
the right way to implement authorization in SAML (or using federated 
identity technology in general) is to delegate it to the SP site.   The 
reasons are quite simple:

1. The user transactions are completely different between authentication 
and authorization.  A user needs only one transaction to complete 
authentication.  Once user is authenticated via an IdP, no interaction 
is needed between IdP and your browser (except SLO). From that point, 
every user transaction occurs between the user and the corresponding 
SP(s) directly.  Imagine that if you have IdP to handle authorization, 
then every user request will have to be intercepted by the IdP for 
making authorization decisions.  If you IdP happened to support multiple 
SPs and large numbers of users, this can make your IdP a bottleneck if 
not useless.
2. Authorization deals with mapping between user access roles or 
attributes to resources.  If authorization is centralized (e.g. by IdP), 
you will have to update your policies every time if there is a resource 
change (e.g. adding a new web application or deleting a data file) on 
some SPs.  If you have multiple SPs to deal with and each one is 
managing thousands of resources, the overhead and time consumption of 
policy management can be huge.

I haven't seen any good implementation or even good use cases of using 
centralized authorization.  Maybe you could ask your vendors for any 
good use cases.   If not, maybe it's time to switch vendors...

Nick
On 12/18/14 2:08 PM, Alex Olson wrote:
> 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/798e9d79/attachment.html