Sorting out Web services security standards

One of the most active parts of the XML Web services community is the groups developing security standards.

Today, we have more than 40 security standards in various stages of specification at several different organizations, as well as various implementations in similar states of completion and conformance.

On the one hand, this is good news, because good security is crucial to the widespread adoption of XML Web services. One of the expected benefits of XML Web services is a more direct connection between back-office systems and a larger group of potential customers by providing a common set of "Web middleware" that removes barriers to connecting. In order for this to happen without undue risk, security standards are needed that can provide assurances about identity, message content and data protection.

On the other hand, the number of security-related specifications (not to mention their page count!) can overwhelm all but a vast team of the most dedicated architects or developers. This article provides a road map to help you pick your way through the major players and the specs they're writing.

It's helpful to view the development of Web services security standards as a pipeline with three parts: initial development, standardization and profiling.

Initial development

The initial development stage tends to be led by vendor-driven organizations. Two of the most important ones are the WS-Workshop headed up by IBM and Microsoft, and the Liberty Alliance, which has more of a mix of vendors and customers.

The goal of the WS-Workshop effort is to define a SOAP-based infrastructure for secure, distributed transactions over the network. The first few dozen specifications were by Microsoft, IBM and BEA, leading some to call this the "Men In Black" (MIB) group. The process is much more open these days, although participants must sign a nondisclosure agreement so that early results aren't disclosed prematurely. They must also promise not to "taint" the process with any intellectual property that could prevent royalty-free implementations.

The WS-Workshop efforts seem to be standards-body-neutral. For example, WS-Security has been an OASIS activity for some time, while WS-Addressing just started at the World Wide Web Consortium (W3C).

But the workshop members aren't above political infighting. When the Liberty Alliance turned over its specifications to OASIS, and the SAML group picked up the "federated identity server" concept and added it to SAML 2.0, there was an effort to declare it out of scope, because it conflicted with a more general federation concept in the WS-Federation workshop specification.

The Liberty Alliance is working on Web- and XML-based federated identity. That is, trusted peers vouchsafe the originating client identity to one another and convey identity and attribute information in a secure manner. The alliance uses SAML for a large part of its work. A large part of SAML 2.0 are the federation (and others, such as log-out) concepts donated to the SAML group by OASIS.

At this stage, the industry has what is usually considered a de facto standard. A specification has been defined by multiple vendors, although the group is often self-selected. Nevertheless, it is better than the old days when a vendor would, perhaps, publish a specification in a "take it or leave it" manner.

Standardization

The major standards organizations are the W3C and OASIS, formally known as the Organization for the Advancement of Structured Information Standards. W3C tends to be the home for core XML Web services standards, including SOAP, XML Digital Signature (DSIG) and XML Encryption. OASIS tends to have higher-level standards. For example, WS-Security specifies how to use XML DSIG and XML-Encryption to secure the content of SOAP messages. WS-Security also provides a framework for carrying crypto material (such as keys) and identity information (such as a SAML assertion about the sending client), collectively known as "tokens."

At this stage, the industry now has a formal open standard, ratified (and usually modified) by an open standards body. The focus has shifted from primarily vendors to a more open group that includes some representation from customers and other interested parties. Part of the standardization process might include formal and open declarations of licensing terms, and a test suite.

Profiling

Designing a framework is commonplace in the security world. For example, the XML DSIG format supports a wide variety of signature methods, including RSA, PGP, Hashed Message Authentication Code (HMAC) and so on. In order to increase interoperability, it's usually necessary to provide a "profile" of these standards, narrowing the choices, often down to one. This profiling is important work and is the purview of the Web Services Interoperability Organization, WS-I. For example, the pipeline could end up with a result like this:

  • XML DSIG defines three types of signatures, including embedded and detached.
  • WS-Security says how to use detached signatures to secure SOAP messages.
  • WS-I Basic Security Profile (BSP) says to use RSA signature, with exclusive preparation (canonicalization) to format the XML for signing.

The most mature and interoperable standards come from the WS-I end of the pipeline. This includes using WS-Security to secure SOAP messages and WS-Security tokens to carry identity information. SAML is the oldest framework for carrying identity.

Recommendations

For basic two-party interactions, it's best to use the WS-I BSP to specify how to use DSIG and encryption to secure SOAP messages, and SAML to identify the sender. Within an organization, it's feasible to replace SAML tokens with Kerberos tokens, provided that Kerberos is already being used.

If Kerberos isn't deployed, or if seamless interoperability with Internet-based services is expected, consider deploying a public-key infrastructure (PKI) and use X.509 certificates within a WS-Security token. Discussing PKI is beyond the scope of this article, but keep in mind that many PKI installations have stayed in pilot phase, rather than moving to full deployment, so consider a light infrastructure that mainly deploys certificates to servers and network devices.

Later on, when the Web (and business processes) have caught up to spontaneous interactions of new business partners, WS-Workshop specifications like WS-Trust and WS-Policy (which provide a framework for deciding who to trust and what security policy to use for communication, respectively), will be more important.

For now, however, it's safe to focus on two-party interactions. To keep track of where and when the technology will be in place for more complicated interactions, watch WS-I and the new security-oriented working groups within OASIS.

Rich Salz is chief security architect at DataPower, a Cambridge, Mass., vendor of XML-aware networking devices.

Copyright © 2005 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon