Who may do what

Module 6 gave you the two questions (who are you, and what may you do?) and promised depth later. That depth arrives now.

Phase 7 opens on the second question because it is where product decisions and security machinery meet daily.

What is an identity?

Start by firming up identityConcept · lights on your mapidentityA single known actor the system can vouch for, human or not. Proving one is Module 6’s authentication. Deciding what each one may do is this module’s subject, and it is why “identity provider” systems sit at the center of corporate IT.: the verified answer to “who is this?”

Module 6 covered the verifying, which is authentication doing its job at login. This module begins the moment after. The system holds a record for the actor, and every request that actor makes arrives stamped with it.

In Module 6, “the user logged in” was most of the story. Now it broadens to every actor in the system, which means the customer, the support agent, the finance analyst, and the deploy pipeline itself. Software has identities too, and next lesson makes that concrete.

And everything else in access control hangs off an identity. Every check in the rest of this lesson starts with the same question. Whose identity is asking?

What is a permission?

Each identity holds permissionConcept · lights on your mappermissionOne specific thing an account is allowed to do, granted or withheld on its own. When the same screen shows a live button to one coworker and a dead one to another, one of these is the difference.s: atomic units of allowed action.

• May view orders
• May issue refunds
• May read customer PII
• May deploy to production

Atomic means each one is the smallest grant that can be given or taken away on its own. Holding one says nothing about holding the others, which is why they can be combined so precisely.

Watch one get checked. When Marcus in support clicks the refund button, the system does not consult the org chart. It asks whether the identity behind the request holds “may issue refunds,” and nothing else. Systems check permissions, not job titles, a fact that becomes visible the day someone’s title says “manager” but the button stays grey.

What is a role?

Nobody sane assigns thousands of permissions one identity at a time. Instead, permissions bundle into roleConcept · lights on your maproleA job-shaped grouping of permissions handed out as one unit, so nobody manages thousands of grants person by person. One assignment covers a new hire’s whole job.s: named bundles matching a job.

“Support agent” means view orders + issue refunds under $100. “Finance” means read reports + export data. Assign the role and the whole bundle comes with it.

The arithmetic is the argument. A company with two hundred employees and eighty distinct permissions would otherwise be managing sixteen thousand individual grants. With a dozen roles, it manages two hundred assignments.

What is role-based access control?

The whole arrangement is role-based access controlConcept · lights on your maprole-based access controlRBAC, the near-universal model for running access. People hold roles and roles hold the grants, which is why “what role do they have?” is the opening question whenever someone can’t see what they expected to., or RBAC, which manages access by assigning roles to identities rather than permissions to individuals. The name parses itself, since access is controlled by way of roles.

The “rather than” is carrying a real alternative. Permissions could attach to each person directly, and in small systems they sometimes do. RBAC inserts one level of indirection instead. Permissions attach to roles, people receive roles, and the two sides never touch directly.

The indirection pays off when things change. Raise the support team’s refund limit to $150, and one edit to the role updates every agent at once. Nobody visits Marcus’s account, or anyone else’s.

It is the model behind virtually every “manage team members” screen you have ever used. Adding someone to a role is a click on an admin screen, not a code change, which is why day-one access and promotions do not wait on engineers.

That grey-button mystery in every workplace, “why can’t I see the export?”, is almost always a role conversation. Now you can have it precisely, by asking what role do I have, and which role holds that permission?

What is least privilege?

The philosophy governing who gets which role is the most quietly important idea in this module. It is least privilegeConcept · lights on your mapleast privilegeGive an account only what its work needs today, and no more. The point is damage control rather than distrust, since whatever an account can do, its thief can also do, and so can its owner on a careless afternoon.: grant each identity the minimum access its job requires, nothing “just in case,” nothing extra.

The support agent can refund up to $100, not because larger refunds never happen but because when (not if) an agent’s account is phished, the thief inherits exactly those boundaries.

This is Module 8’s blast-radius thinking, pointed at people. The question is never “do we trust Marcus?” It is “what’s the damage if Marcus’s laptop is stolen tonight?”

Every unnecessary permission is pure downside. It is attack surface if the account is compromised and accident surface if its owner has a bad day. So wide permissions granted “to be safe” are precisely the opposite.

The mental model to remember

An identity is any verified actor, a customer, an employee, or software itself. Everything in access control hangs off one.

A permission is one atomic allowed action, and systems check permissions, not job titles.

A role is a named bundle of permissions matching a job. RBAC manages access by assigning roles to identities.

Least privilege grants the minimum the job requires. That is not stinginess but blast-radius engineering.

You should now be able to decode the grey button (“what role do I have?”) and the security review’s favorite question (“why does this account hold that permission?”).