Authenticating signing certificates from XML Digital Signatures with Intel® SOA Expressway

Okay, this is my first post and I want to jump straight in with a neat little method of authentication which is often used when Intel® SOA Expressway is deployed as a Service Gateway. It also gives you the ability to be agnostic to whether you’re dealing with SOAP or REST XML patterns in your messaging.

Generally in these blogs I’m going to assume a little bit of familiarity with Intel® SOA Expressway and Intel® Services Designer but if you’re curious to know more or a noob then drop me a comment and I’ll fill you in on the extra detail.

In this situation we are dealing with a non WS Security XML Digital Signature such as a detached or enveloped type. WS Security signatures have authentication built in to the verification policy and are dealt with already in the quickstarts which come with Intel® SOA Expressway. Check out the Dynamic Perimeter micro site to get more info on these capabilities and to get a copy of SOA Expressway yourself.

When you use one of our inbuilt extension functions like soae-xf:verify-x509-enveloped-signature it checks the digests are correct etc. but does not go on to see whether SOA Expressway trusts the certificate of the message signature. To do this we must add a BPEL action to check the chain of trust which has been setup in the security config.

- To do this, first drop an AAA (Authentication, Authorization & Access) action into your workflow. The tokens I'm using here refer to the inbuilt default security config provided with SOA Expressway. Substitute these for your own tokens where necessary when you deploy on the runtime.. The AAA action will need a message to be passed to it. The inbound request will do.

- Create a policy for this AAA action with the following parameters set:


    • Extract Identity

    • Identity source: X.509 Certificate from workflow

    • Certificate attribute: Full certificate

    • Authenticate Identity

    • Authenticate using: X.509 Certificate Chain of Trust

    • Authentication policy, token name: demo-message-level-authentication-policy

    • CA Path: selected

    • Security configuration, token name: demo_ca_path



- Update the policy back in the AAA action properties pane. You will now need to pass a parameter specifying the Source Identity of the X.509 Certificate. This can be extracted from the message using XPath similar to this:

$Request.body//ds:KeyInfo/ds:X509Data/ds:X509Certificate

The above works for our inbuilt security but to change over to your Certification Authority you will need to have added your CA certificate into the Security Config in the SOA Expressway runtime web interface.

If there's a failure of the authentication the following fault will be generated:

<soae-fault:checkPkiCertificateChainOfTrustFault xmlns:soae-fault="http://www.intel.com/soae/bpelFault-2009a/">
<faultString>Error in checking certificate chain of trust</faultString>
<details>
<policyName>Policies/EnvSigVerify</policyName>
</details>
</soae-fault:checkPkiCertificateChainOfTrustFault>

So why is this a neat trick I hear you ask? SOA Expressway isn’t enforcing you to deal with the authentication in either a SOAP or a REST way which some XML Appliances and Java Frameworks might. Just change the XPath and you can be extracting a detached digital signature from the SOAP Header.  In fact I’ve taken this method from a mixed SOAP/REST workflow I developed for a financial transaction web service at a bank which used SOA Expressway as a security gateway and also for runtime governance.  More on that workflow later….

Para obter informações mais completas sobre otimizações do compilador, consulte nosso aviso de otimização.