Redundant authentication handling for AF Clients

Note: This topic only applies to customers who are using the AVEVA Identity Manager (AIM) to handle single-sign on using claims-based authentication for AVEVA PI Server 2024 R2. AVEVA PI Server 2024 does not make use of the Redundant SSO Server functionality within AVEVA Identity Manager.

AF Clients and servers use authentication endpoints provided by AVEVA Identity Manager (AIM). These endpoints include the System Management Server (SMS) and any configured redundant AIM nodes. When the SMS is temporarily unavailable, clients continue to obtain tokens from an available redundant node. This capability is sometimes referred to as redundant single sign-on.

For setup steps, see Configure the AVEVA Identity Manager for redundant deployments.

Purpose of redundancy

Redundant authentication improves resilience in the following ways:

• Maintains continuity when the SMS is offline

• Insures most responsive AIM node is utilized for reliable authentication

  Note: Redundant authentication is supported for AF Server and Asset Framework Software Development Kit (AF SDK)–based clients in environments that use AIM for OIDC. For other PI components, refer to each component’s release notes to confirm support.

How it works

AF Server and AF SDK handle endpoint selection and failover as follows:

• After a machine is configured as a redundant AIM node, it synchronizes configuration and token-issuance capabilities from the SMS.

• AF Server retrieves the list of AIM endpoints (SMS and redundant nodes) from the SMS and shares it with AF SDK–based clients during the connection handshake. AF SDK refreshes this list every 24 hours by default.

• When first attempting to connect, the AF SDK reaches out to every known AIM endpoint to load its discovery document. The AIM endpoint that responds first is treated as the best endpoint and gets used for all subsequent calls. If the endpoint becomes unavailable, the AF SDK automatically fails over to the next best node, and no manual client configuration is required.

Typical workflow

The following steps provides an example of a typical workflow of redundant authentication handling for AF Clients:

1. Configure one or more machines as redundant AIM nodes by connecting them to an existing SMS using the Configurator utility.

2. Register clients with the SMS; at runtime they can request tokens from the SMS or any available redundant node.

3. When a client initiates a workflow, the AF SDK requests a token from the selected endpoint. If that endpoint fails, the AF SDK selects the next best node and retries automatically.

4. The selected node issues the token on behalf of the SMS.

Key considerations

Keep the following points in mind:

• Clients can be registered only with the SMS, not with redundant nodes.

• A token request is handled by one node at a time; if that node fails, the client obtains a new token from another node.

• Redundant nodes can operate independently if they’ve synchronized the latest client and resource configurations from the SMS.

• All configuration changes, such as client registration or identity providers (IdP) updates, must be performed through the SMS. Redundant nodes don’t accept configuration requests.