13 Advanced Access Control: Capability-Based Authorization

13.1 Start With the Decision

A capability grants one subject a narrow right to one object. Set its scope, lifetime, and revocation path before use.

13.2 Route Overview

This is part 1 of 2. Continue with Advanced Access Control: Token Lifecycles and Sessions.

13.3 Part Objectives

• Test capability-based access control (cbac) with a concrete scenario and pass criteria.
• Choose a defensible design using decision framework: choosing session timeout values.

13.4 Start With the Story

Give Each Request the Smallest Safe Right

Picture a shared service desk. One worker may view a machine, another may change a limit, and a supervisor may approve an urgent action for ten minutes. A single “staff” label is too broad for all three jobs.

Access control is the rule set that decides who or what may perform an action. Start with one request. Name the person or device, the exact action, the target, and the allowed time. Grant only that right. Refuse the request when any needed fact is missing.

Keep time and change in the design. End an idle session. Set a firm final end. Replace old proof before it expires. Revoke it after loss, role change, or suspected misuse. Check that a user cannot grant a stronger right than they hold.

Test each refusal. Use no identity. Use an old right. Use the wrong target. Use the wrong time. Ask for too much. Try after logout. Try after loss. Try after role change. Save each result. Make every denial clear.

A device may also need to prove that its software is in an accepted state. That check helps, but it does not prove the device is harmless or that every request is valid.

Use Practitioner to build sessions, rights, and safe failure tests. Use Under the Hood for proof, device state, token, and attack limits.

Imagine the lab system has left the workbench and now protects a shared maintenance console. A technician may read telemetry, a supervisor may change thresholds, an emergency role may act for ten minutes, and a device with modified firmware should be challenged even if it still has a valid key. This chapter adds the policy machinery that keeps those cases separate: capability flags, sessions, token lifecycle, privilege escalation checks, ABAC, and attestation.

The IoT lesson is that advanced access control is mostly about time, context, and failure. Start simple: give one subject a limited capability, expire a session, revoke a token, and verify that stale or overprivileged requests fail closed before trusting the design in a fleet.

13.5 Learning Objectives

By completing this chapter, you will understand:

• Capability-based access control with fine-grained bit-flag permissions
• Session management with idle timeouts and maximum durations
• Token lifecycle management including issuance, validation, refresh, and revocation
• Privilege escalation prevention through detection and blocking mechanisms
• Attribute-based access control with time and context restrictions
• Device attestation for verifying firmware integrity

13.6 Capability-Based Access Control (CBAC)

While RBAC assigns permissions to roles, capability-based access control uses fine-grained bit flags for permissions:

// Capability flags using bit operations
const uint16_t CAP_NONE         = 0x0000;
const uint16_t CAP_READ         = 0x0001;  // Read sensor data
const uint16_t CAP_WRITE        = 0x0002;  // Write configuration
const uint16_t CAP_EXECUTE      = 0x0004;  // Execute commands
const uint16_t CAP_DELETE       = 0x0008;  // Delete records
const uint16_t CAP_CREATE       = 0x0010;  // Create new resources
const uint16_t CAP_ADMIN_READ   = 0x0020;  // Read admin data
const uint16_t CAP_ADMIN_WRITE  = 0x0040;  // Write admin config
const uint16_t CAP_GRANT        = 0x0080;  // Grant permissions to others
const uint16_t CAP_REVOKE       = 0x0100;  // Revoke permissions
const uint16_t CAP_AUDIT        = 0x0200;  // Access audit logs
const uint16_t CAP_EMERGENCY    = 0x0400;  // Emergency override
const uint16_t CAP_DEBUG        = 0x0800;  // Debug/diagnostic access

// Composite capability sets
const uint16_t CAP_BASIC_USER = CAP_READ | CAP_EXECUTE;
const uint16_t CAP_POWER_USER = CAP_BASIC_USER | CAP_WRITE | CAP_CREATE;
const uint16_t CAP_OPERATOR = CAP_POWER_USER | CAP_DELETE | CAP_ADMIN_READ;
const uint16_t CAP_ADMIN = CAP_OPERATOR | CAP_ADMIN_WRITE | CAP_GRANT | CAP_REVOKE | CAP_AUDIT;
const uint16_t CAP_SUPERUSER = 0xFFFF;  // All capabilities

bool hasCapability(uint16_t granted, uint16_t required) {
    // All required bits must be present in granted
    return (granted & required) == required;
}

13.7 Session Management

Sessions provide time-bounded access with multiple safeguards:

struct Session {
    uint32_t sessionId;
    char userId[16];
    unsigned long startTime;
    unsigned long lastActivity;
    unsigned long maxDuration;
    uint8_t tokenCount;
    bool isElevated;
    unsigned long elevatedUntil;
    uint16_t currentCapabilities;
    uint8_t failedElevationAttempts;
};

bool validateSession(Session* session) {
    if (session == NULL || session->sessionId == 0) return false;

    unsigned long now = millis();

    // Check session duration
    if (now - session->startTime > session->maxDuration) {
        Serial.println("Session expired: Maximum duration exceeded");
        return false;
    }

    // Check idle timeout
    if (now - session->lastActivity > SESSION_IDLE_TIMEOUT) {
        Serial.println("Session expired: Idle timeout");
        return false;
    }

    // Check elevation expiry
    if (session->isElevated && now > session->elevatedUntil) {
        Serial.println("Elevation expired - reverting to base capabilities");
        dropElevation(session);
    }

    return true;
}

13.8 Token Lifecycle Management

Tokens provide short-lived access credentials with controlled lifecycle:

struct AccessToken {
    uint32_t tokenId;           // Unique token identifier
    char userId[16];            // Associated user ID
    uint16_t capabilities;      // Granted capabilities (bit flags)
    unsigned long issuedAt;     // Token creation timestamp
    unsigned long expiresAt;    // Token expiration timestamp
    unsigned long lastActivity; // Last use timestamp
    uint8_t refreshCount;       // Number of times refreshed
    bool isRevoked;             // Revocation status
    uint32_t sessionId;         // Associated session
    char issuedBy[16];          // Who issued this token
};

bool validateToken(AccessToken* token) {
    if (token == NULL || token->tokenId == 0) return false;

    // Check blacklist
    if (isTokenBlacklisted(token->tokenId)) {
        Serial.println("Token REJECTED: Blacklisted");
        return false;
    }

    // Check revocation
    if (token->isRevoked) {
        Serial.println("Token REJECTED: Revoked");
        return false;
    }

    // Check expiration
    if (millis() > token->expiresAt) {
        Serial.println("Token REJECTED: Expired");
        return false;
    }

    // Update activity
    token->lastActivity = millis();
    return true;
}

bool refreshToken(AccessToken* token) {
    if (token == NULL || !validateToken(token)) return false;

    // Rate limit refreshes (measured from last refresh or issuance)
    unsigned long lastRefreshTime = (token->refreshCount > 0)
        ? token->expiresAt - TOKEN_LIFETIME  // Approximate last refresh
        : token->issuedAt;

    if (millis() - lastRefreshTime < MIN_TOKEN_REFRESH_INTERVAL) {
        Serial.println("Token refresh denied: Too soon");
        return false;
    }

    // Limit refresh count
    if (token->refreshCount >= MAX_TOKEN_REFRESHES) {
        Serial.println("Token refresh denied: Max refreshes reached");
        return false;
    }

    token->expiresAt = millis() + TOKEN_LIFETIME;
    token->refreshCount++;
    return true;
}

13.9 API Keys vs Tokens

Understanding the difference between long-lived API keys and short-lived tokens is critical for IoT security design. API keys are typically long-lived strings (valid for months or years) that identify an application or device. Tokens (such as JWTs) are short-lived credentials (minutes to hours) that are cryptographically signed and can carry scoped permissions. The key distinction: if an API key is compromised, the attacker has access until the key is manually revoked; if a token is stolen, access expires automatically.

13.10 Privilege Escalation Prevention

Privilege escalation prevention compares the requested capability set with the maximum set assigned to the authenticated user. Follow the code from attemptedCaps to forbidden: the bit mask retains only requested capabilities outside that maximum. A non-zero result increments the attempt record, writes the requested and current sets to the audit trail, and ends the session when the local repeated-attempt rule is met. The action denies an unauthorised capability; it does not silently elevate the session or infer motive from a single request.

bool detectEscalationAttempt(Session* session, uint16_t attemptedCaps) {
    if (session == NULL) return false;

    UserProfile* user = findUser(session->userId);
    if (user == NULL) return false;

    unsigned long now = millis();

    // Check if attempting capabilities beyond max allowed
    uint16_t forbidden = attemptedCaps & ~user->maxCapabilities;
    if (forbidden != 0) {
        escalationAttempts++;
        lastEscalationTime = now;

        Serial.println("\n!!! ESCALATION ATTEMPT DETECTED !!!");
        Serial.print("Attempted forbidden capabilities: ");
        printCapabilities(forbidden);

        logAudit(AUDIT_ESCALATION_ATTEMPT, session->userId, "SECURITY",
                attemptedCaps, session->currentCapabilities, false, "Forbidden caps");

        // Check for sustained attack
        if (escalationAttempts >= MAX_ESCALATION_ATTEMPTS &&
            (now - lastEscalationTime) < ESCALATION_WINDOW) {
            Serial.println("!!! SECURITY LOCKDOWN INITIATED !!!");
            endSession(session);
            return true;
        }
        return true;
    }
    return false;
}

13.11 Attribute-Based Access Control (ABAC)

Adding context-based restrictions to access decisions:

Run it: ABAC is easiest to feel by composing policies and watching the decision, which is what the policy workbench below does. In the Policy Composer, Add Policy rules that gate a resource on attributes such as role and context, Validate Policy, then submit an Access Request and press Evaluate Access to read the Decision Path and Evaluation Trace. Change the Request Context — including the kind of hour-and-role attributes the time-window example below relies on — and watch which Policy Checks flip the decision from allow to deny.

struct ProtectedResource {
    const char* resourceId;
    const char* resourceName;
    uint16_t requiredCapabilities;
    bool requiresAudit;
    bool timeRestricted;
    uint8_t allowedStartHour;  // 0-23
    uint8_t allowedEndHour;    // 0-23
};

bool checkTimeRestriction(ProtectedResource* resource) {
    uint8_t hour = getSimulatedHour();
    return (hour >= resource->allowedStartHour && hour < resource->allowedEndHour);
}

ProtectedResource resources[] = {
    {"RES_SENSOR", "Sensor Data", CAP_READ, false, false, 0, 24},
    {"RES_CONFIG", "Configuration", CAP_WRITE, true, false, 0, 24},
    {"RES_CONTROL", "Device Control", CAP_EXECUTE, true, false, 0, 24},
    {"RES_LOGS", "System Logs", CAP_AUDIT, true, true, 8, 18},        // Business hours only
    {"RES_USERS", "User Management", CAP_ADMIN_WRITE, true, true, 9, 17},
    {"RES_FIRMWARE", "Firmware Update", CAP_ADMIN_WRITE | CAP_EXECUTE, true, true, 2, 6},  // Maintenance window
    {"RES_EMERGENCY", "Emergency Override", CAP_EMERGENCY, true, false, 0, 24},
    {"RES_DEBUG", "Debug Console", CAP_DEBUG, true, true, 9, 17}
};

13.12 Device Attestation

Device attestation is a security mechanism that verifies whether an IoT device is running authentic, unmodified firmware before granting it access to network resources. The process relies on a chain of trust: a secure element on the device holds a private attestation key that signs a hash of the device’s firmware. The server then verifies the signature (confirming the hash came from a genuine device) and compares the firmware hash against a database of known-good firmware versions. If the hash does not match any known-good version, the firmware has been tampered with.

13.13 Mutual TLS Authentication

Ensuring both device and server verify each other:

13.14 Constrained Device Authentication

Constrained-device authentication must preserve proof while respecting memory, airtime, energy, and connectivity limits. Work through the two cases in that order. The first separates a device-held credential from interactive human factors that require frequent synchronisation or confirmation. The second compares authentication-tag and signature overhead against a ten-byte, infrequent radio payload. Neither exercise says one mechanism is universally best; each asks which proof fits the stated trust relationship and resource budget while keeping private or shared keys provisioned and protected appropriately.

13.15 OAuth Device Authorization Grant

For devices without keyboards or displays:

Run it: Before you answer, watch the Device Authorization Grant play out in the animation below. Choose a device such as Smart TV or Factory sensor and step the Valid flow with Next to see the device request a user_code, display it, and poll the token endpoint until the user approves on a second screen. Then run Expired code and Over-polling to see why polling must back off and stop, and Code phishing to see the risk the displayed user_code introduces. Use the Flow, Polling, Risk, and Tokens views to ground your answer to the question below.

13.16 The Accounting Layer

The third “A” in AAA — monitoring and enforcement:

Total certificates: 50,000
Renewal window: 30 days (start 30 days before expiry)
Daily capacity needed: 50,000 / 30 = 1,667 renewals/day
Hourly capacity: 1,667 / 24 = 69.5 renewals/hour

bool renewCertificate(AccessToken* token) {
    // 1. Authenticate with existing certificate
    if (!validateToken(token)) return false;

    // 2. Generate new key pair in secure element
    uint8_t publicKey[64];
    secureElementGenerateKeyPair(publicKey);

    // 3. Create Certificate Signing Request (CSR)
    CSR csr = createCSR(publicKey, token->userId);

    // 4. Submit CSR to EST server (authenticated with old cert)
    Certificate newCert = estSimpleReenroll(csr, token);

    // 5. Validate new certificate
    if (!verifyCertificateChain(newCert)) {
        Serial.println("Certificate validation failed");
        return false;
    }

    // 6. Atomic swap: activate new cert, mark old for deletion
    activateCertificate(newCert);
    scheduleDeletion(token, 7_DAYS);

    return true;
}

Day 1:  1,667 renewed (3.3% complete)
Day 10: 16,670 renewed (33.3% complete)
Day 20: 33,340 renewed (66.7% complete)
Day 30: 50,000 renewed (100% complete)

Success rate: 98.5% (750 failures requiring manual intervention)
Average renewal time: 4.2 seconds per device
Network bandwidth used: 850 KB/renewal x 50,000 = 42.5 GB total

Risk Assessment:
Apply the decision in a deliberate order. First, data: Production metrics, machine status (Medium sensitivity). Next, exposure: Internal network only (Low external threat). Then, regulatory: None specific. Finally, user Impact: Operators interact every 10-30 minutes.

Recommended Settings:
  Idle Timeout: 10 minutes (operators check dashboards every 5-15 min)
  Max Session: 4 hours (typical shift length)
  Token Lifetime: 20 minutes (2x typical interaction interval)
  Refresh Limit: 3 refreshes (allows 80 min total with refreshes)

// BAD IMPLEMENTATION
AccessToken* getValidToken() {
    if (currentToken == NULL || !validateToken(currentToken)) {
        // Token invalid, issue new one
        currentToken = issueToken(session, capabilities);
    }
    return currentToken;
}

// GOOD IMPLEMENTATION
AccessToken* getValidToken() {
    if (currentToken == NULL) {
        // No token at all - create new session
        currentSession = createSession(userId);
        currentToken = issueToken(currentSession, capabilities);
        return currentToken;
    }

    if (validateToken(currentToken)) {
        return currentToken;  // Still valid
    }

    // Token expired - try refresh first
    if (refreshToken(currentToken)) {
        return currentToken;  // Refresh succeeded
    }

    // Refresh failed - revoke old token before issuing new one
    revokeToken(currentToken);
    currentToken = issueToken(currentSession, capabilities);
    return currentToken;
}

13.17 Continue to the Next Part

Carry this evidence into Advanced Access Control: Token Lifecycles and Sessions, which begins with Deep Dive: Token Lifecycle and Stateless Access.