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

preguntada hace 3 meses132 visualizaciones
1 Respuesta
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
EXPERTO
respondido hace 3 meses
  • 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

No has iniciado sesión. Iniciar sesión para publicar una respuesta.

Una buena respuesta responde claramente a la pregunta, proporciona comentarios constructivos y fomenta el crecimiento profesional en la persona que hace la pregunta.

Pautas para responder preguntas