Federated Authorization #3

In my previous article on Federated Authorization, I wrote:

In any case, I think there are problems with the basic premise of federated authorization. If you look closely at the various posts in regards to this question, they all talk about how you can do remote or delegated authorization. This is typically done in a model where an enterprise or service company will have some central authorization service that maintains the set of rights that their customers have.

This isn't a federated solution in that the decision as to the rights afforded the user is not delegated to a foreign entity. Even in the shibboleth model, where a student at university A is granted access to a resource at university B, the authorization decision is made by university B (yes, it's based upon the federated data that the student is a student at university A, but the authorization decision is made by university B).

And James McGovern commented with a question:

I posted in subsequent postings real scenarios where authorization is federated. Shekhar Jha had also chimed in on those which provided a good perspective. Did you get an opportunity to check out the scenarios I posted?

Referring, I think, to these articles:

Consumer Perspectives on Federated Authorization, Federated Authorization and Relationship, and Even More thoughts on Federated Authorization...

These all bring out good examples of some form of delegated authorization (and in the consumer use cases, what I would call federated authorization since you are likely crossing security domains).

While I think that many, if not all, of these use cases are interesting, I think that the model has some issues that prevent its widespread adoptions including:

• The range of settings for permissions at any one resource controller are vastly different from one instance of that type of resource to another, thus substantially raising the complexity of any centralized management infrastructure.
  

  For example, given the "authorize my lawyer to pay my insurance bill" scenario, I not only have to authorize him access to my bank account, but to extract money for a particular purpose and probably with some limits on the amount. How also do I differentiate between paying a bill and paying a co-payment or deductable?.

• The complexity for a good user understandable interface for interacting with such settings. I just don't think that we're even close in the realm of computer/human interfaces to provide a generic mechanism that will allow a central server to have the knowledge and understanding to walk the average technologist through the process. less alone my mother.
• There are a lot of privacy considerations around a centralized authorization entity (much more so than a centralized identity entity). This one entity will not only control all of my authorizations, but will also have the knowledge of what authorizations I have made. In the early days of the Liberty Alliance work, much thought and energy went into minimizing the knowledge of central parties -- that's why we have segregated service instances into groups of related data (rather than one know-all service provider), that's why we don't have the IdP involved in every message from a Web Service Consumer (WSC) to a Web Service Provider (WSP)(yes, through the Discovery Service (DS), the IdP can know that WSC wanted to talk to a particular WSP, but whether or not they spoke and what they spoke about is not visible to the DS nor the IdP.
• Doing authorization remotely can have a significant negative performance impact. This comes from the messages necessary to obtain the Authorization information, the caching of said information (without some form of caching, you're really in the dog house of performance) and the parsing of said information on each access. An internal authorization solution can be optimized for the resources being accessed and even tied to said resources within the internal database of the application. Such tight coupling is very hard to do, if not impossible, when receiving authorization statements from remote parties.

Shekhar also pointed out the "Authorization Push" model which has the same issues plus the issue of somehow figuring out at push time, the policies that the recipient will be interested in. I tend to favor push models when the information necessary at the recipient is easily known in advance. With complex authorization policies, the only way to support push would be to push the entire policy -- something that can be very expensive from a bandwidth and processing overhead point of view.

Another problem with the push model is that it assumes a single identity in the interaction. However, when I go to access Paul's photo service, its his service that needs to get the authorizations from his authorization pool, not from mine. I don't think push works in that environment

I'm not normally the pessimist... I just think that in this case, a distributed authorization model is a much better solution. Tight, application specific authorizations (such as "can James add a comment to this article on my blog") are kept with the resources being authorized. Loose, granular, cross-application authorizations (such as "can James see my blog") are more suitable for some level of centralization.

Tags : identity / federation / authorization / liberty+alliance / liberty / rbac / xacml / id-wsf