eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
We wish we could say Web services will help lighten IT managers security burden, but, unfortunately, quite the opposite is true. In fact, the cost of securing Web services should weigh heavily in any sites return-on-investment analysis, especially for those that plan to extend the technology outside the firewall.
In the near term, IT managers will have to secure Web services with a hodgepodge of measures. The time frame for release of fully interoperable solutions is still a murky guess. Until then, SSL (Secure Sockets Layer) will likely be one of the mainstays of Web services security. Currently, SSL is the most common Web services security choice since it provides both encryption and authentication (through the use of client-side certificates). However, client-side certificates are cumbersome to manage, and Web server management tools do poorly when asked to manage Web services.
At various stages of readiness are a range of specifications that have the potential to overcome those shortcomings—SAML (Security Assertion Markup Language) and WS-S (Web Services-Security) chief among them.
Last week, the previously independent WS-S group (formed by IBM, Microsoft and VeriSign Inc.) met under the auspices of the same organization that controls the development of SAML, a specification that is sometimes seen as WS-S rival.
OASIS, or the Organization for the Advancement of Structured Information Standards, organized the first WS-S technical committee meeting to hammer out a framework for securing SOAP messages. By meeting, work on the two specifications will likely be complementary, thus improving the odds that a security framework with wide adoption will emerge.
In addition, representatives of the World Wide Web Consortium, commonly known as the W3C and the guardian of the SOAP specification, met last month with members of OASIS—again, two bodies that are sometimes seen in a competitive light. The purpose of the forum was to work out ways of integrating the various protocols for the purpose of securing Web services.
SAML, the more developed of the two security specifications, is headed for adoption as an OASIS standard in early November. In its unextended form, SAML allows three things:
- authentication assertion: a person or an application authenticated at this time using these means;
- attribute assertion: This person or process has these attributes, which can be used to convey authentication information about someone, as is often done in LDAP; and
- authorization decision assertion: loosely coupling the enforcement of a decision about resource access from the decision about whether it is permitted.
In other words, upon request, the SAML authority renders a yes or no decision to a requesting application. SAML doesnt handle authentication but rather attempts to provide a reliable record of authentication.
According to Eve Maler, coordinating editor of the Security Services Technical Committee, which handles SAML, the first two characteristics are used quite often today. The third, authorization decision assertion, is “a little more futuristic scenario for using SAML,” Maler said.
SAML is ambitious, taking on how security is passed among SOAP intermediaries—for example, applications that might encrypt portions of a credit card statement before passing the information on to a fulfillment process.
This was demonstrated at the Burton Group Catalyst Conference in July: A SAML interoperability demonstration showed for the first time that authentication and authorization information could be shared among different Web services applications.
The WS-S technical committee will likely push forward with a framework for a SOAP message containing a security token. The work of the two committees will probably overlap in that a SAML assertion is one of the things that could serve as a security token in this scenario. While it is too early to say what the WS-S committee is going to prioritize, it is clear that the decision for the group to work inside OASIS means that previous IT concerns about interoperability are likely much less important.