With the rise of asynchronous messaging comes the need for securing message flows in WebSphere MQ. This article discusses the architecture of WebSphere MQ, along with some options available for securing an asynchronous communications infrastructure.
Today's business environment is becoming more and more complex, and the demands on the IT department to support increasing numbers of enterprise initiatives are growing in lockstep. One area drawing significant attention is communications, both between applications within the enterprise and between applications that span companies. While communications over the Internet have traditionally been characterized in terms of HTTP (browser/Web server, and more recently, Web applications running over SOAP), other communication styles are often more efficient and/or more appropriate.
Asynchronous messaging is a popular and effective communications paradigm for integrating applications within the enterprise as well as facilitating electronic business relationships that span enterprise boundaries. Nevertheless, as with all forms of communications (see sidebar on XML), security is the critical requirement - and the level of trust that can be established is often the major determinant of the business value the integration returns to the enterprise.
In this article I will describe the integration of X.509 digital certificates and messaging to create a trustworthy mechanism for the exchange of sensitive business information. In particular, I will describe in some detail the architecture of IBM's WebSphere MQ (formerly known as MQSeries), with an emphasis on the options for securing message flows using capabilities enabled by aspects of VeriSign Intelligence and Control Services - public key cryptography, digital certificates, and public key infrastructure (PKI).
Introduction to IBM WebSphere MQI will describe a secure asynchronous communications infrastructure. WebSphere MQ commands between 70-80 percent of this market and will be the sole focus of this article. This section provides a gentle WebSphere MQ introduction; a more detailed description comes later.
With deep apologies to IBM development, WebSphere MQ can be likened to an e-mail system on steroids. Although this analogy is a gross simplification, an e-mail system has a message sender and receiver (neither must be online or connected for the other to do useful work), both sender and receiver have a mailbox, to hold messages pending transmission or processing respectively, and sender and receiver are connected through a communications medium (most likely TCP).
Figure 2 illustrates a much-simplified WebSphere MQ architecture (analogs to an e-mail system are obvious; queues equate to mailboxes and the queue manager/MCA [message channel agent] combination functions much like the sendmail daemon):
- Queue manager: Controls the WebSphere MQ environment on a particular machine, facilitating message transfer from the business application through a queue, onto a communications channel vis-a-vis the message channel agent.
- Queue: A (temporary or permanent) holding area for messages (i.e., before they are put onto the communications medium at the sending machine, or consumed by the application on the receiving machine).
- Message channel agent: Deals with the complexity of the communication protocol and manages the guaranteed delivery of messages from the sending machine to the receiving machine.
- Channel: The pipe that connects two communicating WebSphere MQ machines - typically TCP, but other protocols (such as SNA) are supported.
Message queuing is a method of application-to-application communication. Applications communicate by writing/reading application-specific data (messages) to/from queues, without having a dedicated synchronous link between them. Messaging means that programs communicate with each other by sending discrete amounts of data in messages to some intermediary, and not by calling each other directly (unlike the RPC paradigm - remote procedure calls). Queuing implies that applications communicate through queues, which removes the requirement for both sending and receiving applications to execute concurrently. In other words the sending and receiving of messages is asynchronous; there is no time dependency between sending and receiving except that which may be imposed by the applications themselves.
WebSphere MQ is IBM's implementation of messaging. WebSphere MQ-enabled applications use a consistent Application Program Interface (API) across all platforms. The application communicates directly with its local queue manager by using the Message Queuing Interface (MQI). The MQI is a small API with only 13 calls that request services from the queue manager.
The typical programmatic flow of WebSphere MQ is shown in Figure 3. The first step is for the application to connect to the queue manager. It does this through the MQConnect call. The next step is to open a queue for output using the MQOPEN call. The application then puts its data on the queue using the MQPUT call. To receive data the application will also call the MQOPEN call to open an input queue. The application will receive data from the queue using the MQGET call.
Also shown are the message channel agent, channel exits, and Object Authority Manager (OAM). The MCA is the WebSphere MQ program that moves the messages from the local transmission queue on the sending machine to the target queue manager on the receiving machine using existing transport services. The most commonly used transport services are TCP/IP and SNA. The channel exits are user-written programs that can be executed from one of a defined number of points in the program execution flow during channel operation. The OAM is the default authorization service (which is operating system specific) for command and object security. These three components are important for existing security solutions for WebSphere MQ.
EXISTING SECURITY CAPABILITIES WITHIN WEBSPHERE MQ
Existing security capabilities within WebSphere MQ are in three components: the OAM, channel exits, and (available with the current release, v5.3) SSL channels.
1. The Object Authority Manager (OAM): WebSphere MQ uses the OAM to provide access control functionality (i.e., authorization services). The OAM maintains an access control list for each resource that it controls. The OAM is passed a principal, a resource name, and an access type request. It will either grant or reject access based on its internal access control list.
2. Channel exits: WebSphere MQ channels provide three exit points where security functionality may be added (in fact, these exits can be used to implement any desired functionality, for example message compression):
-Security exit: Used for authentication of the partner MCA. The exit is invoked at MCA initiation and termination, and at channel startup after initial negotiation, but before any user data is exchanged. These channel exit routines operate in pairs.
-Message exit: Used for link encryption (such as SSL), validation of user ID, and auditing. A message exit is invoked once per message on each side of the channel, that is, after the message is taken off the transmission queue and before the message is put on the target queue.
-Send and receive exit: Used for data encryption and compression. These exits are called once per message segment. The data available to the exit program is part of the message.
Channel exits are commonly used to protect data. They can provide data encryption, data integrity, and message origin authentication. The data protection is on a machine-to-machine basis and operates at the transport (communications protocol) level, not the application layer.
3. SSL channels: New in WebSphere MQ v5.3 is a capability called SSL channels. As the name implies, this is functionality that implements standard SSL over TCP/IP. This feature provides channel authentication, data encryption, and data integrity for MQ messages on the wire (i.e., as they travel from MCA to MCA over a TCP connection) but has no effect on messages in the sending or receiving queues.
Architectural Perspective on Enhancing WebSphere MQ SecurityThis section describes potential integration points for enhancing or extending WebSphere MQ security from an architectural perspective. Figure 4 highlights the specific points where security can be integrated.
MODIFY THE APPLICATION
Integration Point 1 positions security policy (implemented with programming logic) within the application, which is generally considered a bad idea from a security standpoint. On the other hand, it also means the application has complete control over which security services are provided and at what granularity.
REPLACE THE MQI LIBRARY OR MODIFY ITS BEHAVIOR
Integration Point 2 can be implemented with either of two fundamental approaches:
- Replacing (or displacing) the standard WebSphere MQ library that provides the MQI interface with a new library that provides security services
- Extending the MQI by taking advantage of WebSphere MQ API Exits, a general-purpose framework for modifying the behavior of any MQI call
The first approach would generally represent a vendor-provided solution, while the second could be a vendor-provided solution or a customer roll-your-own alternative.
OBJECT AUTHORITY MANAGER
Integration Point 3 is included in the interest of completeness and represents existing OAM functionality, i.e., authorization to WebSphere MQ resources. On the mainframe equivalent OAM functionality is implemented with RACF (Resource Access Control Facility).
CHANNEL EXITS
Integration Point 4 also represents an existing WebSphere MQ security capability, although out-of-the-box exits are simply exit points (architectural placeholders) that customers can use to implement security either by purchasing a channel exit-based security product or by writing one themselves.
CHANNEL OVERLAY
Integration Point 5 implies the imposition of a security service at the channel level, essentially tunneling WebSphere MQ messages inside a VPN-style service.
Practical Solutions to Enhance WebSphere MQ SecurityThis section maps various practical solutions into the architecture by describing some of the WebSphere MQ security products available today from IBM.
MS81 - WEBSPHERE MQ INTERNET PASS-THRU (MQIPT)
WebSphere MQ Internet Pass-Thru (MQIPT) is a WebSphere MQ base product extension (freely available SupportPac) that can be used to implement messaging solutions between remote sites across the Internet. It makes the passage of WebSphere MQ channel protocols into and out of a firewall simpler and more manageable by tunneling the protocols inside HTTP or SSL or by acting as a proxy.
If the SSL option is chosen, this product fits cleanly into Integration Point 5 in Figure 4, intercepting WebSphere MQ message flows and tunneling them through an SSL connection.
WEBSPHERE MQ V5.3 SSL CHANNELS
WebSphere MQ v5.3 has added new security functionality that provides (out-of-the-box) the ability to transmit messaging through a secure SSL connection. There is no intervening gateway; this is a new channel type built into the base product that provides for encryption of all messages flowing on this channel. This option also represents a solution that works at Integration Point 5.
WEBSPHERE MQ V5.3 API EXITS
WebSphere MQ API exits let you write code that changes the behavior of WebSphere MQ API calls such as MQPUT and MQGET. API exits are conceptually identical to the well-known WebSphere MQ channel exit capability discussed earlier, but operate at a much lower level in the WebSphere MQ code stack. The notion is to insert code immediately before or after any MQI call, and then the queue manager drives this exit code to the registered entry points. This technology works at Integration Point 2 in Figure 4.
Access Manager for Business IntegrationIBM Tivoli Access Manager for Business Integration (TAMBI) also fits into the WebSphere MQ architecture at Integration Point 2; this is clearly shown by its component architecture (see Figure 5).
TAMBI provides a set of multithreaded, shared libraries that execute in the process space of each WebSphere MQ application, and a per-machine daemon for managing functions common across all MQ-enabled applications on that machine. TAMBI libraries intercept WebSphere MQ API calls, enabling WebSphere MQ applications to be secured without modification. Calls made by the application to WebSphere MQ for services are captured by the interceptor, which performs the following four core functions:
- An authorization check on the request for WebSphere MQ services (i.e., should this action be permitted).
- Based on security policy, encrypt and/or digitally sign the message before placing the message on the queue on the sending machine.
- Based on security policy, decrypt and/or validate the signature on the message before presenting the message to the receiving application.
- Audit the message flows based on the authenticated application (or user) PKI identity.
The interceptor obtains policy information from a master policy server that is managed by an administration console called the Web Portal Manager (a WebSphere Application Server-hosted application).
TAMBI uses public key cryptography to protect WebSphere MQ message data from viewing by unauthorized parties (encryption) and from undetected tampering (digital signatures). This data protection is applied while messages are in a queue, as well as on the wire traveling from WMQ machine to WMQ machine In other words, true application-to-application-level security. It also provides an audit trail of (configurable) WMQ events. Finally, because of its integration with Tivoli Access Manager, Access Manager for Business Integration provides a centralized, enterprise-wide authorization capability on all WebSphere MQ resources (queue managers and queues).
WebSphere MQ Security Options ComparisonTable 1 gives a short comparison of the major advantages and disadvantages of implementing some/all security services at the five WebSphere MQ security integration points. This analysis looks at both the architecture as well as the existing implementations discussed above.
Case StudiesThe remainder of this article uses the concepts discussed so far in the context of solving two real-world customer problems. More specifically, these case studies demonstrate the use of a software offering called "IBM-VeriSign Solution for Secure e-business Integration" (affectionately known as Trusted MQ) to create secure messaging environments for two customers.
TRUSTED MQ
Trusted MQ addresses a very familiar problem space (although not necessarily familiar to the business messaging world that WebSphere MQ serves) by marrying a collection of technology and expertise in security from two premier companies in this space, IBM and VeriSign:
- WebSphere MQ SSL channels
- TAMBI
- VeriSign Managed PKI
- Consulting services
Trusted MQ uses IBM PKI-enabled products and VeriSign X.509 digital certificates to provide authentication (application-to-application or channel-to-channel), data confidentiality through strong encryption, data integrity, digital signatures, and auditing capabilities - that can selectively be brought to bear to solve customer security problems in their WebSphere MQ infrastructure.
CUSTOMER A
Customer A's environment was built around a very common WebSphere MQ hub-and-spoke architecture, although the complication here was that the customer operated in all 50 states in the U.S. and had two processing centers - one on the East Coast and one on the West Coast.
All applications homed in one of the hubs, and all applications were hosted in one of the two data centers.
Due to the distribution of the data, most WebSphere MQ traffic was confined to one (or the other) data center, but a small percentage - which still amounted to thousands of messages per day - required access to application(s) on the other hub. This traffic was initially sent in clear text that represented a clear exposure to the customer. In addition, because each hub represented a mission-critical processing point in the enterprise it was mandatory that only the New York hub was allowed to communicate with the LA hub, and vice versa. Rogue applications could not be allowed to connect to a hub, possibly impacting availability or worse.
WebSphere MQ SSL channels and VeriSign were chosen to solve this customer's security problems by providing the following features:
SSL v3 using mutual authentication. One queue manager on each hub was provided a VeriSign X.509 digital certificate; its partner on the other hub validates the certificate (including certificate revocation list checking) and checks for an authorized distinguished name before allowing the channel to start.
SSL provides the strong encryption needed to assure the necessary data confidentiality for the customer's sensitive data as it traverses the Internet.
CUSTOMER B
Customer B had a much more modest WebSphere configuration, only three machines arranged in a bus architecture. However, all three applications exchanged messages representing high dollar value business trans actions. Volume was low, but the data was extremely sensitive and needed to be protected at an application-to-application level.
In other words the message needed to be protected from unauthorized viewing or modification from the moment it left the sending application until the message was processed by the receiving application, including all time spent at rest in intervening queues.
Company audit requirements specified that every message needed to be audited (who sent it and when, who received it and when, how was it protected). The messages needed to be encrypted (eavesdropping by company employees was as much a concern as external hackers) and only authorized programs could be permitted to read/write messages from the queues.
IBM Tivoli Access Manager for Business Integration and VeriSign Managed PKI were chosen to meet these customer security requirements:
- TAMBI provides for digital signatures and encryption of each message (security policy is specified on a per/queue basis, in this case each application had only one queue).
- TAMBI audits each message based on the application's PKI identity (as defined in their X.509 certificate); these records contain a message identifier, sender or receiver identity, time stamp information, security policy applied, and other information.
- TAMBI provides a robust authorization service (access control to queues) guaranteeing that only the authorized application was allowed to PUT (write) or GET (read) messages from the respective queues.
- VeriSign's Managed PKI offering provided the software and services necessary for this customer to establish its own private certificate authority to issue certificates.
XML, A MIXED BLESSING
It is important to understand the (perhaps not so) subtle impact of using XML to encode WebSphere MQ messages. Figure I shows a string of digits being snooped by an unauthorized individual eavesdropping on the channel, but without a detailed knowledge of the sending or receiving application and more specifically the data formats being exchanged, it is difficult to ascribe any meaning to the top flow.
On the other hand, the identical data flowing in the XML self-describing format makes the job of data interpretation much easier. XML places business context (i.e., meaning) around an otherwise incoherent sequence of numbers. XML facilitates many benefits to a corporation (such as application decoupling), nevertheless all other things being equal, XML may increase the security requirements for transmitting confidential data.
Summary
As with any technology that transmits potentially sensitive or high-value information over insecure networks (and they are all insecure at some level) multiple dangers exist:
- Unauthorized viewing of the information
- Unauthorized modification of the information
- Lack of auditability of the information flows
- Lack of assurance of who the communicating partner really is
- Unauthorized access to the communications medium
The architecture of WebSphere MQ was explored at some depth to illustrate the design points where security services could be integrated to address these dangers. Finally, real-world solutions were presented in the form of case studies using typical customer scenarios.
Resource
IBM WebSphere MQ family SupportPacs: www-306.ibm.com/software/integration/support/supportpacs
|
