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.


Comments are closed.

%d bloggers like this: