Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

Validation error when i sign payload using Apigee-Java-WsSec-Signature-2

I am trying to sign a payload using Dino's java callout 2. When i try to validate the same message i signed by invoking validate endpoint using same cert, its failing. I see some special characters in the signed payload . not sure if its causing the issue. anyone ran into similar problem?  Here are my validation and signing configurations.

Sign method: 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<JavaCallout name="Java-WSSEC-Sign-7">
<Properties>
<Property name="source">message.content</Property>
<Property name="expiry">50m</Property>
<Property name="signing-method">rsa-sha1</Property>
<Property name="digest-method">sha1</Property>
<Property name="private-key">{my_private_key}</Property>
<Property name="private-key-password">mypassword</Property>
<Property name="certificate">{my_certificate}</Property>
</Properties>
<ClassName>com.google.apigee.callouts.wssecdsig.Sign</ClassName>
<ResourceURL>java://apigee-wssecdsig-20240426.jar</ResourceURL>
</JavaCallout>

 

Validate: 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<JavaCallout name="Java-WSSEC-Validate-4" continueOnError="false">
<Properties>
<Property name="debug">true</Property>
<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="certificate">{my_certificate}</Property>
</Properties>
<ClassName>com.google.apigee.callouts.wssecdsig.Validate</ClassName>
<ResourceURL>java://apigee-wssecdsig-20240426.jar</ResourceURL>
</JavaCallout>

 

signature elements looks like below with carriage return escape characters. 

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns1="http://ws.example.com/">
<soapenv:Header>
<wssec:Security xmlns:wssec="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">
<wsu:Timestamp wsu:Id="TS-100">
<wsu:Created>2024-11-14T22:20:19Z</wsu:Created>
<wsu:Expires>2024-11-14T23:10:19Z</wsu:Expires>
</wsu:Timestamp>
<wssec:BinarySecurityToken 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" wsu:Id="ST-101">MIIGgDCCBWigAwIBAgIQC/aTObQ4Qc7czcFp/xTgJzANBgkqhkiG9w0BAQsFADBeMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMR0wGwYDVQQDExRHZW9UcnVzdCBSU0EgQ0EgMjAxODAeFw0yNDA1MjAwMDAwMDBaFw0yNTA2MTkyMzU5NTlaMGUxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVUZXhhczEPMA0GA1UEBxMGRGFsbGFzMRYwFAYDVQQKEw1Db21lcmljYSBCYW5rMR0wGwYDVQQDExRhcGkuZGV2LmNvbWVyaWNhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANThaeoNRbtMhK5gUxTONlRFktx+czbwms1Xce1SxKxCW8Vz7LrdJpYL02zQ5U0uFxhr9DgwuVN0e4vDLDHJR8T++lgMTSRCMpww+Ucd3U2YiUgcHBRnQdeNG8rqrJGTO0bXP18B12F0nQuYLztRKscPDkl8EsZQ0g2KPhUeK89HRrULGnl8uxeQi33tmjcgJ4cVhfuHNV48y9tv0IkmERX0dv3Gg5oTqUFojSL3HFNHGQEL/GM+9peUrye4oyBdjCwhFAKx/9juOizrBkKoXhlY+eiQpDJASYjIHa90d9aebQYarpYW/bxchwGL1sK3grXCAnV9yzRvmytd7lFvIJkCAwEAAaOCAzEwggMtMB8GA1UdIwQYMBaAFJBY/7CcdahRVHex7fKjQxY4nmzFMB0GA1UdDgQWBBQE6lf0mEDlhg/RZeuIN72fP+FBtTA1BgNVHREELjAsghRhcGkuZGV2LmNvbWVyaWNhLmNvbYIUYXBpLmJsZC5jb21lcmljYS5jb20wPgYDVR0gBDcwNTAzBgZngQwBAgIwKTAnBggrBgEFBQcCARYbaHR0cDovL3d3dy5kaWdpY2VydC5jb20vQ1BTMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL2NkcC5nZW90cnVzdC5jb20vR2VvVHJ1c3RSU0FDQTIwMTguY3JsMHUGCCsGAQUFBwEBBGkwZzAmBggrBgEFBQcwAYYaaHR0cDovL3N0YXR1cy5nZW90cnVzdC5jb20wPQYIKwYBBQUHMAKGMWh0dHA6Ly9jYWNlcnRzLmdlb3RydXN0LmNvbS9HZW9UcnVzdFJTQUNBMjAxOC5jcnQwDAYDVR0TAQH/BAIwADCCAX4GCisGAQQB1nkCBAIEggFuBIIBagFoAHYAzxFW7tUufK/zh1vZaS6b6RpxZ0qwF+ysAdJbd87MOwgAAAGPljXYPQAABAMARzBFAiEAiVT0r8AkWnttcAO3l4Ju6tqslhPJcIi06PEQojmQhssCIADVFOpwYvWqehGiAs2TvtorYVTAKvHzfTYB1HLL2nFbAHUAfVkeEuF4KnscYWd8Xv340IdcFKBOlZ65Ay/ZDowuebgAAAGPljXYRQAABAMARjBEAiBe1Csv5IaTSNUcSFRD71xLCWrGffto6VhG78j/JA49UgIgCT7k32/gJNfFCr8WV0KGk3YcQrNv51UsMqK2VgzJ/E8AdwDm0jFjQHeMwRBBBtdxuc7B0kD2loSG+7qHMh39HjeOUAAAAY+WNdhRAAAEAwBIMEYCIQDtTFTYcjVvdNDXAqkJkmOf7XZXkluypPjoPGntBRAgiAIhAOLredI/auWiUGty6XY2rYJcz1RVBQhKGfDSmH7YtJmSMA0GCSqGSIb3DQEBCwUAA4IBAQB4jyskMnpr/W8atAVMlmuF9wLUcjzCeRAhqmZnVF7RFNYyUMyxQw8t3mW3wu+/rpUBJdZlRls3KkiptPaCYfa6EjXz2OG74ZtSdwjae+ApnZQsC7nkhYqIvPLpV9gfEpgtdwOp3vSBGk3UCe8MLKUZ6GvQCkgl98OWVbEVG5blPjYOhPbGfUaIXC3wrYA+QJ8cfEr0d67XOFND+4BEsIC5szFzAJeVBFSqxzHPp4P6WMcgEL/A1hWQktqYe9tAoFlHMvaiAJql5JTr85pRkFRTs0TA0Qj2y622J4/sIK5veLNzOVPSYyx5sXRqfstLKRbXJU/m9AJ+y9R9dg/xLZXs</wssec:BinarySecurityToken>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#Body-102">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>lQIvfWFF4/I1s8TG7qYBtcbp3gA=</DigestValue>
</Reference>
<Reference URI="#TS-100">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>aS9BHAuFMsHTvRq736H2PO+E2gQ=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>myrMpAUf+CHYsE1mUxViYb8t9jlZhqP8o0AJC+QUHAY4Z/fZz1HXSwDQOmLFmwTDlf4PW2RVFEPP&#xD;
ePttNJHfmYrKyWjSUxwR2VjgtluqcNfIMQPfOS6cjWD67t7xmwpBT7EdO525lNeU6y/fBmcDH0MM&#xD;
tK9DSyR0hkxXlBowlum0bsm0TWOhV0AN69YI4sQfnBcLusOP6YKJ0NK387CUxN4l8DdUspVML77n&#xD;
puJywTD/CW5J2MM6plWfeZm3TFv2fN2G4/a2TZ6POtSvava9z4niWH7uCFeoo9VbP4FCqLBYRBzK&#xD;
7fgcu2i+GuIv+xZHHhs/KnizP1F6DsFw5zU9XQ==</SignatureValue>
<KeyInfo>
<wssec:SecurityTokenReference>
<wssec:Reference URI="#ST-101" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wssec:SecurityTokenReference>
</KeyInfo>
</Signature>
</wssec:Security>
</soapenv:Header>
<soapenv:Body wsu:Id="Body-102">
<ns1:sumResponse>
<ns1:return>9</ns1:return>
</ns1:sumResponse>
</soapenv:Body>
</soapenv:Envelope>

 

 

Solved Solved
0 8 285
2 ACCEPTED SOLUTIONS


@ranne wrote:

my requirement is to keep following element intact and sign with wsse namespace prefixes. 


<soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
    xmlns:ser="http://webservices.cashedge.com/services"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <soapenv:Header>
      <ser:AuthHeader>
        <ser:HomeID>redacted</ser:HomeID>
        <oas:Security>
          <oas:UsernameToken>
            <oas:Username>redacted</oas:Username>
            <oas:Password>redacted</oas:Password>
          </oas:UsernameToken>
        </oas:Security>
      </ser:AuthHeader>
      ...     

The callout will not help you do that.

According to the standard, the Security Header must be a child of the SOAP header.  In your example, you have the Security Header as a child of... some other element. That opens the signed document to signature wrapping attacks. The callout won't allow that.  It's not secure.

You need to use something like this structure:  

 

<soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
    xmlns:ser="http://webservices.cashedge.com/services"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <soapenv:Header>
      <ser:AuthHeader>
        <ser:HomeID>redacted</ser:HomeID>
      </ser:AuthHeader>
      <oas:Security>
        <oas:UsernameToken>
          <oas:Username>redacted</oas:Username>
          <oas:Password>redacted</oas:Password>
        </oas:UsernameToken>
      </oas:Security>
      ...     

 

The problem you are seeing has nothing to do with the prefix.  You can use oas, wsse, wssec, dpc, or anything else you please for the prefix. The important matter is the element hierarchy.  It's Envelope/Header/Security.  You cannot use Envelope/Header/AuthHeader/Security .

One could argue that the Signing callout should not accept your document, with that broken hierarchy.  That's a fair point. The Validate callout though, is correctly rejecting the signed document.

If you change your requirements, it will work. 

BTW, the error message from the Validate callout was... not ideal in the case where you had a mis-placed Security element.  I've updated the callout to be more explicit about that now.  You can pull the latest and get that update.

 

View solution in original post

  • There should be no licensing issue. The code is licensed under the Apache License v2.0. Which means you can use it for whatever purpose you desire. 
  • You can modify the code to do as you say.  I advise against it because of the signature wrapping attack risk. But I understand your situation. As far as I can tell the Sign callout will just work - it is the Validate that is rejecting the Security header because of its placement.  So you would need to modify only that.
  • I modified the callout yesterday to be more explicit about checking the placement of the Security header. If you get the latest code it should be easy to modify it to eliminate that check.   In fact I guess I could try making it an option in the callout. 
  • The &#xD is just a carriage return. That is an XML-safe encoding of 0x0D, which is CR.  Any system that correctly processes XML will be able to handle that. more: https://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references 

View solution in original post

8 REPLIES 8