Authorization and Role Management

Control Center

FTM’s Data Setup Utility (DSU) must be run to grant application access to users. For more information, see Setting up and running the DSU.

The Control Center’s default sign-in process uses the ODIC provided user ID to query the FTM’s internally stored user group membership. The FTM Control Center then displays the interface based on the user’s group membership and the permissions associated with those groups. Organizations can customize the default process by implementing a Login User Exit. This feature allows them to modify a user’s group membership before the interface is displayed based on the updated group membership. For more information about role-based authorization and user exits, see Integrate with OIDC authorization.

For more information about Control Center authorization, see Common Services security - Authorization.
Note: Regularly review all authorizations and ensure that the application access matches the intended access for a user or a group.

OAC and Legacy APIs

Application role
FTM uses a simplified role-based access model for OAC and legacy APIs. FTM relies on a single application security role: FTM.Role.Logon. This role controls basic login access to FTM’s functions.
Login access role
  • FTM.Role.Logon: A user must be granted (mapped to) FTM.Role.Logon to sign in to the OAC or Control Center. For more information, see The FTM.Role.Logon security role, user groups, and authorization.
  • Default Mapping: By default, FTM maps all authenticated users to the FTM.Role.Logon role in the application’s configuration. (In Liberty’s default application binding for FTM OAC, FTM.Role.Logon is bound to the special subject ALL_AUTHENTICATED_USERS, meaning anyone who passes authentication is granted that role.
    Note: This default setting is convenient for initial setup but should be customized for production environments.

    For more information about OAC security, see OAC security.

Enable FTM user access and authorization
Mapping users or groups to the FTM.Role.Logon role is done through Liberty security role bindings. In a basic registry scenario, this means listing authorized users under an <administrator-role> or mapping a group to the role. In an LDAP scenario, it means to map an LDAP group (or groups) to the role in the Liberty configuration. For example, you might create an LDAP group that is named FTMUsers and map it to the FTM.Role.Logon role. Only users of that group can log in to FTM.
After a user is assigned the FTM.Role.Logon role, fine-grained authorization within FTM is handled by the FTM OAC through an internal permissions model. The OAC defines various resources and operations such as pages and actions and uses a group-based permission model to control access.
In practice, after a user is authenticated and has the FTM.Role.Logon role, their membership in OAC-defined groups determines their access to resources based on the permissions that are linked to those groups.