Service integration security

Messaging security ensures that service integration bus users are authenticated, resources are protected by security checks, and messages are secured when they are in transit. Use these topics to learn how to secure the service integration bus and protect messages sent and received.

Security covers all of the following areas:

• Authenticating and authorizing users that attempt to connect to a bus, and use its resources.

• Secure communication transports between clients and messaging engines, and between messaging engines themselves.

• Authenticating peer messaging engines in a bus.

• Protecting the message store with a user identity.

When a bus is created with bus security enabled, the following conditions apply:

• The bus requires client authentication.

• The bus enforces authorization policy.

• The bus requires use of SSL transport chains.

We can use secure transport connections to ensure the confidentiality and integrity of messages that are in transit between application clients, the bus, and between messaging engines. This is achieved by defining transport chains and then referencing the transport chain name as follows:

• For application client connections: from the connection factory administered objects.

• For connections to foreign buses: from the Target inbound transport chain property of the service integration bus link.

• For connections to WebSphere MQ: from the Transport chain property of the WebSphere MQ link.

• For connections between messaging engines: from the Inter-engine transport chain property of the bus.

For more information, see Secure transport configuration requirements.

When a secure bus is created, only SSL protected messaging chains are permitted. For example, we can use the InboundSecureMessaging transport chain.

In the routing properties for the service integration bus link for a foreign bus connection, the user ID applied to messages entering or leaving the foreign bus can be replaced by values specified by the Inbound user ID and Outbound user ID properties.

The ability to authenticate access to a foreign bus is provided by the Authentication alias property of the service integration bus link. We can specify an authentication alias at each end of the service integration bus link between two secure buses when creating each foreign bus connection. The user ID specified in the authentication alias on each side of the link must be the same for authorization purposes. For example, consider a scenario where two messaging engines are connected by a service integration bus link. Messaging engine A presents the user ID and password to messaging engine B so that messaging engine B can authenticate messaging engine A. For details about creating a foreign bus connection, and therefore a service integration bus link, see Configure foreign bus connections.

Subtopics

• Service integration security planning
  When you are planning the security of the messaging system, the range of options available to we can be described through a set of frequently asked questions.

• Messaging security and multiple security domains
  When you secure a service integration bus, we assign it to a security domain containing a set of security attributes. There are three types of security domain: global, cell level and custom. The type of security domain you use for a particular bus depends on the security requirements, the bus topology, and the versions of the bus members.

• Messaging security
  Messaging security protects the service integration bus from access by unauthorized users.

• Security event logging
  Security events on a service integration bus are logged as audit or error records in the SystemOut.log file for the bus.

• Messaging security audit events
  Messaging security audit events are produced when a messaging client sends or receives a message, or updates a service data object repository, and when a publisher submits a message to a topic.

• Client authentication on a service integration bus
  When a client application attempts to connect to a messaging engine on a secure service integration bus, the client application provides credentials to the server that are checked against the user registry.

• Role-based authorization
  Service integration messaging security uses role-based authorization. By adding and removing users and groups in access roles we can control who has access to a secured bus and its resources.

• Destination security
  When messaging security is enabled, the authorization policy for resources on the service integration bus is enforced, and client applications must have authority to access bus destinations.

• Mediations security
  When bus security is enabled, authorization permissions are required to ensure that mediations can run, and undertake messaging operations securely on a service integration bus. There are mechanisms for mediations security, and implications for running mediations on a bus that spans multiple security domains.

• Topic security
  Client applications publish and subscribe to a topic. When messaging security is enabled, client applications require authority to access a topic.

• Access control for multiple buses
  The messaging engine on a service integration bus uses role-based authorizations to ensure that local buses can exchange messages securely with foreign service integration buses, and with WebSphere MQ.

• Message security in a service integration bus
  The transport policy for a service integration bus controls which transport mechanisms a remote client application can use to connect to the bus.

Related concepts

Mediations

Service integration technologies

Bus configurations

Interconnected bus configurations

Configurations that include WebSphere MQ

Related tasks

Connect buses