AuthA, B, C…no, no…AuthN & AuthZ – yeah, that’s it!

So in a previous post, I said:

I want the authentication of YOUR users accessing MY data, to be as credible as the authentication of YOUR users accessing YOUR data.

And this is ABSOLUTELY true.  But I ONLY want the authentication portion…please, authenticate the user against your identity store, but let’s just stop there.  Is there really any need to stuff his token full of claims?  After all, claims are for AUTHORIZATION, and have nothing to do with AUTHENTICATION.  Presence of a valid token indicates authN.

So why do I want to separate authN from authZ?  Because in my opinion:

Authentication needs to be performed by the party who has the most credible source of the users digital identity.

Authorization though, has nothing to do with the user.  Authorization is all about the data which is being protected.  Therefore, the source of the authorization, is the owner of the data.

This is where claims based systems get interesting today, because the ideas they are based on were largely formed for the “user-centric” identity metasystem…or, to say it another way…the consumer market.  Putting the authorization data into the authentication token makes sense when it’s the users data.  For example, if I’m putting my personal data into a web 2.0 application, then that is still my data.

But what about when the data doesn’t belong to the user (or even the users enterprise) who is accessing it?  For example, Microsoft hosts a DMZ network to provide business partners with access to our data.  Do we want to allow our partners to start deciding which data they get access to?  Probably not.

So as enterprise federation continues to gain traction, it’s time to start exploring what’s required for the authentication to come from the partner, while still allowing the enterprise applications to own the authorization to their own data.

More to come on this…