Migration of service from DATAPOWER to APIGEE

ashwithds123
Participant IV

Hi @Dino, @Dino-at-Google, @williamssean, @Anil Sagar @ Google, @marshg@google.com, @Siddharth Barahalikar, @Kurt Googler Kanaskie

I am working on migrating a service from DataPower to Apigee.

Concern: For one of the SOAP services in DataPower the request payload is getting signed off before hitting the backend. (A header is generated with Signature value in DataPower as shown below). We are using certificates to sign the payload with the password associated with it.

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header>
      <wsse:Security SOAP-ENV:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsu:Timestamp wsu:Id="Timestamp-f1cd885f-336f-45cc-8c47-cdd78b4cd43b" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsu:Created>2019-10-07T19:39:30Z</wsu:Created>
            <wsu:Expires>2019-10-07T19:44:30Z</wsu:Expires>
         </wsu:Timestamp>
         <wsse:BinarySecurityToken wsu:Id="SecurityToken-3f132fb3-ca39-4d6f-b9fc-f0fb0625d957" 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" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">**********************************************************************************************************************************************************************************************************************************************=</wsse: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="#Timestamp-f1cd885f-336f-45cc-8c47-cdd78b4cd43b">
                  <Transforms>
                     <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  </Transforms>
                  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <DigestValue>*************</DigestValue>
               </Reference>
            </SignedInfo>
            <SignatureValue>*************==</SignatureValue>
            <KeyInfo>
               <wsse:SecurityTokenReference>
                  <wsse:Reference URI="#SecurityToken-3f13wetb3-ca39-4d4f-b9fc-f0fb0345d957" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
               </wsse:SecurityTokenReference>
            </KeyInfo>
         </Signature>
      </wsse:Security>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
      <ns0:IVRDataExchangeRequest xmlns:ns0="http://fiserv.com/BillerSolutions/OnDemand/IVRDataExchangeService/V20151201">
         <ns0:RequestHeader>
            <ns1:RequestID xmlns:ns1="http://schemas.datacontract.org/2004/07/demo.bs">EIS:252505de-91c5-49d6-97e9-26c2a04a7ade</ns1:RequestID>
            <ns1:SessionID xmlns:ns1="http://schemas.datacontract.org/2004/07/demo.bs">EIS:252505de-91c5-49d6-97e9-26c2a04a7ade</ns1:SessionID>
            <ns1:TimeStamp xmlns:ns1="http://schemas.datacontract.org/2004/07/demo.bs">2019-10-:22:55.101</ns1:TimeStamp>
            <ns1:VendorID xmlns:ns1="http://schemas.datacontract.org/2004/07/demo.bs">DemoLegacy</ns1:VendorID>
         </ns0:RequestHeader>
         <ns0:RequestBody>
            <ns1:AccountNumber xmlns:ns1="http://schemas.datacontract.org/2004/07/demo">86053</ns1:AccountNumber>
            <ns1:LanguageIndicator xmlns:ns1="http://schemas.datacontract.org/2004/07/demo">en-US</ns1:LanguageIndicator>
         </ns0:RequestBody>
      </ns0:IVRDataExchangeRequest>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

However, with the help of this repo https://github.com/DinoChiesa/ApigeeEdge-Java-WsSec-Signature I am able to generate the signature but it is not matching to our requirement as mentioned in the XML. Any help would be appreciated.

Regards,

Ashwith

0 22 1,152
22 REPLIES 22

WS-Security allows the client to specify which part or parts of the message gets signed, and how (which signing algorithm, how canonicalization is done, which key type, and so on).

Looking at your Signed SOAP message, I can see that the signature uses the same canonicalization, the same XMLDSIG sha (rsa-sha1) as is used by the Java callout you referenced; and I can also see that in your case, the signature has been applied to the Timestamp element in the header.

<Reference URI="#Timestamp-f1cd885f-336f-45cc-8c47-cdd78b4cd43b"> ...

Conversely the Java callout that you referenced ALWAYS signs only the Body element. In . the Java callout you are using (https://github.com/DinoChiesa/ApigeeEdge-Java-WsSec-Signature), this behavior is hard-coded.

Both approaches - the one used by your existing client or system to sign the Timestamp, and the one used by the Java callout to sign the Body - result in valid signatures. But if your server side is expecting a signature on the Timestamp element, validation by that server will fail if the message presents a signature that was computed on the Body element.

To resolve this, you would need to modify the Java code to sign the Timestamp element. You may need the callout to also explicitly insert a Timestamp element into the header, if it is not present. (It depends on whether the source/origin (unsigned) SOAP message includes the Timestamp element in the header)


Or,

Try this:

https://github.com/DinoChiesa/ApigeeEdge-Java-WsSec-Signature-2

It's a new, updated Ws-Security callout that is parameterizable. With that you can "turn off" signing of the Body. You can also configure rsa-sha256 as the signing algorithm, and sha256 as the digest algorithm. And there's more support for expiry and so on. It's much better than the original callout.

Hi @Dino-at-Google

Firstly, thanks for the reply. Is it possible to get the solution using JavaScript policy instead of using JavaCallout, just asking? If yes, can you guide me.

Regards,

Ashwith

No, I think it would be extraordinarily impractical to perform XMLDSIG within a JavaScript policy. A Java callout is probably better for this job.

I am working on a different version of that callout that is more configurable (signs the Timestamp or the Body or both, depending on how you configure it), and as a bonus, it does not depend on WSS4J so it will run in Apigee SaaS.

But it's not quite ready yet.

BTW it seems odd to me that in your case, you use WS-Sec to sign only the Timestamp element. That prevents a "replay" outside of the Expiry window, but.... the actual message Body is not signed or protected. That means an attacker could replay different requests (changing the body content) with the same timestamp.

Thank you so much for working on enhancing the JavaCallout policy.

However, it would be good if you can take my case as a consideration while developing. So that I can migrate the service into Apigee edge platform.

And when can I expect the new version (approximately in how many days from today)?

No promises, but my expectation is that within a few days, 2 or 3 days, I will have something to share.

And let me clarify: your goal is to SIGN the inbound ("bare") SOAP request, is that right?

What about the response flow? Are you looking to use Apigee Edge to verify WS-Security signatures on responses?

Q: your goal is to SIGN the inbound ("bare") SOAP request, is that right?

A: Yes, I am signing the inbound request. As mentioned above in the same format I need to sign the request payload.

Q: What about the response flow?

A: There is no response flow for our scenario.

Regards,

Ashwith

Hi @Dino-at-Google


Any luck on the signature generation using JavaCallout.

Will be waiting for your reply.

Regards,

Ashwith

Ashwith, have you been able to evaluate this Java callout?

Hi @Dino-at-Google,

Thank you so much for helping me out.

But I got stuck in removing the body reference from the request payload

9290-11.png

However, from the github doc I have implemented the required-signed-elements property in java-callout, I could not get rid of body reference in the payload.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<JavaCallout name="Java-WSSEC-Sign-1">
    <Properties>
        <Property name="digest-method">sha256</Property>
        <Property name="signing-method">rsa-sha256</Property>
        <Property name="expiry">5m</Property>
        <Property name="required-signed-elements">timestamp</Property>
        <Property name="private-key">{my_private_key}</Property>
        <Property name="certificate">{my_certificate}</Property>
    </Properties>
    <ClassName>com.google.apigee.edgecallouts.wssecdsig.Sign</ClassName>
    <ResourceURL>java://edge-wssecdsig-20191008.jar</ResourceURL>
</JavaCallout>

I understand. Let me look and see if I can duplicate that. (You're the first user of this callout)


EDIT: Check that - you are using "required-signed-elements" . That configuration property is used for the Validate callout only. It is ignored by the Sign callout. The property you want is called "elements-to-sign".

Hi @Dino-at-Google

Thank you so much I resolved timestamp concern.

One more issue: I see the following error in java callout.

Any help would be appreciated.

wssec_exception java.lang.IllegalStateException: Didn't find OpenSSL key. Found: org.bouncycastle.openssl.PEMKeyPair
wssec_error Didn't find OpenSSL key. Found: org.bouncycastle.openssl.PEMKeyPair

I don't understand. It's working, and also it's not working?

Can you explain under what circumstances you are seeing the error you reported?

Also if you set a Property "debug" to true, and if the error occurs again, you will get a stacktrace and that may help me diagnose.

<JavaCallout name="Java-WSSEC-Sign-1">
    <Properties>
        <Property name="debug">true</Property>
        ...
	

Can you show me the format of the PEM file you're using for the private key? What does the header look like? How did you generate the private key?

Ashwith - disregard my prior. I looked into it and found that the callout did not handle old-format RSA keys correctly. I've since updated the code so that it should avoid the error you described.

You'll need to get the latest .jar from the repo and include it into your API Proxy bundles. Please try again and let me know.

Hi @Dino-at-Google, @Dino

First of all, thank you so much for taking this as a priority. Still I am facing some hiccups here and there.

I see some difference between the Data power signature and APIGEE signature(generated using the java callout)

Here is the signature that is generated in APIGEE

 <SOAP-ENV:Header>
      <wssec:Security SOAP-ENV:mustUnderstand="1">
         <wsu:Timestamp wsu:Id="Timestamp-02deb072-c5e9-40d5-9f54-40f2bb0064ab">
            <wsu:Created>2019-10-16T17:49:28Z</wsu:Created>
            <wsu:Expires>2019-10-16T17:54:28Z</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="SecurityToken-cc3a4f52-db6a-4469-a644-3886f4e6578c">***********=</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="#Timestamp-02deb072-c5e9-40d5-9f54-40f2bb0064ab">
                  <Transforms>
                     <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  </Transforms>
                  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <DigestValue>*****=</DigestValue>
               </Reference>
            </SignedInfo>
            <SignatureValue>****************==</SignatureValue>
            <KeyInfo>
               <wssec:SecurityTokenReference>
                  <wssec:Reference URI="#SecurityToken-*******" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
               </wssec:SecurityTokenReference>
            </KeyInfo>
         </Signature>
      </wssec:Security>
   </SOAP-ENV:Header>


<br>

Please compare this payload with the signature Data power is generating (header payload that is posted in the first comment of this forum)

I see tags like wssec instead of wsse.

Would it be possible for you to spare some time in resolving my concern by scheduling a working session?

Email: ashwithds123@gmail.com

If yes, please ping to the metioned mail. Any help would be appreciated.

Regards,

Ashwith

The prefix for an XML Namespace should be irrelevant.

Any tool or system that is evaluating a document by comparing a prefix, is not handling XML Namespaces correctly.

If that sounds surprising to you, this Q&A should clarify.

So I don't think I'll be taking a change to stipulate the XML namespace prefix.

Can you tell me why you think you need the prefix to match exactly? IS there a system that is rejecting the document? Or are you just doing a visual comparison and drawing your own conclusion about incompatibility.

Hi @Dino-at-Google

Here are the differences between DataPower and APIGEE signature, based upon the following table corresponting tags needs to be updated in JavaCallout (it might be deletion or addition of parameters in xml tags)

Data Power APIGEE
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wssec="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">
<wsse:Security SOAP-ENV:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <wssec:Security SOAP-ENV:mustUnderstand="1">
<wsu:Timestamp wsu:Id="Timestamp-****" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <wsu:Timestamp wsu:Id="Timestamp-****">
<wsse:BinarySecurityToken wsu:Id="SecurityToken-3f132fb3-ca39-4d6f-b9fc-f0fb0625d957" 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" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <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="SecurityToken-***-***">
<wsse:SecurityTokenReference> <wssec:SecurityTokenReference>
<SOAP-ENV:Body> <SOAP-ENV:Body wsu:Id="Body-******">

None of these differences are material, as far as I can tell. They should not matter for an app or system that handles XML correctly. The XML Infoset is exactly the same. They are semantically equivalent.

Comparing XML documents by string comparison is not a useful exercise.

I will repeat my question from my prior comment: Do you have a system that is rejecting the generated document? or are you raising these differences as an issue based on your visual comparison of the string differences between the DP-generated and Apigee-generated documents?

Please answer that.

Hi @Dino, @Dino-at-Google,

Q: Do you have a system that is rejecting the generated document?

ANS: Yes, the backend is not accepting the generated signature.

Any help would be appreciated!

Regards,

Ashwith

Questions

  1. Are you using the same cert and key for the Apigee policy that you've used for the original signature?
  2. Does the backend take any configuration regarding expected prefixes?

desarrollo
Participant I

@Dino-at-Google, Hi, I am having a similar problem to the one mentioned, although I can use the java callout that was mentioned, the legacy is answering that it cannot validate the signature, however I think it is because of the prefixes that are generated since apigee are different, attached the request that comes out of apigee and the one that expects to receive the endpoint, as you can see, are also different than the way it is sent from apigee is not the same.

Request Expected:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ws="http://ws.legalcheck.cifin.com" 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-2795B41DA34FD80A771574109162742128"><wsu:Created>2019-11-18T20:32:42.742Z</wsu:Created><wsu:Expires>2019-11-18T23:19:22.742Z</wsu:Expires></wsu:Timestamp><ds:Signature Id="SIG-2795B41DA34FD80A771574109162617127" 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 ws 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-2795B41DA34FD80A771574109162615126"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces PrefixList="ws 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>6trQTlSQLxzB76UQVloueYy/FpI=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>i3vbBMSTsfbcWeZyuvcdhCDfqpYdaiABQl4V5Y16sWAizmyj3sts3HZ5yKqqkC49hcpPAb87hbM3
9dAqzWKDXRpUKkXH3MuwyMBVJiQ5+radnkCaR/9WHp9Gv6Md6a7F0tR6I8RzafOBMCV5uqPY9jnT
8fglapPvKZZIezyjP81rm/58EC8QAouRFvqr7y+zne3VhBaNtOL24OFwgIgkP17ZNMTFTOKIFPwF
p+5ulgjUC+HVuI7rfkMEJUy0wpWz7jt4RPQ+jzOx5S4i/cwebjr0EaaaySjeEezPpT27kSA4OPjh
vqkQGH2u5kkcTBDGi8fHJwISb3MIAXnuw6TigQ==</ds:SignatureValue><ds:KeyInfo Id="KI-2795B41DA34FD80A771574109162615124"><wsse:SecurityTokenReference wsu:Id="STR-2795B41DA34FD80A771574109162615125"><ds:X509Data><ds:X509IssuerSerial><ds:X509IssuerName>CN=creditoexpress</ds:X509IssuerName><ds:X509SerialNumber>1323432320</ds:X509SerialNumber></ds:X509IssuerSerial></ds:X509Data></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security></soapenv:Header><soapenv:Body wsu:Id="id-2795B41DA34FD80A771574109162615126" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><ws:consultaLegalCheckV2Xml soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><parametrosConsultaLegalCheck xsi:type="dto:ParametrosConsultaLegalCheckDTO" xmlns:dto="http://dto.legalcheck.cifin.com"><codigoInformacion xsi:type="soapenc:string" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">5698</codigoInformacion><numeroIdentificacion xsi:type="soapenc:string" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">14871281</numeroIdentificacion><password xsi:type="soapenc:string" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">WGPt3R</password><tipoIdentificacion xsi:type="soapenc:string" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">1</tipoIdentificacion><userId xsi:type="soapenc:string" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">478867</userId></parametrosConsultaLegalCheck></ws:consultaLegalCheckV2Xml></soapenv:Body></soapenv:Envelope>

The one that leaves from apigee is the following:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wssec="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" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ws="http://ws.legalcheck.cifin.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header><wssec:Security soapenv:mustUnderstand="1"><wsu:Timestamp wsu:Id="Timestamp-0f6815c8-c511-40c6-8464-cfcc9820f49b"><wsu:Created>2019-11-18T22:26:27Z</wsu:Created><wsu:Expires>2019-11-19T01:26:27Z</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="SecurityToken-e828bfab-bb52-4429-b6a4-755b26abc387">MIIC0zCCAbugAwIBAgIETuH5gDANBgkqhkiG9w0BAQsFADAZMRcwFQYDVQQDEw5jcmVkaXRvZXhwcmVzczAgFw0xOTA5MTExNTU2NTJaGA8yMjE2MTAyODE1NTY1MlowGTEXMBUGA1UEAxMOY3JlZGl0b2V4cHJlc3MwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCqQqeXnqqUN5BOi9qj+jXPxTJO3/Eg2+xxUUaKwDhnAsLL14Y6ejBiRnNIctsK0pJNzzF5rHpRS4hM1jtxLm3jVMtmg8oN3FSqShaxOgYSRzyPw8qI9ABdm6XMeGYsYWyYcrp8y3nkAq6hqxUZXGT34tePFeKul1itcwE3ukJVNwB9ER0yNduToRENDRxa5EF9NgKnVm6eD5o8Y2CwrSzSz2y1IJTKDs721qNhhRCsedO3BdS4idbQrff55rfWrrKdp5b1RLJniSmjC5ZKlAJJZr6Y5jDRxpX1PvRq+VjGs5c0fugDLDrj77pMhGnVgWbWTcbnlsULqdlfoXro0zaJAgMBAAGjITAfMB0GA1UdDgQWBBQPzOJty959stMf2TZ8o8Xp54ku2TANBgkqhkiG9w0BAQsFAAOCAQEAYbWhKhl3D5QlSd+aK59/RFHWxAKUtU/7Z1v9YUvCT/L3/+vR/4qF9/AohYtX3AT5AbnkIZaG32BgFOp6xqc8Nh1Dg0XOY4Sk+Pi6Cy9qAn6cxLurssxkBxNNehzaDHIuxlejjOQWxg40ziAKgxi7FeRHEwjhVQAB86gUY1UA1MgXgt4DCV5bO9fVRUTc2v6lMpyH/TpM/OMH5tIdljJ3Md38ybj6jlO4Fm4ifc/jEcEkin6nI6m6TxtuL48l8pM+/DKJVlF1pM2pXRwAB/BY5tz+eqLR9SzcwneKs2IIUelkNYrgPHJpp/WyRcplA4NbVxTZTdyNpHaHl3EiL69DGQ==</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/2001/04/xmldsig-more#rsa-sha256"/><Reference URI="#Body-d558d1e3-9bc1-4adb-b817-e162289bafcd"><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><DigestValue>Ojlq6f+4sLxVrsFJ//3pFhe7ex6NeUBlLiKXMdL0xh4=</DigestValue></Reference><Reference URI="#Timestamp-0f6815c8-c511-40c6-8464-cfcc9820f49b"><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><DigestValue>/02v0jJrVw0z8nj5HpfkBcVrY+WvKxPe/k2R9cpv6+Y=</DigestValue></Reference></SignedInfo><SignatureValue>pFI2YmNQtWeh60Jcy7HXRhrXpHbnQH1tsGM1Ht6dPyJl5yHlH3o0F95moNJcSyP54LY/OHBx5RqC W7aq9jeGXDzbd8sn2nVlx3DSIy9LoxRuzk/4T4rG2WnAJpu8JQWGtz1Z1TEcNCRZhN3FVDu59Jr9 quaz3GHdO51az6nBIC2UtDRUhVgaTi5851sHzjPFAKxf1vh+Bpsxm2l5aqfR1Pf2dKVZBRWGrbwv N5RCDuZfwLjaMgoWyoRwoo+2OuCkuYdqgRqBtJL9AY4oWcAyDH8q2xTxcMlZG9smI7frJ1cHfS5i i+ayeeW3tdqsmAVxZFawvScfTEwcD+fD+DcgEg==</SignatureValue><KeyInfo><wssec:SecurityTokenReference><wssec:Reference URI="#SecurityToken-e828bfab-bb52-4429-b6a4-755b26abc387" 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-d558d1e3-9bc1-4adb-b817-e162289bafcd"> <ws:consultaLegalCheckV2Xml soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <parametrosConsultaLegalCheck xmlns:dto="http://dto.legalcheck.cifin.com" xsi:type="dto:ParametrosConsultaLegalCheckDTO"> <codigoInformacion xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">5698</codigoInformacion> <numeroIdentificacion xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">14871281</numeroIdentificacion> <password xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">WGPt3R</password> <tipoIdentificacion xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">1</tipoIdentificacion> <userId xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">478867</userId> </parametrosConsultaLegalCheck> </ws:consultaLegalCheckV2Xml> </soapenv:Body> </soapenv:Envelope>

Hi - can you ask a new question please? I don't answer questions posed in answers.