The login experience

When a user navigates to the Trust Protection Foundation web console, they are presented with a unified login screen. Because the system supports multiple identity directories and delegated authentication methods simultaneously, the login screen uses a dynamic routing process to ensure each user is authenticated correctly.

Automated routing option

Users can sign in by simply entering their username and clicking Continue. Behind the scenes, Trust Protection Foundation automatically performs a lookup to determine which identity connector handles that specific user.

Once the connector is identified, the system checks its configured authentication method.

  • If the connector requires a local password, the user is prompted to enter it directly.
  • If the connector is configured to delegate authentication, the user is automatically redirected to your central identity provider (such as CyberArk Identity or Microsoft Entra ID) to verify their credentials via SAML or OpenID Connect (OIDC).

This automated routing means end-users don't need to know which underlying directory they belong to. Prefix-based usernames (such as scim+saml:username) remain supported if an administrator needs to explicitly direct a login to a specific connector.

SSO provider buttons option

In addition to the username option, the login screen contains a button for each SSO connector. Users click the button to initiate that authorization process. If you have multiple SSO connectors, users can pick the SSO provider they want to use for connecting.

Users who don't know which button to click can use the username option provided, and the system will determine the correct directory to use.

Authenticating with MMC snap-ins and the CodeSigning client

Some Trust Protection Foundation tools, such as the remote MMC snap-ins and the CodeSigning client, cannot perform standard web browser redirects.

To securely authenticate users through these tools (especially users provisioned via SCIM who might not have local passwords) the system uses a device authorization flow:

  1. The tool issues a short-lived device code to the user.
  2. The user opens a standard web browser, navigates to the verification URI, and completes the login process through their identity provider using SSO.
  3. The tool continuously polls the system in the background and grants access once the browser session is authorized.

This flow ensures that these tools never have to store or transmit user passwords.