We’re excited to announce the Beta release of Microsoft Code Name “Geneva” Framework. This framework is the successor to our previous beta release code named “Zermatt”.
This release, in addition to adding some new features, polishes up many of the existing features that were available in the previous Zermatt release. Our primary motivation for the changes was to simplify the developer experience and better align it with existing technologies. In this post we’re going to discuss some of the changes in this release. Future posts will talk about the features below in greater detail.
Before delving into the details of the framework, we’d first like to point out that the framework is part of a larger wave of products known as “Geneva.” If you haven’t already done so, please be sure to visit http://www.microsoft.com/geneva for more information.
The following document provides a detailed overview of all the changes that were made between the previous release and this release. However, for purposes of keeping this blog post reasonably short, we’ll give a high level overview of some of these changes.
The New Claims Model
This release (as with the previous release) introduces a new claims model. This new model combines the claims world with the IIdentity/IPrincipal world that developers are familiar with into one concept called the IClaimsIdentity/IClaimsPrincipal that is fully compatible with the IIdentity/IPrincipal world. Furthermore, we’ve also replaced ClaimsPrincipal.Current with Thread.CurrentPrincipal as the mechanism by which an application accesses claims about the caller.
In this release, we’ve changed the type of the issuer of a claim, Claim.Issuer, to string instead of a collection of claims to simplify handling, and make the issuer identification independent of the credential that is used to sign issued security tokens. To support the Claim.Issuer as string, we have added a translation mechanism that supports converting an issuer’s signing credential (usually an X.509 certificate) into an issuer’s name. This mechanism is implemented by the IssuerNameRegistry class and is fully extensible so that developers can provide their own implementation for this translation. The framework itself ships with a simple, configuration-based translation implementation.
We’ve also introduced a new data field holding the original issuer of a claim: Claim.OriginalIssuer. This is useful for claims that traverse through a federated chain.
One of the pain points with our previous Beta was with not knowing where to authenticate the set of claims representing the user. The concept of authenticating the user existed in multiple places and it was hard to figure out where such an operation should be performed. To address this, we’ve introduced an easy to use extensibility model called the ClaimsAuthenticationManager as the one place to do authentication.
Token Handling Improvements
In this release, we’ve expanded the role of TokenHandlers. If you recall from our previous Beta, TokenHandlers were only used for processing SAML1.1, and SAML2.0 tokens. In this release however, we’ve expanded this model for all token types, including Username/Password, X509Certificates, Kerberos, Secure Sessions in WCF (SCT’s), and HttpCookies. This makes the programming model simpler and more consistent.
Authentication Module Improvements
One of the more prominent changes that we’ve made is to our ASP.NET relying party (RP) processing pipeline. In the previous release, we implemented a single Federated Authentication Module (FAM) that did all the heavy lifting whenever a token arrived at an ASP.NET RP. In this release, we’ve broken up the FAM into a set of authentication modules, namely the SessionAuthenticationModule, the WSFederationAuthenticationModule, and the ClaimsPrincipalHttpModule. These independent modules all work together to make the processing pipeline easier to understand, and provide a much better compatibility story with ASP.NET’s FormsAuthentication and UrlAuthorization modules.
Security Token Service (STS) Pipeline Improvements
We’ve improved the pipeline around building Security Token Services. In addition we’ve also added better support for an asynchronous pipeline.
Federation Establishment with an STS
Wouldn’t it be nice if there were an easy way to establish a trust relationship between your application and the SecurityTokenService it receives security tokens from? We’ve now included a new tool called FedUtil.exe to make this process easier.
Geneva Token Service
In some federation scenarios, an existing application can be written to accept, for example, a SAML token, but may need to translate this to a Windows account.
The “Geneva” Token Service is a Windows NT service that gets installed as a part of the Geneva Framework. This service can translate the incoming SAML token into Windows identities that can be then used by your application to authorize the caller and to access other services using Windows authentication. With this Beta, whenever your STS issues you a SAML token that has a UPN claim in it, the Geneva Framework has functionality that will automatically convert this token into a WindowsToken for you.
ASP.Net control for Windows® CardSpace “Geneva” Beta
The “Geneva” framework continues to make it easier for developers to write an ASP.NET relying party that works seamlessly with Information Cards. Our Information Card SignIn control now exposes new properties, like Card Tile and RequireUserInteraction that work well with this new Beta version of Windows® CardSpace “Geneva”.
Give us your feedback!
Please give us your feedback and tell us what you think. The features described above provide just a glimpse of the changes that went into this release. We’ve tried hard to make the programming model simpler, and better aligned with some of the existing ASP.NET/WCF environments.
- The “Geneva” Framework Team