One of the cool features of Intel® SOA Expressway is its ability to easily handle token bridging with just a few clicks. What is token bridging you ask? With the increased need for Enterprises to talk outside their perimeter to other Enterprises or cloud services, we need an easy way to morph message level credentials into the proper form as they move across the dynamic perimeter of the Enterprise.
In practice this means that Enterprises deal with different authentication directories and identity management systems and employ different standards and even different variants of authentication standards. If we cross-multiply authentication schemes used in the "web" and "web service" worlds, the range of token types begins to multiply like out of control rabbits: Credentials can be anything from simple HTTP Basic Authorization tokens, Kerberos tickets, custom Microsoft schemes like NTLM, OAuth access tokens, SAML tokens of various types, X.509 tokens, SSL certificates, WS-Security Username/Password tokens and then to make matters more complex, you also have domain-specific cookies from legacy identity management systems such as CA Siteminder, IBM Tivoli Access Manager, and Oracle Access Manager.
Fortunately, Intel® SOA Expressway gives you some nice tools to implement a cross-domain token broker and ease the pain of mapping a format used internally to something that might be accepted by a business partner, such as a SAML token. In this blog post, we'll return to the familiar calculator web service and show how you can use Intel® Expressway to implement a simple policy that maps a HTTP Basic Authentication token to a SAML 2.0 authentication assertion for a SOAP web service.
To follow along, you'll need a copy of SOA Expressway, which can be downloaded from http://www.dynamicperimeter.com as well as a SOAP client such as SOAP UI. You will also need a sample web service. In this case we'll use an example calculator service. You can grab the WSDL here.
The Basic Architecture
Expressway is a web services proxy, which means it’s usually placed in the line of fire between a client and the actual service. The architecture assumes a request leaves the Enterprise and calls a partner web service over the Internet.
In the basic architecture the enterprise will make a SOAP call with a username and password which Expressway will map to a SAML assertion for the destination calculator web service. More astute readers will recognize that in this model, Expressway is acting as a SAML authority because it is actually the issuer of the assertion. In the actual example we will go through, we'll omit the actual authentication of the user as that would make this post a bit long, but it can be easily done by Expressway and is usually accomplished by contacting an LDAP directory.
To begin, start up Intel® Services Designer and select File > New > Intel® SOA Expressway Project. Then, give your project a name such as 'GenerateSAML' and select 'Empty Project' for the Application type drop-down and hit finish.
To keep things simple, we'll just add a single proxy workflow. To do this, right-click on the project name and choose New > Intel® SOA Expressway Workflow. It's one of the options lower down on the context menu. After choosing the project for the workflow, you should see the new workflow creation screen. Click the thumbnail to expand.
Choose the proxy workflow and hit Finish. In the next screen you need to provide the location for the WSDL and be sure to select the specific operation to proxy. In this simple example we are only supporting the "add" operation though you can easily support them all with Expressway's service proxy wizard. If you've done everything right so far you'll get a basic proxy workflow consisting of just receive, invoke, reply.
The Security Policy
The starting point workflow is very simple. To start with it just channels the SOAP request and response through Expressway. How do we add our security policy? To add token bridging to this we need to drag the AAA step from the palette between the receive and invoke actions. Click the thumnail to expand.
Next, in the properties tab for the AAA step we can select the option to create a new policy. Give it a simple name such as Policy.aaa and hit Finish. Then, double click on the new .aaa file in the project which brings up the policy editor in the main workspace. Then, if you click on the Identity Management tab on the bottom portion of the window you will be shown the token bridging options
We’ll set a few important options here. First, we need to tell the policy to extract the identity from an HTTP Basic Authentication header. For now, we’ll skip authentication but if you want to also authenticate the user against a directory or identity management system it can be done by clicking the box to authenticate the identity. For the map options, we’ll choose a SAML assertion and fill out a value for the issuer. Click the thumnail to expand.
To have Expressway sign the assertion, simply click on the Signature option. Expressway ships with a demonstration key-pair that can be used for testing purposes. It’s part of the default security package provided with the product. Click the thumnail below to expand.
Finally, if you want to generate a version 2.0 assertion, you can set this option from the policy options tab as follows. Click the thumbnail to expand.
If you’ve done everything correctly so far you should get summary of what the policy is doing written in English language in the Properties tab for the AAA step. You can see this if you double-click the .bpel file and then make sure the AAA step is selected. Click the thumbnail to expand.
Deploying the Application
To deploy the application, we can right-click on the project in Intel® Services Designer and then upload the application to an active configuration on the appliance. Before activation make sure that the invocation agent for the service (in our case the calculator service) is set with the proper IP address and that Expressway can reach this network location. You will also have to make sure the default security package is selected so we can use the demo signing key. Click the thumbnal to expand.
For this application to work, the destination service has to be able to understand and verify the SAML 2.0 assertion that has been added to the message. In our simple case the calculator web service ignores the headers completely, so we can really send anything and we won’t have a way of knowing if Expressway actually inserted the SAML assertion. One way to check is to enable processing of the SAML assertion for the destination service. Another way, however, is a little trick that can be used to force Expressway to throw the message back directly to the client for debugging purposes.
To do this, all you have to do is change the output of the ‘Reply’ step to be the output of the ‘AAA’ step. This is done by selecting the appropriate drop-down in the Reply step. Click the thumbnail to expand:
To see this in action, we can fire-up our soap client (SOAPUI is shown here) and immediately see what Expressway has been up to. In this case we can see all of the details – the incoming message has an HTTP Basic Authentication header and the output SOAP message has a SAML 2.0 assertion. Click the thumbnail to expand.