ranger-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RANGER-699) higher level policy API to hide complexity of policy update/create/delete
Date Wed, 04 Nov 2015 06:03:27 GMT

    [ https://issues.apache.org/jira/browse/RANGER-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14988955#comment-14988955
] 

Edward Zhang commented on RANGER-699:
-------------------------------------

I have created a pull request for this enhancement, unit test included. I called this API
to be "/api/policyflip" as it looks like it is trying to deny a user who already was allowed
for accessing, or allow a user who already was denied for accessing, meaning it's flipping
the privilege. But we can discuss the naming if this API can be useful for external tool to
explicitly allow or deny a user from accessing a resource.

https://github.com/apache/incubator-ranger/pull/4

Please review that and let me how can I proceed.

> 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)

Mime
View raw message