Who may do what: roles and attributes

The interviewer asks: "Customers, restaurant owners and support staff use one system. How do you stop a customer from refunding an order?" A weak answer is "we check that the user is logged in". A strong answer separates login from permission, says where the check runs, and names the rule that decides.

In an office, your badge opens the doors that your job needs. A hospital adds a rule: a doctor may open a patient file only for a patient in the doctor's own ward, a section of the hospital.

Lesson 99 showed how to find out who the caller is. Authorization is the next question: may this user do this action on this thing? If the user is not logged in, the answer is 401. If the user is logged in but not allowed, the answer is 403 (lesson 9).

A permission is one allowed action, such as order:refund.

Role-based access control (RBAC) groups permissions into roles. A user gets one or more roles. The check is: does any role of this user hold the permission? To change what all support staff may do, change one role.

A role does not know details. Suppose support may refund only orders from their own city, up to a limit. With roles alone, you need one role for each combination. This is role explosion.

Attribute-based access control (ABAC) uses a rule, also called a policy. The rule reads attributes, which are facts about the user, the thing, the action and the situation (such as the time). It returns allow or deny. For example: allow if the user is support, and the order's city is the user's city, and the amount is at most the user's refund limit. A role can be one attribute of the user.

Many systems use both. Roles give the broad jobs, and attribute rules limit them. One rule is always needed: a customer may read an order only if the order's owner is that customer. The role does not say which orders.

Four habits keep this safe:

• The server checks every request. Hiding a button in the app is not a check.
• Deny by default: allow only what a rule names.
• Give each user the least access the job needs.
• Decide where roles come from. A lookup on each request takes effect at once. A role inside a JWT (lesson 99) lasts until exp.

A food-delivery back office. Assumptions (made up): 10,000 staff, 40 permissions, 8 roles, 1.5 roles per person.

Roles against single grants. Giving each person each permission needs up to 10,000 x 40 = 400,000 grants. With roles: 10,000 x 1.5 = 15,000 role assignments, plus at most 8 x 40 = 320 role-permission pairs. That is 15,320 in total.

The refund rule. With roles alone: 20 cities x 2 limits = 40 roles. With a third fact, 3 shifts, it is 120. With ABAC there is one rule: the user is support, order.city equals user.city, and order.amount is at most user.refund_limit. This answers the predict box.

Three requests. Order 8 is from Pune and costs Rs 1,800. A junior agent in Pune (limit Rs 2,000): allow. Order 9 from Pune costs Rs 2,500: 403. The Delhi agent asks for order 8: 403.

Role in a token. An agent loses the support role at 10:00. The token was issued a moment before and lasts 900 seconds (15 minutes). If the role is inside the token, the agent can refund until about 10:15. With a lookup on each request, the delay is 0 seconds.

RBAC solves simple, readable access that is easy to check. It costs role explosion when rules depend on details. ABAC solves fine rules with few policies. It costs harder checks, because "who can refund order 8?" needs the rule to run for each user. I would start with roles, and add attribute rules when I would otherwise add a role for each city.

"Hiding the Refund button is access control." The API still accepts the call. The server must check every request.

"ABAC replaces roles." Most systems use both. A role is one attribute.

1. What is the difference between 401 and 403? Define RBAC and ABAC in one line each.
2. There are 5,000 staff, 30 permissions, 6 roles and 1.2 roles for each person on average. How many grants need single permissions, at most? How many role assignments and role-permission pairs, at most?
3. A shop hides the "Delete product" button from staff. The delete API checks only the login. What happens, and what do you change?