SAML 2.0 unifies support for federation |
 |
By Michael S. Mimoso, Senior News Editor
23 Feb 2004 | SearchWebServices.com |
|
|
Members of the OASIS Security Services Technical Committee hope that the next incarnation of the Security Assurance Markup Language, SAML 2.0, eases any lingering security concerns that could be holding back Web services adoption.
SAML 2.0, due out early this summer, unifies the single sign-on building blocks of version 1 with the identity federation framework developed by the Liberty Alliance in SAML 1.1.
"SAML 2.0 pulls everything under one umbrella, so that different forms of federation are supported in a single framework," said Prateek Mishra, co-author of SAML and the director of technology and infrastructure at Netegrity Inc.
|
|
|
|
|
SAML 2.0 pulls everything under one umbrella, so that different forms of federation are supported in a single framework.
Prateek Mishra
SAML co-author
|
|
|
|
|
|
|
|
|
|
SAML 1.0 focused on Web single sign-on, in which an online identity is submitted once and carried across enterprise boundaries online. In 1.1, the Liberty Alliance built a stack of protocols on top of that, so that it now supports account linking and role-based federation.
"We were surprised by the level of support [1.0 received]," Mishra said. "It got a lot of attention because it solved a business problem. It explained how to use an XML structure to transfer information securely. SAML 1.0 and 1.1 are driving a number of deployments, and we've gotten a lot of practical experience that we're applying to 2.0."
Mishra said that deployment and configuration issues remain. Also, OASIS needs industry to lobby for the security of Web services and the implementation of standards like SAML and WS-Security; better security would ease apprehension about application-to-application communication.
"This is a network problem, when you get down to it -- configuring software so that it can interoperate," Mishra said. "The technology has been there [XML signatures, SSL and others]. We have to get industry consensus to use these building blocks. This is not trivial."
Mishra said the OASIS Security Services Technical Committee is largely made up of vendors, but it does include some high-profile enterprise representation from companies like Boeing Co. and Fidelity Investments, and from the federal government.
"We have to get vendors, customers and researchers to agree on a direction and get them to understand that there is a specification that addresses their needs," Mishra said.
Mishra's concerns about a glut of specifications are justified. Last July, BEA Systems Inc., IBM, Microsoft, RSA Security Inc. and VeriSign Inc. penned the Web Services Federation specification. The specification was criticized for essentially duplicating what the Liberty Alliance had done in SAML 1.1. Adding to the confusion was the fact that RSA, BEA and VeriSign Inc. belong to the Liberty Alliance as well.
Web Services Security (WS-Security) is another competing standard, though this one is under OASIS. It is a set of SOAP extensions that can be used to build secure Web services.
WS-Security supports multiple security tokens, trust domains, signature formats and encryption technologies to securely exchange tokens and messages.
|
|
|
|
