- Newest
- Most votes
- Most comments
Hi Dennis. When your project scales, managing a large number of IAM users can become complex and cumbersome.
I think creating a Cognito identity pool and controlling permissions based on user attributes may also be a solution.
Here is the AWS example document: Using attributes for access control policy example
Regarding the user's login, I think that an identity pool (federated identity) external identity provider can be used, and the specific configuration documents are as follows: Identity pools (federated identities) external identity providers
Hope my answer can be helpful to you :D
I'd not grant access via IAM Users, you can assign permissions to a bucket to allow another account to place items in the bucket. It'd be better to allow that.
Hi Rob. Thank you for the reply. In this scenario it's application organizations that would get a unique IAM user with a strict policy to only be able to get and put objects in a subfolder dedicated to their organization. So it's not a case of multiple AWS accounts having access to the bucket. As I can read from the other reply, Cognito may be a solution dedicated for this purpose ? I just want to ensure that the individuel organization has the least neccessary permissions to S3 and will not be able to accidentaly access files belonging to another organization, and it has to be handled programatically.
Relevant content
- asked 3 months ago
- asked 5 years ago
- Accepted Answerasked 16 days ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 2 years ago
Hi Wang. Thank you for the reply. I will take a look at Cognito to see if that would be a better solution. We have our own login flow, so would that work ? Or does it require generating identities for each organization ? And would it also have the same possibility to limit access to organization specific subfolders on S3 ?
Sorry for the late reply, I did not receive comment notifications. Regarding your question, you don't have to set up identity for each organization. If your existing authentication method can use SAML and OpenID, it can be plugged in directly, using attributes of an organization's identity as variables in the identity pool role policy to dynamically grant permissions to the organization. For example, if your user attribute has an attribute named "organization", you can specify it in the Resource of the role policy like this: "arn:aws:s3:::${aws:PrincipalTag/organization}/*".