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: When the rights within a capability 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.
- Explain: Without a live revocation check, a valid token can be used until it expires; RFC 6750 §5.3 recommends short-lived bearer tokens, while RFC 7662 describes token introspection for checking current state.
- Explain: Capabilities can express fine-grained, per-object rights: read a named sensor but write only its temperature setpoint, or open the trunk but never start the engine.
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)
Capability-based access control uses a different representation of authority.
- 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 clearest analogy is a physical key.
Major section
Overview: Authority You Hold, Not a Role You Have (continued)
In role-based access control, the system asks which roles the requester has and which permissions those roles carry.
- The system does not look you up in a list; it checks the token you present.
- “A capability is a claim until someone shows the token resists forgery and explains how its authority ends.”.
- A capability is a key for a particular action on a particular thing.
Major section
Overview: Authority You Hold, Not a Role You Have (continued)
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 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 capability is the ticket you carry; an access-control list is the list the doorkeeper holds.
- A capability is a held, unforgeable token that grants a specific right on a specific object.
- Delegable, but sticky: A holder can pass a capability (or a narrower subset) onward.
Major section
Overview: Authority You Hold, Not a Role You Have (continued)
Capabilities can express fine-grained, per-object rights: read a named sensor but write only its temperature setpoint, or open the trunk but never start the engine.
- A suitable system can let one device delegate a narrow slice of its authority to a neighbor without contacting a central issuer for each handoff.
- Rights within a capability can be encoded as compact permission flags, though the protected object reference and token also consume memory.
- 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 rights set combines several flags, and an access check confirms that all required bits are present, not merely some.
- The rights bits can fit in a couple of bytes, but the capability also needs a protected reference or authenticated token that binds them to an object.
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.
- Emergency shutdown sits at the operator's ceiling and requires a second person's approval.
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.
- A capability design could instead issue an operator narrowly scoped, time-limited authority for a named control, leaving the resource definitions untouched.
- The example avoids a combinatorial role table; RBAC with temporal extensions, or ABAC, could also handle changing shifts.
- A shared or valet key is an attenuated capability: for example, it can drive but cannot open the trunk or exceed a set speed.
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 rights sets are built by OR-ing flags together.
Major section
Under the Hood: Unforgeability, Delegation, and Revocation (continued)
When the rights within a capability 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.
- A rights set can fit in a small integer on a microcontroller; the complete capability still needs a protected object reference or authenticated token.
- Who: whoever holds the protected capability presents it for a check; a bitmask alone is not proof of authority.
Major section
Under the Hood: Unforgeability, Delegation, and Revocation (continued)
The verifier must check the protection, scope, and any expiry.
- Proof: the check is conjunctive -- every required bit must be present, not just one.
- Two established approaches are a protected reference, mediated by a runtime or kernel, and a cryptographically authenticated token.
- A plain client-editable string of flags is not an unforgeable capability.
Major section
Under the Hood: Unforgeability, Delegation, and Revocation (continued)
Unix file descriptors and seL4 kernel capabilities illustrate protected references; a process can pass a descriptor to another process as a delegation.
- Macaroons use chained MACs, and a signed or MAC-protected, time-limited URL can also carry authority if it names the resource and permitted operation.
- A central design question is whether the rights travel with the client or stay on the server.
- Without a live revocation check, a valid token can be used until it expires; RFC 6750 §5.3 recommends short-lived bearer tokens, while RFC 7662 describes token introspection for checking current state.
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.
- If instead you hand the client an opaque session identifier and keep its rights server-side, revocation can take effect on the next checked request, but you have moved back toward an ACL-style lookup.
- Delegation is a defining strength: a holder can pass a capability, or an attenuated subset of it, to another principal without a central issuer approving each handoff.
- Linux CAP_SYS_ADMIN is a broad process privilege, not an object capability like a seL4 reference, and is close to full root.
Major section
Under the Hood: Unforgeability, Delegation, and Revocation (continued)
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.
- Unsigned capability flags in client tokens: If the token is not cryptographically protected, the client simply forges its own rights.
Major section
Under the Hood: Unforgeability, Delegation, and Revocation (continued)
Assuming bearer tokens revoke instantly: A locally validated bearer token can remain usable until expiry unless the verifier checks revocation state.
- Over-broad ambient authority: A broad process privilege such as Linux CAP_SYS_ADMIN can defeat least authority when inherited or granted unnecessarily.
- No revocation path at all: Without revocation, a capability system can be weaker than a simple list; define expiry, revocation, or both and test the delay.
- At this depth, a capability is a precise, held authority that is only as good as its unforgeability and its revocation story.
Deck summary
Key takeaways
A broad staff role would also expose other rooms and controls.
- Capability-based access control uses a different representation of authority.
- In role-based access control, the system asks which roles the requester has and which permissions those roles carry.
- Here she reads capabilities the way she reads sessions: what the holder can do, how far it can travel, and how it gets revoked.
- Capabilities can express fine-grained, per-object rights: read a named sensor but write only its temperature setpoint, or open the trunk but never start the engine.
Retrieval practice
Recall check 1 of 4
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: D With capabilities, authority travels with the held token.
Retrieval practice
Recall check 2 of 4
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: C Narrow capabilities can carry each holder's rights for named objects without inventing a role for every combination.
Retrieval practice
Recall check 3 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q3A service gives a contractor a capability for one sensor. How should it delegate a narrower right?
Show answer
Answer: B Delegation should attenuate authority, with a clear lifetime or revocation path.
Retrieval practice
Recall check 4 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q4A system embeds signed admin permission flags in client JWTs with a 24-hour lifetime and keeps no server-side revocation state. An administrator's token is stolen. For how long can the attacker retain access if the verifier checks expiry but has no other revocation control?
Show answer
Answer: D In this scenario, the stolen bearer JWT remains usable for up to its remaining 24-hour lifetime because verifiers have no revocation state.
Print reference
Answers
Answer key.
- D · With capabilities, authority travels with the held token.
- C · Narrow capabilities can carry each holder's rights for named objects without inventing a role for every combination.
- B · Delegation should attenuate authority, with a clear lifetime or revocation path.
- D · In this scenario, the stolen bearer JWT remains usable for up to its remaining 24-hour lifetime because verifiers have no revocation state.