LinkedIn
Twitter
@DChiesa @dchiesa1 I am working on SOAP digital Signature , and I am referring code which is given by you -https://github.com/DinoChiesa/Apigee-Java-WsSec-Signature-2. When I am signing through this Java code, the signature validation working fine but when I am signing through SOAPUI, validation signature is not working. I have attached the screenshot of SOAPUI configuration. Please suggest I am doing something wrong or issue with this Java code.
I have attached the screenshot of trace for both the cases pass and fail.
Solved
1 ACCEPTED SOLUTION
Hi, I'll see if I can help you out.
When I am signing through this Java code, the signature validation working fine but when I am signing through SOAPUI, validation signature is not working.
Are you saying that when you Sign a document through Java code and then try to validate ... through the same Java callout.... the validation works?
And ... when you sign through SOAPUI, and then try to validate through the Java callout , the validation does not work?
If that is the case, that's clear enough. Let me talk through the common reasons or causes for signature verificaiton failures.
- The most common reason I see for signature validation failing is a modification of the spacing in the signed document. If you "pretty print" the signed XML after the signature has been applied, adding spaces and indents into the XML document, and then try to verify the signature on that re-formatted document, the verification will fail. You must not change the document at all. (Specifically you must not change the SignedInfo element nor the referent of that element)
- The second most common cause of signature verification failures is that the Java policy is not configured in such a way to accept the signed document. You can configure the policy to accept rsa-sha256 or rsa-sha-1 for the signing method. You can configure the policy to accept sha1 or sha256 for the digest method. The canonicalization the callout uses is always "http://www.w3.org/2001/10/xml-exc-c14n#". In the SOAPUI configuration, You have it set to default. I don't know what that means, not sure what SOAPUI's default is here. The key identifier type can take many options (Issuer Name and Serial is but one option). And so on. Lots of other possibilities. You did not show the policy configuration you used. Check it and see. Maybe post it here and we can examine it together. Also you did not show the signed document that SOAPUI generated. If you post THAT here, that would help also.
- The third most common cause of problems is key disagreement. Make sure you are configuring the Java policy to accept and trust the cert that is present in the signed document. And that the cert actually holds the public key, corresponding to the private key that was used to sign the document. If you are using SOAPUI to sign, then you probably have that part right.
Good luck!
EDIT Just as a sanity check, I used this as my outgoing WS-Security config in SOAPUI
And I configured the parts-to-sign to include Timestamp and Body - be sure to use the right namespaces there. They are
- http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
- http://schemas.xmlsoap.org/soap/envelope/
...respectively. The resulting signed document looks like this:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:whatever.url">
<soapenv:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><wsu:Timestamp wsu:Id="TS-A5BD634E3E4A991EC116654468547491"><wsu:Created>2022-10-11T00:07:34Z</wsu:Created><wsu:Expires>2022-10-11T00:17:34Z</wsu:Expires></wsu:Timestamp><ds:Signature Id="SIG-A5BD634E3E4A991EC116654468547926" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces PrefixList="soapenv urn" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:CanonicalizationMethod><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI="#id-A5BD634E3E4A991EC116654468547825"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces PrefixList="urn" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>sJh0DJZZ+PuHDYq2zxBlcmO2oOE=</ds:DigestValue></ds:Reference><ds:Reference URI="#TS-A5BD634E3E4A991EC116654468547491"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces PrefixList="wsse soapenv urn" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>SMz/tlJQzW/aezde4xXem0ei3is=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>aXAXl/bnQmUw4IkGUhXZ7GC/ckNd92XMSHJuTm51d30AUevGdYmRRIABwewabpQ1khtDdFRRHs8zgnZ71NWWsEensMiviQvW0DFBlY8XlfcvJR+nAUNdNRhoYULNiA2uVpRhghf92TBUbwrpIwoTx9XYge6nFIGEEC9plMVEIicnXqSe8p0r6Q+eYidgM8qQkjTE2BqTquEz9+IdZ8WDyFIMrc2OCITegJqo29VOhLZGP/iuR23tZ6cb9S4JgJkdzBHZA9ch+tYoUBUju7nLQHnMtc3N1iHWDYFoNMR2B0XHnfqFrWTql9HpUif7u+CI98b6grPcsHVm+M8B7Mre8Q==</ds:SignatureValue><ds:KeyInfo Id="KI-A5BD634E3E4A991EC116654468547763"><wsse:SecurityTokenReference wsu:Id="STR-A5BD634E3E4A991EC116654468547794"><wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">MIIDczCCAlugAwIBAgIEelQdkTANBgkqhkiG9w0BAQsFADBqMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExETAPBgNVBAcTCEtpcmtsYW5kMRQwEgYDVQQKEwtHb29nbGUsIExMQzEPMA0GA1UECxMGQXBpZ2VlMRQwEgYDVQQDEwtEaW5vIENoaWVzYTAeFw0yMjEwMTAyMzU3MTlaFw0yMzAxMDgyMzU3MTlaMGoxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTERMA8GA1UEBxMIS2lya2xhbmQxFDASBgNVBAoTC0dvb2dsZSwgTExDMQ8wDQYDVQQLEwZBcGlnZWUxFDASBgNVBAMTC0Rpbm8gQ2hpZXNhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl8uWhbIFcPLOboKhZl/46czFMgYFJ9/VivBmb/+IAiTr1SWvzILjz0UTEmQz+hE+ySkIklfExHtTNREsgqqq+wHrV/g9/JaQa0s+bmgfIV/MyDMZUefh5cQZFiOUjsYiP660/83ZD3vaeL5+kLE5V3ZDXY4WX4UucEZbOoXQkkBtOYCjfuM1EtfQtv5LA6KpJC9l5E6NysMa7MxQ+Y7FhS1nIb+Dcp9LMFdOojqmxNkTHi540sH0VwLsi+O4tjaY41Ol93J7lkdpuTTezeBSc328u7GGXtn6f6Lx3WYfhCcCAzdfPtD+8MsOWS7rkQ8Z9A+Q9xFpJjb2Z7wFpmfcUQIDAQABoyEwHzAdBgNVHQ4EFgQUUM073/CWdR3SPVZDycaBzzIVCc0wDQYJKoZIhvcNAQELBQADggEBAAP87O+0++wu5AMNFXm/fdXzSyI0oS97Wwf3BhGxiyeC539kQuPLLp7rduyrnUBfrg+oU250X8qt2duOFX2JmbIwXb0DUuG4YGJHtAo7/EK/R38lNVqTj+UqmhVXk767uAIJZq6FRIxHnZPX9TDDt+nkd0YbwouTxYHIT18S8hcPouJucYK4fHeSJW3AdlaGNgIHhNLFBMIEoZw7kWE++ZuncUKNq2lSVoutUJdUiFvEPALwBea0u6/Gd2OXWf4pmkIgRfVqyWjiklsNmIbrRfzWJLKMsM4UTpblLoD0YbH7LojL7CX6UE/lmC+N66mChjneZLPv9UmKzXpunDJzf8E=</wsse:KeyIdentifier></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security></soapenv:Header>
<soapenv:Body wsu:Id="id-A5BD634E3E4A991EC116654468547825" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<urn:ApplicationUpdateRequest>
<urn:SessionID>hello</urn:SessionID>
<urn:ApplicationID>28728</urn:ApplicationID>
<urn:ProductCode>123</urn:ProductCode>
</urn:ApplicationUpdateRequest>
</soapenv:Body>
</soapenv:Envelope>
Notice I have not inserted newlines into the Header element, nor have I pretty-printed any of that. This is important! Signatures are sensitive to spaces and newlines in the XML, specifically in the SignedInfo element and in the elements that are being signed - Timestamp and Body in this case.
The corresponding configuration for the WS-Security Signature validation policy is like this:
<JavaCallout name='Java-WSSEC-Validate-4' continueOnError='true'>
<Properties>
<Property name='source'>message.content</Property>
<Property name='require-expiry'>false</Property>
<Property name='digest-method'>sha1</Property>
<Property name='signing-method'>rsa-sha1</Property>
<Property name='throw-fault-on-invalid'>false</Property>
<Property name='accept-thumbprints'>0542c43794bd41375ae2abde5f390049900ff889</Property>
</Properties>
<ClassName>com.google.apigee.callouts.wssecdsig.Validate</ClassName>
<ResourceURL>java://apigee-wssecdsig-20220916.jar</ResourceURL>
</JavaCallout>
That "accept-thumbprints" is the SHA1 thumbprint of the cert in the soapui keystore.
If I do all of this, then... it works. The Apigee policy successfully validates the signature on the signed document that has been generated by SOAPUI.
Here is the new SOAPUI config, the previous one is the old one. I tried with this new one but didn't work.
Sign Message-
<soapenv:Envelope xml
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:examples:helloservice" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><wsu:Timestamp wsu:Id="TS-0B942919A14B5D54561665503681653152"><wsu:Created>2022-10-11T15:54:41.653Z</wsu:Created><wsu:Expires>2022-10-11T16:54:41.653Z</wsu:Expires></wsu:Timestamp><ds:Signature Id="SIG-0B942919A14B5D54561665503681646151" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces PrefixList="soapenv urn xsd xsi" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:CanonicalizationMethod><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI="#id-0B942919A14B5D54561665503681640150"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces PrefixList="urn xsd xsi" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>UEyEqfj6BKUjeFk65poDCZwblXs=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>L9rNNEYmklXmV+FLtK1OT+j7Mj82i4iwvaOmDLxwqe1PxH1yrWK/uHoPGxpHXDB/7rsXhmi6IwhYWWWE2MVWnguo4DWAy2a3MIwrtZ5oWDOsPHUyB5h0xnGUwPBYjx2fHDRBgGNmf1I+dga4vtcOfGjJLdJbwX84N+5Z4B0H7Vuhq8y6+3WJgGb/ifNgrfNj2RBDNfIBtjLZimXcVJWNU5knLP/MZjRk/W0AAaWmvgzn3uua3RJoNLkK8FdCAEaQsBKL5rIkieANILTZ2Z3SWv6Gd5i/bT8NGj5I9UW6ChDK6YMsZHHYEtAHzTuX+E4lta2bYPF1+0nStKLR+XAHqA==</ds:SignatureValue><ds:KeyInfo Id="KI-0B942919A14B5D54561665503681640148"><wsse:SecurityTokenReference wsu:Id="STR-0B942919A14B5D54561665503681640149"><wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">MIIDSzCCAjOgAwIBAgIISbqp4r2sAMMwDQYJKoZIhvcNAQELBQAwHjELMAkGA1UEBhMCSU4xDzANBgNVBAMMBkFQSUdFRTAeFw0yMjA5MjYxMTIzMTlaFw0yMzA5MjYxMTIzMTlaMB4xCzAJBgNVBAYTAklOMQ8wDQYDVQQDDAZBUElHRUUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELeWIJjJmJtMknjrRslIqgaamSp9I1Uope8wgyN2xBsXiE+emp1e4yH6wz/fTFbW9t3Md9mxEDdKWT0D1TXi53+YnVPOEE50wPOeRYR6mBxwR1y4+JmOUnvi2lZwQFC09bqQ4RSCIaYBGPaG/g81/XnN8E/3c26EHBPtbEdApwiUmXqlNu9T6qvoDjlN1jOr80mun5EqG3d17o6EzD/yL6nSmRKe5YqMCcpQDjByqN+wuuQatO2XgGbkeQDxxknW9kP6dv1JZtLKojoPpJDqa+2+MBvJZcuLA6BJ2v/ReAE7kfnh2juVDxiHo51c5beKNddZQXPQamDGeCh3bvov7AgMBAAGjgYwwgYkwDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQUI3X73I3SKY/pR8qrFvaqXqRLfz4wTQYDVR0jBEYwRIAUI3X73I3SKY/pR8qrFvaqXqRLfz6hIqQgMB4xCzAJBgNVBAYTAklOMQ8wDQYDVQQDDAZBUElHRUWCCEm6qeK9rADDMAsGA1UdDwQEAwICvDANBgkqhkiG9w0BAQsFAAOCAQEAGZa7JvKuqgZtLOY83TVpLXc609/3ePjET2X7tmYDh4YT41SaYZnNbLgvihkHmvZNsqYBdB4oKUQm0+LaGd1EYEzEIq7WZ6WM2XhuFDnZrItSY+AKDquoUhEaSGQphHPTPm1TPAspkcpH/c9mWNhvA1q0xfPih27Rz+ujD+lNqVUMu5wWMEt2e+HELv2b01D7VDT7+g4lzj3TdVIW5rMzOAmA+fCz13Wu7KvAj5B8iGczpijIDUevusUjuC8NjmTIwrmmyKiMh28/Iic3jVrViP37aVtk/lYZ2qSRlP/q+JIY9ojz3O/brF3xa2q7flJa8SAQMv834W3pA+1nYMJc1g==</wsse:KeyIdentifier></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security></soapenv:Header>
<soapenv:Body wsu:Id="id-0B942919A14B5D54561665503681640150" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<urn:sayHello soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<firstName xsi:type="xsd:string">Pankaj</firstName>
</urn:sayHello>
</soapenv:Body>
</soapenv:Envelope>ns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:examples:helloservice" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><wsu:Timestamp wsu:Id="TS-0B942919A14B5D54561665503681653152"><wsu:Created>2022-10-11T15:54:41.653Z</wsu:Created><wsu:Expires>2022-10-11T16:54:41.653Z</wsu:Expires></wsu:Timestamp><ds:Signature Id="SIG-0B942919A14B5D54561665503681646151" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces PrefixList="soapenv urn xsd xsi" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:CanonicalizationMethod><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI="#id-0B942919A14B5D54561665503681640150"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces PrefixList="urn xsd xsi" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>UEyEqfj6BKUjeFk65poDCZwblXs=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>L9rNNEYmklXmV+FLtK1OT+j7Mj82i4iwvaOmDLxwqe1PxH1yrWK/uHoPGxpHXDB/7rsXhmi6IwhYWWWE2MVWnguo4DWAy2a3MIwrtZ5oWDOsPHUyB5h0xnGUwPBYjx2fHDRBgGNmf1I+dga4vtcOfGjJLdJbwX84N+5Z4B0H7Vuhq8y6+3WJgGb/ifNgrfNj2RBDNfIBtjLZimXcVJWNU5knLP/MZjRk/W0AAaWmvgzn3uua3RJoNLkK8FdCAEaQsBKL5rIkieANILTZ2Z3SWv6Gd5i/bT8NGj5I9UW6ChDK6YMsZHHYEtAHzTuX+E4lta2bYPF1+0nStKLR+XAHqA==</ds:SignatureValue><ds:KeyInfo Id="KI-0B942919A14B5D54561665503681640148"><wsse:SecurityTokenReference wsu:Id="STR-0B942919A14B5D54561665503681640149"><wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">MIIDSzCCAjOgAwIBAgIISbqp4r2sAMMwDQYJKoZIhvcNAQELBQAwHjELMAkGA1UEBhMCSU4xDzANBgNVBAMMBkFQSUdFRTAeFw0yMjA5MjYxMTIzMTlaFw0yMzA5MjYxMTIzMTlaMB4xCzAJBgNVBAYTAklOMQ8wDQYDVQQDDAZBUElHRUUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELeWIJjJmJtMknjrRslIqgaamSp9I1Uope8wgyN2xBsXiE+emp1e4yH6wz/fTFbW9t3Md9mxEDdKWT0D1TXi53+YnVPOEE50wPOeRYR6mBxwR1y4+JmOUnvi2lZwQFC09bqQ4RSCIaYBGPaG/g81/XnN8E/3c26EHBPtbEdApwiUmXqlNu9T6qvoDjlN1jOr80mun5EqG3d17o6EzD/yL6nSmRKe5YqMCcpQDjByqN+wuuQatO2XgGbkeQDxxknW9kP6dv1JZtLKojoPpJDqa+2+MBvJZcuLA6BJ2v/ReAE7kfnh2juVDxiHo51c5beKNddZQXPQamDGeCh3bvov7AgMBAAGjgYwwgYkwDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQUI3X73I3SKY/pR8qrFvaqXqRLfz4wTQYDVR0jBEYwRIAUI3X73I3SKY/pR8qrFvaqXqRLfz6hIqQgMB4xCzAJBgNVBAYTAklOMQ8wDQYDVQQDDAZBUElHRUWCCEm6qeK9rADDMAsGA1UdDwQEAwICvDANBgkqhkiG9w0BAQsFAAOCAQEAGZa7JvKuqgZtLOY83TVpLXc609/3ePjET2X7tmYDh4YT41SaYZnNbLgvihkHmvZNsqYBdB4oKUQm0+LaGd1EYEzEIq7WZ6WM2XhuFDnZrItSY+AKDquoUhEaSGQphHPTPm1TPAspkcpH/c9mWNhvA1q0xfPih27Rz+ujD+lNqVUMu5wWMEt2e+HELv2b01D7VDT7+g4lzj3TdVIW5rMzOAmA+fCz13Wu7KvAj5B8iGczpijIDUevusUjuC8NjmTIwrmmyKiMh28/Iic3jVrViP37aVtk/lYZ2qSRlP/q+JIY9ojz3O/brF3xa2q7flJa8SAQMv834W3pA+1nYMJc1g==</wsse:KeyIdentifier></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security></soapenv:Header> <soapenv:Body wsu:Id="id-0B942919A14B5D54561665503681640150" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <urn:sayHello soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <firstName xsi:type="xsd:string">Pankaj</firstName> </urn:sayHello> </soapenv:Body> </soapenv:Envelope>
SOAPUI Config-
ok thanks, that's helpful.
I see from that signed document that there is a wsu:Timestamp in the header, with "Created" and "Expires" child elements. Here is the pretty-printed version that allows you to see it clearly:
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:examples:helloservice"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsu:Timestamp wsu:Id="TS-0B942919A14B5D54561665503681653152">
<wsu:Created>2022-10-11T15:54:41.653Z</wsu:Created>
<wsu:Expires>2022-10-11T16:54:41.653Z</wsu:Expires>
</wsu:Timestamp>
<ds:Signature Id="SIG-0B942919A14B5D54561665503681646151"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
...
But the signature does not sign that Timestamp. I can determine that by examining the SignedInfo element from the signed document. Again, pretty-printed:
...
<ds:Signature Id="SIG-0B942919A14B5D54561665503681646151"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="soapenv urn xsd xsi"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#id-0B942919A14B5D54561665503681640150">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="urn xsd xsi"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>UEyEqfj6BKUjeFk65poDCZwblXs=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
...
The list of ds:Reference elements indicates WHAT is signed within a signed document. In your document there is a single ds:Reference element, and the URI attribute refers to the Body element.
By default the WS-Security signature validation callout requires that both Body and Timestamp are signed. The signed document would show two ds:Reference elements , with different URI attributes, pointing to the Timestamp and the Body elements, respectively. This is a best practice, as described by this WS-Attacks.org article . Requiring a signed timestamp at signature-verification time is important because it prevents replay attacks. All crypto is vulnerable to attack, given enough time and compute resources. The timestamp in a WS-Security header is specifically intended to prevent attacks that take a long time. The timestamp element in your document says that it's good for 1 hour. (That seems like an overly-long time, in my opinion. It should not need to have a lifetime of more than a few minutes, unless you're storing that XML in a queue for later processing.) So the callout is telling you "signature did not verify" because the timestamp is not signed.
There are two ways to avoid this "signature did not verify" problem:
-
RECOMMENDED. Add the Timestamp to the parts-to-sign when you specify the WS-Security Outgoing configuration in SOAPUI. It should use Element name Timestamp and namespace URI http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
- configure the Java callout to NOT require that the timestamp be signed. This is not recommended as it weakens your security protections. So I strongly advise against it. But you can do so by specifying the required-signed-elements property to be "body" in the policy configuration. This is also described in the README.
There IS a bug in the callout, in that it does not TELL YOU that the reason the signature was rejected was because of the unsigned Timestamp element. I will fix that so that the callout sets the wssec_error context variable indicating the reason for the failure. I've updated the callout to version 202210112 with this fix. Thanks for your patience and assistance in working through this.
@pankajrai9026 wrote:
but as per standard signature element directly come in header part as well.
To which standard do you refer? I reviewed the WS-Security specification in some detail. This is what it says in relation to signatures:
This document defines syntax and semantics of signatures within a <wsse:Security> element. This document does not constrain any signature appearing outside of a <wsse:Security> element.
Ok, so that says that in the context of a Signature that is compliant with the WS-Security standard, the Signature element is ALWAYS a child of the wsse:Security element. This is contrary to what you stated.
Also in that document, I could not find a specific explicit statement saying that the wsse:Security header must always be a child of the soap:Header element. But, I did find repeated informal statements referring to the wsse:Security header block .
Also, every example shows the wsse:Security element as a child of the soap:Header.
All of this implies that the wsse:Security element is always a child of soap:Header.
Now, if you have a document that has soap:Envelope/soap:Header/Signature , that is perfectly fine. XML is extensible, any application can organize the elements in the way it sees fit. But such a signature is not compliant with the WS-Security standard. The Java callout we are discussing here is used for Signatures that comply with the WS-Security standard.
If you have a Signature that complies with XMLDSIG on a document, this WS-Security Java callout is probably not the right thing to use. There is a separate callout for Apigee that can generate and validate signatures that conform to XMLDSIG. Look here. But this latter callout has some restrictions - it works by generating or validating signatures that apply to the entire document. And the Signature element is always a child of root. If you have Envelope/Header/Signature, then you may need to create your own callout that works with that non-standard scheme.
If I am overlooking a standard, please inform me.
