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 four roles at an account level – an Account Administrator, an Auditor, an Account Member, or a Custom account role. There are three roles at the group level – a Group Administrator, a Group Auditor, or a Custom group role.

The Account Administrator, Auditor, Account Member, Group Administrator, and Group Auditor are called “legacy roles”.

Account Administrator is a Group Administrator for all groups in the account. This role includes all account-level permissions as well as giving users the Group Administrator role in all groups in the account.

Account Member has the ability to create groups, act as quorum policy reviewer and key custodian, and read permissions at the account level. This role does not automatically entitle the user to any group. A user with this role can have selective access to any group if invited.

Account Auditor is a Group Auditor for all groups in the account. This role only entitles the user to read permissions (such as getting audit logs, and so on.) at the account level.

Group Administrator allows the user to do everything in a group.

Group Auditor allows read permissions in a group such as getting security objects.

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.

With the introduction of Custom user roles, it is possible to define a Custom user role with an arbitrary set of permissions. There are two types of Custom user roles: Custom account role and Custom group role. For more details on how to create and manage Custom user roles, refer to User’s Guide: Custom Roles.

Please see the following chart for the actions allowed for every role.

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:
  1. Go to the EXTERNAL ROLES tab to import External Roles from the LDAP directory.
  2. Click SEARCH DIRECTORY to Search the External Roles in the LDAP directory.
  3. Select the external roles and click IMPORT EXTERNAL ROLES. Figure 5: Import external roles
  4. 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:

  1. Create a group called “CodeSigning” in Fortanix DSM that has a key named “key_SoftwareSigning”.
  2. Now create two separate apps, say “app1” and “app2” with authentication method “External Directory” whose authorization is determined by External mapping.
     
     NOTE

     Name the app to have full distinguished name of the app in the Active Directory.
  3. These apps must also already exist in the LDAP directory groups “AMR\DevTeam21” and “AMR\KeyManagementTeam” respectively.
  4. Define “External App Authorizations” by searching for appropriate object class (for example Group) as follows:
     1. 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.
     2. 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.
  5. 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