Managing system permissions

In Trust Protection Foundation you need to understand the distinction between authentication and authorization:

  • Authentication (Who you are): Your central identity providers (like Active Directory, Okta, or Microsoft Entra ID) provide user identities and verify their credentials during login.
  • Authorization (What you can do): Trust Protection Foundation entirely controls permissions internally. Authentication does not determine what a user can see or do inside the system.

Trust Protection Foundation uses a least-privileged model. By default, local users have only the Read permission, and external users provisioned via SCIM or Active Directory have no permissions. Even if a user successfully authenticates via Single Sign-On, they will not be able to view or manage certificates, credentials, or folders until a Trust Protection Foundation administrator explicitly grants their identity permissions to those specific objects.

How permissions work

All administrative access is managed at the object level. Every object in the system (including folders, certificates, devices, and credentials) has a dedicated Permissions tab.

When you assign a permission to a user or group on a parent folder, those permissions automatically flow down and are inherited by all subordinate objects within that folder. Because of this inheritance, it is a best practice to assign permissions to groups at the folder level, rather than assigning permissions to individual users on individual objects.

Auditing and troubleshooting permissions

Because Trust Protection Foundation uses a least-privileged model, external users provisioned via SCIM or Active Directory default to having no permissions. If a user successfully logs in but cannot see expected folders or objects, use the following tools to audit their access.

View all permissions granted to a specific user (Entitlements)

You can view a centralized list of every object a user has been explicitly granted access to. This is particularly useful for closing security gaps when an employee transfers to another role or leaves the company.

  1. In the web console, click your user account icon, and then click My Teams.
  2. Use the filters to search for the specific user or team, and click their name.
  3. Click the Permissions Granted link on the left. This screen displays every object where the identity (or a group the identity belongs to) has been granted explicit permissions.

Troubleshoot why a user has (or lacks) access to an object

Because permissions flow down the folder tree, a user might inherit access from a parent folder or a group membership. If you need to know exactly where a user is getting their permissions for a specific object, you can use the Troubleshoot Permissions tool.

  1. Open the specific object (such as a certificate or folder) and click Permissions in the sidebar.
  2. In the Cumulative Permissions section, click Troubleshoot Permissions.
  3. Enter the identity you want to review. The system will display the effective permissions and show you the exact level in the folder structure where the permissions were added or removed, allowing you to trace the inheritance.