Refactored Cognito AAI from Data Portal stack

[williamputraintan]

• Break out Cognito User Pool and Identity Pool from Data Portal
• Imported existing resources
• Migrated terraform states
• Improved structure and code arrangement

[victorskl]

As discussed, the plan is to refactor the TF code including their TF state migration into separate stack. It will get a bit touchy with state import, anyhow, in tick, next down the track. So, let me take it from here. Thanks for the try, Will!

[victorskl]

Status: @victorskl will take over branch and follow up with changes.

[victorskl]

Okay! This refactor is ready to go to this point. Going to merge in tick, next.

[victorskl]

@williamputraintan Just FYI and, feel free to have a peek into diff. No action required on your side.

[williamputraintan]

Wondering what do you think of defining SSM Parameter for cog_user_pool_id, cog_app_client_id_local, oauth_domain from the main stack, then for any future app could just refer this user_pool from their own stack? Ideally we do not need to keep changing this stack for every new app. (let the new app handle by its own stack)

By this means, app that is defined here such as sscheck or status_page need to refactored out to their own stack.

[victorskl]

Yep; that was the initial idea, remember? You have faced issue trouble creating with CDK or something; in those early days for sscheck/status-page. Hence, we did this quickly here.

[williamputraintan]

Yup! The trouble was adding a new app_client to the same identity_pool. Realising that identity_pool is not required, and if required we could just create a new identity_pool in the app itself instead of adding it to the existing one.

[victorskl]

SSM Parameter for cog_user_pool_id, cog_app_client_id_local, oauth_domain from the main stack

This are already in SSM; just that, they still bear /data_portal/... coordinate for now. We could change this to /umccr/... or something else later. But that's pure textual naming issue we can tackle in next iteration. For now, we just focus on splitting out code and migrating existing states.

[victorskl]

The trouble was adding a new app_client to the same identity_pool. Realising that identity_pool is not required

Ah! Right, I remember now! Okay.

and if required we could just create a new identity_pool in the app itself instead of adding it to the existing one.

Understood. This can be done, yes. But, we probably wish to reduce multiple/many Identity Pools spinning up. We shall see; case by case basis, though.

[williamputraintan]

This are already in SSM; just that, they still bear /data_portal/... coordinate for now. We could change this to /umccr/... or something else later. But that's pure textual naming issue we can tackle in next iteration. For now, we just focus on splitting out code and migrating existing states.

Yup sure! I was planning to move out sscheck and status_page from this stack

[williamputraintan]

Understood. This can be done, yes. But, we probably wish to reduce multiple/many Identity Pools spinning up. We shall see; case by case basis, though.

Sure! ( My consideration is spinning up Identity Pool is free and I assume needing identity pool means that there is a specific need for that app 😅 )

[victorskl]

Yup, yup, correct!

[victorskl]

Merging...