ACL / Role Management: Managing users with multiple roles & Conflicting Permisisons

Question

A logical stuck point. I am building a simple ACL, and I am just confused. I am just trying to do this the right way.

Take a example of a simple model based ACL.

A table of managing users tbl_user

id | userid |
-------------
1  | nabin  |
2  | suman  |

Another table for managing groups tbl_group

id | groupname |
-----------------
1  | admin     |
2  | member    |
3  | editor    |
4  | moderator |

Another table for maintaining groups and users. tbl_roles

id | userid | groupid
-----------------------
1  | 1      | 1
2  | 1      | 2
3  | 2      | 2
4  | 2      | 3
5  | 2      | 4

Now a table for managing the access tbl_acl

id | groupid | appresourceid
----------------------------
1  | 3       | 1

On this table, I will store the deny list, cause deny list will definitely be shorter than the access list.

Now, according to the example groupid:3 (editor), has been denied to the resource 1(suppose this is the administration area).

But, if you take userid: 2(suman), then he is a both editor and moderator. As per the rule of tbl_acl, editor should be denied, where as moderator should be allowed.

Should he be allowed to access the resource or should be denied? Allowed FIRST or Denied FIRST. Which should be prioritized?

Some ways of looking into this

1. Although the user is denied as a editor, he as a moderator is allowed to access the area.
2. Even though, moderator is allowed to access the resource, all the editors are restricted.
3. Not to forget that the user is a member too. So if we are prioritizing the allow over the deny. Member will have access as an moderator. Unless, member are blocked too

_{P.S. I am well aware of this topic being debatable. So, facts would be appreciated (not saying don't) over opinions and guesses.}

Answer 1

You are encountering this dilemma because you have adopted the rather non-standard approach of allowing access to resources by default. The far more standard approach is to prevent access by default, grant access via one or more "allow" ACL entries, and override any "allow" entries via even a single "deny" entry. Under this approach, any given "deny" entry trumps all "allow" entries. (i.e.: The application should look for denies first and, if it finds any, it doesn't even need to check for allows.)

If you need convincing that the "prevent by default" is a better model than "allow by default", here are a few major differences:

1. It is generally a better fit for the mental model of permissions management held by most permission administrators, whether they be IT staff or business-role application administrators. (Granted, this is at least partly due to the fact that most other systems they will have administered use this model, but that doesn't make it any less relevant.)

2. Human error is less likely to result in inappropriate granting of a permission. (i.e.: If the administrator forgets to add an "allow" entry under prevent-by-default, no user ends up being able to access resources that he should not have been able to touch.)

3. When a new permission is added to the system, nobody without special admin rights can access the target resource(s) until explicit "allow" entries are added.

#3 is particularly compelling. Imagine you deploy a new version of an HR application with a new "view salaries" permission. Would you find it acceptable to allow all users to be granted this permission until someone gets around to adding "deny" entries to your ACLs?