Service integration security planning
- How do I secure the bus?
- Provide WebSphere Application Server global security is enabled, and a user registry is configured, a newly created service integration bus is secured by default. The Messaging securityEnable bus security flag in the bus definition is checked by default. This means that the messaging engine authenticates all connecting client applications, and performs authorization checks on every client application that attempts to access bus resources.
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 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.
To secure an existing bus, see Secure existing bus, and Secure an existing bus by using multiple security domains. To migrate an existing secure bus from a global security domain to a cell level or custom security domain, see Migrate 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 that 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.
- 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 we want a group of client applications called MyGroup to send messages to a queue destination called MyQueue, we add MyGroup to the sender role for MyQueue.
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. We can choose to override default inheritance for selected destinations.
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.
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.
- 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. We 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 can configure an Outbound ID to prevent the original user ID from being carried in the messages on the foreign bus.
- 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 service integration with web services, see: Secure bus-enabled web services.
Related concepts
Mediations security Messaging security and multiple security domains Messaging security Secure transport configuration requirements
Related tasks
Secure service integration Security planning overview