(Studying for my Security cert exam in a few weeks)
I have a generic application design/architecture question: how does one decide between using IAM-level accounts versus just having accounts/IDs as ‘application-level’ abstractions? If one runs, for example, a SaaS startup with 30 employees, a few dev/test environment, one (or more) production environments and, say, 5,000 "users" of the SaaS, I don’t imagine we’d create IAM accounts for those 5,000 users, correct? Or do we?
Just trying to get my around how this translates to topics like identity federation as well. Would one create an app that allows Web Identity federation and create IAM-level accounts for end users? I don’t think so, but not sure.
Thanks!!!
1 Answers
Hello fellow guru,
if you are studying for the Security certification I would encourage you to definitely study this topic pretty well.
As far as I understand you would usually not handle all the user information in IAM but use a directory service (i) and then federate the identities (ii) by using roles.
(i) You may use different identity providers (IdPs) such as Cognito User Pools, Active Directory (via SAML), OpenID Connect and implement OAuth using Cognito. [1] You will get a JWT token to use against a Cognito identity pool. The identity pool will return AWS credentials (secret access key, access key, session token) which can be used to authenticate against AWS services.
(ii) Use a Cognito identity pool to map the identities to IAM roles. [2]
So to make it clear: No, you typically do not need to create 5000 IAM users. You create 5000 user accounts in one of the directory services (or federate them via 3rd party providers such as Facebook, Google). You create an IAM role for each "group" of users which has common permissions. You map each one of your 5000 users to a corresponding role. You can do this automatically using "Rule-Based Mapping" or "Tokens". [3]
In our startup, we use AWS SSO for our internal staff to authenticate and authorize against AWS services. However, I think AWS SSO is too new and thus out of scope for the certification exam. Nevertheless, I think it is good to know that there is a very simple out-of-the-box SSO solution by AWS.
— Martin
[1] https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-identity-provider.html
[2] https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html
[3] https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html
Thank you Martin, I think I understand the concepts, it’s just a more generic question related to understanding the expectations around identity architecture for AWS deployments.
Ok, I think I misunderstood your question a little bit =)
I asked myself the conceptual question whether user accounts from our MongoDB should be transferred to a more advanced and managed directory service such as Cognito or Active Directory. I think that goes in the direction which you have in mind? In the startup I work, we decided against moving our users out of the MongoDB/application-level context because at our stage, it is more cost-effective to manage user accounts ourself (we would not take advantages of the features which managed user directories deliver). It is also easier to manage a custom solution because the majority of our developers are not familiar with AWS services. Setting up and connecting Active Directory properly comes with a big overhead which is sometimes not worth it (esp. for smaller companies) in my opinion. That are my two cents on this topic. =)