Domains: Web Service Security: Timestamp

The user-specified name of this MBean instance.

This name is included as one of the key properties in the MBean's javax.management.ObjectName:
Name=user-specified-name

MBean Attribute:
WebserviceTimestampMBean.Name

Changes take effect after you redeploy the module or restart the server.

Specifies whether the Web Service assumes synchronized clocks.

If the clockSynchronized attribute is false, the Web Service rejects all inbound messages with that contain expirations, because this is the only safe way to ensure that the message hasn't already expired. In this case, the Web Service also does not enforce a freshness policy.

If this attribute is set to true, then the Web Service enforces expirations on inbound messages to the best of its ability and enforces an optional freshness policy (via maxProcessingDelay).

The default value of this attribute is true.

MBean Attribute:
WebserviceTimestampMBean.ClockSynchronized

If clocks are synchronized, this attribute describes the accuracy of the synchronization.

ClockPrecision is expressed in milliseconds. Clock precision is enforced by rendering all times into milliseconds since a common time 0 and dividing each time by clockPrecision. Comparisons for the purpose of policy enforcement are performed using the rounded times. This provides a mechanism for allowing for some reasonable level of clockskew. For example, if you're clocks are accurate to within 1 minute of each other, you would set your precision to 1 minute * 60 seconds * 1000 milliseconds or 60000. All times would be rounded to the nearest minute before comparison.

One significant side effect of setting clockPrecision to indicate low accuracy is that expiration periods smaller than clock precision cannot be enforced safely. As a result, if the expiration period of message is shorter than can be resolved given the system's clock precision, the message will be rejected as expired -- the only safe assumption. For example, assume your are accurate to within 1 minute of each other. If you received a message with an Expires time 10 seconds after the Created time, its clear that you would not reliably be able to enforce such an expiry -- after rounding, the Expires time is indistinguishable from the Created time. In these cases, the handler will reject the message. This behavior can be relaxed using the laxPrecision value described below.

MBean Attribute:
WebserviceTimestampMBean.ClockPrecision

This attribute allows you to relax the enforcement of clockPrecision.

Specifically, setting laxPrecision to true will cause the timestamp handler to make a best effort to enforce Expires even if it is set to an increment smaller than can be reliably enforced given the clock precision. The default value is false.

MBean Attribute:
WebserviceTimestampMBean.LaxPrecision

Specifies the freshness policy for received messages: the Web Serivce observes the processing delay by subtracting the Created time in the Timestamp from the current time.

If the observed processing delay is greater than maxProcessingDelay, the message is rejected as stale.

This attribute is specified in milliseconds, and is adjusted to reflect clockPrecision prior to enforcement. maxProcessingDelays smaller than clockPrecision are unenforceable and therefore rejected.

Setting maxProcessingDelay to NO_MAX_PROCESSING_DELAY disables to enforcement of the freshenss policy.

MBean Attribute:
WebserviceTimestampMBean.MaxProcessingDelay

Represents the length of time the sender wants the outbound message to be valid.

When the validityPeriod is positive, the TimestampHandler inserts an Expires element into the Timestamp header. The validityPeriod is expressed in seconds: the Expires time will be that many seconds ahead of the Timestamp's Created time.

MBean Attribute:
WebserviceTimestampMBean.ValidityPeriod

Minimum value: 1