IBM Integration Bus, Version 10.0.0.0 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS


Securing the Integration Registry

Optionally, secure access to the Integration Registry by authorization and authentication.

About this task

The Integration Registry is hosted inside a runtime integration node. If you choose to secure the integration node, the security configuration depends on the artifacts that you are storing, and whether you require access from the IBM® Integration Toolkit, the web user interface, or at run time from an integration server. For example, the Integration Registry can be accessed by REST calls through the IBM Integration Bus web user interface. This interface can be configured to be available over HTTP or HTTPS.

In the following diagram, server keystore and server truststore are also known as integration server keystore and integration server truststore. Integration node keystore and integration node truststore are also known as broker keystore and broker truststore.

Possible security configurations for the Integration Registry.

The Integration Registry runs inside the integration node. The server only ever connects to the Integration Registry that is running inside the integration node that the server belongs to.

You can secure access to an integration node and its Integration Registry by using authorization, authentication, or both. You configure authorization and authentication for the Integration Registry in the same way for as for other integration node capabilities. The tasks to set up security depend on the access method used:

Authenticating Integration Registry connections from the web user interface

About this task

You can use the web user interface to configure workload management policies and attach them to message flows. To enable SSL authentication for the browser connection to the web user interface server, follow the instructions in Configuring the IBM Integration Bus web user interface.

Interactions from the web user interface with policies (or any other resource held in the embedded Integration Registry) also require a further exchange of messages between the runtime integration node and the embedded Integration Registry. Consequently, the runtime integration node must act as both the client and server. If HTTPS is enabled, you must export the node's certificate from the Keystore of the web user interface server, and import it into the runtime integration node's Truststore.

Authenticating Integration Registry connections with the IBM Integration API (including the IBM Integration Toolkit)

About this task

You can connect the IBM Integration Toolkit to an integration node and its embedded Integration Registry.

This data exchange uses either HTTP or HTTPS, depending on the configuration of your web user interface. If you configure the web user interface to use HTTPS, the integration node must act as both client and server. Export the integration node's certificate from the keystore, and import it into the integration node's truststore.

Authorizing Integration Registry connections with the IBM Integration API (including the IBM Integration Toolkit)

About this task

When you use the IBM Integration API to connect to an integration node, and administration security is enabled, the user ID associated with the request is checked to see whether it is authorized. This check analyzes the user ID's read, write, and execute privileges on particular SYSTEM queues on the integration node queue manager. In this way, you can grant authority to one or more groups or users to authorize them to complete specific tasks against an integration node and its resources.

All tasks that relate to creating, retrieving, updating and deleting artifacts in the Integration Registry are controlled through the SYSTEM.BROKER.AUTH queue. For more information, see Tasks and authorizations for administration security.

Authenticating Integration Registry connections from an integration server

About this task

When an integration server connects to the Integration Registry in an integration node, requests and responses are sent over either HTTP or HTTPS (using the REST API). If you use SSL authentication (HTTPS), ensure that the truststore and keystore of both the integration server and the integration node have the required certificates.

  1. To enable SSL authentication for the web user interface, follow the instructions in Configuring the IBM Integration Bus web user interface.
  2. To understand the role of a keystore and truststore, see Digital certificates.
  3. In this communication, the integration server acts as the client in the communication, and the integration node acts as the server. For information about how to populate the keystore and truststore, see Setting up a public key infrastructure.

    This scenario also requires a further exchange of messages between the integration node and the embedded Integration Registry. Consequently, the runtime integration node acts as both the client and server, so you must export the integration node's certificate from the keystore , and import it into the truststore of the integration node.

Authorizing Integration Registry connections from an integration server

About this task

To secure an integration node so that REST API connections must be authorized, enable administration security in either of the following ways:
  • When you create the integration node, by using the -s active property of the mqsicreatebroker command.
  • By modifying an integration node by using the mqsichangebroker command.
For more information, see Role-based security.

An integration server can connect to the Integration Registry that runs in an integration node on which authorization is enabled. In this case, authorization takes place without any further configuration actions by a user. However, an integration server cannot connect to an authorization-enabled Integration Registry that is hosted by a different integration node. If you try to do so (by providing a message flow with a URL to a workload management policy stored in a different Integration Registry), the policy cannot be retrieved.


bn34266_.htm | Last updated 2015-03-27 19:28:29