hub

A CA UIM hub serves as the communication center for a group of robots. A hub binds robots into a logical group with the hub as the central connection point. Hubs are typically set up based on a location (such as a lab ora building) or by service (such as development). A hub can connect other hubs into a hierarchy of hubs. Two types of hubs and robots are now available—secure (9.10S) and non-secure (9.10 and earlier). Hub and robot versions 9.10 and earlier use the legacy security model. Beginning with CA UIM 9 SP1, secure hub (9.10S) and robot (9.10S) are available, which further enhance the security mechanism in CA UIM. 
uimpga-ga
A CA UIM hub serves as the communication center for a group of robots. A hub binds robots into a logical group with the hub as the central connection point. Hubs are typically set up based on a location (such as a lab ora building) or by service (such as development). A hub can connect other hubs into a hierarchy of hubs. Two types of hubs and robots are now available—secure (9.10S) and non-secure (9.10 and earlier). Hub and robot versions 9.10 and earlier use the legacy security model. Beginning with CA UIM 9 SP1, secure hub (9.10S) and robot (9.10S) are available, which further enhance the security mechanism in CA UIM. 
The 
hub_adapter
 probe (9.10S), a new probe, enables an incremental upgrade over time. hub_adapter supports a 
mixed
-
mode
 environment, where non-secure and secure hubs and robots coexist.
2
2
General Architecture
The general architecture applies to both non-secure and secure hubs and robots. Architecturally, a hub is a robot that gains management capabilities through the presence of the 
hub probe
. Configure the probe to modify how the hub handles the following CA UIM services:
  • Message distribution
    - Messages from robots are routed through the hub. Messages are routed to other hubs, or dispatched to local subscribers (users and probes).
  • Name service
    - The hub translates a
    /domain/hub/robot/probe
     address into an IP address and port. The service registers TCP/IP addresses at start-up. Registration allows applications to connect to the service using TCP/IP.
    This is not applicable for secure hub and robot. In a secure environment, this functionality is achieved by using tunnels.
  • Authentication
    - The hub handles logins to the domain.
  • Authorization
    - The hub verifies user access rights to probes and the infrastructure (hub, robot, and spooler).
  • Tunneling
    - Hub-to-hub tunnels enable a secure communication from one site to another site, much like a VPN.
Secure Hub and Robot Architecture
In addition to the general architectural components above, the secure hub and robot:
  • Establish a strong trust relationship between hubs, and between hubs and robots.
  • Proxy the communications to and from all probes, including the hub and controller.
  • Use encrypted, trusted transport.
  • Ensure that probes listen only on the loopback address. Non-encrypted and non-trusted inter-server probe-to-probe communication is prevented.
  • Support for third-party certificate authorities and PKI. Self-signed certificates are supported, but are not recommended.
  • Replace the legacy SSL mode, proxy mode, and passive mode.
  • Support 
    mixed-mode
     implementations. Mixed mode allows legacy and secure hubs and robots to coexist.
  • Provide secured access to the CA UIM message bus. For example, callbacks above READ level from remote robots are not allowed.
  • Implement enhanced password hashing with the 
    Password Based Key Derivation Function 2
     (PBKDF2) hashing algorithm.
  • No communication between hub-to-hub is supported without tunnels.
Mixed Mode
In large installations, where many hubs connect to many robots, upgrading all the hubs and robots at once is impractical. To avoid a loss of communication during the upgrade, incremental upgrades are supported. Secure hubs can communicate with legacy robots when the hub_adapter probe is installed on the secure hubs. A mixed mode environment consists of both secure and non-secure hubs and robots in a CA UIM domain.
The following diagram illustrates an example mixed-mode implementation.
  • A
      Secure hubs communicate only through tunnels.
  • The controller handles communication between secure hubs and robots. The communication is encrypted.
  • non-secure hubs and robots continue to use unencrypted transport.
  • All internal communication between components that are installed on a secure server occur over the loopback.
Mixed Mode Secure Hub
Mixed Mode Secure Hub
A secure hub and robot support:
  • Secure child robots
  • Non-secure child robots, when the hub_adapter is installed on the secure hub
A non-secure hub and robot support:
  • Non-secure child robots only