When you are planning the security of your messaging system,
the range of options available to we can be described through a set of frequently asked questions.
These are some of the questions you might have when we start planning
for messaging security:
- How do I secure the bus?
- Providing WebSphere Application Server global security is enabled, and a user registry is configured, a newly created service integration bus is secured by default. The Enable
bus security flag in the bus definition is checked by default. This means the messaging engine authenticates all connecting client applications, and performs authorization checks on every client application that attempts to access bus resources. For more information about enabling bus security, see Messaging security.
When creating a new bus, or to secure an existing bus, the Bus
Security wizard prompts you to specify a security domain. The security domain contains the security settings for the bus. We can specify the default global domain, or an alternative domain, depending on the versions of the bus members:
- Global domain
- This is the default security domain. Specify the global domain for mixed-version buses.
- Cell level and custom domains
- If the bus contains WAS v7.0 or later bus members only, we can configure the bus to use either the cell default security domain, or a custom security domain. A custom security domain typically contain security settings specific to a particular bus. We can configure additional, separate security domains for user applications such as the UserRepository. For more information about using multiple security domains for the bus, see Messaging security and multiple security domains.
For more information about how to add a new secure bus, see Add a secured bus.
To secure an existing bus, see tjr_secure_bus_global.html#tjr_secure_bus, and Secure an existing bus using multiple security domains. To migrate an existing secure bus from a global security domain to a cell level or custom security domain, see Migrating an existing secure bus to multiple domain security.
Who has authority to access the bus?
- When a client application attempts to connect to the bus, the messaging engine authenticates the credentials (an identity and password)
for the client application against the user registry. If the client authenticates successfully, the messaging engine checks the client has authority to connect to the bus. Every client applications that has a valid user identity and password in the user registry can authenticate successfully, but you might not want every client application to have authority to connect to the bus. To control access to the bus, you must grant authority to specific client applications in the bus connector role for the bus. We create a group in the user registry, add the identities of the client applications to the group, and then add the group to the bus connector role for the bus. For more information, refer to Administer the bus connector role.
Who has authority to access bus destinations?
- For each destination, decide which clients require authority to undertake operations at a bus destination, and which operations (or roles) they have to undertake. Authority is granted by adding
groups and group members to roles. For example, if you want a group
of client applications called MyGroup to send messages to a queue destination called MyQueue, you add MyGroup to the sender role for MyQueue. For more information, refer to Administer destination roles.
We can define a set of default permissions that apply to every destination in a bus. For example, to authorize all the members of a group called MyMediations to send messages to every destination on a selected bus, we can add MyMediations to the default sender role. By default, all local destinations inherit roles from the default resource. Choose to override default inheritance for selected destinations. For more information about default roles, see Administer default roles.
For more information about overriding default role inheritance, see Disable inheritance from the default resource.
If a group
of client applications publish and subscribe to topics, the topics exist in a topic space. The identities of all the clients that publish
to a topic to must belong to a group that has the sender role for the topic space. All the client applications that subscribe to a topic must belong to a group that has the receiver role on the topic space.
For more information, see Administer topic space root roles.
By default, there are also checks on authorization permissions at the topic level. We can disable the topic level check, or decide
which groups of client applications to authorize to access selected topics.
Which connections must I secure?
- Decide which of the following connections to secure with SSL:
- Connections between the clients and the servers (messaging engines).
- Connections between messaging engines within a bus.
- Connections between buses.
For more information, refer to Secure messages between messaging buses.
Which user IDs are stored in messages that flow between the bus and any foreign buses?
- When a message is sent, the user ID of the sender is stored in the message and is used for any subsequent access control checks on the message. Where a link exists between buses, we can configure the Inbound ID and the Outbound ID on the link to control which user ID is stored in messages that flow between local and foreign buses.
The Inbound ID replaces the user ID in every message that flows across the link into the bus. The Inbound ID is used to control access to messages within the bus. You might want to configure an Inbound ID
for the following reasons:
- The local bus and the foreign bus exist in separate security domains.
- The foreign bus is not secure.
- We can manage access control more easily when every message has the same user ID.
The Outbound ID replaces the user ID in every message that flows across the link out of the bus. You might want to configure an Outbound ID when we to prevent the original user ID from being carried in the messages on the foreign bus.
For more information, refer to Secure links between messaging engines.
What level of data store security do I
need?
- The messaging system can use a data store (database) to store
messages on a disk. The messages in the data store might be protected
by a username and password. You should consider whether this is sufficient security for the data store. Your data base might provide additional security options, for example data encryption. For more information, refer to Secure database access.