Identity and Access Management

Decision frame

Identity questions become manageable when authentication and authorization are separated. Authentication establishes or verifies an identity and creates a session. Authorization determines whether that session can perform a specific action on a specific resource in context. Trust answers who may assume or invoke; permissions answer what the resulting principal may do. Secure designs must solve all of them.

For every request, identify the principal, session issuer, action, resource, account boundary, applicable policies, context keys, and explicit denies. Never infer effective access from one policy document.

Objective map

Authentication architecture

Prefer temporary credentials. AWS IAM Identity Center can provide workforce access across accounts and applications. External identity providers can federate with SAML or OIDC. IAM roles provide workload and cross-account sessions through AWS STS. IAM Roles Anywhere can issue temporary AWS credentials to approved workloads outside AWS using a certificate-based trust model. Amazon Cognito addresses customer identity use cases. Long-term IAM user access keys should be exceptional, governed, rotated, monitored, and removed when a role or federation path is available.

Design the complete session, not only sign-in. Consider identity proofing, authentication factors, federation trust, token audience and issuer, role trust conditions, session duration, source identity, session tags, role chaining, credential delivery, revocation behavior, and monitoring. MFA strengthens a supported authentication path but does not correct an overprivileged role. A short session reduces exposure but does not replace least privilege.

Cross-account access requires two sides: the target role or resource must trust the external principal, and the external principal must be permitted to request the action. Use specific principals and conditions such as organization, account, source identity, external ID, source ARN, source account, tags, network context, or MFA only when they match the threat model. Avoid wildcard principals with weak conditions. For third-party role access, an external ID helps address the confused deputy problem but is not a secret or a substitute for scoping the principal.

Authorization evaluation

Start with the default implicit deny. An applicable explicit deny overrides an allow. Then determine which policy types can grant and which only limit. Identity policies and many resource policies can grant permissions. Service control policies define the maximum available permissions for principals in member accounts; they do not grant access. Permissions boundaries limit the maximum identity-policy permissions for an IAM user or role; they do not grant access. Session policies limit a role session. Resource control policies can limit resource permissions in an organization where supported. Key policies and grants participate in AWS KMS authorization and must be evaluated with the calling principal's permissions.

The exact evaluation varies with principal type, resource policy, same-account or cross-account request, service behavior, and context. Avoid memorizing a single universal diagram without its assumptions. Instead, build a request worksheet:

1. Normalize principal, action, resource, and account ownership.
2. List every applicable organization, identity, resource, boundary, session, endpoint, and key control.
3. Find explicit denies first.
4. Identify at least one applicable grant path.
5. Confirm no limiting policy removes that grant.
6. Test the real context keys and service-specific authorization behavior.

Decision patterns

Privilege escalation often appears through control-plane capabilities rather than a direct wildcard allow. Review who can pass a role, update trust, attach policies, create policy versions, modify resource or key policies, invoke functions with privileged roles, change automation, or write to deployment artifacts. Delegated administration requires constraints on both what may be created and what may be attached or passed.

Troubleshooting

For AccessDenied, capture the exact principal ARN, session ARN, action, resource ARN, account, Region, and request context. Confirm whether the denial comes from an SCP or RCP, permissions boundary, session policy, identity policy, resource policy, VPC endpoint policy, KMS policy, or service-specific ownership rule. CloudTrail can show the caller and request, but some authorization details require policy simulation or service documentation. Do not respond by adding Action: * or Resource: *; that erases the evidence needed to locate the missing grant.

For unexpected access, look for alternate paths: a resource policy granting the session directly, a role trust wildcard, a stale group membership, a permission-set update, a policy version, session tags, a service-linked role, a key grant, or a delegated service. Validate with a controlled request and remove the narrow unwanted path.

Scenario drill

A platform team must let application teams deploy Lambda functions without allowing them to create arbitrary administrator roles.

1. Create approved execution-role patterns with least-privilege policies.
2. Constrain delegated role creation with paths or tags and a permissions boundary.
3. Scope iam:PassRole to approved roles and, where useful, the destination service.
4. Prevent boundary removal, unapproved trust changes, policy-version escalation, and attachment of broader policies.
5. Add organization guardrails for prohibited actions and monitor role, policy, and function changes.
6. Test one approved deployment and several escalation attempts.

The answer must control creation, attachment, passing, trust, and later modification—not merely place a boundary on a role.

Common traps

• Saying an SCP, permissions boundary, or session policy grants access.
• Checking only the role's permissions policy and ignoring the trust policy.
• Treating an external ID as a password.
• Using MFA as compensation for broad authorization.
• Allowing iam:PassRole to roles more privileged than the caller's intended scope.
• Adding wildcard permission to fix one unexplained denial.
• Ignoring KMS key policy or VPC endpoint policy in a data-access failure.

Self-check

1. Trace a cross-account AssumeRole from identity provider to target resource.
2. Explain the difference between trust policy, identity policy, resource policy, SCP, and permissions boundary.
3. Name three permissions that can create indirect privilege escalation.
4. Diagnose a request allowed by IAM but denied by AWS KMS.
5. Design a temporary access path for a workload outside AWS without long-term keys.

Primary references

• AWS SCS-C03 exam guide
• AWS policy evaluation logic
• IAM best practices
• AWS IAM Access Analyzer