User's Guide: Authorization

1.0 Introduction

This article describes the authentication and authorization mechanisms of the Fortanix-Data-Security-Manager (DSM).

It also contains the information related to:

• Planned enhancements for these mechanisms.

• Steps the users can take to safeguard their own authentication credentials.

1.1 Fortanix DSM Authentication and Authorization

Fortanix DSM provides access to its functions and APIs to two types of entities – humans (users) and machines (applications). There are many ways to authenticate to Fortanix DSM for both users and applications, which vary in terms of ease of use, integration with existing enterprise IAM (Identity and Access Management Systems), and level of security. Once authenticated, there is an elaborate access control mechanism which controls which entity has authorization to perform which function under what conditions.

2.0 Authorization

After a user or an application (app) is authenticated, it still requires authorization to perform the operations on Fortanix DSM. Fortanix DSM provides detailed authorization controls, that can broadly be categorized into time-based authorization, role-based access control, quorum-based authorization, key-based authorization, LDAP authorization and authorization for plugins.

2.1 Time-Based Authorization

After the successful authentication of a user or an application, Fortanix DSM issues a bearer token that authorizes the user or app to make API calls for the duration of the token’s validity. By default , this token expires after a defined period of inactivity, which can be configured by a system administrator. Additionally, a user can change an application's API key at any time, which immediately invalidates all existing bearer tokens.

2.2 Role-Based Access Control Authorization (RBAC)

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 system roles.

Account Administrator is a Group Administrator for all groups within the account. This role includes all account-level permissions and the ability to assign the Group Administrator role for users in all the groups in the account. An Account Administrator manages other users in a DSM account. This role is intended for a small set of privileged users, such as a member of the IT team, who is authorized to manage the account as a whole. At least one Account Administrator must always be present in the account.

Account Member is a regular member of an account, who is allowed to read as well as modify most objects in the account but does not have administrative privileges in the account. 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 but cannot modify anything. This role is intended for auditors, who only need to observe but not interact with the account.

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 information on how to create and manage Custom user roles, refer to the User’s Guide: Custom Roles.

Table 1: Fortanix Data Security Manager User Roles and Actions

2.3 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”.

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 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 login 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.

Quorum-based authentication ensures that some high-value keys can be protected from misuse by a single rogue Administrator.

2.4 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.

2.5 LDAP Authorization for Applications

Apps with LDAP authentication methods 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.

The authorization method for apps is defined with two possibilities: Native, and External Directory. By default, existing applications will use the Native method. 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, the following parameters are defined:

• directory_id: The LDAP directory to search, supporting the multiple LDAP integrations in each account).

• app_dn: The distinguished name (DN) of the app to search for within the LDAP directory.

NOTE

Apps must also exist in the LDAP compliant directory so Fortanix DSM can use it for determining authorization.

2.5.1 Mapping LDAP Group to Fortanix DSM App

Perform the following steps to map the LDAP group:

1. Navigate to the Groups menu item from the DSM left navigation panel.

2. Go to the EXTERNAL ROLES tab to import the external roles from the LDAP directory.

3. Click the SEARCH DIRECTORY button to search the external roles in the LDAP directory.

4. Select the external roles and click the IMPORT EXTERNAL ROLES button. For more information about LDAP Authorization, refer to the User Guide: Single Sign-On.

   

5. Under the Group for apps column, click the MAP TO GROUPS link to map the external role to all apps in the group.

   

6. On the Mapping to groups dialog box, select the MAP GROUPS FOR APPS option. Select the required group and click the SAVE MAPPING button to save the changes.

   

7. After you map to a group, define the permissions for all apps that are part of this LDAP group using the permissions icon.  

   

   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.

2.6 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.

2.6.1 Mapping LDAP Group to Fortanix DSM User

Perform the following steps to map the LDAP group:

1. Navigate to the Groups menu item from the DSM left navigation panel.

2. Go to the EXTERNAL ROLES tab to import the external roles from the LDAP directory.

3. Click the SEARCH DIRECTORY button to search the external roles in the LDAP directory.

4. Select the external roles and click the IMPORT EXTERNAL ROLES button. For more information about LDAP Authorization, refer to User Guide: Single Sign-On.

   

5. Under the Group for users column, click the MAP TO GROUPS link to map the external role to all users in the group.

   

6. On the Mapping to groups dialog box, select the MAP GROUPS FOR USERS option. Select the required group and click the SAVE MAPPING button to save the changes.

   

7. After you map to a group, you can assign or change the group role for all users that are part of this LDAP group.

   

   When a user authenticates successfully, Fortanix DSM will query the corresponding LDAP directory using a service account to find the user's group memberships. Based on the defined 'External User Authorization,' DSM determines the following entitlements for the user:

   • Groups the user has access to.

   • Operations the user can perform on security objects in applicable groups.

2.7 Plugins-Specific Authorization

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.

3.0 Access Control for Keys

A key (or security object) in Fortanix DSM can be managed by a user or an application. This includes actions such as generating a key, importing a key, disabling a key, changing permissions on a key, or deleting a key. A key, however, can be used for cryptographic operations only by an application. A key resides in a group in Fortanix DSM, and it can be accessed only by users and applications that also belong to that group.

A typical use case for Fortanix DSM in a large enterprise may involve providing access to keys in several applications which operate on the same encrypted data set but are owned by separate business units or product owners. Fortanix DSM makes it very easy for applications to either share keys or keep access to their set of keys isolated.

• Key sharing between applications: Sharing keys between applications is as easy as making the applications member of the same group. An application in Fortanix DSM may be a member of multiple groups and has a default group which is used by the APIs if no group is explicitly specified. The application has full access to all the keys in all the groups it belongs to. For example, Application A has full access to all the keys that Application B generates due to its membership in Group B.

• Partitioning of key space between applications: Fortanix DSM also allows applications to keep their key space separated by making them members of disjoint set of groups. For example, Application C does not have access to any of the keys available to Applications A and B as it does not share any group with those applications.

The group membership of applications is determined either by the Account Administrator (AA), or the Account Member (AM) if the AM has a Group Administrator role for the group, he is providing access to. It is imperative on the Fortanix DSM users to ensure how applications are provided access to keys in Fortanix DSM.