Authentication & Access · Study deck
Capability-Based Access Control
Picture a service worker who needs to open one plant-room door and reset one air unit before noon.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: With pure RBAC, every combination tends to spawn its own role -- a day-shift level-three role, a night-shift level-three role, and so on -- until the role list is unmanageable.
- Explain: Because a capability bundles the object designation with the authority, the caller must supply the capability for the specific object, so a deputy cannot be steered onto something it was not given.
- Explain: A robust design distinguishes a user's or device's base capabilities, granted by default, from its maximum capabilities, an absolute ceiling it can never exceed even when temporarily elevated.
Major section
Overview: Authority You Hold, Not a Role You Have
A broad staff role would also expose other rooms and controls.
- Loss of a distant check should not turn into broad access by default.
- This opening does not claim that held rights beat roles in every system.
- Practitioner maps issue, use, handoff, and removal.
- Holding the capability is the permission.
Major section
Overview: Authority You Hold, Not a Role You Have (continued)
Under the Hood examines how rights are made unforgeable, narrowed, stored, passed on, and revoked.
- Sometimes the easiest permission to reason about is not a name on a list.
- The system does not look you up in a list; it checks the token you present.
- The clearest analogy is a physical key.
Major section
Overview: Authority You Hold, Not a Role You Have (continued)
A capability is a key for a particular action on a particular thing.
- “A capability is a claim until someone shows the token resists forgery and can still be taken back.”.
- Here she reads capabilities the way she reads sessions: what the holder can do, how far it can travel, and how it gets revoked.
- A capability is the ticket you carry; an access-control list is the list the doorkeeper holds.
Major section
Overview: Authority You Hold, Not a Role You Have (continued)
A key to room 12 does not care who you are -- whoever holds it can open room 12, and they can hand it to someone else.
- If you only need the intuition, this layer is enough: a capability is a held, unforgeable token that grants a specific right on a specific object.
- They allow one device to delegate a narrow slice of its authority to a neighbor without a central server in the loop.
- Unforgeable token:: Possession grants the right, so the token must be impossible to forge -- protected by the runtime or signed cryptographically.
Major section
Overview: Authority You Hold, Not a Role You Have (continued)
A narrow key can reduce harm, but possession still matters and taking back a copy may be hard.
- Delegable, but sticky:: A holder can pass a capability (or a narrower subset) onward.
- The trade-off is that revoking it is harder than deleting a list entry.
- If you can explain why authority travels with a held token, you have the core idea.
Major section
Practitioner: Represent, Compose, and Choose
A composite "role-like" set is just several flags combined, and an access check confirms that all required bits are present, not merely some.
- The appeal is precision: you grant exactly the rights needed and nothing more, and on a constrained device the whole set fits in a couple of bytes.
Major section
Practitioner: Represent, Compose, and Choose (continued)
A robust design distinguishes a user's or device's base capabilities, granted by default, from its maximum capabilities, an absolute ceiling it can never exceed even when temporarily elevated.
- A canElevate flag controls whether elevation is allowed at all.
- Proof: the audit trail names exactly which extra rights were used and who approved them.
- The capability model captures "who may do exactly what, right now" without a combinatorial role table.
Major section
Practitioner: Represent, Compose, and Choose (continued)
With pure RBAC, every combination tends to spawn its own role -- a day-shift level-three role, a night-shift level-three role, and so on -- until the role list is unmanageable.
- With capabilities, you instead edit a single operator's granted rights when their shift or certification changes, leaving the resource definitions untouched.
- Digital vehicle keys are a familiar illustration.
- A capability that can be forged or copied is no capability at all.
Major section
Under the Hood: Unforgeability, Delegation, and Revocation
The deeper layer explains what makes a capability actually work and where the model breaks.
- Two properties carry the whole design: the token must be impossible to forge, and the system must have an answer for taking authority back.
- Composite sets are built by OR-ing flags together.
Major section
Under the Hood: Unforgeability, Delegation, and Revocation (continued)
When capabilities are represented as flags, each permission is an independent bit position, not a step in a ladder -- setting the fourth bit does not imply the first three.
- An access check is conjunctive: the granted set must contain every required bit, which is the bitwise test (granted & required) == required.
- This compactness is why the model fits microcontrollers, where a full permission set is a single small integer.
- Who: whoever holds the granted bitmask presents it for every check.
- Proof: the check is conjunctive -- every required bit must be present, not just one.
Major section
Under the Hood: Unforgeability, Delegation, and Revocation (continued)
The danger to manage is the opposite: ambient authority, where capabilities are inherited automatically and broadly.
- A capability that is merely a plain string of flags, with nothing protecting it, is forgeable and therefore worthless.
- A central design question is whether the rights travel with the client or stay on the server.
- An over-broad inherited privilege -- the Linux CAP_SYS_ADMIN capability is close to full root -- undermines least authority.
Major section
Under the Hood: Unforgeability, Delegation, and Revocation (continued)
Delegation is a defining strength: a holder can pass a capability, or an attenuated subset of it, to another principal, enabling decentralized authorization with no central gatekeeper.
- Capabilities also resist the confused-deputy problem, in which a privileged program is tricked into misusing its broad authority on an object an attacker names.
- A capability system should record categorized audit events -- access attempted versus granted, elevation requested, and denials -- rather than flat log lines.
- Categorized events let monitoring raise alerts automatically (a burst of denied elevations is a probing signal) and make compliance forensics tractable.
Major section
Under the Hood: Unforgeability, Delegation, and Revocation (continued)
At this depth, a capability is a precise, held authority that is only as good as its unforgeability and its revocation story.
- Represent rights as independent flags, protect the token by the runtime or by cryptography, delegate by narrowing, and decide deliberately whether authority lives with the client or the server.
- A trustworthy review checks that forged tokens are rejected, that delegation cannot widen rights, and that revocation actually works.
- Because a capability bundles the object designation with the authority, the caller must supply the capability for the specific object, so a deputy cannot be steered onto something it was not given.
Deck summary
Key takeaways
A broad staff role would also expose other rooms and controls.
- Under the Hood examines how rights are made unforgeable, narrowed, stored, passed on, and revoked.
- A capability is a key for a particular action on a particular thing.
- A key to room 12 does not care who you are -- whoever holds it can open room 12, and they can hand it to someone else.
- A narrow key can reduce harm, but possession still matters and taking back a copy may be hard.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1What most fundamentally distinguishes a capability from a role in role-based access control?
Show answer
Answer: A With capabilities, authority travels with the held token.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A platform must grant many users their own custom combination of fine-grained permissions, and creating a separate role for each combination has become unmanageable. Which model addresses this most directly?
Show answer
Answer: A Capabilities express per-user custom rights directly, avoiding the role explosion that RBAC suffers when every combination needs its own role.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3A system embeds signed permission flags directly in client JWTs with a 24-hour lifetime and keeps no server-side session state. An administrator's token is stolen. For how long can the attacker retain admin access, and what is the fix?
Show answer
Answer: A Authority lives in the holder's signed token, so without revocation state it stays valid until expiry.
Print reference
Answers
Answer key.
- A · With capabilities, authority travels with the held token.
- A · Capabilities express per-user custom rights directly, avoiding the role explosion that RBAC suffers when every combination needs its own role.
- A · Authority lives in the holder's signed token, so without revocation state it stays valid until expiry.