Authorization

Once a user or an app is authenticated, it still needs authorization to perform an operation on Fortanix Self-Defending Key Management Service (KMS). Fortanix Self-Defending KMS 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 Self-Defending KMS, a bearer token is granted which authorizes the user or the app to make API calls until 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 Self-Defending KMS 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 Self-Defending KMS 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.

 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 - 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 Self-Defending KMS 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 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 Self-Defending KMS 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.

Key Based Authorization

In Fortanix Self-Defending KMS 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.

LDAP Authorization

Fortanix Self-Defending KMS can also leverage group membership in an LDAP-compliant directory to assign users to groups dynamically. This requires mapping LDAP groups to Fortanix Self-Defending KMS groups which are achieved by defining external roles in Fortanix Self-Defending KMS and mapping these external roles to Fortanix Self-Defending KMS groups. After a user authenticates to Fortanix Self-Defending KMS using LDAP, Fortanix Self-Defending KMS retrieves the list of directory groups that the user belongs to and if those groups are mapped to Fortanix Self-Defending KMS groups, the user is added to the mapped Fortanix Self-Defending KMS groups for the current session.

For more information about LDAP Authorization, please refer to "User Guide: Single Sign-On.

Authorization for Plugins

Similar to the Fortanix Self-Defending KMS apps, the Fortanix Self-Defending KMS 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.