Javawstutorial phần 7
- 45 trang
- file .pdf
256 UNDERSTANDING AND RUNNING THE XWS-SECURITY SAMPLE APPLICATIONS
The application prints out both the client and server request and response SOAP
messages. The output from the server may be viewed in the appropriate con-
tainer’s log file. The output from the client is sent to stdout or to whichever
stream is used by the configured log handler. Messages are logged at the INFO
level.
In this example, server-side code is found in the /dynamic-policy/server/
src/sample/ directory. Client-side code is found in the /dynamic-policy/cli-
ent/src/sample/ directory. The asant (or ant) targets build objects under the
/build/server/ and /build/client/ directories.
Security Configuration Files for Enabling
Dynamic Policy
To specify the request and/or response security policy dynamically at runtime,
you need to enable DynamicPolicyCallback by setting the enableDynamicPol-
icy flag on the element. The application-
defined runtime parameters can then be set by the application and passed into the
ProcessingContext, which is made available to the CallbackHandler as a
DynamicApplicationContext. The CallbackHandler can then modify an
existing policy or set a completely new policy into the Callback.
As you can see, the security configuration files for this example are very simple,
because the actual security policy that will be applied at runtime is being decided
by SecurityEnvironmentHandler. The SecurityEnvironmentHandler is dis-
cussed in Setting Security Policies at Runtime. The security configuration file for the
client, dynamic-client.xml, looks like this:
DynamicPolicy="true">
SETTING SECURITY POLICIES AT RUNTIME 257
com.sun.xml.wss.sample.SecurityEnvironmentHandler
The security configuration file for the server, dynamic-server.xml, looks like
this:
DynamicPolicy="true">
com.sun.xml.wss.sample.SecurityEnvironmentHandler
Setting Security Policies at Runtime
The dynamic-policy sample application demonstrates how the request and
response security policies can be set at runtime from the SecurityEnvironmen-
tHandler callback.
In this sample, the SecurityEnvironmentHandler inserts a SignaturePolicy
at runtime. The SignaturePolicy asks for a signature over the body of the mes-
sage. For the requesting side, this is equivalent to using an element
in the configuration file. For the receiving side, this is equivalent to using an
element in the configuration file. Both the request
and response contain a signature over the body.
Note: The APIs used in this sample by the SecurityEnvironmentHandler callback
are evolving and hence are subject to modification prior to the release of XWS
Security FCS 2.0.
258 UNDERSTANDING AND RUNNING THE XWS-SECURITY SAMPLE APPLICATIONS
The full code for the SecurityEnvironmentHandler is located in the /
dynamic-policy/src/com/sun/xml/wss/sample directory. The SecurityEn-
vironmentHandler file is a sample implementation of a CallbackHandler. The
following snippet of that file demonstrates how to handle a DynamicPolicy-
Callback:
} else if (callbacks[i] instanceof DynamicPolicyCallback) {
DynamicPolicyCallback dpCallback =
(DynamicPolicyCallback) callbacks[i];
SecurityPolicy policy =
dpCallback.getSecurityPolicy();
if (policy instanceof WSSPolicy) {
try {
handleWSSPolicy (dpCallback);
} catch (PolicyGenerationException pge) {
throw new IOException (pge.getMessage());
}
} else if (policy instanceof DynamicSecurityPolicy)
{
try {
handleDynamicSecurityPolicy (dpCallback);
} catch (PolicyGenerationException pge) {
throw new IOException (pge.getMessage());
}
} else {
throw unsupported;
}
Running the Dynamic Policy Sample
Application
To run the dynamic-policy sample application, follow these steps:
1. Complete the tasks defined in the following sections of this addendum:
• Setting System Properties
• Configuring a JCE Provider
• Setting Build Properties
2. Start the selected container and make sure the server is running. To start
the Application Server,
a. From a Unix machine, enter the following command from a terminal
window: asadmin start-domain domain1
RUNNING THE DYNAMIC POLICY SAMPLE APPLICATION 259
b. From a Windows machine, choose Start→Programs→Sun
Microsystems→J2EE 1.4→Start Default Server.
3. Build and run the application from a terminal window or command
prompt.
• On the Application Server, the command to build and run the applica-
tion is: asant run-sample
• On the other containers, the command to build and run the application
is: ant run-sample
Note: To run the sample against a remote server containing the deployed endpoint,
use the run-remote-sample target in place of the run-sample target. In this situa-
tion, make sure that the endpoint.host, endpoint.port, http.proxyHost,
http.proxyPort, and service.url properties are set correctly in the build.prop-
erties file (as discussed in Setting Build Properties) before running the sample.
If the application runs successfully, you will see a message similar to the follow-
ing:
[echo] Running the client program....
[java] ==== Sending Message Start ====
...
[java] ==== Sending Message End ====
[java] ==== Received Message Start ====
...
[java] ==== Received Message End ====
You can view similar messages in the server logs:
/domains//logs/server.log
/logs/launcher.server.log
//logs/errors
260 UNDERSTANDING AND RUNNING THE XWS-SECURITY SAMPLE APPLICATIONS
Dynamic Response Sample
Application
The dynamic-response sample application demonstrates using the certificate
that arrived in a signed request to encrypt the response back to the requester
using the XWS-Security APIs. To accomplish this task,
• A CallbackHandler retrieves the requester Subject and obtains its certif-
icate.
• The requester certificate is used to encrypt the response back to the
requester.
The application prints out both the client and server request and response SOAP
messages. The output from the server may be viewed in the appropriate con-
tainer's log file. The output from the client is sent to stdout or to whichever
stream is used by the configured log handler. Messages are logged at the INFO
level.
In this example, server-side code is found in the /dynamic-response/server/
src/sample/ directory. Client-side code is found in the /dynamic-response/
client/src/sample/ directory. The asant (or ant) targets build objects under
the /build/server/ and /build/client/ directories.
Security Configuration Files for Enabling
Dynamic Response
For this sample application, the security configuration files are fairly simple. The
security configuration files are used to sign the request and encrypt the response,
but the work of using the requester certificate to encrypt the response back to the
requester is accomplished using the SecurityEnvironmentHandler, which is
discussed in Using the CallbackHandler to Enable Dynamic Response.
The client security configuration file for this example, sign-client.xml, looks
like this:
sample.SecurityEnvironmentHandler
The server security configuration file for this example, encrypt-server.xml,
looks like this:
sample.SecurityEnvironmentHandler
Using the CallbackHandler to Enable
Dynamic Response
In this sample application, the security configuration files sign the request and
encrypt the response, however the work of using the requester certificate to
encrypt the response back to the requester is done in the SecurityEnvironmen-
tHandler. The full source code for the SecurityEnvironmentHandler is
262 UNDERSTANDING AND RUNNING THE XWS-SECURITY SAMPLE APPLICATIONS
located in the directory dynamic-response/src/sample. This snippet from that
file demonstrates how to use a CallbackHandler to generate the response
dynamically:
if (cb.getRequest() instanceof
EncryptionKeyCallback.AliasX509CertificateRequest) {
EncryptionKeyCallback.AliasX509CertificateRequest request =
(EncryptionKeyCallback.AliasX509CertificateRequest)
cb.getRequest();
String alias = request.getAlias();
if ((alias == null) || "".equals(alias)) {
Subject currentSubject =
SubjectAccessor.getRequesterSubject();
Set publicCredentials =
currentSubject.getPublicCredentials();
for (Iterator it =
publicCredentials.iterator(); it.hasNext();) {
Object cred = it.next();
if(cred instanceof
java.security.cert.X509Certificate){
java.security.cert.X509Certificate
cert =
(java.security.cert.X509
Certificate)cred;
request.setX509Certificate(cert)
;
Running the Dynamic Response Sample
Application
To run the dynamic-response sample application, follow these steps:
1. Complete the tasks defined in the following sections of this addendum:
• Setting System Properties
• Configuring a JCE Provider
• Setting Build Properties
2. Start the selected container and make sure the server is running. To start
the Application Server,
a. From a Unix machine, enter the following command from a terminal
window: asadmin start-domain domain1
FURTHER INFORMATION 263
b. From a Windows machine, choose Start→Programs→Sun
Microsystems→J2EE 1.4→Start Default Server.
3. Build and run the application from a terminal window or command
prompt.
• On the Application Server, the command to build and run the applica-
tion is: asant run-sample
• On the other containers, the command to build and run the application
is: ant run-sample
Note: To run the sample against a remote server containing the deployed endpoint,
use the run-remote-sample target in place of the run-sample target. In this situa-
tion, make sure that the endpoint.host, endpoint.port, http.proxyHost,
http.proxyPort, and service.url properties are set correctly in the build.prop-
erties file (as discussed in Setting Build Properties) before running the sample.
If the application runs successfully, you will see a message similar to the follow-
ing:
[echo] Running the client program....
[java] ==== Sending Message Start ====
...
[java] ==== Sending Message End ====
[java] ==== Received Message Start ====
...
[java] ==== Received Message End ====
You can view similar messages in the server logs:
/domains//logs/server.log
/logs/launcher.server.log
//logs/errors
Further Information
For links to specifications and other documents relevant to XWS-Security, refer
to the Further Information section in Introduction to XML and Web Services Security.
264 UNDERSTANDING AND RUNNING THE XWS-SECURITY SAMPLE APPLICATIONS
6
Java XML Digital
Signature API
THE Java XML Digital Signature API is a standard Java API for generating
and validating XML Signatures. This API was defined under the Java Commu-
nity Process as JSR 105 (see http://jcp.org/en/jsr/detail?id=105). This
JSR is final and this release of Java WSDP contains an FCS access implementa-
tion of the Final version of the APIs.
XML Signatures can be applied to data of any type, XML or binary (see http:/
/www.w3.org/TR/xmldsig-core/). The resulting signature is represented in
XML. An XML Signature can be used to secure your data and provide data
integrity, message authentication, and signer authentication.
After providing a brief overview of XML Signatures and the XML Digital Sig-
nature API, this chapter presents two examples that demonstrate how to use the
API to validate and generate an XML Signature. This chapter assumes that you
have a basic knowledge of cryptography and digital signatures.
The API is designed to support all of the required or recommended features of
the W3C Recommendation for XML-Signature Syntax and Processing. The API
is extensible and pluggable and is based on the Java Cryptography Service Pro-
vider Architecture. The API is designed for two types of developers:
• Java programmers who want to use the XML Digital Signature API to gen-
erate and validate XML signatures
265
266 JAVA XML DIGITAL SIGNATURE API
• Java programmers who want to create a concrete implementation of the
XML Digital Signature API and register it as a cryptographic service of a
JCA provider (see http://java.sun.com/j2se/1.4.2/docs/guide/
security/CryptoSpec.html#Provider)
How XWS-Security and XML Digital
Signature API Are Related
Before getting into specifics, it is important to see how XWS-Security and XML
Digital Signature API are related. In this release of the Java WSDP, XWS-Secu-
rity is based on non-standard XML Digital Signature APIs.
XML Digital Signature API 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 (the goal for a future release) and by non-Web
Services technologies (for example, signing documents stored or transferred in
XML). Both JSR 105 and JSR 106 (XML Digital Encryption APIs) are core-
XML security components. (See http://www.jcp.org/en/jsr/
detail?id=106 for more information about JSR 106.)
XWS-Security does not currently use the XML Digital Signature API or XML
Digital Encryption APIs. XWS-Security uses the Apache libraries for XML-
DSig and XML-Enc. The goal of XWS-Security is to move toward using these
APIs in future releases.
XML SECURITY STACK 267
XML Security Stack
Figure 6–1 shows how XML Digital Signature API (JSR 105) interacts with
security components today and how it will interact with other security compo-
nents, including XML Digital Encryption API (JSR 106), in future releases.
Figure 6–1 Java WSDP Security Components
XWSS calls Apache XML-Security directly today; in future releases, it should
be able to call other pluggable security providers. The Apache XML-Security
provider and the Sun JCA Provider are both pluggable components. Since JSR
105 is final today, the JSR 105 layer is standard now; the JSR 106 layer will be
standard after that JSR becomes final.
268 JAVA XML DIGITAL SIGNATURE API
Package Hierarchy
The six packages in the XML Digital Signature API are:
• javax.xml.crypto
• javax.xml.crypto.dsig
• javax.xml.crypto.dsig.keyinfo
• javax.xml.crypto.dsig.spec
• javax.xml.crypto.dom
• javax.xml.crypto.dsig.dom
The javax.xml.crypto package contains common classes that are used to per-
form XML cryptographic operations, such as generating an XML signature or
encrypting XML data. Two notable classes in this package are the KeySelector
class, which allows developers to supply implementations that locate and option-
ally validate keys using the information contained in a KeyInfo object, and the
URIDereferencer class, which allows developers to create and specify their own
URI dereferencing implementations.
The javax.xml.crypto.dsig package includes interfaces that represent the
core elements defined in the W3C XML digital signature specification. Of pri-
mary significance is the XMLSignature class, which allows you to sign and vali-
date an XML digital signature. Most of the XML signature structures or
elements are represented by a corresponding interface (except for the KeyInfo
structures, which are included in their own package and are discussed in the next
paragraph). These interfaces include: SignedInfo, CanonicalizationMethod,
SignatureMethod, Reference, Transform, DigestMethod, XMLObject, Mani-
fest, SignatureProperty, and SignatureProperties. The XMLSignature-
Factory class is an abstract factory that is used to create objects that implement
these interfaces.
The javax.xml.crypto.dsig.keyinfo package contains interfaces that repre-
sent most of the KeyInfo structures defined in the W3C XML digital signature
recommendation, including KeyInfo, KeyName, KeyValue, X509Data,
X509IssuerSerial, RetrievalMethod, and PGPData. The KeyInfoFactory
class is an abstract factory that is used to create objects that implement these
interfaces.
The javax.xml.crypto.dsig.spec package contains interfaces and classes
representing input parameters for the digest, signature, transform, or canonical-
ization algorithms used in the processing of XML signatures.
Finally, the javax.xml.crypto.dom and javax.xml.crypto.dsig.dom pack-
ages contains DOM-specific classes for the javax.xml.crypto and
SERVICE PROVIDERS 269
javax.xml.crypto.dsig packages, respectively. Only developers and users
who are creating or using a DOM-based XMLSignatureFactory or KeyInfo-
Factory implementation should need to make direct use of these packages.
Service Providers
A JSR 105 cryptographic service is a concrete implementation of the abstract
XMLSignatureFactory and KeyInfoFactory classes and is responsible for cre-
ating objects and algorithms that parse, generate and validate XML Signatures
and KeyInfo structures. A concrete implementation of XMLSignatureFactory
must provide support for each of the required algorithms as specified by the
W3C recommendation for XML Signatures. It may support other algorithms as
defined by the W3C recommendation or other specifications.
JSR 105 leverages the JCA provider model for registering and loading XMLSig-
natureFactory and KeyInfoFactory implementations.
Each concrete XMLSignatureFactory or KeyInfoFactory implementation sup-
ports a specific XML mechanism type that identifies the XML processing mech-
anism that an implementation uses internally to parse and generate XML
signature and KeyInfo structures. This JSR supports one standard type, DOM.
The XML Digital Signature API early access provider implementation that is
bundled with Java WSDP supports the DOM mechanism. Support for new stan-
dard types, such as JDOM, may be added in the future.
An XML Digital Signature API implementation should use underlying JCA
engine classes, such as java.security.Signature and java.security.Mes-
sageDigest, to perform cryptographic operations.
In addition to the XMLSignatureFactory and KeyInfoFactory classes, JSR 105
supports a service provider interface for transform and canonicalization algo-
rithms. The TransformService class allows you to develop and plug in an
implementation of a specific transform or canonicalization algorithm for a par-
ticular XML mechanism type. The TransformService class uses the standard
JCA provider model for registering and loading implementations. Each JSR 105
implementation should use the TransformService class to find a provider that
supports transform and canonicalization algorithms in XML Signatures that it is
generating or validating.
270 JAVA XML DIGITAL SIGNATURE API
Introduction to XML Signatures
As mentioned, an XML Signature can be used to sign any arbitrary data, whether
it is XML or binary. The data is identified via URIs in one or more Reference
elements. XML Signatures are described in one or more of three forms:
detached, enveloping, or enveloped. A detached signature is over data that is
external, or outside of the signature element itself. Enveloping signatures are sig-
natures over data that is inside the signature element, and an enveloped signature
is a signature that is contained inside the data that it is signing.
Example of an XML Signature
The easiest way to describe the contents of an XML Signature is to show an
actual sample and describe each component in more detail. The following is an
example of an enveloped XML Signature generated over the contents of an XML
document. The contents of the document before it is signed are:
The resulting enveloped XML Signature, indented and formatted for readability,
is as follows:
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-
20010315#WithComments"/>
uooqbWYa5VCqcJCbuymBKqm17vY=
EXAMPLE OF AN XML SIGNATURE 271
KedJuTob5gtvYx9qM3k3gm7kbLBwVbEQRl26S2tmXjqNND7MRGtoew==
Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/
XPaF5Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==
qV38IqrWJG0V/
mZQvRVi1OHw9Zj84nDC4jO8P0axi1gb6d+475yhMjSc/
BrIVC58W3ydbkK+Ri4OKbaRZlYeRA==
The Signature element has been inserted inside the content that it is signing,
thereby making it an enveloped signature. The required SignedInfo element
contains the information that is actually signed:
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-
20010315#WithComments"/>
uooqbWYa5VCqcJCbuymBKqm17vY=
The required CanonicalizationMethod element defines the algorithm used to
canonicalize the SignedInfo element before it is signed or validated. Canonical-
ization is the process of converting XML content to a canonical form, to take
272 JAVA XML DIGITAL SIGNATURE API
into account changes that can invalidate a signature over that data. Canonicaliza-
tion is necessary due to the nature of XML and the way it is parsed by different
processors and intermediaries, which can change the data such that the signature
is no longer valid but the signed data is still logically equivalent.
The required SignatureMethod element defines the digital signature algorithm
used to generate the signature, in this case DSA with SHA-1.
One or more Reference elements identify the data that is digested. Each Refer-
ence element identifies the data via a URI. In this example, the value of the URI
is the empty String (""), which indicates the root of the document. The optional
Transforms element contains a list of one or more Transform elements, each of
which describes a transformation algorithm used to transform the data before it
is digested. In this example, there is one Transform element for the enveloped
transform algorithm. The enveloped transform is required for enveloped signa-
tures so that the signature element itself is removed before calculating the signa-
ture value. The required DigestMethod element defines the algorithm used to
digest the data, in this case SHA1. Finally the required DigestValue element
contains the actual base64-encoded digested value.
The required SignatureValue element contains the base64-encoded signature
value of the signature over the SignedInfo element.
The optional KeyInfo element contains information about the key that is needed
to validate the signature:
Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/
XPaF5Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==
qV38IqrWJG0V/mZQvRVi1OHw9Zj84nDC4jO8P0axi1gb6d+475yhMjSc/
BrIVC58W3ydbkK+Ri4OKbaRZlYeRA==
XML DIGITAL SIGNATURE API EXAMPLES 273
This KeyInfo element contains a KeyValue element, which in turn contains a
DSAKeyValue element consisting of the public key needed to validate the signa-
ture. KeyInfo can contain various content such as X.509 certificates and PGP
key identifiers. See the KeyInfo section of the XML Signature Recommenda-
tion for more information on the different KeyInfo types.
XML Digital Signature API Examples
The following sections describe two examples that show how to use the XML
Digital Signature API:
• Validate example
• Signing example
To run the sample applications using the supplied Ant build.xml files, issue the
following commands after you installed Java WSDP:
For Solaris/Linux:
1. % export JWSDP_HOME=
2. % export ANT_HOME=$JWSDP_HOME/apache-ant
3. % export PATH=$ANT_HOME/bin:$PATH
4. % cd $JWSDP_HOME/xmldsig/samples/
For Windows 2000/XP:
1. > set JWSDP_HOME=
2. > set ANT_HOME=%JWSDP_HOME%\apache-ant
3. > set PATH=%ANT_HOME%\bin;%PATH%
4. > cd %JWSDP_HOME%\xmldsig\samples\
validate Example
You can find the code shown in this section in the Validate.java file in the
/xmldsig/samples/validate directory. The file on which it
operates, envelopedSignature.xml, is in the same directory.
To run the example, execute the following command from the/
xmldsig/samples/validate directory:
$ ant
274 JAVA XML DIGITAL SIGNATURE API
The sample program will validate the signature in the file envelopedSigna-
ture.xml in the current working directory. To validate a different signature, run
the following command:
$ ant -Dsample.args="signature.xml"
where "signature.xml" is the pathname of the file.
Validating an XML Signature
This example shows you how to validate an XML Signature using the JSR 105
API. The example uses DOM (the Document Object Model) to parse an XML
document containing a Signature element and a JSR 105 DOM implementation
to validate the signature.
Instantiating the Document that Contains the
Signature
First we use a JAXP DocumentBuilderFactory to parse the XML document
containing the Signature. An application obtains the default implementation for
DocumentBuilderFactory by calling the following line of code:
DocumentBuilderFactory dbf =
DocumentBuilderFactory.newInstance();
We must also make the factory namespace-aware:
dbf.setNamespaceAware(true);
Next, we use the factory to get an instance of a DocumentBuilder, which is used
to parse the document:
DocumentBuilder builder = dbf.newDocumentBuilder();
Document doc = builder.parse(new FileInputStream(argv[0]));
Specifying the Signature Element to be
Validated
We need to specify the Signature element that we want to validate, since there
could be more than one in the document. We use the DOM method Docu-
VALIDATE EXAMPLE 275
ment.getElementsByTagNameNS, passing it the XML Signature namespace URI
and the tag name of the Signature element, as shown:
NodeList nl = doc.getElementsByTagNameNS
(XMLSignature.XMLNS, "Signature");
if (nl.getLength() == 0) {
throw new Exception("Cannot find Signature element");
}
This returns a list of all Signature elements in the document. In this example,
there is only one Signature element.
Creating a Validation Context
We create an XMLValidateContext instance containing input parameters for val-
idating the signature. Since we are using DOM, we instantiate a DOMValidate-
Context instance (a subclass of XMLValidateContext), and pass it two
parameters, a KeyValueKeySelector object and a reference to the Signature
element to be validated (which is the first entry of the NodeList we generated
earlier):
DOMValidateContext valContext = new DOMValidateContext
(new KeyValueKeySelector(), nl.item(0));
The KeyValueKeySelector is explained in greater detail in Using
KeySelectors (page 277).
Unmarshaling the XML Signature
We extract the contents of the Signature element into an XMLSignature object.
This process is called unmarshalling. The Signature element is unmarshalled
using an XMLSignatureFactory object. An application can obtain a DOM
implementation of XMLSignatureFactory by calling the following line of code:
XMLSignatureFactory factory =
XMLSignatureFactory.getInstance("DOM");
The application prints out both the client and server request and response SOAP
messages. The output from the server may be viewed in the appropriate con-
tainer’s log file. The output from the client is sent to stdout or to whichever
stream is used by the configured log handler. Messages are logged at the INFO
level.
In this example, server-side code is found in the /dynamic-policy/server/
src/sample/ directory. Client-side code is found in the /dynamic-policy/cli-
ent/src/sample/ directory. The asant (or ant) targets build objects under the
/build/server/ and /build/client/ directories.
Security Configuration Files for Enabling
Dynamic Policy
To specify the request and/or response security policy dynamically at runtime,
you need to enable DynamicPolicyCallback by setting the enableDynamicPol-
icy flag on the
defined runtime parameters can then be set by the application and passed into the
ProcessingContext, which is made available to the CallbackHandler as a
DynamicApplicationContext. The CallbackHandler can then modify an
existing policy or set a completely new policy into the Callback.
As you can see, the security configuration files for this example are very simple,
because the actual security policy that will be applied at runtime is being decided
by SecurityEnvironmentHandler. The SecurityEnvironmentHandler is dis-
cussed in Setting Security Policies at Runtime. The security configuration file for the
client, dynamic-client.xml, looks like this:
SETTING SECURITY POLICIES AT RUNTIME 257
com.sun.xml.wss.sample.SecurityEnvironmentHandler
The security configuration file for the server, dynamic-server.xml, looks like
this:
com.sun.xml.wss.sample.SecurityEnvironmentHandler
Setting Security Policies at Runtime
The dynamic-policy sample application demonstrates how the request and
response security policies can be set at runtime from the SecurityEnvironmen-
tHandler callback.
In this sample, the SecurityEnvironmentHandler inserts a SignaturePolicy
at runtime. The SignaturePolicy asks for a signature over the body of the mes-
sage. For the requesting side, this is equivalent to using an
in the configuration file. For the receiving side, this is equivalent to using an
and response contain a signature over the body.
Note: The APIs used in this sample by the SecurityEnvironmentHandler callback
are evolving and hence are subject to modification prior to the release of XWS
Security FCS 2.0.
258 UNDERSTANDING AND RUNNING THE XWS-SECURITY SAMPLE APPLICATIONS
The full code for the SecurityEnvironmentHandler is located in the /
dynamic-policy/src/com/sun/xml/wss/sample directory. The SecurityEn-
vironmentHandler file is a sample implementation of a CallbackHandler. The
following snippet of that file demonstrates how to handle a DynamicPolicy-
Callback:
} else if (callbacks[i] instanceof DynamicPolicyCallback) {
DynamicPolicyCallback dpCallback =
(DynamicPolicyCallback) callbacks[i];
SecurityPolicy policy =
dpCallback.getSecurityPolicy();
if (policy instanceof WSSPolicy) {
try {
handleWSSPolicy (dpCallback);
} catch (PolicyGenerationException pge) {
throw new IOException (pge.getMessage());
}
} else if (policy instanceof DynamicSecurityPolicy)
{
try {
handleDynamicSecurityPolicy (dpCallback);
} catch (PolicyGenerationException pge) {
throw new IOException (pge.getMessage());
}
} else {
throw unsupported;
}
Running the Dynamic Policy Sample
Application
To run the dynamic-policy sample application, follow these steps:
1. Complete the tasks defined in the following sections of this addendum:
• Setting System Properties
• Configuring a JCE Provider
• Setting Build Properties
2. Start the selected container and make sure the server is running. To start
the Application Server,
a. From a Unix machine, enter the following command from a terminal
window: asadmin start-domain domain1
RUNNING THE DYNAMIC POLICY SAMPLE APPLICATION 259
b. From a Windows machine, choose Start→Programs→Sun
Microsystems→J2EE 1.4→Start Default Server.
3. Build and run the application from a terminal window or command
prompt.
• On the Application Server, the command to build and run the applica-
tion is: asant run-sample
• On the other containers, the command to build and run the application
is: ant run-sample
Note: To run the sample against a remote server containing the deployed endpoint,
use the run-remote-sample target in place of the run-sample target. In this situa-
tion, make sure that the endpoint.host, endpoint.port, http.proxyHost,
http.proxyPort, and service.url properties are set correctly in the build.prop-
erties file (as discussed in Setting Build Properties) before running the sample.
If the application runs successfully, you will see a message similar to the follow-
ing:
[echo] Running the client program....
[java] ==== Sending Message Start ====
...
[java] ==== Sending Message End ====
[java] ==== Received Message Start ====
...
[java] ==== Received Message End ====
You can view similar messages in the server logs:
260 UNDERSTANDING AND RUNNING THE XWS-SECURITY SAMPLE APPLICATIONS
Dynamic Response Sample
Application
The dynamic-response sample application demonstrates using the certificate
that arrived in a signed request to encrypt the response back to the requester
using the XWS-Security APIs. To accomplish this task,
• A CallbackHandler retrieves the requester Subject and obtains its certif-
icate.
• The requester certificate is used to encrypt the response back to the
requester.
The application prints out both the client and server request and response SOAP
messages. The output from the server may be viewed in the appropriate con-
tainer's log file. The output from the client is sent to stdout or to whichever
stream is used by the configured log handler. Messages are logged at the INFO
level.
In this example, server-side code is found in the /dynamic-response/server/
src/sample/ directory. Client-side code is found in the /dynamic-response/
client/src/sample/ directory. The asant (or ant) targets build objects under
the /build/server/ and /build/client/ directories.
Security Configuration Files for Enabling
Dynamic Response
For this sample application, the security configuration files are fairly simple. The
security configuration files are used to sign the request and encrypt the response,
but the work of using the requester certificate to encrypt the response back to the
requester is accomplished using the SecurityEnvironmentHandler, which is
discussed in Using the CallbackHandler to Enable Dynamic Response.
The client security configuration file for this example, sign-client.xml, looks
like this:
sample.SecurityEnvironmentHandler
The server security configuration file for this example, encrypt-server.xml,
looks like this:
sample.SecurityEnvironmentHandler
Using the CallbackHandler to Enable
Dynamic Response
In this sample application, the security configuration files sign the request and
encrypt the response, however the work of using the requester certificate to
encrypt the response back to the requester is done in the SecurityEnvironmen-
tHandler. The full source code for the SecurityEnvironmentHandler is
262 UNDERSTANDING AND RUNNING THE XWS-SECURITY SAMPLE APPLICATIONS
located in the directory dynamic-response/src/sample. This snippet from that
file demonstrates how to use a CallbackHandler to generate the response
dynamically:
if (cb.getRequest() instanceof
EncryptionKeyCallback.AliasX509CertificateRequest) {
EncryptionKeyCallback.AliasX509CertificateRequest request =
(EncryptionKeyCallback.AliasX509CertificateRequest)
cb.getRequest();
String alias = request.getAlias();
if ((alias == null) || "".equals(alias)) {
Subject currentSubject =
SubjectAccessor.getRequesterSubject();
Set publicCredentials =
currentSubject.getPublicCredentials();
for (Iterator it =
publicCredentials.iterator(); it.hasNext();) {
Object cred = it.next();
if(cred instanceof
java.security.cert.X509Certificate){
java.security.cert.X509Certificate
cert =
(java.security.cert.X509
Certificate)cred;
request.setX509Certificate(cert)
;
Running the Dynamic Response Sample
Application
To run the dynamic-response sample application, follow these steps:
1. Complete the tasks defined in the following sections of this addendum:
• Setting System Properties
• Configuring a JCE Provider
• Setting Build Properties
2. Start the selected container and make sure the server is running. To start
the Application Server,
a. From a Unix machine, enter the following command from a terminal
window: asadmin start-domain domain1
FURTHER INFORMATION 263
b. From a Windows machine, choose Start→Programs→Sun
Microsystems→J2EE 1.4→Start Default Server.
3. Build and run the application from a terminal window or command
prompt.
• On the Application Server, the command to build and run the applica-
tion is: asant run-sample
• On the other containers, the command to build and run the application
is: ant run-sample
Note: To run the sample against a remote server containing the deployed endpoint,
use the run-remote-sample target in place of the run-sample target. In this situa-
tion, make sure that the endpoint.host, endpoint.port, http.proxyHost,
http.proxyPort, and service.url properties are set correctly in the build.prop-
erties file (as discussed in Setting Build Properties) before running the sample.
If the application runs successfully, you will see a message similar to the follow-
ing:
[echo] Running the client program....
[java] ==== Sending Message Start ====
...
[java] ==== Sending Message End ====
[java] ==== Received Message Start ====
...
[java] ==== Received Message End ====
You can view similar messages in the server logs:
Further Information
For links to specifications and other documents relevant to XWS-Security, refer
to the Further Information section in Introduction to XML and Web Services Security.
264 UNDERSTANDING AND RUNNING THE XWS-SECURITY SAMPLE APPLICATIONS
6
Java XML Digital
Signature API
THE Java XML Digital Signature API is a standard Java API for generating
and validating XML Signatures. This API was defined under the Java Commu-
nity Process as JSR 105 (see http://jcp.org/en/jsr/detail?id=105). This
JSR is final and this release of Java WSDP contains an FCS access implementa-
tion of the Final version of the APIs.
XML Signatures can be applied to data of any type, XML or binary (see http:/
/www.w3.org/TR/xmldsig-core/). The resulting signature is represented in
XML. An XML Signature can be used to secure your data and provide data
integrity, message authentication, and signer authentication.
After providing a brief overview of XML Signatures and the XML Digital Sig-
nature API, this chapter presents two examples that demonstrate how to use the
API to validate and generate an XML Signature. This chapter assumes that you
have a basic knowledge of cryptography and digital signatures.
The API is designed to support all of the required or recommended features of
the W3C Recommendation for XML-Signature Syntax and Processing. The API
is extensible and pluggable and is based on the Java Cryptography Service Pro-
vider Architecture. The API is designed for two types of developers:
• Java programmers who want to use the XML Digital Signature API to gen-
erate and validate XML signatures
265
266 JAVA XML DIGITAL SIGNATURE API
• Java programmers who want to create a concrete implementation of the
XML Digital Signature API and register it as a cryptographic service of a
JCA provider (see http://java.sun.com/j2se/1.4.2/docs/guide/
security/CryptoSpec.html#Provider)
How XWS-Security and XML Digital
Signature API Are Related
Before getting into specifics, it is important to see how XWS-Security and XML
Digital Signature API are related. In this release of the Java WSDP, XWS-Secu-
rity is based on non-standard XML Digital Signature APIs.
XML Digital Signature API 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 (the goal for a future release) and by non-Web
Services technologies (for example, signing documents stored or transferred in
XML). Both JSR 105 and JSR 106 (XML Digital Encryption APIs) are core-
XML security components. (See http://www.jcp.org/en/jsr/
detail?id=106 for more information about JSR 106.)
XWS-Security does not currently use the XML Digital Signature API or XML
Digital Encryption APIs. XWS-Security uses the Apache libraries for XML-
DSig and XML-Enc. The goal of XWS-Security is to move toward using these
APIs in future releases.
XML SECURITY STACK 267
XML Security Stack
Figure 6–1 shows how XML Digital Signature API (JSR 105) interacts with
security components today and how it will interact with other security compo-
nents, including XML Digital Encryption API (JSR 106), in future releases.
Figure 6–1 Java WSDP Security Components
XWSS calls Apache XML-Security directly today; in future releases, it should
be able to call other pluggable security providers. The Apache XML-Security
provider and the Sun JCA Provider are both pluggable components. Since JSR
105 is final today, the JSR 105 layer is standard now; the JSR 106 layer will be
standard after that JSR becomes final.
268 JAVA XML DIGITAL SIGNATURE API
Package Hierarchy
The six packages in the XML Digital Signature API are:
• javax.xml.crypto
• javax.xml.crypto.dsig
• javax.xml.crypto.dsig.keyinfo
• javax.xml.crypto.dsig.spec
• javax.xml.crypto.dom
• javax.xml.crypto.dsig.dom
The javax.xml.crypto package contains common classes that are used to per-
form XML cryptographic operations, such as generating an XML signature or
encrypting XML data. Two notable classes in this package are the KeySelector
class, which allows developers to supply implementations that locate and option-
ally validate keys using the information contained in a KeyInfo object, and the
URIDereferencer class, which allows developers to create and specify their own
URI dereferencing implementations.
The javax.xml.crypto.dsig package includes interfaces that represent the
core elements defined in the W3C XML digital signature specification. Of pri-
mary significance is the XMLSignature class, which allows you to sign and vali-
date an XML digital signature. Most of the XML signature structures or
elements are represented by a corresponding interface (except for the KeyInfo
structures, which are included in their own package and are discussed in the next
paragraph). These interfaces include: SignedInfo, CanonicalizationMethod,
SignatureMethod, Reference, Transform, DigestMethod, XMLObject, Mani-
fest, SignatureProperty, and SignatureProperties. The XMLSignature-
Factory class is an abstract factory that is used to create objects that implement
these interfaces.
The javax.xml.crypto.dsig.keyinfo package contains interfaces that repre-
sent most of the KeyInfo structures defined in the W3C XML digital signature
recommendation, including KeyInfo, KeyName, KeyValue, X509Data,
X509IssuerSerial, RetrievalMethod, and PGPData. The KeyInfoFactory
class is an abstract factory that is used to create objects that implement these
interfaces.
The javax.xml.crypto.dsig.spec package contains interfaces and classes
representing input parameters for the digest, signature, transform, or canonical-
ization algorithms used in the processing of XML signatures.
Finally, the javax.xml.crypto.dom and javax.xml.crypto.dsig.dom pack-
ages contains DOM-specific classes for the javax.xml.crypto and
SERVICE PROVIDERS 269
javax.xml.crypto.dsig packages, respectively. Only developers and users
who are creating or using a DOM-based XMLSignatureFactory or KeyInfo-
Factory implementation should need to make direct use of these packages.
Service Providers
A JSR 105 cryptographic service is a concrete implementation of the abstract
XMLSignatureFactory and KeyInfoFactory classes and is responsible for cre-
ating objects and algorithms that parse, generate and validate XML Signatures
and KeyInfo structures. A concrete implementation of XMLSignatureFactory
must provide support for each of the required algorithms as specified by the
W3C recommendation for XML Signatures. It may support other algorithms as
defined by the W3C recommendation or other specifications.
JSR 105 leverages the JCA provider model for registering and loading XMLSig-
natureFactory and KeyInfoFactory implementations.
Each concrete XMLSignatureFactory or KeyInfoFactory implementation sup-
ports a specific XML mechanism type that identifies the XML processing mech-
anism that an implementation uses internally to parse and generate XML
signature and KeyInfo structures. This JSR supports one standard type, DOM.
The XML Digital Signature API early access provider implementation that is
bundled with Java WSDP supports the DOM mechanism. Support for new stan-
dard types, such as JDOM, may be added in the future.
An XML Digital Signature API implementation should use underlying JCA
engine classes, such as java.security.Signature and java.security.Mes-
sageDigest, to perform cryptographic operations.
In addition to the XMLSignatureFactory and KeyInfoFactory classes, JSR 105
supports a service provider interface for transform and canonicalization algo-
rithms. The TransformService class allows you to develop and plug in an
implementation of a specific transform or canonicalization algorithm for a par-
ticular XML mechanism type. The TransformService class uses the standard
JCA provider model for registering and loading implementations. Each JSR 105
implementation should use the TransformService class to find a provider that
supports transform and canonicalization algorithms in XML Signatures that it is
generating or validating.
270 JAVA XML DIGITAL SIGNATURE API
Introduction to XML Signatures
As mentioned, an XML Signature can be used to sign any arbitrary data, whether
it is XML or binary. The data is identified via URIs in one or more Reference
elements. XML Signatures are described in one or more of three forms:
detached, enveloping, or enveloped. A detached signature is over data that is
external, or outside of the signature element itself. Enveloping signatures are sig-
natures over data that is inside the signature element, and an enveloped signature
is a signature that is contained inside the data that it is signing.
Example of an XML Signature
The easiest way to describe the contents of an XML Signature is to show an
actual sample and describe each component in more detail. The following is an
example of an enveloped XML Signature generated over the contents of an XML
document. The contents of the document before it is signed are:
The resulting enveloped XML Signature, indented and formatted for readability,
is as follows:
20010315#WithComments"/>
EXAMPLE OF AN XML SIGNATURE 271
KedJuTob5gtvYx9qM3k3gm7kbLBwVbEQRl26S2tmXjqNND7MRGtoew==
/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9jQTxe
Eu0ImbzRMqzVDZkVG9xD7nN1kuFw==
li7dzDacuo67Jg7mtqEm2TRuOMU=
XPaF5Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==
mZQvRVi1OHw9Zj84nDC4jO8P0axi1gb6d+475yhMjSc/
BrIVC58W3ydbkK+Ri4OKbaRZlYeRA==
The Signature element has been inserted inside the content that it is signing,
thereby making it an enveloped signature. The required SignedInfo element
contains the information that is actually signed:
20010315#WithComments"/>
The required CanonicalizationMethod element defines the algorithm used to
canonicalize the SignedInfo element before it is signed or validated. Canonical-
ization is the process of converting XML content to a canonical form, to take
272 JAVA XML DIGITAL SIGNATURE API
into account changes that can invalidate a signature over that data. Canonicaliza-
tion is necessary due to the nature of XML and the way it is parsed by different
processors and intermediaries, which can change the data such that the signature
is no longer valid but the signed data is still logically equivalent.
The required SignatureMethod element defines the digital signature algorithm
used to generate the signature, in this case DSA with SHA-1.
One or more Reference elements identify the data that is digested. Each Refer-
ence element identifies the data via a URI. In this example, the value of the URI
is the empty String (""), which indicates the root of the document. The optional
Transforms element contains a list of one or more Transform elements, each of
which describes a transformation algorithm used to transform the data before it
is digested. In this example, there is one Transform element for the enveloped
transform algorithm. The enveloped transform is required for enveloped signa-
tures so that the signature element itself is removed before calculating the signa-
ture value. The required DigestMethod element defines the algorithm used to
digest the data, in this case SHA1. Finally the required DigestValue element
contains the actual base64-encoded digested value.
The required SignatureValue element contains the base64-encoded signature
value of the signature over the SignedInfo element.
The optional KeyInfo element contains information about the key that is needed
to validate the signature:
/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9jQTxe
Eu0ImbzRMqzVDZkVG9xD7nN1kuFw==
li7dzDacuo67Jg7mtqEm2TRuOMU=
XPaF5Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==
qV38IqrWJG0V/mZQvRVi1OHw9Zj84nDC4jO8P0axi1gb6d+475yhMjSc/
BrIVC58W3ydbkK+Ri4OKbaRZlYeRA==
XML DIGITAL SIGNATURE API EXAMPLES 273
This KeyInfo element contains a KeyValue element, which in turn contains a
DSAKeyValue element consisting of the public key needed to validate the signa-
ture. KeyInfo can contain various content such as X.509 certificates and PGP
key identifiers. See the KeyInfo section of the XML Signature Recommenda-
tion for more information on the different KeyInfo types.
XML Digital Signature API Examples
The following sections describe two examples that show how to use the XML
Digital Signature API:
• Validate example
• Signing example
To run the sample applications using the supplied Ant build.xml files, issue the
following commands after you installed Java WSDP:
For Solaris/Linux:
1. % export JWSDP_HOME=
2. % export ANT_HOME=$JWSDP_HOME/apache-ant
3. % export PATH=$ANT_HOME/bin:$PATH
4. % cd $JWSDP_HOME/xmldsig/samples/
For Windows 2000/XP:
1. > set JWSDP_HOME=
2. > set ANT_HOME=%JWSDP_HOME%\apache-ant
3. > set PATH=%ANT_HOME%\bin;%PATH%
4. > cd %JWSDP_HOME%\xmldsig\samples\
validate Example
You can find the code shown in this section in the Validate.java file in the
operates, envelopedSignature.xml, is in the same directory.
To run the example, execute the following command from the
xmldsig/samples/validate directory:
$ ant
274 JAVA XML DIGITAL SIGNATURE API
The sample program will validate the signature in the file envelopedSigna-
ture.xml in the current working directory. To validate a different signature, run
the following command:
$ ant -Dsample.args="signature.xml"
where "signature.xml" is the pathname of the file.
Validating an XML Signature
This example shows you how to validate an XML Signature using the JSR 105
API. The example uses DOM (the Document Object Model) to parse an XML
document containing a Signature element and a JSR 105 DOM implementation
to validate the signature.
Instantiating the Document that Contains the
Signature
First we use a JAXP DocumentBuilderFactory to parse the XML document
containing the Signature. An application obtains the default implementation for
DocumentBuilderFactory by calling the following line of code:
DocumentBuilderFactory dbf =
DocumentBuilderFactory.newInstance();
We must also make the factory namespace-aware:
dbf.setNamespaceAware(true);
Next, we use the factory to get an instance of a DocumentBuilder, which is used
to parse the document:
DocumentBuilder builder = dbf.newDocumentBuilder();
Document doc = builder.parse(new FileInputStream(argv[0]));
Specifying the Signature Element to be
Validated
We need to specify the Signature element that we want to validate, since there
could be more than one in the document. We use the DOM method Docu-
VALIDATE EXAMPLE 275
ment.getElementsByTagNameNS, passing it the XML Signature namespace URI
and the tag name of the Signature element, as shown:
NodeList nl = doc.getElementsByTagNameNS
(XMLSignature.XMLNS, "Signature");
if (nl.getLength() == 0) {
throw new Exception("Cannot find Signature element");
}
This returns a list of all Signature elements in the document. In this example,
there is only one Signature element.
Creating a Validation Context
We create an XMLValidateContext instance containing input parameters for val-
idating the signature. Since we are using DOM, we instantiate a DOMValidate-
Context instance (a subclass of XMLValidateContext), and pass it two
parameters, a KeyValueKeySelector object and a reference to the Signature
element to be validated (which is the first entry of the NodeList we generated
earlier):
DOMValidateContext valContext = new DOMValidateContext
(new KeyValueKeySelector(), nl.item(0));
The KeyValueKeySelector is explained in greater detail in Using
KeySelectors (page 277).
Unmarshaling the XML Signature
We extract the contents of the Signature element into an XMLSignature object.
This process is called unmarshalling. The Signature element is unmarshalled
using an XMLSignatureFactory object. An application can obtain a DOM
implementation of XMLSignatureFactory by calling the following line of code:
XMLSignatureFactory factory =
XMLSignatureFactory.getInstance("DOM");