Role-based access control (RBAC) What is this really and are there problems with it?
RBAC is using permissions and roles to authorize people for access to a system, or parts of a system. It is very straightforward and is standard security used in many different technologies. The basic components for RBAC security is you have subjects, permissions, roles, and operations.
1 – Subjects. A Subject is the person or system that is requesting authorization to perform an operation. In some advanced scenarios the subject would have a context with some session information useful for authorization decisions.
2 – Permissions – A Permission is a granular activity that is well defined, an example would be access to a file-system, permissions would be read-access, or write-access, etc. A permission is made up of smaller components being an operation and a target/resource. This linkage between an operation and a resource with a name/context is the permission.
3- Operation – this is the activity being requested and is linked to a resource where the activity will be completed.
4 – Role – This is the collection of permissions with some description around the purpose and role of the system.
One of the hard requirements for RBAC to work is that you must only assign subjects to roles, and nothing else, as this would bypass the purpose of RBAC as being able to manage and secure things easier. Some of the common problems with RBAC are listed below.
1 – Role Explosion – This is basically that when you have more complicated security requirements you basically need to create a role for every user, or have an exponential role requirement when you are trying to enforce logical security needs having to centralize the roles. RBAC has a notion of a role-hierarchy, where you can nest roles within roles, for permissions, this works well but only considers one scenario.
2 – Role Management – This is where management of roles and subjects is really brittle and cannot easily be fixed, as having roles containing roles and permissions, the biggest problem is knowing the final result, which can be very confusing with role scopes and precedence, the kinds of problems RBAC should solve.
3 – Tightly Coupled – When you have a security system tightly coupled to the other systems, usually RBAC is baked inside the systems it is not designed in an open and modular fashion making expanding and extending impossible.
We will go into more detail on advanced RBAC scenarios, solutions and other systems that will solve your problems.