At the recent RSA conference in San Francisco in the second week of April, several vendors demonstrated new interoperability between previously incompatible federation protocols. Through Project Concordia, a new project co-sponsored by the Liberty Alliance and several other vendors, several profiles were shown that showed seamless integration of SAML, WS-Federation and CardSpace. This demonstration is significant, because it shows that vendors, especially Microsoft, are bowing to increased pressure from customers to focus on interoperability. It also highlights the challenges that are still ahead and yet to be solved.
At the interop, taking place on the 8th of April during a pre-conference event in San Francisco, FuGen Solutions, Internet2, Microsoft, Oracle, Ping Identity, Sun Microsystems and Symlabs showed several use cases that combined these technologies. At the forefront of the demonstration was to show that integration of federation scenarios using a mixture of SAML2 and WS-Federation protocols was now possible. Those companies that managed to implement support for both of these protocols in their products showed how a server running the vendors' federation software could transparently (for the user) bridge between systems using the SAML2 protocol, and the WS-Federation protocol. For example, a user that had previously federated successfully using SAML2 technology could now seamlessly access a Resource Partner (federation client) such as Microsoft SharePoint. The vendors' federation server acts simultaneously as a SAML2 Identity Provider (IdP) and a WS-Federation Account Partner (AP), and translates authentication tokens from one protocol to the other.
Another interesting demonstration was the use of SAML2 tokens within the WS-Federation protocol. Even though this feature has always been foreseen from the specification, Microsoft and IBM, the main drivers behind the WS-* specification including WS-Federation, had never implemented support for SAML2 tokens within their implementation, instead opting to support only SAML1 security tokens embedded within WS-Federation protocol messages. A month ago, Joe Long from Microsoft made a groundbreaking announcement at Netpro's Directory Experts Conference in Chicago. He mentioned that it was already possible to include SAML2 tokens with ADFS, Microsoft's Active Directory Federation Services, and that Microsoft was currently re-evaluating whether to support SAML2 as a native protocol. Previously, Microsoft had steadily refused to support SAML2, pointing out that WS-Federation was the intended standard for federating within the Microsoft ecosystem.
Kuppinger Cole was unable to confirm the claim at that time, because the current release of ADFS, even at the point of writing of this article, does not yet support SAML2 tokens within WS-Federation protocol messages. It is clear however, that this will be released in a future version of ADFS. When? Microsoft is keeping its cards very close to its chest, and will only inofficially say "soon".
Another interesting use case was the use of InfoCards as an authentication mechanism for federation servers based on the SAML2 protocol. Although the SAML2 protocol is designed to be very open with regards to security tokens embedded into its protocol messages, this had never before been demonstrated. Kuppinger Cole finds that many companies are taking an interest in CardSpace technology, although adoption is still lagging behind. Now that this use case has been demonstrated, and will likely be supported in future (and for some companies even concurrent) releases of federation software, it may provide an additional small incentive for companies evaluating CardSpace as well as remove an additional obstacle in CardSpace adoption.
Read the complete article by Felix Gaehtgens of Kuppinger Cole.
