Microsoft has published the first of a series of step-by-step guides on configuring AD FS 2.0 to interoperate with partner products. This guide describes how to configure AD FS 2.0 and CA Federation Manager r12.1 to federate using the SAML 2.0 protocol. The guide is available in HTML and Word format. Thanks go to author Dave Martinez for his expert and detailed treatment of the topic.
Category: Interoperability Page 2 of 3
Today Microsoft released a Community Technology Preview (CTP) of software for issuing Information Cards that works with the recently released Active Directory Federation Services (AD FS) 2.0 server software. This means that as well as supporting identities using WS-Federation and SAML 2.0, people can try out scenarios where their identities are based on Active Directory, AD FS 2.0 provides the claims for them using WS-Trust, and cards using the AD FS 2.0 WS-Trust endpoints are issued using the CTP.
As well as working with the current CardSpace 2.0 beta, these cards work with CardSpace 1, which shipped with Windows 7 and Windows Vista and is available for download on Windows XP. They should also work with other identity selectors, both on Windows and on other platforms.
You can ask questions about this at ici-ctp@microsoft.com or by participating in the CardSpace forum.
Active Directory Federation Services (AD FS) 2.0 shipped today. In addition to supporting WS-Federation, as the first version did, this release also supports the SAML 2.0 and WS-Trust protocols.
At this milestone, I’d like to thank the numerous partners who did extensive interop testing with us as AD FS 2.0 was being developed, helping ensure that it works well with other’s products. Milestones along the way included early interop testing with Shibboleth, IBM, and Ping Identity during Beta 1, interop work with CA, Novell, and Sun during Beta 2, the Federation Interop at Catalyst in July 2009, the Liberty Alliance SAML 2.0 testing last summer, and the OASIS IMI interop at RSA in March. Plus, we’re grateful to the numerous customers who test-drove and gave us invaluable feedback on AD FS 2.0 and the other “Geneva” wave products as they were being developed. This release is far stronger because of all of your contributions!
On Monday, OASIS announced the commencement of the 60-day public review period for the SAML V1.1 Information Card Token Profile Version 1.0 and the SAML V2.0 Information Card Token Profile Version 1.0 specifications. These specs propose standard profiles for SAML 1.1 and SAML 2.0 tokens when used with the Identity Metasystem Interoperability Version 1.0 (IMI 1.0) specification for Information Cards.
Special thanks go to Scott Cantor and the OASIS Security Services (SAML) TC for driving the creation of these profiles. You can provide feedback to the IMI TC on these specifications at this page.
This morning at the RSA conference, Scott Charney announced that Microsoft has licensed the U-Prove technology under the Open Specification Promise and released sample implementations in C# and Java under the BSD license. Implementers will be interested in two specifications: the “U-Prove Cryptographic Specification V1.0”, which documents U-Prove’s cryptographic operations, and “U-Prove Technology Integration into the Identity Metasystem V1.0”, which documents how to use U-Prove tokens with WS-Trust. These specifications are intended to enable interoperable implementations.
The U-Prove technologies enable two key properties: minimal disclosure and unlinkability. For more about U-Prove and today’s Community Technology Preview (CTP) release, see the Microsoft U-Prove site, the post announcing the release, and Vittorio’s post (with links to videos).
Today Microsoft announced the availability of new releases of several identity products: Active Directory Federation Services (AD FS) 2.0, the Windows Identity Foundation, and CardSpace 2 (which collectively were formerly referred to as “Geneva“), as well as Federation Extensions for SharePoint. See Announcing the AD FS 2.0 Release Candidate and More and Announcing WIF support for Windows Server 2003 for the release announcements as well as links to numerous step-by-step guides, samples, docs, and video. Thanks to all those who did interop work with us (including at Catalyst, Liberty, and pair-wise) to help ensure that these releases will work well with other’s implementations.
I’m pleased to report that Microsoft passed the Liberty SAML 2.0 interoperability tests that it participated in, as did fellow participants Entrust, IBM, Novell, Ping Identity, SAP, and Siemens. Testing is an involved process, as you can read about on the team blog, with numerous tests covering different protocol aspects and scenarios, which are run “full-matrix” with all other participants. Microsoft participated in the IdP Lite, SP Lite, and eGov conformance modes, which our customers told us were important to them.
As Roger Sullivan reported in the Liberty press release, this round of testing included more vendors than ever before. Related to this, I was pleased that Microsoft decided to let other vendors know up front that it would be participating. (Typically vendors don’t say anything about their participation until there’s an announcement that they’ve passed.) This openness enabled me to personally reach out to others with SAML 2.0 implementations, many of whom did choose to participate (and of course who might have also done so without my encouragement to join the party!).
For more about this accomplishment, see John Fontana’s ComputerWorld story, the Interoperability @ Microsoft blog, Vittorio’s blog, and the full test results.
CA and Microsoft have published a whitepaper describing interop work the two companies have done between their identity products, ensuring that they work well together. SiteMinder and CA Federation Manager from CA and Active Directory Federation Services (AD FS) 2.0 and Windows Identity Foundation from Microsoft were the products tested. The interop work covered both the SAML 2.0 protocol and the WS-Federation protocol, with each companies’ products configured in both Identity Provider and Relying Party roles. For instance, one scenario tested was using using a CA-hosted identity to access a SharePoint 2007 installation via the Windows Identity Foundation using the WS-Federation protocol. You can download the whitepaper either from CA or from Microsoft.
I’d like to thank Dave Martinez for all the expert work he put into getting this done, which included configuring products, running tests, doing the writing, and herding cats! I’d also like to extend my sincere thanks to Wes Dunnington, Mark Palmer, and Jeff Broberg of CA, who have been exemplary and diligent partners throughout this effort, rolling up your sleeves and working closely with your Microsoft counterparts to diagnose issues that arose, until we demonstrated all the scenarios working.
I’ll close by quoting a note that Wes sent to both teams upon the successful conclusion of our work together:
We are truly happy that this joint effort has resulted in the successful interop between our two products. This kind of work is crucial to get more and more businesses to adopt standards based solutions as they start to reach across the Internet for their application needs.
I couldn’t agree more!
Many of us share a vision of an Internet where people can have authorities that they trust make verified claims about themselves in contexts that they choose. For instance, using an identity that can issue “age-18-or-over” or “age-21-or-over” claims for me may enable me to utilize services at a site accepting those claims from that issuer that might otherwise be closed to me. More specialized interoperable verified claims, such as “coppa-certified-adult”, are also possible, and may open other doors for me. Before another month goes by, I wanted to draw attention to two new Information Cards that have been issued that represent progress in making this vision for interoperable verified claims a reality.
Privacy Vaults Online (a.k.a. Privo) launched a Privo parent card that can make the claim that the person has been certified as an adult using a method that satisfies the US COPPA regulations. Indeed, this is the “coppa-certified-adult” claim referenced above, and is defined in the ICF Claims Catalog so that others can use it as well. The Privo card also broke new ground in utilizing a “verification-method” claim, so that the relying party can tell how the information was verified, and the “verified-claims” method, so the relying party can tell which claims were verified. It also offers the same “age-18-or-over” claim that the Equifax card does. See the press release for more information, including sites where you can use your Privo card.
Acxiom issued the Acxiom Identity Card, which a person can use to make verified name and address claims about them self online. It also makes a new ICF-defined claim “icam-assurance-level-1” asserting that “the security token is issued according to the requirements of the U.S. federal Identity Credential and Access Management (ICAM) Assurance Level 1”. See the press release for more information about the Acxiom card.
I’m writing to thank the Burton Group for sponsoring the federation interop demonstration at the 2009 Catalyst Conference in San Diego. As you can see from the logos, they attracted an impressive set of interop participants. It was great working with the knowledgeable and enthusiastic colleagues from other companies to assure that our products will work together for our customers.
Microsoft demonstrated SAML 2.0 interoperation using our forthcoming Active Directory Federation Services 2.0 product (no, it’s not named “Geneva” Server anymore). We federated both to and from numerous other implementations. For instance, those attending in person got to watch yours truly demonstrate using AD FS 2.0 to log into SalesForce.com and WebEx, among other scenarios.
But why write about this now, one might ask? Isn’t the interop done? Not necessarily! In fact, one of the cool things about online interops is that the participants can continue testing well after “the event” is over. For instance, we’ve done some WS-Federation testing with participants since Catalyst, as well as just invited participants to re-test with a more recent drop of our server bits if they’d like to.
Finally, I’d be remiss if I didn’t thank the Eternal Optimist herself for doing the work to enable the Catalyst interop to be hosted the OSIS wiki. Doing the interop online with public endpoint information helped the work go as smoothly as possible.
I’m thrilled to announce that the Identity Metasystem Interoperability Version 1.0 specification has been approved as an OASIS standard, with 56 votes in favor and none against. This standard benefitted substantially from the input received during the process. Numerous clarifications were incorporated as a result, while still maintaining compatibility with the Identity Selector Interoperability Profile V1.5 (ISIP 1.5) specification.
While this is often said, this achievement is truly the result of a community effort. While by no means a comprehensive list, thanks are due to many, including the OSIS members whose diligent efforts ensured that Information Cards are interoperable across vendors and platforms, the Information Card Foundation members for their adoption and thought leadership work, and the IMI TC members, including co-chairs Marc Goodner and Tony Nadalin, and Mike McIntosh, who was my co-editor. Paul Trevithick and Mary Ruddy get enormous credit for starting and leading the Higgins Project, as does Dale Olds for the Bandit Project. Kaliya Hamlin and Phil Windley were instrumental behind the scenes by running the IIWs. Axel Nennker has been a tireless force, producing both ideas and software, as has Pamela Dingle. Jamie Lewis, Bob Blakley, and Craig Burton all provided insightful guidance on the practical aspects of birthing a new technology. Arun Nanda deserves enormous thanks for doing the heavy lifting to produce the ISIP 1.0 spec. And of course, none of this would have occurred without the leadership and vision of Kim Cameron. Thanks one and all!
OASIS has scheduled the standards approval vote for the Identity Metasystem Interoperability Version 1.0 specification for June 16-30. My thanks to everyone who submitted comments during the public review. Numerous clarifications have been incorporated as a result of your comments, while still maintaining compatibility with the Identity Selector Interoperability Profile V1.5 (ISIP 1.5) specification.
Microsoft announced the availability of the second beta of its forthcoming “Geneva” claims-based identity software today during Tech•Ed. This is a significant milestone for the team along the path to releasing production versions of the “Geneva” software family, which includes the server, framework, and CardSpace. I’m personally particularly proud of all the interop work that has been done in preparation for this release. I believe that you’ll find it to be high-quality and interoperable with others’ identity software using WS-*, SAML 2.0, and Information Cards.
For more details, see What’s New in Beta 2 on the “Geneva” Team Blog. Visit the “Geneva” information page. Check out the Identity Developer Training Kit. Learn from team experts on the ID Element show. Download the beta. And let us know how it works for you, so the final versions can be even better.
Enjoy!
This week the Information Card Foundation marked two significant developments at the European Identity Conference: the formation of the German-language chapter of the ICF, and receiving the European Identity Award for Best New Standard.
The inaugural meeting of the German-language D-A-CH chapter was exciting. About 25 people attended representing at least 17 companies and organizations. A highlight was presentations by Fraunhofer FOKUS, Deutsche Telekom, CORISECIO, Siemens, Universität Potsdam, and Microsoft about their Information Card work. Lots of good things happening! Also see the ICF post about the chapter.
Receiving the European Identity Award for Best New Standard was a significant honor for the foundation, and a mark of the maturing of the Information Card ecosystem. Also see the ICF post about the award.
Sehr aufregend!
Microsoft published a knowledge base article today giving examples of intermediate data values produced when generating actual PPID, ClientPseudonym, and Signing Key values. These examples use the algorithms specified in ISIP 1.5 to go behind the scenes of specific OSIS interop computations.
In particular, the article shows how to correctly generate the PPID and Signing Key values for the test Selector_Constructs_Site-Specific_Identifiers_for_Self-Issued_Cards and how to generate the ClientPseudonym value for the test Selector_Support_for_Non-Auditing_Cards. These examples are also highly relevant to the tests Selector_PPID_Construction_for_RP_using_EV_SSL, Selector_Support_for_Auditing-Optional_Cards, and Selector_Support_for_Auditing_Cards.
Thanks to Toland Hon of the “Geneva” test team for writing this useful article.
Today OASIS announced the commencement of the 60-day public review period for the Identity Metasystem Interoperability Version 1.0 specification. This spec is based upon, and compatible with, the Identity Selector Interoperability Profile V1.5 (ISIP 1.5) specification and related Information Card documents submitted to the IMI TC. My sincere thanks to my fellow committee members for their diligence and promptness in reviewing and improving the specification drafts, enabling us to reach today’s milestone on a timely basis. Let the public review begin!
My congratulations to Equifax for issuing the first commercially deployed Information Cards with verified claims. This is huge step forward towards a future where individuals can routinely make verified digital statements about themselves, facilitating trusted, privacy-preserving interactions online.
I’m writing to bring you some of the story-behind-the-story in Information Card Foundation member Equifax issuing these verified Information Cards. Rather than use proprietary claims schemas in their cards, Equifax chose to use claims that are designed to be interoperable with cards that will be issued by other identity providers. Their cards use a combination of the standard Information Card claims, along with a newly defined age-18-or-over claim that anyone can implement.
This new age-18-or-over claim is the first to emerge from the new Information Card Foundation Identity Schemas Working Group. This is a place where anyone can propose a new claim URI and register it for use by all. You will find the age-18-or-over claim definition in the working group’s Claims Catalog. This is an example of how the Information Card Foundation is facilitating collaboration to advance interoperable Information Cards.
I’ll close by saying that while the Equifax page promotes the new Azigo identity selector, their card uses interoperable protocols and file formats, and is compatible with all identity selectors. For instance, you’ll see a screen shot of my Equifax card in Windows CardSpace below, showing both the use some of the standard Information Card claims, as well as the new age-18-or-over claim from the ICF Claims Catalog.
As Don Schmidt wrote this morning, Microsoft’s “Geneva” Identity Server product will support the SAML 2.0 protocol. Specifically, we will be supporting the SAML 2.0 IdP Lite and SP Lite profiles and the US Government GSA profile. Customers had told us that these SAML profiles are important to them and we’re responding to that feedback by implementing them in “Geneva” Server. Those of you who were at Kim Cameron’s “Identity Roadmap for Software + Services” presentation at the PDC got to see Vittorio Bertocci demonstrate SAML federation with “Geneva” Server to a site running IBM’s Tivoli Federated Identity Manager.
The “Geneva” Server is the successor to Active Directory Federation Services (ADFS). It will, of course, interoperate with existing ADFS and other federation implementations using the WS-Federation protocol. In addition, it adds WS-Trust support for issuing Information Cards, letting it work with Windows CardSpace and other Identity Selectors.
I’ll add that the SAML 2.0 support doesn’t stop with the server. SAML 2.0 is also supported by the “Geneva” Identity Framework — a .NET application development framework formerly known as “Zermatt” and “IDFX”, which likewise also supports WS-Federation and WS-Trust. In short, the same identity development framework components that are being used to build “Geneva” Server will be available to all .NET developers as the “Geneva” Identity Framework.
Finally, I’ll close by thanking the folks on the Internet 2 Shibboleth project, IBM, and Ping Identity who helped us with early interop testing of our code. You have been valuable and responsive partners in this effort, helping us make sure that what we’re building truly interoperates with other SAML 2.0 implementations deployed in the wild.
I’m looking forward to participating in the new OASIS Identity Metasystem Interoperability Technical Committee (IMI TC) starting next week, which will produce an Information Card standard. As I told John Fontana of Network World earlier this week after the OASIS announcement of the IMI TC, this work is coming at a logical time.
The industry has been working together on building and testing interoperable Information Card software for the past two years through the OSIS Interops. The breadth of participation and the level of interop achieved between the participants are a testament to the maturity both of the Identity Selector Interoperability Profile specification, which will be a primary input to the standardization work, and of the numerous implementations of interoperable Information Card software. I’m also pleased that the features and tests from the most recent OSIS Interop will be one of the inputs informing the standardization work, enabling the committee to benefit from the experiences that implementers have gained by seeing how their software actually interoperates with others’ solutions.
As a personal note, I haven’t been involved in standards work since I was a technical editor of the POSIX Threads standard in the late ’80s and early ’90s (eventually published as PASC 1003.1c-1995 and ISO/IEC 9945-1:1996). I’ll be curious to see how the OASIS process is like and unlike the POSIX process from nearly two decades ago. Also on a personal level, I’ll say that the committee is a great collection of individuals, and I’m really looking forward to working with them to produce an identity standard of significant long-term value.
Also, be sure to see the comprehensive posting on Cover Pages about the IMI TC, which is chock full of useful information and references. Looking forward to seeing some of you in London!
Relying Parties often identify subjects using the Private Personal Identifier (PPID) claim and Signing Key values sent by an Information Card. Thus, it is important that the PPID and Signing Key values produced by a card be stable and long-lived.
Unfortunately, the PPIDs and Signing Keys generated by self-issued (a.k.a. personal) Information Cards using the algorithm originally shipped with Windows CardSpace (and documented in ISIP V1.0) for sites using regular certificates were not stable under several important conditions. Therefore, after considering industry feedback on the long-term problems that this continued instability would cause, and in consultation with other Identity Selector authors, a decision was made to change these algorithms in a way that will provide much better long-term stability of these important Subject identifiers for Relying Parties. The new algorithm is documented in the Identity Selector Interoperability Profile (ISIP) V1.5.
This change shipped with the version of Windows CardSpace in the .NET Framework 3.5 Service Pack 1. This service pack will be installed by Windows Update on systems with the .NET Framework 2.0, 3.0, and 3.5 in the coming months. I know that the Bandit and Higgins projects have implemented the new algorithm as well.
Unfortunately, this change means that the PPIDs and Signing Keys for self-issued cards used at existing Relying Parties that employ standard SSL certificates will change after this installation.
What Sites Need to Do
Sites need to ensure that they have tested mechanisms in place to enable their users to re-associate their Information Card with their account when the card’s PPID and Signing Key change. The good news is that these mechanisms are likely already in place in the form of “lost card” handling procedures.
When the card is used after the update, it will appear to be an unrecognized card. Just as sites’ lost card procedures can be used today to associate a new Information Card with their account, these same procedures can be used to re-associate the existing card with the account after these changes.
These lost card procedures will typically involve sending the user a message at the e-mail address of record for the account. This message contains a link that enables them to associate an Information Card with their account. This flow is nearly identical to the “lost password” flows often found on sites. Best practices for lost card handling are documented in the “Enabling Information Card Recovery” section of Patterns for Supporting Information Cards at Web Sites: Personal Cards for Sign up and Signing In.
Additional Steps Sites Could Take
In the short term, sites could also choose to add text to their Information Card login pages warning users that their existing cards will not be recognized as being associated with their accounts after the .NET update, and directing them to use the “lost card” feature of the site to remedy this situation.
EV and no-SSL Sites Not Affected
None of this affects sites using Extended Validation (EV) certificates or sites not using SSL certificates. These algorithms were already stable and have not changed. No action is required in these cases.
Background on the Problem
Because the original PPID and Signing Key algorithms used the entire certificate chain, these values could change under several circumstances:
- First, as sites renew their certificates, it is common for the certificate chain for the new cert to differ from the old one. This would change the PPID, breaking the user’s self-issued cards at those sites. And of course, the chain always changes if the site changes its certificate provider.
- Second, because the algorithm for converting the bytes of the chain certificates into characters was not fully specified by ISIP V1.0 for some OIDs, for some kinds of certificates, different Identity Selectors produced different results for the PPID claim, Signing Key, Client Pseudonym PPID, and IP Identifier values.
- Finally, in ISIP V1.0, the PPID for a site using a non-EV certificate is different than the PPID for a site that uses an EV certificate, even in the case where the non-EV leaf cert content meets the EV issuance criteria. This means that when a site upgraded to using an EV certificate, user’s cards would stop working at that site.
Overview of the Solution
To address these issues, the computation of the PPID and Signing Key for sites using regular certificates has been changed to no longer include information from the certificate chain, but only information from the leaf certificate. This will provide stability both when certificates are renewed and when a certificate is obtained from a new issuer.
Furthermore, the new algorithm generates the same PPID values for sites using EV and non-EV certificates with the same leaf certificate information, while generating different Signing Keys. This will help enable a smooth migration path for sites upgrading from non-EV to EV certificates because the PPID remaining the same can be used as evidence that the same card is being used before and after the certificate upgrade.
More about the specifics of the algorithm change can be found in Section 8.6.1 of ISIP V1.5 and additional guidance and commentary can be found in the corresponding section of the ISIP V1.5 Guide.