Besides Microsoft, AmberPoint, BEA, BMC, CA, IBM, Red Hat, and SOA Software have been involved and are co-sponsors of the TC proposal. Conspicuously of course missing are HP, Oracle, and Sun, who have backed the Liberty Alliance-shaped SAML, which has also gone through Oasis.
Until now, Liberty has claimed the advantage, as SAML has been ratified as an Oasis standard, while WS-Federation was simply a specification that had yet to find a home in a standards group. In turn, the Liberty Alliance has claimed a head start, boasting over 1 billion identities using the standard around the world, while WS-Federation was associated primarily with Microsoft’s Passport and CardSpace protocols.
This isn’t the first time that we’ve seen alternative approaches, it’s not uncommon for the standards world to address the same problem in different ways, remarked Marc Goodner, a technical diplomat from Microsoft who is a co-proposer of the WS-Federation TC effort.
Yesterday’s announcement was not much of a surprise, given that other pieces of the stack, including WS-Trust and WS-SecureConversation, have already been in the Oasis pipeline for some time, under development of the Web Services Secure Exchange (WS-SX) Technical Committee.
TCs are the formal mechanism by which standards are drafted at Oasis. Once a TC is approved, any Oasis member can become a participant.
While at the end of the day, all differences in standards typically boil down to politics, there are technical differences in the two approaches to federating identity in service-oriented environments.
WS-Federation, plus two of the other pieces, cover different aspects of how you secure an exchange between requestor and service provider. In a federated identity environment, actual identifiers are not passed from system to system, because that could open a major security leak. Instead, source systems vouch for the identity of the requestor and pass along tokens signifying that, which external systems decide to accept or reject.
WS-Security provides a basic framework specifying a modular schema for each of the building blocks validating the integrity of the requestor and protecting the integrity of the message flow leading to request and provision of a service. It doesn’t specify any tokens per se, but can accept a wide variety of them.
In turn, WS-Trust provides methods for managing the token life cycle, involving issuing, renewing, and validating security tokens as well as establishing, detecting, and brokering trust relationships. Finally, WS-SecureConversation allows security contexts to be created and key material to be exchanged more efficiently. There are also other related standards proposals, often bunched under the WS-* banner.
By contrast, SAML specifies a specific token, whereas WS-Federation leaves the choice of tokens open.
While the headlines imply that vendors are in hot pursuit of customers, in actuality, this is an argument of the future, rather than the present, said ZapThink analyst Ron Schmelzer in an email response. End users are still grappling with the basics of getting enterprise identity management to work in a composite environment. It remains to be seen what long-term uptake customers will have with WS-Federation specific products and offerings.
Our View
Appearances can be deceiving, in that the battle of SAML vs. WS-Federation appears to be one of those religious wars where you’re either on one side or another. But given the reality that the SOA world assumes heterogeneity and loose coupling (where different pieces, such as whatever identity management tool you use) should be able to be swapped in and out without impacting the service, vendors are likely to apply SOA principles literally here.
And anyway, the whole idea of federation is that you may have to accept credentials, through tokens, that are generated on a wide array of systems. Anyway, there’s too much Kerberos and X.509 around for any vendor to take a single authentication approach.
They may argue for SAML or WS-Federation, but at the end of the day, their tools will take the pragmatic approach, supporting both standards. F9or instance, Microsoft will support the SAML token itself, but it doesn’t support the broader SAML 2.0 Oasis standard that manages exchange of tokens. Similarly, Oracle, which is a vocal SAML supporter, is supporting both in current versions of its identity management suite, and BEA (which sits on both Oasis federated identity TCs) has promised likewise.
