feat!: iauth updates

[suhussai]

Issue # (if applicable)

Closes #54 , #53

Reason for this change

The objective of this PR is to simplify the IAuth interface.

Description of changes

• replace REST API GW with HTTP API GW
• update custom resource in cognito-auth to only create resources that cannot be created in CDK
• replacing custom authorizer with jwtAuthorizer
• enabling PUT /tenants to be protected with JWT Auth instead of IAM. This means that it is available via sync for saas Admin and async for eventBridge target
• added another client for m2m flow. This is used for eventBridge to APIGW authZ
• removed ControlPlaneIDPDetails -- too cryptic/vague
• add pagination for GET /tenants and GET /users
• update sbt-aws cli to allow updating tenants and pagination for GET /tenants and GET /users
• simplified user-mgmt APIs and standardized responses
• added tests for /users functionality

Description of how you validated changes

Checklist

• My code adheres to the CONTRIBUTING GUIDE

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

[tobuck-aws]

A few comments. Lmk if you want to chat.

[PeterGFernandez]

Appreciate the addition of support for pagination here; thank you 😎

[PeterGFernandez]

The use of userId provides a more unique way of identifying a user - especially with something like Auth0. So, using userId rather than username is a better approach. However, I don't think that the username claim for a user should be set to a userId value; username and userId are separate entities, and both are valid for a user 😎

[suhussai]

Good point. I definitely agree that username and userId are two separate entities.

The thing to consider here is that the Cognito API uses username for API operations. For example, if you look at the enable_user(...) function

sbt-aws/resources/functions/user-management/cognito_user_management_service.py

Lines 133 to 143 in f699f38

	def enable_user(self, event):
	user_details = event
	user_pool_id = user_details['idpDetails']['idp']['userPoolId']
	user_name = user_details['userName']
	response = client.admin_enable_user(
	Username=user_name,
	UserPoolId=user_pool_id
	)
	return response

you can see that the username is used as part of the API call:

sbt-aws/resources/functions/user-management/cognito_user_management_service.py

Line 139 in f699f38

Username=user_name,

Docs for admin_enable_user API: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/cognito-idp/client/admin_enable_user.html

So, in order to conform to the new Users API schema, what I'm doing here is using the userId (which end-users will pass in for lookups and other API calls) and mapping that internally to the userName so it can work with the Cognito API.

As I write this, one improvement that I think we need to make is to clarify to end-users what the value they should use for userId. This might require us to map the userName we get from a call such as admin_get_user(...) that we make as part of this function

sbt-aws/resources/functions/user-management/cognito_user_management_service.py

Line 74 in f699f38

def get_user(self, event):

to userId and pass that back to the user. The result would be that the end-user sees userId wherever they would typically see userName and so we avoid confusion. That's something we can iron out, though. Appreciate the comment!

[suhussai]

created issue: #63