Skip to content

User Principals

In Apache Ranger and Privacera, a User Principal is any identity that can be granted or denied access to a data resource. This includes users, groups, and roles. Users and groups can also have attributes associated with them. Policies are evaluated against these principals to determine access outcomes.

Types of Principals

Principal Type Description
User A specific identity (e.g., alice, bob) that represents an individual
Group A collection of users (e.g., finance_team, engineers)
Role A logical role that can be assigned to one or more users (e.g., analyst)

All three types of principals can be used in resource-based, tag-based, and masking policies.

User Groups vs Roles

  • User Groups are collections of users that can be used to simplify access management. For example, you can create a group called finance_team and assign it access to financial data.
  • Roles are more specific and often used to define job functions or grant temporary access. For example, you might have a role called data_scientist that has access to certain datasets for a limited time.

Privacera does not distinguish between user groups and roles in terms of core functionality. Both can be used to manage access to resources. However, the distinction is important for organizational purposes. Using groups for general access and roles for job-based or temporary privileges helps keep access management organized and easier to maintain.

User Groups Roles
A collection of users A logical role that can be assigned to one or more users
Simplifies access management Defines job functions or temporary access
Used for general access control Used for job-based or temporary privileges
Can be used in all policy types Can be used in all policy types
Groups can include only users Roles can include users, groups, and nested roles

User Attributes

User attributes are metadata associated with users and groups that can be used in policies. For example, you can use user attributes to restrict access based on department, location, or job title. Using user attributes in policies can help you create more granular and context-aware access controls.

Here are some examples of user attributes that can be used in policies:

Attribute Name Description
department The department to which the user belongs (e.g., finance, engineering)
location The location of the user (e.g., US, Europe, APAC)
job_title The job title of the user (e.g., analyst, manager, developer)

For more information on how to use user attributes in policies, refer to the ABAC documentation.

Attributes are currently not supported for Roles

How Principals Are Mapped to Data Platforms

Every data platform has its own way of representing users, groups, and roles. The policies are also platform-specific, meaning they must be configured according to the target platform's requirements. Privacera provides a mapping layer that translates users/groups/roles from Privacera to the native representation in the data platform. This feature helps in maintaining a consistent access control model across different data platforms.

Here are some common mapping scenarios:

  1. Snowflake: Snowflake uses roles for access control. Privacera maps users and groups to Snowflake roles and privileges. This requires that the roles corresponding to the users and groups exist in Snowflake. This can be created using Privacera's PolicySync connector feature or using other automation tools.
  2. Databricks: In Databricks, user permissions are given to their email address. Privacera maps usernames to their email address and applies the permissions accordingly. This requires that the mapping between usernames and email are available in Privacera. If permissions are given to roles in Privacera, then it is expected that a corresponding group with the same name exists in Databricks. Privacera will automatically apply the permissions to the corresponding group
  3. RedShift: For databases like RedShift and PostgreSQL, Privacera maps users and groups to database roles. The mapping is done based on the username and group name. Privacera will automatically create the roles in the database if they do not exist.

How Principals Are Managed

  • Users and Groups can be synced from identity providers (LDAP, Azure AD, Okta) or manually managed. Refer to the Privacera UserSync for more details.
  • Roles are defined within Ranger/Privacera and are mapped to users and groups.

Privacera Portal also provides a user interface for managing users, groups, and roles. You can create, update, and delete these principals. This is useful during the initial testing phase and for managing administrator users who might not be part of the identity provider.

Policy Enforcement

When a user attempts to access a resource:

  1. The policy engine looks up the user's identity, groups, and roles.
  2. It checks for matching policy items that allow or deny access based on these principals.

Not all connectors support DENY policies. Check the respective connector documentation for the level of support.

For example, the DENY policies are not supported in the following connectors:

  • Databricks Unity Catalog
  • Snowflake

Best Practices

  • Use groups for general access control.
  • Use roles for job-based or temporary privileges.
  • Use user attributes to create more granular policies.
  • Avoid granting access directly to individual users unless absolutely necessary.
  • Review principal mappings regularly, especially when identities are synced from external sources.

Comments