things a Project Manager should be able to do with the
application – list available applications, add or remove
employees to a project, generate project reports, etc.
In this sense, a role is primarily a behavioral concept:
roles give you an idea of what users can do in the
application.
Role-Based Access Control
As a role is primarily a behavioral concept, the logical
step when developing software is to use Roles as a
means to control access to application features or data.
As you might expect, most people call this approach
Role-Based Access Control, or RBAC (“are-back”) for
short.
However, there are two primary ways of of actually
implementing and performing Access Control: an Implicit
way, and an Explicit way.
The very large majority of software applications today
use Implicit access control. I posit that Explicit Access
Control is much better for securing today’s software
applications.
Implicit Access Control
As mentioned previously, Roles represent behavior or
responsibility. But how do we know exactly what
behavior or responsibility is associated with a role?
The answer is that, for the large majority of applications,
you don’t know exactly what that role represents. You
have a good idea of course – you know that someone
with an ‘administrator’ role can probably lock user
accounts or configure certain parts of the application,
and maybe user accounts assigned the ‘customer’ role
can put items in a shopping cart or request new
products. But usually there is nothing that concretely
defines what those behaviors are.