>> My proposal is to just keep the policy to have only allow and deny with NO exceptions. In your use case, if we allow "finance" group and deny "intern" group, then anyone in intern group would not be allowed while everyone else in finance group will get access. If there is a person in intern group who needs access, then user need to be taken out of the intern group or we need to add only the users who specifically need to be denied.
<<Users who are not comfortable with the idea of “excludes” can continue to use only allow and deny in the policies. Users who are comfortable with “excludes” can choose to use it to simplify their policy management.>> The question here is whether exceptions are really needed in the product. We need to keep the product simple Questions is what use cases can exceptions clearly solve above and beyond simply access grant and access deny policy line items. As an example, I am looking at MSFT for how they have have implemented deny-access https://msdn.microsoft.com/en-us/library/windows/desktop/aa446597(v=vs.85).aspx. The use case MSFT is trying to solve it denying access to specific users who are part of the group which is provided access. I think most of the deny-access use cases would be for specific users, not for large sets of groups. On Tue, Oct 13, 2015 at 11:47 PM, Madhan Neethiraj < [email protected]> wrote: > >> For argument sakes, finance could be the higher level group and intern > could be a sub group in a hierarchy. There could be n number of sub groups. > We could provide access by adding n-1 groups to the policy. We can argue > whether n<10 or n>50, depending on the answer it would make sense to add > all groups which needs access or specify deny groups which don't need access > > The groups may not fall into nice hierarchies – for example, interns group > might consist of users from various orgs in a company (not just from > finance group). In such cases, the only choice is to setup Ranger policies > with individual users (and not groups). > > >> My proposal is to just keep the policy to have only allow and deny with > NO exceptions. In your use case, if we allow "finance" group and deny > "intern" group, then anyone in intern group would not be allowed while > everyone else in finance group will get access. If there is a person in > intern group who needs access, then user need to be taken out of the intern > group or we need to add only the users who specifically need to be denied. > > Users who are not comfortable with the idea of “excludes” can continue to > use only allow and deny in the policies. Users who are comfortable with > “excludes” can choose to use it to simplify their policy management. > > Thanks, > Madhan > > From: Balaji Ganesan > Reply-To: "[email protected]" > Date: Tuesday, October 13, 2015 at 10:24 PM > > To: "[email protected]" > Subject: Re: [DISCUSS] Policy model enhancement to support > deny-conditions and exceptions > > <<Are you suggesting that the security admins create policies that list > individual users, instead of using groups? Wouldn’t that make security > administration more painful, in a reasonably large organization? For every > change in users role (or group) or an employee joining/leaving the org, all > security policies have to be reviewed and updated.. Many ACLs support both > users and groups to alleviate this issue.>> > For argument sakes, finance could be the higher level group and intern > could be a sub group in a hierarchy. There could be n number of sub groups. > We could provide access by adding n-1 groups to the policy. We can argue > whether n<10 or n>50, depending on the answer it would make sense to add > all groups which needs access or specify deny groups which don't need access > > My proposal is to just keep the policy to have only allow and deny with NO > exceptions. In your use case, if we allow "finance" group and deny "intern" > group, then anyone in intern group would not be allowed while everyone else > in finance group will get access. If there is a person in intern group who > needs access, then user need to be taken out of the intern group or we need > to add only the users who specifically need to be denied. > > On Tue, Oct 13, 2015 at 9:48 PM, Madhan Neethiraj <[email protected]> > wrote: > >> Balaji, >> >> >> why cannot user clearly specific users or groups that would need >> specific access. Why is there a need to give access to finance group as a >> whole when we know there is a subset of user who do not need access to the >> the finance database? or clearly specify users who need to be denied? >> Are you suggesting that the security admins create policies that list >> individual users, instead of using groups? Wouldn’t that make security >> administration more painful, in a reasonably large organization? For every >> change in users role (or group) or an employee joining/leaving the org, all >> security policies have to be reviewed and updated.. Many ACLs support both >> users and groups to alleviate this issue. >> >> >> From: Balaji Ganesan >> Reply-To: "[email protected]" >> Date: Tuesday, October 13, 2015 at 9:01 PM >> >> To: "[email protected]" >> Subject: Re: [DISCUSS] Policy model enhancement to support >> deny-conditions and exceptions >> >> Madhan, Fantastic job in putting together in the wiki. Thank you. >> >> We clearly need to show case use cases for deny exclude and allow >> exclude. In my opinion it is very confusing to user to construct such a >> policy >> >> <<Let’s say one of the users, scott who is in interns and finance groups, >> works on an assignment that requires select access to finance database. To >> enable this access, the authorization policy for the database should be >> updated by adding a deny-exclude, as shown below:>> >> In the wiki, we have created a "deny" policy for intern group and an >> exception for Scott. First of all, why cannot user clearly specific users >> or groups that would need specific access. Why is there a need to give >> access to finance group as a whole when we know there is a subset of user >> who do not need access to the the finance database? or clearly specify >> users who need to be denied? It is confusing to think about exceptions for >> deny, deny, exceptions for allow and allow. >> >> >> On Tue, Oct 13, 2015 at 2:43 PM, Madhan Neethiraj <[email protected]> >> wrote: >> >>> Bosco, >>> >>> Thanks for the review and comments. The wiki >>> <https://cwiki.apache.org/confluence/display/RANGER/Deny-conditions+and+excludes+in+Ranger+policies> >>> has been updated to address your comments. Please review. >>> >>> Thanks, >>> Madhan >>> >>> From: Don Bosco Durai >>> Reply-To: "[email protected]" >>> Date: Monday, October 12, 2015 at 6:20 PM >>> To: "[email protected]" >>> Subject: Re: [DISCUSS] Policy model enhancement to support >>> deny-conditions and exceptions >>> >>> Madhan, thanks for putting this document together. It is looking good. >>> >>> Can I make a few suggestions: >>> >>> 1. Call out each use case as separate section. E.g. 2.2.3 for "HDFS >>> policy that allows all finance group users to access contents of /finance >>> folder, but denies access to users in interns group. Users in interns >>> group >>> will be denied the access even if they are part of finance group.” >>> 2. Can we also add a simple use case of global “Deny”. E.g Deny all >>> users from “interns” group from accessing table “Employees" >>> 3. The label “Exceptions”, can we make it more explicit. E.g. >>> “Exclude from Allow Conditions” and “Exclude from Deny Conditions” >>> 4. Probably one small paragraph to explain “Exceptions” will be >>> good. I think, this is sort of a new concept. >>> 5. Section 3 “Policy Evaluation”, it seems to be a flow chart. Can >>> we create flow chart diagram. It will be easy to understand >>> >>> Thanks again. Let me know if you need help in the documentation. >>> >>> Bosco >>> >>> >>> From: Madhan Neethiraj >>> Reply-To: <[email protected]> >>> Date: Monday, October 12, 2015 at 5:46 PM >>> To: "[email protected]" >>> Subject: [DISCUSS] Policy model enhancement to support deny-conditions >>> and exceptions >>> >>> All, >>> >>> Apache Ranger policy model enhancement to support deny-conditions and >>> exceptions (RANGER-606 >>> <https://issues.apache.org/jira/browse/RANGER-606>) is available in >>> tag-policy >>> branch <https://github.com/apache/incubator-ranger/tree/tag-policy>. >>> This enhancement adds the capability to explicitly deny access to resources >>> based on users/groups, access-types and custom-conditions. It also supports >>> allow/deny to be specified for a wider group (like employees, public, etc) >>> but exclude specific users/groups who might be part of the wider groups. >>> >>> An overview of the implementation, along with few examples is available >>> in Apache wiki page here >>> <https://cwiki.apache.org/confluence/display/RANGER/Deny-conditions+and+exceptions+in+Ranger+policies>. >>> Please review. >>> >>> Thanks, >>> Madhan >>> >>> >>> >> >
