Monday, December 18, 2006

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 : / / / / / / /

2 comments:

James McGovern said...

In the lawyer example, paying a bill doesn't necessarily require granting access to a bank account. It could require though a simple mechanism in which your mother prepopulated information on the insurance web site and it is simply an entitlement based on relationship whether the lawyer can click pay now.

I think you are concluding that federated identity or even federated authorization still isn't ready to handle real business-oriented scenarios (except for really trivial stuff) and for folks attempting the hard stuff that they should sit back and wait.

Curious if Liberty has decided to keep in simple strictly in the short-term or have decided to avoid tackling any of the issues surrounding the business scenarios and deferred it to the indefinite future...

Conor P. Cahill said...

Clearly I was NOT speaking about federated identity (and I have no clue how you could somehow think I was). Federated Identity is a solved problem that is ready to handle real business *and* consumer oriented scenarios.

My point about the complexity in setting up remote authorization is a valid point and while you are speaking of federated authorization, you had my mother at her insurance web site (not some shared authorization point) to set a permission on that site -- that's what I call local authorization and the model that I think will be used for most application specific authorizations.

Your curiosity at the end is clearly done just to try to appear thoughtful and evoke responses rather than any knowledgeable interpretation of what I said. I don't speak for Liberty, but Liberty clearly has addressed many complex (as well as simple) business solutions.