Special Reports

Make an ESB Secure

Discover the many security services built into the ESB technology.

• By Mark O'Neill
• 02/08/2005

The Enterprise Service Bus (ESB) is a new architectural pattern that proposes some significant advantages over older approaches to integration, such as the Enterprise Application Integration (EAI) "integration hub" approach. There is currently some debate about whether the term "Enterprise Service Bus" is here to stay or if it will become an architectural pattern that, by being adopted in a wide variety of integration products, becomes ubiquitous enough to no longer need to be called by name. Indeed, the an ESB's core concepts are now found in products from Message Oriented Middleware (MOM) vendors and those from mainframe specialists. Whether the term ESB sticks, a consensus is gathering regarding the value of these core concepts. Just what are the core concepts of an ESB?

Document-based integration. In an ESB, messages are sent between applications. These messages contain only declarative data; i.e., they are not pointers to information stored in a database elsewhere, nor are they encapsulated objects that must be reserialized by the recipient (as in CORBA). Document-based integration is how EDI has worked for years, passing formatted business documents between applications.

The difference is, however, that ESBs can leverage XML's structural advantages for message validation and transformation rather than being forced to splice EDI files manually. In document-based integration, the recipient application decides what it will do with the data. It might require only a subset of the data, or it might pass on the data to another application for subsequent processing. Document-based integration makes swapping applications a snap because the data representation is independent of the applications sending and receiving the data.

Asynchronous message routing. Because "only" data is sent between the applications being integrated, a message router can act autonomously. All the information it needs for its decisions is contained in the messages; it does not need to consult a database or create an instance of an object. Based on the message data, the message router can route the message to one application or another. An intelligent routing application can delay sending a document to a recipient application until that application is online. This is different from synchronous integration, where both applications must be online at once.

Coarse-grained interfaces. In the first wave of XML-based integration products, a developer would feed the product a Java class and it would generate discrete SOAP interfaces based on all the methods the class exposed. This could result in many SOAP interfaces for all the Get and Set methods exposed by the Java class. This was not significantly different from simply using Java RMI and it felt like technology for its own sake. Over time, architects realized a better approach is to construct coarse-grained services, which non-technical people in the organization can understand and could be swapped out more easily for different implementations without breaking the interface. These coarse-grained services hide the complexity of all the individual methods behind them.

Transport independence. It is a fact of life that enterprise architecture includes a mish-mash of different protocols for connecting applications. Although I mentioned document-based integration, you can't avoid the question of how the documents get from Application A to Application B. An ESB must support a variety of different protocols, including MQ/JMS, FTP, Java RMI, DCOM, ODBC, JDBC, and CICS. Only by supporting such a wide variety of transports can an ESB become transport-independent and allow an architect to focus on the documents used by the ESB rather than becoming bogged down by writing connectors and bridges. This is one of the chief features of an ESB product-providing all the interfaces and managing the connections between them.

Getting Down to Business
Upon first encountering an ESB, you can reasonably ask, Where is the business logic? Because if an ESB is all about routing documents between applications, how does it actually do meaningful work? The answer is that the applications connected by the ESB contain the business logic. Mainframes, application servers, and Enterprise Resource Planning (ERP) systems all contain business logic; the ESB does not replace them. Instead, the ESB adds value by allowing the existing business logic to be used more easily. This is sometimes called "return on assets" and is as important as the more commonly used term "return on investment."

The general consensus seems to be that document-based integration is a good thing. Certainly it is more attractive than the integration hub EAI architecture, which has a proprietary "spider in the web" acting as a bottleneck for enterprise data integration. It also is more attractive than a tightly coupled approach, where applications access methods of other applications directly, using CORBA or DCOM, and the whole thing crumbles if one node fails. The definition of a distributed application used to be "when an application you've never heard of causes your application to fail"; ESBs are designed to be more resilient than that.

Now that you know what an ESB is, let's look at how security is overlaid onto one.

Security Services: The Demise of the API
As well as passing data between application endpoints, which are exposed as services, an ESB provides services of its own, including security services. For example, take an audit-logging service. The enterprise architect deploying the ESB can choose to route documents through the audit-logging service before routing them to their destination. Another example of a security service is a document-signing service. The OASIS Digital Signature Services technical committee is nearing completion on standard service-based interfaces for message signing and signature validation, and these services would be ideal candidates to include in an ESB.

Before the concept of security services came about, a developer might have considered performing cryptography using an API or toolkit. This meant that each application requiring cryptography also required a toolkit. In addition, when applications used different programming languages, this meant they used different implementations of security algorithms-some using DLLs, some using C libraries, some using Java. This also had wider ramifications in terms of extra development demands, the time required to configure security policies into application code, and ensuring the ongoing maintenance of these applications. Now, with security services in an ESB, routing the message to a security service and effectively saying "sign this" or "encrypt this" is much easier.

Essentially, a crucial part of an ESB is a Security Server, which provides services for encryption, signing, message validation, audit logging, and security-token management. These security services then become part of the palette of services available to the architect deploying the ESB. You can create sophisticated message flows where a document is received, then encrypt a sensitive portion of the document for privacy reasons. The document then is passed to an application server and the response is routed to a signing service, then passed to an audit-logging service, and finally is routed to the mainframe. The overall effect is similar to a UNIX pipe command.

Monitor Messages Using an Audit Trail
Because messages used in ESBs are information-rich, they are well suited to being stored in a persistent audit trail. If all that was passed in the message were pointers to data in a database, or serialized objects, the value of an audit trail would be greatly diminished. A number of regulatory requirements (Sarbanes Oxley, Basel II, and so on) now force organizations to store all their transactions. The document-based nature of ESBs means this audit trail requirement is met "for free," so to speak.

Use Document-Bound Security Tokens for Single Sign-On
Single Sign-On (SSO) traditionally has applied only to the interaction between users and Web sites. Web Access Control products from vendors such as Entrust and RSA allow a user to enter a password for one Web site, browse to a different site, and be logged in automatically without re-authenticating. In the case of an ESB, the security requirement is slightly different. When messages travel over multiple "hops," their security context must travel with them. Security needs to be pervasive to ensure persistence of the security context as data moves across the enterprise-point-to-point security is inadequate. The job of the ESB product is to perform this type of SSO.

Because ESBs use document-based integration, security tokens can be bound to the documents themselves. For example, if the document contains a security token that indicates the end user is Joe Bloggs and the document is to be passed to a service being exposed by a J2EE application server, the ESB can set the J2EE runAs deployment descriptor to the identity of Joe Bloggs. Similarly, if the message is to be passed to a mainframe using CICS Sockets, the ESB can populate the RACF credentials for Joe Bloggs to ensure the document enters the mainframe under the appropriate user ID. This is what SSO means for ESBs.

Persistent Signatures and Persistent Encryption
ESBs do not necessarily have to use XML, but in practice most do. Because ESBs are document-based and include content-based routing as a standout feature, XML is an obvious choice. XML allows an application which is a node in an ESB to single out its portion of a document without performing finicky string manipulation (as in EDI).

Another advantage of using XML is you can then use the entire family of technologies that have been built on top of XML. These include XML Encryption and XML Signature. When XML documents are routed between nodes in an ESB, XML Encryption and XML Signature allow portions of the message to remain encrypted and signed throughout the whole transaction. Together, these two standards provide Confidentiality and Integrity, which are the first two of the three "CIA" security pillars. The third is Availability, and this is provided by the ESB product itself by ensuring that if a node in the ESB is unavailable, the document is either queued, routed to an alternative backup node, or the application fails gracefully and passes an appropriate error message back to the client.

Analyze the XML Threat
More often than not, ESBs use XML. In some cases, they take XML as input from other applications. The security maxim "never trust your input" applies here. You easily can think, "XML is just data; it doesn't present a security threat. You might as well say CSV files represent a security threat." But the problem is not XML itself, which indeed is simply data, but the family of technologies that act on XML. Attacks have been devised that clog XML parsers or trick them into opening a local file from the file system and inserting the file into an XML document. Attacks such as SQL Injection prove problematic if the ESB is routing data into a database using JDBC or ODBC. It is important that the ESB scrubs the XML data of any harmful content.

This XML threat analysis can itself be performed as a service. It should be one of the security services the ESB provides. This allows you to route suspicious XML documents through the threat analysis service to check them for malicious content.

Higher-Level WS-* Specifications
Many corporate architects are wary of using technologies that are not open standards (such as HTTP and TCP-IP) or "industry standards" (such as IBM WebSphere MQ and MSMQ). The technologies often known as WS-* are examples of this. Of the WS-* technologies, only WS-Security is an OASIS standard. WS-Security is an obvious choice for binding security tokens to XML documents and it is also the means by which XML Encryption and XML Signature are used with SOAP.

Unfortunately the higher-level WS-* specifications are still far from being standards, but they will become standards in time and have clear uses for security in an ESB. For example, WS-Trust defines useful messages for requesting security tokens using services, and in fact some companies use it in production today. In addition, WS-SecurityPolicy is an attractive way to define the security policy of an individual node in an ESB, and WS-SecureConversation addresses the issues that arise when security sessions must be set up and torn down repeatedly for multiple documents sent along an ESB. The reliable messaging specifications also apply to security because availability is part of security. Still, enterprise architects need to consider the competitive and risk implications of deploying an ESB that uses higher-level WS-* specifications that are not yet standards.

Get on the Bus
The ESB is a useful technology that presents a practical approach to enterprise integration. Like all enterprise products, the ESB requires security to be credible, and an ESB should provide these services. Ensure that the vendor you choose has the security requirements covered so you can start using this valuable development tool.