authorization

Choose RBAC when permissions map to fixed roles, ABAC when decisions depend on attributes like department or time, and ReBAC when access depends on entity relationships like sharing or folder hierarchies. In practice, start with an RBAC plus ABAC hybrid and add ReBAC only when relationship graphs are required.

Place static role checks in the application layer, domain-state-dependent rules in the domain layer as Specifications, and complex cross-cutting rules in a dedicated bounded context. If a constraint holds regardless of the actor, it is a domain invariant and belongs in the entity, not in an authorization policy.

Use architecture tests like ArchUnit to verify every controller method has an authorization annotation, or enforce checks structurally with Authorized<T> types required as use case arguments. For CQRS systems, command bus middleware makes authorization impossible to bypass.

For multi-tenant SaaS where cross-tenant leakage is critical, combine ORM global filters with PostgreSQL Row-Level Security as a double layer. The ORM filter protects normal queries while RLS blocks direct SQL bypasses, configured to fail closed when the tenant setting is missing.

Command-side authorization asks whether an operation may execute and returns explicit 403 errors, acting as a PDP. Query-side authorization filters which data is visible, acting as a PEP that silently excludes unauthorized rows via WHERE clauses or access scopes.

Move to a centralized policy decision point when microservice count grows and rule consistency across services becomes hard to maintain, or when ReBAC relationship graph traversal requires a dedicated engine. Decentralized per-service authorization is simpler and faster for monoliths and single services.