User's Guide: Authorization

Last Updated: November 26, 2021 05:21

FORTANIX DATA SECURITY MANAGER AUTHENTICATION AND AUTHORIZATION USER GUIDE.pdf
(4 MB)

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.

**Table 1: Fortanix Data Security Manager User Roles and Actions**
ACTIONS	SYSTEM ADMIN	SYSTEM OPERATOR	ACCOUNT ADMIN	ACCOUNT MEMBER	ACCOUNT AUDITOR	APP	ADMIN APPS
Add and manage applications			YES	YES			YES
Add and manage users, change user roles			YES				YES
Create accounts			YES
Manage accounts			YES				YES
Create and manage groups			YES	YES			YES
Cryptographic operations						YES
Create and manage plugins			YES	YES			YES
Invoke plugins			YES	YES		YES	YES
Key management (add, edit, delete keys)			YES	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		YES

NOTE

Note for Account Member Role:

- 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 - Add and manage applications, 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.

NOTE

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

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