aws-AssumeRoleWithWebIdentity-claim-problem.md

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?

Did you have any luck? Same issue

Thank you for getting back to me with the updates about your research.

I have actually taken some time to work on this with another Senior Engineer from my team, and we have tried several combinations of conditions in the trust policy for an OIDC mapped role I created in my test environment, but unfortunately we could not get this to work as expected, despite several attempts.

I also stumbled upon the forum link you sent while I was researching the issue like you did.

I did however find information within our internal forums that indicate that custom claims are not supported for OIDC providers in AWS at this time, although our public documents sort of gives the impression that they are.

I had this suspicion when I first pulled one of the CloudTrail events of a failed "AssumeRoleWithWebIdentity" action from your account and found that the error message displayed as "An unknown error occurred":

},
    "eventTime": "2019-07-18T05:44:42Z",
    "eventSource": "sts.amazonaws.com",
    "eventName": "AssumeRoleWithWebIdentity",
    "awsRegion": "FILLER",
    "sourceIPAddress": "FILLER",
    "userAgent": "aws-sdk-go/1.20.21 (go1.12.7; darwin; amd64)",
    "errorCode": "AccessDeniedException",
    "errorMessage": "An unknown error occurred",
    "requestParameters": {
        "roleArn": "FILLER",
        "roleSessionName": "FILLER"
    },

Digging deeper into our internal forums, I found that our service team has been notified already and they are aware about this limitation. As a matter of fact, AWS support has logged a new feature request ticket with our service team on behalf of customers who also met a stumbling block when they were trying to implement a similar use case like you. Currently, our service team hasn't updated the internal ticket with an ETA of when to expect the addition of this feature, hence I am unable to also provide that information to you at this time.

I have added your case to this internal feature request ticket as well for tracking purposes, which also increases the chances that you will be contacted via this case directly when the support for custom claims for OIDC providers has been implemented in AWS.

In the meantime please feel free to keep an eye on the following 2 links in the references section where our service teams usually publishes information about new features or updates to existing feature that they release. I sincerely apologize for the inconvenience caused to you due to this.

@thebenwaters we've begun using the amr claim to pass group data. However since the id_token has a max size, I'm building a system to find the intersection between a given user's groups that they're a member of and the union of all groups used in all policy conditions in all roles in all AWS accounts. It's an ugly hack but I suspect it will work, allowing us to use amr and to not exceed the max claim size.

Here's more information if you want to follow along on that effort : mozilla-iam/mozilla-aws-cli#26

I never got a good response though about the oaud claim sadly.

Ah @gene1wood1 that's an amazing find, but unfortunately our idp doesn't give us access to override the amr value

I had the same issue and solved by using the azp claim (I had to read throughly https://docs.aws.amazon.com/en_en/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#ck_aud). So in your example it would be WebIdentityToken:

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

Then, in the 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": "some-unique-identifier",
          "auth-dev.mozilla.auth0.com/:oaud": "xRFzU2bj7Lrbo3875aXwyxIArdkq1AOT"
        },,
        "Null": {
          "auth-dev.mozilla.auth0.com/:aud": "false",
          "auth-dev.mozilla.auth0.com/:oaud": "false"
        }
      }
    }
  ]
}

It will also required to add the some-unique-identifier to Audience list in the OIDC provider configuration in IAM

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.

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/

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