Notifications
Clear all
Topic starter
24/06/2026 9:14 pm
TL;DR: SaaS authorization works best when teams define resources, actions, roles, and policy context before code hardens around them, according to Cerbos. The deeper lesson is that access models decay when role sprawl, broad permissions, and weak review cycles outrun the business structure they were meant to mirror.
NHIMG editorial — based on content published by Cerbos: authorization models for a typical workspace SaaS application
Questions worth separating out
Q: How should teams design SaaS authorization so it stays maintainable?
A: Start with the product’s resources and actions, then define permissions, roles, and policy exceptions from that inventory.
Q: When should organisations use ABAC instead of RBAC?
A: Use ABAC when access depends on context that roles cannot express cleanly, such as the sensitivity of a resource, user attributes, or request conditions.
Q: What breaks when authorization policies are embedded directly in application logic?
A: Policies become harder to test, harder to audit, and easier to drift away from the intended access model.
Practitioner guidance
- Map resources and verbs before writing roles List the protected nouns and actions in the product, then derive permissions from that inventory before assigning any roles.
- Use RBAC as the baseline and ABAC for sensitive exceptions Keep broad workspace access in roles, but move high-risk decisions into attribute-based policy when context such as resource sensitivity changes the answer.
- Separate policy from application code Use a policy framework that can be tested independently so developers can validate authorization logic without deploying the full application.
What's in the full article
Cerbos's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of mapping workspace resources into permissions and roles
- Implementation guidance for ACL, RBAC, and ABAC patterns in a SaaS codebase
- Testing workflow examples for policy evaluation and decision outcome validation
- Ongoing maintenance guidance for pruning roles and reviewing authorization logs
👉 Read Cerbos's guide to implementing SaaS authorization models →
SaaS authorization models: are your roles keeping pace?
Explore further
25/06/2026 6:19 am
Role design is an identity governance control, not just an application architecture choice. This article treats authorization as a system-design problem, but the governance issue is broader: roles are a lifecycle object that must track how people, teams, and permissions change over time. When role definitions are too broad or too narrow, the failure mode is privilege creep, not simply messy code. Practitioners should treat role engineering as part of IGA, not a one-time app configuration task.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: How do security teams keep role sprawl from turning into overprivilege?
A: Review roles regularly, remove unused ones, and split roles that are too broad for current business needs. Visibility into allow and deny decisions helps show which roles are actually in use and where access is being denied repeatedly. That telemetry makes it possible to prune excess access before it becomes routine privilege creep.
👉 Read our full editorial: SaaS authorization still fails when roles drift beyond need
