Burden of Authorization

[federator]

On 12/18/14 4:06 PM, Cantor, Scott wrote:
> On 12/18/14, 8:41 PM, "federator" <wpadmin at identiainc.com> wrote:
>
>> 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.
> No, that's not what people mean by it. Performing authorization at the IdP
> generally means blocking SSO for unprovisioned or unauthorized accounts.
> That's what the vast majority of cloud services require because
> authorization doesn't matter to them, the resources aren't theirs to
> protect.
Sounds like the terminology confusion is quite widespread.  Even Google 
is calling their OAuth engine which performs authentication as 
"Authorization Server".  Authorization deals with access control after 
user has been authenticated by some means.  Yes, most cloud identity 
providers only handles SSO at this point and that's not authorization by 
all means.
>> 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...
> You could switch ten times, and 9 of them would demand that you relieve
> them of all error handling responsibility.
That's very true because these vendors don't do authorization, and this 
is why:  The hard reality is that 99% of the service provider 
implementation today is still based on account-based security using 
Role-based access control.   RBAC requires you to create user account on 
for every user and assign him/her with access roles or groups, even user 
authentication can be handled via IdP externally. To fully utilize the 
benefits of federated identity management via IdPs, the RP or the SP 
technology has to be upgraded to support so called "account-less" 
authorization mechanism.   That's the real challenge to make federated 
identity and access control truly scalable.
>
> -- Scott
>