IAM role conditional access of OpenID provider with roles set claim matching does not work

0

Hello,

I have a JWT issued by an IDP with roles=["role1"], I would like to match an IAM role based on that JWT role, I tried:

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
				"Federated": "arn1"
			},
			"Action": "sts:AssumeRoleWithWebIdentity",
			"Condition": {
				"StringEquals": {
					"idp1/:aud": "aud1"
				},
				"ForAnyValue:StringEquals": {
					"idp1/:roles": [
					    "role1"
					]
				}
			}
		}
	]
}

It seems like the roles claim is not propogated, as it never matches with ForAnyValue and matches everything with ForAllValues. Does anyone have an experience of how to match based on on roles claim? I do not have issue with other string based claims.

Regards, Alon

asked 3 months ago124 views
1 Answer
1

The propagation will not occur since :roles is not included in the list of cross-service AWS web identity federation context keys, unlike :aud. To achieve the desired restriction, you can utilize sts:RoleSessionName. This key can be incorporated into a role's trust policy, mandating users to specify a particular session name when assuming a role.

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
				"Federated": "arn1"
			},
			"Action": "sts:AssumeRoleWithWebIdentity",
			"Condition": {
				"StringEquals": {
					"idp1/:aud": "aud1"
				},
				"ForAnyValue:StringEquals": {
					"sts:RoleSessionName": [
					    "role1"
					]
				}
			}
		}
	]
}

Resources:

profile picture
EXPERT
answered 2 months ago
  • Hello Osvaldo,

    Thank you for addressing my question, when initially reading this document in the past I understood these are examples of standard claims that are added, I did not understand that the rest are stripped, this is very unfortunate.

    Your suggestion to perform role based on session name is interesting, however, I need to perform role assignment based on authenticated attribute, these that are issued by the IDP and not something the user may tamper with.

    Maybe I do not understand this correctly, but I do not see any way to apply backend logic on the identity of the user except of using the audience of the JWT, this means that I need to issue a audience per role instead of having it based on scope or any other useful claim.

    Thanks, Alon

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions