Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
OpenSSL SOAP WS-Security digest/signature issue
514 views
Skip to first unread message
SterlingSL
Jun 27, 2018, 12:57:48 PM6/27/18
to
We currently have OpenSSL 1.0.2o on the HPNS. We have a customer requirement to send a SOAP request with the same WS-Security header which is being generated by a windows test app 'SoapUI' (SmartBear). Internally the customer is using another black box they refer to as DataPower (IBM Websphere). Their DataPower is also generating WS-Security headers in SOAP requests acceptable by their server. No one, including the customer, has any idea how this security header is generated. They are telling us to just send what SoapUI sends. I am stuck trying to generate the same signature on the HPNS openssl that I see in my windows SoapUI tool.
So far as I understand it these are the steps I need to perform:
1) Canonicalize (Exclusive XML Canonicalization) the portion of the request that will be digested, in our case everything in and including the <soapenv:Body>...</soapenv:Body>.
2) Generate a digest value from the canonicalized version from step 1. Include this in the <DigestValue> within the <SignedInfo>...<Reference> element.
3) Canonicalize the <SignedInfo>...</SignedInfo> portion of the <Signature> element.
4) Digest the Canonicalized version of the <SignedInfo>
5) Sign the digest value of the <SignedInfo> and that is our <SignatureValue>
I'm trying to duplicate this on the HPNS OpenSSL, first using the command line tool and then eventually we'll use the API if we can figure out how to do this.
What I have figure out so far (not much):
From steps 1&2, I have managed to canonicalize, using a Java program, the <Body> from the request. I was not able to do it without first removing comments and leading white spaces from the request within SoapUI. Repeating...the ONLY way I could get a digest value match in openssl is to have SoapUI generate it's security header with no leading whitespace or comments in the request. The Java program then provided some direction one how namespace and other properties are re-arranged.
First question: how do I canonicalize the request directly in OpenSSL? I cannot find this anywhere other than references to a libxml2 library on a *nix system
After I got a matching digest I have been fruitless trying to get a signature match using variations of openssl commands: dgst, rsautl and pkeyutl. I have tried using the same canonicalizatoin of the <SignedInfo> block and digesting that then signing...no match.
Not sure if this will help but this is the WS-Security header generated by SoapUI that we are trying to duplicate (with lengthy signature removed and customer info removed):
<wsse:Security xmlns:wsse="redacted" xmlns:wsu="redacted">
<ds:Signature Id="SIG-7175F72748C072A4761529013840614108" 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 v1 v11 v2" 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-CE0A4571D7DB69D8CE152339585717529">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="v1 v11 v2" 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>redacted</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>removed for brevity</ds:SignatureValue>
<ds:KeyInfo Id="redacted">
<wsse:SecurityTokenReference wsu:Id="redacted">
<ds:X509Data>
<ds:X509IssuerSerial>
<ds:X509IssuerName>CN=Symantec Class...</ds:X509IssuerName>
<ds:X509SerialNumber>redacted</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
So far as I understand it these are the steps I need to perform:
1) Canonicalize (Exclusive XML Canonicalization) the portion of the request that will be digested, in our case everything in and including the <soapenv:Body>...</soapenv:Body>.
2) Generate a digest value from the canonicalized version from step 1. Include this in the <DigestValue> within the <SignedInfo>...<Reference> element.
3) Canonicalize the <SignedInfo>...</SignedInfo> portion of the <Signature> element.
4) Digest the Canonicalized version of the <SignedInfo>
5) Sign the digest value of the <SignedInfo> and that is our <SignatureValue>
I'm trying to duplicate this on the HPNS OpenSSL, first using the command line tool and then eventually we'll use the API if we can figure out how to do this.
What I have figure out so far (not much):
From steps 1&2, I have managed to canonicalize, using a Java program, the <Body> from the request. I was not able to do it without first removing comments and leading white spaces from the request within SoapUI. Repeating...the ONLY way I could get a digest value match in openssl is to have SoapUI generate it's security header with no leading whitespace or comments in the request. The Java program then provided some direction one how namespace and other properties are re-arranged.
First question: how do I canonicalize the request directly in OpenSSL? I cannot find this anywhere other than references to a libxml2 library on a *nix system
After I got a matching digest I have been fruitless trying to get a signature match using variations of openssl commands: dgst, rsautl and pkeyutl. I have tried using the same canonicalizatoin of the <SignedInfo> block and digesting that then signing...no match.
Not sure if this will help but this is the WS-Security header generated by SoapUI that we are trying to duplicate (with lengthy signature removed and customer info removed):
<wsse:Security xmlns:wsse="redacted" xmlns:wsu="redacted">
<ds:Signature Id="SIG-7175F72748C072A4761529013840614108" 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 v1 v11 v2" 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-CE0A4571D7DB69D8CE152339585717529">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="v1 v11 v2" 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>redacted</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>removed for brevity</ds:SignatureValue>
<ds:KeyInfo Id="redacted">
<wsse:SecurityTokenReference wsu:Id="redacted">
<ds:X509Data>
<ds:X509IssuerSerial>
<ds:X509IssuerName>CN=Symantec Class...</ds:X509IssuerName>
<ds:X509SerialNumber>redacted</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
Bill Honaker
Jun 28, 2018, 12:44:32 PM6/28/18
to
So, knowing what you expect your final application will be built with would help with what recommendations are given.
Your client's Websphere is a J2EE app container, interoperability with that may be easier with a Java app.
My understanding of the digests is that whatever is in the <body /> element of the SOAP request, with or without comments or whitespace, the compted digest must match on the recipient.
An exact lexical match of the digest isn't what they're looking for.
SterlingSL
Jun 28, 2018, 3:10:26 PM6/28/18
to
On Thursday, June 28, 2018 at 11:44:32 AM UTC-5, Bill Honaker wrote:
> You mentioned using Java, you should first note that OpenSSL is NOT used in Java apps. In addition, a lot of SOAP middleware libraries are available.
> So, knowing what you expect your final application will be built with would help with what recommendations are given.
> Your client's Websphere is a J2EE app container, interoperability with that may be easier with a Java app.
> My understanding of the digests is that whatever is in the <body /> element of the SOAP request, with or without comments or whitespace, the compted digest must match on the recipient.
> An exact lexical match of the digest isn't what they're looking for.
Thanks for the input Bill. I probably wasn't clear so I'll answer some of your input.
> You mentioned using Java, you should first note that OpenSSL is NOT used in Java apps. In addition, a lot of SOAP middleware libraries are available.
> So, knowing what you expect your final application will be built with would help with what recommendations are given.
> Your client's Websphere is a J2EE app container, interoperability with that may be easier with a Java app.
> My understanding of the digests is that whatever is in the <body /> element of the SOAP request, with or without comments or whitespace, the compted digest must match on the recipient.
> An exact lexical match of the digest isn't what they're looking for.
My sole purpose for the Java program was born out of trying to figure out how the soap request is canonicalized (henceforth: C14N). Reading the W3C spec for exclusive C14N is a nightmare. I actually wrote two Java programs, the first using the XOM (XML Object Model) library and that did not produce a C14N version of the soap request that would generate a matching digest on the NSK openssl. My second attempt using the native java crypto library did finally produce a C14N version of the request that generated a matching digest value, albeit with some modification to the original request prior to the C14N transform.
You mentioned SOAP middleware - we currently have NS-Soap on the machine but it has not been used yet (future plans). Our current application is a C program that is building the XML request pretty much by hand - for now. To digest and sign the request we are calling the openssl api. So far, we do not know of an openssl api call that will do the exclusive C14N transform.
I only mentioned their Data Power as they keep reiterating that other customers are successfully using their platform successfully and so we should be able to as well. We are the only Nonstop origin terminating on their servers. As well they keep hammering that a SoapUI client can generate a valid request that is acceptable on their server. So we're stuck with no help trying to figure this out.
The body or whatever you indicate through the reference elements is what gets digested, in our case the body only. That digest value is placed within the <SignedInfo> and that block is transformed C14N and digested and that final digest value is what gets signed. That's how I believe it works and what I'm aiming at.
Bill Honaker
Jun 29, 2018, 12:34:23 PM6/29/18
to
I haven't kept up with where the NonStop SOAP product stands with regard to WS-SECURITY, but if it supports it might be more worth your time to work there instead.
Alternatively, a Java client using Axis2 might be quicker than trying to use C/C++. You could implement a server that takes in a 'DDL structured' using DDL2Java and have it call an API that is generated from the site's WSDL.
Best of luck,
Bill
0 new messages