What's the purpose of claims-based authorization?

Question

I've been reading about Azure's Access Control Service and claims-based authorization in general for a while now, and for whatever reason, I still don't see the rationale behind moving from role/permission-based authorization to a claims-based model. The models seem similar to me (and they probably are), except that the list of what the client can and can't do comes from a third party and is wrapped up in some sort of token, instead of from some sort of database that the server has to query. What's the advantage of getting a third party (the token issuer) involved?

I fully understand the advantages of outsourcing authentication to a third party. It allows apps to not have to create new users all the time, worry about storing passwords, etc. when they can just push that off to some other service that already has the infrastructure set up. It's essentially the DRY principle for authentication.

However, in my mind, that same logic doesn't work for authorization. Each app has its own resources it has to protect, and therefore its own rules for authorizing users to perform certain actions. The infrastructure seems simple enough that each app could create it on its own (a table mapping users to roles, and possibly another mapping roles to permissions), and even if you wanted to outsource it, it seems that the claims-based model is doing something more complicated than that.

The only partial explanation I've seen comes from Building a Claims-Based Security Model in WCF, and it gives two main advantages to claims-based auth: more flexibility, and someone to "vouch" that the information in a claim is correct. When would you need either of those?

Claims-based authorization seems to be gaining popularity, so I assume there must be some good rationale for it; I just haven't figured out what that is yet. Can someone please provide a concrete example of a situation where claims-based auth works better than role-based, and why it works better in that case?

(EDIT: I missed a third benefit listed in the article: supporting single sign-on/federation. But doesn't authentication deal with that on its own without getting authorization involved?)

Answer 1

I guess the main promise of a benefit from federated security / claims-based system would be one fewer area you have to deal with different systems.

Imagine a site where you have local users authenticating with Windows credentials, a bunch of internet users using username/password, others using certificates, and maybe another group of users with biometric authentication.

In today's system, you have to set up and deal with all different kinds of authentication schemes and their different ways of doing things. That can get pretty messy.

The promise of a federated security solution would be to handle all those chores for you - the STS (security token server) would handle all different kinds of authentication systems for you, and present to you a uniform and trusted set of claims about a caller - no matter from where and on which path he's arriving at your site.

Of course, just examining and reacting to a single set of claims rather than having to understand four, five, ten different and disparate authentication systems looks like a really compelling promise to me!