Why Your Authorization Model Is Overkill (and How to Fix It)

Stop Chasing the Perfect Model

I remember a project where the team spent three months building a flawless RBAC hierarchy. The day we launched, a single exception request broke it all. We had to scramble and patch things on the fly. That's when I learned: there's no perfect model. The real world is messy, and your authorization should be too.

So, what's the best strategy? It's not picking one model—it's layering them deliberately. As Cisco Duo explains, RBAC handles defined job roles well, while ABAC offers granularity based on context. Most modern systems use RBAC as the baseline and add ABAC for the tricky cases. That's not a compromise; it's just practical.

Picture This: Your SaaS Platform

Imagine you're the lead engineer at a SaaS platform serving everyone from tiny startups to huge enterprises. You've got thousands of users, dozens of roles, and constant requests like "only for this project" or "can't see billing." Role sprawl is killing you—everyone's an "Admin" for something, and "Viewer" means different things to different people.

If you stick with RBAC alone, you'll end up creating a role for every permutation, which is a maintenance nightmare. If you go full ABAC, you'll drown in policy logic that nobody can debug. What actually works? A hybrid. I've seen it save teams from chaos.

Start with RBAC as Your Foundation

Think of RBAC as the skeleton. The NIST standard (ANSI INCITS 359) defines Core RBAC as the minimum: you have users, roles, and permissions. You start with a clean set of roles—like Admin, Editor, Viewer—and assign users accordingly. This covers 80% of your cases neatly.

But here's the catch: the standard also includes separation of duty rules. For example, a user can't be assigned to conflicting roles (static), or can't activate conflicting roles in the same session (dynamic). These are handy, but they don't solve the "one-off" problem. That's where ABAC steps in.

Use ABAC for the Exceptions

Instead of creating a role for "Viewer but only for Project X," you write a policy that grants Viewer permissions only when resource.project equals user.assignedProject. That's attribute-based access control—evaluating attributes of the subject, object, action, and environment. The trick is to use ABAC only for the exceptions, not for everything.

Here's a concrete example: a Support Engineer role can read logs, but only if the log's region matches the engineer's region and it's within business hours. That keeps your RBAC roles clean while giving you the flexibility you need. I've used this pattern many times, and it's a lifesaver.

Real-Life Scenario: The Contractor Problem

Let's say you have a contractor who needs access to a specific customer's data for two weeks. With RBAC alone, you'd either create a new role (bad) or give them the standard Support role (worse). With a hybrid approach: assign the contractor the Support role (RBAC), then add an ABAC policy that restricts access to only the customer whose account.owner matches the contractor's user.contractorClient. Also, set an environment attribute for time, so access is allowed only during the contract dates.

That's the principle of least privilege in action—granting only the minimum access needed. Tenable reminds us this is crucial. And honestly, it's not that hard to implement if you keep it simple.

Don't Forget the Gritty Details

Now, let's talk about the stuff that trips people up. AWS IAM, for instance, denies by default, and an explicit Deny overrides any Allow. Adopt that same default in your policies. Also, remember: OAuth 2.0 is for authorization, not authentication. An access token doesn't tell you who the user is. Use OpenID Connect for authentication—it adds an ID token that proves identity—and OAuth 2.0 for delegated access. If you're stuck in a legacy environment, SAML 2.0 might be your bridge, but it's XML-based and heavier than modern JWT approaches.

And one more thing: privileged accounts. NIST calls them the "keys to the kingdom" because their compromise causes many major breaches. So whatever your strategy, apply it to your privileged users. Use PAM controls like credential vaulting, just-in-time access, and session recording. Don't let your hybrid model leave gaps for the most dangerous access.

Quick tip: Whenever you mix models, document every policy and role change in your access control review. You'll thank yourself during the next audit—trust me, I've been there.

Bottom Line

Start with RBAC as your baseline, then layer ABAC only where you need context-aware decisions, and add MAC only if you have classified data. Don't aim for perfection; aim for maintainability and clarity. Your future self—and your auditors—will appreciate it.

Sources

• Cisco Duo - https://duo.com/learn/access-control-models
• NIST RBAC (INCITS 359) - https://csrc.nist.gov/projects/role-based-access-control
• NIST SP 800-53 - https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
• Tenable - https://www.tenable.com/cybersecurity-guide/learn/key-iam-components
• AWS IAM - https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
• NIST PAM - https://www.nccoe.nist.gov/financial-services/privileged-account-management