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

已提問 3 個月前檢視次數 132 次
1 個回答
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
專家
已回答 3 個月前
  • 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

您尚未登入。 登入 去張貼答案。

一個好的回答可以清楚地回答問題並提供建設性的意見回饋,同時有助於提問者的專業成長。

回答問題指南