Building Blocks of Authorization: Rules, Policies, and Roles
Building Blocks of Authorization: Rules
A Rule in a Policy is the building block of Authorization. It contains the following:- Name: A unique name to define the rule
- Description: Description of the rule
- Resources: List of resources this rule applies to. An Admin can select a specific resource, such as Table or All, to apply against all resources.
- Operations: List of operations this rule applies to. An Admin can select a specific operation such as EditOwner or All to apply against all the operations.
- Condition: Expressions written using policy functions that evaluate true or false.
- Effect: Deny or Allow the operation.
Condition
Collate provides SpEL-based conditions for Admins to select during rule creation. Here are some examples of conditions.| noOwner() | Returns true if the resource being accessed has no owner. |
| isOwner() | Returns true if the user accessing the resource is the owner of the resource. |
| matchAllTags(tagFqn, [tagFqn…]) | Returns true if the resource has all the tags from the tag list. |
| matchAnyTag(tagFqn, [tagFqn…]) | Returns true if the resource has any of the tags from the tag list. |
| matchTeam() | Returns true if the user belongs to the team that owns the resource. |
| hasDomain() | Returns true if the logged in user is the has domain access of the entity being accessed |
Default Policy and Rule
When navigating to Settings -> Policies -> Organization Policy, you’ll discover the default rules set at the organizational level. Here’s a quick breakdown of these rules:
OrganizationPolicy-NoOwner-Rule
Purpose: This rule allows users to assign ownership to resources without an owner.
Example: If a user accesses fact_table and finds that it is unowned, then they can modify the ownership field to establish a new owner. However, for a table like dim_address that already has an assigned owner, any attempt to change the ownership will be restricted.
OrganizationPolicy-Owner-Rule
Purpose: This rule grants permissions based on the ownership of a data asset.
Details: When a user, who either personally owns a table or is part of the team owning that table logs in, they’re granted extensive rights. They can modify all properties of that Data Asset and access complete information about it.
By setting up such default rules, the organization ensures clarity in access control based on ownership status and user roles.
Building Blocks of Authorization: Policies
A policy encompasses multiple rules, as delineated earlier. When a user accesses a resource, the policy evaluates all its associated rules in the context of that user’s current session. Resolving Conflicts In instances where a policy has contradicting rules - for example, one rule allows “EditDescription” for all resources while another denies the same - the “Deny” action takes precedence. Policy Assignments While policies can be associated with a specific team within the organizational hierarchy, they cannot be directly linked to individual users. Inheritance and Application
Any user positioned within a team structure inherently adopts its policies. For instance, if the “Organization-NoOwner-Policy” is instituted at the organization’s apex, all its internal members will be governed by this policy and the rules therein.
Similarly, if a policy is designated to “Division1” such as “Division Policy”, every member, be it “Department”, “Team1”, “Team2”, or the individual users in these groups, will fall under its purview.
However, if you formulate a policy explicitly for “Team1”, only the members of “Team1” will be affected.
The Philosophy Behind the Design
This architecture aims to establish broad, overarching rules at the organizational level, potentially being more lenient in nature. As you move down the hierarchy, teams can sculpt stricter, more tailored policies. For instance, a policy might dictate, “Deny access to everyone outside of Team 1.” This ensures a blend of flexibility at the top and precision at the grassroots level.
Building Blocks of Authorization: Roles
Policies serve as mechanisms to enforce authorization, while Roles offer a more structured hierarchy for the same purpose. Each role is closely aligned with a user’s function or job description.
For instance, in an organization, you might have:
- Data Engineers: Tasked with producing data assets.
- Data Scientists: Responsible for creating dashboards and utilizing assets developed by Data Engineers.
- Data Stewards: Experts in all data-related matters who oversee governance duties within the organization.
Roles Based Access Controls (RBAC) Search
In Collate, Role-Based Access Control (RBAC) extends to search functionalities, allowing administrators to enforce granular permissions on metadata assets. By default, the search feature permits all users to access and view available data assets. To restrict search results based on user roles and policies, administrators must enable the Search RBAC setting. To enable or disable the RBAC Search option, navigate to Settings > Preferences > Search in the Collate UI. This setting controls whether search results are filtered based on the user’s assigned roles and permissions.
Implications of Enabling Search RBAC:
Restricted Search Results: Users will only see search results for data assets they have explicit permissions to access, enhancing data security and compliance. Policy Enforcement: The system will enforce policies at the search level, ensuring that unauthorized users cannot discover or access sensitive metadata.Additional Considerations:
Role and Policy Configuration: Ensure that roles and policies are appropriately configured to reflect the desired access controls. This includes assigning correct permissions to users and teams for various data assets. Testing: After enabling Search RBAC, conduct thorough testing to verify that users can access only the data assets permitted by their roles and policies. For a comprehensive understanding of configuring roles and policies, refer to the Advanced Guide for Roles and Policies. Implementing Search RBAC ensures that Collate’s search functionality aligns with your organization’s data governance and security requirements.Use Cases: Creating Roles & Policies in Collate
Tailor you policies to meet your organizational and team needs.