Chapter 2. Design Methods
Executable design principles, failure analysis, decision logic, and key engineering dimensions
2.1 Executable Design Principles & Bases
The following twelve design principles form the executable foundation of the authorization model. Each principle is grounded in security best practices, compliance requirements, or engineering quality standards, and each has a defined scope of applicability. Teams should treat these as testable assertions — every principle should be verifiable through automated tests, audit queries, or operational drills rather than relying on documentation alone.
| Principle | Why It Matters | When Applicable | Evidence / Basis Type |
|---|---|---|---|
| Least Privilege by Default | Reduce breach blast radius; limit damage from compromised accounts | Always — applies to all users, service accounts, and integrations | Security best practice; audit requirements |
| Deny-by-Default for Privileged | Prevent catastrophic actions from proceeding without explicit authorization | Config/policy changes; bulk operations; destructive actions | Risk management; fail-closed safety engineering |
| One Taxonomy for UI + API | Avoid "UI security only" — API must be equally protected | Any platform with both UI and API access | Engineering integrity; bypass prevention |
| Separation of Duties (SoD) | Prevent fraud and insider abuse through role separation | Multi-admin operations; approval workflows | Compliance control (ISO 27001, SOC 2) |
| Explainability | Make audits and access reviews feasible and defensible | Regulated environments; post-incident investigations | Governance requirement; forensics support |
| JIT & Time-Bounded Access | Reduce standing privilege; minimize attack surface | Cross-team support; emergency access; project work | Modern IAM practice; zero-standing-privilege goal |
| Strong Authentication for High Risk | Prevent credential abuse for the most impactful operations | Privileged operations; configuration changes; bulk exports | Threat modeling; MFA best practices |
| Immutable Audit Logs | Ensure accountability; support forensic investigations | All authorization decisions and sensitive operations | Forensics requirement; compliance evidence |
| Versioned Permission Model | Enable safe evolution without breaking existing access | Frequent releases; API changes; schema migrations | Change management; backward compatibility |
| Testable Authorization | Prevent regressions; validate coverage automatically | CI/CD pipelines; deployment gates | Engineering quality; shift-left security |
| Tenant Isolation First | Prevent data leakage in multi-tenant environments | SaaS platforms; MSSP portals; shared infrastructure | Security architecture; data protection |
| Fail-Closed for Writes | Stop bypass attempts during outages or ambiguous states | Any write, delete, or privileged operation | Safety engineering; defense-in-depth |
2.2 Failure Causes → Recommendations
Authorization systems fail in predictable patterns. Understanding these failure modes and their root causes enables teams to design preventive controls and detect drift before it becomes a security incident. The following analysis covers the eight most common failure categories observed in enterprise authorization deployments, along with practical avoidance strategies.
| Failure Cause | Failure Mechanism | Practical Avoidance |
|---|---|---|
| Role Explosion | Many special roles become unreviewable; access reviews fail; SoD breaks down | Role templates + permission sets + naming rules + periodic consolidation reviews |
| Hidden Privileges in Backend Jobs | Cron jobs and automation bypass PEP; actions not audited or governed | Service accounts with explicit scopes + PEP in service layer + audit for all automated actions |
| "Admin" Used as Shortcut | Over-broad grants for speed; SoD broken; excessive blast radius | Tiered privileges + JIT packages + approvals + periodic review of admin assignments |
| UI-Only Menu Checks | API still accessible; UI hiding provides false security | Enforce at gateway + service middleware; automated API coverage tests |
| No Data-Level Controls | Exports leak sensitive rows/columns; PII and secrets exposed | Data tags + row filters + column masking + export volume alerts |
| Manual Provisioning | Stale access after transfers/leavers; orphan accounts accumulate | SCIM + JML automation + deprovision SLA + periodic orphan account detection |
| No Versioning | Breaking changes remove/rename permissions; enforcement gaps appear | Permission registry versioning + migration mapping + backward compatibility tests |
| Weak Audit Schema | Events cannot reconstruct who did what; investigations fail | Standard fields + correlation IDs + tamper-evidence + schema validation in CI |
| Shared Accounts | No accountability; impossible to attribute actions to individuals | Ban shared accounts; use PAM for shared device access with individual checkout |
2.3 Core Design / Selection Logic
The authorization design decision tree provides a structured methodology for determining the appropriate combination of controls for any given system. Starting from actor identification and progressing through resource classification, action tiering, enforcement point selection, and model layering, the decision tree ensures that every design choice is grounded in the specific requirements and risk profile of the system being designed.
The fundamental principle is that RBAC serves as the baseline for all systems, with ABAC conditions added only where context-awareness is genuinely required, and obligations (MFA, approval, dual control) applied only to high-risk actions. This layered approach avoids over-engineering while ensuring that the highest-risk operations receive the strongest controls.
Figure 2.1: Authorization Design Decision Tree — Flowchart from actor identification through resource classification, action tiering, enforcement point selection, and model layering to governance and testing
Step-by-Step Design Process
- Inventory all actors and entry points: UI, API, automation, integrations, and break-glass accounts.
- Create resource model: classify as tenant-scoped vs. global, mutable vs. immutable, sensitive vs. standard.
- Enumerate operations and assign tier (Read/Operate/Admin/Privileged) and risk score to each.
- Decide enforcement: gateway PEP + service PEP for all writes; data layer for row/column controls.
- Implement RBAC role catalog: define baseline roles per job function with minimum required permissions.
- Introduce ABAC only where RBAC is insufficient — for example, network zone, time window, or device trust conditions.
- Add obligations for high-risk actions: MFA step-up, approval workflow, dual control, PAM session recording.
- Design governance: JML lifecycle, review cadence, audit schema, rollback procedures.
- Build test suite: coverage tests, regression tests, and negative tests for each enforcement point.
2.4 Key Engineering Dimensions
Authorization system design must balance multiple competing engineering dimensions. The following analysis covers the critical dimensions that teams must explicitly address during design, with specific targets and trade-off guidance for each.
| Dimension | Target / Requirement | Key Trade-offs | Design Guidance |
|---|---|---|---|
| Performance / UX | PDP decisions p95 <20ms; deterministic error messages; batch evaluation for UI | Caching improves latency but delays revocation propagation | Cache with short TTL (30–300s); precompute role expansions; use batch evaluation for menu rendering |
| Stability / Reliability | PDP HA with at least 2 nodes; explicit fail-closed rules for writes | Fail-closed improves security but may block legitimate emergency access | Document break-glass path; test failover quarterly; use circuit breakers with explicit policy |
| Maintainability / Replacement | Permission registry decoupled from code via specs; migration tooling available | Decoupling adds complexity but enables independent evolution | Registry-first workflow; version all permission IDs; provide migration mapping for renames |
| Compatibility / Extensibility | Plugin resources; multi-tenant; external policy engines optional | Extensibility points increase attack surface if not governed | Define extension contracts; require registration before deployment; validate in CI |
| LCC / TCO | Reduce role count; automation for reviews; avoid manual tickets for low-risk | Automation investment upfront reduces ongoing operational cost | Invest in tooling for role consolidation and access review automation early |
| Energy / Green | Optimize log pipeline cost; avoid excessive audit duplication; retention tiering | Longer retention increases storage cost and energy consumption | Tier audit logs (hot/cold); compress cold storage; deduplicate where legally permitted |
| Compliance / Certifications | SoD, MFA, immutable logs, periodic reviews, data minimization | Stricter compliance controls may slow operations | Map controls to specific framework requirements; automate evidence collection |
Before finalizing the authorization design, validate the following: (1) Every endpoint has a permission ID in the registry. (2) Every role has a defined owner and review schedule. (3) Every privileged action has documented MFA and approval requirements. (4) Tenant isolation is enforced at the data layer, not only at the API layer. (5) The audit schema includes all required fields for forensic reconstruction. (6) The break-glass procedure is documented, tested, and stored in the PAM vault.