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?
- 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 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.
For more information about how to
add a new secure bus, see Adding a secured bus.
If you want to secure an existing bus, see Securing an existing bus by using the global security domain, and Securing an existing bus by using multiple security domains. If you want 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 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.