Secure buses
Secure a service integration bus provides the bus with an authorization policy to prevent unauthorized users from gaining access. If a bus is configured to use multiple security domains, the bus also has a security domain and user realm to further enforce its authorization policy.
- If administrative security is not enabled for the cell that hosts the bus, enable it. These tasks use an administrative console wizard that detects if administrative security is not enabled, and takes you through the steps to enable it. We must supply the type of user repository used by the server, and the administrative security username and password.
- If the bus contains a bus member at WebSphere Application Server v6, provide an inter-engine authentication alias to establish trust between bus members, and to enable the bus to operate securely. The administrative console wizard detects whether an inter-engine authentication alias is required, and prompts you to supply one. To specify a new inter-engine authentication alias, provide a user name and password.
When we secure a bus, consider the following points:
- If we are securing a bus containing only v7.0 or later bus members, we can use a non-global security domain for the bus. If the bus has a WAS v6 bus member, or might have a v6 bus member in the future, we must assign the bus to the global security domain.
- To assign the bus to a custom domain, we can select an existing security domain, or create a new one.
- If we assign the bus to a custom domain, specify a user realm. We can select an existing user realm, or use the global user realm.
Subtopics
- Add a secured bus
In this task we add a new service integration bus that is secured by default. The security settings for the bus are stored in a security domain. When we add a new bus, we can assign it to the default global security domain, the cell-level domain, or specify a custom domain containing a set of settings that are unique to the bus, or shared with another resource.- Secure an existing bus using multiple security domains
We can configure an existing bus to use a cell-level or custom security domain. Using non-global security domains provides the scope to use multiple security domains. The bus can inherit security settings from the cell, or have a unique security configuration.- Secure an existing bus using the global security domain
Use this task to secure an existing service integration bus using the global security domain.- Migrate an existing secure bus to multiple domain security
Use this task to migrate a secured service integration bus from the global security domain to a cell-level or custom security domain.- Configure bus security using an administrative console panel
Use the administrative console to configure the security properties for an existing service integration bus.- Configure the bus to access secured mediations
Use this task to ensure that the service integration bus is authorized to access secured mediations.- Configure a bus to run mediations in a multiple security domain environment
Configure a secured bus so that it can run mediations successfully on bus members in different security domains.
What to do next
- The bus is secured after you restart all the servers that are members of the bus, or (for a bus that has bootstrap members) servers for which the SIB service is enabled.
- Use the administrative console to control access to the bus by administering users and groups in the bus connector role.
Related:
Messaging security and multiple security domains Disable bus security Enable client SSL authentication Administer authorization permissions Secure messages between messaging buses Secure access to a foreign bus Secure links between messaging engines Controlling which foreign buses can link to your bus Secure database access Secure mediations Add unique names to the bus authorization policy Administer permitted transports for a bus