8  Auth & Authorization Concepts

Learning Objectives

After completing this chapter, you will be able to:

  • Apply the AAA framework (Authentication, Authorization, Accounting) to evaluate IoT security implementations
  • Identify common authentication anti-patterns and explain their security implications
  • Map lab-based access control concepts to production systems including OAuth 2.0, AWS IAM, and Kubernetes RBAC
  • Distinguish between authentication (identity verification) and authorization (permission checking) in system design

Access control determines what each user or device is allowed to do in an IoT system. Think of a hospital where doctors, nurses, and visitors each have different access levels – doctors can prescribe medication, nurses can administer it, and visitors can only visit patients. Similarly, IoT access control ensures each device and user can only perform actions appropriate to their role.

“AAA is not a battery size,” Max the Microcontroller joked. “In security, AAA stands for Authentication, Authorization, and Accounting. You need ALL three!”

Sammy the Sensor demonstrated. “Authentication answers ‘Who are you?’ – like showing your school ID card. I scan my credentials and the system verifies I am really Sammy. Authorization answers ‘What can you do?’ – Sammy can read sensors but cannot change system settings. And Accounting answers ‘What did you do?’ – every action gets logged so we can look back and see what happened.”

“Here is the dangerous part,” Lila the LED warned. “If you have authentication without authorization, everyone who logs in gets FULL access. That is like a building where everyone with an ID badge can enter every room, including the server room and the CEO’s office. You need authorization to limit people to only the rooms they actually need.”

“And without accounting, you cannot investigate what happened when something goes wrong,” Bella the Battery added. “Imagine a bank with no security cameras – if money goes missing, you have no way to find out who took it! Audit logs are the security cameras of the digital world. In production systems, this maps directly to OAuth 2.0 for authentication, RBAC or ABAC policies for authorization, and SIEM systems for accounting.”

8.1 Key Authentication Concepts

The AAA Framework

Enterprise security systems use the “AAA” framework:

Component Question This Lab Production Example
Authentication Who are you? Card ID lookup OAuth login, biometrics
Authorization What can you do? Access level check RBAC, ABAC policies
Accounting What did you do? Audit log SIEM, CloudTrail

All three are essential. Authentication without authorization means everyone gets full access. Authorization without accounting means you cannot investigate incidents.

Common Security Mistakes Demonstrated

This lab intentionally shows what NOT to do in production:

Lab Shortcut Production Requirement
Hardcoded credentials Store in secure element (ATECC608B, TPM)
Plain text card IDs Encrypted credential storage
In-memory audit log Persistent, tamper-evident logging
Single-factor auth Multi-factor authentication (MFA)
Local database Centralized identity provider (LDAP, Active Directory)
No encryption TLS for all communications

8.2 Connecting to Real-World Systems

From Lab to Production
Lab Implementation Production Equivalent
RFID card IDs Smart cards with cryptographic challenge-response
Hardcoded user database LDAP/Active Directory integration
Serial monitor Secure management API (TLS + client certificates)
LED indicators Security Operations Center (SOC) dashboards
Buzzer alerts SIEM integration, SMS/email notifications
Simple lockout Adaptive authentication with risk scoring
Role hierarchy Attribute-Based Access Control (ABAC)

Real-world systems these lab concepts apply to: - Corporate badge access (HID, SALTO) - Data center entry (biometric + card + PIN) - AWS IAM policies (principals, resources, actions) - Kubernetes RBAC (roles, bindings, service accounts) - OAuth 2.0 / OpenID Connect (tokens, scopes, claims)

8.3 Worked Example: Designing AAA for a Hospital IoT Network

Scenario: A hospital deploys 3,000 IoT devices across 5 buildings: patient monitors (1,200), infusion pumps (800), environmental sensors (600), and staff badge readers (400). Design the AAA architecture and calculate the credential management overhead.

Requirements:

  • HIPAA compliance (audit trail for all PHI access)
  • Device lifetime: 7 years average
  • Staff turnover: 25% annually (400 of 1,600 clinical staff)
  • Network: Segregated VLANs per device class
  • Budget: $250,000 for identity infrastructure

Step 1: Authentication – Device Identity Architecture

Device Class Auth Method Credential Storage Provisioning
Patient monitors (1,200) X.509 cert + mTLS ATECC608B secure element ($0.65/unit) Factory provisioned via EST protocol
Infusion pumps (800) X.509 cert + mTLS TPM 2.0 (built into MCU) Manufacturer PKI enrollment
Environmental sensors (600) PSK + DTLS Encrypted NVS (no secure element) Bulk provisioned via QR code
Badge readers (400) Network cert + 802.1X Software keystore IT department manual setup

Cost of secure elements for patient monitors: 1,200 x $0.65 = $780

Compare to breach cost: Average healthcare data breach costs $10.93 million (IBM 2023). The $780 investment protects the highest-risk devices (those with direct PHI access).

Step 2: Authorization – Role-Based Access Control Matrix

Role Patient Monitors Infusion Pumps Env Sensors Audit Logs
Nurse Read vitals Start/stop infusion, adjust rate Read temperature View own actions
Doctor Read vitals, acknowledge alarms Full control, override limits No access View department
Biomedical Engineer Configure thresholds, firmware update Calibrate, firmware update Full control View device logs
IT Admin Network config only Network config only Network config Full audit access
Device (M2M) Report vitals to EMR Report dosage to pharmacy Report to BMS Write own events

Permission count: 5 roles x 4 device classes x ~4 actions each = ~80 permission rules

Using RBAC (Role-Based) vs ABAC (Attribute-Based):

RBAC approach:
  5 roles x 4 device classes = 20 role-device mappings
  Simple to audit, but coarse-grained
  Problem: Nurse on Floor 3 can read monitors on Floor 7

ABAC approach:
  Attributes: role + department + floor + shift + device_owner
  Policy: "Nurse can read vitals IF device.floor == nurse.floor
           AND device.department == nurse.department
           AND current_time IN nurse.shift_hours"
  Fine-grained, but 80+ attribute rules to maintain

Hospital decision: ABAC for clinical devices (patient safety),
                   RBAC for infrastructure devices (simpler)

Step 3: Accounting – Audit Log Sizing

Calculate storage requirements for HIPAA-compliant audit trails:

Events per device per day:
  Patient monitor: 1,440 (1/min vitals) + 5 (alarms) + 2 (nurse interactions) = 1,447
  Infusion pump: 96 (status every 15 min) + 8 (rate changes) + 3 (nurse actions) = 107
  Environmental sensor: 96 (every 15 min) = 96
  Badge reader: 50 (entries/exits per reader per day) = 50

Daily log volume:
  1,200 x 1,447 = 1,736,400 monitor events
  800 x 107 = 85,600 pump events
  600 x 96 = 57,600 sensor events
  400 x 50 = 20,000 badge events
  Total: 1,899,600 events/day

At 256 bytes per log entry (timestamp + device ID + user + action + result):
  Daily: 1,899,600 x 256 = 486 MB/day
  HIPAA requires 6-year retention: 486 MB x 365 x 6 = 1,064 GB ≈ 1.04 TB

Storage cost: ~$24/month for 1 TB cloud storage with encryption

Step 4: Credential Lifecycle Cost

Annual credential operations:
  Staff turnover (25%): 400 staff x (revoke old + provision new) = 800 operations
  Certificate renewal (3-year cycle): 1,000 devices/year
  Compromised credential replacement: ~20/year (lost badges, suspected breaches)
  Total: 1,820 credential operations/year

At 15 minutes per manual operation: 1,820 x 0.25 hrs = 455 hours/year
At $75/hr IT staff cost: $34,125/year for manual credential management

With automated PKI (EST + SCEP):
  Automated operations: 1,600 of 1,820 (88%)
  Manual operations: 220 (compromised creds + exceptions)
  Cost: 220 x 0.25 hrs x $75 = $4,125/year
  PKI platform license: $18,000/year
  Total: $22,125/year (saves $12,000/year vs manual)
  Break-even: Year 2 (after $40,000 initial setup)

Result: The complete AAA infrastructure costs approximately $63,193 in year one ($40,000 PKI setup + $18,000 license + $780 secure elements + $288 storage at $24/mo + $4,125 manual ops) and $22,413/year ongoing ($18,000 license + $288 storage + $4,125 manual ops). This protects against an average healthcare breach cost of $10.93 million – an ROI of over 170:1.

Key lesson: The most expensive part of AAA is not the technology but the ongoing credential management. Automating 88% of credential operations through PKI protocols (EST, SCEP) saves $12,000/year and eliminates human error in the most security-critical operations. The cheapest component – $780 for secure elements – provides the strongest authentication guarantee.

8.4 Interactive Calculators

An authentication system’s risk score \(R\) is the product of probability \(P\) of unauthorized access and impact \(I\) of a security breach.

\[R = P \times I\]

For biometric authentication, the False Accept Rate (FAR) and False Reject Rate (FRR) create a tradeoff:

\[\text{FAR} = P(\text{accept impostor}) \quad ; \quad \text{FRR} = P(\text{reject legitimate user})\]

Use the calculator below to explore how changing FAR, FRR, employee count, and breach cost affects your risk exposure.

Use this calculator to estimate audit log storage requirements for HIPAA-compliant IoT deployments. Adjust device counts and event rates to match your scenario.

8.5 Knowledge Check

8.6 Concept Relationships

How AAA Framework Concepts Connect
Core Concept Builds On Enables Common Confusion
Authentication (who) Identity verification methods Authorization decisions “Is a password authentication or authorization?” - Authentication only. It proves identity, not permissions
Authorization (what) Authentication results Access control enforcement “Can authorization work without authentication?” - No. You must know WHO before determining WHAT they can do
Accounting (audit) Both auth and authz events Forensics, compliance, anomaly detection “Isn’t logging the same as accounting?” - Accounting is structured event logging with security-specific metadata
RBAC (roles) User groupings Simplified permission management “Do all users in a role have identical access?” - Yes for RBAC; no for capability-based extensions
ABAC (attributes) Context-aware policies Time/location/device restrictions “When to use RBAC vs ABAC?” - RBAC for hierarchies; ABAC for context-dependent rules

Key Insight: The AAA framework provides separation of concerns - authentication verifies identity (who), authorization determines permissions (what), and accounting records actions (audit trail). Each serves a distinct security function.

8.7 See Also

Within This Module:

Related Security Topics:

Production Systems:

  • OAuth 2.0 / OpenID Connect - Industry-standard authentication and authorization
  • AWS IAM - Cloud resource access control with policies and roles
  • Kubernetes RBAC - Container orchestration access management
  • LDAP/Active Directory - Enterprise identity and access management

Common Pitfalls

Defining permissions directly on individual users rather than through roles creates an unmaintainable access control system. When one user needs new access, you edit their record; when a regulatory change requires all admins to lose a permission, you must modify hundreds of user records. Always assign permissions to roles, not users.

Teams often design 30+ roles to handle every possible future case, creating role explosion. Most IoT systems need only 3–7 roles (Device, Viewer, Operator, Admin, SuperAdmin). Start minimal and add roles only when operational requirements clearly demand them.

ABAC’s flexibility comes with complexity — policies are harder to audit, debug, and understand than RBAC. Use RBAC as the foundation for most access control, and apply ABAC only for the subset of decisions that genuinely require attribute-based context (time of day, location, device health status).

Access control systems that grow organically without documentation become impossible to audit or modify safely. Maintain a living document describing every role, its permissions, the business justification, and the process for requesting role membership changes.

8.8 What’s Next

After understanding these core authentication concepts, you can:

Key Concepts

  • Access Control List (ACL): A list of rules attached to a resource specifying which principals have which permissions; traditional approach that scales poorly with many users and resources
  • Role-Based Access Control (RBAC): Assigns permissions to roles and assigns users to roles; more scalable than ACLs because role changes propagate immediately to all members
  • Attribute-Based Access Control (ABAC): Makes access decisions using policy rules evaluated against user attributes, resource attributes, and environmental context; most flexible but complex to manage
  • Mandatory Access Control (MAC): A system-enforced access policy where resource owners cannot override access rules; used in high-security government and military systems
  • Discretionary Access Control (DAC): The owner of a resource can grant access to others; most common in commercial systems but vulnerable to confused deputy attacks
  • Principal: Any entity that can be authenticated and granted permissions; includes users, devices, services, and automated processes
  • Resource: Any system element that access control protects; includes API endpoints, database tables, device actuators, configuration files, and firmware images
In 60 Seconds

Authentication and authorization concepts — including RBAC, ABAC, ACLs, and the principle of least privilege — form the theoretical foundation for building IoT access control systems that correctly distinguish between “who can access this device” and “what operations this role can perform on this device.”

Or return to the Authentication and Access Control Overview.