Project administrators can perform audits on user access and see reports per user that show policies used by each user and their access to datasets and projects.

Authentication

Tamr uses local database-backed authentication and authorization by default.

Tamr can also use:

• LDAP to authenticate and authorize users. If you have groups configured in LDAP that you also want to use in Tamr, you can map your LDAP groups to local groups that you create in Tamr. For more information, see LDAP Authentication and Authorization.
• SAML for SSO. See SAML Authentication.

Authorization

The authorization model in Tamr centers around the relationships between users, resources, and roles. Use the following concepts to create meaningful access control scenarios in your team.

Access Control Concepts

In the Tamr access control model, we rely on:

• A user is an authenticated user in Tamr.
• A group is a set of users.
• A privilege is a type of permission on a resource. For example, a read permission on a specified dataset.
• A role is a set of preconfigured privileges. Roles define a set of access privileges to a resource. Tamr has two predefined roles: curator and reviewer. For example, a reviewer role has read access to a project named ABC, and a curator role has read and write (update) access to the same project.
• An administrator can perform any action. An administrative user named "admin" is created when you install Tamr. You may create additional administrative users. A Tamr administrator can assign one or more roles to users, groups, or projects.
• A resource is a specific dataset or a project.

Use these constructs to create authorization policies in Tamr. Each policy establishes one or more mappings between users or a group of users, roles, and Tamr resources. For example, you can create a policy Ethan-read-ds for a user Ethan that provides him with a read permission to a dataset with ID=456.

Policies

You can create an authorization policy to map users or groups to predefined roles. In the same policy, you can add projects and datasets associated with the project. It is useful to create a policy for each project.
Each policy has a name, description, a mapping from a list of roles and permissions to a specific user or group, and a set of resources to which this policy applies.

The users or groups of users to which a policy applies are referred to as members of that policy.

Policies have these characteristics:

• Policies on datasets control access to them by users and groups, in any project.
• Policies on projects affect which users and groups have access to projects, and which datasets these project can read. Derived datasets inherit policies you use for projects.
• A user can add a dataset to a particular project only if the policy:
• Allows the user "read access" to the dataset
• Allows the user "write (update) access" to the project
• Allows the project "read access" to the dataset.
• A default policy exists that grants all projects read access to all input datasets. In a typical deployment, you don't need to manage project access to datasets. If you require more restrictive access, we recommend removing the default policy and replacing it with custom policies that meet the needs of your team.

📘

If you create a new dataset or a new project, nobody has access to it by default. To enable access, create a policy and attach it to the dataset or project. You can also attach an existing policy to your new dataset or project, to allow access.

Example

Consider a deployment with two users, Anne and Bob.

• Anne plans to master some data in a project named "Master Project" using datasets "Input Data A" and "Input Data B" that have already been uploaded by an administrator.
• Bob is a subject matter expert who is advising Anne.

In this situation, the administrator creates a new mastering project named "Master Project", and a new authorization policy. In this policy, the administrator makes these choices:

• Assigns "Anne" the "Curator" role
• Assigns "Bob" the "Reviewer" role
• Adds the "Master Project", the "Input Data A", and the "Input Data B" datasets as resources to the policy.

As a result:

• Anne can perform all project-related actions. She can add the two datasets as inputs to the project, because:
  1. She has write (update) access to the project.
  2. She has read access to both of the input datasets. (She also has write access to them.)
  3. The default policy grants all projects read access to all datasets, so the project has the required read access to both input datasets.
• Bob can provide feedback and perform other reviewer actions in the new project. Bob cannot add the two datasets as input, because he is assigned a reviewer role, and this role does not have write (update) access to the project.

Creating and Managing Access Policies

Before you create policies, create users and groups.

To create a policy:

1. Navigate to Policies and choose Create New Policy.
   Each policy you create shows its name, the members of the policy (users and/or groups) and their assigned roles, and the resources to which this policy is attached (projects and datasets).

You can manage each policy by adding or removing members or resources, or changing the role assigned to a policy member. You can also edit, duplicate, or delete an existing policy.

Using Policies for Restricted Access

By using access control policies, an instance administrator can grant access to a subset of data to a subset of users. To implement this scenario, use the following tips:

• Decide which projects will contain which datasets. For example, you may have two projects, where project A includes all of your input datasets, and project B includes some of the input datasets and does not provide read access to other input datasets.
• Create policies and attach them to these projects. The default policy exists that allows all projects to have read access to all datasets. In the restricted access scenario, we recommend that you delete it and replace it with a set of policies required by your team and organization.
• To ensure that users who have access to restricted input datasets do not accidentally add them to unrestricted projects, you can create a policy that does not allow such access. In the policy, the project resource should not include read access to any restricted input datasets. Attach this policy to a restricted project and test it. The policy should prevent users with access to both projects from accidentally adding restricted input datasets to an unrestricted project.