Ashutosh's Blog

Its been quite some time since milestone 2 of Web Services Interoperability Technologies (WSIT) was released. We have added a number of features and bug fixes to Security module of WSIT i.e. xwss since then. Here is a list of some of the important features/fixes you can expect from the latest promoted build or the upcoming milestone 3 release:

1. Security path is now much faster than milestone 2. We no longer convert soap messages to DOM for signing/encryption. Security operations are now performed in a streaming fashion. In other words, security operations are performed when the message is being written to transport wire. This results in huge performance gains as message is no longer converted to DOM objects. Our initial tests suggest almost a gain of 30-40% over previous implementation.

2. Support for EncryptedHeaders: WSS1.1 introduced an additional element <wsse11:EncryptedHeader> for containing encrypted SOAP header blocks. We now support this for WSS1.1 messages.
   What this means for a SOAP Message?
   If the EncryptedParts assertion for a SOAP message contains encryption of a SOAP header e.g. an addressing header, the header is first encrypted (resulting in an EncryptedData element) and then the result is wrapped with a wsse11:EncryptedHeader element.
   What are the other changes?
   If the referencing security header block contains mustUnderstand, role/actor or relay attributes, those attributes and the associated values must be copied to this wsse11:EncryptedHeader element. The ReferenceList in the referencing Security Header should now refer to this wsse11:EncryptedHeader element and not to the contained EncryptedData element.
   How does this help?
   A SOAP node can now decide if it is required to process an encrypted SOAP header. If the mustUnderstand attribute is set to true, a SOAP node/processor now must be aware of this encrypted header and know how to decrypt and convert into original header block. It should raise a fault if it cannot decrypt the block or cannot process (or understand) the decrypted block. It was not possible with just an EncryptedData as a SOAP header.

3. Support for LaxTsLast Layout: LaxTsLast (LaxTimestampLast) layout feature was not functional in WSIT till milestone 2 (Refer security status notes of M2). If a timestamp was inserted, it was always on top; this is now a supported feature. By default, we always insert Timestamp at the top of Security header in Lax and Strict modes; in LaxTsFirst, it is ofcourse supposed to be at the top.
   Is timestamp as last element in security header useful?
   If wsu:Timestamp is the first element in security header, we can process it first, and safely fail if the timestamp appears stale; thus avoiding much more time consuming signature and encryption operations. On the other hand some might say that we made a decision on freshness of timestamp without actually verifying signature – this is where LaxTsLast comes into picture; so that we can perform signature verification on timestamp before checking its freshness. Actually, it does not matter as had the timestamp been a tampered one, we would eventually reject it during signature verification. So, timestamp at top should be the popular choice as it provides the option of rejecting stale messages early in the processing. Note: WSIT always signs a wsu:Timestamp if it is included in the Security header.

4. Better Policy verification of incoming messages: Policy verification for security till Milestone 2 of WSIT was very minimal (Refer security status notes of M2) and did not work when the payload of soap message was encrypted. We now have a much better support to reject messages which do not confer to the policy of the service wsdl – e.g. some targets not being signed/encrypted, correct token inclusion policy etc. One thing we still do not check is mismatch in AlgorithmSuite values between the service policy and the policy used by the client to secure the message.

5. Apart from these features, we have had numerous bug fixes and feature additions. Give the latest WSIT a try, and put across your feedback to users@wsit.dev.java.net.