For an updated, online version of these release notes, see Release Notes.
Revised: 6/9/2004
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 EA 2.0 release of XWS-Security:
/xws-security/samples/api-sample
directory.
These APIs are intended to insulate XWS-Security users from possible changes in the internal APIs, however, these APIs are being evolved/refined and are subject to minor changes between 2.0 EA and 2.0 FCS.
When using XWS-Security in stand alone mode, it is dependent on JAXP 1.3, SAAJ 1.2.,
the file <jwsdp_install_dir>/jwsdp-shared/lib/activation.jar
,
the file xmlsec.jar (for XML-Security 1.2.1 ), and the file xmldsig.jar
(for XML Digital Signatures/JSR 105 RI).
A sample application demonstrating this feature is shipped in the <jwsdp_install_dir>/xws-security/samples/swainterop
directory.
A sample application demonstrating this feature is shipped in the <jwsdp_install_dir>/xws-security/samples/samlinterop
directory.
Timestamps
and UsernameTokens
on the receiving side. In the earlier release, the Timestamp
and UsernameToken
had to appear in the message strictly in the order in which it was mentioned in the configuration file. In this release, the Timestamp
and UsernameToken
can appear anywhere in the wsse:Security
header.A sample application demonstrating this feature is shipped in the <jwsdp_install_dir>/xws-security/samples/dynamic-policy
directory.
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:
BinarySecurityTokens
in the incoming message. 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.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. However, for performance reasons XWS-Security 2.0 EA does not check all of this information against the actual policy in the incoming message during receiver-side policy verification.
Target
details included in a RequireSignature
or RequireEncryption
element are checked for equivalence against the actual Targets
that were signed then encrypted in the incoming secure message.Targets
, such as DigestMethod
for SignatureTargets
or DataEncryptionAlgorithm
for EncryptionTargets
are also not verified. Any transforms specified on the Targets
, such as C14N, are also not verified.Target
under a RequireSignature
element, then the transform would be applied to resolve the final target. A later release may enable full policy verification on the receiver-side when enabled by a configurable flag.
/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. Consequently, the XWS-Security 2.0 EA 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. The final version of the SwA specification may change this behavior.
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 60 seconds
timestampFreshnessLimit
: defaults to 300 seconds
RequireUsernameToken
element:
maxClockSkew
: defaults to 60 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.
CertificateValidationCallback
is made by the receiver-side logic only for certificates used in Signatures
. In the previous release, this callback was being made for Encryption
also. CertificateValidation
for Encryption
is not necessary since what is received is the self-certificate of the receiver.PrefixNamespaceMappingCallback
has been deprecated and disabled. When specifying XPath expressions for targets in XWS Configuration files, you are required to make use of the elongated syntax (see example below) and avoid references to namespace prefixes in the XPath expressions if the prefix involved is anything other than one of the following options:
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 SOAP-ENV : http://schemas.xmlsoap.org/soap/envelope/ 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/']
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
. DataEncryptionMethod
, as described in the XWS-Security configuration schema, is "http://www.w3.org/2001/04/xmlenc#aes128-cbc"
. However, for backward compatibility reasons, the XWS-Security implementation still uses "http://www.w3.org/2001/04/xmlenc#tripledes-cbc"
as the default DataEncryptionMethod
.
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
and com.sun.identity.saml.assertion
packages are subject to change in XWS-Security 2.0 FCS.
com.sun.xml.wss.impl.policy.*
and com.sun.xml.wss.impl.policy.mls.*
are subject to refinement/change between XWS-Security 2.0 EA and XWS-Security 2.0 FCS.tomcat-config.xml
file needs to be changed:
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/"/>
<xwss:Target>
and <xwss:EncryptionTarget>
elements within an <xwss:RequireEncryption>
element should match the order of the corresponding <xenc:DataReference>
's in the <xenc:ReferenceList>
of the incoming message if the type of the <xenc:EncryptedData>
for any of the <xenc:DataReference>
's is "http://www.w3.org/2001/04/xmlenc#Element"
.