|
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. One fundamental problem remains however, and is currently not solved to a sufficient level: "Home Realm Discovery" or "IDP Discovery" are the terms used for the identical concept within the WS-Federation and SAML2 world respectively. The concept describes the discovery of a user's primary authentication server for seamless single-sign on. In other words: when a user attempts to access a federated site, a SAML2 IdP or a WS-Federation AP needs to issue an "assertion" or a "claim" with a security token. Which server? Both protocol worlds describe a mechanism how this can happen, but the mechanisms used are incompatible and hence do not work well in a mixed environment. Until this is solved, the user experience in a mixed federation protocol environment is at best incomplete. Project Concordia acknowledges that this is still an outstanding issue that needs to be resolved. Kuppinger Cole believes that once it is resolved, identity federation technology will move ahead rapidly, as important obstacles regarding interoperability will then be resolved. Until then, Project Concordia's achievements are an important step in a still incomplete evolution to true federation interoperability.
Created: 20.06.08, modified: 03.07.08
|
