SAML 1.0 is Adopted - What Developers Can Expect
More than 200 security and web services vendor members of OASIS have approved specs for SAML 1.0 (Security Assertion Markup Language). The approval, with no dissenting vote, sets in motion a standards-based movement for providing a common framework for web services security. But, while SAML 1.0 spells out the specs and the schema for web services identity management and single sign-on, it does not say how hundreds of vendors will implement the standard or even test for compliance and vendor-to-vendor interoperability. This week, Integration Developer News takes a hard look what SAML 1.0 provides, what's missing, and the willingness of vendors to fill in the gaps.
Earlier this month, more than 200 security and web services vendors approved the Security Assertion Markup Language (SAML) v. 1.0. According to OASIS execs and member companies, this unanimous endorsement set in motion the first step toward providing a common security framework for a variety of vendor-specific web services solutions.
SAML 1.0 spells out the specs and the schema for web services identity management and single sign-on, but last week's vote doesn't fill in the gaps on how hundreds of vendors will implement the standard or even test for compliance and vendor-to-vendor interoperability. This week, Integration Developer News takes a hard look what SAML 1.0 provides, what's missing, and the willingness of vendors to fill in the gaps.
The SAML 1.0 Vote -- A Unanimous "Big Deal"
Reflecting the votes of nearly 270 member vendors and more than 1,000 individual members, "the SAML approval was the highest level of OASIS approval," Karl Best, vice president of OASIS told Integration Developer News. "The completion and approval of SAML is a very big thing," he added. Notably, the vote could resolve many of the disruptive incompatibilities that threaten compatibility and interoperability between Sun's Liberty Alliance Project and the Microsoft/IBM/Verisign WS-Security proposals.
By itself, SAML won't sort out all the scuffles, but it is quite central to many aspects of the security picture, including XACML (Extensible Access Control), WS-Security, The Liberty Alliance Project, (XML Key Management Specification), biometrics and provisioning.
A presentation by Verisign's Dr. Phillip Hallam-Baker at an OASIS security conference last summer made put SAML at the nexus of several of these security components.
"It's pretty obvious that we'll use SAML as a glue between different identity approaches [such as Liberty and Passport], Jeff Hodges, the SAML technical committee cochair for OASIS, told IDN. "And while SAML is not an authentication technology in and of itself, it can be used as a tool to glue together disparate authentication domains."
So far, the peace talks between Liberty and Microsoft Passport have made progress, thanks in large part to OASIS and to the willingness of both sides to adopt some XML-based security-brokering technology specified by SAML.
Sun is committed to SAML on a number of fronts in its Liberty Alliance Project and the progress of Java and J2EE. In Liberty, SAML will support one-to-one trusted relationships in which users will be able to link certain core accounts to a single username/password. In addition, 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," said Hodges (who is also an engineer at Sun Microsystems).
Meanwhile, Microsoft execs also see SAML's merits for .NET, Passport and WS-Security, the joint IBM/Microsoft/Verisign-proposed standard for security specified by the Web Services Interoperability Organization (WS-I). "There is good news. First, WS-Security will mention SAML in its next draft," Slava Kavsan, chief technologist at RSA Security and chairman of the Liberty Alliance's Trust and Security Group, told IDN. "We're starting to see some convergences and rapprochement among all these groups," he added.
What the SAML 1.0 Provides
In SAML 1.0, OASIS sets the terms for core foundation specs for how security identities instructions for single sign-on should be handed off and securely managed across nodes (and/or trusted partners) in a web service.
In specific, SAML 1.0 specifies:
security and privacy considerations for protecting user identification, and
conformance program specs.
SAML 1.0 also sets definitions for a variety of terms in a glossary, to prevent vendor-specific definitions of features and/or services.
Few of these documents underwent any major revision since they were voted out of technical committee in May, but their formal adoption on November 6 sets in stone the first wave of SAML terms, technologies and specifications.
The SAML 1.0 Missing Pieces
But there are many momentum-building steps the SAML 1.0 vote does not accomplish, at least directly, Best told IDN. Chief among the missing elements are formal conformance tests that would ensure current-spec compliance to those of the 260+ vendors who don't have SAML but may wish to implement it.
"We don't have conformance tests for SAML yet," Best said, "but we're encouraging the technical committee to develop those as a next step. OASIS also doesn't have implementation guidelines or conformance testing for how OASIS members should best implement SAML," Best added. "but there are a number of technical committees, including SAML, that have a goal to make it as easy as possible to implement SAML in a way that it will be interoperable. We'll make the spec publicly available and the first of the approval process."
Best insisted momentum is behind SAML to fill in these gaps in the practical side of implementation. "ASIS is not just interested in developing prudent specs and letting them go. There are a vast amount of specs are not even used. We don't want to send anything to members that is vapor-ware. It must be implemented and be shown that it can be implemented by other vendor members. So, OASIS has the added requirement that three or more members have already implemented a spec before it's put up for a vote," he explained.
"But," Best conceded, "because all the work is done by volunteer members, we can't require [them]. But we can encourage them, so (we're not sure about the plans of the SAML technical committee to promote implementation. We're working with the technical committees to help ensure these standards get adopted by a wide number of vendors."
The SAML Roadmap -- What's To Come
The stage is set for vendor agreement -- and implementation by early 2003, according to Hodges, who, as cochair of the SAML committee, is on the front lines for setting an agenda and seeing it through.
The official SAML 1.0 document (likely to be called SAML 1.1) will be released in three to four 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 there's hard work ahead: The current version of SAML does not define any authentication mechanisms -- instead, SAML is a framework, and one needs to profile it to put into context to make use of it.
That is just one of the issues that will be on the agenda for the mega-upgrade to SAML (v. 2.0) slated to start Q1 2003. "We have an extensive laundry list of possible items for a major revision to SAML for version 2.0," Hodges added.
But the few months are the calm before the frenzied storm, Hodges said, as SAML 2.0 has an ambitious "laundry list" of possible areas of attention. Among those being considered, Hodges told IDN, are:
- Multi-participant transaction workflow
- Credentials collections
- Baseline attribute namespaces
- SAML feature discovery using WSDL -- when/if there is an authentication that is already done, this would be a way to use WSDL to discover how to concoct a query.