Configuring Timestamp verification in WSIT through policy assertions
By ashutoshshahi on Mar 13, 2007
Glassfish V2 beta released yesterday (12th March 2007). It includes Microsoft Interoperability using WSIT. WSIT is being developed within the Glassfish community and will be delivered through Glassfish v2. You can learn more about WSIT and get the latest builds from the WSIT home page. Of course you do not need to download and install WSIT if you are using Glassfish beta or latest versions of Glassfish v2. Latest WSIT builds get integrated into Glassfish v2 on a periodic basic. For a tutorial on WSIT, check out tutorial.
Here I will describe some of the custom properties a user might want to set for Timestamps in the policy if he has a security enabled web service. These are custom WSIT specific policy assertions and provide additional control to the user over how to configure a service.
WS-SecurityPolicy specifies following construct to include a timestamp in SOAP Security header:
<wsp:Policy> <wsp:ExactlyOne> <wsp:All> <sp:AsymmetricBinding> <wsp:Policy> . . . <sp:IncludeTimestamp/> . . </wsp:Policy> </sp:AsymmetricBinding> . . </wsp:All> </wsp:ExactlyOne> </wsp:Policy>
This makes the SOAP message include a Timestamp element in Security header with creation time and expiry time. Here is a sample message with timestamp:
<S:Envelope xmlns:S="..." xmlns:wsse="..." xmlns:wsu="..."> <S:Header> <wsse:Security S:mustUnderstand="true"> <wsu:Timestamp wsu:Id="3"> <wsu:Created>2007-03-13T06:14:45Z</wsu:Created> <wsu:Expires>2007-03-13T06:19:45Z</wsu:Expires> </wsu:Timestamp> . . </wsse:Security> </S:Header> . . </S:Envelope>
Along with creation time and expiry time, there are two other properties based on which a service in WSIT can decide to accept or reject messages based on timestamp. They are:
MaxClockSkew: This sets the maximum difference allowed between the system clocks of the sender and recipient.
Here is what WSS 1.1 spec says about clock skew: The wsu:Expires child in a Timestamp is relative to the requestor's clock. In order to evaluate the expiration time, recipients need to recognize that the requestor's clock may not be synchronized to the recipient's clock,. The recipient MUST therefore make an assessment of the level of trust to be placed in the requestor's clock, since the recipient is called upon to evaluate whether the expiration time is in the past relative to the requestor's, not the recipient. The recipient may make a judgment of the requestor's likely current clock time by means not described in the WSS specification,for example an out-of-band clock synchronization protocol. The recipient may also use the creation time and the delays introduced by intermediate SOAP roles to estimate the degree of CLOCK SKEW.
TimestampFreshnessLimit: Sets the maximum duration of time after which the timestamp becomes stale. It is RECOMMENDED that Web Service producers provide a timestamp "freshness" limitation, and that any stale timestamps be rejected. As a guideline a value of 5 minutes can be used as a minimum to detect and reject replays.
By default the value of both these properties is set to 5 minutes in WSIT. This should be good enough for most use cases. But if someone wants to specify custom values for these properties, WSIT provides proprietary policy assertions for them. This is how it could be specified in the policy:
<wsp:Policy> <wsp:ExactlyOne> <wsp:All> <!-- Proprietary WSIT assertion --> <sc:ValidatorConfiguration xmlns:sc="http://schemas.sun.com/2006/03/wss/server" xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy" wspp:visibility="private" sc:maxClockSkew="0" sc:timestampFreshnessLimit="300000"> <sp:AsymmetricBinding> <wsp:Policy> . . . <sp:IncludeTimestamp/> . . </wsp:Policy> </sp:AsymmetricBinding> . . </wsp:All> </wsp:ExactlyOne> </wsp:Policy>
where the values of sc:maxClockSkew and sc:timestampFresshnessLimit are in milliseconds. Setting MaxClockSkew to 0 might be helpful if we are sure that client and service are on same system, or if the the systems are synchronized in time. TimestampFeshnessLimit should be greater than zero as a value of zero means timestamp becomes stale immediately. The default value of 5 minutes should be good in most cases, but can be kept less to avoid replay attacks in this duration.
The same properties can be specified on client side also in the wsit-client.xml file to set maxClockSkew and timestampFreshnessLimit to required values – the only change being the namespace of properties change to http://schemas.sun.com/2006/03/wss/client. The default remains 5 minutes for both of them.