How to implement the security of process data and services in WebSphere message Broker

Transmission protocol and Security control

WebSphere Message Broker (for short message broker) is an enterprise-class consolidated middleware and service bus that provides extensive connectivity, including MQ, HTTP, FTP, Web services, CICS Dozens of different transmission modes and protocols. In terms of security, each protocol has its own user identity information transmission and processing methods.

Before introducing security validation and access control for message Broker, let's take a look at some of the common security specifications and standards for communication and transport protocols.

HTTP protocol

The Hypertext Transfer Protocol (Http,hypertext Transfer Protocol) defines the data interaction specification between browsers and Web servers and is the standard of communication for all Web applications.

The HTTP protocol has many kinds of security information delivery and authentication criteria, including HTTP basic,digest and so on. Among them, the most common is the HTTP Basic standard. It is defined by the specification of the HTTP 1.0/1.1, which is supported by all major browsers. On the transport, it encodes the username and password in BASE64, and adds it to the Authorization property of the HTTP header. When the other receives the request, the user information is parsed from the Authorization attribute of the message header.

Figure 1. Example of HTTP headers using HTTP Basic method

Where d2fuz2xpondhbmdsaq== is the encrypted string of user name and password.

HTTP Basic is the simplest way, it does not require the server to retain the state of the session, and does not require additional components, which is ideal for message Broker application scenarios. For commonality and processing independence, message Broker is usually designed to be stateless, not to retain session information, and to require security authentication for each HTTP request, if it is required. Using HTTP Basic, you can include encoded user identity information in all request headers.

However, HTTP Basic is simply coded for user names and passwords and is not secure. If higher security is required, you can use HTTPS's secure transmission to ensure that the username and password are not stolen during transmission.

MQ/JMS protocol

WebSphere MQ messages are divided into message headers and message bodies. Where the header consists of several properties that describe the message, is fixed and does not allow expansion. In the header, security-related properties are only one user identifier and are limited to a maximum of 12-bit characters. But there are no properties for storing passwords.

Figure 2. User identity properties in MQ message headers

Therefore, if you follow the MQ message header standard, you can only pass user name information, and the user name needs to be less than or equal to 12 characters. If more complete user identity information (such as username + password) is required, it needs to be defined in the message body of MQ.

The Java Messaging Service (Jms,java) is a standard API interface defined by the Java EE specification for accessing different message middleware, such as WebSphere MQ, SONICMQ, and so on. JMS also divides messages into message headers and message bodies, but unlike MQ, JMS allows a custom message header to place the username and password (or encrypted password) into the specified properties of the header. (If the JMS bottom access is WebSphere MQ, the custom header is actually in the MQ message body)

Either MQ or JMS, the user information can be placed in a property of the message header, but there is no standard or specification similar to HTTP Basic. Of course, you can also define the security information in the message body when defining the data format of the message.