ICF servers

An ICF server hosts the ConnId / ICF connector server that your ICF connectors call to reach target systems. You register server instances under Configuration → Target system servers, then select one when you configure each connector under Configuration → ICF Connectors.

The configuration wizard

Available in3.21.0 +

Creating or editing an ICF server is a short guided wizard. The progress bar shows the main steps Configuration (with sub-steps), Deployment (Agent and Direct types only), and Verification. Move between them with Next and Previous, or by clicking a completed node.

1. Configuration
   • General — name the server and pick its Connection type.
   • Connection — the connection details for the chosen type. This sub-step is skipped for Agent (no host or port to enter). For Legacy, enter Host, Port, Key, and optional SSL. For Direct, enter Host and Port (default 8759); a Why this is needed note explains that those values feed the generated agent commands.
2. Deployment — (Agent and Direct types only, after you save) the commands to deploy the containerized agent.
3. Verification — a read-only summary of the configuration and a Test button.

Connection types

The Connection type you choose on the General sub-step (shown above) determines how RAC/M and the connector server reach each other.

Type	Who connects to whom	You provide
Legacy	RAC/M connects to a ConnId server you run	Host, Port, Key, optional SSL
Direct	RAC/M connects inbound to the agent on your host	Host, Port (default 8759)
Agent	The agent opens an outbound tunnel to RAC/M	(nothing — managed by RAC/M)
Internal	Built-in server shipped with RAC/M	(read-only)

Legacy

A stand-alone ICF server that you install, host, and manage yourself. RAC/M initiates the connection to it using the Host, Port, Key, and (optionally) Enable SSL / Server Certificate settings on the Connection sub-step. Use this when the ICF server is directly reachable from RAC/M.

Direct and Agent — SaaS

For RAC/M Identity as a Service (SaaS), you run the connector server yourself as the racm-icf-server-agent Docker (or Podman) container, deployed near your target systems:

• Direct: RAC/M connects inbound to ConnId on the Host and Port (default 8759) you configure on the Connection sub-step. Open that port so RAC/M can reach it.
• Agent: the agent opens a secure outbound tunnel to RAC/M — ideal when the host accepts no inbound connections. There is no host or port to enter, so the Connection sub-step is skipped.

Both modes share the same Deployment step after you save (bearer token, three deployment commands, Docker/Podman runtime toggle). Network setup and whether you enter a host/port differ as above. See Docker agent (SaaS) for the full deployment guide and the environment-variable reference.

Internal

The built-in ICF server shipped with RAC/M. Its configuration is read-only and managed automatically — you can view it (and run Test) but you cannot change its connection settings.

Choosing a type

• Use Legacy when RAC/M can reach a ConnId server you host directly.
• Use Direct (SaaS) when RAC/M can reach the agent host on a published port.
• Use Agent (SaaS) when the agent host accepts no inbound connections.

Verifying the connection

The last step of the wizard, Verification, shows a read-only Summary of the server — name, connection type, host and port when they apply (omitted for Agent), SSL for Legacy and Internal, and Last connection to the system for Agent and Direct servers — and a Test button. Testing is available for every connection type — including read-only Internal servers and saved Agent / Direct servers.

Click Test to check that RAC/M can reach the connector server (directly, through the agent, or over the tunnel). A successful test reports that the connection was established and marks Verification as done in the progress bar; a failed test flags the step in error, so you can go back, fix the configuration, save, and test again.

Connector configuration (choosing a server, connector types, parameters) is described in Connectors.