Revised: 11/30/2005
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 2.0 EA2 release of XWS-Security:
/xws-security/samples/jaxws2.0.optimize
on <xwss:JAXRPCSecurity> configuration element that allows
certain common security usecases to be optimized under JAXWS 2.0.<jwsdp-install-dir>/xws-security/samples/saajsecurity.
<jwsdp-install-dir>/xws-security/samples/dynamicpolicy.<xwss:Sign>
<xwss:X509Token
certificateAlias="xws-security-client"/>
<xwss:SignatureTarget
type="qname" value="SOAP-BODY"/>
</xwss:Sign>This release includes the following XML and Web Services Security (XWS-Security) features:
This release includes samples that demonstrate the following WSS interoperability scenarios:
simple sample. swainterop sample.samlinterop
sample.<jwsdp-install-dir>/xws-security/samples/saajsecurity
for more details.
Due to import control restrictions, the jurisdiction policy files shipped with the Java 2 SDK, versions 1.4.x and 1.5.x allow "strong" but limited cryptography to be used. The maximum key sizes allowed by this "strong" version of the jurisdiction policy files is 128 bits for AES.
To use a key length of 256, such as in AES-256, policy files in <jdk_install>/jre/lib/security
need to be updated. The document Java
Cryptography Extension (JCE) for the Java 2 SDK, v 1.4 describes
how to download the unlimited strength jurisdiction policy files.
For more information on this topic, read:
pkcs12import
and keyexport. The XWS-Security release contents are arranged in the following structure within the Java WSDP release:
| Directory Name | Contents |
|---|---|
<jwsdp_install_dir>/xws-security/etc |
Keystore files, property files, and configuration files. |
<jwsdp_install_dir>/xws-security/docs |
Release documentation for the XWS-Security framework. See also: JWSDP Tutorial. |
<jwsdp_install_dir>/xws-security/lib |
JAR files used by the XWS-Security framework. |
<jwsdp_install_dir>/xws-security/samples |
Example code. See samples.html for details. |
<jwsdp_install_dir>/xws-security/bin |
Command-line tools specific to XWS-Security. |
Configuration
schema allows it. xwss:RequireSignature and xwss:RequireEncryption
schema elements allow a lot of detailed (optional) policy information
(such as the SignatureMethod, etc.) to be specified.
XWS-Security 2.0 EA2 does not check the following information against
the actual policy in the incoming message during receiver-side policy
verification.
Targets
are also not verified.A later release may enable full policy verification on the receiver-side.
/xws-security/samples/simple/config/encrypt-using-symmkey-client.xml,
DataReferences to any encrypted attachment targets
would not be listed as part of the stand alone <xenc:ReferenceList>
as currently required by the WSS SwA Specification 1.0 Draft 15.
Consequently, the XWS-Security 2.0 EA2 implementation currently expects
a separate xwss:RequireEncryption element in the
receiver-side security configuration for each such attachment that was
encrypted using a shared-secret key. All the non-attachment targets
that were encrypted using the same shared-secret key (using an xwss:Encrypt)
can still be listed in a single xwss:RequireEncryption
element when no key encryption is configured. document-literal-non-wrapped,
and the SecurityConfiguration contains
method/operation-level security declarations, then the Operation
name to be specified for the Operation in the
configuration file should be a concatenated string, delimited by ":",
of the QNames of all child elements of SOAPBody:
// the following pseudo code shows how the Operation Name is inferred
node = body.getFirstChild();
String operation = "";
for (; node != null; node = node.getNextSibling())
operation += "{" + node.getNamespaceURI() + "}" + node.getLocalName() + ":";
return operation.substring(0, operation.length()-1);
These apply to both incoming and outgoing messages.
For incoming messages, XWSS 2.0 is liberal by default. This
means that by default the BSP restrictions/requirements are not
mandated. In order to enable BSP, there is a conformance
flag that needs to be set to bsp. Setting this flag will
turn on BSP requirement checks for incoming messages. This switch is
available at the Service and Port levels.
PropertyCallback has been deprecated and
disabled. You can now configure the following properties as attributes
of other elements, as indicated in the following list:
RequireTimestamp element:
maxClockSkew: defaults to 300 seconds timestampFreshnessLimit: defaults to 300
seconds RequireUsernameToken element:
maxClockSkew: defaults to 300 secondstimestampFreshnessLimit: defaults to 300
secondsmaxNonceAge: defaults to 900 secondsRefer to the documentation for PropertyCallback
for more details. Note that the maxNonceAge is only a
hint to the receiver to cache the received nonce for at least the
specified period of time. Caching of nonces is used to detect nonce
replays.
Prefix : Namespace URI
--------------------------------------------------------------------
ds : http://www.w3.org/2000/09/xmldsig#
xenc : http://www.w3.org/2001/04/xmlenc#
wsse : http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
wsu : http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
saml : urn:oasis:names:tc:SAML:1.0:assertion
S11 : http://schemas.xmlsoap.org/soap/envelope/
The use of XPath expressions is discouraged in XWS Security
2.0 because it impacts performance. Users are advised to make use of
fragment URI's and QNames instead to identify targets of Signature
and Encryption. For example, the XPath expression:
//env:Body
should instead be written as
//*[local-name()='Body' and
namespace-uri()='http://schemas.xmlsoap.org/soap/envelope/']
SOAP-ENV and env can be used
in XPath expressions to mean either a SOAP 1.1 or a SOAP 1.2 Envelope
depending on the protocol of the SOAPMessage.Target in RequireSignature or RequireEncryption
resolves to multiple nodes, the receiver requirement validation might
fail. It is required that the XPath targets in the receiver requirement
should resolve to a single target node.Target in a Sign/Encrypt
configuration element resolves to multiple nodes, the implementation
would sign/encrypt all of the resolved nodes.cid:* as the target value, where the target
type is uri. This release also allows verification of all
attachments by specifying cid:*. This feature is only
supported for all required targets (i.e., targets with enforce
flag="true"). SecurityTokenReference (STR) Transform only
supports the exc14
algorithm as its canonicalizationMethod. SubjectConfirmation,
the implementation assumes that the assertion contains at most one Subject
and at most one SubjectConfirmation method for all
statements of the assertion. In this release, the XWS-Security implementation has the following known issues:
KeyIdentifier reference without
the ValueType attribute when using the STR-Transform. SubjectConfirmation KeyInfo of a SAML
assertion is not supported. Instead, the first one is picked when a
collection is given. AssertionID's for assertions populated by CallbackHandler
should be unique (results are unknown if there is an Id clash) com.sun.xml.wss.saml.assertion tomcat-config.xml
file needs to be changed for the following configuration
Change the classpath separator on line number 3 of the file <jwsdp.home>\xws-security\samples\buildconfig\tomcat-config.xml
from ":" to ";", as shown:
Unix: <property name="java.endorsed.dir" value="${tomcat.home}/jaxp/lib/endorsed:${tomcat.home}/jaxp/lib/"/>
Windows: <property name="java.endorsed.dir" value="${tomcat.home}/jaxp/lib/endorsed;${tomcat.home}/jaxp/lib/"/>