Saturday, December 09, 2006


More Thoughts on Federated Authorization

Federated Identity sometimes requires Federated Authorization. A continuing discussion on what industry thought leaders aren't talking about...

The integrity and openness of Sun employees such as Pat Patterson is something that other software vendors should aspire to. In a recent blog entry on Federated Authorization he provides a scenario as to how it may conceptually work but also how Sun uses it for their own benefit. He also mentions the SAML standard and how SAML 2.0 profile supports XACML 2.0 and the simple fact that he is not aware of any commercial products that actually implement it. Maybe this is an opportunity for Sun to show some industry leadership by helping to converge authentication and authorization in a standards based way. Hopefully, industry analysts that cover this space are listening.

I wonder what the folks from Sun thing of Rajiv Gupta's (CEO of Securent) and his comments on the conversation around identity management. I was be happy if Pat also responded to him and hopefully engaged in a meaningful dialog in the blogosphere we could all observe. Anyway, I am of the belief that there are other scenarios in terms of federated authorization that should be discussed and therefore lets jump into some additional examples...

Let's say that I am an employee of the insurance giant AIG and Hank Greenberg just hired me to be King of IT and wants me to address some of the security problems that are frequently mentioned by our customers. There are two customers in particular whom we really want to focus our efforts on: Marsh and Aon where I want to expose my systems to them via both portals and service-oriented ways. Of course I would love to declare not only support for identity via SAML and WS-Federation but would also like to make the authorization models consistent between them. I would like to say that regardless of whether you use a portal or a web service, if you are from Marsh and you have been authorized by Marsh to perform quotes (more on this later) then both my Portal and ESB will behave exactly the same from a security perspective.

The notion of performing quotes in this scenario goes beyond simple name-value pair constructs and needs to take into consideration business information only known by Marsh. Since the law requires that the individual performing the quote have a license, I minimally need to understand this. I also understand that each and every state has their own licensing procedure and that every individual may not be licensed by every state. I also understand that even if I am licensed on a state by state basis, it may still restrict me from selling certain products. So, I may be licensed to sell personal insurance (e.g. Auto and Homeowners) in the State of Kentucky while I may not be allowed to sell this in the state of Kansas but can sell Life insurance.

So now that we got the business scenario out of the way, let ask ourselves some questions:

Anyway, are these scenarios by any means a complete listing of what would truly add value to a enterprise and move identity management out of the compliance space into the business enablement space and provide real business value. In a future blog entry, I will expand upon the enterprise perspective by also incorporating consumer-oriented requirements not yet discussed in hopes that I could get folks at Microsoft to incorporate some of the thinking into Cardspace 2.0. It would be great to get the thoughts of Shekhar Jha, Johannes Ernst, Ash Motiwala, Bob Blakley, Chad Brown, Chris Ceppi, Dick Hardt, Jeff Katz, John Madelin, Justin Peavey and Josh Bregman to jump in on this important topic.

Anyway, I am glad that we are not only talking about successes but are able to openly reflect on where we need to go in the future and are game to tune accordingly. Hopefully, this posting will not result in a one-off response but that a larger dialog can occur.

<< Home
| | View blog reactions

This page is powered by Blogger. Isn't yours?