At the Professional Developers Conference this week Microsoft is announcing the beta release of “Geneva”, the codename for its new claims based access platform.  This platform helps developers and IT professionals simplify user access to applications and other systems with an open claims-based model.  “Geneva” helps developers to externalize user authentication and identity processing from application code by using claims that are obtained with pre-built security logic that is integrated with .NET tools.  “Geneva” helps IT professionals to efficiently deploy and manage new applications by reducing user account management, promoting a consistent security model, and facilitating seamless collaboration across departmental, organizational and vendor boundaries.  User access benefits include shortened provisioning lead times, reduced accounts, passwords and logins, and enhanced privacy support.  “Geneva” implements the Identity Metasystem vision for open and interoperable identity, and includes built-in support for standard federated identity protocols.

A fundamental goal of “Geneva” is to extend the reach of its predecessor, Active Directory Federation Services, and provide a common identity programming model for developers of both web applications and web services.  To maximize interoperability with clients and servers from other vendors, it supports the WS-Trust, WS-Federation and SAML 2.0 protocols.  To maximize administrative efficiency “Geneva” automates federation trust configuration and management using the new harmonized federation metadata format (based on SAML 2.0 metadata) that was recently adopted by the WSFED TC.

WS-Trust is provided to support Information Card based Identity Selectors from third parties, as well as Windows CardSpace.  WS-Federation is required to maintain interoperability with existing federations being operated by government agencies, military organizations and business enterprises around the world.  “Geneva” support for SAML 2.0 was added in direct response to customer requests for increased cross-platform interoperability.  The benefits that are expected to accrue to customers, and the industry at large, are best summarized by Scott Cantor who is one of the key contributors to the SAML 2.0 standard and a Senior Systems Developer at the Ohio State University.

As a Shibboleth and OpenSAML project developer, and a deployer of the Shibboleth software at The Ohio State University, I’m excited and gratified that Microsoft is implementing the SAML 2.0 Web SSO profile in its upcoming products. Throughout the life of the Shibboleth project, and my work on the SAML 2.0 standard, our goal has been to leverage open standards to foster broad interoperability in federated identity within the higher education community and between it and its many commercial and non-commercial partners. Microsoft is clearly one of those critical partners, and as a key technology supplier, its support for the SAML standard reflects an understanding of our community’s needs and goals, and will expand the scope and impact of our efforts.

Our users will benefit by obtaining access to the broadest potential set of federated applications and services, and our worldwide community will benefit from the opportunity to deploy Microsoft’s identity solutions with the knowledge that they will interoperate with Shibboleth. Microsoft’s willingness to listen to our requirements and suggestions demonstrates a commitment to real-world compatibility. I look forward to continuing the dialog with Microsoft as we drive further interoperability in the use of federation metadata to scale and simplify both SAML 2.0 and WS-Federation deployments.

 

The fundamental purpose of federated identity is to enable subjects to use identities managed in one realm to gain authorized access to resources managed in other realms.  Requests to access resources are authenticated and authorized by the exchange of security tokens and the claims they contain.  Before seamless federated access can be granted, Identity Providers and Service Providers must configure their servers to agree on the types of tokens and claims that will be exchanged, and the keys that will be used to sign and encrypt them.  This configuration data is generically referred to as “federation metadata”; early implementations required this metadata to be manually entered on both sides of the relationship, which can be extremely error prone due to the lengthy URIs involved. 

A huge improvement in administrative efficiency can be gained by automating this configuration.  The key to automation is enabling IPs and SPs to publish their federation metadata in a standard format which can be exchanged between potential partners.  The Shibboleth community has demonstrated the effectiveness of this approach.  The SAML 2.0 standard includes the Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 specification [Samlv2Meta] that is devoted to standardization of a federation metadata format.

Federation metadata has also been a critical component of the WS-Federation specification that was submitted to OASIS.  A key goal has been to develop a single specification that can support both passive web application and active web service requestors.  In the interests of promoting engineering efficiencies for developers, and interoperability enhancements for deployers, the WSFED TC decided to make a substantive change to its federation metadata document structure during the first Public Review cycle.  WS-Federation has been revised to take a normative dependency on the SAML 2.0 federation metadata document structure.  The original format has been deprecated, although it is supported for backwards compatibility with early implementations.  The preferred format must be rooted in either the <md:EntityDescriptor> element or <md:EntitiesDescriptor> element from [Samlv2Meta].  The WS-Federation specification defines extensions for web services constructs (such as Endpoint References) that are required for WS-* protocols.

This work could not have been accomplished without the help of numerous SAML experts.  In particular I would personally like to thank Scott Cantor, Bob Morgan and Steven Carmody from the Shibboleth community, and Eve Maler and Pat Patterson from Sun Microsystems.  I believe this joint effort will significantly improve interoperability and reduce cost of ownership for enterprise class customers who typically deploy products from multiple vendors.  The harmonization dialogue between the WS-* and SAML communities has begun.  We can expect more to come.