Forum Discussion
I think I found a solution (or work-around); I noticed that the request is changing slightly once it leaves SOAP UI:
For example the original request may have a field like <payload>cid:147612301643</payload>
But after if gets signed it then changes to <payload><inc:Include href="cid:147612301643" xmlns:inc="http://www.w3.org/2004/08/xop/include"/></payload> which fails any hash check on a request since the signed message has been modified.
But if you replace the original entry in SOAP UI with the later (from the above examples), the message gets signed as is and passes the hash validation on the target server.
Hope this helps,
V
Yes this helps a Great Deal ! Thanks, this solution works, I find I have to attach the file using the original WSDL format
example first in order to set the Attachment Part to the generated partnumber (in example below) 147612301643 here:
<payload>cid:147612301643</payload>
Then once the file is attached, change this line in the request message to the following format (your example correct as is :)
<payload><inc:Include href="cid:147612301643" xmlns:inc="http://www.w3.org/2004/08/xop/include"/></payload>
DataPower then does then successfully verify the signed message/attachment - Presumably the problem we're fixing is a minor bug in SOAPUI signing-MTOM-attachments, which needs to be addressed in a future release.
Many thanks for your speedy reply...
Regards Gavin Bayfield
- grb1239 years agoNew Contributor
Still confused around whether the SOAUP MTOM Client we have 'working' is ACTUALLY Signing the Attachment Or Not ?
On the Server side, we're successfully Verifying the SOAP WSSEC Digital Signature passed in, but suspect the Enclosed Attachment is NOT part of the SOAPUI-Generated Signature- in other words, SOAPUI is/can ONLY in effect sign the Body (so the XML Infoset being processed does not include a Base64Binary component representing the attachment) ??
Can SmartBear pls clarify the Signing Attachment Capabilities for MTOM Support in SOUPUI please ??
Regards Gavin Bayfield
- OLensmar9 years agoStaff
Hi all,
from what I can see in the code you are correct with the assessment that SoapUI does that signing before it modifies the message for MTOM (i.e. moves the binary content to a separate multipart) - which makes the signature invalid. Perhaps SoapUI should perform the MTOM processing before signing the request - although that would result in the MTOM multipart not being signed itself.
I'm not sure what the actual rules for MTOM/WSS are; could it be that the server should first "inline" the MTOM attachment before validating the signature (which it doesn't seem to be doing)?
I'll dig around a little more online...
/Ole
Related Content
- 9 years ago
- 2 years ago
- 4 years ago
- 9 years ago
- 3 years ago
Recent Discussions
- 15 years ago