Planning your service integration security

Use this task to determine the security requirements for your messaging system before you begin installation.

About this task

When planning security for your messaging system you should consider the following points:

A bus as a whole can be marked secure or not secure, depending on server security, see Enabling and disabling messaging security.

If you are going to use service integration with Web services, refer also to Securing Web services through service integration technologies.

Who should be able to access the bus
When a user connects to the bus, the user ID and password are authenticated and then the user ID is checked to see whether it has permission to connect to the bus. Any user who has a valid user ID and password in the user registry will be able to authenticate successfully, but you may not want all of these users to connect to the bus. To allow a user, or a group of users, to connect to the bus, you must add them to the Connector role on the bus, see Administering bus connector roles.

When a bus is created, initial authorization permissions are created with the "AllAuthenticated" group in the Connector role, which means that any user who can authenticate successfully will have permission to connect to the bus. You will probably want to remove this and replace it with the specific users and groups that you want to connect to the bus.

Who should be able to access each destination
For each destination, you should decide which users should have permission to send messages to, receive messages from, or browse messages on the destination. You can grant a user, or a group of users, these permissions by adding them to the Sender, Receiver, or Browser role on the destination, see Administering destination roles through the command line.

You can define default permissions which apply to all destinations in a bus, although you can also specify that a given destination should not use the default permissions. You should use the default permissions if you want a user, or group of users, to be able to access all the destinations in a bus, for example you might want to grant the mediations user permission to send to all destinations in a bus by adding this user to the default Sender role, see Administering default roles through the command line.

If you publish and subscribe to topics, the topics will exist in a topic space. You must add all users who you want to publish on a topic to the Sender role on the topic space, and all users who you want to subscribe to a topic to the Receiver role on the topic space, see Administering topic space root roles through the command line. By default, there is also a check on authorization permissions at the topic level (as well as on the topic space). You must either decide to turn this off, or decide which users you want to access specific topics.

When a bus is created, initial default permissions are created with the "AllAuthenticated" group in the Sender, Receiver and Browser roles. This allows all authenticated users to access all destinations and topics in the bus. You will probably want to remove these default permissions and either have no defaults, or grant default permissions to a restricted set of users, such as the mediations user. You should then add specific users and groups to specific roles on destinations and topics within the bus, see Administering destination roles through the command line and Administering topic roles through the command line.

Which connections should be secure
You should decide which connections should be secured with SSL or HTTPS. These include connections between the clients and the servers (messaging engines), the connections between messaging engines within a bus, and the connections between buses.

For further information, see Configuring connections and Securing messages between messaging buses.

Which user IDs should be stored in messages that flow out of or into your bus from 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. When you have a link between buses, you can configure the Inbound ID and the Outbound ID on the link to control what user ID is stored in the messages that flow into or out of your bus from foreign buses, see Securing the links between messaging engines.

The Inbound ID replaces the user ID in all messages flowing over the link into your bus, and it will be used for access control decisions involving these messages within your bus. You would typically set this if the foreign bus were in a different security domain from yours, if it were insecure, or simply to make access control of these messages easier to manage by making them all use the same user ID.

The Outbound ID replaces the user ID in all messages flowing over the link out of your bus. You would typically set this if you wanted to prevent the message senders' real user IDs from being carried in the messages on the foreign bus.

Data store security
The messaging system uses a data store (database) to store messages on disk when necessary. Access to the data store is protected by a user name and password. You should consider whether this is sufficient or whether you want to use additional security options which your database might offer, such as encrypting the data. See Securing database access.



In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic Task topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 1:23:07 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-dist&topic=tjr0010_
File name: tjr0010_.html