Access control: ACL, RBAC and ABAC – who may do what?

In short: Authentication clarifies who someone is, authorisation what the person may do; common models are access lists (ACL), roles (RBAC) and rule-based attributes (ABAC).

In more detail: Two questions are often confused: authentication (“Who are you?”, login) and authorisation (“What may you do?”). For the latter every application needs a permission model.

In Depth

ACL: access control lists

For each resource there is a list of people/groups and permitted actions: file.txt: Mia (read, write), group Team (read). Typical for file systems (NTFS, POSIX ACLs), network devices, cloud storage. Advantage: very fine-grained; disadvantage: confusing with many resources.

RBAC: role-based access control

Rights are assigned to roles, people have roles: admin, editor, reader. New employees get the role instead of many individual rights; rights change centrally. Widespread (databases, Kubernetes, cloud, CMS). Danger: role explosion (too many special roles) and permission creep (gradual accumulation).

ABAC and other models

ABAC (attribute-based) decides by properties of user, resource, action and context: “Doctors may read patient files of their ward during duty hours.” Very flexible but more complex. Add ReBAC (relationship-based: “owner, member of a group”, as in Google Drive; systems: Zanzibar, OpenFGA, SpiceDB) and policy engines (OPA, Cedar). DAC (owner decides) and MAC (central security levels, for example SELinux) are classic basic models.

Good practice

• Least privilege: allow only what is necessary, deny by default.
• Always check on the server, never only in the interface (hiding a button is not enough).
• Check at object level: may this user see exactly this record? (protection against IDOR/broken access control, number 1 of the OWASP Top 10.)
• Separation of duties, regular permission reviews, logging.
• Keep permissions central and testable, not scattered across many individual functions.

See also: Authentication, Least privilege, OWASP Top 10