Taking Cost of Security Into Account

By Cameron Sturdevant  |  Posted 2002-09-16 Print this article Print

We wish we could say Web services will help lighten IT managers' security burden, but, unfortunately, quite the opposite is true.

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.

    Cameron Sturdevant Cameron Sturdevant is the executive editor of Enterprise Networking Planet. Prior to ENP, Cameron was technical analyst at PCWeek Labs, starting in 1997. Cameron finished up as the eWEEK Labs Technical Director in 2012. Before his extensive labs tenure Cameron paid his IT dues working in technical support and sales engineering at a software publishing firm . Cameron also spent two years with a database development firm, integrating applications with mainframe legacy programs. Cameron's areas of expertise include virtual and physical IT infrastructure, cloud computing, enterprise networking and mobility. In addition to reviews, Cameron has covered monolithic enterprise management systems throughout their lifecycles, providing the eWEEK reader with all-important history and context. Cameron takes special care in cultivating his IT manager contacts, to ensure that his analysis is grounded in real-world concern. Follow Cameron on Twitter at csturdevant, or reach him by email at cameron.sturdevant@quinstreet.com.

    Submit a Comment

    Loading Comments...
    Manage your Newsletters: Login   Register My Newsletters

    Rocket Fuel