Authentication services are supported only between client applications that use the WebSphere MQ Real-time Transport and WebSphere Event Broker Real-timeInput and Real-timeOptimizedFlow nodes.
The WebSphere Event Broker authentication services verify that a broker and a client application are who they claim they are, and can therefore participate in a publish/subscribe session.
Each participant in the session uses an authentication protocol to prove to the other that they are who they say they are, and are not an intruder impersonating a valid participant.
The WebSphere Event Broker product supports the following four protocols:
The first two of these protocols and their infrastructure requirements are described in Simple telnet-like password authentication and Mutual challenge-response password authentication respectively. Asymmetric and symmetric SSL protocols are described in SSL authentication.
The protocols vary in strength, in terms of providing protection against participants that are not valid participants in the session; P is the weakest and R is the strongest.
The set of protocols that can be supported by a specific broker in the broker domain can be configured using the workbench. One or more protocols can be specified for each broker. Use the workbench to enable or disable authentication on each Real-timeInput node that is defined for a particular broker. When authentication is enabled at a Real-timeInput node, that node supports the full set of protocols specified for its corresponding broker. The configuration options are illustrated in the following diagrams:
This protocol can also be described as password in the clear because the password passes un-encrypted over the network. The client application connects to the Real-timeInput node using TCP/IP. The input node requests that the client identify itself. The client sends its "userid" and its password.
This simple protocol relies on both the client and the broker knowing the password associated with a user ID. In particular, the broker needs access to a repository of user and password information. The user ID and password information is distributed by theUser Name Server to all the brokers in a WebSphere Event Broker product's domain. The User Name Server extracts user and password information from an operating system file.
The User Name Server approach allows for the centralized maintenance of the source of users and passwords, with automatic distribution of the information to brokers, and automatic refreshes of the information if required. It also provides availability benefits, because user and password information is maintained persistently at each broker.
Each client application must know its own user ID and keep its password secret. When creating a connection, a client specifies its credentials as a name/password combination.
This protocol provides relatively weak security. It does not compute a session key, and should only be used in environments where there are no "eavesdroppers" and no untrusted "middle-men".
In the case where user and password information is stored in a flat file on the User Name Server system, the passwords are stored and distributed "in-the-clear".
The computational load on the client and server is very light.
This is a more sophisticated and secure protocol that involves the generation of a secret session key. Both the client and the server compute this key using the client's password. They prove to each other that they know this secret through a challenge and response protocol.
The client must satisfy the server's challenge before the server satisfies the client's challenge. This means that an attacker impersonating a client can gather no information to mount an "offline" password guessing attack. Both the client and the server prove to each other that they know the password, so this protocol is not vulnerable to "impersonation" attacks.
As in the case of the simple telnet-like password protocol, the broker must have access to user and password information. Information about the user ID and password is distributed by the User Name Server to all the brokers in the domain. The User Name Server extracts user and password information from an operating system file.
Each client application must know its own user ID and keep its password secret. When creating a connection, a client specifies its credentials as a name/password combination.
Computational demands on both client and server are fairly modest.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
aq01206_ |