des on Federated Identity ... less is more » ADFS

“Geneva” SAML Interop … With a Lot of Help from Our Friends

Don Schmidt — Mon, 03 Nov 2008 03:53:15 +0000

Call me sentimental … but when I started to think about writing this post, I immediately flashed on that great Lennon and McCartney song, “With a Little Help from My Friends.” Read on and you’ll see why.

Response to the unveiling of “Geneva” at the PDC last week has been outstanding! If you thought all those blogs about the Identity Metasystem were just talk … this is Microsoft putting its money where its mouth is. Improvements over ADFS and CardSpace v1 are huge. The Microsoft Federated Identity server, framework and client teams have worked long and hard. Every one of them deserves a curtain call with a standing ovation. It was particularly heartwarming to see Pamela’s acknowledgement of the Federated Identity team’s labors and accomplishments.

“Geneva” comprises a rich claims-based access feature set that will deliver on much of the promise of the Identity Metasystem vision. I just want to focus on the SAML 2.0 protocol support in this article. In the hope of being able to submit “Geneva” Server to the Liberty Alliance interoperability testing program, Liberty Interoperable, we have targeted the IdP Lite and SP Lite Operational Modes from the SAML 2.0 Conformance Requirements specification, plus the GSA Profile which is referenced by many governments around the world. That is still a lot of functionality and we had to determine what customers really needed so we could prioritize our development process accordingly. Microsoft did not do this alone. We had a Lot of Help from Our Friends.

We have been working with customers and other vendors for over a year to determine what features of the SAML 2.0 protocol are most commonly deployed. They unanimously agreed that the Web SSO Profile is what matters most. Based on actual customer deployments – augmented by extensive consultation with experts from the Shibboleth community, and precious insights from other vendors, including IBM, Ping Identity, SAP and Sun Microsystems – the SAML 2.0 feature prioritization for “Geneva” Server looks like this (in descending order).

- Web SSO AuthnRequest : HTTP redirect
- Web SSO Response : HTTP POST
- Identity Provider Discovery : Cookie
- Web SSO Response : HTTP Artifact
- Artifact Resolution : SOAP
- Single Logout (IdP-initiated) : HTTP redirect
- Single Logout (SP-initiated) : HTTP redirect
- Enhanced Client/Proxy SSO : PAOS

Patrick Harding, from Ping Identity, provided a most eloquent confirmation of the “Geneva” plan.

Ping Identity has partnered with Microsoft on numerous federated identity initiatives over the last few years – from the early work on WS-Federation to the more recent Information Cards interoperability events. It was extremely gratifying to have Microsoft recognize Ping Identity’s market leading success with SAML 2.0 when they reached out to us to ensure that Microsoft’s SAML 2.0 Web SSO profile implementation in its upcoming products will successfully interoperate with PingFederate.

Microsoft’s support for SAML 2.0 is a watershed moment in the identity management industry as it now allows deployers to focus on the business value of Internet SSO rather than concerning themselves and their business partners with protocol choice. Microsoft’s decision to focus on the IdP Lite, SP Lite and eGov interoperability profiles for SAML 2.0 also matches Ping Identity’s expectations as to what is the minimum bar necessary for deployers to successfully leverage SAML 2.0. I am looking forward to continuing to work with Microsoft to solve the next set of issues that will allow us to further simplify the effort involved in establishing federated identity connections.

Congratulations to all at Microsoft who were involved in enabling SAML 2.0 in Geneva.

We are working our way down the SAML 2.0 feature list above As anyone who has ever developed software knows, code isn’t finished until you test it. And that meant testing “Geneva” Server to prove its interoperability with other implementations. Again, we got a Lot of Help from Our Friends. We owe a huge debt of gratitude to the Shibboleth community (Scott Cantor from The Ohio State University, and Jim Fox from the University of Washington, in particular), IBM (Tony Nadalin, Shane Weeden, Neil Readshaw) and Ping Identity (Patrick Harding, Tom Doyle, Pasha Beneson).

We would not have finished the “Geneva” beta in time for the PDC without this incredible outpouring of help from the community. On behalf of Microsoft I extend our heartfelt gratitude. I guess this shows that the Identity Metasystem is bringing people together, as well as technologies.

Microsoft “Geneva” Server Supports SAML 2.0

Don Schmidt — Tue, 28 Oct 2008 10:29:31 +0000

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.

New Diagnostic Tool for Active Directory Federation Services

Don Schmidt — Thu, 31 Jan 2008 04:10:54 +0000

Establishing a production federation between different organizations can be challenging. A successful federated connection depends on numerous configuration and policy details being setup correctly at both ends. If an application request fails, it can be difficult to track the failure back to an underlying configuration error, especially since an administrator at either partner only has access to half of the end-to-end system data.

Like most products Active Directory Federation Services provides trace logs to help solve these kinds of problems. However, as any seasoned sysadmin knows, a high-level application request can spawn a multitude of underlying protocol messages. Finding a single setup error by combing through the associated debug logs is tedious at best, and impossible if you do not know what to look for.

The ADFS Test Team has filled the gap with tooling to verify that the underlying federation infrastructure is setup correctly. They developed a new ADFS Diagnostics Tool that is available for free download on the web. Administrators at each end of an ADFS-based federation can run the tool, share the output files, and quickly pinpoint configuration problems at their security token services (STS). If ADFS is only used by the Relying Party partner in the federation, the tool can still be used to diagnose configuration problems between the STS and the application server. One of Microsoft’s premier support engineers has posted the tool and provided a space for customers to ask questions and provide feedback. He has high praise for how easy it is to perform low-level diagnostics of the complete distributed system.

The tool is very simple to use and provides a graphical UI. In order to perform distributed diagnosis, i.e. diagnose failures based on the configuration of multiple machines in the scenario, it’s necessary to copy the out file generated by the tool each time it’s run and use it as an input/output file when running the tool on the next machine.

For example, to debug a scenario with an FS at the account role (FS-A), an FS at the resource role (FS-R) and a Web Server (WS), first run the tool on the FS-A selecting a new file, say adfsdiag.out. After the tool is run, this file will now contain configuration information relative to the FS-A. Copy the file to the FS-R machine and run the tool there, this time selecting the existing adfsdiag.out file. The tool will detect it already contains information relative to other roles and will execute extra configuration checks, for example, a claim flow check that verifies the outgoing claims sent by the FS-A match the incoming claims expected by the FS-R. After this second run, adfsdiag.out will contain information relative to both the FS-A and FS-R. Finally, copy the out file to the WS machine and run the tool again following the same steps.

A number of large scale, production ADFS deployments came on line towards the end of last year. Many more are in the pipeline. This free tool has already proven to be priceless. Try it and see for yourself.

DIDW: A Claims Based Architecture for British Columbia

Don Schmidt — Fri, 28 Sep 2007 15:16:01 +0000

This session was delivered by Ian Bailey (Director of Application Architecture, Office of the CIO, Provence of British Columbia, Canada) at Digital ID World in San Francisco. A compelling session in its own right, it was also the coming out party for the BC Identity Management Architecture Project.

The provincial government leadership has taken a bold step to provide better outcomes for BC citizens through the use of online services and advanced identity management technology, such as Information Cards. They organized a working group of government agencies and vendors to define an architecture that will enable critical, online access to services provided by the government and the broader public sector, while protecting the privacy of BC citizens. The website spells out the scope and vision of the project.

The Office of the Chief Information Officer (OCIO) for the Province of British Columbia, with the advice and counsel of an executive committee of Broader Public Sector (BPS) Chief Information Officer’s (or equivalent), and key industry leaders have collaborated to develop an architecture that would enable an identity management service for the government and the BC BPS.

The goal of this project is to develop an identity management architecture to enable interoperation across a diverse range of public sector organizations and their service providers using multiple vendors’ technology solutions.

I have had the privilege to participate in this project. It has been an exhilirating experience to work with peers from so many BC government agencies and leading vendors in the identity management space. In addition to Ian, I especially want to congratulate Dave Nikolejsin (CIO) and Peter Watkins (Executive Director, Office of the CIO) for their vision and energy. And I want to thank Dick Hardt (CEO, Sxip Identity) for leading us in the development of a Claims Based Identity Management Architecture that I personally believe will become a model for governments and the broader public sector everywhere. This quote from the introduction of the Architecture Document should explain my enthusiasm.

Over the past three decades, the British Columbia Provincial Government and Broader Public Sector (BPS) organizations have invested heavily in the automation of business processes. Much of this investment has taken place only to meet a single organization’s unique local needs. It was usually done with limited consideration towards building interoperable cross-organizational information architecture.

To achieve the broader goals of the Province and improve service delivery, a mechanism must be created to securely share information between organizations and systems. An important piece of this mechanism is the development of common cross-organizational standards for interoperable identity management.

This is a complex issue to resolve when one considers the spectrum of public and private sector stakeholders involved: policy, management and administrative issues; privacy and security requirements for the management of access to information; and the various technologies in place. Compounding this architectural challenge is the fact that the Information Technology industry does not have an inclusive “off the shelf” solution. This project will require the British Columbia public sector to work with industry to build upon existing international standards in the development of a business and technology architecture to meet the secure information sharing needs of the BPS.

There is so much more I would like to share with you about this project. It is a profound endorsement of the industry wide convergence on Information Card technology and the underlying WS-* protocols and web services architecture. However, I have to catch another plane. So let me leave you with the knowledge that the BC government has also announced that they are taking the next step and moving the Identity Management Architecture Project from concept to reality. In his session, Ian described a pilot project that is expected to get underway this year.

“Understanding WS-Federation” White Paper Published

Don Schmidt — Thu, 31 May 2007 07:43:02 +0000

Yesterday a White Paper, Understanding WS-Federation, was jointly published by IBM and Microsoft. The primary goal of this paper is to promote an appreciation for the functional scope of the revised publication of WS-Federation. As I have stated in previous posts, the scope of this specification extends far beyond the features delivered in first generation WS-Federation products, such as, Active Directory Federation Services v1.

The paper includes two use cases, an Enterprise “request for proposal” scenario and a Healthcare “emergency room treatment” scenario, that highlight key new features of WS-Federation 1.1. Textual descriptions of the scenarios are annotated with sample XML message flows.

Another goal of this paper is to encourage participation in the OASIS WSFED TC. Hopefully WS-Federation supporters and critics, alike, will find functionality that they care about, and be wiling to join in the open standards process for WS-Federation 1.1.