WS Security for Apigee - Configurable Reference: SignatureConfirmation

[writetorajeshku]

Hi @dchiesa1 ,

@dchiesa1 

I am currently working on a service that requires sending the WS Security signature, so I used your contribution Java Callout for WS-Security Digital Signature[Apigee-Java-WsSec-Signature-2].
I could see that the structure is formed but there is no option to include SignatureConfirmation and interface is very stubborn to include it in response signature. 

how can I do to configure them.?

Thank you very much for your help.

[dchiesa1 · Accepted solution]

Hi Rajesh

What specifically are you attempting to do?  The WS-Security signature callout you are pointing to, is somewhat limited in that it is able to sign:

• the soap:Body
• the wssec:Security/wsu:Timestamp
• or both

But today, not "other arbitrary elements", including the SignatureConfirmation elements. 

Do you simply want  the callout to also be able to sign the SignatureConfirmation elements? That would not be a difficult enhancement for me to make.  But that would mean that you (or your API proxy) would have to insure that the appropriate SignatureConfirmation elements were present in the unsigned response, before invoking the callout. 

OR, do you want the callout to also generate the SignatureConfirmation elements, inject them into the unsigned response message, and THEN sign the various elements?  To do this, your apiproxy would need to be able to provide the original signature values to be confirmed.  (and there may be more than one). 

Please advise in more detail what you want to accomplish.

EDIT: I modified the callout to add a new configuration property "confirmations".  re-pull the latest version, and Check the README.  In short, if you add that  property, and specify a comma-separated set of values, the callout will inject SignatureConfirmation elements into your SOAP document with those values; if you specify the special value "*all*", the callout will sign all existing SignatureConfigurations that are present in the document.  Try it and see if it does what you want. 

[dchiesa1 · Accepted solution]

OK great, I'm glad you were able to try the callout.

Regarding your concerns, I think you should not be bothered by any of the differences you described. I'll explain why.

First, you are saying that you expect the element to be wsse11:SignatureConfirmation but are getting wsse1.1:SignatureConfirmation. The thing before the colon in an XML element name is known as the "prefix". This is just a way to qualify elements in an XML document with a "namespace". The namespace - often a long URL, but in general it is a URN (any string) - is the semantically important thing. The prefix can be anything. In other words, the following two are exactly equivalent.

<foo:ElementName xmlns:foo="http://a.b.com/something"/>

<a:ElementName xmlns:a="http://a.b.com/something"/>

Any compliant XML processor will process those elements as being equivalent. It would be an error for an XML processing application to check the string values of the prefixes. It is required that the XML processor check the string values of the namespaces that the prefixes refer to. Therefore the difference you observe between wsse11 and wsse1.1 is immaterial.

Another thing you should be aware of - prefixes that are defined in a parent node of an element, will be effective for that element. Therefore, the following two are equivalent:

<s:Envelope 
    xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <wsse1.1:SignatureConfirmation 
       xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
       xmlns:wsse1.1="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" 
       Value="abc" wsu:Id="conf-101"/>
    ... 

<s:Envelope 
    xmlns:s="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:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
    xmlns:wsse1.1="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd">
  <s:Header>
    <wsse:Security>
      <wsse1.1:SignatureConfirmation Value="abc" wsu:Id="conf-101"/>
    ... 

You can see that the prefixes wsse1.1 and wsu are defined in the toplevel element, but are used only in the SignatureConfirmation element. That is no problem. Correct XML processors will treat them as the same.

You may also wonder about the value inside the quotes for the wsu:Id attribute . They are different from your "expected" and "actual observed" outputs. Here again, that won't matter. That ID is relative to the document itself. It merely provides a way for a Signature to refer to that signed element. So it does not matter if your example is "SigConfi-100" and the callout generates "Conf-103". That won't make a difference to the signature validator.

In summary, the observed output is exactly equivalent to what you describe as your "expected" output.

One more thing I will mention .... regarding "default" namespaces. This isn't important for the question you asked here, but you may come across this in the future, so I thought I'd explain it here. As I described above, you can use a prefix to "qualify" an XML element within a particular namespace. Therefore the following two are NOT equivalent, from an XML Infoset perspective:

<p1:address xmlns:p1="http://example.com/schemas">123 Main Street</p1:address>

<p1:address xmlns:p1="urn:abcdefg">123 Main Street</p1:address>

The reason is, the p1 prefix refers to two different namespaces. the address element in the namespace "http://example.com/schemas" is not the same , from an XML point of view, as the address element in the namespace "urn:abcdefg".

Beyond namespaces that are explicitly (if indirectly) referenced via a prefix, any element in an XML document has a "default" namespace. The following two ARE equivalent:

<address xmlns="http://example.com/schemas">123 Main Street</address>

<p1:address xmlns:p1="http://example.com/schemas">123 Main Street</p1:address>

In the first example, "http://example.com/schemas" is the default namespace for the element - it is the namespace the element, as well as any unqualified children of the element, gets. In the second example, the same namespace is present, but it has an explicitly declared prefix. Any correct XML processor will treat those two as exactly the same.

Maybe a more relevant example , these two are also the same:

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
  <Header>
    <Security xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <SignatureConfirmation xmlns="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" Value="abc=="/>
      ...

<soap:Envelope 
   xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
   xmlns:wsse1.1="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd">
  <soap:Header>
    <wsse:Security>
      <wsse1.1:SignatureConfirmation Value="abc=="/>
      ...

The former uses only default namespaces for each element. The latter uses explicitly defined prefixes. They are the same, from an XML infoset point of view.