Roles, RBAC and Permissions
Keeper's Least-Privilege Role permissions are both flexible and powerful.
Last updated
Keeper's Least-Privilege Role permissions are both flexible and powerful.
Last updated
In the Keeper architecture, Roles and Teams are separate but related concepts.
Roles define permissions, controls what features and security settings apply to users and manages administrative capabilities.
Teams are used for sharing privileged accounts and Shared Folders among users within the vault. Teams can also be used to easily assign Roles to entire groups of users to ensure the consistency of enforcement policies across a collective group of individuals (more on teams here).
Role-based Access Controls (RBAC) provide the organization the ability to define enforcements based on a user's job responsibility as well as provide delegated administrative functions.
The number of roles a business creates is a matter of preference and/or business need. At its simplest configuration the default role Keeper Administrator (under the Root Node) is applied to the initial administrator who set up the Keeper account for the organization as well as any other user who you wish to grant full admin rights. Roles can be assigned enforcement policies, and they can be assigned administrative permissions for access to the admin console.
We strongly recommend adding a secondary admin to the Keeper Administrator role in case one account is lost or no longer accessible. The creation of additional roles such as a General Employee role, is not required but highly encouraged.
Watch the video below to learn more about role-base access controls.
You can add roles manually through the Admin Console, automatically mapped via SCIM, created with Keeper Commander, or assigned from Active Directory / LDAP via the Keeper AD Bridge.
To add roles manually, select the Roles tab. There you can navigate to the specific node you would like the role to be assigned to. Select the + button to add a role. Verify or select the appropriate Node in the organization tree (or select the Root Node). Enter the name of the role you are creating then click Add. After the role has been created, you can configure the role enforcement policies, select the users to assign the role and set administrative permissions.
First, select the role you would like to configure. Click the Enforcement Policies button. Observe the enforcement policies are are structured into the following areas:
Login Settings
Two-Factor Authentication (2FA)
Platform Restriction
Vault Features
Sharing & Uploading
KeeperFill
Account Settings
Allow IP List
Keeper Secrets Manager
Transfer Account
For more information about Enforcement Policies, click here.
Team-to-role mapping allows organizations to use their existing identity provider to assign users directly into Teams that can be assigned custom Roles. With team-to-role mapping, a user who is a member of a team who is assigned to a role will assume the enforcements of the given role. That user can be a member of the role more than once, once via user-role membership and again via user-team-role memberships if any exist.
To use team-to-role mapping, administrators simply assign a role to an entire Team, as opposed to individual users, and use Role Enforcement Policies to establish different requirements and restrictions for each Team.
Currently Keeper does not allow mapping of administrative roles to teams, in order to prevent an admin from inadvertently elevating permission of a user. This feature is being considered for a future release.
When setting up SCIM (System for Cross-Domain Identity Management) in the Keeper Admin Console, roles can be automatically assigned instead. By default, SCIM groups map to Keeper teams. SCIM group names that start with this optional prefix will instead map the assignments to a role.
It is important to note, that if a user is a member of multiple roles or a team with differing role enforcements, all enforcements must be satisfied for all the roles the user is a member of. Keeper implements least-privileged policies, so when a user is a member of multiple roles, their net policy is typically most restrictive, but this can vary depending on the enforcement.
For example: Role A does not allow sharing to anyone. Role B does not allow sharing outside of the enterprise. The user will be unable to share to anyone because Role A (least privilege) does not allow it.
The next section documents each of the available enforcement policies.
