Messaging security uses a simple role model in which a role contains
the authorization permission required to perform a given operation. If messaging
security is switched on, you must give any users who connect to a bus permission
to carry out the operations that they need to perform. You do this by assigning
them to the appropriate role or roles.
Note: A user is the entity that performs an operation such
as initiating the sending of a message to a destination.
Roles
When you assign a user to a role, this grants
the user all of the permissions that the role contains. Users can belong to
groups, which are defined in the user registry, and you can also assign a
group to a role. In this case, all the users who are members of the group
are authorized to carry out the operations for which this role contains permissions.
There are three special
groups of users:
- AllAuthenticated, which contains all authenticated users. If the AllAuthenticated
group is authorized to perform an operation, then all authenticated users
are authorized to perform it. When a bus is created, an initial set of authorization
permissions is created that allows all users in the AllAuthenticated group
access all local destinations.
You can change these permissions to restrict access to the specific users
and groups that you want to connect to the bus.
- Everyone, which contains all users whether or not they are authenticated.
- Server, which contains all the WebSphere Application
Servers in the cell.
You can assign a user or group to the following types of roles:
- Connector, which contains permission to connect to
the local bus.
- Sender, which contains permission to send (produce) a
message to the destination.
- Receiver, which contains permission to receive (consume)
a message from the destination.
- Browser, which contains permission to browse messages
on the destination.
- Creator, which contains permission to create a temporary
destination based on this temporary destination prefix. This role only applies
to prefix destinations; see Destinations below.
- IdentityAdopter, which contains permission to send
a message using a different user identity. This cannot be used from JMS.
Operations requiring authorization
When
messaging security is switched on, all operations on the following objects
require authorization:
- Buses
- When a user connects to a local bus, before the user is allowed to perform
any further operations, a check is made that this user has permission to connect
to this bus. If a user connected to a local bus wants to send a message to
a destination in a foreign bus, the user must also be authorized to access
the foreign bus.
- Destinations
- Users require authorization to send, receive, or browse all types of destination.
Users who create a temporary destination need to be granted create
permission on the destination prefix on which the temporary destination is
based. The authorization permissions of a temporary destination are the same
as those of the destination prefix on which it is based. The name of this
special destination prefix appears as a prefix in the temporary destination
name.
- Topic spaces and topics
- To access a topic within a topic space,
a user must be authorized to access both the topic space,
and the specific topics within this topic space.
To make topic authorizations easier to manage, a topic by default inherits
authorization permissions from its parent in the topic namespace. However,
you can change these inherited permissions for any given topic, or you can
turn this level of authorization off altogether for a topic space,
in which case a check is made that the user is authorized to access the topic space, but no further checks
are made at the topic level.
Default authorization permissions
The
default authorization permissions provide you with a way of quickly granting
access to all local destinations. While all authenticated users have full
access to all destinations, only the Server user will have the bus connector
role. The administrator needs to specifically grant users access to the bus.
Once the administrator has done that the user has full access to the bus.
The
default permissions apply to all destinations in a local bus namespace. Three
exceptions:
- For an individual destination, which has inheritance disabled
- For any foreign destination
- For alias destinations, which have an alias bus name that is not the local
bus name