PERMISSIONS AND ACCESS CONTROL

THE DECISION STEPS A well-designed resolver follows a clear order, and a common order is the following. First, check the explicit deny rules; if any matches, deny immediately, because denies should win over allows. Second, check whether the request is on the explicit allow rules for this actor and scope; if so, allow, possibly with conditions. Third, check whether the action belongs to a category that requires human approval; if so, ask. Fourth, if nothing matches, apply the default, which for security should be deny. This last point is called default deny, and it is among the most important ideas in security: anything not explicitly permitted is forbidden. WHERE RULES COME FROM Rules can come from several places, such as organization-wide policy, project-level settings, user preferences, and session-level approvals. A good resolver defines which source wins when they conflict, usually with the broader and stricter policy overriding the narrower and looser one. It must also be deterministic and testable, as you learned in Chapter 35, since a resolver is exactly the kind of component that deserves thorough unit tests, including tricky and hostile inputs. MAKING DECISIONS UNDERSTANDABLE Each decision should record a reason, such as which rule matched. This helps debugging, auditing, and trust.