Optionally, secure access to the Integration Registry by authorization and authentication.
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.
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:
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.
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.
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.
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.
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.
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.