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.


WESB listening on multiple IDoc basic types from SAP

IBM redbook named “Connect WebSphereService-Oriented Middleware to SAP” covers steps necessary for receiving IDocs from SAP using WebSphere adapter. But what if your ESB solution requires receiving and processing several IDocs basic types, such as Orders02 and Invoice01? Do you simply create another adapter module? That’s correct, but you will also need to make the following changes.

1) Each mediation modules should listen on a single IDoc basic type. Configure each module to use separate RFC Program ID. If you neglect this, SAP will have no way of determining which module to send each IDoc to and IDocs will be routed to random modules. This is certainly not the behavior you desired

2) Configure destinations in SAP for these RFC Program IDs. Please note that additional configuration is required on SAP side. Use the redbook as your guide

3) Each of the mediation modules you created in step 1 will use SAP adapter in inbound mode. Adapter should be deployed with the module.

Practitioner’s note: I had trouble getting this configuration to work correctly when SAP adapter is also installed at node level (“deployed on the server”) in WESB 6.1.2. SystemOut log entries showed that each IDoc was processed by correct adapter instance (deployed with module), but adapter behaved as if it were server-wide instance. It was unable to find method binding to process inbound IDocs in many cases. It is probably a bug, but you don’t have to wait for a fix. Simple workaround is not to mix up server- and module-packaged SAP adapter instances. In other words, when you need to listen on multiple IDoc basic types from SAP, DO NOT deploy adapter on the server level.