ACL / Role Management: User Management with Multiple Roles and Conflicting Permismsons

Question

The logical point of getting stuck. I am building a simple ACL and I'm just confused. I'm just trying to do it right.

Take an example of a simple model-based ACL.

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 to support groups and users. tbl_roles

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

Now table for access control tbl_acl

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

In this table, I will keep the ban list, because the ban list will definitely be shorter than the access list.

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

But, if you take userid: 2(suman) , then it is both an editor and a moderator . According to the tbl_acl rule, editor should be rejected where moderator should be enabled.

Should it have access to the resource or should it be rejected? FIRST Allowed or FIRST Rejected . What should be a priority?

Some ways to search in this

• Although the user is denied as an editor, he as a moderator is allowed access to this area.
• Despite the fact that the moderator is allowed access to the resource, all editors are limited.
• Do not forget that the user is also a member . Therefore, if we give priority to permission to refuse. The member will have access to the moderator. If, in addition, members are blocked.

<sub> Postscript I am well aware that this topic is controversial. Thus, the facts would be evaluated (not to mention) over opinions and assumptions. Sub>

Answer 1

You are faced with this dilemma because you have taken a rather non-standard approach to allowing access to resources by default. A more standard approach is to prevent default access, grant access through one or more "allow" ACLs, and override any "allow" entries even through a single "deny" entry. With this approach, any given deny entry intercepts all allow entries. (i.e. the application must first look for failures and, if it is detected, it does not even need to be checked for permissions.)

If you need to convince yourself that "prevent by default" is a better model than "allow by default," here are a few key differences:

• This is usually best suited for the mental permissions model managed by most permission administrators, regardless of whether they are IT staff or business role application administrators. (Provided, this is at least partially due to the fact that most other systems they will use this model, but this does not make it less relevant.)

• Human error is less likely to result in inappropriate granting permission. (that is: if the administrator forgets to add "allow", the default entry is by default, no user can access resources that he should not have touched.)

• When a new permission is added to the system, no one without special administrator rights can access the target resource (s) before the "allow" entries are added.

# 3 is especially convincing. Imagine that you are deploying a new version of the HR application with the new “see salary” permission. Do you find it acceptable to allow all users to obtain this permission until someone adds the "deny" entries to your ACLs?

Answer 2

For me, allow should benefit from deny when there are conflicting permissions. As a rule, you will have roles covering a wide range of functions, but with limited permissions (for example, a guest) in relation to roles with a greater responsibility. You can only reuse common roles when you allow the redefinition of "denied".

Permission example:

1.

 deny members all allow members to view articles 

Allow rejection rejection.

• Suman is the editor. The editor can do something, and he is denied some others, for example, permission X. Now, if the negation takes precedence over allowing Suman not to do X. It is important to create roles for very specific privileges that change several common roles ( guests, participants), otherwise he will shrink in both directions (not being able to deny Suman the privilege that you gave him through the role).

Answer 3

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

Answer 4

I think that a sensible image of the building would be appropriate. 2 Scenario:

Default Allow Scenario:

• The entrance to the building is open.
• The rooms of the building are open.
• Any closet in the rooms is open.

If access is denied in this scenario, it will look like this:

• John cannot enter Room A
• John approaches Room A
• Someone needs to check if this is John
• So that someone should have the right to deny that John entered the room
• That someone is closing the door in front of John.

This is the same for the closet in each room, etc. This is done for each person who wants to enter the room, and it should be compared with the black list to either refuse or allow.

How practical is that?

Default Deny Script:

• Entrance to the building is closed and blocked.
• The rooms of the building are closed and closed.
• Any closet in the rooms is closed and locked.

If access is allowed in this scenario, it will look like this:

• Provide a key for the building and each room and toilet that a person should access.

Is it practical? You can even give each person a unique key. Yes, these are many keys for management and administration. But a victory? This will ensure granularity and therefore flexibility while enhancing safety.