Authorization
Once a user or an app is authenticated, it still needs authorization to perform an operation on Fortanix Data Security Manager (DSM). Fortanix DSM provides fine-grained authorization controls that can broadly be categorized into “time-based authorization”, “role-based access control (RBAC)”, “quorum-based authorization”, “key-based authorization”, “LDAP authorization” and “authorization for plugins”.
Time-Based Authorization
When an application or a user authenticates to Fortanix DSM, a bearer token is granted which authorizes the user or the app to make API calls while the bearer token is valid. In the current implementation, the bearer token expires after a period of inactivity. A System Administrator can configure this period. A user may also change the API key of an app at any time which invalidates any existing bearer tokens immediately.
Role-Based Authorization
Fortanix DSM provides three roles at an account level – an Account Administrator, an Auditor, or an Account Member. There are two roles at the group level – a Group Administrator, and a Group Auditor. An Account Administrator is a Group Administrator for all groups in the account, while an Account Auditor is a Group Auditor for all groups in the account. An Account Member may have selective roles in each group they are a member of.
At the system level, Fortanix DSM provides two more roles – a System Administrator, and a system operator. They roughly map to an Administrator and an Auditor (read-only) role at the account level.
Please see the following chart for the actions allowed for every role.
| ACTIONS | SYSTEM ADMIN | SYSTEM OPERATOR | ACCOUNT ADMIN | ACCOUNT MEMBER | ACCOUNT AUDITOR | APP |
|---|---|---|---|---|---|---|
| Add and manage applications | YES | YES | ||||
| Add and manage users, change user roles | YES | |||||
| Create and manage accounts | YES | |||||
| Create and manage groups | YES | YES | ||||
| Cryptographic operations | YES | |||||
| Create and manage plugins | YES | YES | ||||
| Invoke plugins | YES | YES | YES | |||
| Key management (add, edit, delete keys) | YES | YES | YES | |||
| Monitor Fortanix Data Security Manager | YES | YES | ||||
| Install and configure Fortanix Data Security Manager | YES | |||||
| Upgrade software | YES | |||||
| View audit logs | YES | YES | YES |
- When we add a user with "Account Member" role and assign this user to a group as Group Admin or Group Auditor, then this user is allowed to do operations such as - Create and manage groups, Create and manage plugins, Invoke plugins, Key management (add, edit, delete keys), and View audit logs.- - When we add a user with "Account Member" role without assigning the user to a group, then this user is allowed to do operations such as - Create and manage groups, Key management (add, edit, delete keys) for the keys inside the group created by the Account Member, and View audit logs.
Quorum-Based Authorization
Fortanix DSM allows a quorum policy to be set on a group in an account, such that every security-sensitive operation in the group requires a quorum approval to be obtained.
- The quorum policy is defined as a conjunctive or disjunctive set of quorum groups defined in the form of (M of N approvers). It is the minimum number of approvals required among the total number of Group Administrators for the group.
- A policy may also include the specific identity of users who form the quorum, and not just the size of the quorum.
- An advanced policy could be a combination of quorum rules. For example, a quorum could be defined as “one out of users A and B”, and “three out of users C, D, E, F, and G”.
Figure 1: Add Quorum Policy For a Group
Figure 2: Adding a Quorum Policy
Quorum Approval Workflow
Any sensitive operation performed in the group (for example: using a key for cryptographic operations, modifying the quorum policy, deleting/updating a group, and so on) triggers a quorum event where notification is sent to all the approvers in the quorum group and a workflow is triggered.
- This involves sending a notification to all users who can grant approval. This is done by sending emails, as well as generating a task in the approver’s accounts, which they see on the dashboard as soon as they log in to their Fortanix DSM account.
- The users can then grant approvals from the UI. The sensitive operation is blocked until the quorum is met.
- Once a quorum is reached, the operation is performed, and the quorum approval is written into the audit logs including the names of users who approved the request.
Figure 3: Quorum Approval Tasks
Quorum-based authentication ensures that some high-value keys can be protected from misuse by a single rogue Administrator.
Key Based Authorization
In Fortanix DSM when a security object (key) is created, there are some crypto operations that are permitted with the security object. These operations can be defined during the creation of a security object.
Figure 4: Permission for Security Object
LDAP Authorization for Users
Fortanix DSM can also leverage group membership in an LDAP-compliant directory to assign users to groups dynamically. This requires mapping LDAP groups to Fortanix DSM groups which are achieved by defining external roles in Fortanix DSM and mapping these external roles to Fortanix DSM groups. After a user authenticates to Fortanix DSM using LDAP, Fortanix DSM retrieves the list of directory groups that the user belongs to and if those groups are mapped to Fortanix DSM groups, the user is added to the mapped Fortanix DSM groups for the current session.
For more information about LDAP Authorization, refer to "User Guide: Single Sign-On.
LDAP Authorization for Applications
Apps with LDAP authentication method can have either normal authorization or use LDAP authorization. Authorization for an application extends the App’s authorization model to tie it to group membership in an LDAP compliant directory.
We define an authorization method for apps with two possibilities: Native, and External Directory. Existing apps will default to Native. For the app with External Directory authorization, the group membership and authorization of the app are determined dynamically based on its group membership in LDAP.
For the External Directory option, we define the following parameters:
directory_id: which LDAP directory to search (we support multiple LDAP integrations in each account).app_dn: The distinguished name of the app to search for.
Similar to the “External Role” described in the previous section, we have “External App Authorization” which will do the following:
- Map LDAP group to a Fortanix DSM group. To Map LDAP group:
- Go to the EXTERNAL ROLES tab to import External Roles from the LDAP directory.
- Click SEARCH DIRECTORY to Search the External Roles in the LDAP directory.
- Select the external roles and click IMPORT EXTERNAL ROLES.
Figure 5: Import external roles - To map the External Role to an App, under the column Group for apps click MAP TO GROUPS.
Figure 6: Map external roles to group for app 
Figure 7: Group mapped
- Once you map to a group, define the permissions for all Apps that are part of this LDAP group using the permissions icon.
Figure 8: Define permissions for the app
When an App authenticates successfully, Fortanix DSM will query the corresponding LDAP directory using a service account to find its group memberships and then using the defined “External App Authorization” it determines the following entitlements for this App:
- Groups that it has access to
- Operations that it can perform using security objects in applicable groups.
For example:
- Create a group called “CodeSigning” in Fortanix DSM that has a key named “key_SoftwareSigning”.
- Now create two separate apps, say “app1” and “app2” with authentication method “External Directory” whose authorization is determined by External mapping.
NOTEName the app to have full distinguished name of the app in the Active Directory. - These apps must also already exist in the LDAP directory groups “AMR\DevTeam21” and “AMR\KeyManagementTeam” respectively.
- Define “External App Authorizations” by searching for appropriate object class (for example Group) as follows:
- Search for the group “AMR\DevTeam21” and map it to the Fortanix DSM group “CodeSigning”, and set only the “Sign” permission for the app such that the app can only perform the Sign operation and will disallow other operations on the Security Object.
- Similarly, search for the group “AMR\KeyManagementTeam” and map it to the Fortanix DSM group “CodeSigning”, and set only the “UnWrap” permission for the app such that the app can only perform the UnWrap operation and will disallow other operations on the Security Object.
- When the “app1” tries to authenticate to Fortanix DSM using the applicable authentication mechanism, it will dynamically determine authorization entitlements for this app by querying the LDAP directory. So, “app1” will show up with membership of group “AMR\DevTeam21” and will have the entitlement to use the Security Objects in Fortanix DSM group “CodeSigning” but will only be used to perform “Sign” operation using those objects.
This way LDAP directory continues to be the source of truth for authorization and by removing an application from a group in LDAP directory, the authorization can be easily revoked.
Authorization for Plugins
Similar to the Fortanix DSM apps, the Fortanix DSM plugins are entities that may be in multiple groups.
A plugin may use a security object if and only if it shares a group with the security object.
An app, user, or another plugin may invoke a plugin if and only if it shares a group with the plugin.
In a typical configuration, a plugin will be in a privileged group A that contains the keys the plugin will use, as well as a less privileged group B that contains the apps that will invoke the plugin.
Since the apps in the less privileged group B are not in the privileged group A, the apps may only access the keys by invoking the plugin, which may enforce access control policies, invariants, and so on.
Figure 9: Plugin Example