Service integration security planning
When you are planning the security of your messaging system, the range of options available to you can be described through a set of frequently asked questions.
- How do I secure the bus?
- Who has authority to access the bus?
- Who has authority to access bus destinations?
- Which connections must I secure?
- Which user IDs are stored in messages that flow between the bus and any foreign buses?
- What level of data store security do I need?
If you are using service integration with web services, refer to Securing bus-enabled web services.
- 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 that 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 you create a new bus, or you want 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. You 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. You must specify the global domain for mixed-version buses.
- Cell level and custom domains
- If the bus contains WebSphere Application Server Version 7.0 or later bus members only, you 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. You 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.
- 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. You 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 Administering the bus connector role.
- Who has authority to access bus destinations?
- For each destination, you must 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 Administering destination roles.
You can define a set of default permissions that apply to every destination in a bus. For example, if you want to authorize all the members of a group called MyMediations to send messages to every destination on a selected bus, you can add MyMediations to the default sender role. By default, all local destinations inherit roles from the default resource. You can choose to override default inheritance for selected destinations. For more information about default roles, see Administering default roles. For more information about overriding default role inheritance, see Disabling 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 Administering topic space root roles. By default, there are also checks on authorization permissions at the topic level. You can disable the topic level check, or decide which groups of client applications you want 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 Securing 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, you 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.
- You 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 you to prevent the original user ID from being carried in the messages on the foreign bus.
For more information, refer to Securing 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 your data store. Your data base might provide additional security options, for example data encryption. For more information, refer to Securing database access.