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

I think a mental image of building would be appropriate. 2 Scenario's:

The 'allow by default' scenario:

• The entry of the building is open
• The rooms of the building are open
• Any closet in the rooms are open

In case of denying access in this scenario it would look like this:

• John is not allowed to enter room A
• John is approaching room A
• Somebody has to check if it is John
• That somebody must have the authority to deny John to enter the room
• That somebody shuts the door in the face of John

This goes the same with the closet in each room etc. This is done for every person that wants to enter the room and should be compared to a blacklist to either deny or allow.

How is this practical?

The 'deny by default' scenario:

• The entry of the building is closed and locked
• The rooms of the building are closed and locked
• Any closet in the rooms are closed and locked

In case of allowing access in this scenario it would look like this:

• Provide a key for the building and each and every room and closet the person needs access to.

Is this practical? It is even possible to give each person a unique key. Yes, that are a lot of keys to manage and administer. But the win? It will provide granularity and thus flexibility while increasing security.

Answer 2

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?

Answer 3

For me 'allow' should win from 'deny' when there are conflicting permissions. Generally you'll have roles spanning a broad feature set but with limited permissions (eg guest) towards roles with greater responsabilities. You will only be able to reuse the general roles when you allow to override the 'denied'.

Example permissions:

1.

deny members all
allow members to view articles

Allow overrules the deny.

1. Suman is made editor. An editor can do some things and is denied some others, for example permission X. Now if denying has precedence over allowing there will be no way of permitting Suman to do X. It is important to create roles for very specific privileges modifying a few general roles (guests, members), otherwise it will cut both ways (not being able to deny Suman a privilege you have given him through a role).

Answer 4

in my opinion the default should be to deny access, unless they are allowed to access it as a member of a group (in tbl_acl).