Of Claims and Public Identities

I remember sitting in a session delivered a few years ago by Kim Cameron, in which I heard for the first time about ‘the laws of identity’, and I was hooked immediately. I find the topic of identity very interesting and important, and too often looked over.

The cloud often bring this into the conversation and often I find people surprised how comprehensive the Microsoft story around identity is and how powerful the ACS is. I’ve discussed an aspect of this – the ability to federate with the ‘big boys’ – Windows Live ID, Yahoo, Google and Facebook in my previous post.

In his talk, Kim listed 7 ‘laws’ –

1. User Control and Consent
2. Minimal Disclosure for Constrained Use
3. Justifiable Parties
4. Directed Identity
5. Pluralism of Operators and Technologies
6. Human Integration
7. Consistent Experience Across Contexts

You can read about them here.

In my post I mentioned that the application developer could leverage the ACS to authenticate the user without having to write authentication code, worry about storing username and password, implementing password reset, etc., but suggested the developer would still need to implement a registration screen to get any information that is required about the user and manage a local profile.

This is due to the second law – an identity provider should, in most cases, and certainly in the case of a provider outside the organisation, only disclose the user’s identity, and nothing else. all that’s needed is for someone to say – ‘yep – this user is X as far as I can tell’,

To understand why this is important, consider the difference between these two examples –

When using Windows Live ID as the identity provider, the calling web site (the Relying Party, or RP), receives back a token with two claims – the identity provider (“uri:WindowsLiveID”) and the name identifier (in the Windows Live ID case – a GUID). no personal details are shared, nothing that can be used to hack the account.

The web site is then expected to have details stored against those two facts, which the user had given directly to the web site, as it should be according to the 1st law, and if the web site does not have any such details, it should ask the user directly, and the user – now knowing exactly who is getting these details, can make a conscious call as to whether to share them or not.

In contrast, consider Google’s identity provider – this returns four claims – the identity provider (‘Google’) and the name identifier (a link with a unique identifier in it), similar to Windows Live ID, but also the user’s friendly name (‘Yossi Dahan’ in my case) and email address (‘my gmail address used to sign-in to Google). these are two pieces of information I did not necessarily wish to share with the web site, but they were shared without me realising it (until I debugged the code, that is).

Now – it is true that as a user I needed to first proactively go to the website, and then when got redirected to the Google sign-in page I had to agree for details to be shared, so it’s not exactly horrible, but it does demonstrate the point that identity providers should really provide very little detail and that web site developers, whilst they don’t have to worry about authentication, should really manage user profiles independently and handle user registration against those identities.

Using Access Control Service for Identity Federation

The Windows Azure Platform is full of goodies. Some are at the heart of the conversation – Web Roles, Worker Roles, SQL Azure, the fabric controller – these form a part of pretty much every conversation. Some are often mentioned, but usually in very little detail – the Marketplace, for example, or the Service Bus or the Caching capabilities.

Another topic I find that I often end up glossing over in conversations is the Access Control Service, not because it’s not useful or important, it is, simply because the platform is so big, and there’s only so much one can discuss in any one conversation, but federated identity is something I’m quite passionate about, and I just love the Windows Identity Foundation, so the Access Control Service is bound to be something close to my heart.

The Access Control Service is seemingly a fairly simple offering – on it’s own, in most circumstances, it does not really do much per-se, but, coupled with the Windows Identity Foundation and the .net framework, it enables federated identity scenarios (think single-sign on within, as well as across, organizations) easily, reliably and securely.

Using ACS, you can take any web application and, in just a few clicks, allow users to authenticate to it using all the major public identity providers (Windows Live ID, Yahoo, Google and Facebook) as well as, if you have ADFS, your corporate identity, or – if you need to – any other custom Secure Token Service that supports industry standards.

Want a proof? take a look at this walk through that shows how to enable a web site to use Google ID.

As a developer, ACS takes away the need to build authentication mechanism, store passwords, build password reset capabilities and all of that, you can simply leverage other identity providers. all that’s left for you to do is to enhance the given with your own profile information (as some of these provider will only give you a GUID for that user, no personal information is shared, which is a good thing!)

So – using the ACS can be a great relief for anyone building a public web site as it saves you a lot of work and your users the need to remember yet another set of credentials, but the support for ADFS means you can also protect your web assets with your corporate identity, no matter where they are deployed (your data centre, someone else’s data centre or the public cloud) and also – considering the Consumerization of IT trend – allowing users access to enterprise applications using external identities in a managed way may not be a bad thing.