WS-Security, SAML, Standards and the Future of Webservices

By Peter A. Bromberg, Ph.D.
Printer - Friendly Version

Peter Bromberg

When IBM, Microsoft, and VeriSign announced in July 2002 that they planned to move their proposed WS-Security standard to the OASIS group, they had successfully convinced Sun Microsystems to join the effort, and thus avoided a potential prolonged dispute over how to add baseline security -- things like encryption and digital signature support -- to Web services. But there is a lot more to it than just baseline security. This could be the beginning of a major step forward for webservices.

For enterprises making big commitments on XML webservice based application architectures, there are some important issues that have been put on the table:

  • WS-Security should �have broad support among actual security vendors
  • WS-Security does not answer all the security needs for XML-based Web services
  • Additional specifications may now come from OASIS, not necessarily W3C. OASIS may be replacing the W3C as most important Web services standards body.
  • There is now an opportunity for WS-Security to play well with Secure Assertions Markup Language (SAML).�
  • Let's take� a look at these issues:

    WS-Security : a broad security standard

    The addition of Sun to the "big player list" was an important step forward, and is likely to have a ripple effect as more players decide to finally jump into the webservices pool. Getting everyone around the same table will be good for the entire industry.

    Besides Sun's backing of WS-Security is the fact that most mainstream security vendors -- the big players that will actually deploy and support the specifications -- are already firmly in the WS-Security camp. In addition to VeriSign, security-oriented vendors such as Baltimore Technologies, Entrust, Netegrity, RSA Security, and Novell are WS-Security backers, and they will be involved in creating more security standards at OASIS. Many of these vendors have also been behind SAML, a key standard for enabling cross-platform single sign-on.

    What Does WS-Security Do?

    WS-Security's goal is to specify how to secure Web services -- including encryption and access control -- in a platform-independent manner. It's generally accepted today that security is the key driving force -- and the biggest bottleneck -- in the deployment of Web services by enterprise customers. �By using the SOAP extensibility model, SOAP-based specifications are designed to be composed with each other to provide a rich messaging environment.

    WS-Security defines a set of SOAP headers that can be used to implement security measures for Web services. The WS-Security specification describes how to add encryption and digital signatures to Web services (in each case supporting the W3C's XML-Encryption and XML-Signature). WS-Security also defines a general mechanism for passing around security tokens. These are the foundations of a standardized, industry - wide SOAP security framework.

    The goal of WS-Security is to enable applications to construct secure SOAP message exchanges. The Web services security language must support a wide variety of security models.  The key driving requirements for this specification are:

    •        Multiple security tokens for authentication or authorization
    •        Multiple trust domains
    •        Multiple encryption technologies
    •        End-to-end message-level security and not just transport-level security

    At this point, WS-Security and SAML work together: WS-Security defines how you insert the information into a SOAP envelope, and SAML defines what the security information is.

    The overall thrust with WS-Security is to build a "security stack" in a manner similar to the way the industry built a basic Web services protocol stack with XML Schemas, SOAP, WSDL, and so on. This concept of simplifying and consolidating Web services security efforts is also a key force behind WS-Security.

    WS-Security: Room for improvement

    WS-Security is flexible and is designed to be used as the basis for the construction of a wide variety of security models including PKI, Kerberos, and SSL. Specifically, WS-Security provides support for multiple security tokens, multiple trust domains, multiple signature formats, and multiple encryption technologies.

    As presently composed, WS-Security is not the "end all", but only a start, and the three main supporters -- IBM, Microsoft, and VeriSign -- are aware of this. When they kicked off the WS-Security effort in April, and again when they moved it to OASIS, they emphasized that they planned to deliver a much broader architectural plan for Web services security.� Microsoft's Global XML Web Services Architecture (GXA) is how their version of this vision is laid out.

    The partners, who now include the larger OASIS working group members, are working on specifications in six other important areas.� Of course, there may be some combination and consolidation of these as time goes on. The six proposed specifications come in two major areas, policy and federation:


    • WS-Policy, which is a general purpose spec describing how to express enterprise security policies.
    • WS-Trust, which defines brokered trust relationships a Web services environment.
    • WS-Privacy, which defines a way for Web services to state and implement privacy preferences and practices.


    • WS-Secure Conversation, which defines a general method for managing and authenticating message exchanges between parties.
    • WS-Federation, which describes the management and brokering of trust relationships in a heterogeneous federated environment, including support for federated identities.
    • WS-Authorization, which defines how Web services manage authorization data and policies.

    Backers of WS-Security believe that these are the key technologies required for the provision of a secure Web services architecture. We can expect to see formal, written specifications for each of these areas by the end of the year 2002. Once that is completed, the OASIS working group handling Web services security will work to put all these facets together.

    �The W3C and Standards

    There appears to have been a shift in power among standards bodies. The bureaucracy of the W3C is increasingly frustrating many players.� So while the W3C will continue to hold an important influence over most core Web standards like XML, the OASIS organization has now moved into a dominant role in developing and promulgating standards, at least insofar as webservices security is concerned.

    WS-Security and SAML

    SAML is a specification which defines a standard, XML-based approach for passing security tokens defining authentication and authorization rights. Originally, SAML was targeted more toward distributed authentication and single sign-on. But those concepts are also central to Web services, and with both SAML and WS-Security now domiciled at OASIS, some integration and change is likely to be seen. The two security approaches should be able to work together and eventually give enterprises some quality choices about how to secure Web services.

    SAML has already adopted WS-Security as the appropriate method for "binding" SAML assertions into SOAP messages. Version 1.0 of SAML came up to a vote in July 2002; it is expected to be approved as standard by fall 2002. SAML 1.0 won't include a formal SAML-over-SOAP definition in its first iteration, but you can expect future versions of the SAML spec to adopt WS-Security.

    WS-Security is a major extension to the concept of the SOAP envelope header. With WS-Security you can use any security token you want. WS-Security is the messaging language; SAML is the security language.� These two specifications should work together very nicely. The bottom line for developers is that we now have a stable foundation emerging that allows us to forge ahead with plans for an extensible, standards-based webservice architecture in our applications, and to be reasonably confident that this foundation will remain solid and dependable.


    Peter Bromberg is a C# MVP, MCP, and .NET consultant who has worked in the banking and financial industry for 20 years. He has architected and developed web - based corporate distributed application solutions since 1995, and focuses exclusively on the .NET Platform.