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:

1. Name: A unique name to define the rule
2. Description: Description of the rule
3. 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.
4. 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.
5. Condition: Expressions written using policy functions that evaluate true or false.
6. Effect: Deny or Allow the operation.

Building Blocks of Authorization: Rules

Condition

OpenMetadata provides SpEL-based conditions for Admins to select during rule creation.

Here are some examples of conditions.

Conditions are used to assess DataAsset like Tables/Topics/Dashboards etc.. for specific attributes.

Example: Consider the noOwner() condition when applied to the table fact_orders. If this table lacks an assigned owner, then the condition returns true. However, if an owner is present, it returns false.

Another instance: The matchAnyTag(PII.Sensitive) condition, when applied to the dim_address table that carries the PII.Sensitive tag, will yield true. But, without this specific tag, the outcome is false.

You can also combine conditions using logical operators like AND (&&) or OR (||).

For instance, the combined condition: noOwner() && matchAllTags('PersonalData.Personal', 'Tier.Tier1', 'Business Glossary.Clothing') will produce a true result if the Data Asset (be it a Table, Topic, etc.) has no assigned owner and concurrently matches all specified tags.

These dynamic conditions empower admins to craft rules that holistically consider the DataAssets and its attributes when dictating access control.

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:

Default Policy and Rule

OrganizationPolicy-NoOwner-Rule

Organization Policy - No Owner - 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

Organization Policy - 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

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.

Building Blocks of Authorization: Roles

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 provide the advantage of bundling multiple policies encapsulating a user’s specific function or job. For example, a "Data Consumer" role would encompass a "Data Consumer Policy." Any individual or team assigned this role would automatically be subject to the stipulations outlined in the associated policies.

Moreover, roles can be allocated either to individual users or teams within an organizational hierarchy. When a role is assigned to a team, every member of that team inherits the privileges of that role. This design is intentional, aiming to simplify the role assignment process for administrators.