Wishing for DataPower

What is the best way to appreciate the value of DataPower network appliances? Working on a SOA integration project where one is not available.
I’ve had an integration project recently: service-enablement of mainframe using WebSphere ESB. Services to be exposed using SOAP/HTTP(S) and WebSphere MQ. Other software we used: WSRR for governance and ITCAM for monitoring. What we did not use: DataPower. Our requirements included securing services in a situation where access must be provided to a diverse base of service consumers, both internal and external.
How DataPower appliance would’ve been handy! It is extremely fast XML appliance especially well prepared to deal with diverse security requirements.


Security for WESB services: WSRR as a good-governance alternative to LDAP groups

Quite frequently, access to Enterprise Services is secured based on individual user, but on requesting application (department, organization, org unit, etc). If one or another application in your company consumes an Enterprise Service, you may not be particularly interested in the identity of individual user behind a screen who clicked a button on an internal Web page, resulting in Web application making a call to mainframe behind the scenes. Knowing that the call came from a known internal application may be enough. In fact, often times there will be no individual user at all: the service call may be coming from a batch or unattended process.

If your Enterprise Service is hosted on WebSphere Enterprise Service Bus (WESB), how do you configure security (authentication/authorization) for this scenario? One obvious option is to leverage standard security mechanisms of WESB, which are effectively J2EE based. Create an ID for each requester application in your enterprise LDAP and use standard role-based access control to authorize access. Normally, you will create an LDAP group for each services access role and assign application IDs to those LDAP groups. This approach is simple and familiar to enterprises. But I can see one shortcoming: governance is often difficult to establish.

Defining access policies for enterprise services is responsibility of Enterprise Architects. But it is difficult to do this using LDAP. In a typical enterprise, processes for governing LDAP security changes are geared toward end user access. Roles, personnel involved, tools, ticket approval systems – everything is set up to deal with end user accounts. Enterprise architects are not involved in this process and would not be comfortable with security tools, because individual account maintenance is not their responsibility. Looking at the problem from the other side, security administrators may not even want to give Enterprise Architects access to account data that is required to effectively govern service account roles.

One possible solution to the governance dilemma is to use a true service governance tool, such as WebSphere Service Registry and Repository (WSRR). WSRR comes with a prebuilt governance templates in “Governance Enablement Profile”, including definition of SLA. If you establish an SLA between each service consumer application (department, etc) and consumed service. Then, in WESB (or WPS), you can insert “SLA Check” mediation primitive before actual invocation of a service. SLA Check primitive is new to WID/WESB/WPS version 7.0. It is very simple: it consults configured WSRR instance to determine whether there an SLA for particular service exists (for a particular user and in a particular context) and returns a simple yes or no. Now your service access is under control of WSRR, which Enterprise Architects understand and (hopefully) use daily. Service access is governed by the same tool as all other aspects of the service.

Problem solved? Unfortunately, WSRR solution has several shortcomings of its own:

  • LDAP-driven security is declarative, but WSRR-driven requires SLA Check primitive to be inserted (is programmatic)
  • Out of the box SLA lifecycle is quite evolved and requires several document types to complete. It is likely too complex for a simple task of service authorization
  • Establishing an SLA for every consumer-service pair is a lot of work.

All in all, I would recommend using SLA Check for service authorization if you highly value service governance, are unsatisfied with LDAP governance tools and process and prepared for the task of creating a massive number of SLAs. Otherwise, LDAP role-based security is still a more reasonable choice.

Identify service requestor application for MQ and Web services

Suppose you are establishing SOA in an organization that is quite new to the concept. They have a developed MQ infrastructure and are quickly building up enterprise Web Services catalog. A lot of existing functionality and legacy applications will be exposed as Web Services and MQ. You must continue to support MQ services because there is still a large number of MQ clients there that can not be reasonably changed. But enterprise architects want to gain better control of the enterprise services, including both Web Services and MQ. They want to establish service governance. All service consumers will be required to subscribe to the services they need and establish an SLA. To enforce this policy, Enterprise Service Bus in the middle of SOA landscape will need to authenticate requester and verify SLA. Authentication needs to be done on application level, not individual user level, because SLA is established for departments/LOBs and not for users.

What is the easiest way to find out which application sent an MQ request message? Consider this constraint: source applications can not be modified to insert their identity into the message. First, I will assume that I can differentiate applications by Queue Manager: each QM from which request messages may be sent will represent only one application. This is already the case, but even it was not, we could create additional QMs as required and reconfigure some applications to use new QMs. With this assumption, my problem has been reduced to identifying Queue Manager that sent each message. After that I can use a table to map QM name to application name. This can be done in several ways. It can be done quite elegantly by WebSphere Message Broker. It can be done by MQ means alone, in a way that is both cute and ugly at the same time:

  • create a user account for each source QM
  • on a “central” QM, create a queue for each source Queue Manager
  • limit PUT on each of these queues to a single user corresponding to its QM
  • configure MCAUSER on channels

With some trimming around the edges, I can guarantee that messages on each of these queues have arrived from a single QM.

This is quite a bit of work. I can achieve a rough first cut of a solution much easier. I will add an assumption that only request-response pattern is used (no datagrams, all request messages require a response). Now I can identify service requester by finding where the reply message goes. That’s right: ReplyToQMgr property of MQMD structure carries the name of Queue Manager that expects a response. Under normal circumstances, by looking at this property we can identify which QM sent the message because it is the same QM that the response will be sent to. All that’s left is control for spoofed messages, which is an open item as of now.

WSRR: WS-I validator and loading WSDL files

To WebSphere Service Registry and Repository (WSRR) practitioners, I’d like to recommend this excellent developerWorks article explaining how to leverage WS-I compliance validator that is part of that software. Among the things you will learn: how to make this validator enforce arbitrary restrictions expressed in Schematron.

Just one thing to keep in mind: this article was written for WSRR 6.2 and you will not be able to reproduce the scenario in this article with default settings of WSRR 6.3 (original or with Fixpack 1). This is because MAKE_GOVERNABLE event will not fire for WSDL documents containing endpoint definitions in default setup. I recommend that you replace MAKE_GOVERNABLE with CREATE event in sample code – then it will work.

Here’s how the story unfolds. When you load a service document (a WSDL document or a SCA module) into WSRR, a complex sequence of actions is taken by the software behind the scene. WSDL document is validated. The document is parsed and concepts relevant to WSRR are identified. Those include service, port, binding, operation, message and endpoint definitions, XML schema elements and types. All these objects are linked together. As these objects are created, configurable modifier kicks in to enable governance and initiate appropriate lifecycle. Once one item in a collection of linked objects has governance enabled, all other linked items are pointed to the same governance record. From that point on, they are governed together: it is not possible to enable governance separately for any other item in the linked collection.

Configurable modifier named “Triggers” contains the following fragment:

<!-- Mapping to push the relevant items through the Service Endpoint Lifecycle -->
<model-type model-uri="http://www.ibm.com/xmlns/prod/serviceregistry/v6r3/ServiceModel#ServiceEndpoint"/>
<model-type model-uri="http://www.ibm.com/xmlns/prod/serviceregistry/v6r3/ServiceModel#MQServiceEndpoint"/>
<model-type model-uri="http://www.ibm.com/xmlns/prod/serviceregistry/v6r3/ServiceModel#SOAPServiceEndpoint"/>
<model-type model-uri="http://www.ibm.com/xmlns/prod/serviceregistry/v6r3/ServiceModel#ExtensionServiceEndpoint"/>
<configuration name="InitiateEndpointLifecycle"/>

And configurable modifier named “InitiateEndpointLifecycle” includes this:

<?xml version="1.0" encoding="UTF-8"?>

<action-configuration xmlns="http://www.ibm.com/xmlns/prod/serviceregistry/Actions"
xsi:schemaLocation="http://www.ibm.com/xmlns/prod/serviceregistry/Actions Actions.xsd">

<!-- Transition the selected object into the SLA Lifecycle -->
<make-governable-action uri="http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/LifecycleDefinition#InitiateEndpointLifecycle"/>


These 2 modifiers are both enabled in Governance Enablement profile. Putting all this together, if a SOAP Service Endpoint is found in WSDL document, a SOAPServiceEndpoint object will be created and endpoint lifecycle will be initiated. WSDL document itself will be linked to the governance record of the SOAP Endpoint. It will not be possible to enable governance on the WSDL document separately.

Indeed, when a sample WSDL is loaded, we see exactly this effect. When I click on newly loaded WSDL document and proceed to the Governance tab, I see the following:

Governance Tab of WSDL document

Governance Tab of WSDL document

If I click on the “Root governance record” link, it takes me to the SOAP Service Endpoint:

SOAP Endpoint governance tab

SOAP Endpoint governance tab