Microsoft “Geneva” Framework

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 https://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.

Claims Authentication 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

Comments

• Anonymous
  November 03, 2008
  PingBack from http://mstechnews.info/2008/11/microsoft-%e2%80%9cgeneva%e2%80%9d-framework/
• Anonymous
  November 04, 2008
  We’re excited to tell you more about the beta release of “Geneva” Server. In this post we’ll talk a bit
• Anonymous
  November 13, 2008
    If you want your application to externalize user authentication to a Security Token Service (STS),
• Anonymous
  November 21, 2008
  In an earlier posts, Colin described how to handcraft a web page to implement the new CardTile feature
• Anonymous
  November 25, 2008
  For those who didn't attend PDC, the Zermatt identity framework has been re-code-named Geneva Framework
• Anonymous
  January 06, 2009
  What happened to the Claim.Right property that was in the System.IdentityModel? Are all claims assumed to be "possessed" in Genenva?
• Anonymous
  June 11, 2009
  How do you give IWSTrust13SyncContract another ProtectionLevel than the default ex. ProtectionLevel.Sign?
• Anonymous
  February 18, 2010
  Hello All,I am new to Microsoft technology. I have few doubts :1) How can I consume card space token in Java web application? Does Microsoft provides some library to help Java developers?2) How "Geneva Framework" know which Identity provider it can trust? Do we need to import some certificate or something else at "Geneva Framework"?Thanks