We have a SaaS application that accesses our users...
# platform-leadership
a
We have a SaaS application that accesses our users' AWS account for creating S3 buckets. Since we operate in a SaaS environment, our users are not comfortable giving their permanent security credentials. We created the following method to generate temporary credentials :- 1. Create AWS Cognito User Pool with a client 2. Create AWS Identity pool with a policy for the relevant resources We ask our users to pass the User Pool Client ID and Identity Pool ID and then generate temporary credentials from the token received after the user logs into AWS cognito. Source code here. Unfortunately this is a major blocker in terms of UX. We want to make this process as seamless as how GitHub has implemented their OAuth mechanism. We have already tried the AWS Cognito route but right now we are exploring IAM cross account access. We are able to generate temporary credentials but are unable to revoke it when required. Is there a better way of implementing this?
l
One thing you might investigate is using OIDC (this is in fact what Github uses). It requires some setup on your customers' part, but that appears unavoidable in these circumstances: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html
c
I might be misunderstanding the requirements, but why not have your customers just create an IAM role that you can assume with an externalID? https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html Many SaaS tools just use this (e.g. Datadog) for accessing AWS.
c
Assuming you only need to create a small number of buckets, then with S3 you can give another aws account direct access to another bucket with your bucket policy (don't even need an IAM role). Package that up as a cloudformation template and I feel like that would be a reasonable user experience. https://cloudfix.com/ (I am not affiliated) seems to use a similar approach for their service, where you download a generated cloudfromation template from their portal.
a
@Cody Grant We are actually exploring this method. We can generate temporary credentials but unfortunately, token revocation is not possible with this method. This was the only blocker in this method hence i decided to explore other possible options. @Louis McCormack Cody's approach is actually much simpler to get started with, especially when we consider that our majority user base is only using our platform with their private AWS accounts. Once we approach enterprises, we'll explore OIDC.
@Cody Ray Hoeft Actually it's not just S3. Our goal is to control your entire AWS account just via depX. We will introduce a feature for users to build the IAM policy doc on our platform according to all the resources they want depX to have access to. They can simply copy paste it.