feat(auth) - New privilege for Associate entities for entities tags and glossary terms

[mkamalas]

New privilege to restrict association of tags. We have some use-cases where only a specific group users are authorized to associate certain tags. Also added a resource exclusion capability so that policy can be created for all resources excluding a certain set of resources using NOT_EQUALS policy condition.

To mimic behavior before this change, we need to create a policy which authorizes all users to the new privilege ASSOCIATE TAGS all tag resources.

Checklist

• [ x] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
• Links to related issues (if applicable)
• Tests for the changes have been added/updated (if applicable)
• [ x] Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
• For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

Summary by CodeRabbit

• New Features

  • Introduced enhanced authorization checks for tag association and removal, ensuring only authorized users can perform these actions.
  • Added a new enumeration value NOT_EQUALS to improve filtering capabilities in policy conditions.
  • Introduced a new privilege "Associate Tags" for more granular permission management related to tag associations.

• Bug Fixes

  • Improved error handling for permission-related issues during bulk edits of tags, providing clearer feedback to users.

• Documentation

  • Updated documentation to reflect new privileges and conditions related to tag management and policy definitions.

[anshbansal]

HTTP 405 is well defined in general tech. Let's not override the standard HTTP codes

[mkamalas]

Reverted back the error code to 403 with different error message

[david-leifker]

I think we definitely need to add a test around the policy and new privilege added to the existing tests around the policy engine. Note that the policy engine will grant access if any of the policies match, which means the NOT_EQUAL condition would not be given precedence. It is not a deny condition, but the naming might be a bit confusing based on the NOT_EQUAL name.

Specifically, I am not sure this logic allows this use case

That is the reason we want to add this Exclusionary logic so that we can restrict access for these special tags alone. Would it be okay if we add this with a feature flag to reduce impact ?

[rtekal]

Comments from John Joyce:
If we do this, we'd want to be consistent and do it for terms, structured properties, domains as well. I think it does make sense.

The defaults also have to be great

[jjoyce0510]

Hi guys - Circling back on this one.

I don't think you have responded directly about the request to drop the exclusionary policy requirement.

We've to date kept our policy system extremely simple intentionally. We don't want to break this without deeper consideration.

Given the name of the PR, can we please isolate only the changes related to adding a a new privilege for associating tags? That would reduce the surface area dramatically.

Then we can focus on adding tests to this and we can merge this.

I think we need clear alignment around the exclusionary rules piece. I would want to have a meeting with our team and yours to establish alignment before we proceed any more with this. Please coordinate with Raj Tekal to get that meeting on the books!

[mkamalas]

Hi guys - Circling back on this one.

I don't think you have responded directly about the request to drop the exclusionary policy requirement.

We've to date kept our policy system extremely simple intentionally. We don't want to break this without deeper consideration.

Given the name of the PR, can we please isolate only the changes related to adding a a new privilege for associating tags? That would reduce the surface area dramatically.

Then we can focus on adding tests to this and we can merge this.

I think we need clear alignment around the exclusionary rules piece. I would want to have a meeting with our team and yours to establish alignment before we proceed any more with this. Please coordinate with Raj Tekal to get that meeting on the books!

Hi Joyce,

I attempted to explain the need for the exclusionary rule in this message #8644 (comment). The rationale behind this is the restriction for tag association would typically not be needed for most tags. It is something that would be needed only for certain specially-governed tags. With inclusive policies alone, the policy/policies for Associate tag privilege has to be updated every time a new tag is introduced in the system.

If the use case is to restrict association of 2 tags TagA, TagB and allow only a set of users to associate these 2 tags and allow all users to associate all other tags.
Below will be the 2 policies that we setup:
Policy1 -> Grant Associate Tag privilege on all tags except TagA and TagB to all users
Policy2 -> Grant Associate Tag privilege on TagA and TagB to the specific set of authorized users.

The current datahub setup allows all users to associate all tags. Without exclusionary policy, I am thinking it would be hard to establish a policy for Associate tag privilege.

We can discuss further on options to configure such a setup or any use case for Associate tags. I will work with Raj to plan for a meeting for this discussion.

Thanks

[jjoyce0510]

Hi there. This makes sense. Our team will be considering this reasoning shortly. Getting this through will be a priority for us!

[codecov]

Codecov Report

Attention: Patch coverage is 6.09756% with 154 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...src/app/permissions/policy/PolicyPrivilegeForm.tsx	3.07%	126 Missing ⚠️
.../src/app/permissions/policy/PolicyDetailsModal.tsx	0.00%	7 Missing ⚠️
datahub-web-react/src/app/entity/shared/utils.ts	0.00%	6 Missing ⚠️
...eb-react/src/app/permissions/policy/policyUtils.ts	40.00%	6 Missing ⚠️
...n/java/com/datahub/authorization/PolicyEngine.java	0.00%	4 Missing and 1 partial ⚠️
...eb-react/src/app/shared/tags/AddTagsTermsModal.tsx	0.00%	4 Missing ⚠️

❌ Your patch check has failed because the patch coverage (6.09%) is below the target coverage (75.00%). You can increase the patch coverage or adjust the target coverage.

📢 Thoughts on this report? Let us know!

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[rtekal]

@jjoyce0510
Few days ago, we had a conversation and you are aligned with this PR. You said your team might take over and create a new PR.
Could you please first take this PR first and then more improvements can be made? It is better if you accept this PR rather than creating a new one; which will cause more work for us to reconcile.

Please suggest what more is needed in accepting this PR. Thank you.

[mkamalas]

@jjoyce0510 - Updated the privilege to call it Associate Entity and applied the logic for glossary terms as well. The other ask was to add more test cases around new policy and we are working on it.