Ntseze-Nelvis

Posted on Oct 3

IDENTITY PROVIDERS

#security #devops #architecture #aws

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

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!

DEV Community