[
https://issues.apache.org/jira/browse/RANGER-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14995759#comment-14995759
]
Edward Zhang commented on RANGER-699:
-------------------------------------
[~madhan.neethiraj] Ah, I think we have fundamentally different understanding
of this API, that is why we want to implement it in different ways :-)
I proposed this API to solve the problem of updating user's privilege partially
with given policy but it's not complete override.
Example1: (explicitly user deny)
Existing policy:
policyItems: user1 -> read,delete -> /tmp/private
denyPolicyItems: <empty>
allowExceptions: <empty>
denyException: <empty>
Given policy:
policyItems: <empty>
denyPolicyItems: user1 -> delete -> /tmp/private
allowExceptions: <empty>
denyException: <empty>
Final policy:
policyItems: user1 -> read -> /tmp/private
denyPolicyItems: user1 -> delete -> /tmp/private
allowExceptions: <empty>
denyException: <empty>
After this API, user1 can only read, but not delete.
Example2: (explicitly user allow)
Existing policy:
policyItems: user1 -> read -> /tmp/private
denyPolicyItems: user1 -> delete -> /tmp/private
allowExceptions: <empty>
denyException: <empty>
Given policy:
policyItems: user1 -> delete -> /tmp/private
denyPolicyItems: <empty>
allowExceptions: <empty>
denyException: <empty>
Final policy:
policyItems: user1 -> read, delete -> /tmp/private
denyPolicyItems: <empty>
allowExceptions: <empty>
denyException: <empty>
After this API, user1 can do both read and write.
The purpose of this API is for external tool like EAGLE to block/allow a user
with one privilege without understanding all others privileges this user
already has. That is important because external tool can not get a whole
picture of a user's privileges and override existing policy. Let me know if
something is missing.
> higher level policy API to hide complexity of policy update/create/delete
> -------------------------------------------------------------------------
>
> Key: RANGER-699
> URL: https://issues.apache.org/jira/browse/RANGER-699
> Project: Ranger
> Issue Type: Improvement
> Components: admin
> Affects Versions: 0.6.0
> Reporter: Edward Zhang
> Assignee: Edward Zhang
> Fix For: 0.6.0
>
> Original Estimate: 720h
> Remaining Estimate: 720h
>
> Ranger has very good fine-grained policy API with which user can define
> access control rules for any resource. But sometimes it is not human being
> but third party tools may use Ranger policy API to temporarily block or
> unblock user. The third party tool just wants to simply tell Ranger that
> "please block/unblock this user from accessing resource A" and the third
> party tool is not able to analyze the complicated scenarios as follows:
> 1. The exactly same rule already exists for resource A
> 2. The current rules for resource A includes the new rule implicitly
> 3. There is no any rules for resource A
> If it's admin to operate the policy, admin can analyze policy semantics and
> will figure out it's to create a new policy or update an existing policy.
> To better support integration from third party tool, Ranger can provide a
> higher level API which accepts request like "block user access to one
> resource" and internally figure out what policy to create/update.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
