AWS IAM: From Principal to Decision

Your deployment calls s3:PutObject, but S3 returns AccessDenied. The useful starting point is the request itself: which principal signed it, which action did it ask for, which resource did it name, and which context values travelled with it?

This page keeps one request in view as it moves through IAM:

arn:aws:sts::111122223333:assumed-role/AppDeployer/darshan → s3:PutObject → arn:aws:s3:::prod-artifacts/releases/app.zip

AWS builds request context, finds every policy that applies, looks for a sufficient grant, applies the relevant limits, and lets any applicable explicit deny win. The diagrams organize documented policy relationships so you can reason about them; they do not represent AWS’s internal implementation order.

Principal: who signed the request?

A principal is the entity AWS authorizes for this request. A person or workload may begin the journey, but temporary credentials often mean that an assumed-role session becomes the runtime principal that calls S3. That distinction affects which policies and condition keys match. Principal forms ↗

The person or workload that starts an action may first become a role session. Authorization follows the runtime principal and its request context. An IAM group organizes user permissions; it cannot authenticate or appear in a policy’s Principal element.

Policies: where can permission come from?

Authentication establishes who is calling. Authorization comes from policy statements that match the action, resource, principal where required, and condition context. Identity and resource policies can supply permissions; other policy types cap those permissions or govern a specific access path. IAM policy types ↗

In the same account, either side can often supply a sufficient allow. Across accounts, the caller’s account and the resource-owning account normally must both authorize access.

Identity and resource policies are the ordinary grant sources. Boundaries, session policies, SCPs and RCPs reduce the available permissions. Endpoint policies, ACLs and RAM participate only for their supported path or resource model.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "PublishRelease",
    "Effect": "Allow",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::prod-artifacts/releases/*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalTag/Environment": "prod"
      }
    }
  }
}

An identity policy cannot contain Principal; the user, group or role it is attached to supplies that identity. A resource policy must name the principal receiving the permission.

AWS services differ in which resources and policy elements they support. A pattern that works for an S3 bucket policy may not transfer unchanged to a KMS key policy or another service.

Evaluation: why was it allowed or denied?

The durable rules are straightforward: a request begins implicitly denied, it needs a relevant allow, limiting policies must permit the request when they apply, and an explicit deny overrides an allow. The details depend on the principal, accounts, resource-policy support, and the exact kind of principal named by a resource policy. Evaluation logic ↗

A request begins denied. A relevant grant must survive every limiter that applies to this path. Any applicable explicit deny wins, even when all other controls allow the request.

Role and session principals are different

When a same-account resource policy grants directly to an assumed-role session ARN, permissions-boundary and session-policy implicit denies do not limit that direct grant. An applicable explicit deny still wins. A grant to the IAM role ARN remains limited by the role’s boundary and session policy. AWS recommends using role principals where possible. Detailed allow and deny evaluation ↗

Guardrails: how is power capped?

Permissions boundaries help a platform team delegate role creation without allowing each new role to exceed an approved maximum. SCPs define a maximum for principals in member accounts as policy inheritance moves from the organization root through OUs to an account. RCPs provide the resource-side Organizations control for supported services.

A permissions boundary follows one IAM user or role. An SCP follows the organization path to a member account. Both constrain existing grants; neither creates one.

Region guardrails need care because some AWS services use global endpoints or do not operate in an ordinary regional request path. A production policy should include the appropriate global-service exceptions rather than treating the diagram’s “approved Regions” label as a complete SCP.

Sessions: what happens when a role is assumed?

An IAM role stores trust and permissions configuration. When an authorized caller invokes AssumeRole, AWS STS creates a named role session and returns an access key ID, secret access key, session token, and expiration. Those credentials represent the session until they expire. Temporary credentials ↗

A trust policy authorizes an STS operation such as AssumeRole; it does not grant S3 or KMS access. The resulting role session uses temporary credentials to sign later service requests, which receive their own authorization decisions.

AssumeRoleWithSAML and AssumeRoleWithWebIdentity change how the caller proves its identity to STS. GetFederationToken creates a federated-user session for older custom-broker patterns. The separate Identity and Credential Flows page follows those credential artifacts in more depth.

Cross-account: which two sides must agree?

Cross-account access is not synonymous with assuming a role. A caller can assume a role in the target account, or supported resources can grant the original external principal direct access. Both patterns require the appropriate caller-side and target-side authorization, but they produce different runtime principals. Cross-account evaluation ↗

A role trust policy permits assumption; the role’s permissions govern the later service request. Direct resource access keeps the Account A identity as the caller and normally requires permission from both account sides.

Least privilege: how do you refine access?

Least privilege is easier to maintain when you treat a policy as an evidence-backed draft. Start with the task, validate the syntax and service support, test the actual request, observe use, and remove permissions that the principal does not need.

"Action": "s3:*",
"Resource": "*"

"Action": "s3:PutObject",
"Resource":
  "arn:aws:s3:::prod-artifacts/releases/*"

Begin with the task, verify the policy, observe what the principal actually uses, and remove unused access. Protect policy-management and iam:PassRole paths because they can expand what another principal can do.

Prefer federation and temporary role credentials for people and workloads. Use strong identity-provider controls for privileged humans, separate everyday and elevated roles, govern tags before relying on ABAC, review external trust, and log sensitive policy changes and unusual role assumptions.

Diagnose an AccessDenied

Start with the failed request rather than reading every policy in the account. An AWS error can identify one reason for denial without listing every reason, so work outward from evidence.

Policy Simulator and IAM Access Analyzer can narrow the investigation, but confirm their findings against the service’s authorization model and the actual request context. Broader administrator access cannot overcome an explicit deny.