By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post

IAM Condition via Principal Tag not working

0

Hi all,

I have an app built in AWS Amplify that uses a cognito user pool for my user base.

In the associated identity pool, I have gone to the Attributes for access control subtab and am using the default mappings. I was having trouble with custom attributes from the user pool so I thought I would get it working with default mappings first.

username - sub client - aud

I am now trying to set a condition using these attributes, condition below:

"Condition": {
	"StringLike": {
		"aws:PrincipalTag/username": "users_sub_value"
	}
}

I get the below error message when trying to run my operation : Error AccessDeniedException: User: <<ASSUMED_ROLE>> is not authorized to perform: dynamodb:PutItem on resource: <<DYNAMO_TABLE>> because no identity-based policy allows the dynamodb:PutItem action

I have tried using the below, just in case but that throws the same issue

"Condition": {
	"StringLike": {
		"aws:PrincipalTag/username": "*"
	}
}

I have done a Null check as well but same issue.

Can anyone shed any light on why this may be happening, or what I may have missed? Is there any way for me to debug what is actually present in the PrincipalTag as well, as currently I am stumped because I have no idea of actually figuring out why the condition is failing in the first place because I do not know what is present "aws:PrincipalTag/username"

Topics
Security, Identity, & ComplianceFront-End Web & Mobile
Tags
AWS Identity and Access ManagementAWS AmplifyAmazon CognitoIAM Policies
Language
English
DinoM
asked a month ago236 views
1 Answer
1

Hello.

Isn't it necessary to allow "sts:TagSession" in the trust policy of the IAM role set in the Cognito ID pool, as described in the following document?
https://docs.aws.amazon.com/cognito/latest/developerguide/using-afac-with-cognito-identity-pools.html

Grant permission to assume the role with the action AssumeRoleWithWebIdentity. Grant permission to tag users' sessions with the permission-only action sts:TagSession. For more information, see Passing session tags in AWS Security Token Service in the AWS Identity and Access Management User Guide. For an example trust policy that grants sts:AssumeRoleWithWebIdentity and sts:TagSession permissions to the Amazon Cognito service principal cognito-identity.amazonaws.com, see Using attributes for access control policy example.

profile picture
EXPERT
Riku_Kobayashi
answered a month ago
profile picture
EXPERT
Oleksii Bebych
reviewed a month ago
profile picture
EXPERT
Giovanni Lauria
reviewed a month ago
  • DinoM
    a month ago

    Hi Riku, thanks for the answer, I actually already have TagSession included, I'd had the error previously without it where it was throwing an invalidIdentityPoolConfigurationException, but that has since been resolved

  • Riku_Kobayashi EXPERT
    a month ago

    How are Cognito ID pool attributes and PrincipalTag's Key set? I think you can see it from the Cognito identity pool authentication provider screen.

  • Leo K EXPERT
    a month ago

    You might also want to check in CloudTrail in your current region or us-east-1 (depending on which STS endpoint is getting called) what it shows as being included in the API call AssumeRoleWithWebIdentity. I'm not sure if the session tags are logged in CloudTrail, but if they are, that should give a good overview of what to expect to be present in the IAM request context keys.

  • Riku_Kobayashi EXPERT
    a month ago

    In CloudTrail, I think it is recorded in an event called "InitiateAuth". I think the event contains the "sub" attribute as shown below.

      "additionalEventData": {
    "sub": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  }
  • Leo K EXPERT
    a month ago

    According to https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html#cloudtrail-integration_signin-tempcreds, also the original AssumeRoleWithWebIdentity API call, including its full response, should be included in CloudTrail. An important thing to note is that STS can be called in pretty much any region, and CloudTrail in one region wouldn't show calls made in another region. The global STS endpoint is in us-east-1.

Relevant content