AWS IAM IDENTITY PROVIDERS Deep Dive
iamidentityproviders #iamroles #iam #aws
π This article is part of the AWS IAM Deep Dive series.
- Part 1: IAM Users Deep Dive
- Part 2: IAM Groups Deep Dive
- Part 3: IAM Roles Deep Dive
- Part 4: IAM Policies Deep Dive
- [Part 5: IAM Identity Providers Deep Dive(https://dev.to/ntsezenelvis/identity-providers-18ka)
PART 5: IAM IDENTITY PROVIDERS
aws #iam #security #devops
1. What is an IAM Identity Provider?
An IAM Identity Provider (IdP) is a trusted external system (e.g., Okta, Azure AD, Google, GitHub, Auth0) that enables federated authentication into AWS without the need for creating long-lived IAM users.
Instead of storing AWS credentials locally, users authenticate with the IdP and assume roles in AWS through STS (Security Token Service).
2. Types of IAM Identity Providers
- SAML 2.0 β Enterprise IdPs like Okta, Azure AD, ADFS.
- OIDC (OpenID Connect) β Modern apps (Google, GitHub, Auth0).
- Cognito β AWS-managed identity provider with social login support.
- Web Identity Federation β Direct federation with STS AssumeRoleWithWebIdentity.
3. Trust Policy vs Permission Policy
π IAM roles with IdPs use two types of policies:
- Trust Policy β Defines who can assume the role (the external IdP).
- Permission Policy β Defines what actions the role can perform in AWS.
Example: Trust Policy (SAML Federation with Okta)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:saml-provider/MyOktaIdP"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}
4. Common Problems with Identity Providers
π΄ Misconfigured SAML metadata (expired certificate or mismatch)
π΄ Overly broad trust policies (Principal: *
)
π΄ Missing MFA enforcement in federation
π΄ Roles granting excessive session durations (12h+)
5. Best Practices
β
Always use short-lived credentials (1β12 hours max)
β
Enforce MFA via IdP + AWS conditions (aws:MultiFactorAuthPresent
)
β
Map IdP groups to roles in AWS (least privilege principle)
β
Rotate SAML/OIDC metadata & thumbprints regularly
β
Monitor STS AssumeRole events in CloudTrail
6. Hands-On Guide
Simple Example: GitHub Actions β AWS
What we're building:
- Allow GitHub Actions to upload files to an S3 bucket
- No complex SAML setup - using OIDC (modern, simpler approach)
Step-by-Step in 4 Simple Steps
Step 1: Create OIDC Identity Provider in AWS
- Go to IAM β Identity Providers
- Click "Add Provider"
- Choose "OpenID Connect"
-
Enter:
-
Provider URL:
https://token.actions.githubusercontent.com
-
Audience:
sts.amazonaws.com
-
Provider URL:
- Click "Add provider"
β Done! AWS now trusts GitHub.
Step 2: Create IAM Role - Trust Policy
CHANGE THIS PART:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::[YOUR-AWS-ACCOUNT-ID]:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:[YOUR-GITHUB-USERNAME]/[YOUR-REPO-NAME]:ref:refs/heads/main"
}
}
}
]
}
Change these 3 things:
-
[YOUR-AWS-ACCOUNT-ID]
β Your 12-digit AWS account number -
[YOUR-GITHUB-USERNAME]
β Your GitHub username or organization name -
[YOUR-REPO-NAME]
β Your repository name
Step 3: Add Permissions
-
Attach policy:
AmazonS3FullAccess
- Click "Next"
Step 4: Create Workflow File
Create: .github/workflows/deploy.yml
CHANGE THIS PART:
name: Deploy to S3
on:
push:
branches: [ main ]
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
id-token: write # β KEEP THIS LINE
contents: read
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v2
with:
role-to-assume: arn:aws:iam::[YOUR-AWS-ACCOUNT-ID]:role/github-actions-s3-deploy
aws-region: us-east-1 # β Change region if needed
- name: Upload to S3
run: |
aws s3 sync ./ s3://[YOUR-BUCKET-NAME]/
Change these 3 things:
[YOUR-AWS-ACCOUNT-ID] β Same 12-digit AWS account number
us-east-1 β Your AWS region if different
7. Industry Examples
Startup: Developers use Google OIDC federation for AWS CLI access.
Enterprise: Okta SAML federation with AWS Organizations β mapped roles per business unit.
Finance: MFA enforced on SAML federation roles for compliance (PCI, SOX).
DevOps: GitHub Actions OIDC β AssumeRole directly in AWS without storing long-lived secrets.
8. Interview Questions
Basic:
- What is an IAM Identity Provider?
- Difference between SAML 2.0 and OIDC?
Intermediate:
- How does
sts:AssumeRoleWithSAML
work? - Explain the difference between Trust Policy and Permission Policy.
Advanced:
- How do you scale identity federation across multiple AWS accounts?
- How do you securely rotate OIDC thumbprints?
- How do IAM IdPs integrate with AWS Organizations SCPs?
π Wrapping Up
IAM Identity Providers act as the bridge between external authentication systems and AWS IAM. They remove the need for long-lived IAM credentials and enable federated, secure, and scalable authentication.
π Key takeaways:
- Use trust + permission policies correctly
- Enforce short-lived sessions & MFA
- Monitor & audit federation events
β Thanks for reading! If this helped:
- Leave a β€οΈ reaction and follow for more AWS/DevOps deep dives
- Drop your federation experiences/questions in the comments π¬
- Share with your team to promote SSO best practices
π Stay tuned for the next deep dive in this IAM series!
Top comments (0)