Before you work with this release, make sure that you have installed the required software and are on a supported operating system. You can find this information in the JavaTM Web Services Developer Pack (Java WSDP) home page and Release Notes.
The following features are new to the FCS 1.0 release of XWS-Security:
simplesample application for an example using the callback handler.
This release includes the following XML and Web Services Security (XWS-Security) features:
The XWS-Security release contents are arranged in the following structure within the Java WSDP release:
||Keystore files, properties files, configuration files.|
||Release documentation for the XWS-Security framework and API documentation. See also: Java Web Services Tutorial.|
||JAR files used by the XWS-Security framework.|
||Example code. See samples.html for details.|
||Command-line tools specific to XWS-Security.|
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. The following table shows how the various technologies are stacked upon one another:
API/Implementation Stack Diagram
JSR-105 & JSR-106 (possible in future release)
Security implementation (current implementation, however this can
easily be replaced or swapped, because
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: http://xml.apache.org/security/.
Java security includes the Java Cryptography Extension (JCE) and the Java Cryptography Architecture (JCA). JCE and JCA form the foundation for public key technologies in the Java platform. The JCA API specification can be viewed at http://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html. The JCE documentation can be viewed at http://java.sun.com/products/jce/index-14.html.
In this release, the XWS-Security implementation has the following known issues:
When running XWS-Security samples under SJSAS and SJSWS, and if a third party JCE provider is
needed (because you are running under a version of the Java SDK prior to 5.0), add the appropriate
permissions for the provider in the
server.policy file of SJSAS/SJSWS. The README.txt file under each of the XWS-Security samples specifies a list of permissions required for running those samples under SJSAS and SJSWS. This permission is in addition to the list of permissions specified in the README, and is applicable only when a third party JCE provider is being used.
Add the following permission:
permission java.security.SecurityPermission "putProviderProperty.<Provider>";
Where <Provider> is the standard name of the JCE provider. For example, if the provider has a standard name of ABC, the permission would look like this:
permission java.security.SecurityPermission "putProviderProperty.ABC";
For more information, refer to the Java Web Services Tutorial chapter Securing JAXRPC Applications with XML and Web Services Security, downloadable from http://java.sun.com/webservices/downloads/webservicestutorial.html for more details on configuring the JCE provider.
The security-configuration file is validated against the schema at compile time (before deployment), but if there is an error in the security-configuration file, an exception is not being thrown. Instead a Warning Message is issued.
dumpMessagesflag is enabled on the
SecurityConfigurationelement, the incoming request message is dumped twice when using method level security with encrypted body content.
When method-level security is configured for a particular WSDL method and the security configuration specifies encryption of the body content, the incoming request is dumped twice when dumpMessages is set to true.
For more information, refer to the Java Web Services Tutorial chapter Securing JAXRPC Applications with XML and Web Services Security, downloadable from http://java.sun.com/webservices/downloads/webservicestutorial.html for more details on configuring method level security for a JAX-RPC web service.
<RequireEncryption>/<RequireSignature>element, and no
<OptionalTargets>element is configured in the security configuration, a
NullPointerExceptionmay be thrown.