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
