Mixed RBAC design - fine or bad?

1
votes

Introduction

I am designing my application role-permission-based access system. In my system I have the following roles:

  • Root
  • Office manager
  • Auditor
  • Customer
  • Worker

For example, lets view the users relations with 'task' entity.

Worker and Customer are quite special roles, they will have almost read-only access to their own tasks. Workers will see only few properties of the 'task' object. Depending on system business rules, in some cases they will be able to update one or two properties.

Root user can do everything, it can create, update, read, delete 'tasks'. Office manager can list, update and create 'tasks'. Auditor can only list tasks.

Root, Auditor and Office manager will have access to same (full) set of 'task' entity properties. This three user types will access system via same management interface (web app module).

Customers will access system via separate role-oriented module (customer module), functionality is too specific. Workers - too (worker module).

So, using the described example, we can say that we can create the following permissions for Root, Auditor and Office manager:

  • LIST_TASKS
  • CREATE_TASKS
  • UPDATE_TASKS
  • DELETE_TASKS

This will work for them, but not for Customer and Worker. For Worker we could do:

  • LIST_WORKER_OWN_TASKS
  • UPDATE_WORKER_TASK_STATUS

... and so on.

But this makes quite low sense, as for me. Noone else but Worker will use this permissions. Also, the conditions when Worker will be able to edit certain properties of 'task' entity can not be described using permissions.

Summary

So, I make a conclusion, that I need a mixed access control system. Customers and Workers will be roles without any permissions. Root, Auditor and Office manager will be roles with set of permissions binded to each role.

Finally , we can call such mechanism mixed permissions-and-role based access system.

Question

Is it a normal to have such design? Am I thinking wrong way? Or it is better to describe Customer and Worker logic (as much as possible) using very detailed list of permissions?

1
phppermissionsrolesrbac

1 Answers

2
votes

I likely wouldn't do something like this just because it seems to be not maintainable over a long term.

Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Members or staff (or other system users) are assigned particular roles, and through those role assignments acquire the computer permissions to perform particular computer-system functions. Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning appropriate roles to the user's account; this simplifies common operations, such as adding a user, or changing a user's department.

Reference: https://en.wikipedia.org/wiki/Role-based_access_control

You could also implement ACL (Access control lists)

An access control list (ACL), with respect to a computer file system, is a list of permissions attached to an object. An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects.[1] Each entry in a typical ACL specifies a subject and an operation. For instance, if a file object has an ACL that contains (Alice: read,write; Bob: read), this would give Alice permission to read and write the file and Bob to only read it.

I usually prefer ACL implementations because they give a finer grain of control.

Reference: https://en.wikipedia.org/wiki/Access_control_list

After looking at your thought, it looks like you are wanting to actually implement ACLs. Loading each users permission through a template. Of course you can always implement both but that is usually just so much overkill and you more-or-less have the security model of the Windows operating system afterwards.