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

Federated Authorization

Last week, James McGovern posted comments on a number of blogs trying to stir up some conversation around the concept of federated authorization. There were several responses including one from Pat, Paul, Pat again, Gerald, and myself.

The comment was simply:

Does Federated Identity sometimes require Federated Authorization? Would be a great topic for your next blog entry...

A seemingly simple question. James followed up with his own post making it look like we were responding to some article he wrote on his blog and claiming he already new the answer to that question, but what he really meant was:

The perspective that I was actually seeking wasn't the architecture viewpoint but more of why industry thought leaders aren't talking about authorization and the over-abuse of the term identity management as a catch-all term and how these two problem spaces should become coupled in terms of the conversation.

I'm not sure how anybody could have gotten that out of the question above.

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).

I think that is a common model and I don't see companies giving up the rights to authorization to foreign entities.

That said, I do see the value and benefit of having support for an remote authorization service, especially in an environment where there are many customers with many different levels of authorization at many service endpoints. The diagram below is from a presentation I made in October of 2005 at a Liberty Alliance workshop in Tokyo, Japan.

The issues around setting this model up are non-trivial. Essentially you need to be able to, on a service-by-service basis, define a set of knobs controlling access rights to each service and the valid range for those knobs (for example, an internet radio service might have knobs controlling the number of stations that are available to the user, the quality of those stations, and the number of endpoints from which they may listen simultaneously).

This type of model allows separation of the package definition (a sales/marketing issue) from the implementation of the service access (a development issue). The sales team can change packages fairly easily without impacting the development team (unless, of course, they need a new knob). This does put a lot of onus on the design of the knobs such that they allow the sales team to develop the appropriate service packages, but it's a big win when done correctly.

In an enterprise, this solution will present the same set of issues that come up with any RBAC implementation - the multitude of roles that need to be managed and the individual approvals necessary to allow the addition of access rights to a particular service within the enterprise. I think it's still doable with the knobs/settings paradigm, but given the "need to know" controls necessary for the privacy of employees and the protection of corporate trade secrets, the result is a vast multitude of yes/no knobs.

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

Federated Identity and Federated Authorization

I guess James McGovern got his wish via his multi-posted this comment across a number of blogs (Paul, Pat and Eve's in addition to mine):

Does Federated Identity sometimes require Federated Authorization? Would be a great topic for your next blog entry...

At first I had thought I was the only such person (that I was special in some way) and I had started working on an article around this subject, but alas that wasn't the case - this was just a SPAM comment sent out in a shotgun approach probably to even more people than I mentioned above. However, it did raise an interesting question.

Pat first responded with a nice summary of two models for authorization.

Paul later responded with a nice article talking about the P*P entities (although I had thought it was XACML that had popularized the P*P, not SAML).

While I like both of their answers and don't disagree with their content, neither of them explicitly answered the question (I think they did implicitly, but not explicitly).

So, I'll jump in there and say that the short answer to the question posed is "No". Federated identity never requires Federated Authorization. A resource owner may require remote policy decisions (which is what I would call federated authorization and fits into Pat's 2nd model) or they may simply require federated attributes (sometimes just an identity handle for the user). It's all an implementation decision for the owner of the resource that's being accessed.

That said, I would say that the reverse is true: Federated authorization does require some level of federated identity (the authorization statement is a piece of identity that is passing across to the relying party).

Tags : identity / federation / authorization / saml / xacml