Authorization
Once a user or an app is authenticated, it still needs authorization to perform an operation on SDKMS. SDKMS 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 SDKMS, 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
SDKMS 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 member of.
At system level, SDKMS 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.
|
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 |
|
|
|
|
Cryptographic operations |
|
|
|
|
|
YES |
|
Create and manage plugins |
|
|
YES |
YES |
|
|
|
Invoke plugins |
|
|
YES |
YES |
|
YES |
|
Key management (add, edit, delete keys) |
|
|
YES |
YES |
|
YES |
|
Monitor SDKMS |
YES |
YES |
|
|
|
|
|
Install and configure SDKMS |
YES |
|
|
|
|
|
|
Upgrade software |
YES |
|
|
|
|
|
|
View audit logs |
|
|
YES |
YES |
YES |
|
Quorum-Based Authorization
SDKMS 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 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 SDKMS 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 SDKMS 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
SDKMS can also leverage group membership in an LDAP-compliant directory to assign users to groups dynamically. This requires mapping LDAP groups to SDKMS groups which is achieved by defining external roles in SDKMS and mapping these external roles to SDKMS groups. After a user authenticates to SDKMS using LDAP, SDKMS retrieves the list of directory groups that the user belongs to and if those groups are mapped to SDKMS groups, the user is added to the mapped SDKMS 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 SDKMS apps, the SDKMS 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.
