In-Depth

The New .NET Identity Class

Simplifying identity with Microsoft's 'Zermatt' class libraries.

• By Keith Brown
• August 15, 2008

Responsibility for implementing authentication, authorization, auditing and personalization into applications has traditionally belonged to Web developers, even though they often lack security expertise and training. Consequently, each application often ends up with its own plumbing for authentication, usually accompanied by a private user account database or directory that stores names and passwords for users. As a result, provisioning and maintaining these databases is expensive, and users are burdened with accessing numerous systems.

Microsoft's answer to this problem came last month when the company released the first beta of a set of class libraries code-named "Zermatt." Zermatt is a new identity framework from Microsoft-packaged as a .NET version 3.5 library-that makes it easy for Web developers to adopt a claims-based approach to identity.

Introducing Identity Providers
A central tenet of this identity model is that each application should not be doing its own authentication; rather, the application should rely on an external system-an identity provider-to gather identity attributes about the user and supply claims to the application that are directly useful. These claims are packaged in a security token that's digitally signed by the identity provider. Claims could include personalization details such as the user's first and last name or an e-mail address, enabling the application to send e-mail notifications to the user. Claims can also include authorization details such as groups, roles or capabilities. Claims are essentially name-value pairs, and as long as the application and its identity provider agree on what each claim means, the content of a claim can be as sophisticated as needed.

Offloading authentication into an identity provider leads to many benefits for applications. The identity provider can be written and maintained by an individual or a team with intimate knowledge of the central user stores. Because queries to enterprise directories are now centralized in an identity provider, they can be easily optimized for performance, and it's much less likely that mistakes will be made. Any bugs in this identity logic can be fixed in one place, and all applications that rely on the identity provider immediately reap the benefits.

[click image for larger view]

Zermatt works with both browser-based Web apps and Windows Communication Foundation services.

An identity provider hides complications; for example, user e-mail addresses may be stored in an enterprise directory, while user roles are stored in a SQL database. Application developers are no longer responsible for figuring out where to get identity attributes for users, or for learning the myriad of APIs required to gather those attributes. Upgrading applications to use stronger authentication no longer requires touching each individual application; only the identity provider needs to be changed. And single-sign on is a natural outcome, as the user is logging into a central identity provider in order to access a group of applications. This means less individual passwords or other credentials for the user to manage.

Federation Protocols
Zermatt uses standard protocols such as WS-Trust and WS-Federation to transmit claims from the identity provider to the apps that rely on those claims, also known as relying parties. This leads to two benefits. The first is that it now becomes possible to buy an identity provider off the shelf instead of requiring the developer to build one. Microsoft's upcoming version of Active Directory Federation Services (ADFS) is one example. Secondly, it becomes possible to have one identity provider federate with another using these standard protocols.

Federation is useful when you have users in one security realm, organization or platform who need to use applications in a different security realm, organization or platform. For example, when two companies partner together, it's often useful to have users from company A have access to Web applications supplied by company B. By federating identity, company B doesn't need to provision user accounts for users from company A. Instead, B relies on A to authenticate its own users and relies on claims from A to make security and personalization decisions. Federation simply automates an existing covenant that two companies have established, and this automation allows the relying party to get up-to-date identity details about users instead of maintaining its own user database, which over time will become stale.

When Alice quits company A, when does company B get notified to disable her user account? With federation, there's no user account at B to be disabled, and B never has to worry about this latency. Federation is also useful in cases when companies merge, particularly where the enterprises are based on entirely different platforms; for example, Java and Microsoft .NET. If both sides are using claims-based identity, they can simply federate their identity providers, and now users in the Java world have single-sign on access to applications, regardless of platform. By building Web applications and services with Zermatt's claims-based model, those systems will be ready for federation should the need arise.