WS-Security related queries in API Gateway

[VA82375905]

Following the solution provided by Stephen_Hughes in the post Consuming SOAP web service in CA API Gateway , I was able to add WS-Security Headers to a incoming Soap request. I am now having some difficulties creating the WS-Security headers similar to those generated by the legacy application.

 

We are trying the remove the generation of WS-Addressing and WS-Security from client application (written in Java using CXF 2.7.7) and move to handling to gateway. Application is now expected to send only simple payload and gateway service would add the required WS-* Headers. Sample message which our application currently generates is attached (forCA_soapRequestFromApplication.xml).

 

I have created a Soap service and added the two assertions, “Configure WS-Security Decoration Assertion” and “Apply WS-Security Assertion”. Security header is added, however is quite different from the one generated by the CXF Framework. I have tried changing the few settings on the above two assertion, still unable to resolve the mismatches in the following Security sections:

 

1) <BinarySecurityToken>: Token generated by the Application and Gateway are different, as we are only signing the request with the Private key, using same private key is generating the value in the Gateway. I am not sure where in assertion I need to select the Private key. a) “Configure WS-Security Decoration Assertion”-> Right Click, “Select Private Key”  or b) “Apply WS-Security Assertion” à Use selected certificate for default recipient”, or both places?

 

2) <KeyInfo>: Application is sending <BinarySecurityToken> and <KeyInfo> which contains the SHA1 thumbprint of the certificate (as below).

 

<wsse: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="X509-8BB84B0E7E429B22FA154587081374711">
  MIIDXTCCAkWgAwIBAgIEPUHL8Su0bTVDa+<Truncated to fit the page>+SJGtOw==
</wsse:BinarySecurityToken>

 

<ds:KeyInfo Id="KI-8BB84B0E7E429B22FA15458708137479">
  <wsse:SecurityTokenReference wsu:Id="STR-8BB84B0E7E429B22FA154587081374710">
    <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/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">
      p0VXEq8R+d5S41U1szlgaMVRCi4=
    </wsse:KeyIdentifier>
  </wsse:SecurityTokenReference>
</ds:KeyInfo>

 

Now in Gateway, if I select “Configure WS-Security Decoration Assertion à Signing à Key Reference à BinarySecurityToken”, then the <KeyInfo> is populated with the reference URI as below (not our requirement, attached file forCA_soapRequestFromGateway_withKeyRefAsBST.xml ).

 

<ds:KeyInfo>
  <wsse:SecurityTokenReference
    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <wsse:Reference URI="#id-0-0cf64fb8031c33bc853d63857a6a162c"
                    ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
  </wsse:SecurityTokenReference>
</ds:KeyInfo>

 

I tried selecting “Configure WS-Security Decoration Assertion --> Signing --> Key Reference --> ThumbprintSHA1”, it generate the KeyInfo in the correct format but now <BinarySecurityToken> is missing in the WS-Security Headers (refer attached file  forCA_soapRequestFromGateway_withKeyRefAsSHA1.xml).

 

<ds:KeyInfo>
  <wsse:SecurityTokenReference 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:Id="id-5-b38fe061d4b22f7ebb3bac533c7193dc">
    <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/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">
      p0VXEq8R+d5S41U1szlgaMVRCi4=
    </wsse:KeyIdentifier>
  </wsse:SecurityTokenReference>
</ds:KeyInfo> No <BinarySecurityToken>

 

3) Can we sign the specific WS-Addressing Headers, not all? Selecting the “Configure WS-Security Decoration Assertion -->Signing --> Sign WS-Addressing Headers” checkbox signs all WS-Addressing Headers but our requirement is to sign only <To> header not <ReplyTo> or <MessageID> etc.

 

<To xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
    xmlns="http://www.w3.org/2005/08/addressing"
    wsu:Id="Id-1889306702">https://XXXX-DEV1-MAR-VMD/***.tpa/account.svc
</To>
<ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
  <Address>http://www.w3.org/2005/08/addressing/anonymous</Address>
</ReplyTo>

 

4) Is “Configure WS-Security Decoration Assertion” is the super set of other related assertions such as “Add Signed Timestamp”, Add Signed Security Token Assertion” etc? Or they need to be used together.

 

Would really appreciate any guidance.

Thanks

Attachment(s)

forCA_soapRequestFromApplication.xml.zip   1 KB 1 version

forCA_soapRequestFromGateway_withKeyRefAsBST.xml.zip   2 KB 1 version

forCA_soapRequestFromGateway_withKeyRefAsSHA1.xml.zip   1 KB 1 version

[Stephen Hughes]

Good morning,

 

I've reviewed your post and the requirements. I have been able to make some headway and have some additional questions to complete the policy. I've attached a sample one to get you started. I have comment out a few assertions if you want to see how it can be done using XSLT. If you try that route just disable the add WS-Addressing assertion.

 

1) For all the signing of the payload, you can either use the default SSL key or right click on the Add Sign Timestamp, Configure WS-Security Decoration, and Sign Element and select the private key. This will ensure you are using the same private key throughout the process. The Apply WS-Security setting is for encryption only not signing.

 

2) From the example that you provided the BinarySecurityToken does not seem to be referenced in the Signature Keyinfo so I don't believe that it is used. Please confirm and if not then you can change Configure WS-Security Decoration to use ThumbprintSHA1 for the key reference and Sign Request Element to use SubjectKeyIdentifier.

RFC https://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-SOAPMessageSecurity.htm#_Toc118717135
7.3 Key Identifiers
Alternatively, if a direct reference is not used, then it is RECOMMENDED that a key identifier be used to specify/reference a security token instead of a <ds:KeyName>. A <wsse:KeyIdentifier> is a value that can be used to uniquely identify a security token (e.g. a hash of the important elements of the security token). The exact value type and generation algorithm varies by security token type (and sometimes by the data within the token), Consequently, the values and algorithms are described in the token-specific profiles rather than this specification.

 

Note: Gateway uses a direct reference to the BST in the payload SOAP header

 

3) By default we will sign all WS-Addressing. To disable this they uncheck the “Configure WS-Security Decoration Assertion -->Signing --> Sign WS-Addressing Headers” checkbox and add in a Sign Element to sign just the TO element.

 

4) The “Configure WS-Security Decoration Assertion” provide a way to override behaviors in some of the WS-Security assertions. In some cases where you select Timestamp to Automatic and Timestamp Signature to Automatic the Decocation assertion will add in a signed timestamp to the payload. You will lose the capability to select the duration but can select Key reference through the Decoration assertion.

 

Sincerely,

 

Stephen Hughes

Broadcom Support

Attachment(s)

ws-addressing_bst_policy.xml.zip   2 KB 1 version

[VA82375905]

Thanks Stephen,

 

I did the quick initial test and it is working using the sample policy and by just changing the key reference to SHA1.

 

Thanks,

Varun 

[Stephen Hughes]

Varun,

 

Good morning. If the solution addressed your need please mark the question as answered.

 

Sincerely,

 

Stephen Hughes

Broadcom Support

[VA82375905]

Thanks Stephen, marked the answer to correct. Just need a quick info on how I can extract the "action" from the input message? Unlike any other http headers, action is coming as below and I am not able to capture it in context variable. I have tried using ${request.http.allheadervalues.action}, ${request.http.header.action} and ${request.http.action} but that doesnot work. Also application is not sending action as a part of soap request, so cant use ${request.soap.action}

 

[Stephen Hughes]

Varun,

 

Normally you will see the action as the header SOAPAction but in the example you provided it is in the content-type header. You will need to parse out the value using a regular expression against the context variable ${request.contentType}.

 

Sincerely,

 

Stephen Hughes

Broadcom Support

[VA82375905]

Thanks Stephen, extracted it via regex. Looks like SOAP 1.2 allows action is sent as a part of Content-Type header. So CXF is sending it as expected. 

Anyways, using regex I am able to extract action so all good. Thanks for all your support. 

[Stephen Hughes]

Varun,

 

If you specify SOAP 1.2 on the WSDL tab of the service properties, this may populate the right built-in standard SOAP Action variables. I haven’t tested so can say for certain.

 

Sincerely,

 

Stephen Hughes

Broadcom Support