ranger-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Madhan Neethiraj (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (RANGER-699) higher level policy API to hide complexity of policy update/create/delete
Date Fri, 04 Mar 2016 18:17:40 GMT

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

Madhan Neethiraj edited comment on RANGER-699 at 3/4/16 6:17 PM:
-----------------------------------------------------------------

[~yonzhang2012] API implementation in the attached patch from [~abhayk] meets the requirements
of the usecases you listed earlier. Will you be able to review (review board link: https://reviews.apache.org/r/44383/)?
Thanks.


was (Author: madhan.neethiraj):
[~yonzhang2012] API implementation in the attached patch from [~abhayk] meets the requirements
of the usecases you listed earlier. Will you be able to review? Thanks.

> 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
>
>         Attachments: RANGER-699.1.patch, RANGER-699.2.patch
>
>   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