[Cache from http://home.earthlink.net/~fjhirsch/xml/xmlsec/starting-xml-security.html; please use this canonical URL/source if possible.]

©Copyright 2002 Frederick Hirsch. Please do not reprint without permission.

Available at http://www.fjhirsch.com/xml/xmlsec/starting-xml-security.html

All names and identifiers in the examples are meant to be fictitious.

$Header: /usr/local/cvsrep/article/starting-xml-security.html,v 1.7.2.10 2002/08/07 22:16:38 fjh Exp $

1. Executive Summary

2. Introduction

Security has always been vitally important in the business world to ensure the integrity of content and transactions, to maintain privacy and confidentiality, and to make sure information is used appropriately. However, in today's web-based business environment, the means for providing that security have changed. Using physical security no longer works as well as it did in the past when all the computing resources were locked in a central computing room with all jobs submitted locally. Efforts to create a single pervasive security infrastructure do not scale effectively to the Internet, due to the heterogeneous nature of hardware and software systems and to conflicting administrative, application and security requirements. There is too much to administer, too many applications, too many variations, and too rapid a pace of technology change to design a single infrastructure to meet all requirements effectively. Extensible standards are required that can adapt to changing requirements, that can incorporate new technologies while continuing to work with legacy technologies, and that can be deployed modularly as needed without requiring use of unnecessary portions. These standards should work well together, not replicate functionality, and should fit with new technologies to enable open distributed systems, application integration and content management.

An essential requirement of new security standards is that they work naturally with content created using eXtensible Markup Language (XML). XML is being adopted widely for a growing variety of applications and types of content. It is also forming the basis for distributed system protocols to integrate applications across the Internet, such as Web Services protocols. XML languages are text based and designed to be extended and combined. It should be natural to provide integrity, confidentiality and other security benefits to entire XML documents or portions of these documents in a way that does not prevent further processing by standard XML tools [ XMLRef ]. XML Security therefore must be integrated with XML in such a way as to maintain the advantages and capabilities of XML while adding necessary security capabilities. This is especially important in XML-based protocols, such as XML Protocol (XMLProt, Simple Object Access Protocol, SOAP), that are explicitly designed to allow intermediary processing and modification of messages.

Older security technologies provide a set of core security algorithms and technologies that can be used in XML Security, but the actual formats used to implement security requirements are inappropriate for most XML Security applications. One reason is that these standards use binary formats that require specialized software for interpretation and use, even for extracting portions of the security information. A second reason is that these standards are not designed for use with XML and do not support common XML technical approaches for managing content, such as specifying content with uniform resource identifier strings (URIs) or using other XML standard definitions for locating portions of XML content (like XPath [ XPath ]). In addition, some existing security technologies assume that security-specific software will be integrated with applications to enable security. In practice, this is not always the case due to the details of custom integration.

XML Security addresses these issues by defining a common framework and processing rules that can be shared across applications using common tools, avoiding the need for extensive customization of applications to add security. XML Security reuses the concepts, algorithms and core technologies of legacy security systems while introducing changes necessary to support extensible integration with XML. This allows interoperability with a wide range of existing infrastructures and across deployments.

XML Security reduces barriers to adoption by defining the minimum modular mechanisms to obtain powerful results. By employing existing technologies and enabling use of XML paradigms and tools, XML Security minimizes the need to modify applications to meet security requirements.

This document summarizes the key XML Security technologies and provides an overview of how they fit together and with XML. It should serve as a roadmap and basis for further exploration of the related specifications. Most of the specifications are early in the definition process and are currently undergoing rapid change, so the interested reader is encouraged to turn to the specifications himself to learn the latest details.

This article assumes a basic understanding of XML and security concepts, but in order to provide a starting point, it presents a very brief introduction to those two subjects. This is followed by an overview of the following core XML Security standards:

• Integrity and signatures - XML Digital Signature
• Confidentiality - XML Encryption
• Key Management - XML Key Management Specification (XKMS)
• Authentication and Authorization Assertions - Security Assertion Markup Language (SAML)
• Authorization Rules - XML Access Control Markup Language (XACML)

• Web Services Security - Roadmap and WS-Security
• Privacy - Platform for Privacy Preferences (P3P)
• Digital Rights Management - eXtensible Rights Markup Language 2.0 (XrML)

2.1. XML

XML languages created by different people may be combined. If you define a language for expressing addresses, for example, and I define one for purchase orders, I may reuse your address language within my purchase order language. To associate elements with the appropriate schemas and to avoid conflicting elements, XML namespaces may be used. XML namespaces associate tags with unique identifiers (URIs) and may be used to avoid ambiguity [ Namespaces ]. A well-formed XML document may be processed using general XML-aware tools, including parsers that understand the general rules of XML syntax and processing. An advantage is that use of these tools does not depend on the specific vocabulary defined in a particular document. This means that once general tools have been created they may be used for many applications of XML. This allows reuse of tools and training, another advantage of XML.

Many XML languages have already been defined, including XHTML for creating web pages, DocBook for creating technical documentation, RSS for content distribution (syndication), RDF for representing information,MathML for mathematics markup, BRML for business reports, and many others.

The following example shows a language for managing office medical records, including XML elements like <PatientRecord>, <Name> and <Diagnosis>. It also shows the use of an XML Namespace associated with a lab, to allow a <lab:Diagnosis> element that does not conflict with the office <Diagnosis> element.

2.2. Security

Security is vital to online business. Technologies designed to meet security requirements have evolved, but the requirements have remained relatively constant. These requirements include Authentication, Authorization, Integrity, Signature, Confidentiality, Privacy and Digital Rights Management and are briefly summarized below:

Authentication - Who is it?

Determine the identity or role of a party attempting to perform some action such as accessing a resource or participating in a transaction. A role may be appropriate to many parties, for example "Human Resources Person".

Authorization - What can they do?

Determine whether some party is allowed to perform a requested action, such as viewing a web page, changing a password, or committing an organization to a 10 million dollar transaction.

Integrity - Ensure that information is intact

Ensure that information is not changed, either due to malicious intent or by accident. This may be information transmitted over a network, such as from a web browser to a web server, information stored in a database or file system, or information passed in a web services message and processed by intermediaries, to give a few examples.

Signature - Create and verify electronic signatures analogous to handwritten signatures

Produce or verify an electronic signature intended to be the equivalent of a handwritten signature. Such a signature may be used for different purposes such as approval, confirmation of receipt, acceptance or agreement.

Confidentiality - Make content unreadable by unauthorized parties

Ensure that content may only be viewed by legitimate parties, even if other access control mechanisms are bypassed. Confidentiality is generally associated with encryption technologies, although other approaches such as steganography (information hiding) might serve a similar purpose.

Privacy - Limit access and use of individually identifiable information.

Personally identifiable information is required by individuals and companies in order to perform services for the individual. An example is a Doctor's office that requires medical records to track a patient's health. Privacy relates to control over what is done with this information and whether it is redistributed to others without the individual's knowledge or consent. Privacy may be managed by a combination of technical and legal means. Confidentiality technology may be used to protect privacy, but cannot prevent inappropriate sharing of information.

Digital Rights Management - Limit use and sharing of content according to license agreements

Ensure that content is used according to license agreements. Generally access rules are incorporated with the content, and enforcement controls are integrated with the clients needed to use the content.

Traditionally, security technologies have required applications to be security or Public Key Infrastructure (PKI) "enabled". This often involves integrating specialized security code with the application in order to meet security requirements. This created a slow, cumbersome and inflexible customization process. An alternative is to create generic XML tools and generic XML Security and then allow them to be used with a variety of XML applications. This allows generic XML Security filters to be applied to arbitrary content without requiring extensive customization for each application, reducing costs and delay.

3. XML Security

XML Security standards provide a set of technical standards to meet security requirements. These standards are designed to conform to common XML paradigms. The XML Security standards leverage existing XML standards and also enhance XML standards as follows:

1. The XML Security standards define XML vocabularies for representing security information, using XML technologies, such as XML Schema, for definition. An example is the <KeyInfo> element defined in the XML Digital Signature recommendation for carrying signing or encryption key information. This definition is used in a number of the specifications. The specifications define a shared meaning for the XML vocabularies.
2. The XML Security standards use other existing XML standards where possible to leverage current XML efforts. For example, XML Digital Signature allows XPath expressions to extract portions of XML for processing. (Defined in [XMLDigSig] and extended in [ XPathFilter ]).
3. The XML Security standards are designed to offer the flexibility and extensibility aspects of XML. They allow security to be applied to XML documents, to XML elements and element content, as well as to arbitrary binary documents. They support extending the XML vocabularies through the use of XML namespaces and extensible XML Schema definitions.
4. XML Security technologies may be applied to end-end security, which is especially important when XML messages are routed through a number of processing intermediaries. Persistent security is associated with the content, rather than with a transport pipe. The security remains with the content. XML Security technologies may be used in conjunction with transport security technologies, such as SSL/TLS, as well.
5. XML Security technologies reuse existing cryptographic and security technologies whenever possible, without reinventing the wheel. For example, X.509 V3 certificates [ X509Cert ] are used without redefinition when needed - they are simply encoded in a text format. Existing algorithms, such as the SHA1 digest algorithm, are also brought into the XML Security standards world by associating unique URI identifiers with them and defining how they may be used in the XML Security processing models.

3.1. Core XML Security Standards

1. XML Digital Signature for integrity and signatures,
2. XML Encryption for confidentiality,
3. XML Key Management (XKMS) for key management,
4. Security Assertion Markup Language (SAML) for making authentication and authorization assertions, and
5. XML Access Control Markup Language (XACML) for stating authorization rules.

Each standard defines the XML vocabulary necessary for describing the security information required for that aspect of security, as well as the processing rules necessary to understand how to apply the standard.

3.1.1. Integrity & Signatures: XML Digital Signature (XML DigSig)

3.1.1.1. Purpose and Benefits

1. To provide persistent content integrity, and
2. To create and verify portable electronic signatures

Electronic signatures offer the digital equivalent of handwritten signatures and may be used for a variety of purposes such as content approval, receipt confirmation, and contract agreement. Using digital signatures makes it possible to move business workflows online, without requiring manual approval steps. This can reduce the delays, costs and inconveniences caused by geographic separation and time zone differences. Digital signatures use cryptographic techniques to construct signatures that are stronger and more portable than other techniques for creating "electronic signatures".

3.1.1.2. Features

1. Entire XML documents as well as element and element content portions of XML documents,
2. Arbitrary documents, including binary documents,
3. Compound documents including multiple documents and/or XML elements and element contents,
4. Properties to be included with a signature,
5. Counter-signatures (signatures that include other signatures)

An XML <Signature> element may be handled in different ways, based on the desired application. It may be placed in a document apart from what is signed. This is known as a "detached" signature, and is used when signing non-XML content. When XML content is signed, the <Signature> element may be added to the XML. This is convenient, since signatures may then be bundled within the content and remain embedded with it, making it easy to keep track of them. When placed in an XML document, the <Signature> element may be added to the document being signed under the document element (an "enveloped" signature). In some cases, it is useful to place the content being signed within the <Signature> element, an example being a signature property (an "enveloping" signature).

If a signature is added to the <PatientRecord> as an enveloped signature, for example, the <Signature> element would be a child of the <PatientRecord> as follows:

When a signature is added to a document as part of the document, it changes the document. To verify the signature, it is necessary to compare the original document without the signature. The XML Digital Signature recommendation defines a mechanism for removing the <Signature> as part of the verification process.

Another possibility is to create a new XML document with a <Signature> document element and to place the signed element as a child of the <Signature> element. This is usually reserved for information associated with a signature, such as the purpose of the signature, for example:

3.1.1.3. Key Concepts

The following concepts are central to understanding XML digital signatures:

1. A signature is only valid if the signed content has not changed. This content is represented using a short, fixed-length digest, designed to change if the content changes. Thus a signature will only be valid if a digest used to create a signature is the same as a digest used to verify it later. A verifier can create a digest to see if it is the same.
2. An XML <Signature> element is an XML structure that contains a cryptographic signature value in a <SignatureValue> element as well as an XML structure that has been signed, the <SignedInfo> structure. This means that the contents of the <SignedInfo> structure should not change for the signature to be valid.
3. The signer creates a <Reference> for each item to be included in a signature. Each <Reference> includes a digest of the item and a unique identifier (URI) for the item. It also identifies how to recreate the digest, specifying the algorithm and other necessary information. Each Reference is part of the <SignedInfo> structure.

   To verify a signature, a recipient must validate each <Reference> by independently generating the same digest for the item. The verifier may use the URI to aid locating the item, and the algorithm information to know how to generate the digest. If the item has not changed, the digest should be the same.

4. A reference may refer to anything using a URI, including non-XML content such as image and text files. It is not required to obtain the item using the URI, but it is often useful. A special form of URI may be used to refer to XML elements within the same document as the signature, allowing signatures to be transferred along with XML content to be signed.
5. A <Reference> may specify one or more transforms to be applied to an item before creating the digest. One use is to sign parts of an XML document that are known not to change - such as boilerplate for example. This may be done by defining transform to extract the portion of the document to be signed, using standard XML XPath expressions for example.
6. Digest algorithms require content to be exactly the same to produce the same digest. Even a minor change that does not change the meaning, such as adding an extra space, will invalidate the digest. XML, on the other hand, allows some variation in the syntax of the XML text without changing the document. In other words, two XML documents may be considered the same even if they do not have the exact same text. For example, one XML document may use single quotes for an attribute and another double quotes. These are the same to an XML parser, but very different to a digest algorithm. There is an entire list of such potential issues for digests. To get around this problem, a Canonicalization transform may be used, one that converts any XML document to a form using a single set of rules, such as always using a certain type of quote for attributes.

3.1.1.4. Examples

Note that there is a single reference with URI "", meaning "this document". If only the <Account> element were to be signed, it could be referenced using the id attribute value, as follows: <Reference URI="#acct">. If there was no id attribute (perhaps signing wasn't anticipated), an XPath expression could be used, producing the following <Reference>:

3.1.2. Confidentiality: XML Encryption (XML Enc)

3.1.2.1. Purpose and Benefits

The owner of content may encrypt it to make it confidential. This will make the content unintelligible until it is decrypted. Encryption is generally performed using symmetric key encryption, since this is an efficient technique even for large documents. Symmetric key encryption uses the same key for both encryption and decryption. To send confidential information to a receiver, the sender must also share the symmetric key with the recipient but not anyone else. This can be difficult without person to person contact.

To avoid this problem and make it easier to share confidential content with a number of people, asymmetric or public-key cryptography was designed. Public key cryptography uses a matched pair of keys, one for encryption and one for decryption. This allows the sender to encrypt using the recipient's public key, a key that can be shared widely. Decryption requires use of the recipient's private key, known only to them. This helps address the difficulty of establishing confidential communication. Because public key cryptography is less efficient than symmetric cryptography, they are typically used together. The symmetric key is used to encrypt the content, and then the symmetric key is encrypted using public key cryptography. Both the encrypted content and encrypted symmetric key are then sent to the recipient.

1. Encrypt the content using a symmetric key
2. Encrypt the symmetric key using the recipient's public key
3. Package the encrypted content, encrypted key and necessary algorithm information together
4. Send the package to the recipient

1. Unpack the package to obtain the algorithm information, the encrypted symmetric key and the encrypted content
2. Decrypt the symmetric key with their private key
3. Decrypt the content with the symmetric key

3.1.2.2. Features

1. XML and non-XML content may be encrypted, giving broad applicability to the recommendation.
2. Confidentiality may be applied at a fine level of granularity to XML content. It may be applied to XML elements and XML element content as well as entire XML documents. This is valuable for securing portions of XML Protocol messages to be routed through intermediary processors.
3. XML Encryption produces well-formed XML from well-formed XML. This allows portions of XML content to be encrypted yet subsequently processed by XML tools.
4. XML Encryption is compatible with and may be used in conjunction with XML Digital Signatures.
5. XML Encryption allows for encryption of a symmetric key that may be packaged with encrypted content.
6. XML Encryption supports a variety of encryption algorithms and techniques.

3.1.2.3. Key Concepts

1. When an XML element or element content is encrypted, it is replaced by an <EncryptedData> element.
2. When non-XML content is encrypted, the result is a new XML document containing an <EncryptedData> element.
3. An <EncryptedData> element may include a Type attribute to assist the recipient in decrypting it. This Type may indicate that an XML element or element content was encrypted, or give the type of other information, such as images for example. This is done using an existing standard for mail attachments, known as MIME types.
4. The <EncryptedData> element defines the algorithm used for encryption, provides the encrypted content, and may include information necessary to determine the key needed for decryption.
5. The symmetric key used to encrypt content may be conveyed in an <EncryptedKey> element.
6. XML Encryption supports the selection of appropriate encryption algorithms and defines XML identifiers for common cases and may be extended for others.
7. Definitions for identifying key information are based on XML Digital Signature definitions and extended.
8. User-defined properties may be associated with an encrypted element, such as a timestamp or log reference.
9. The actual cipher text, the result of encryption, is specified using a <CipherData> element. This may contain the actual encrypted data within a <CipherValue> element, or a URI reference to encrypted data that is stored elsewhere (<CipherReference>). A reference is useful when the encrypted data is large and not needed by most parties, such as processing intermediaries.

There are additional security issues raised by XML Encryption, particularly those of "known plaintext attacks". If it is known that particular text was encrypted, such as an element (such as <Visit>, for example) it can make it easier to break the encryption. Because XML is verbose, and the names of elements may be known from the schema definition of the XML vocabulary, it is more likely that plaintext attacks are possible. As a result, additional care must be taken in choosing the encryption algorithms and their parameters to prevent use of this information from removing confidentiality.

3.1.2.4. Examples

Use of both <EncryptedData> and <EncryptedKey> elements may be summarized using the previous example where the account information is encrypted for confidentiality. Additional information on the EncryptedData and EncryptedKey portions of this example are explained in the XML Encryption candidate recommendation [ XML Enc ]:

3.1.3. Key Management: XML Key Management Specification (XKMS)

3.1.3.1. Purpose and Benefits

The XML Key Management Specification (XKMS) [ XKMS ] defines protocols for Public Key management services. Public Key management includes the creation of a public and private key pair, the binding of this key pair with identity and other attributes, and the representation of this key pair in different formats, such as by key name, digital certificate or key parameters, to give some examples. Public key technology is an essential part of XML Digital Signatures, XML Encryption and other security applications. When signing, the private key is used to sign and the public key is used to verify signatures. When encrypting, the public key is used to encrypt and the private key is used to decrypt. In either case the private key must be maintained under control of the owner and the public key may be shared with others. XKMS is designed to help manage the sharing of the public key to enable signature verification and encrypting for recipients.

Public Key management usually requires a registration step in which the key pair is generated and some sort of token is issued to associate the public key with the identity and other attributes of the owner. This registration step usually incorporates some sort of due diligence to reduce the risks of associating the public key incorrectly, since people will rely upon the key pair later. Management also includes the ability to revoke the association of information with the key pair should circumstances change, such as the theft of the private key or a change in the owner's attributes (no longer an employee, for example). Likewise, information bound to the key pair may be updated. Traditionally, such bindings were managed using X.509 Digital Certificates, specialized protocols and public key infrastructures. XKMS defines XML message formats to support requests and responses for public key management, including registration, revocation and updates. This eliminates the need for applications to support other specialized public key registration and management protocols.

Once registration is complete, a public key pair may be used for signing and verification or encryption and decryption. The <KeyInfo> element defined in the XML Digital Signature recommendation may be used to provide information to the recipient of a digital signature or encrypted data block about the key needed to process that content. This information may take on a number of different forms, such as a key name, a digital certificate containing the public key, a set of key parameters, or a URI indicating where to obtain the public key. Given the variety of choices for providing information about a key to a recipient, it may be hard for an application to process and locate a key. In addition to the difficulty of anticipating all formats, some, such as X.509 certificates, require special cryptographic code and logic for processing. XKMS provides an XML message format to allow this processing to be performed by a service which will sort through the various options, determine the one that was used, and provide the key information to the recipient in a useful form.

3.1.3.2. Features

• XML Key Registration Service Specification (XKRSS),
• XML Key Information Service Specification (XKISS)
• Protocol Bindings

The registration service supports the binding of information with a public key pair, either one generated by the server or by the client. The binding associates information with the key pair, creating a <KeyBinding> element. This binding may have a validity period associated with it and may be reissued or revoked. The private key associated with a key binding may also be backed up recovered if the local copy is destroyed (as when an operating system requires reinstallation).

The key information service allows a client to request information associated with a <KeyInfo> element. This may include:

1. Locate - Resolve the <KeyInfo> element to return requested key information
2. Validate - Locate key information and provide an assertion on the validity of the binding to the key pair.

The Protocol Bindings specification defines mechanisms for meeting security requirements, including mechanisms to ensure message confidentiality, integrity, and security. This includes the following definitions:

• A two phase protocol to avoid replay attacks
• Pending response protocol
• Use of payload security
• Use of transport security such as SSL/TLS
• Use of Web Services security (see below)

3.1.3.3. Key Concepts

1. This specification defines XML protocol messages to convey key registration and information requests to a trust server and to convey responses from the server. The specification defines a binding of these messages to the XML Protocol (SOAP) and defines the relationships among the messages using the Web Services Definition Language (WSDL).
2. <ds:KeyInfo> processing is delegated to the trust service by the client, minimizing the complexity of the client. How the trust service is implemented is dependent on the service, but acting as a front-end to a public key infrastructure (PKI) is one possibility.
3. The XML Key Information Service Specification (XKISS) includes online status functionality equivalent to that in traditional PKI OCSP protocols as part of the Validate functionality.
4. Registration supports the requirements of smart card manufacturing, including bulk processing and pending responses.
5. The specification supports the use of XML Digital Signatures for message integrity and authentication. The specification also defines other authentication mechanisms, support for proof of key ownership and other security functionality.
6. A Locate or Validate request may include a <KeyInfo> element and <RespondWith> element in the request. The <RespondWith> element is used to specify what the <KeyInfo> element is to be resolved to, possibly more than one item. For example, the request <KeyInfo> might contain an X.509 certificate and the <RespondWith> might indicate that the KeyName and KeyValue are to be returned. Possibilities include KeyName, KeyValue, and Certificate, Certificate Chain (collection of certificates needed to trace a signature back to a trusted party) among the possibilities outlined in the specification.
7. A <KeyBinding> element is used to associate information with a key. This is what is returned in a Locate or Validate response. Every <KeyBinding> includes a <ValidityInterval> (NotBefore, NotOnOrAfter) and may also include <KeyInfo>, <ProcessInfo> (opaque data), <KeyUsage> and <UseKeyWith> elements.
8. Key usage definition is deliberately limited to Encryption, Signing and Key Exchange.
9. A <KeyBinding> <UseKeyWith> element defines which application and application entity the key is intended for. For example, a key may only be appropriate for authentication of an SSL server. In this case, the application is HTTPS, and the identifier is the URL of the server. Applications listed in the specification include S/MIME, HTTPS, SMTP, IPSec, PKIX and others.

3.1.3.4. Examples

A client might generate a key pair and wish to register it with a trust server, as in this example. (Complete examples are provided with the XKMS specification):

The server responds with the information requested with <RespondWith>:

A client could request an identity validation:

The following response indicates that the certificates are valid:

3.1.4. Authentication and Authorization Assertions: Security Assertion Markup Language (SAML)

3.1.4.1. Purpose and Benefits

Authentication is the process of establishing identity. This is required to limit access to resources, to identify participants in transactions, and to create seamless personalization of information based on identity. A means of sharing the fact that authentication has been performed successfully is necessary to allow "single sign-on" as well as to allow third party authentication services.

An example is a travel portal offering destination information, flight schedules, the ability to make reservations and other services. To a customer, it should appear as a single web site, but in fact different systems may be cooperating to implement the service. For usability and transparency, a customer should only need to authenticate once to the portal, and information on the successful authentication should be shared with the different underlying systems, with some validity period. A general requirement when using multiple networked systems is "single sign-on" - authenticating once and then sharing the result of authentication with multiple systems to avoid repeated authentication.

Related to authentication is authorization, the process of determining whether an authenticated party should be able to access a resource or perform an action. To give an example, human resources salary information may only be accessible to certain employees of a company, or only to members of the HR group. Such access control is based on the authenticated identity of an individual. To give another example, only specific individuals or individuals acting in specific roles should be able to enter into high value transactions on behalf of a company. Access control rules may be based on authenticated identity, the resource or action and other information, such as the time of day, day of week, or content of transactions.

3.1.4.2. Features

The XML Security Assertion Markup Language (SAML) defines an XML vocabulary for sharing security assertions, including authentication and authorization assertions, enabling "single sign-on" and third party management of these functions. It also defines a Request/Response protocol definition and an XML protocol (SOAP) binding. The SAML specification defines a general assertion framework, allowing assertions to be given validity time periods, and allowing assertions to be targeted to specific audiences (avoiding the potential for misuse). Assertions are associated with a given "subject" or named entity.

3.1.4.3. Key Concepts

1. An XML vocabulary for expressing authentication and authorization assertions, allowing statements about how and when authentication and authorization occurred to be passed among parties.
2. A request response protocol for conveying SAML assertions, as well as an XML protocol (SOAP) binding.
3. Unique identifiers (URNs) for different authentication mechanisms and authorization actions.
4. How digital signatures are associated with assertions.

A SAML AuthorizationDecisionStatement may be used to assert that a request by a subject to access a specified resource has resulted in the specified decision, and may optionally include evidence to support the decision.

The SAML security considerations document discusses issues of security and privacy associated with SAML. For details see the SAML specifications [ SAML ].

3.1.4.4. Examples

The following simplified authentication assertion example states that John Doe was authenticated using SSL client certificate authentication:

The SAML specifications allow more complicated authentication statements, including the ability to include information needed to confirm subject identity, such as <KeyInfo> - see the SAML specification for details [ SAML ].

The following example shows a response permitting John Doe to access a web resource:

3.1.5. Authorization Rules: XML Access Control Markup Language (XACML)

3.1.5.1. Purpose and Benefits

3.1.5.2. Features

1. An XML vocabulary for expressing authorization rules
2. An XML vocabulary for expressing a variety of conditions to be used in creating rules.
3. How rules are to be combined and evaluated
4. A means for creating policy statements, a collection of rules applicable to a subject.

3.1.5.3. Key Concepts

1. The XACML draft uses the SAML definitions for subjects and actions.
2. XACML defines rules as targets, effects and conditions.
3. A target includes resources, subjects and actions, as defined in SAML.
4. An effect is either "Allow" or "Deny".
5. Conditions are predicates and attributes defined in the XACML specification.

3.1.5.4. Examples

To make this concrete, consider the following rule taken from the XACML draft. This example will grant read access to records documents on the medico web site only if the SAML subject is the patient:

Rules may be combined, and the XACML includes a specification on how this is done. In addition, rules may be collected into policy statements, including a target, rule-combining algorithm specification, a set of rules, and obligations. The target of a policy statement is used to determine where the policy is applicable and may be stated explicitly or derived from the targets of the policy rules. An obligation is an action to be performed once the authorization decision is complete. An example is sending a patient a notification email each time his or her record is accessed.

3.2. XML Security Applications

3.2.1. Web Services Security: Roadmap and WS-Security

3.2.1.1. 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.

3.2.1.2. 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.

3.2.1.3. 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

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.

3.2.1.4. 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:

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.

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:

1. 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

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

3. 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 ].

3.2.2. Privacy: Platform for Privacy Preferences (P3P)

3.2.2.1. Purpose and Benefits

Privacy is about controlling access to personally identifiable information, and, to a large degree, this is a human policy issue of ensuring that organizations and individuals with legitimate access to that information do not misuse that privilege. To give an example, although a medical office staff may have knowledge of a persons medical records, this does not mean they should share this information with others for profit or other purposes.

3.2.2.2. Features

• An XML vocabulary for expressing user privacy preferences
• An XML vocabulary for expressing site privacy policies
• Mechanisms for retrieving site policies
• Processing rules.

3.2.2.3. Key Concepts

A P3P site policy indicates what information is collected and for what purpose, where to locate a human-readable policy, how the site manager may be contacted, and what assurances are made regarding privacy. P3P defines categories of data to be collected and provides the means to associate policy information with portions of a web site, URLs, and other information (such as cookies).

A site may associate privacy policies with different portions of the site. This is done by defining privacy meta information using an XML language defined in the P3P specification and either storing it at a well known location on the site, linking to it from an HTML or XHTML document using the link tag, or by referring to it in a special HTTP header defined in the P3P specification.

3.2.2.4. Examples

An example meta file from the P3P specification is:

The P3P specification also defines an XML language for writing a privacy policy, such as the following:

3.2.3. Digital Rights Management: eXtensible rights Markup Language (XrML) 2.0

3.2.3.1. Purpose and Benefits

Digital Rights Management (DRM) refers to controlling the use of content to conform to license policies, such as allowing single use, repeated use, no sharing with others and so on. Uses of DRM include control over movies, books, software and other electronic media. The general mechanism is to include usage rules with the content and then to enforce these rules in the applications that allow use of the content. This control mechanism is designed to be effective regardless of who is using the content, dynamically adjusting to the user. As a result, controls remain in place for copies and also adjust for content that is moved in a workflow among multiple users.

Digital rights management technology is an emerging technology. Use of a common language for rules would not only enable interoperability among "viewers" but also allow content to be passed through a workflow with multiple participants and applications. An emerging XML language for digital rights management is XrML 2.0, the extensible rights Markup Language [ XrML ]. This language is based on the Xerox PARC’s Digital Property Rights Language (DPRL), first introduced in 1996 and converted from LISP to XML in 1999 and championed by ContentGuard.

3.2.3.2. Features

XrML defines a framework and language for expressing rights, a definition of terms (a common set of meanings), and a set of processing rules.

3.2.3.3. Key Concepts

Core concepts defined in XrML include the following:

Principal

A unique authenticated individual. Any authentication mechanism specified in the XrML principal definition may be used. One mechanism is to authenticate by demonstrating possession of a private key, by creating an XML Digital Signature.

License

Collection of grants giving certain rights to specified resources to certain principals under certain conditions as well as license issuer information.

Grant

A right issued to a principal against a resource under specified conditions

Right

An action a principal may perform against some resource under certain conditions. XrML defines actions, including read, write, delete, modify, install, play, transfer, and others.

Resource

An object that can be granted a right. Examples include digital works such as movies, books, images, audio as well as services such as email and transactions or other information (such as a name).

Condition

A condition is the terms and obligations that must be met to execute a grant against a resource. One condition may require other conditions as prerequisites. Example conditions include time, time period, use counters and viewer information

XrML uses XML Schema to define types and to provide for extensibility. XrML uses XML Namespaces to avoid name conflicts. XrML also uses XML Digital Signature to create signed licenses.

3.2.3.4. Examples

Here is an example from the XrML use cases document where the consumer pays $5.99 to play an eBook for one year and print up to 5 copies. In this example, detailed conditions are stored in a Web Services directory (UDDI) and referred to by a unique identifier(UUID):

4. Conclusion

The XML Security standards define XML languages and processing rules for meeting common security requirements. For the most part, these standards incorporate the use of the other XML Security standards, especially the core XML Digital Signature and XML Encryption standards. Another example is the sharing of policy statements by SAML and XACML. This set of interlocking standards has emerged quickly, and, since it is based on a foundation of accepted practices and technologies, should mature quickly. This article has presented a brief introduction to the set of standards and how they work together.

XML Security standards will be essential to moving business online as XML technologies are adopted for Web Services, Digital Rights Management and other emerging applications. Understanding of how XML may meet authentication, authorization, confidentiality,integrity, signature and privacy requirements will be essential. This paper has provided an introduction to these topics.

5. Acknowledgements

6. References

[ 21CFR11 ]

Title 21 Code of Federal Regulations (21 CFR Part 11) Electronic Records; Electronic Signatures Final Rule Published in the Federal Register, March 20, 1997, http://www.fda.gov/ora/compliance_ref/part11/frs/background/11cfr-fr.htm

[ BRML ]

Business Rules for Electronic Commerce: Project at IBM T.J. Watson Research, http://www.research.ibm.com/rules/home.html

[ DocBook ]

The DocBook Document Type Committee Specification 4.2, 16 July 2002, Document identifier: cs-docbook-docbook-4.2 Location: http://www.oasis-open.org/docbook/specs/

[ Kerberos ]

Kerberos: The Network Authentication Protocol, http://web.mit.edu/kerberos/www/

[ MathML ]

Mathematical Markup Language (MathML™) 1.01 Specification W3C Recommendation, revision of 7 July 1999 http://www.w3.org/TR/REC-MathML/

[ Namespaces ]

Namespaces in XML, World Wide Web Consortium 14-January-1999, http://www.w3.org/TR/REC-xml-names/

[ P3P ] The Platform for Privacy Preferences 1.0 (P3P1.0) Specification

W3C Recommendation 16 April 2002, http://www.w3.org/TR/P3P/

[ PKI ]

Public-Key Infrastructure (X.509) (pkix), http://www.ietf.org/html.charters/pkix-charter.html

[ RDF ] Resource Description Framework (RDF) Model and Syntax Specification

W3C Recommendation 22 February 1999, http://www.w3.org/TR/REC-rdf-syntax/
See also RDF Primer, W3C Working Draft 19 March 2002 http://www.w3.org/TR/rdf-primer/

[ RSS ]

RDF Site Summary (RSS) 1.0, December 6, 2000, http://purl.org/rss/1.0/spec

[ SAML ] Security Assertion Markup Language

http://www.oasis-open.org/committees/security/

[ SOAP ] Simple Object Access Protocol

SOAP Version 1.2 Part 0: Primer, W3C Working Draft 26 June 2002, http://www.w3.org/TR/soap12-part0/
SOAP Version 1.2 Part 1: Messaging Framework, W3C Working Draft 26 June 2002, http://www.w3.org/TR/soap12-part1/
SOAP Version 1.2 Part 2: Adjuncts, W3C Working Draft 26 June 2002 http://www.w3.org/TR/soap12-part2/

[ SSLIntro] Introducing SSL and Certificates using SSLeay

Somewhat dated article (1997) providing an introduction to SSL/TLS: http://www.fjhirsch.com/Papers/wwwj/index.html

[ TLSRFC ] The TLS Protocol, Version 1.0

INTERNET-DRAFT , March 2002 (Expires September 2002) http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-01.txt

[ URI]

Uniform Resource Identifiers (URI): Generic Syntax, RFC 2396, August 1998, http://www.ietf.org/rfc/rfc2396.txt

[ WebSvcSecRoadmap]

Security in a Web Services World: A Proposed Architecture and Roadmap A Joint White Paper from IBM Corporation and Microsoft Corporation April 7, 2002, Version 1.0 , http://www-106.ibm.com/developerworks/security/library/ws-secmap/

[ WSDL ]

Web Services Description Language (WSDL) Version 1.2, W3C Working Draft 9 July 2002, http://www.w3.org/TR/wsdl12/

[ WS-Security ] Web Services Security (WS-Security)

Version 1.0, April 5, 2002, http://www-106.ibm.com/developerworks/library/Ws-secure/

[ X509Cert ]

• Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002, http://www.ietf.org/rfc/rfc3280.txt (Note that this superceded RFC 2459)
• Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002, http://www.ietf.org/rfc/rfc3279.txt
• An Internet Attribute Certificate Profile for Authorization, April 2002, http://www.ietf.org/rfc/rfc3281.txt

[ XACML ] OASIS extensible Access Control Markup Language (XACML)

Working Draft 14, 14 June 2002 Document identifier: draft-xacml-specification-14.doc Location: http://www.oasis-open.org/committees/xacml/docs/
See http://www.oasis-open.org/committees/xacml/#documents for related documents.

[ XHTML ]

XHTML™ 1.0: The Extensible HyperText Markup Language, A Reformulation of HTML 4 in XML 1.0, W3C Recommendation 26 January 2000, http://www.w3.org/TR/xhtml1/

[ XKMS ] XML Key Management Specification 2.0 (XKMS)

W3C Working Draft 18 March 2002, http://www.w3.org/TR/xkms2/

[ XML ]

Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation 6 October 2000 http://www.w3.org/TR/REC-xml

[ XMLCanon]

Canonical XML, Version 1.0, W3C Recommendation 15 March 2001, http://www.w3.org/TR/xml-c14n
Exclusive XML Canonicalization, Version 1.0, W3C Proposed Recommendation 24 May 2002, http://www.w3.org/TR/xml-exc-c14n/

[ XMLDecTrans ]

Decryption Transform for XML Signature, W3C Candidate Recommendation, 04 March 2002 http://www.w3.org/TR/xmlenc-decrypt

[ XML DigSig ] XML-Signature Syntax and Processing

W3C Recommendation 12 February 2002, http://www.w3.org/TR/xmldsig-core/.

[ XML Enc ] XML Encryption Syntax and Processing

W3C Candidate Recommendation 04 March 2002, http://www.w3.org/TR/xmlenc-core/.

[ XMLProt ]

XML Protocol Abstract Model, W3C Working Draft 9 July 2001, http://www.w3.org/TR/xmlp-am/

[ XMLRef ]

"Essential XML Quick Reference", Skonnard, Gudgin, Addison-Wesley, 2002

[ XPath ]

XML Path Language (XPath), Version 1.0, W3C Recommendation, 16 November 1999 http://www.w3.org/TR/xpath

[ XPathFilter ]

XML-Signature XPath Filter 2.0, W3C Candidate Recommendation, 18 July 2002 http://www.w3.org/TR/xmldsig-filter2/

[ XrML ] extensible rights Markup Language (XrML) 2.0 Specification

20 November 2001 Available upon registration from http://www.xrml.org/