Blog
IAM Chapter 6, Part 1: Who May Do What
Every control has a purpose. Knowing which one is the hard part.
On this page
Part of the IAM study series.
Chapters 1–5 answered who are you. This chapter answers what may you do. Like the MFA chapter, it's a ladder, where each fix creates the next problem:
ACL → no way to ask "what can John access?" → RBAC → who defines the roles? → role engineering → roles can't express context → ABAC (Part 2).
1. ACL: The List Lives on the Resource
An ACL (Access Control List) is a list stored with a resource, naming who may do what to it. Each line is an ACE, with three parts: a principal (a user, group, or service account), a permission (read, write, delete), and an effect (allow or deny).
drawing_A320_wing_bracket_rev7
john.wick → read, write
marcus → read
sofia → read, write, deleteYou've met these as NTFS permissions, S3 bucket ACLs, and SharePoint item permissions. The owner of each object writes its list, so the decision sits with whoever owns the object, not with a central policy. In most systems deny beats allow, so one stray deny overrides every grant.
The asymmetry that kills ACLs
Two questions, two completely different costs:
- "Who can access this drawing?" Read one list. Seconds.
- "What can John access?" There is no list for John. You must open all 400,000 drawings and check each one.
ACLs answer the resource question beautifully and the person question not at all, yet every question that matters in IAM is the person question: joiner, mover, leaver, audit, recertification, export control.
This is also where access creep comes from. Removing access requires a search nobody can perform, so grants accumulate and never leave.
2. RBAC: Grant to the Role, Not the Person
A role is a named bundle of permissions representing a job function. RBAC grants access to roles and assigns people to roles: two assignments instead of one. The maintenance load drops from people × resources to people × roles plus roles × permissions.
Now both questions read one place. What can John access? List his roles and expand each. Who can write wing drawings? Find the roles that grant it and list their members.
Roles can also inherit: Senior Wing Engineer includes everything Wing Design Engineer has, plus approvals. This works along a genuine line like seniority, and fails between peers. Force Wing and Engine into a hierarchy so that one person can hold both, and 400 wing engineers get engine access.
Role vs group
| Group | Role | |
|---|---|---|
| Origin | A directory container (AD, Entra ID) | An access-model concept |
| Means | "These people are together" | "These people do this job" |
| Grants? | Only if an app happens to check it | Yes, by definition |
The real difference is enumerability. A role holds its entitlement list, so you can open it and read what it grants. A group has nothing to open, because its grants live in apps that never told the directory anything. If your "roles" are just AD groups someone named nicely, you don't have RBAC.
An entitlement is a single unit of access inside a target app, such as "write on wing drawings in PLM". Entra ID knows PLM-WingEngineers exists and who's in it, but not what it grants inside PLM. A name like PLM-WingDrawings-Read doesn't help either: nothing stops an admin wiring it to write, and the name and the reality diverge silently.
3. IGA: What the IdP Cannot Answer
IGA (Identity Governance and Administration) sits above the identity provider and holds the cross-application picture. SailPoint, Saviynt, One Identity, and Omada are the usual names.
The IdP decides whether you get in. The IGA decides whether you should have been allowed in the first place.
| Function | What it means |
|---|---|
| Entitlement catalogue | Connectors pull each app's permissions into one inventory |
| Access request and approval | A front door with a recorded approver and reason |
| Provisioning and deprovisioning | Pushes grants into the app and removes them (Chapter 7) |
| Access review | Campaigns asking owners to confirm access is still needed |
The catalogue is what makes it real. Without one, reviewers certify group names rather than grants, which is blind approval at scale.
4. Role Explosion, and the Four Layers
John needs engine drawings for one project, so someone creates "Wing Design Engineer – Engine Read". Repeat for two years and you have several thousand roles, most with one or two members: per-person grants wearing role-shaped names. It's the ACL problem one level up, and the most common way RBAC fails.
The cause is that adding a role is the only lever RBAC hands you. The fix is deciding which needs belong in the model at all, and that's role engineering:
| Layer | What it is | Owner | Changes |
|---|---|---|---|
| Birthright | Everyone gets it: email, intranet, VPN | IAM team | Rarely |
| Business role | The job function, derived from HR data | Line of business | When the org changes |
| Application role | A bundle of entitlements inside one app | App owner (Winston) | When the app changes |
| Entitlement | The raw grant in the app | The app | Constantly |
John joins as DE-03 in WING-ASSY. HR data assigns him the business role Design Engineer – Wing Assembly, which contains his PLM, TeamCenter, and SharePoint application roles, so he has working access before he sits down. The engine exception stays a time-bound request (90 days, approved by Winston, reason recorded) and never enters the catalogue.
The test for the two middle layers: would it still mean something if the system were replaced tomorrow? "Design Engineer – Wing Assembly" survives PLM being replaced, so it's a business role. "Wing Site Contributor" doesn't survive SharePoint being replaced, because Contributor is a SharePoint permission level, so it's an application role.
Two layers earn their cost twice. A line manager can confirm "John is a wing design engineer" but not PLM.WRITE_WING_DWG, while Winston is the reverse, so each certifies the layer they understand. And when PLM is replaced, you swap the inner role once and 400 people move in one change.
Three rules worth keeping:
- Aim for 70–80% of access through birthright and business roles. Chasing 100% is what produces 3,000 roles.
- A role with one member is not a role.
- If a role changes every month, it's a project, and it should be time-bound.
Measure the split between roles and direct assignment. Nobody announces it when direct assignment quietly becomes the default path.
5. The Limit of the Model Itself
A perfect role model still can't hold one class of condition. John's access depends on his project, site, export clearance, and whether the drawing is restricted. RBAC can only express that with a role for every combination:
50 projects × 8 sites × cleared (2) × restricted (2) = 1,600 roles, to express four facts.
Leave those conditions out instead, and the role is blind. An admin assigned it on Monday. By Thursday 14:32 John's clearance may have expired, he may be working abroad, and the drawing may have been reclassified that morning. The role knows none of it.
Almost every authorization argument is about which of two moments you chose: grant time, when someone assigns access, or access time, when John uses it. Under RBAC the real decision happened at grant time, and access time only looks it up. That's why it's fast, and why it's blind to the situation.
Pros: both access questions are answerable; joiners get access on day one; a mover swaps one role; a human can review it; it survives app replacement. Cons: role engineering is expensive; it can't express context; roles drift from reality silently; it needs HR data good enough to drive it.
🔴 CHECKPOINT: Study Notes
← Previous: OAuth 2.0, Part 2 · Back to the series start · Next: ABAC and the Policy Engine →