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.

access-controlrbacabac

Shield Shelly, the module guide, in a scene from this chapter.

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.

RBAC authorization flow: map the identity to a role, look up that role's permissions, then grant or deny the requested action.

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)

Doctors may prescribe, nurses may administer, and visitors may only visit.

A fifth style, capability-based access, grants rights by holding an unforgeable token and has its own chapter.
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.

Device identity has a full lifecycle: provision a key at manufacture, bind a certificate at deployment, authorize during operation, and revoke at decommission.

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.

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), preferred over the older SCEP.
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.

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.”.
Doctors may prescribe, nurses may administer, and visitors may only visit.

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?

ANo access by default; grant only the role's needed resources

BFull administrative access, to be narrowed later once the role is understood

CThe same permissions as every other account, for consistency

DAccess to everything except clearly dangerous actions

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?

AThe Client Credentials grant, since it is the simplest option

BThe Authorization Code grant with PKCE running in the device's local browser

CThe Implicit grant, because it returns a token quickly

DThe Device Authorization Grant (device code flow).

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?

AAccess is denied, because an explicit Deny always overrides any Allow in the policy evaluation

BAccess is granted, because the Allow statement is broader and broader rules take precedence

CAccess is granted, because the Allow statement appears first

DThe result is undefined, because Allow and Deny conflict

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.