AWS Access Portal or IAM Identity Centre (AWS Single Sign-On or SSO) vs IAM - Claude

AWS IAM Identity Center (formerly AWS Single Sign-On or AWS SSO) represents a more modern and centralized approach to AWS authentication that sits alongside—but is architecturally distinct from—the traditional IAM user login flow.

How This Fits into AWS’s Security Framework

Two Parallel Authentication Paths

AWS now offers two primary ways to authenticate humans:

1. Traditional IAM Users (the “old” way):

• Direct login at https://[account-id].signin.aws.amazon.com/console
• Requires: Account ID/alias + IAM username + password + (optional) MFA
• Each AWS account manages its own IAM users independently
• Credentials are scoped to a single AWS account

2. IAM Identity Center (what you’re seeing):

• Centralized login portal at https://[your-org].awsapps.com/start or through the access portal
• Single set of credentials provides access to multiple AWS accounts
• Organization-wide identity management
• This is AWS’s recommended approach for human users in 2025

What You’re Looking At (Example)

This access portal could show:

Three AWS Accounts:

• organisation-project-dev (571337803998)
• organisation-project-prod (81829631544)
• organisation-project-sandbox (882996234115)

Permission Sets/Roles:

• “ProjectEngineer” - appears across all accounts
• “Administrator” - appears in the sandbox account

This is a single authentication giving you access to multiple accounts with different permission levels—something traditional IAM users cannot do without switching credentials.

The Authentication Flow

With IAM Identity Center (this portal):

1. You authenticate once to the Identity Center using:

   • Your Identity Center username/email
   • Password (stored in Identity Center’s directory OR federated from external IdP)
   • MFA (if configured at the Identity Center level)

2. You select an account + role from the portal

3. Behind the scenes, Identity Center:

   • Uses AWS STS (Security Token Service) to assume the selected role
   • Provides you temporary credentials (valid 1-12 hours)
   • These credentials grant the permissions of that role in that account

4. You’re redirected to the AWS Console or given CLI credentials for that account/role combination

Key Differences from Traditional IAM Login:

Aspect	Traditional IAM Users	IAM Identity Center (This Portal)
Credentials	Per-account IAM username/password	Single identity across all accounts
Access Keys	Long-lived access keys per account	Temporary credentials only
Multi-Account	Must switch accounts/roles manually	Select from unified portal
MFA	Configured per IAM user	Configured once at Identity Center level
Identity Source	AWS IAM only	Can federate (Azure AD, Okta, Google Workspace)
Best Practice	Being phased out for human users	Recommended for all human access

Is This “Just Another Way of Presenting” the Same Credentials?

No—it’s fundamentally different architecture:

Traditional IAM Users:

You → [Account ID + IAM Username + Password] → IAM User in Account A
You → [Account ID + IAM Username + Password] → IAM User in Account B

Each account has separate credentials. No shared identity.

IAM Identity Center:

You → [Single Identity Center Login] → Identity Center Directory
                                          ↓
                    [Select Account + Role from Portal]
                                          ↓
                    AWS STS AssumeRole with SAML assertion
                                          ↓
                    Temporary credentials for that account/role

The “Access keys” Links

Those “Access keys” links you see don’t generate traditional long-lived IAM user access keys. Instead, they provide:

1. Temporary AWS credentials (Access Key ID, Secret Access Key, Session Token)
2. Valid for hours, not years (unlike IAM user access keys)
3. Automatically rotated when you re-authenticate through the portal
4. Properly scoped to the role you selected

You’d use these for CLI/SDK access:

# Instead of 'aws configure' with long-lived keys, you'd use:
aws configure sso
 
# Or manually set temporary credentials:
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...  # This is the key difference

The Underlying Technology

This portal is built on SAML 2.0 (Security Assertion Markup Language) federation:

1. IAM Identity Center acts as the Identity Provider (IdP)
2. AWS accounts act as Service Providers (SP)
3. When you select an account/role, Identity Center issues a SAML assertion attesting your identity
4. AWS STS exchanges this assertion for temporary credentials via AssumeRoleWithSAML

This is the same federation mechanism mentioned in the primer’s OIDC section, but using SAML instead of OIDC.

Why AWS Pushes This Approach

From the primer’s security section perspective, IAM Identity Center addresses several IAM user pain points:

1. Credential sprawl: One password instead of N passwords across N accounts
2. Long-lived keys: No more eternal access keys sitting in ~/.aws/credentials
3. Least privilege: Easier to grant time-limited, role-based access
4. Compliance: Centralized audit trail, easier to enforce MFA org-wide
5. Offboarding: Disable one identity instead of hunting down IAM users across accounts

Relationship to Concepts in the Primer

From the IAM Section:

• Roles: “FrontierEngineer” and “Administrator” are IAM roles in each account
• AssumeRole: Identity Center programmatically assumes these roles on your behalf
• STS: Provides the temporary credentials after successful authentication

From the OIDC/Federation Section:

• This is SAML federation (similar concept, different protocol)
• Identity Center is the trusted identity provider
• You’re not creating IAM users—you’re federating

From Best Practices:

• This fulfills “Never use root account credentials”
• Implements “Use roles for EC2/Lambda” extended to human users
• Enables “Rotate credentials regularly” automatically via temporary credentials

Practical Implication

If you’re joining an organization using IAM Identity Center, you’ll:

1. Never see the traditional https://[account-id].signin.aws.amazon.com/console login
2. Never have an IAM user created for you in any account
3. Bookmark the access portal URL
4. Configure CLI/SDK tools differently (using aws configure sso instead of aws configure)

This is the modern AWS authentication pattern, and understanding it is crucial for communicating with infrastructure teams about access provisioning, troubleshooting authentication issues, and properly configuring your local development environment.