SoapUI 4.5.1 does now allow to sign BinarySecurityToken
A regression in SoapUI 4.5.1 due to the upgrade to wss4j-1.6.2 blocks us from upgrading to the latest version. Since SoapUI 4.5.1 it is not possible to sign the wsse:BinarySecurityToken.
A part referencing {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}BinarySecurityToken generates an error **Element to encrypt/sign not found**. In SoapUI 4.0.1/wss4j-1.5.x, there was a workaround to add a part named 'Token' (no namespace) which was resolved to the BinarySecurityToken by wss4j. This is not the case in 1.6.2 anymore.
The implementation of the Signature step should add all tokens to the SOAP header before hashing the signature parts. This is not the case in SoapUI. Another solution would be to add a WSS Entry BinarySecurityToken (cfr the Username entry) to specify the token before the Signature entry.
Signing the security token is a best practice for avoid token substitution as described in the OASIS specification:
http://docs.oasis-open.org/wss-m/wss/v1 ... c307416645
The issue was reported in July 2009, but the workaround given is not acceptable as it generates double signatures.
viewtopic.php?t=2086
The issue was also reported on the Communicaty Board in July 2012, but no response was given to this post.
viewtopic.php?f=13&t=14296&hilit=token
Please provide a solution to this problem.
A part referencing {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}BinarySecurityToken generates an error **Element to encrypt/sign not found**. In SoapUI 4.0.1/wss4j-1.5.x, there was a workaround to add a part named 'Token' (no namespace) which was resolved to the BinarySecurityToken by wss4j. This is not the case in 1.6.2 anymore.
The implementation of the Signature step should add all tokens to the SOAP header before hashing the signature parts. This is not the case in SoapUI. Another solution would be to add a WSS Entry BinarySecurityToken (cfr the Username entry) to specify the token before the Signature entry.
Signing the security token is a best practice for avoid token substitution as described in the OASIS specification:
http://docs.oasis-open.org/wss-m/wss/v1 ... c307416645
The issue was reported in July 2009, but the workaround given is not acceptable as it generates double signatures.
viewtopic.php?t=2086
The issue was also reported on the Communicaty Board in July 2012, but no response was given to this post.
viewtopic.php?f=13&t=14296&hilit=token
Please provide a solution to this problem.
