Skip to main content

What authorization is (and is not)

Objective​

Explain the difference between authentication and authorization at runtime, and read the reference OPA policy to predict whether a given request is allowed or denied.

Concept​

Authentication proves who a caller is. Authorization decides what that identity may do, on which resource, in a given context, at runtime. EnforceAuth calls the gap between the two "the Authorization Gap," and its operating model is Define, Enforce, Audit.

In practice a Policy Decision Point (PDP) such as OPA or Enterprise OPA evaluates a policy against an input document and returns a decision. A good policy is default-deny: it denies unless a rule explicitly allows. EnforceAuth's control plane, Writ, governs and deploys these policies (signed bundles from Git, promotion across environments, decision logs). Writ is not a PDP on the request path; the PDP is OPA or Enterprise OPA.

Open the lab policy in ../lab/policy.rego. It maps each role to a set of permitted actions and allows a request only when the requested action is in the set for the subject's role. An unknown role leaves the lookup undefined, so the decision falls through to the default, false.

Hands-on lab​

The lab in courses/reference-hello-authorization ships as a starter: policy.rego gives you the permissions map and default allow := false, but the allow rule is left as a TODO(learner) stub. Open policy.rego and implement the allow rule so a request is granted only when input.action is in the set of actions permitted for input.subject.role.

Run the suite as you work:

git clone https://github.com/EnforceAuth/university-labs.git
cd university-labs
opa test courses/reference-hello-authorization -v

The starter reports FAIL: 3/6. It includes allow cases (an admin can delete, an editor can write, a viewer can read) and deny cases (a viewer cannot write, an editor cannot delete, an unknown role is denied). The deny cases catch a "false allow," a request granted when policy says it should not be. Implement the TODO until you reach PASS: 6/6. Keep iterating until opa test is green.

Check for understanding​

  1. A request arrives with a valid token but for an action the subject's role does not permit. Is this an authentication failure or an authorization failure?
  2. In policy.rego, what decision does a request with role: "guest" produce, and why?
  3. Which tests in policy_test.rego would start failing if you changed default allow := false to default allow := true, and what class of security bug does that represent?