http://en.wikipedia.org/wiki/Role-based_access_control

RBAC differs from access control lists (ACLs) used in traditional discretionary access control systems in that it assigns permissions to specific operations with meaning in the organization, rather than to low level data objects. (ACL authorizes read/write access to a file, RBAC authorizes what fields in the file can be read/write, for example)


RBAC model

• S = Subject = A person or automated agent
• R = Role = Job function or title 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: ≥ (The notation: x ≥ y means that x inherits the permissions of y.)
• Many to many relation for subject-role and role-permission.

A constraint places a restrictive rule on the potential inheritance of permissions from opposing roles, thus it can be used to achieve appropriate separation of duties. For example, the same person should not be allowed to both create a login account and to authorize the account creation.

• PA is a subset of P X R
• SA is a subset of S X R
• RH is a subset of R X R

(What is the organization for?)

With the increasing complexity of organizations, using RBAC becomes extremely complex without hierarchical creation of roles and privilege assignments. Alternatives to RBAC are being researched. There are also newer systems that extend the RBAC model to address its limitations.