One thing I don’t understand from the lecture is what role the user will assume once authenticated. Given the user is not “configured” in IAM, where are his/her permissions/policies defined? Is there a mapping somewhere or a configuration place that is not shown in the lecture?
Thanks a ton in advance if you know the answer, cause that has been buggering me for quite some time 🙂
3 Answers
Generally, it is the application being used that requests to assumeRole, so the app developers need to coordinate with IAM admins to get the correct Role information.
Steven had a great answer, but I’d like to add that can be dependent on what you’re serving to the user in combo. with Cognito.
In my experience, using Cognito in combination with an API gateway (Very common when utilizing a serverless architecture for a public application).
For instance, static-web hosting through an API gateway. You’re wouldn’t specifically grant a user access to a resource, but instead, you’re hosting a custom web application that has a backend of aws resources. You may grant permissions to the user using Cognito based on what you want the user to be able to do on the website (normal user, super user, admin, maybe profiles), by placing users into groups in Cognito User Pools. From there the actions the user requests to make (if they have the permission based off the group they’re in) invokes a lambda function that has the actual IAM roles to access the private/"public" AWS services. This way, users never get past the API gateway. And you don’t have to give or grant users IAM permissions. Very similar concept to using S3 bucket policies over IAM.
Regarding the mapping aspect of roles. You have to create the the role with suitable/same name on both sides – AWS and IdP. On the AWS side a Policy/permissions is attached to the role.
So when the user gets the "named role" from the IdP – it assumes the corresponding AWS mapped role (and the permissions thereof).
Makes total, sense. Thanks a ton!
Thanks, it makes sense