The Freak Parade

The face of Identity is changing, as I’ve discussed in agonizing depth in Part 1 and Part 2 of this monologue. So hurrah for the Identity Metasystem, Identity  Federation and all that swinging jazz, but now what? Well, if you’re in the business of designing and building software systems and you want your applications to be able to run with the jet set you’ll probably want to be thinking about how an application should go about implementing support for externalized authentication, claims based authorization and the like. In many cases you may also want to buy or build your own Identity Provider / STS so you can have the benefits of federated identity but still keep the keys to the castle inside your organization.

If you’re on the .NET Platform, and therefore on the Microsoft platform, you have a few options available to you.

Commercial Turn-Key Solutions

Although I’m only aware of one vendor in this space, Ping Identity, I imagine there are others. Buying a turnkey solution will probably offer the least touch, most expedient route to enabling new and existing applications with the capabilities to participate in the Identity Metasystem or any other identity system. I say turn-key, but of course some integration is required. Ping Identity offers products like Ping Federate, offer highly polished, low friction components that will allow your existing IT components to play ball with partners using any of a number of federation protocols (SAML 1.1, 2.0. + more) and they have .NET client and server libraries and even offer a free trial of their stuff. If you know what you want and just want to get started, I’d recommend looking there first.

Active Directory Federation Services (ADFS)

Active Directory Federation Services (ADFS) is a component that is part of Windows Server 2003, so it doesn’t add any cost. ADFS provides a framework on which you can build an STS that integrates Active Directory with external applications. I looked closely at this product at one point, and from my perspective it seemed a bit complex. Internet searches revealed that implementation of ADFS isn’t a proverbial walk in the park. As ADFS is going to be re-implemented using Microsoft’s latest and greatest identity platform called Zermatt, which I’ll talk about in a moment, you may way to hold your horses on a ADFS implementation.

WCF Claims Based Security - the System.IdentityModel Namespace

WCF has extensive support for claims based security built into it, and it is documented very well in many books and online articles, blog posts, etc. Claims based authorization in WCF (although not limited to WCF) is in the System.IdentityModel namespace. Unfortunately, however, it seems that Microsoft’s newest, shiniest identity effort (Zermatt) is not backwards compatible with System.IdentityModel. In the discussion forum on the Connect Web site for Zermatt they even called systems based on the WCF 3.0 model Legacy. So…I’m not sure building new applications using System.IdentityModel would be very future proof.

Zermatt = Identity.NET

Microsoft has released to public beta a brand new framework code named Zermatt. Zermatt is billed as providing the .NET component libraries required to easily add robust claims based authorization and interoperable identity federation capabilities to your .NET based software, as well as making it a boilerplate experience to put together a custom Security Token Service, which is really quite something. Building an STS has not historically been a simple undertaking on the MS Platform thus far. There is a very good white paper on Zermatt which goes into some depth about all of these topics that I highly recommend reading. The big downer, though, is that the Zermatt SDK won’t install on XP. It requires Vista or a Windows Server OS. However, the Zermatt SDK looks so enticing, and promises to deliver powerful digital identity management to our software with such little effort, that it may be the carrot that spurs us to upgrade our development environment from XP to Vista (or Server 2008). One way or the other Zermatt is the future for identity management on the Microsoft platform, so if you don’t take a look at it now, you’ll be taking a look eventually.

Information Cards (eg CardSpace)

I didn’t end up getting into this aspect of the identity puzzle, but one of the major issues with the current state of identity management is the proliferation of passwords and the general weakness of the username/password concept itself. Identity Selectors were invented to solve this problem, and provide a highly secure, certificate based approach to authentication that supports the claims based model and eliminates the need for using usernames and passwords entirely ( as long as all the systems you use accept cards ). Information Card’s (such as those provided by the CardSpace technology) can be issued by Identity Providers and accepted by Relying Parties. Alternatively, self issued Identity Card’s can be directly accepted by relying parties in lieu of a username/password. You can read about CardSpace here.

OpenID, OAuth

On the consumer end of things, OpenID provides an open standard that can be used by public facing web sites to allow users to centralize their identity management. Similar in concept to the original Windows Passport concept (you can still use Live ID, the Passport successor, if you like) Open ID and similar standards allow you to design your application to delegate authentication of users to third party servers who you elect to trust. This is a gift to your users because they can manage a much reduced quantity of digital identities, have one place to manage username / passwords and change them if they become compromised, and more or less maintain more control over their online information. OAuth is a similarly open standard for centralizing authorization to open APIs and other web services to allow applications to create mash-ups of users data without having to ask the user for credentials for each service they wish to use in the mashup. I don’t work on consumer software, so my knowledge of these technologies is limited, but if you are working on public facing software OpenID and OAuth are probably where you want to put the tip of the Identity chisel.

So there you have it folks. Let me know if I’ve forgotten any major pieces of the puzzle. There wasn’t room in this post for the list of links, so I’ll follow up shortly with those.