Following on from my last blog post I want to go deeper into some of the flexibility Intel® SOA Expressway gives you when authenticating requests with some WS Security or other digital certificate sent with the message. It's all good and convenient when you know that you need to extract the cert subject and pass that to LDAP for authentication but what about the cases where you need to examine a token within the workflow which would both be simpler to do than call out to a policy decision point like LDAP or Oracle* Access Manager and much, much quicker?
Method 1:
Choose a custom GetSOAPHeader workflow action that extracts out the Security node with the wsse namespace for WS Security. this is followed by an extension function in an f(x) action:
soae-xf:get-certificate-field$GetSOAPHeader//*[local-name() = 'BinarySecurityToken'], 'subject-name')
which (for our built in demo certificate) then gives:
CN=SarvegaDemoCert,OU=Support,O=Sarvega, L=Oakbrook Terrace,ST=Illinois,C=US
What else can you pop out of the certs then? Well the whole set of stored data which includes:
As usual with Intel® Services Designer there's a couple of ways to do things depending on your preferences so here comes...
Method 2:
Use the AAA workflow action to extract the certificate subject name. It’s a three step process:
soae-xf:get-certificate-field($GetSecurityMetadata, 'subject-name')
Pros and Cons of each method:
The AAA plus policy and extra BPEL action step will be slower as there is an extra workflow action step and the AAA policy to read in but it more accurately extracts the X509 certificate from the binary security token node of the WS Security header. The first method may be faster but you need to be aware that you cannot just pass the whole SOAP header to the get-certificate-field and expect it to find the certificate. Instead you need to narrow down what gets passed to it and weed out any other SOAP headers like WS Addressing and WS Security Timestamps by using XPath.
*Other names and brands may be claimed as the property of others.
Method 1:Choose a custom GetSOAPHeader workflow action that extracts out the Security node with the wsse namespace for WS Security. this is followed by an extension function in an f(x) action:
soae-xf:get-certificate-field$GetSOAPHeader//*[local-name() = 'BinarySecurityToken'], 'subject-name')
which (for our built in demo certificate) then gives:
CN=SarvegaDemoCert,OU=Support,O=Sarvega, L=Oakbrook Terrace,ST=Illinois,C=US
What else can you pop out of the certs then? Well the whole set of stored data which includes:
- subject-name
- ski
- generated-ski
- generated-short-ski
- sha1-fingerprint
- md5-fingerprint
- issuer
- serial-number
As usual with Intel® Services Designer there's a couple of ways to do things depending on your preferences so here comes...
Method 2:
Use the AAA workflow action to extract the certificate subject name. It’s a three step process:
- AAA workflow action and policy to get the full cert from the WS Sec header.
- GetSecurityMetadata workflow action retrieves the text of the Certificate.
- And the extension function is changed to look like:
soae-xf:get-certificate-field($GetSecurityMetadata, 'subject-name')
Pros and Cons of each method:
The AAA plus policy and extra BPEL action step will be slower as there is an extra workflow action step and the AAA policy to read in but it more accurately extracts the X509 certificate from the binary security token node of the WS Security header. The first method may be faster but you need to be aware that you cannot just pass the whole SOAP header to the get-certificate-field and expect it to find the certificate. Instead you need to narrow down what gets passed to it and weed out any other SOAP headers like WS Addressing and WS Security Timestamps by using XPath.
*Other names and brands may be claimed as the property of others.