Permissions in Passwords and Projects

Previous versions of Team Password Manager (lower than V6) had a very simple security model, mainly based on granting access to passwords and projects. V6 security model is more complete and defines permissions, which allow a better definition of access to passwords and projects.

This document describes the security/permissions model in Team Password Manager V6 and up.

Permissions in Projects

A user/group can have the following permission on a project:

• Not defined/set: the permissions on a project are not set. The effective permission on a project is then calculated from groups. If the resulting permission from groups is also not defined, no access is given.
• No access: the user/group doesn't have access to the project or any of its passwords. The name of the project may be seen if the user/group has access to any of its passwords.
• Traverse: the user/group can see the project name only. Used to traverse the project to its subprojects (subprojects can be seen in the projects tree) and for project managers/it users create subprojects in it without having access to any of their data and passwords.
• Read: the user/group can read project data and download files and see the passwords of the project (but not create).
• Read / Create passwords: the user/group can read project data and download files, read the passwords of the project and create passwords in it.
• Read / Edit passwords data: the user/group can read project data and download files, and edit data from its passwords. Can also create passwords.
• Read / Manage passwords: the user/group can read project data and download files, and manage its passwords. Can also create passwords.
• Manage (default for the creator): total access and control over the project and its passwords. Normal users with manage permission cannot move the project to another parent, create subprojects inside it or delete it. Only leaf projects can be deleted.
• Inherit: inherits the permission set in the parent project. Note that this doesn't mean that it will inherit the effective permission in the parent project, but the one that's set there. This permission doesn't apply to projects that don't have a parent (first level or root projects).

To define permissions in a project you need to have "Manage" permission on it. Permissions are then set using the "Security" button in the project screen:

Permissions can be defined globally for all the users (which will also apply to new users) or to individual users and groups.

Permissions in Passwords

A user/group can now have the following permissions on a password:

• Not defined/set (default): the permissions on a password are not set. When this happens, the permissions are defined by group membership or from the project.
• No access: the user/group can't see anything from the password (not even the name).
• Read: the user/group can read data from the password and download files.
• Edit data: can edit data and upload files but can't do anything else with the password (set custom fields, lock, delete, etc.).
• Manage: total access and control over the password. Users/groups with manage permission on the project have this permission on the password.

Notes:

• If a user is a manager in the password's project, he/she has by default "Manage" permission on the password, and this cannot be overriden in the password.
• Linked passwords are read only, so even if a user has edit/manage permission on the password, they cannot be edited.

To define permissions in a password you need to have "Manage" permission on it. Permissions are then set using the "Security" button in the password screen:

Manager for new passwords

Until v. 11.141.247, the main manager for new passwords was always the user who created the password.

Since v. 11.141.247 you can define who is going the be the main manager for new passwords. There are three options:

• The user who creates the password (default).
• The manager of the project of the password.
• A specific user, which you need to select.

You can define this in Settings (top menu), and then "Manager for New Passwords".

Note that this setting also applies when importing and creating passwords via the API.

Precedence of Permissions

When calculating effective permissions on a password or project, this is taken into consideration:

1. A user permission takes precedence over a group permission.

Example (project): G1 (manage), G2 (access), User (no access) => the user has no access over the project
Example (password): G1 (read only), G2 (edit data), User (manage) => the user can manage the password

2. If there are different permissions in different groups, the one with most access takes precedence.

Example (password): G1 (read only), G2 (edit data) => the user can edit data

3. A specific password permission takes precedence over the one set in the project for its passwords. Exception: if a user has "manage" permission over the project of the password, this takes precedence.

Example (project): user has read / edit data permission => can edit data for all passwords
Example (password X in project): user has no access permission

Result: the user will be able to edit the data for all the passwords except for password X, on which he doesn't have access.

Editing Policy Disappears

Versions below V6 had a global setting called "Editing Policy" that regulated how users could manage a password: if anyone that had access to a password could manage it or if only its manager could manage it.

This setting in V6 disappears because this can be controlled explicitly in each project/password using the provided permissions.

If upgrading from previous versions, the upgrade process will take care of assigning the correct permissions depending on your editing policy setting value.