Liberty, WS-Security Uniting Over SAML Standards

Last month, the Liberty Alliance Project elected a new president Michael Barrett, vice president for Internet strategy at American Express. Since his election, Barrett has left little doubt that he will push those vendors sparring over identity and security standards -- notably Sun, IBM and Microsoft -- to reach an agreement on interoperability. In this special focus, Integration Developer News tracks down execs from Sun, Microsoft, RSA and others to get an update on how well the "peace talks" are going. See why these talks may be going better than you thought.

Tags: SAML, Liberty, Profile, Authentication, Microsoft, Security, WS-Security,

Last month, the Liberty Alliance Project elected a new president Michael Barrett, vice president for Internet strategy at American Express. Since coming to office, Barrett has left little doubt that he will push those vendors sparring over identity and security standards -- notably Sun, IBM and Microsoft -- to reach an agreement on interoperability.

So far, the "peace talks" between Liberty and Microsoft Passport seem to be going well, thanks in large part to all-party discussions on security taking place under the OASIS (Organization for the Advancement of Structured Information Standards) umbrella, and some XML-based security brokering technology being specified inside OASIS called SAML (Security Assertion Markup Language).

"It's pretty obvious that we'll use SAML as a glue between different identity approaches [such as Liberty and Passport], the SAML technical committee co-chair for OASIS Jeff Hodges told Integration Developer News. "And while SAML is not an authentication technology in and of itself, SAML can be used as a tool to glue together disparate authentication domains."

For its part, Liberty is built on SAML, but does not define any authentication mechanisms. SAML is a framework and one needs to profile it to put into context to make use of it. Further, the Java Community Process (JCP) has a proposal to natively support SAML (JSR 155) for use in J2EE. "Presumably, using that and other aspects of the J2EE environment a Java developer will be able to put together the technologies and specs he needs to integrate a Liberty approach with another authentication approach," Hodges said, who is also an engineer at Sun Microsystems.

Of good news to developers worried about interoperability issues, SAML is also being endorsed by Microsoft execs. "Members of the OASIS security committee wants to see all our work reconciled, and we want to see SAML token support in WS-Security." Adam Sohn, a product manager for Microsoft .NET platform strategy group told IDN in an interview this summer. Sohn added that WS-Security's decision to support SAML (and Liberty) will not prompt WS-Security to "downplay" plan to support a variety of security mechanisms already at work within the enterprise, including PKI, Kerberos and even SSL.

WS-Security will look at Liberty and SAML as just another credential type, and we expect to have support in WS-Security this year" Sohn added. Notably, OASIS now manages the standards proceedings for both SAML and WS-Security, as the group has also formed a technical committee to push WS-Security standards. Read more on the scope of the OASIS committee here.

Federated Identities -- Many "Touching Points"
"There are a lot of touching points across Liberty, SAML and WS-Security, and it's hard to look at a crystal ball to see exactly what will happen. But we are starting to see some convergences and rapprochement between all these groups, " Slava Kavsan, Chief Technologist at RSA Security, and chairman of the Liberty Alliance's Trust and Security Group told IDN.

Notably, RSA has been a key figure in pushing compatibility among Sun, Microsoft and IBM approaches. "There is good news. First, WS-Security will mention SAML is its next draft."

Kavsan looks at the interoperability issues on identity as similar to other compatibility questions that exist on a number of web services fronts between IBM, Microsoft and Sun. "We're still in a basic architectural world of the Microsoft client needing to talk to a Java or Sun server," he said. "Even though Liberty is working on its own browser-based client spec, Liberty needs to and intends to support Microsoft's client base."

"In fact, today Passport and Liberty could work together to enable users to have SSO authentication," Slava said. "A user could authenticate with passport, and the service provider could use SAML authentication assertion to make sure that authentication is acceptable to Liberty users," he said. Illustrating the point, RSA earlier this month released its SecureXML toolkit, which supports developers building SAML messages. RSA is also working with Microsoft to bring its Secure ID technology to Passport.

A key to interoperability moving forward, Kavsan said, may be found in the approach by all parties to a concept known as a "federated identity." With a federated identity, developers can access a distributed API that would access multiple provision systems via a middleware or brokering layer is provided between the client (consumer or business) and the end server.

"So, for example, with a federated identity, a user could use his username and password to gain access to all his accounts, even though each website might maintain their own site-specific identity database," Kavsan said. For its part, Microsoft's Passport also intends to have a federated identity. "And while to my knowledge it does not specifically mention SAML right now, support for a federated identity is a key goal of Liberty," Kavsan said.

In Liberty -- Phase One: Through one-to-one trusted relationships, users will be given a way to link certain core accounts up to a single username/password. Both of these identities would be Liberty-enabled, so that while the consumer would be able to use a unified account login, each company would continue to maintain their own unique identity databases.

In Liberty - Phase Two : Here, the plan is to begin to replace the need for one-off "trusted relationships" and implement more on-demand (loosely coupled) identity mechanisms. That way, consumers or businesses could simple have identities protected and verified by new web sites or providers or services on a per use basis, without a standing relationship, Kavsan said. "Many Liberty and SAML members are on working groups and committees for this, and so I expect that SAML 2.0 will map closely to these new Liberty features."

But developers shouldn't look for too much progress until early next year. "Point-to-point with trusted partners versus Service-Oriented Architecture is pretty far away, but that will be the part of the Liberty 2.0 roadmap, slated for release the first quarter of 2003," Kavsan added.

What's Coming for SAML?
SAML 1.1 will be released in 3-4 months, Hodges said. Most of the heavy lifting on the coming specification is just about done. "The group is taking a little breather and cleaning up a few things in the current spec," Hodges told IDN. But it's just the calm before the frenzy. "We have an extensive laundry list of possible items that for a major revision to SAML for version 2.0," he added.

One key area of focus for SAML 2.0 will be setting standard and reusable profiles. "There are several contexts where there is not yet a profile spec, such as B2B,"Hodges said. [SAML profiles are protocol specifications that detail how an interaction operates and what elements it needs for determining a secured identity. These profiles do not have to specify the SAML assertions being used -- or the identity mechanism.]

"Someone could use a proprietary use of SAML and not document what they did," Hodges said. "It could be SAML-compliant, but it wouldn't necessarily be interoperable [with other SAML users]. But, if that private scenario were profiled in an open spec, and implemented by multiple vendors and tested for interoperability, there would be a greater possibility to reuse that SAML profile."

Users are encouraged to draft their own SAML profiles, and submit them to the committee for broader publication, Hodges said. "We wrote into the SAML spec how one registers a profile," he told IDN. Developers can correspond with OASIS about SAML profiles by emailing the committee at

So far there is only one profile: How to establish the security context in a SOAP message. Without that profile, developers needed to place information in the SOAP header and specify how that will use XML digital signature and encryption

Other prospective items on SAML 2.0's laundry list include:
1. Multi-participant transaction workflow
2. Credentials collections
3. Baseline attribute namespaces
4. Sessions
5. SAML feature discovery using WSDL -- when/if there is a SAML authentication that is already done is there a way to use WSDL to discover how you concoct a query

What determines what gets done, and when? It's a matter of bandwidth," Hodges said. "How much horsepower do people [on the committee] have, and so we need to go through all the items on the list and prioritize them. We've already gotten feedback from analysts based on what their customers say they want to see.