See more

User's Guide: Authorization

  • Last updated:
  • access_time Reading time:

Authorization

Once a user or an app is authenticated, it still needs the 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.

Table 1: Fortanix Self-Defending KMS User Roles and Actions

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

YES

YES

 

 

 

 

Install and configure Fortanix Self-Defending KMS

YES

 

 

 

 

 

Upgrade software

YES

 

 

 

 

 

View audit logs

 

 

YES 

YES

YES

 

 

NOTE
Note for Account Member Role:
  • Light_Green.png Green_Dark.png - 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.
  • Green_Dark.png - 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 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”.

1.png

                                           Figure 1: Add Quorum Policy For a Group

2.png

                                                             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.
3.png
                                                        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 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.

4.png
                                                 Figure 4: Permission for Security Object

LDAP Authorization for Users

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, 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 Self-Defending KMS 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 Self-Defending KMS 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. AppAuthExtDir_8.png                                                         Figure 5: Import external roles
       
    4. To map the External Role to an App, under the column Group for apps click MAP TO GROUPS. AppAuthExtDir_9.png                                                    Figure 6: Map external roles to group for app
        AppAuthExtDir_10.png                                                         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. Fortanix-SDKMS-Groups12.png                                                         Figure 8: Define permissions for the app

    When an App authenticates successfully, Fortanix Self-Defending KMS 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 Self-Defending KMS that has a key named “key_SoftwareSogning”.
    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 Self-Defending KMS 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 Self-Defending KMS 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 Self-Defending KMS 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 Self-Defending KMS 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 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.

5.png                                                                                              Figure 9: Plugin Example