SOAP and Security

Based on the number of questions I get on the subject, quite a few people think that SOAP isn't secure. It's a bit hard to answer these questions because SOAP is neither secure nor insecure. It's not within the scope of SOAP to implement security. SOAP is simply a mechanism to package information to send between two applications. Even so, it's easy to secure SOAP messages, and SOAP provides an extensible mechanism that allows you to convey security information in your messages.

Security is a complicated topic, so let me start by explaining the basic goals of security when dealing with distributed computing.

Message integrity ensures that it isn't modified in transit.
Message confidentiality ensures that the message can only be read by the intended recipient.
Proof of origin provides proof to the receiver that the message indeed came from the sender.
Mutual authentication allows the client to verify the identity of the service and the service to verify the identity of the client.
Authorization controls access to the service.

The most common mechanism used to implement message integrity, message confidentiality, and mutual authentication is a transport-level security system, such as the Secure Sockets Layer (SSL) or Transport Layer Security (TLS). SSL/TLS uses public key encryption to protect messages between two points. If the sender encrypts the message using its private key (as opposed to the receiver's public key), SSL/TLS also supplies proof of origin. All authentication and encryption actions occur at the transport layer, so SSL/TLS security is completely transparent to the communicating SOAP applications.

For simple communications, SSL/TLS is often sufficient, but as things get more complicated, additional security measures are needed. SSL/TLS only protects messages as they are transferred between two network ports. In many cases, a message may need to be routed through one or more intermediaries (such as a firewall or an auditing service) before reaching its final destination. So sometimes you need to use application-level security. Application-level security gives you end-to-end security control. It allows you to establish a separate identity for each service running on a server. It allows you to delegate or propagate security information across multiple hops. And it allows the service to implement authorization controls.

When using application-level security, you need to pass security information, such as user IDs, permissions, and security tokens (X.509 certificates or Kerberos tickets) within the message. A SOAP message normally passes this information in a header element. As the message travels through the routing path to its final destination, each intermediary can prepend additional security information to the security header element to indicate its progress through the path. You can still use SSL/TLS to encrypt these messages, but in some cases you might want to encrypt or digitally sign only certain parts of the message. (You might want to make only certain information available to each intermediary.) In this case, you need to use an application-level encryption service rather than SSL/TLS.

The W3C XML security standards can be used for this. XML Signature provides a mechanism to digitally sign all or part of a message. It relies on Canonical XML to normalize the XML message before encryption, and XML Encryption provides the encryption process. Signature information then needs to be specified in the security header element.

The OASIS Security Assertions Markup Language (SAML) is another handy standard. SAML is designed to support single sign-on operations. It provides a standard format to exchange security information, including authentication assertions, qualifying attribute information, and authorization decisions.

For example, a SAML assertion might specify that my corporate LDAP directory service asserts that I am Anne Thomas Manes, employee of Systinet Corp. This assertion is based on a password challenge that occurred at 11:20:22 on 04/16/02, and I am permitted to submit a purchase order to Acme Supplies for an order not to exceed $5,000; this assertion is good for 30 minutes. Once I obtain this assertion, I can plug it into a header element in a SOAP message containing my purchase order for Acme Supplies. Assuming that Acme Supplies trusts the Systinet LDAP directory service (we have a pre-existing trust agreement), it should allow me to make the purchase without requiring me to sign on to the Acme system directly.

As you can see, the basic technology is in place to support end-to-end Web services security. The only issue still at large is one of interoperability. If two applications are going to exchange security information, they must first agree on how to represent the information within SOAP messages. SAML provides a standard way to represent the security assertions, but we still need to define a standard format for expressing digital signatures and partial encryptions.

IBM, Microsoft, and Verisign recently published a WS-Security specification describing a set of SOAP conventions that can be used to exchange security information and to digitally sign messages. This specification focuses on direct authentication rather than single sign-on and doesn't include support for SAML assertions, but it does address the issues of digital signatures and partial encryptions. Unfortunately the copyright notice at the beginning of the specification makes it clear that it is not available to the general public.

I'd like to see the W3C set up a new working group to define a standard royalty-free Web services security specification. The sooner the better.

Author Bio
Anne Thomas Manes is CTO of Systinet, a Web services infrastructure company. Anne is a recognized industry spokesperson and has published on a range of technology issues. ATM@SYSTINET.com

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.