The Fine World of AWS Idxxxxty and Access Management
Making Identity Easy from 190never-before — #1: Authentication, Users, and Federation
If you are like me (I assume most people are not), you would have some hiccups with the concepts of identity and access management. For me, as a developer who started with VB 6.0 and then later with ASP.NET, a major portion of identity and access management was limited to Forms authentication and basically writing my own completely hackable code for a long time. Then came SAML, and later OIDC (OAuth x.x), and I was a developer no longer.
In IAM there are 2 primary constructs: authentication and authorization. That is a good line of separation when trying to decompose your understanding. Let us talk about authentication, users, and federation in this blog.
Authentication
Authentication is about signing in to AWS. Who gets to sign in to AWS is dependent on existence of a user or a role within AWS. The “who” is referred to as: Principal. An application can be a Principal too, but I like to think of an application to be a synthetic principal (i.e. not original). When an application requests access to AWS, depending on the zone of trust (i.e. your own AWS account, some 3rd party AWS account, an IdP and its audience or app), the Principal could be a user or a role or an assumed role or a federated user that requests access at the behest of the application. So the principal still boils down to be a user or a role.
In advanced real life settings, typically an app utilizes a role while making the authentication request using
AssumeRole<something-else>(more on that later). Note, that the role itself does not guarantee access, it is the federation, as explained below that provides the access. The role allows or denies actions by this app (user) after the authentication is done.
Let us focus on users first. Users can be an IAM User (i.e. directly created in AWS using the Console, or by issuing aws iam create-user command in the CLI, or by calling the API reference for CreateUser) or a Federated User.
Federated User
Simply speaking, a federated user is one that is already authenticated by a different source. In this case, that different source is typically called an identity provider (IdP). AWS supports federated users from 2 types of IdP: Web identity federation sources like Google, Facebook, Amazon (or basically the IdPs which use OAuth 2.0 protocol) and SAML 2.0 federation sources. For either sources of federation, AWS allows access after exchanging authentication information (a well formed request context which includes a lightweight JWT token + an IAM Role ARN) with a temporary/short lived security credential. Using this security credential, you can then create a signed request to call the AWS API. If you are using one of the AWS SDK, you still use the security credential, but do not need to cryptographically sign the HTTP request as this is taken care by the SDK in use.
When you use a federated user, you no longer create an IAM user within AWS. Instead you create a role. More specifically, you create a role for the IdP (the IdP becomes the trusted entity) in question and assign permissions (permissions: what the role can or cannot do — part of Authorization and for later) to that role. Note that you will have created a role for the IdP in question prior to making this request, and that role will allow or deny actions for the calling app based on the permission that is set with the role. But the role have nothing to do with providing access to AWS, it is the federation (the validity of the authentication token a.k.a JWT) that guarantees access. As stated, the role simply allows or denies actions by this authenticated app (user).
Further reading: Creating an IAM role for SAML 2.0 IdP and Creating an IAM role for OIDC (OAuth 2.0) IdP
Next up: Roles
None of anything mentioned in this blog represents official AWS guidance and may have quality issues.
