Authentication and Identity Management

The Control Center integrates with enterprise identity providers (IdPs) using the OpenID Connect (OIDC) protocol to delegate authentication. Control Center does not verify or enforce any authorization claims, such as user roles or groups, that may be embedded in the OIDC token. This authorization handling is performed by the Control Center application.

Configure OIDC Integration for Control Center

To enable OIDC-based authentication for the Control Center, complete the following steps:
  1. Register an OIDC client for FTM in the enterprise IdP.
  2. Create a corresponding Red Hat® OpenShift® secret to store the OIDC client secret securely. For more information, see Create an OIDC secret for your FTM installation on Red Hat OpenShift.
  3. Configure the OIDC integration in the FTM custom resource (CR) by specifying the OAuth client ID, the OIDC issuer URL, and the secret defined earlier. For more information, see Configuration parameters for the FTM offerings.
  4. Run FTM’s Data Setup Utility (DSU) to grant application access to users. By default, users in the enterprise IdP's user registry cannot authenticate or start a session with the FTM application, even after OIDC integration is successfully configured. For more information about configuring users in Data Setup Utility (DSU), see Configuring users.
  5. Access the Control Center UI to begin the login process. If the system is configured correctly, it redirects the user to the IdP login page. After a successful login, the IdP issues an OIDC ID token. FTM accepts the token and grants access. For more information, see Authentication.
  6. Verify that the IdP’s OIDC configuration (redirect URIs, scopes, and other settings) meets the FTM application’s requirements.
  7. Store the OIDC client secret securely in the Red Hat OpenShift secret. Avoid storing it in plain text in the custom resource (CR).

Operations and Administration Console (OAC)

The OAC is a web application that runs on WebSphere Liberty and is used for administrative tasks. For more information, see OAC security and OAC security data model.

Unlike the Control Center, OAC does not include a login screen or support OpenID Connect (OIDC). Instead, it uses Liberty’s built-in authentication. By default, FTM’s Liberty instances use a basic user registry (an XML file with usernames and passwords) for authentication. A predefined administrative user account (fxhadmin) is available in this registry. The password for fxhadmin is auto-generated and stored in the main FTM application secret, typically under the FXH_PASSWORD key. At runtime, the password is injected into the Liberty configuration. For more information about Liberty authentication, see WebSphere Application Server Liberty overview and Authenticating users in Liberty.
Note: To log in to OAC for the first time, use the fxhadmin account and the password that is stored in FXH_PASSWORD. After logging in, change the password immediately to meet your organization’s security policies.

For production environments, it is recommended to replace the basic registry with an enterprise user registry (LDAP) that aligns with your organization’s identity management policies. WebSphere Liberty supports several authentication methods that can be configured for OAC. For more information, see Basic registry authentication for FTM, Custom LDAP registry authentication for FTM, and Client certificate authentication for FTM.

RESTful APIs and SOAP Web Services

FTM exposes programmatic APIs (REST and SOAP) for integration. These services are hosted on Liberty and share the same authentication setup as the OAC. By default, they use the basic user registry. For more information, see Basic registry authentication for FTM.

In hardened deployments, configure Liberty security to use more robust authentication methods according to your security policies. Liberty supports various authentication methods, such as LDAP, federated registries, client certificates. For more information, see Custom LDAP registry authentication for FTM, and Client certificate authentication for FTM.

The following are examples of FTM API endpoints leveraging these methods:
  • Enable client certificate authentication for specific SOAP endpoints.
  • Use a custom LDAP registry for REST requests if it is configured in Liberty.

For more information about securing RESTful web services, see RESTful web services security.

For more information about user authentication in Liberty, see Authenticating users in Liberty.

Data Setup Utility

FTM’s Data Setup Utility (DSU) must be run to grant application access to users. For more information about importing user and user group information into FTM, see Run the Limited DSU Import.

User Exits

FTM provides extensibility through user exits, which allow to customize authentication and authorization. User exits can be used for the following:
  • Enforce additional authorization logic based on custom attributes.
  • Map authenticated users to internal roles or permissions dynamically.
  • Integrate with existing compliance enforcement, entitlement services, or audit platforms.
  • Apply fine-grained access control that external identity providers do not handle.

For more information, see Integrate with OIDC authorization and Sample user exit.