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 Core 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

Tamr Core's authorization model is based on the relationships between users, resources, and roles. Use the concepts described in this topic to create meaningful access control scenarios for your team.

Access Control Model

The Tamr access control model relies on:

Resources: Specific datasets or projects.
Users: Authenticated users in Tamr Core.
Groups: Sets of users.
Privileges: Types of permissions on a resource. For example, a privilege is read permission on a specified dataset.
Roles: Set of preconfigured privileges. Roles define a set of access privileges to a resource. Tamr Core's non-admin roles are curator, verifier, 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.
Admins: Users who can can perform any action. An admin user named "admin" is created when you install Tamr Core. You can create additional admin users. Admins can assign one or more roles to users, groups, or projects.

Use these constructs to create authorization policies in Tamr Core. Each policy establishes one or more mappings between users or user groups, roles, and resources.

For example, you might create a policy Ethan-read-ds for a user Ethan that provides him with read permission to a dataset with ID=456.

Policies

Authorization policies map users or user groups to Tamr Core roles. The users or user groups to which a policy applies are members of that policy. You select the role for each policy member. In the same policy, you can add projects and datasets associated with the project.

Policies control access to datasets and projects as follows:

Policies on datasets control access to datasets by users and groups, in any project.
Policies on projects control which users and groups have access to projects, and which datasets these project can read. Derived datasets inherit the policies you create 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.

Tip: Create a policy for each project.

Default Policy

Tamr Core provides a default policy that grants all projects read access to all input datasets. Typically, you do not need to manage project access to datasets. If you require more restrictive access, remove the default policy, and replace it with custom policies that meet the needs of your team.

Policies for New Datasets and Projects

By default, only admins have access to new datasets or new projects. To enable access for other users, create a policy and attach it to the dataset or project. You can also attach an existing policy to your new dataset or project.

User Policy Example

Consider a deployment with two users, Anne and Bob.

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

In this situation, the admin creates a new mastering project named "Master Project", and a new authorization policy. In this policy, the admin 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.

Using Policies for Restricted Access

By using access control policies, admins 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 allows all projects to have read access to all datasets. In the restricted access scenario, delete the default policy, 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, 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.

Creating Access Policies

Before you create policies, create users and groups.

Tips:

When configuring the users and group for a policy, you can enable the option to apply the same specified role to all current and future users or groups for this policy.
When configuring the projects for a policy, you can enable the option to grant all current and future projects access to this policy's resources.

To create a policy:

Navigate to Policies > Create New Policy.
In the Create new policy dialog, enter a Name and Description for the policy.
Select Create Policy.
In the Manage members dialog > Users tab, add the appropriate users to the policy, selecting the role for each user.
In the Manage members dialog > Groups tab, add the appropriate groups to the policy, selecting the role for each group.
In Manage members dialog > Projects tab , add the appropriate projects to the policy.
Select Save.
The policy is listed on the Policies page, along with the number of members and resources in that policy.
(Optional) To add datasets to the policy, select the datasets link for the policy on the Policies page, and then add datasets from the Dataset Catalog.

Managing Policies

Manage policies from the Policies page.

You can do the following:

Add or remove members or resources.
Change the role assigned to a policy member.
Edit, duplicate, or delete an existing policy.

You can also add or remove a single project from a policy by editing project permissions.