Overview
Authorization models define how access decisions are made—who can do what to which resources under what conditions. Choosing the right model dramatically impacts your ability to implement security policies, scale administration, audit access, and adapt to changing requirements. Role-Based Access Control (RBAC) works well for stable organizations with clear job functions. Attribute-Based Access Control (ABAC) handles complex, contextual decisions. Relationship-Based Access Control (ReBAC) excels for collaborative applications where access depends on who created or shared resources. Most mature organizations use hybrid approaches, combining models to match different use cases. The wrong choice leads to either role explosion (too many granular roles) or insufficient control (overly broad permissions).
Architecture & Reference Patterns
Pattern 1: Centralized RBAC with Entitlement Database
Roles and permissions are managed in a central identity governance system. Applications query role membership from the IdP or directory and enforce permissions locally. Simple, auditable, and works well for traditional enterprise applications. However, it struggles with fine-grained, resource-level authorization. Products like SailPoint, Saviynt, and Microsoft Entra implement this pattern.
Pattern 2: Policy-Based Authorization (ABAC/PBAC)
A central Policy Decision Point (PDP) evaluates authorization requests against policies written in a policy language. Applications send authorization queries with subject, resource, action, and environment attributes. The PDP returns allow/deny decisions. Open Policy Agent (OPA) with Rego, AWS Cedar, and legacy XACML implement this pattern. Ideal for complex, contextual rules but requires investment in policy management.
Pattern 3: Graph-Based Authorization (ReBAC)
Authorization is modeled as a graph of relationships between users and resources. "User A is owner of Document B" or "User A is member of Team C which has access to Folder D." Queries traverse the graph to determine if a path exists from user to resource with required permission. Google Zanzibar, AuthZed SpiceDB, and Ory Keto implement this pattern. Excellent for collaborative applications but requires different mental models and tooling.
Pattern 4: Embedded Authorization with SDK
Authorization logic runs within each application using an SDK or library. Policies are distributed to applications, which evaluate them locally for low-latency decisions. OPA as a sidecar, Cerbos, and Permit.io support this pattern. Trades some centralization for performance and simplicity.
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| Primary authorization model | RBAC, ABAC, ReBAC, hybrid | Start with RBAC for coarse-grained, add ABAC/ReBAC for fine-grained | Don't over-engineer—RBAC handles 80% of use cases |
| Policy Decision Point location | Centralized service, embedded library, gateway | Embedded for latency-sensitive; centralized for auditability | Centralized PDP is a latency and availability dependency |
| Role granularity | Job-based broad roles, task-based fine roles | Job-based roles with contextual ABAC refinement | Fine-grained roles explode into thousands; avoid this trap |
| Policy language | Rego (OPA), Cedar, XACML, custom | Rego or Cedar for modern systems; avoid custom languages | Policy language learning curve is real—invest in training |
| Permission model | Explicit allow, explicit deny, both | Allow-only with implicit deny is simpler; add explicit deny only when needed | Mixing allow and deny creates complex conflict resolution |
| Negative permissions | Not supported, supported with precedence rules | Avoid if possible; if needed, deny takes precedence | Negative permissions complicate auditing and troubleshooting |
Implementation Approach
Phase 0: Discovery
Inputs: Current authorization implementations across applications, access control policies and requirements, compliance requirements (SOX, HIPAA, etc.), application inventory, user population and access patterns Outputs: Authorization model assessment per application, gap analysis against compliance requirements, candidate authorization patterns, entitlement complexity analysis (role count, permission explosion indicators)
Phase 1: Design
Inputs: Discovery outputs, security requirements, scalability requirements, developer adoption requirements Outputs: Target authorization architecture document, role/permission model design, policy language selection and standards, PDP deployment architecture, migration strategy from current state, policy governance process
Phase 2: Build & Integrate
Inputs: Design documents, PDP infrastructure, pilot applications, policy authoring tools Outputs: PDP deployed and configured, initial policies migrated/authored, pilot applications integrated, policy testing framework operational, admin interfaces functional
Phase 3: Rollout
Inputs: Tested authorization system, prioritized application list, migration runbooks, training materials Outputs: Applications migrated in priority order, policy administrators trained, developer documentation and SDKs available, monitoring and alerting operational, legacy authorization systems deprecated
Phase 4: Operate
Inputs: Production authorization system, policy change management process, audit requirements Outputs: Policy changes through governed process, regular access reviews and certification, performance tuning and optimization, policy drift detection and remediation, authorization analytics for security insights
Deliverables
- Authorization architecture document with model selection rationale
- Role/permission model for RBAC components with naming conventions
- Policy standards document for ABAC/ReBAC policies
- Developer integration guide with code examples per language/framework
- Policy testing framework and CI/CD integration
- Access review and certification procedures
- Authorization monitoring dashboard requirements
- Migration playbook from legacy authorization
Risks & Failure Modes
| Risk | Likelihood | Impact | Early Signals | Mitigation |
|---|---|---|---|---|
| Role explosion makes RBAC unmanageable | H | M | Role count growing faster than user count, roles with one member | Regular role rationalization, add ABAC for contextual refinement, role mining |
| Policy conflicts cause unpredictable access | M | H | Access that works sometimes, audit findings of inconsistent enforcement | Conflict detection tooling, deterministic precedence rules, policy testing |
| PDP latency impacts application performance | M | M | Slow page loads, authorization timeouts, user complaints | Caching, embedded PDP, async authorization for non-blocking decisions |
| Policy drift from intended authorization | M | H | Access reviews finding inappropriate permissions, audit findings | Policy-as-code with version control, drift detection, regular access reviews |
| Insufficient policy visibility blocks troubleshooting | M | M | Long resolution times for access issues, helpdesk escalations | Policy simulation tools, decision logging, admin query interfaces |
| Developer adoption failure leaves apps on legacy authz | H | M | Applications not migrating, shadow authorization systems | Developer experience investment, SDKs, documentation, migration support |
KPIs / Outcomes
- Role-to-user ratio: Healthy ratio is 1:10 or better; worse indicates role explosion
- Policy evaluation latency: P99 under 10ms for embedded, under 50ms for centralized
- Access review completion: 100% of required reviews completed on time
- Authorization incidents: Track inappropriate access events and trend toward zero
- Developer adoption: Percentage of applications using standard authorization
- Time to provision access: Should decrease compared to manual/ticket-based approaches