Architecture

Gateway

The Gateway handles certificate management requests driven by TPP over a REST API, and routes them to an agent in the target RACF, TSS, or ACF2 environment. 

Only a single gateway instance is required on an LPAR in the primary sysplex. To maintain high availability, you can configure the gateway with a dynamic virtual IP address (DVIPA) so that you can activate the gateway on any LPAR in the sysplex. A gateway moving from one LPAR to another is transparent to TPP. Transactions from the REST API are automatically routed to the LPAR on which the gateway is running.

Requests from TPP and responses from EC for Venafi are coded in JSON when they pass through the REST API. The gateway verifies whether the JSON structure and content are correct. The gateway uses a REST API protocol to forward the request to the appropriate target RACF, TSS, or ACF2 environment.

The transactional interface between TPP and the gateway is synchronous. This means that a request from TPP waits until the gateway and agent have completed processing the request and returned a response.

If the target agent is unavailable or does not respond within a preconfigured timeout period (in seconds), the request is canceled and an appropriate error response is returned to TPP. 

For more information, see Configuring-the-gateway.

Agent

Agents handle REST API transactions from the gateway and manage the necessary RACF, TSS, or ACF2 commands. 

Agents run in specific RACF, TSS, or ACF2 environments and must run on an LPAR in the sysplex with direct access to the RACF, TSS, or ACF2 database.

Agents never accept requests directly from TPP. 

For more information, see Configuring-the-agent.

Sample implementation

The following diagram displays a sample implementation of EC for Venafi. TPP uses a REST API to communicate with the EC for Venafi gateway in the primary sysplex. The gateway, configured with a DVIPA, passes the requests to the various agents. A second DVIPA-configured gateway waits to ensure continuous operation.