data-dot-all
Optimizations in fetching user groups in custom authorizer when using External IDP Implementation
Is your idea related to a problem? Please describe. In order to trigger graphQL api call, groups information is needed. When using Cognito , this information is available as a part of claim in the ID Token. When using the External IDP, which doesn't store this information, this information can be fetched from any External User Pool Provider.
Whenever the GraphQL Api Handler Lambda is called , this External User Pool Provider API will have to be called to fetch this group information. Considering the number of graphQL calls which are made when a user navigates from one screen to another, this quickly can cause scaling problems for the External User Pool Provider.
Describe the solution you'd like Whenever the user logs in , this groups information can be stored in the frontend's local Storage. But local storage is not that secured .
How about if we encrypt the local storage ?
One such implementation is - https://www.npmjs.com/package/react-secure-storage
As other enhancements for the IdP PR, we could add the comments made on how to pass variables to the CICD:
The amount of variables in this block (deploy/configs/frontend_config.py) and in the one in deploy/stacks/pipeline.py is getting very long. For custom_auth we are reading CodeBuild env variables that are PLAINTEXT. Maybe it is time to review this process, as a proposal we could use PARAMETER_STORE type of CodeBuild env vars: https://docs.aws.amazon.com/codebuild/latest/APIReference/API_EnvironmentVariable.html We would store the cdk.json as an SSM parameter and make it available as environment variables or directly reading it in the frontend_config script.
Also adding a followup item on a functino get_groups_for_user which is not used in the dataall/base/aws/cognito.py file but can be implemented with cognito boto calls just for consistency
Thanks for opening the issue @TejasRGitHub. We will come back to this issue after we share our 2024 roadmap