RBAC model: user in two roles access dilemma

Question

I am implementing the Role-Based Access Control (RBAC) model security system and I have a dilemma: one User1 is in Role1 and is in Role2. Role1 allows access to the Resource1 and Role2 denies access to the same one. It is a well known problem. Could somebody help me, how to resolve it, maybe some explanations. How to explain User1 why it has not access to some resource. Is any solution how to overcome it smarty.

Thanks.

score 7 · Accepted Answer · edited Mar 17 '17 at 10:46

It seems that you are conflating between RBAC and DAC (Discretionary Access Control): Deny Access is not typically employed in RBAC, but rather it comes from the DAC world. F.e. its common to see an NTFS ACL (Access Control List) with DENY in it.

You might be trying to implement a merged model (see the example in my response here) - e.g. building an ACL with ACEs (Access Control Entry) pointing to roles. E.g. using groups to grant access to folders...

There are two possible solutions you can use, perhaps even mix'n'match, depends on what makes sense for your system (I've built and used both, in different contexts):

Ordered ACL - i.e. the ACL is not a big pile of ACEs, but they're in a specific order: higher on the list takes precedence, keep evaluating ACE until you find either a PERMIT ACE, or a DENY ACE for that user. Whichever is first on the list, wins.
DENY ACE overrides all other ACEs. I.e., if the user is granted access via Role1, scan the ACL for any DENY that applies to the user, and then Role2 would block access no matter what.

Note that you might not be implementing this with a standard ACL model, but truly only checking the user roles - that's still fine, the above still applies (just harder to visualize and explain).

The real question you need to figure out is, What makes sense for your system? Are you trying to implement SoD (Segregation/Separation of Duties)? If so, it's clear that DENY must override any PERMIT. If you want the user to configure this (in which case its DAC, not RBAC), the first option gives the most flexibility, since there IS a way to work around it.

@igor, I'm curious - was I correct about you using an ACL model together with the RBAC? — AviD, Nov 18 '10 at 12:55
Yes, you are completely right. I am trying to combine both models, because of real life dictates so — garik, Nov 18 '10 at 14:54
@igor - Oh, I completely understand that, it wasn't criticism of course. I have had many situations where this is exactly what is required (short of a full blown EAM), but I think it's vital to be very clear on your model, and what part of it comes from which. — AviD, Nov 18 '10 at 15:49

score 4 · Answer 2 · answered Nov 18 '10 at 11:17

I'm not sure this is a well-known problem. If your default position is deny-to-all, and it should be, then rules should only state what each role can do. If a user/role has access to a resource under any rule at all, I would think that they should be allowed.

You might have to re-think the way your roles are laid out. I think that in conflicts, the highest priv would win. Tools might handle this in different ways. It's important to understand exactly how your environment does work, not how it should work.

+1 Deny everything, allow little. If your system relies on denying stuff to certain roles, I believe you've already engineered yourself into a quagmire. Good luck! — Theodore R. Smith, Dec 02 '14 at 16:19

score 2 · Answer 3 · answered Nov 18 '10 at 21:19

2

I may be missing something, but isn't a fairly simple solution to use a concept like an "active role"?

In other words, the user picks their active role from the list of roles to which they are assigned and then you only check ACL's against that single role.

answered Nov 18 '10 at 21:19

Van Gale

163
5

3

yes active role is often a good concept to employ, however (depending on the system) it often complicates the usability, and thus lowers the overall security. Most importantly, that would not help solve the issue of SoD. – AviD Nov 18 '10 at 21:31
1

@AviD, it does complicate the usability but at least it does it in a way where there is no dilemma. I voted your answer up, but the idea of ordered ACL's doesn't really solve the dilemma (because you can easily have two roles that conflict regardless of their order) and also adds complexity at a point where it is harder to diagnose problems / conflicts. – Van Gale Nov 18 '10 at 21:40
@Avid, if SoD means always deny if there is a deny rule then there won't be a system dilemma with ordered ACL's. Instead it will be an administrative dilemma on how to create some new role that gives user access to something they need. – Van Gale Nov 18 '10 at 21:45
for ordered ACLs, how can you have conflicting roles? For a given ACL, whichever ACE comes first is valid, anything after that is ignored. SoD means Segregation of Duties - and in some instances it will in fact be required to deny any user that has the second role, regardless of any PERMIT ACE in the ACL (and thus the order is not important). And if you need to enforce SoD, then you have no dilemma how to give access - you don't give it, SoD forbids it. – AviD Nov 18 '10 at 21:55
I agreed with AviD, there are complicates the usability. – garik Nov 20 '10 at 23:54

score 1 · Answer 4 · edited Aug 30 '12 at 08:31

You may want to consider using what I have heard referred to as a hybrid Claims based access security. In this model basically each task is broken down and used as a profile to keep security easier to manage (although harder to initially implement).

Basically setup tables akin to:

Users --> Groups --> Profiles --> Rights
 |         |_______________________^
 |____________________^
 |_________________________________^

Users table, each user may have one or more groups Users may also have one or more Profiles (aka. sub groups of rights for a task) Users may also have one or more rights Groups have one or more Profiles Groups may have one or more Rights Profiles may have one or more Rights

The disadvantage comes from the extra layer of groups that are task oriented, however it is easier for most non-developers to be able to conceptualize this design.

Also you can use a pure Claims based system but it is hard to maintain something like that long term IMO. You would probably be better off with standard RBAC (not RB-RBAC) and use a consistent set of rules such as conflicts = denial of access.

RBAC model: user in two roles access dilemma

4 Answers4