Which approach will meet these requirements and priorities?
Create a new database field ג€suspended_statusג€ and modify the application logic to validate that field when processing requests.
Add suspended customers to second Cognito user pool and update the application login flow to check both user pools.
Use Amazon Cognito Sync to push out a ג€suspension_statusג€ parameter and split the IAM policy into normal users and suspended users.
Move suspended customers to a second Cognito group and define an appropriate IAM access policy for the group.
Explanations:
While adding asuspended_statusfield could track the status of customers, modifying application logic to validate this field increases complexity and introduces potential for security issues if not managed carefully. It requires changes to every request-handling function to check the suspension status, which could lead to inconsistent enforcement of permissions.
Creating a second Cognito user pool for suspended customers complicates user management and requires changes to the application login flow. This approach increases operational overhead and could lead to issues with user experience, as users would have to be managed across two different user pools.
Using Amazon Cognito Sync to manage asuspension_statusparameter and splitting the IAM policy would also increase complexity. It involves implementing synchronization logic and maintaining two different IAM policies, which could introduce vulnerabilities and increase the risk of misconfiguration.
Moving suspended customers to a second Cognito group is a straightforward approach that leverages existing Cognito capabilities. By defining a specific IAM access policy for this group, it simplifies permission management and ensures that suspended users can log in but cannot make changes, aligning well with the requirement to reduce complexity and avoid security issues.
From what I’ve heard, the answer is:
Move suspended customers to a second Cognito group and define an appropriate IAM access policy for the group.