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 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.

Federated User: Authentication flow prior to calling AWS. This flow exists outside of AWS, and is an important step for authentication.

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.




Insignificant part of a significant race which is insignificant in the grand scheme of significant things. Working @AWScloud. Views and humors are my own.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

The Ultimate Collection of Mobile Security Resources

Beware, the Microsoft Edge update might contain a ransomware

Product Security — Dev Sec Tips — 2

Mobile App Security Best Practices In 2022

{UPDATE} The Quiz for Aikatsu Hack Free Resources Generator

An introduction to RFID hacking

{UPDATE} Dash Race Hack Free Resources Generator

How to Add & Remove Liquidity to / from JulSwap Liquidity Pool

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Som Chatterjee

Som Chatterjee

Insignificant part of a significant race which is insignificant in the grand scheme of significant things. Working @AWScloud. Views and humors are my own.

More from Medium

AWS Manager — Manage resources and services

The Amazon Cloudfront CDN within our AWS Manager

AWS Amplify

Atos AWS Coaching Hub kicks off 2022 series with a AWS General Immersion Day

A Better Datadog AWS Integration for Organizations with Multiple Accounts