Overview #
Defining Roles is difficult. Defining roles that work over long periods is even more difficult.
Role definition includes two sub-tasks:
- defining the permissions in the role
- defining the users that are to be given membership in the role
Some things to avoid.
- Human Resource Job Titles - Usually do not work as these usually do not define job functions. That is the same bank teller may have different job functions.
- Too Many Roles - The more resources and assets that roles must manage, the more complex the roles become. At some point, the sheer complexity of the roles becomes the burden instead of the solution.
Generally, defining Functional Roles is the best tract. We will use some examples to help clarify.When defining an RBAC model, the following conventions are useful:
- S = Subject = A person or automated agent
- R = Role = Job function which defines an authority level
- P = Permissions = An approval of a mode of access to a resource
- SE = Session = A mapping involving S, R and/or P
- SA = Subject Assignment
- PA = Permission Assignment
- RH = Partially ordered role Hierarchy. RH can also be written: ≥
- A Subject can have multiple Roles.
- A Role can have multiple Subject.
- A Role can have many permissions.
- A Permission can be assigned to many Role.
Constraint place a restrictive rule on the potential inheritance or assignment of permissions from possible opposing roles, thus it can be used to achieve appropriate segregation of duties.
As an example, the same person should not be allowed to both create a login account for someone, and also be allowed to authorize the procedure.
There might be more information for this subject on one of the following: