Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save gene1wood/54611c45a3298504f8e33d95e317ae5c to your computer and use it in GitHub Desktop.
Save gene1wood/54611c45a3298504f8e33d95e317ae5c to your computer and use it in GitHub Desktop.

We (Mozilla Enterprise Information Security team) are encountering a challenge with trying to connect AWS with our identity provider (Auth0) when calling iam:AssumeRoleWithWebIdentity

We've setup an AWS IAM Identity Provider

  • ARN arn:aws:iam::656532927350:oidc-provider/auth-dev.mozilla.auth0.com/
  • Provider type : OIDC
  • Provider URL : auth-dev.mozilla.auth0.com/
  • Audience : xRFzU2bj7Lrbo3875aXwyxIArdkq1AOT

And created an IAM Role with a Trust Relationship policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::656532927350:oidc-provider/auth-dev.mozilla.auth0.com/"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "auth-dev.mozilla.auth0.com/:aud": "xRFzU2bj7Lrbo3875aXwyxIArdkq1AOT"
        }
      }
    }
  ]
}

When we call the sts.amazonaws.com endpoint with these parameters

'Action': 'AssumeRoleWithWebIdentity',
'RoleArn': 'arn:aws:iam::656532927350:role/gene-test-federated-role-mozlando',
'RoleSessionName': 'federated-boto-gene',
'WebIdentityToken': 'id token goes here',
'Version': '2011-06-15'

and pass an OIDC ID Token containing these values in the WebIdentityToken parameter

{
  "https://sso.mozilla.com/claim/AAL": "MEDIUM",
  "iss": "https://auth-dev.mozilla.auth0.com/",
  "sub": "ad|Mozilla-LDAP-Dev|gene",
  "aud": "xRFzU2bj7Lrbo3875aXwyxIArdkq1AOT",
  "iat": 1544218355,
  "exp": 1544254355
}

We get success and are issued AWS STS API Keys.

If however, following this aws doc we pass an oaud claim (as oaud is one of the 3 allowed claims to pass) things don't work.

If we instead set our IAM Trust Relationship Policy to

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::656532927350:oidc-provider/auth-dev.mozilla.auth0.com/"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "auth-dev.mozilla.auth0.com/:aud": "xRFzU2bj7Lrbo3875aXwyxIArdkq1AOT",
          "auth-dev.mozilla.auth0.com/:oaud": "authenticated"
        }
      }
    }
  ]
}

and pass a WebIdentityToken with these values

{
  "https://sso.mozilla.com/claim/AAL": "MEDIUM",
  "oaud": "authenticated",
  "iss": "https://auth-dev.mozilla.auth0.com/",
  "sub": "ad|Mozilla-LDAP-Dev|gene",
  "aud": "xRFzU2bj7Lrbo3875aXwyxIArdkq1AOT",
  "iat": 1544218355,
  "exp": 1544254355
}

calling AssumeRoleWithWebIdentity results in Access Denied

We've tried this with other claims beyond oaud as well with no luck. We've confirmed that sub is passed through and we can compare against it.

Why does oaud not work? How can we pass a claim through that we can use in our policy condition without overloading/replacing aud or sub, the two claims we've found we can use in our policy conditions?

@mungojam
Copy link

This appears to still be the case in 2022. I found similar with SourceIdentity not getting through when using WebIdentity even though it is a documented AWS feature, or at least gives that impression.

@Cyberax
Copy link

Cyberax commented Jul 16, 2022

I found the solution. Turns out that you can pass SourceIdentity through WebIdentity if you set this claim on the ID token.
"https://aws.amazon.com/source_identity": "{UserNameDetail}".

Yes, you read it right. The claim NAME is a URL: https://aws.amazon.com/ru/blogs/security/how-to-relate-iam-role-activity-to-corporate-identity/

@mungojam
Copy link

I found the solution. Turns out that you can pass SourceIdentity through WebIdentity if you set this claim on the ID token. "https://aws.amazon.com/source_identity": "{UserNameDetail}".

Yes, you read it right. The claim NAME is a URL: https://aws.amazon.com/ru/blogs/security/how-to-relate-iam-role-activity-to-corporate-identity/

@Cyberax did you find that it flowed all the way through to access logs? In our case it got dropped somewhere and so wasn't any use for auditing. That was about a year ago though

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment