Skip to content
BoKSA

3 — Authorisation: models and enforcement

3 — Authorisation: models and enforcement

Study time: ± 60 minutes

Policy plus enforcement

Being logged in says nothing about what you may do. Authorisation has two halves: the policy (who may perform which action on which resource) and the mechanism that enforces it. The classic vocabulary: a subject (a user's session, a process) requests an operation (read, write, delete) on an object (a file, a record, an API endpoint), and something decides yes or no.

The golden rule is least privilege: grant exactly the rights a task needs, nothing more — and revoke rights that are no longer needed. Deny by default; every exception is a conscious decision you can defend.

Organising the rules: the models

  • DAC (discretionary): the owner of a resource decides who gets access. Simple, but unmanageable at scale.
  • MAC (mandatory): the system enforces access via security labels/levels; used in high-assurance and military contexts.
  • RBAC (role-based): permissions attach to roles ("teacher", "student", "admin"), people are assigned roles. Intuitive and scalable; watch out for "role explosion" when exceptions multiply.
  • ABAC (attribute-based): decisions based on attributes of the subject, object and context — time of day, device, department. Flexible and fine-grained, at the cost of complexity.

For your project, RBAC is usually the sensible starting point; know when ABAC-style context rules are worth the extra complexity.

Enforcing the rules: the reference monitor idea

Enforcement rests on one architectural idea: a reference monitor — a checkpoint that every access request must pass, that cannot be bypassed and cannot be tampered with. Modern policy architectures (such as XACML) split this into roles: where policy is written (PAP), where extra facts come from (PIP), the brain that decides (PDP) and the gate that executes the decision (PEP). You do not need to build XACML, but recognise the pattern: decision and enforcement are separated, and there is exactly one unavoidable gate.

Two operations complete the picture: delegation (passing rights on — to a colleague, to a service) and revocation (taking them back — the half everyone forgets).

Where it goes wrong: broken access control

The most common failure in real applications: the app checks whether you are logged in, but not what you may access. Change an ID in a URL and read someone else's invoice — this is an IDOR (Insecure Direct Object Reference). "Broken Access Control" is the number-one risk in the OWASP Top 10, and the fix is discipline, not magic: check authorisation server-side, on every request, against the data being requested.

Core resources

Check yourself

  1. Design three roles for your current project application and name one permission each role has that the others lack.
  2. Explain the difference between RBAC and ABAC using an example from your own project context.
  3. What is an IDOR, and how would you test your own app for one in under five minutes?