Z is for… Zermatt

Zermatt is, well actually was, the code name for Microsoft’s next generation identity and access management API.   Zermatt is now known by its new code name of “Geneva” Framework, but short of z-index, I was coming up empty on something to cover for this final post of my A-Z series – so let’s just call it poetic license. 

The “Geneva” Framework is just one part of this new claims-based identity platform, which also comprises “Geneva” Server and Windows CardSpace “Geneva”.  Its two primary goals are to simplify the single sign-on process within the enterprise and to enable existing systems to interoperate with new hosted services and service-oriented architecture implementations.

Let’s take a brief look at the three components, and then I’ll offer a number of links for further reference.

“Geneva” Server

“Geneva” Server is a Security Token Service (STS) that transforms claims into tokens.  Clear as mud? let’s take a step back to get a handle on what that means.

A claim is simply a piece of information about a specific identity (often a user), and it’s the assembly of one or more of these claims into a (security) token that drives the authentication model.  A claim could be someone’s name, their age, a password, or really any other piece of information that’s relevant to identifying valid users to a given application or computing environment.  Tokens are interpreted by the application to which the user is requesting access, and it’s up to that application (the “relying party” in the picture above) to decide whether it trusts the provider of the token and the claims it is making.

While the specific claims aren’t all that important, knowing those claims are accurate and valid is paramount, so the token (which contains the claims) is digitally signed by a trusted party to verify its source and guard against tampering.  The issuer of a signed token is referred to as a Security Token Service (STS), and the organization hosting the STS (the “trusted party”) is termed the identity provider – they are the ones attesting that the claims in the tokens they issue are valid.  In the Windows Live ID service, for instance, Microsoft is acting as the identity provider.

“Geneva” Server, which is the next generation of Microsoft’s Active Directory Federation Services (ADFS), implements just such a Security Token Service.   An organization could then choose “Geneva” Server to implement their own claims-based identity provider, built on Active Directory Domain Services, and act as an identity provider to applications within their enterprise or elsewhere.

Windows CardSpace “Geneva”

Cardspace “Geneva” is the user-focused component of the “Geneva” platform.  In the simplest of scenarios, a user would have one identity, managed by an STS like “Geneva” Server, and she’d request the STS to provide the claims associated with her identity to authenticate herself to every application. 

That’s a rather myopic view though.  Just as we have multiple identification facets in our physical lives (social security numbers, driver’s licenses, passports, etc.) that we use in different contexts, so do we have multiple digital identities that we use for different applications and services (think for instance of all of the various passwords you’re keeping track of now!)  My Facebook account, for instance, doesn’t need to know what my Blue Cross number is, but my on-line pharmacy probably does.

This is where the concept of an identity selector comes in.  When a user requests the services of an application, that application will forward a list of its needs – in terms of token types, claim requirements, and the identity providers it trusts.  The identity selector, here “Geneva” Cardspace, can review the requirements and present the user a list of the available identities (presented as Information Cards) that meet the authentication needs of the application.  The information card contains the information needed to locate the appropriate STS and obtain the requisite token; the card itself doesn’t store any claims or token information.

“Geneva” Cardspace also handles the user interface, so that there is a consistent experience across Windows applications relying on identity selection.  The interface presented to the user looks something like the following, with a link (“What information will be sent”) to provide more information on exactly what specific pieces of information (claims) will be sent to the relying party application.

“Geneva” Framework (previously “Zermatt”)

The “Geneva” Framework (my “Z” for this post) provides the programmatic interface for .NET developers to validate and consume claims in client applications (the “relying party” in the figure presented at the beginning of this post).  The .NET Framework 3.0 does include a few classes in System.IdentityModel.dll to do claims-based programming; however, the developer story wasn’t too compelling in terms of openness and ease of use.

At the forefront of the new framework (incorporated into Microsoft.IdentityModel.dll), is the Claim class, which contains several properties:

ClaimType

Typically a URI that indicates what the claim is.  This URI could be anything that your application and issuer can agree on.  In CardSpace, a user’s first name would have a ClaimType of https://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname 

Value and ValueType

Value indicates the value of the claim, such as “Jim” for a first name.  This is always a string value.  The ValueType property indicates the underlying XML schema type used to serialize and deserialize the value. There’s a number of predefined schema type strings you can use in the static class ClaimValueTypes; for instance, a date value would be serialized per https://www.w3.org/2001/XMLSchema#date

Properties

An IDictionary<string, string> of optional metadata related to the claim.

Issuer and OriginalIssuer

A name for the issuer (STS) of the claim.  In a federated scenario, where two or more issuers are involved, the Issuer is the last in the chain, and OriginalIssuer is the first in the chain.

Subject

An object implementing IClaimsIdentity that provides additional information about the user’s identity.  IClaimsIdentity extends the existing IIdentity interface, which provides only the name of the user.  IClaimsIdentity exposes a ClaimsCollection as well as a way to specify which claim corresponds to the user’s name and roles.

The “Geneva” Framework also exposes a IClaimsPrincipal interface, with a default implementation in ClaimsPrincipal.  IClaimsPrincipal extends the existing IPrincipal class to include a collection of IClaimsIdentities.  In most, cases there will be one item in this collection, but it does make it possible to support scenarios where the relying application requests multiple tokens from different issuers.

The addition of the new interfaces and enhancement of the Claims class does add a little more complexity, but given the extension of existing interfaces, you can access the claims information using the same constructs you’ve used before to get the user information, by accessing the Thread.CurrentPrincipal or User.Identity in an ASP.NET page.  For example,

 IClaimsIdentity claimsIdentity = 
    Thread.CurrentPrincipal.Identity as IClaimsIdentity;

The Microsoft Code Name "Geneva" Framework Whitepaper for Developers is a great source of information for using these classes within your applications. In fact, it’s interesting (and not too surprising) to note that “Geneva” Server actually uses the “Geneva” Framework itself to implement its own security token service.  If you’re concerned over all the infrastructure required to try all this out, you’ll be happy to know that if you download the Beta 2 release, there’s an option to get a pre-configured VPC to facilitate your evaluation.

One final point to note is that while these three components provide a solid infrastructure for claims-based identity, they do not form an all-or-nothing proposition.  “Geneva” is Microsoft’s implementation of standards-based technologies like WS-Trust and SAML 2.0.  You don’t have to use “Geneva” server to use CardSpace; in fact, you might not even need an identity selector for simple scenarios.  Likewise, applications built using the “Geneva” Framework can process claims served from sources other than “Geneva” Server.

References

MSDN Security Developer Center

“Geneva” Claims Based Access Platform (whitepapers)

“Geneva” Framework Whitepaper for Developers

“Geneva” Beta 2 Download

Channel 9: The Id Element

“Geneva” Team Blog