DEV Community

Cover image for IDENTITY PROVIDERS
Ntseze-Nelvis
Ntseze-Nelvis

Posted on

IDENTITY PROVIDERS

AWS IAM IDENTITY PROVIDERS Deep Dive

iamidentityproviders #iamroles #iam #aws

πŸ“Œ This article is part of the AWS IAM Deep Dive series.


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"
        }
      }
    }
  ]
}

Enter fullscreen mode Exit fullscreen mode

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

  1. Go to IAM β†’ Identity Providers
  2. Click "Add Provider"
  3. Choose "OpenID Connect"
  4. Enter:
    • Provider URL: https://token.actions.githubusercontent.com
    • Audience: sts.amazonaws.com

OIDC Setup

  1. 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"
        }
      }
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

trusted policy

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

  1. Attach policy: AmazonS3FullAccess
  2. Click "Next"

AmazonS3FullAccess

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]/
Enter fullscreen mode Exit fullscreen mode

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)