Authentication & Access Control · Study deck
IoT Access Control: Models and Policy
A floor controller may read heat data but must not unlock doors.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- compare role, attribute, and capability access models
- evaluate policy scope, certificate life, and deny behaviour
- Explain: It needs to read temperatures and adjust lights on floor three, but it should not unlock doors or change another floor.
- Explain: Access control is the second gate: after identity is trusted, it limits the action to the smallest useful scope.
Major section
Overview: From Proven Identity to Scoped Permission
It needs to read temperatures and adjust lights on floor three, but it should not unlock doors or change another floor.
- Identity answers who is asking.
- Permission must still answer which action is allowed on which resource.
- A gateway is a device that passes local device traffic into another service path.
Major section
Overview: From Proven Identity to Scoped Permission (continued)
Access control is the second gate: after identity is trusted, it limits the action to the smallest useful scope.
- This exercise does not prove every user or fleet rule.
- Choosing the right model is what keeps a fleet of thousands of devices both secure and manageable.
- Best when decisions are dynamic or multi-tenant.
Major section
Overview: From Proven Identity to Scoped Permission (continued)
The common models differ in who decides and *on what basis*.
- The deeper sections compare owner-set, centrally set, role-based, attribute-based, and token-held permission models, then show where each one becomes hard to manage.
- That still does not mean it should read every tenant's data, change another floor's locks, or publish commands for a valve it does not own.
- The practical sweet spot when job categories are stable.
Major section
Overview: From Proven Identity to Scoped Permission (continued)
“Proving who you are only opens the first gate -- I still want to see the scope on the second one.”.
- Through this chapter she follows one thing: how a proven identity gets narrowed down to the smallest permission it actually needs.
- With mandatory access control (MAC) a central policy decides and users have no discretion.
- With role-based access control (RBAC) permissions are grouped into roles and identities are assigned roles.
Major section
Overview: From Proven Identity to Scoped Permission (continued)
A fifth style, capability-based access, grants rights by holding an unforgeable token and has its own chapter.
- Every model is a way to enforce least privilege -- each identity gets only the access it needs and nothing more.
- Doctors may prescribe, nurses may administer, and visitors may only visit.
- DAC and MAC: DAC lets owners grant access; flexible but hard to govern.
- MAC enforces a central policy; rigid but strong for classified systems.
Major section
Practitioner: Choose a Model and Provision Identity
For a device with no user at all, a pre-provisioned device certificate is often a better fit than any OAuth flow.
- The lesson is that roles give a clean baseline while attributes enforce the situational rules roles cannot express.
Major section
Practitioner: Choose a Model and Provision Identity (continued)
Authorization is only as trustworthy as the identity behind it, so device identity must be provisioned deliberately.
- At the platform level, distinguish human identity and access management (IAM) from the management of machine and device identities, which have their own enrolment and lifecycle.
- A unique key is first provisioned, deployment binds that key to an approved device record, operation repeatedly authenticates the device before applying its scoped policy, and decommission revokes the credential and removes residual secrets.
- If you can choose a model, pick an OAuth grant, and provision per-device identity, you can stop here.
Major section
Under the Hood: Policy Evaluation, Certificate Lifecycle, and Failure Modes
The deeper layer explains how an authorization decision is actually computed and how device identity is maintained over years of operation.
- The recurring theme is that authorization fails when a policy is broader than intended or when a credential outlives its trust.
- Every decision is logged.
Major section
Under the Hood: Policy Evaluation, Certificate Lifecycle, and Failure Modes (continued)
It then selects policies that match the requested action and evaluates each policy's conditions, all of which must be true.
- The decisive rules are precedence and default: an explicit deny overrides any allow, and if no policy grants access the request is denied by default.
- Each statement is checked for an action match and a resource match; an explicit Deny always wins over any Allow, and if nothing allows the action it is implicitly denied.
- Enrolment and renewal are commonly automated with EST (RFC 7030), generally preferred for new designs over SCEP, which remains common in legacy fleets.
Major section
Under the Hood: Policy Evaluation, Certificate Lifecycle, and Failure Modes (continued)
RAM and energy depend on the implementation, so measure them on the target hardware.
- The damage a compromised device can do scales with the breadth of its permissions: a device scoped to its own telemetry is a small blast radius, while a device holding wildcard rights is a large one.
- The same logic applies to identifiers -- use long random token or session identifiers (at least 128 bits) so they cannot be guessed or collide across a large fleet.
- Proof: token and session identifiers stay at least 128 bits so they can't be guessed across a large fleet.
Major section
Under the Hood: Policy Evaluation, Certificate Lifecycle, and Failure Modes (continued)
No effective revocation path: A CRL, OCSP, local denylist, or registry state must enforce the chosen policy; without one, a stolen certificate may work until expiry.
- Uniform permissions across device types: A weather sensor and a valve actuator should not share a policy; scope to each role.
- Wildcard development policies in production: A convenient "allow all" left in place is a standing breach.
- Treating OAuth as authentication: OAuth authorizes; use OIDC if you need to authenticate the user.
Deck summary
Key takeaways
It needs to read temperatures and adjust lights on floor three, but it should not unlock doors or change another floor.
- Access control is the second gate: after identity is trusted, it limits the action to the smallest useful scope.
- The common models differ in who decides and *on what basis*.
- “Proving who you are only opens the first gate -- I still want to see the scope on the second one.”.
- A fifth style, capability-based access, grants rights by holding an unforgeable token and has its own chapter.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1A new technician account is created in an IoT platform. Following least privilege, what should its initial access be?
Show answer
Answer: A Least privilege means starting from zero and adding only what is required, so an over-broad default never silently grants more than intended.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2An input-constrained IoT device with no browser needs a user to authorize it for cloud access by approving the request on their phone. Which OAuth 2.0 grant fits?
Show answer
Answer: D The device code flow (RFC 8628) is designed for browserless, input-limited devices that need a user to approve access elsewhere.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3An AWS IoT-style policy contains a broad statement that Allows publishing to all device topics and a separate statement that explicitly Denies publishing to another tenant's topics. A device tries to publish to another tenant's topic. What happens?
Show answer
Answer: A These engines evaluate all statements and an explicit Deny wins over any Allow, so the cross-tenant publish is blocked despite the broad allow.
Print reference
Answers
Answer key.
- A · Least privilege means starting from zero and adding only what is required, so an over-broad default never silently grants more than intended.
- D · The device code flow (RFC 8628) is designed for browserless, input-limited devices that need a user to approve access elsewhere.
- A · These engines evaluate all statements and an explicit Deny wins over any Allow, so the cross-tenant publish is blocked despite the broad allow.