Microsoft has published the fifth in 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 IBM Tivoli Federated Identity Manager to federate using the SAML 2.0 protocol. The guide is available in HTML format and soon also Word and PDF. Thanks again to author Dave Martinez for making this series a reality!
Archive for the 'Federation' Category
Microsoft has published the fourth in 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 Ping Identity PingFederate to federate using the SAML 2.0 protocol. The guide is available in Word and PDF formats and also HTML. Thanks again to author Dave Martinez, and special thanks to Ping Identity for sponsoring this guide.
Microsoft has published the third in 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 Shibboleth to federate using the SAML 2.0 protocol. There is also an appendix on federating with the InCommon Federation. The guide is available in Word format and HTML. Thanks again to author Dave Martinez.
Microsoft has published the second in 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 Oracle Identity Federation 184.108.40.206, as delivered in Oracle Identity Management 220.127.116.11, to federate using the SAML 2.0 protocol. The guide is available in HTML and Word formats. Thanks again to author Dave Martinez.
Medtronic, PayPal, Southworks, and Microsoft recently worked together to demonstrate the ability for people to use their PayPal identities for participating in a Medtronic medical device trial, rather than having to create yet another username and password. Furthermore, the demo showed the use of verified claims, where the name, address, birth date, and gender claims provided by PayPal are relied upon by Medtronic and its partners as being sufficiently authoritative to sign people up for the trial and ship them the equipment. I showed this to many of you at the most recent Internet Identity Workshop.
From a technology point of view, this was a multi-protocol federation using OpenID and WS-Federation – OpenID for the PayPal identities and WS-Federation between Medtronic and two relying parties (one for ordering the equipment and one for anonymously recording opinions about the trial). It was also multi-platform, with the Medtronic STS running on Windows and using the Windows Identity Foundation (WIF) and DotNetOpenAuth, the equipment ordering site running on Linux and using simpleSAMLphp, and the opinions site running on Windows and also using WIF. A diagram of the scenario flows is as follows:
We called the demo an “identity mash-up” because Medtronic constructed a identity for the user containing both claims that came from the original PayPal identity and claims it added (“mashed-up”) to form a new, composite identity. And yet, access to this new identity was always through the PayPal identity. You can read more about the demo on the Interoperability @ Microsoft blog, including viewing a video of the demo. Southworks also made the documentation and code for the multi-protocol STS available.
I’ll close by thanking the teams at PayPal, Medtronic, and Southworks for coming together to produce this demo. They were all enthusiastic about using consumer identities for Medtronic’s business scenario and pitched in together to quickly make it happen.
I’ll be participating in an Open Identity for Business Interop being held by OSIS at Catalyst in San Diego this month. This multi-protocol interop event includes exercising the US Government identity profiles developed as part of the Open Identity Solutions for Open Government initiative. Microsoft is hosting testing endpoints using AD FS 2.0 and the Card Issuance CTP. The public interop demonstration is on Wednesday, July 28th. Hope to see you there!
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.
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!
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!).
It’s been an open secret in the identity community for the past several months that the US Government has embarked on an initiative to enable people to sign into US Government web sites using commercial identities. The public announcements of the first steps were made last week during the Gov 2.0 Summit. Now that we can write about the initiative, here’s a personal recap of some of the steps that have gotten us here, and thoughts about what comes next.
- Then-candidate Barack Obama made a commitment to increase people’s access to government services; President Obama issued his Transparency and Open Government memo reinforcing this commitment on his first day in office.
- The federal CIO, Vivek Kundra, requested that the GSA do the ground work to enable people to log into US government web sites using commercially-issued identities using open protocols.
- In parallel to this, the Information Card Foundation, and especially Mary Ruddy, had been working with the GSA on a demo of using Information Cards to sign into government sites. The GSA demonstrated using the Equifax card to sign into a mockup of recovery.gov in April at RSA.
- In April, the GSA, and in particular, the Identity, Credential, and Access Management (ICAM) committee, communicated the need for certification frameworks for identity technologies and identity providers to be used to access government sites. The OpenID Foundation and Information Card Foundation agreed to develop certification programs for their respective technologies and to work with the GSA on profiles for use of the technologies.
- Not long thereafter, the OpenID Foundation and Information Card Foundation made a key decision to work together on aspects of the profiles and certification programs that can be common between the two technologies. Don Thibeau, the OIDF executive director, and Drummond Reed, the ICF executive director, get enormous credit for this decision, which I believe has served both communities well.
- The foundations jointly hired John Bradley to develop profiles for the two technologies. They also hired the same lawyer to look at liability issues.
- The foundations decided to base their profiles as much as possible on the SAML government profile developed by InCommon, so as not to re-invent the wheel.
- ICAM published its Identity Scheme Adoption Process and Trust Framework Provider Adoption Process documents in July. These established criteria for identity technologies and trust framework providers to be accredited for use at US Government sites.
- Based on their work together and with the government, the two foundations published the joint whitepaper “Open Trust Frameworks for Open Government”, with its release timed to coincide with the Open Government Identity Management Solutions Privacy Workshop in August. The whitepaper is available on both OIDF site and the ICF site.
- The privacy characteristics of the draft profiles when used at ICAM Assurance Level 1 (a.k.a. NIST Assurance Level 1) were subjected to public review at the Open Government Identity Management Solutions Privacy Workshop.
- On September 9th, the two foundations jointly announced the Open Identity for Open Government initiative, with Yahoo!, PayPal, Google, Equifax, AOL, VeriSign, Acxiom, Citi, Privo and Wave Systems participating as identity providers. See the press release on the ICF site or the OIDF site.
- On September 9th, US federal CIO Vivek Kundra met with the boards of the OpenID Foundation and Information Card Foundation to discuss progress on the initiative to accept commercial identities at government web sites. He endorsed the idea of starting with three pilot projects that would enable privacy, security, and usability issues to be identified and addressed before a broader rollout. He agreed that two of these pilots should be at ICAM Assurance Level 1 and one at Level 2 or 3.
- The ICAM OpenID 2.0 Profile was published on September 9th.
- At the Gov 2.0 Summit on September 10th, Vivek Kundra described the identity initiative to attendees. His remarks were in the context of things he is doing to make government’s IT investments more efficient. He gave the example of making campground reservations at recreation.gov, which currently requires you to create an account that you’re unlikely to use again soon. He said that since you already have identities from Google or Yahoo or Microsoft, wouldn’t it be better to let you use those identities at the government site?
- ICAM updated the Open Identity Solutions for Open Government page on September 10th. This page should continue to reflect the current state of the initiative.
Of course, despite all the activity above, this is really just the beginning. No government relying parties are yet live, the identity provider certification programs are still being developed, and the Information Card profile is not yet final. Only once sites go live will data start to come in about whether people are able to successfully use commercially-issued identities at the sites, and whether they find this capability useful.
Finally, I’ll note that while government sites will always be only a small fraction of the sites that people use on the Internet, and will typically not be on the cutting edge of innovation, I believe that that this is one of the relatively rare moments where a government initiative is serving as a useful focal point for action within private enterprise. A diverse set of companies and organizations have come together to meet this challenge in a way that would be hard to imagine happening without the government initiative to serve as a catalyst. That’s all good.
We still have a lot to learn and a lot to do. I’m glad we’re getting started.
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!
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.
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.
As announced in Dale Olds’ post Information Card breakthrough with Novell Access Manager 3.1, Novell has released a version of Access Manager that adds support for Information Cards and WS-Federation, partially courtesy of the Bandit Team. I was on the show floor at BrainShare in March 2007 when Novell first demonstrated WS-Federation interop (showing eDirectory users on Linux accessing SharePoint on Windows via an early version of Access Manager and ADFS), so I’m particularly glad to see that the scenarios we jointly demonstrated then can now be deployed by real customers.
It was also at that BrainShare where Novell demonstrated the first cross-platform Identity Selector (an event significant enough that I decided it was time to start blogging). It’s great to likewise see Novell’s Information Card work progress from show-floor demos to shipping product. Congratulations to Novell and the Bandits!
As just announced on the “Geneva” Team Blog (formerly known as the CardSpace Team Blog), beta releases of all three components of Microsoft’s “Geneva” identity platform are now available at the “Geneva” Connect site. The components are:
- “Geneva” Framework: Previously called “Zermatt“, the Geneva Framework helps developers build claims-aware .NET applications that externalize user authentication from the application and helps them build custom Security Token Services (STSs). It supports WS-Federation, WS-Trust, and SAML 2.0.
- “Geneva” Server: Geneva Server is an STS that issues and transforms security tokens and claims, manages user access, and enables easy federation. Based on the “Geneva” framework, it also supports WS-Federation, WS-Trust, and SAML 2.0.
- Windows CardSpace “Geneva”: CardSpace “Geneva” will be the next version of Windows CardSpace. It has a much smaller download footprint, starts fast, and has some innovative user interface improvements made in response to feedback from the first version.
All are early betas that are works in progress, but I highly encourage those of you who are interested in claims-based identity to download them and let us know what you think. Also, be sure to check out the “Introducing ‘Geneva’” whitepaper by David Chappell.
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.
Two important identity interoperability demonstrations will occur at RSA two weeks from now: the OSIS User-Centric Identity Interop and the Concordia Multi-Protocol Federation Interop. During both you’ll see different projects and vendors publicly showing their identity software working together. But what you won’t see at the conference is what’s happening right now – the engineers behind these implementations working together to refine their deployments and their software to ensure that solutions that should work together in theory actually do in practice.
Like the previous OSIS Interop, the current one is testing both Information Card and OpenID implementations – sometimes in combination. I’m especially excited about this Interop for three reasons. First, the set of participants has expanded again by over 50% and includes many commercial deployments of these relatively new technologies. Second, much deeper testing is occurring than ever before. Thanks, in part, to significant efforts by Pamela Dingle and the Microsoft Identity Lab team, during this Interop not only are people trying their implementations with one another’s – they’re also systematically testing their support for an important range of protocol features using interop endpoints designed and deployed for this very purpose. Third, this Interop won’t end when the conference ends. Most of the participants plan to leave their endpoints up after the conference is over, enabling new participants to join and test later and for existing participants to re-test their implementations against the others when they deploy new versions. Visit the OSIS Interop demonstrations in person if you can, especially between 4:00-6:00 on both Tuesday and Wednesday during the conference.
The Concordia Interop is showing the use of Information Cards to sign into both SAML 2.0 and WS-Federation based federations. Both these federations are using SAML 2.0 tokens carrying consistent authentication context information. (I believe that this is the first public demonstration of WS-Federation implementations using SAML 2.0 tokens.) Furthermore, the Concordia Interop demonstrates the ability to bridge between WS-Federation and SAML federations, allowing identities originating in one to be used to authenticate to services in the other. Visit the Concordia workshop during the conference on Monday from 9:00-12:30.
Finally, I’m not the only one excited by these Interops. Axel Nennker, Francis Shanahan, Gerald Beuchelt, Prabath Siriwardena, Scott Kveton, Vittorio Bertocci, and Will Norris have all written about the upcoming OSIS Interop. There’s also a press release from the Concordia project. Hope to see many of you at RSA!
Why has OpenID grabbed so much popularity while SAML, a much more mature, academically respected, ‘robust’ specification has been largely ignored by the cutting edge web 2.0 community?
I’ll encourage you to read his post for his insightful answer.
His question reminded me of another answer to the same question that I gave during the recent Concordia meeting at DIDW: OpenID solves the “Home Realm Discovery” problem that all Federation protocols face; that is, figuring out where the person’s authentication information should come from.
There’s lots of ways this problem can be solved, many of which involve potential identity providers being pre-configured by system administrators as possible choices for specific services. Some systems have even dictated the use of a particular identity provider. OpenID’s solution to this is elegant in its simplicity: Let the user decide. When I type in an OpenID URL such as https://mbj.signon.com/ I’m telling the relying party where my identity provider for this interaction is – thus solving the “Home Realm Discovery” problem. As elegant as this is, of course, the potential downside of this solution is that it assumes that people will remember their OpenID identifiers and will faithfully type them in when a page prompts them for an OpenID.
OpenID 2.0 actually allows i-names such as =mbj or =Mike.Jones to be used as OpenIDs as well. I-names then use their own lookup protocol to discover the identity provider behind the i-name typed. This is arguably better (and is the kind of OpenID I personally use), but still relies on the user to reliably enter their OpenID identifier when prompted.
In this discussion at Concordia, others pointed out that using an Identity Selector (such as DigitalMe or CardSpace) is another means of solving the problem. Like OpenID, it also lets the user decide, but in this case, by clicking on a visual Information Card, rather than typing in a string. I personally believe that this will be an easier metaphor for many people to use once it’s commonly available than typing in an OpenID identifier.
I’ll also point out that it’s not a one-or-the-other choice between OpenIDs and Information Cards when letting the user decide. As was recently demonstrated, OpenID Information Cards can be used to deliver the OpenID identifier to the OpenID relying party, rather than having the user type it.
In conclusion, while it may seem esoteric, solving the “Home Realm Discovery” problem is essential to working digital identity deployments. And the usability of the solution chosen matters a lot. Using Andy’s terminology, I believe that its solution to this problem both accounts for some of “the juju that OpenID has” and may result in usability problems for less technical audiences that will need to be addressed if it’s to break out beyond just us geeks.
The WS-Federation service provider and configuration CLI code was committed into OpenSSO yesterday – this PDF gives some basic instructions on getting started with WS-Fed and OpenSSO. Note that this is just the initial drop of code – still to come is identity provider support.
Give it a whirl and send us feedback at dev(at)opensso.dev.java.net.