Skip to content

AVP: IsAuthorizedWithToken not picking up users Cognito Group

0

In AVP i have the following policy template;

permit (
    principal == ?principal,
    action in [NS::Action::"ListUsers"],
    resource
);

I'm using IsAuthorizedWithToken. Essentially with a policy that grants this action to the Group;

permit (
    principal == NS::Group::"my_pool|My_Group",
    action in [NS::Action::"ListUsers"],
    resource
);

IsAuthorizedWithToken DENIES access

However a direct policy against the user works.

permit (
    principal == NS::User::"my_pool|My_User",
    action in [NS::Action::"ListUsers"],
    resource
);

No "policies" are being returned in the "DeterminingPolicies" in the deny response.. not sure what to debug/try. Using the test bench I can verify against the group directly the decision is ALLOW.

I do have another policy template and policy that works for a similar process;

permit (
    principal == NS::Group::"my_pool|My_Group",
    action in [NS::Action::"ViewWorkspace"],
    resource == NS::Workspace::"WorkspaceA"
);

So the Congito and AccessToken side seems to be working ok.

2 Answers
1
Accepted Answer

The policy needed to be in principal not *==", cries.

permit (
    principal in ?principal,
    action in [NS::Action::"ListUsers"],
    resource
);

answered 2 years ago

EXPERT

reviewed 2 years ago

1

It appears that you're encountering an issue with Amazon Verified Permissions (AVP) where the IsAuthorizedWithToken operation is not recognizing the user's Cognito group membership. This is a common challenge when working with AVP and Cognito integration.

The problem likely stems from how the group information is being passed to AVP. When using IsAuthorizedWithToken, AVP populates the principal attributes from the claims in the user's ID or access token. If the group information is not present in these tokens, AVP won't be able to match the user to the group-based policy.

To resolve this issue, consider the following steps:

  1. Ensure that the Cognito user pool is configured to include group membership in the ID and access tokens. This may require adjusting the user pool settings or using custom attributes.

  2. Verify that you're using the correct token type (ID or access token) that contains the group information. Remember that ID tokens and access tokens contain different sets of claims, and you need to use the one that includes group membership.

  3. Check the format of the group identifier in your policy. The format "NS::Group::"my_pool|My_Group"" should be correct, but ensure that "my_pool" matches your Cognito user pool ID and "My_Group" exactly matches the group name in Cognito.

  4. Examine the token claims to confirm that the group information is present and correctly formatted. You can decode the JWT token to inspect its contents.

  5. If you're using a Lambda authorizer with API Gateway, ensure that it's correctly passing the token to the IsAuthorizedWithToken operation.

  6. Consider using the AVP test bench to debug the authorization decision process. This can help you understand which policies are being evaluated and why they might not be matching.

If the group-based policy still doesn't work after these checks, you might need to adjust your approach. One alternative is to include group membership as a custom attribute on the user and reference that in your policies instead of using the group directly.

Remember, when no policies match the request, AVP returns a DENY decision with no determining policies, which aligns with what you're observing. This suggests that the group-based policy is not being considered in the evaluation, likely due to the group information not being available or recognized in the token claims.
Sources
Community | Using Verified Permissions with Cognito to control access to API endpoints
Implementing authorization in Amazon Verified Permissions - Amazon Verified Permissions
IsAuthorized - Amazon Verified Permissions

answered 2 years ago

EXPERT

reviewed 2 years ago

  • 1&4. Cognito User pool is set-up to include the group information. Can verify presence of the group decoding the token, 2. Using the access token, but again can see presence of the group in this token (it also works on another call). 3. all identifiers are correct. 5. not using a lambda authorizer. 6. test bench allows responds with ALLOW as expected for the group

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.