Mastering AWS Identity Services: IAM Identity Center & Directory Service

This study guide covers the architectural strategies for managing user identities and access across multi-account AWS environments and hybrid infrastructures, focusing on AWS IAM Identity Center and AWS Directory Service.

Learning Objectives

After studying this guide, you should be able to:

• Differentiate between IAM Identity Center and standard IAM federation.
• Select the appropriate AWS Directory Service type (Simple AD, AD Connector, or Managed Microsoft AD) based on technical requirements.
• Explain the role of SAML 2.0 and SCIM in identity synchronization.
• Implement Attribute-Based Access Control (ABAC) using session tags.

Key Terms & Glossary

• Identity Provider (IdP): A trusted system that manages identity information and provides authentication services (e.g., Okta, Azure AD, Google).
• Federation: A mechanism that allows users to access AWS resources using their existing corporate or social credentials without creating local IAM users.
• SAML 2.0 (Security Assertion Markup Language): An open standard for exchanging authentication and authorization data between an IdP and a service provider (AWS).
• SCIM (System for Cross-domain Identity Management): An HTTP-based protocol used to automate the exchange of user identity information between identity domains.
• Service-Linked Role: A predefined IAM role that allows an AWS service to perform actions on your behalf, managed and updated by AWS.

The "Big Idea"

In a modern enterprise, security is no longer about perimeter defense but identity management. Instead of managing long-lived credentials (Access Keys/Secret Keys) for every user in every account, AWS identity services allow you to centralize management. By leveraging Identity Federation, you reduce the "blast radius" of credential leaks and ensure that when a user leaves the company, their access is revoked globally in one place: the corporate Identity Provider.

Formula / Concept Box

Hierarchical Outline

• Identity Federation
  • Public-facing: Social IdPs (Apple, Google, Facebook) via Amazon Cognito or OIDC.
  • Workforce: Corporate IdPs (Microsoft AD, Okta) via SAML 2.0.
• AWS IAM Identity Center (formerly AWS SSO)
  • Centralized access: Manage access to multiple AWS accounts and SaaS apps.
  • Attribute-Based Access Control (ABAC): Using session tags passed from IdP to filter resource access.
• AWS Directory Service
  • Simple AD: Low-scale, standalone, Microsoft AD-compatible (Samba 4).
  • AD Connector: Proxy service; does not store data; forwards requests to on-prem AD.
  • Managed Microsoft AD: Real Microsoft AD running on AWS; supports trusts and replication.
• Service Roles
  • Service-linked roles: Automatic setup with specific permissions.
  • Custom Service roles: Manual setup when the service doesn't provide a linked role.

Visual Anchors

Choosing the Right Identity Service

Directory Service Architecture Comparison

\begin{tikzpicture}[node distance=2cm, every node/.style={rectangle, draw, rounded corners, minimum width=3cm, minimum height=1cm, align=center}] \node (client) {Application/EC2}; \node (proxy) [below left of=client, xshift=-1cm] {AD Connector$Proxy Mode)}; \node (managed) [below right of=client, xshift=1cm] {Managed MS AD$Hosted Mode)}; \node (onprem) [below of=proxy, yshift=-1cm] {On-Premises AD};

\draw[->, thick] (client) -- (proxy); \draw[->, thick] (proxy) -- node[left, draw=none] {Redirects} (onprem); \draw[->, thick] (client) -- (managed); \draw[<->, dashed] (managed) -- node[above, draw=none, sloped] {Trust Relationship} (onprem); \end{tikzpicture}

Definition-Example Pairs

• ABAC (Attribute-Based Access Control):
  • Definition: A logic that grants access based on attributes (tags) of the user and the resource.
  • Example: A user with the tag Project: Apollo can only start EC2 instances that also have the tag Project: Apollo.
• AD Connector:
  • Definition: A gateway that forwards directory requests to your existing on-premises Microsoft AD without caching or synchronizing data.
  • Example: Connecting an existing corporate AD to Amazon WorkSpaces so employees can use their Windows passwords to log in to their cloud desktops.

Worked Examples

Example 1: Creating a Service-Linked Role via CLI

When a service (like Auto Scaling) needs to interact with other resources (like EC2) on your behalf, you might need to create a role manually if it's not done automatically.

Command:

Example 2: Selecting a Directory for RDS SQL Server

Scenario: A company is migrating a legacy .NET application and its SQL Server database to AWS. They require full Microsoft AD features and Windows Authentication for RDS. Solution: Use AWS Managed Microsoft AD. Why? Simple AD does not support RDS for SQL Server, and AD Connector is merely a proxy. Managed MS AD provides the native features required for RDS domain joining.

Checkpoint Questions

1. Which service is best for centralized access management across 100+ AWS accounts? (Answer: IAM Identity Center)
2. True or False: Simple AD supports trust relationships with on-premises domains. (Answer: False)
3. What protocol is used to automatically sync user accounts from an external IdP to AWS IAM Identity Center? (Answer: SCIM)
4. If you need to use your existing on-premises MFA for AWS Management Console access, which Directory Service option is most suitable? (Answer: AD Connector or Managed MS AD with AD Trust)

Muddy Points & Cross-Refs

[!NOTE] Simple AD vs. AD Connector: This is a common point of confusion. Remember: Simple AD is a standalone directory (a new source of truth), while AD Connector is a pass-through (it doesn't store users; it just points to your on-premise AD).

[!WARNING] RDS Compatibility: Simple AD is not compatible with RDS SQL Server. If your architecture involves managed SQL Server, you must use Managed Microsoft AD.

Comparison Tables

AWS Directory Service Options