Not too long ago I wrote a developerworks article on Using Tivoli Access Manager for eBusiness WebSEAL without a user registry. In the article I provided a working Java Servlet which acts as a WebSEAL Enhanced Authentication Interface (EAI) application. The servlet leverages Tivoli Federated Identity Manager (TFIM) to build a Tivoli Access Manager (TAM) Privilege Attribute Certificate (PAC) without requiring the TAM user registry configuration to point to your actual user registry.

Ok – enough with the acronyms. One of my recent follow-up activities was to replicate this EAI application with an XSL accelerator configuration on a Datapower SOA appliance. In this post I’ll show you how it works. The information here is primarily targeted at folks with previous Datapower experience. TAM experience is essential, and won’t be covered. The only real TAM-ish difference between the solution with Datapower and the Servlet solution is that the junction from WebSEAL is created to a datapower endpoint instead of to a WebSphere application service instance.

Overview

First, a quick recap of the solution architecture:

The solution component discussed in the post is the EAI Application (this time on datapower). The work I’ve done was developed and tested on an XI50, however should be equally application to the XS40. The EAI is an XSL Proxy Service, with a custom processing policy.

Datapower Configuration

Create a new XSL Proxy Service object using the web administration panel, as shown in the following screenshot:

Name the proxy, then set the Proxy Type to Loopback Proxy. A loopback proxy indicates the response is generated by datapower itself, which will be done by the stylesheet configured in the custom processing policy. Take note of the Device Port – this will be the port that the WebSEAL junction should point to. The relevant configuration settings are shown in this screenshot:

Now configure a new Proxy Policy, by clicking on the + next to the Proxy Policy drop-down list. A new dialog box will open to configure the policy. Name the policy, then click on New Rule. A match rule (diamond with the = inside) will be added to the policy configuration wizard, and to that you should add an Advanced policy object by dragging it to the policy editing line just to the right of the match rule. Do the same for a Transform object, so that you have a policy rule with three objects, as shown here:

Double-click on the match rule to edit it, and add a URL matching rule. This determines which URL’s match your request. For testing purposes I just set mine to ‘*’, which matches everything:

After successfully configuring the match rule, you should see the surrounding yellow highlighting vanish from the object in the policy editor. Next, double-click on the advanced object in the processing policy. Be sure to select the Convert Queiry Params to XML radio button:

Press Next, then Done to select the default settings for the object. Finally, double-click on the Transform object in the policy editor, and upload this stylesheet. After uploading the stylesheet, use the advanced tab to configure TFIM parameters for the:

• URL to the trust server (our example uses http://mytfimserver:9080/TrustServer/SecurityTokenService)
• Applies-To address for the WS-Trust request to the TFIM STS (must match the TFIM STS chain configuration)
• Issuer address for the WS-Trust request to the TFIM STS (must match the TFIM STS chain configuration)

Note that in the example stylesheet, the request to the TFIM STS contains a UsernameToken, with a username and password rather than an STSUniversalUser. There is a commented out example with an STSUniversalUser as well. The stylesheet (and the TFIM STS configuration) will need customization based on your own real authentication requirements, however all the building blocks are in place, and no Java code needs to be written with this approach.

After you have configured the transform object, the processing policy configuration is complete, so press Apply Policy, then Close Window to return to the main XSL Proxy configuration panel. Press Apply, and your XSL proxy is ready to use.

WebSEAL Configuration

WebSEAL configuration is required to junction to the datapower endpoint (remember the Device Port), and set an EAI trigger URL to match the URL you will use to datapower.

Details of the Processing Policy Stylesheet

The main take-home from this article is the example stylesheet. You will almost certainly need to customize it, however it is quite readable and easy enough to understand with just a modest knowledge of XSL. It has the ability to both display the login form, and process the parameters when submitted from that form. You can modify the number and names of these parameters however you need to, just look at how the username and password are used in the existing example.

The advanced object in the processing policy (which is executed before the stylesheet) is also an interesting component of the solution. Using the excellent “Probe” debugging tool of datapower, you can see the before and after formats of the request of a POST’d form. Understanding this process is quite important to understanding how the FORM post parameters are referenced in the example stylesheet. Here’s a couple of screenshots from the probe that show the details:

FORM Parameters BEFORE conversion to XML	FORM Parameters AFTER conversion to XML

Final Thoughts

This technique describes how to use a Datapower SOA appliance as a simple web application, which in this instance performs a WS-Trust token exchange with the TFIM STS, and sets HTTP response headers which are consumed by WebSEAL as authentication data. Many variants are possible, and the Datapower SOA appliance provides a rich set of XSL extenstion functions which can be utilized for those purposes. I am certainly no expert on Datapower capabilties, but found the platform very easy to work with. The Probe utility in particular is excellent and really aided with debugging exercises.

If you have any questions on using this technique, of course feel free to contact me.