Authorization determines which actions a person, machine, or service may perform on a resource. Authentication establishes identity; authorization uses that identity to decide whether a particular request is permitted. A digital twin needs both for dashboard reads, model changes, service calls, and commands that can affect physical equipment. section 10.2.3 section 1.6.5 section 10.2.2
Start with least privilege. A GraphQL API that only reads sensor data should not receive permission to modify the table or control equipment. Cloud identity and access management assigns the API a role whose policy permits only DynamoDB Query on the sensor-data table. section 10.2.3
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "dynamodb:Query",
"Resource": "arn:aws:dynamodb:REGION:ACCOUNT_ID:table/sensor-data"
}]
}
The IAM policy names one allowed action and one table resource; REGION and ACCOUNT_ID are placeholders in the resource identifier. section 10.2.3
Cloud permissions are only one layer. Application-specific actions also need authorization. Role-based access control (RBAC) is a foundation; attribute-based access control (ABAC) can additionally consider the time, location, or age of data involved in a request. Across network segments and organizational boundaries, zero trust means verifying each request rather than treating network location as permission. section 4.5.3 section 10.2.3
Authorize a state update
A Cedar policy permits a named maintenance agent to perform update_state on one named HVAC twin. An application submits that principal, action, resource, and an empty context to the policy engine, then reads the returned decision. Keeping the rule separate from business logic lets it be managed, versioned, and deployed as configuration. section 10.2.3
Listing 10.1 Cedar authorization policy evaluation
import requests
AGENT = "http://localhost:8180/v1"
post = lambda path, payload: requests.post(f"{AGENT}/{path}",
json=payload).json()
post("policies", { #1
"id": "twin-policy-01",
"content": """
permit(
principal == User::"maintenance_agent",
action == Action::"update_state",
resource == Twin::"hvac_unit_1"
);
"""
})
decision = post("is_authorized", { #2
"principal": 'User::"maintenance_agent"',
"action": 'Action::"update_state"',
"resource": 'Twin::"hvac_unit_1"',
"context": {}
}).get("decision")
print(f"Digital Twin Access Decision: {decision}")
The Python listing registers the Cedar policy and posts a matching authorization request to Cedar-agent’s HTTP API. section 10.2.3
In production, give devices, services, and automated agents distinct identities and permissions. For example, a maintenance agent can receive a time-limited token scoped to invoke inference, while a dashboard uses a separate read-only identity. Log attributable requests, and define who may view a twin, modify its models, or trigger physical actions. Command-capable twins expand the attack surface, so these boundaries belong in the initial design. section 10.2.2 section 1.6.5
