Next Previous

Retired Document

Important: This document may not represent best practices for current development. Links to downloads and other resources may no longer be valid.

Security in Web Services

When you need to transmit sensitive information across a network, you should consider the security implications of putting that information on the wire. You should use a level of security that corresponds with the sensitivity of the information you transmit. You should also take into account that adding security processing to message transmission has a detrimental effect on the performance of your applications.

One way you can address security concerns when serving Web services over an unsecure network, such as the Internet, is by exposing them only to trusted entities and specific IP addresses. However, this could reduce the speed at which you can add business partners to your enterprise because it would require manual configuration.

Using standard transport security, such as HTTPS (HyperText Transmission Protocol, Secure) or Secure Sockets Layer (SSL), you can ensure that a message is protected from eavesdroppers during transit. However, while these protocols protect a message as it's transmitted, they do not protect such data once it has reached its destination.

Web Services Security Core Specification (WSS-Core) is a specification that provides a security framework that can be used to secure Web services. It encompasses two major areas: digital signatures and encryption. With digital signatures you can ensure that a particular entity is the sender of a message, even when the message itself may be unprotected. You use encryption when you want to keep communications private, that is, when you want no entity other than the recipient to be able to read a message.

The following list itemizes the four areas that a security model for data communication should address:

Integrity : Allows a message's recipient to ensure that a message hasn't been modified in transit.
Confidentiality : Ensures that a message can be read only by the intended recipient.
Authentication : Allows a recipient to ensure that a particular party is the originator of a message.
Nonrepudiation : Allows a recipient to ensure that a sender cannot deny having sent a message.

Table 2-1 shows the level of security the protocols mentioned earlier provide.

**Table 2-1** Features provided by the major security approaches
	Integrity	Confidentiality	Authentication	Nonrepudiation
SSL/HTTPS	x	x
Digital signature	x		x	x
Encryption	x	x	x	x

This chapter has the following sections:

Web Services Security provides an overview of the WSS-Core specification. It covers digital signatures and encryption.
Canonical XML Documents explains why it's necessary to normalize data before signing or encrypting it.

Web Services Security

Web Services Security Core Language (WSS-Core) is a specification that specifies how to provide a security infrastructure to SOAP (Simple Object Access Protocol) messages. This quality-of-protection model can be extended to incorporate various security models and encryption technologies. Actually, the specification does not provide for the management of keys, certificates, or encryption mechanisms. It just specifies the elements that a SOAP message must have to ensure that it contains an acceptable level of protection against snooping and other types of security threats. For detailed information on WSS-Core, see Web Services Security Core Specification at http://www.oasis-open.org/committees/wss .

SOAP messages using WSS-Core include security tokens that represent claims. For example, a security token can indicate that a Web service client is operating under the "Mary" user name and that she's authorized to view certain data. The security token format is extensible, and a message can use more than one security-token format.

WSS-Core itself is an extension of SOAP. It adds elements to a SOAP message that can be used to enclose security-related information to its Header element. However, WSS-Core is not a security protocol and it does not provide one.

Digital Signatures

The XML Signature specification, which is based on public-key infrastructure (PKI) is an very important part of WSS-Core. It specifies the format of digital signatures in XML documents. XML Signature uses X.509 certificates (digital certificates) to authenticate the purported sender of a message. This is possible because digital certificates, which are issued by a Certification Authority, bind the subject identified by a certificate with its public key. For more information on PKI, see PKI Basics: A Technical Perspective at http://www.pkiforum.org .

The most secure approach to protect a SOAP message is to encrypt the message's payload. However, encrypting entire messages would bring about performance penalties. Therefore, as a general rule only a portion of a message or the message's hash is encoded using the sender's private key. (A hash is a number derived from a string such that any change to the string produces a different number.) This is the electronic version of a manual signature. That way, the message can be easily read by people, while the signature guarantees its integrity and identifies its sender. When the recipient receives a message, it creates a hash of the signed content, decrypts the signature using the sender's public key, and compares the two; if they match it means that the message is authentic.

XML Signature also adds support for integrity and nonrepudiation to XML-encoded messages. Digital signatures can sign individual elements of an XML document. This provides the actors involved in a transaction the ability to sign only the sections of the document for which they are responsible for. In addition, the signed elements do not have to be of the same type.

Figure 2-1 shows the structure of a digital signature element.

The signature element would normally be enclosed in a header-entry element named Security in a SOAP message. Listing 2-1 shows a SOAP message with a digital signature. Notice that the message's Signature element signs the content of the Body element.

Listing 2-1 Example SOAP message using a digital signature

<SOAP-ENV:Envelope

    xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/"

    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

    xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/xx/utility">

    <SOAP-ENV:Header>

        <wsse:Security

            xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/xx/secext">

            <ds:Signature>

                <ds:SignedInfo>

                    <ds:CanonicalizationMethod

                        Algorithm="http://www/w3.org/TR/2000/CR-xml-c14n20001026" />

                    <ds:SignatureMethod

                        Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" />

                    <ds:Reference URI="#Secret">

                        <ds:Transforms>

                            <ds:Transform

                        Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026" />

                        </ds:Transforms>

                        <ds:DigestMethod

                            Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />

                        <ds:DigestValue>...</ds:DigestValue>

                    </ds:Reference>

                </ds:SignedInfo>

                <ds:SignatureValue>...</ds:SignatureValue>

            </ds:Signature>

        </wsse:Security>

    </SOAP-ENV:Header>

    <SOAP-ENV:Body

        xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"

        wsu:Id="Secret">

        <m:GetCurrentTemperature

            xmlns:m="My-URI">

            <m:zipCode>80913</m:zipCode>

        </m:GetCurrentTemperature>

    </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

For detailed information on XML Signature, see An Introduction to XML Digital Signatures at http://www.xml.com/lpt/a/2001/08/08/xmldsig.html .

Encryption

You can encrypt parts of a message when you need to make sure that only its recipient is able to read it. In public-key cryptography, you encrypt data using your private key. The recipient then uses your public key to decrypt the encrypted information. This makes paramount the proper management of public and private keys. Enter public-key infrastructure (PKI).

PKI provides for the creation and issuance of certificates and public and private keys that message encryption and signing processes require. The W3C is developing a standard for XML-based key management. See XML Key Management at http://www.w3.org for details.

Canonical XML Documents

During secure message processing, a message's recipient must ensure that the message was not modified during its travel from the sender. Digital signatures provide proof that the content they sign has not been altered. To make sure signed content—which is probably not encrypted—has not been modified, a recipient must create a hash of the signed information and apply the sender's public key. If the result matches the contents of the SignatureValue element, the content has not been modified.

The problem that arises is that an XML fragments that are functionally equivalent may not be identical. While XML goes a long way in defining a format for structure data, it still leaves room for ambiguity. Look at Listing 2-2 .

Listing 2-2 Person elements

<person id="1001" group="admin">

    <last_name>Morton</last_name>

    <first_name>Ashley</last_name>

</person>

<person id='1001' group='admin">

    <first_name>

        Ashley

    </first_name>

    <last_name>

        Morton

    </last_name>

</person>

The person elements listed are functionally the same; however, they would produce different hashes.

XML fragments (or documents) in canonical form are the normalized versions of XML fragments. These fragments can be signed, verified, encrypted or decrypted with the assurance that formatting artifacts, such as superfluous spaces or attribute ordering, do not play a role in the process. In other words, when you encrypt a document in canonical form and then decrypt it, you get back a document that is almost identical to the original. For more information, see Canonical XML at http://www.w3.org/TR .

The canonical form of an XML element includes all the namespaces in the element's scope, even if they don't apply to the element being normalized. To solve this drawback, another initiative, called Exclusive XML Canonicalization, is used. Essentially, a document in exclusive canonical form includes only the information pertinent to the element being normalized. For more information, see Exclusive XML Canonicalization at http://www.w3.org/TR .

Next Previous