AWS Identity and Access Management (IAM) & Identity Center

Learning Objectives

After studying this guide, you should be able to:

• Differentiate between IAM Users and IAM Roles and identify when each is appropriate.
• Explain the benefits of User Federation and how to leverage existing Identity Providers (IdPs).
• Compare AWS IAM Identity Center (formerly AWS SSO) with traditional IAM federation for multi-account environments.
• Understand the role of Attribute-Based Access Control (ABAC) and Session Tags in scaling permissions.
• Identify the use cases for Service-Linked Roles and cross-account access delegation.

Key Terms & Glossary

• Identity Provider (IdP): An external service (e.g., Okta, Active Directory) that manages user identities and authenticates them for use with AWS.
• SAML 2.0 (Security Assertion Markup Language): An open standard for exchanging authentication and authorization data between an IdP and a service provider (AWS).
• OIDC (OpenID Connect): An identity layer on top of the OAuth 2.0 protocol, used for federating users from web/mobile providers (Google, Amazon).
• SCIM (System for Cross-domain Identity Management): A protocol used to automate the exchange of user identity information between identity domains.
• Trust Policy: A JSON policy document associated with an IAM Role that defines who (which principal) is allowed to assume the role.

The "Big Idea"

The core philosophy of modern AWS security is the move away from long-lived credentials (IAM Users) toward short-lived, temporary credentials (IAM Roles). In complex, multi-account organizations, the goal is to centralize identity management using AWS IAM Identity Center, allowing users to log in once to their corporate directory and gain scoped access across the entire AWS Organization without needing local IAM credentials in every account.

Formula / Concept Box

Hierarchical Outline

• 1. Identity Entities
  • IAM Users: Best for specific legacy cases (e.g., Amazon SES SMTP credentials).
  • IAM Roles: Standard for service-to-service communication and federated users.
  • User Groups: Collections of IAM users used to manage permissions at scale.
• 2. Federation Mechanisms
  • IAM Identity Center (AWS SSO): Centralized management for AWS Organizations; supports SCIM for directory sync.
  • Direct IAM Federation: Used for individual account OIDC/SAML integration.
• 3. Policy Types
  • Identity-based Policies: Attached to users/roles.
  • Resource-based Policies: Attached to resources (e.g., S3 Buckets, KMS Keys).
  • Service-Linked Roles: Predefined roles used by AWS services to act on your behalf.

Visual Anchors

Federation Flow (SAML 2.0)

Service-Linked Role Concept

\begin{tikzpicture} [node distance=2.5cm, box/.style={rectangle, draw, minimum width=3cm, minimum height=1cm, align=center}] \node[box] (service) {AWS Service$e.g., Auto Scaling)}; \node[box, right of=service, xshift=2cm] (role) {Service-Linked Role$Managed by AWS)}; \node[box, below of=role] (resource) {Target Resource$e.g., EC2 Instance)};

\end{tikzpicture}

Definition-Example Pairs

• ABAC (Attribute-Based Access Control): A strategy that defines permissions based on attributes (tags).
  • Example: A developer with the tag Project: Apollo can only start EC2 instances that also have the tag Project: Apollo.
• Session Tags: Temporary tags passed during a federated session to identify the user's attributes.
  • Example: When a user logs in via Okta, their CostCenter is passed as a session tag to AWS, which is then used to audit S3 bucket access in CloudTrail.
• Service-Linked Role: A unique type of IAM role that is linked directly to an AWS service.
  • Example: The AWSServiceRoleForAutoScaling allows the Auto Scaling service to delete EC2 instances when a scale-in event occurs.

Worked Examples

Scenario: Multi-Account Access for a Global Team

Problem: A company has 50 AWS accounts. They want their 200 developers to access these accounts using their existing Active Directory credentials without creating 10,000 IAM users.

Step-by-Step Solution:

1. Enable AWS Organizations: Ensure all 50 accounts are part of one Organization.
2. Setup IAM Identity Center: Link it to the corporate Active Directory (via AD Connector or SAML).
3. Create Permission Sets: Define a "Developer" permission set (e.g., PowerUserAccess).
4. Assign Access: Map AD groups (e.g., "Dev-Group-A") to specific AWS accounts using the "Developer" permission set.
5. Result: Developers log into the AWS Access Portal once and see a list of accounts they are authorized to enter.

Checkpoint Questions

1. What is the primary advantage of using IAM Roles over IAM Users for applications running on EC2?
2. Which protocol is used to automatically synchronize user identities from an external IdP to AWS IAM Identity Center?
3. True or False: IAM Identity Center is the preferred solution for managing federation across multiple AWS accounts.
4. When would you still be required to use an IAM User with long-lived credentials?

[!TIP] Answer Key:

1. Roles provide temporary credentials, eliminating the need to manage and rotate secrets manually.
2. SCIM (System for Cross-domain Identity Management).
3. True.
4. For specific services like Amazon SES SMTP credentials or applications that do not support AWS SDKs/Roles.

Muddy Points & Cross-Refs

• IAM vs. Identity Center: It is often confusing when to use which. Remember: IAM is "Local" (best for single account/legacy); Identity Center is "Global" (best for the modern multi-account enterprise).
• Resource-Based Policies vs. Roles: A resource-based policy stays on the resource (like a "Keep Out" sign on a door), while a role is something a principal "puts on" (like a security guard uniform).
• Deeper Study: Review the AWS STS documentation for API calls like AssumeRole, AssumeRoleWithWebIdentity, and GetSessionToken.

Comparison Tables

IAM Users vs. IAM Roles

IAM Identity Center vs. IAM Federation