Getting Started with XML Security

XML Security Applications

The XML Security standards form the basis for providing security to other XML-based initiatives, such as Web Services and Digital Rights Management.

Web Services Security: Roadmap and WS-Security

Purpose and Benefits

Web Services rely on XML Protocol ( SOAP) messages to link applications within an enterprise or across enterprises in an interoperable, platform-independent and programming language-neutral manner. This allows applications to be loosely coupled and integrated much more easily, inexpensively, and quickly than before. Ensuring that these interconnections are secure is essential to the future of Web Services.

Features

Microsoft and IBM have released a Web Services security architecture and roadmap [ WebSvcSecRoadmap ] that outline a strategy and series of specifications to bring together different security technologies. The aim is to provide a unified, flexible and extensible security framework for Web Services. This architecture defines higher-level security requirements and terminology to allow those requirements to be met using one or more different security technologies. This use of high-level abstraction supports the goal of compatibility with existing and emerging security technologies.

The WS-Security specification outlines how XML Digital Signatures and XML Encryption may be used with XML Protocol (SOAP) messages as well as how security claims (such as identity credentials, for example) may be included with a message. This security mechanism goes beyond the SSL/TLS [ SSL-Intro, TLS-RFC ] transport security mechanism, since it defines an end to end security mechanism and provides support for intermediary security processing.

The other specifications will be rolled out in a two-phase process. The first phase will include specifications necessary for Web Services Security across trust domains:

WS-Policy

Specify security requirements, capabilities, constraints and policies on Web Services intermediaries and endpoints

WS-Trust

Define security trust model allowing interoperation across security trust domains

WS-Privacy

Define a model for web service clients and services to state privacy preferences and practices

The second phase is intended to include those specifications for meeting more advanced requirements, specifically:

WS-SecureConversation

How to dynamically establish trust across trust domains using key exchange

WS-Federation

How to manage identities and other information across heterogeneous federated systems

WS-Authorization

How to manage authorization data and policies in a Web Services environment.

Key Concepts

One of the fundamental aspects of the Web Services Security Architecture is to define general terms for concepts, enabling the Web Services security standards to allow for different diverse security technologies, such as Public Key Infrastructure (PKI) as well as symmetric key systems such as Kerberos. Some of the concepts defined in the architecture include:

Principal

A person, application or business entity that can send or receive web service messages.

Claim

A statement (or assertion) about a subject that associates the subject with a property, such as the subject's identity, authorization, or other information. A claim may be made by a subject or some other party.

Token

A token is a representation of security related information and may be used to represent and substantiate a claim. A token may be unsigned (such as a shared secret password used to support an identity claim) or signed (such as a PKIX Identity certificate, a Kerberos ticket, or an authorization certificate). Use of an unsigned token may require secure transport such as provided by SSL/TLS or a VPN.

Note that having a token is often not enough - a signature is also required to demonstrate proof of possession of material associated with a token. An X.509 certificate, for example, may serve to demonstrate the binding of an identity with a public key, but proof of ownership of the corresponding private key may be provided by including a signature using that private key.

The architecture defines two base aspects of Web Services Security that are addressed. First is end to end message integrity and confidentiality, including consideration of the implications of intermediary processing. Second is the definition of secure web services endpoint processing, based on the ability to require some set of claims (a policy) to be met before performing processing. The message security model has been outlined in the WS-Security [ WS-Security ] specification. The roadmap outlines a number of other specifications and how they will relate to each other and potential scenarios.

WS-Security defines how to extend SOAP to provide integrity and confidentiality and how to include security tokens in messages. This includes defining how to encode binary formats, including X.509 certificates and Kerberos tickets. The latest version of the Web Services Security Language (WS-Security) specification supersedes earlier specifications, including SOAP-SEC, WS-Security and WS-License from Microsoft. The specification addresses explicit requirements for supporting multiple security tokens, trust domains, and encryption technologies as well as supporting end to end integrity and confidentiality.

Examples

SOAP messages are defined to include a header and a body. Generally the payload is carried in the body of a SOAP message, and control information, such as that needed for intermediary processing and routing, is carried in the header. The WS-Security specification defines a <Security> XML element to be used in the SOAP message header to meet the SOAP security requirements. Thus, a simple SOAP stock quote request might be structured as follows, using an example given in WS-Security:

<?xml version="1.0" encoding="utf-8"?>        
<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"          
           xmlns:ds="http://www.w3.org/2000/09/xmldsig#">        
   <S:Header>        
       <!-- WS-Security specific information here -->        
       <wsse:BinarySecurityToken          
           xmlns:wsse="http://schemas.xmlsoap.org/Ws/2002/04/secext"          
           Id="myToken"          
           ValueType="wsse:X509v3"          
           EncodingType="wsse:Base64Binary">        
                MIIEZzCCA9CgAwIBAgIQEmtJZc0...          
       </wsse:BinarySecurityToken>        
       <wsse:Security          
           xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext">        
                   
           <ds:Signature>        
           <!-- XML Digital Signature on the MsgBody below        
                to provide payload integrity -->        
           </ds:Signature>        
       </wsse:Security>        
   </S:Header>        
   <!-- the Id provides a simple way for the security part        
        of the header to refer to the body -->        
   <S:Body Id="MsgBody">        
       <tru:StockSymbol xmlns:tru="http://fabrikam123.com/payloads">        
           QQQ          
       </tru:StockSymbol>        
   </S:Body>        
</S:Envelope>
Example 15 - Signed SOAP Request

This example shows use of a binary security token in the SOAP header. Used to convey key information, it includes the following identifying information:

• ValueType - what it is. Definitions include X.509V3 certificate, Kerberos ticket granting ticket, Kerberos service ticket.
• EncodingType - how it was encoded, such as base64 or hex encoding.

Alternately, a <KeyInfo> element , or a name and password token (over a secure transport like SSL/TLS) may be used. A security token may be combined with an XML Digital Signature by using a signature <Reference> to the token contained in a message header. This requires a <KeyInfo> extension defined in WS-Security.

Confidentiality of header and body elements may be provided using XML Encryption. As discussed in the previous section on XML Encryption, the encrypted element or element content is replaced by an <EncryptedData> element. Whenever an element or element content in a SOAP message is encrypted, a sub-element is required to be added to the <Security> element in the SOAP header:

An <xenc:ReferenceList> element may be added, giving the Id (fragment URI) of the <EncryptedData> element. This is most useful when key information is shared out of band. An example is:

<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"          
           xmlns:wsse="http://schemas.xmlsoap.org/Ws/2002/04/secext"          
           xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">        
   <S:Header>        
       <wsse:Security>        
           <xenc:ReferenceList>        
               <xenc:DataReference URI="#bodyID" />        
           </xenc:ReferenceList>        
       </wsse:Security>        
   </S:Header>        
   <S:Body>        
       <xenc:EncryptedData Id="bodyID">        
           <ds:KeyInfo>        
               <ds:KeyName>CN=Smith Joe, C=US</ds:KeyName>        
           </ds:KeyInfo>        
           <xenc:CipherData>        
               <xenc:CipherValue>...</xenc:CipherValue>        
           </xenc:CipherData>        
       </xenc:EncryptedData>        
   </S:Body>        
</S:Envelope>
Example 16 - Encrypted SOAP Payload

An <xenc:EncryptedKey> element is added to carry the encrypted key used to encrypt the portion of SOAP, to convey a symmetric key.

Attachments are possible using the same mechanism for providing email attachments, multi-part MIME (Multi-Purpose Internet Mail Extensions). Such attachments may be encrypted using XML Encryption.

The WS-Security specification gives detailed processing rules, examples and information about special issues such as canonicalization, so for more information refer to the specification [ WS-Security ].