Does XWS-Security Implement Any Specifications?

XWS-Security is an implementation of the Web Services Security (WSS) specification developed at OASIS. WSS defines a SOAP extension providing quality of protection through message integrity, message confidentiality, and message authentication. WSS mechanisms can be used to accommodate a wide variety of security models and encryption technologies.

The WSS specification provides an extensible mechanism for associating security tokens with SOAP messages. The WSS specification itself does not define the format of the various types of security token. Instead, a series of security token profile documents have either been published or are in the process of being published. Each of these documents provides a specification for one type of security token. In addition to XML formatted security tokens, WSS also defines a mechanism for encoding binary security tokens so that they can be used too. Some of the token types either in use or under development for WSS include User Name Token, X.509, Kerberos, and SAML. It is common practice to use public-key cryptography to encrypt a random secret key which is used to do the actual encryption of the payload and often the response message as well. WSS provides a mechanism for including these encrypted session keys.

The WSS specification defines an end to end security framework that provides support for intermediary security processing. Message integrity is provided by using XML Signature in conjunction with security tokens to ensure that messages are transmitted without modifications. The integrity mechanisms can support multiple signatures, possibly by multiple actors (however, the configuration file schema does not provide support for intermediary security processing). The techniques are extensible such that they can support additional signature formats. Message confidentiality is granted by using XML Encryption in conjunction with security tokens to keep portions of SOAP messages confidential. The encryption mechanisms can support operations by multiple actors.

In this release, the XWS-Security framework provides the following options for securing JAX-RPC applications:

XML Digital Signature (DSig)

This implementation of XML and Web Services Security uses Apache's XML-DSig implementation, which is based on the XML Signature specification, which can be viewed at http://www.w3.org/TR/xmldsig-core/.

XML digital signatures are designed for use in XML transactions. It is a standard that was jointly developed by W3C and the IETF (RFC 2807, RFC 3275). The standard defines a schema for capturing the result of a digital signature operation applied to arbitrary data and its processing. XML signatures add authentication, data integrity, and support for non-repudiation to the signed data.

XML Signature has the ability to sign only specific portions of the XML tree rather than the complete document. This is important when a single XML document may need to be signed multiple times by a single or multiple parties. This flexibility can ensure the integrity of certain portions of an XML document, while leaving open the possibility for other portions of the document to change. Signature validation mandates that the data object that was signed be accessible to the party that is interested in the transaction. The XML signature will generally indicate the location of the original signed object.

Samples containing code for signing and/or verifying parts of the SOAP message are included with this release in the directory <JWSDP_HOME>/xws-security/samples/. Read Understanding and Running the Simple Sample Application and Understanding and Running the Interop Sample Application for more information on these sample applications.

XML Encryption (XML-Enc)

This implementation of XML and Web Services Security uses Apache's XML-Enc implementation, which is based on the XML Encryption W3C standard. This standard can be viewed at http://www.w3.org/TR/xmlenc-core/.

XML Encryption specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data.

Samples containing code for encrypting and/or decrypting parts of the SOAP message are included with this release in the directory <JWSDP_HOME>/xws-security/samples/simple/. Read Understanding and Running the Simple Sample Application for more information on these sample applications.

Username Token Verification

Username token verification specifies a process for sending UserName tokens along with the message. The receiver can validate the identity of the sender by validating the digital signature sent by the sender. A digital signature internally refers to a security token (for example, UserName token or an X509 Certificate Token) to indicate the key used for signing. Sending these tokens with a message binds the identity of the tokens (and any other claims occurring in the security token) to the message.

This implementation of XML and Web Services Security provides support for Username Token Profile, which is based on OASIS WSS Username Token Profile 1.0 (which can be read at http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf) and X509 Certificate Token Profile, which is based on OASIS WSS X509 Certificate Token Profile 1.0 (which can be read at http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf).

Samples containing code for sending user name and X509 certificate tokens along with the SOAP message are included with this release in the directory <JWSDP_HOME>/xws-security/samples/simple/. Read Understanding and Running the Simple Sample Application for more information on these sample applications.

Implement Interoperable Web Services Security applications

This implementation of XML and Web Services Security fully supports the implementation of WSS Interop scenarios. Developers can use the XWS-Security framework to implement applications that have security requirements similar to those defined in the WSS interop scenarios.

The WSS interop scenarios define concrete scenarios for the purpose of an interop demonstration. Some of the scenarios have been purposely oversimplified, and serve just to bootstrap interop. In other words, the scenarios have not been selected primarily for their utility, but more to prove some basic interop of the methodology. The scenarios should be interpreted more as test plans to demonstrate basic features of the protocol than as descriptions of scenarios for which there must be solutions.

The following are some of the interoperability scenarios documents that are supported by this implementation:

The full set of the Oasis Open Technical Committee documents are available to Oasis TC members only

http://www.oasis-open.org/apps/org/workgroup/wss/documents.php.

Draft Spec for Interop1 (draft 5)

http://lists.oasis-open.org/archives/wss/200306/msg00002.html

Final Spec for Interop2 (draft 6)

http://lists.oasis-open.org/archives/wss/200310/msg00003.html

Samples containing implementations of all the WSS Interop Scenarios are included in this release in the directory <JWSDP_HOME>/xws-security/samples/interop/. Read Understanding and Running the Interop Sample Application for more information on these sample applications.

On Which Technologies Is XWS-Security Based?

XWS-Security APIs are used for securing Web services based on JAX-RPC. This release of XWS-Security is based on non-standard XML Digital Signature and XML Encryption APIs, which are subject to change with new revisions of the technology. As standards are defined in the Web Services Security space, these nonstandard APIs will be replaced with standards-based APIs.

JSR-105 (XML Digital Signature APIs) are included in this release of the Java WSDP as well. JSR 105 is a standard API (in progress, almost at Proposed Final Draft) for generating and validating XML Signatures as specified by the W3C recommendation. It is an API that should be used by Java applications and middleware that need to create and/or process XML Signatures. It can be used by Web Services Security (which is the goal for a future release) and by non-Web Services technologies, for example, documents stored or transferred in XML. Both JSR-105 and JSR-106 (XML Digital Encryption APIs) are core-XML security components.

XWS-Security does not use the JSR-105 or JSR-106 APIs because, currently, the Java standards for XML Digital Signatures and XML Encryption are undergoing definition under the Java Community Process. These Java standards are JSR-105-XML Digital Signature APIs, which you can read at http://www.jcp.org/en/jsr/detail?id=105 and JSR-106-XML Digital Encryption APIs, which you can read at http://www.jcp.org/en/jsr/detail?id=106.

XWS-Security uses the Apache libraries for DSig and XML-Enc. In future releases, the goal of XWS-Security is to move toward using JSR-105 and JSR-106 APIs.

Table 3-2 API/Implementation Stack Diagram
XWS-Security
JSR-105 & JSR-106 (possible in future release)
Apache XML Security implementation (current implementation, however this can easily be replaced or swapped, because the JSRs are provider-based)
J2SE Security (JCE/JCA APIs)

The Apache XML Security project is aimed at providing implementation of security standards for XML. Currently the focus is on the W3C standards. More information on Apache XML Security can be viewed at: