Securing messaging resources

This topic describes the configuration required to secure messaging resources.

Overview

The IBM® Reliable Transport Extension for WebSphere® sMash implements system-level authentication and authorization for messages which is similar to the one applied to HTTP requests. A secured broker authenticates inbound messaging connections using the application user service and authorization rules can be defined to determine a user's access to queues.

Securing the messaging resources requires the enablement of Secure Socket Layer (SSL) for the broker message service listener. If SSL is not configured, authentication and authorization will not take place. However, if SSL is enabled the access will only by granted to successfully authenticated connections with matching authorization rules.

Authentication

The IBM Reliable Transport Extension leverages the Java™ Authentication and Authorization Service (JAAS) model implemented by the security infrastructure to handle the authentication process.

When SSL is enabled, a JAAS login module called BrokerLogin is registered. This login module is called to validate the credentials presented when an attempt is made to establish a new messaging connection. User authentication is performed using the user service defined to the long-running application containing the messaging broker. For example, the application can use the file user service, LDAP or a custom user service registry.

For environments that do not already have a user service registry created, please refer to the User Service section of the documentation on how to create and configure a user service registry.

Authorization

The IBM Reliable Transport Extension uses an event based authorization mechanism similar to that used to secure HTTP resources.

When an authenticated connection to a secured broker is used to access a queue, an authorizeMessage event is fired and the registered handlers are used to determine whether access should be granted. The authorizeMessage event includes the name of the queue and the type of of access being attempted:

GET: Receive a message from the queue.
POST: Send a message to the queue.

Authorization configuration

The simplest way to configure the rules for the authorizeMessage event is to use the messaging_rule.config template. The most common usage patterns are outlined in the following sections.

Authorizing resources individually

The following example grants POST access to queue1 for the named users. This rule grants access to users "john" and "bob" for the POST operation only. If the user is not "john" or "bob" and no other rules are configured to match the access attempt, the authorization check will fail and the message will not be sent to the queue.

@include "security/messaging_rule.config" {
	"conditions" : "(/event/queue == queue1) && (/event/method == POST)",
	"users" : ["john", "bob"]
}

In the next example, GET access to queue1 is granted to some other users. This rule grants access to users "nancy" and "beth" for the GET operation only. If the user is not "nancy" or "beth" and no other rules are configured to match the access attempt, the authorization check will fail and the message will not be received from the queue.

@include "security/messaging_rule.config"{
	"conditions" : "(/event/queue == queue1) && (/event/method == GET)",
	"users" : ["nancy", "beth"]
}

In the next example, both GET and POST access to queue2 is granted to "bill" and "paul".

@include "security/messaging_rule.config" {
	"conditions" : "(/event/queue == queue2) && (/event/method =~ (GET|POST))",
	"users" : ["bill", "paul"]
}

In the above example, a regular expression is used to select alternative values of /event/method. Since we want the rule to match all possible values of /event/method we could omit that clause, as follows:

@include "security/messaging_rule.config" {
	"conditions" : "(/event/queue == queue2)",
	"users" : ["bill", "paul"]
}

Authorizing multiple resources

A single rule can be used to grant access to multiple resources by the use of regular expressions. For example, the following rule grants full access to all queues to the user broker1.

@include "security/messaging_rule.config" {
	"conditions" : "(/event/queue =~ (.*)) && (/event/method =~ (GET|POST))",
	"users" : ["broker1"]
}

Authorization using user groups and roles

As an alternative to granting authorization for individually named users, the following example authorizes access to all users that belong to the named groups.

@include "security/messaging_rule.config" {
	"conditions" : "(/event/queue == queue2)",
	"groups" : ["group1", "group2"]
}

The special group ALL_AUTHENTICATED_USERS can be used to grant access to all authenticated users.

Use of roles is considered an advanced feature of security. If the application requires roles, the application can associate a role with a set of users, a set of groups or a combination of the two.

The next example outlines the definition of a new role, custom_role, and grants access to all users that have to send messages to the queue:

/config/security/roles/custom_role/groups = ["mySpecialUser", "myOtherUser"]

@include "security/messaging_rule.config" {
	"conditions" : "(/event/queue == queue1) && (/event/method == POST)",
	"roles" : ["custom_role"]
}