Dynamic Policy Sample Application
The
dynamic-policy
sample application demonstrates how to specify (or change) the request and/or response security policy at runtime using the XWS-Security APIs. Another sample that demonstrates using the XWS-Security APIs isapi-sample
, which is discussed in XWS-Security APIs Sample Application.You would want to dynamically set the security policy for an application at runtime when one of these conditions is present:
- Response policy: When you don't know who the requester may be, you want to be able to specify the response security policy after you determine the identity of the requester.
- Request policy: When you don't know what the runtime parameters will be, you want to discover these parameters, such as whether SSL is enabled at the transport layer, before you specify your request policy.
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 container'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 theINFO
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/client/src/sample/
directory. Theasant
(orant)
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 theenableDynamicPolicy
flag on the<xwss:SecurityConfiguration>
element. The application-defined runtime parameters can then be set by the application and passed into theProcessingContext
, which is made available to theCallbackHandler
as aDynamicApplicationContext
. TheCallbackHandler
can then modify an existing policy or set a completely new policy into theCallback
.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 discussed in Setting Security Policies at Runtime. The security configuration file for the client,dynamic-client.xml
, looks like this:<xwss:JAXRPCSecurity xmlns:xwss="http://java.sun.com/xml/ns/ xwss/config"> <xwss:Service> <!-- the exact policy to apply will be decided by the SecurityEnvironmentHandler at runtime --> <xwss:SecurityConfiguration dumpMessages="true"enable- DynamicPolicy="true"
> </xwss:SecurityConfiguration> </xwss:Service> <xwss:SecurityEnvironmentHandler> com.sun.xml.wss.sample.SecurityEnvironmentHandler </xwss:SecurityEnvironmentHandler> </xwss:JAXRPCSecurity>The security configuration file for the server,
dynamic-server.xml
, looks like this:<xwss:JAXRPCSecurity xmlns:xwss="http://java.sun.com/xml/ns/ xwss/config"> <xwss:Service> <!-- the exact policy to apply will be decided by the SecurityEnvironmentHandler at runtime --> <xwss:SecurityConfiguration dumpMessages="true"enable- DynamicPolicy="true"
> </xwss:SecurityConfiguration> </xwss:Service> <xwss:SecurityEnvironmentHandler> com.sun.xml.wss.sample.SecurityEnvironmentHandler </xwss:SecurityEnvironmentHandler> </xwss:JAXRPCSecurity>Setting Security Policies at Runtime
The
dynamic-policy
sample application demonstrates how the request and response security policies can be set at runtime from theSecurityEnvironmentHandler
callback.In this sample, the
SecurityEnvironmentHandler
inserts aSignaturePolicy
at runtime. TheSignaturePolicy
asks for a signature over the body of the message. For the requesting side, this is equivalent to using an<xwss:Sign>
element in the configuration file. For the receiving side, this is equivalent to using an<xwss:RequireSignature>
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.
The full code for the
SecurityEnvironmentHandler
is located in the/dynamic-policy/src/com/sun/xml/wss/sample
directory. TheSecurityEnvironmentHandler
file is a sample implementation of aCallbackHandler
. The following snippet of that file demonstrates how to handle aDynamicPolicyCallback
:} 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:
Note: To run the sample against a remote server containing the deployed endpoint, use the
run-remote-sample
target in place of therun-sample
target. In this situation, make sure that theendpoint.host
,endpoint.port
,http.proxyHost
,http.proxyPort
, andservice.url
properties are set correctly in thebuild.properties
file (as discussed in Setting Build Properties) before running the sample.
If the application runs successfully, you will see a message similar to the following:
[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: