AWS Two Factor Authentication – what are the differences between SSO and IAM?
One of the most challenging topics in AWS security is controlling access to the management APIs, also known as the control plane. Cloud security incidents are frequently caused by misconfiguration of privileges, ranging from the ubiquitous world-readable S3 bucket to use of ill-gotten credentials for users or roles with excessive access permissions.
The IAM service is the foundation of AWS security, since it controls authentication and authorization of access to the AWS APIs. It allows the usage of multi-factor authentication (MFA) and granular policies and integrated and support the entire AWS service ecosystem.
For organizations with non-trivial AWS environments, though, it is imperative to segregate their environment into separate AWS accounts. The segregation allows for better access management and also containment of the blast radius of any security incidents. This approach creates a challenge, though, since IAM user accounts are restricted in scope to a single AWS account. The best practice is to use an identity federation service to grant controlled access to the different AWS accounts, avoiding the creation of a huge number of IAM user accounts and credentials.
It was precisely to support this federation that AWS Single Sign-On (SSO) was created. It allows the use of an internal user directory or integration with a cloud-based or on-premises Active Directory to easily grant users controlled access to a variety of AWS accounts.
Until recently, the only way use SSO with MFA was to integrate it to an Active Directory environment that was configured to enforce MFA. In late October, though, SSO announced it was now possible to add TOTP authenticator validation even if the user directory used password-only authentication. This brought the service closer to the native MFA support IAM users have enjoyed for a long time.
Given that AWS itself is implementing this second authentication factor for SSO logins, it would stand to reason that it would behave similarly to IAM MFA as far as logging and access control policies. So we decided to test for ourselves if this was true in two specific ways:
- confirm if Console actions performed by SSO users logged in with TOTP would be identifiable in CloudTrail logs as having been performed with MFA;
- confirm if it’s possible to use IAM policies with conditions that require MFA to be used for SSO users;
An API call performed by an IAM user without MFA creates a log entry like this on CloudTrail:
If that same IAM user was logged in using MFA, a field called mfaAuthenticated will be populated with the value true to indicate it:
The perhaps surprising find is that when you use SSO to access the AWS Console, even though MFA was used to authenticate, the mfaAuthenticated field is set to false:
It is safe to conclude, then, that test 1) has failed.
We move on to test 2), using IAM policy conditions to demand that certain operations only be allowed to users logged in with MFA. We create a very simple S3 bucket policy denying any action starting with List* to any users not authenticated using MFA:
Then, we try to access this bucket with MFA authenticated IAM and SSO users.
The IAM user succeeds:
The SSO user is denied access:
So we conclude that test 2) has also failed, as the IAM policy condition on MFA usage is not honored for SSO users even if they did log in with MFA.
However counterintuitive this behavior is, though, it seems to be consistent with the documentation – it states that federated users and STS temporary credentials obtained by AssumeRole do not support MFA. SSO actually implements a form of federation, and generates credentials using AssumeRole for CLI access to the different AWS accounts. So even though it is AWS itself performing the MFA authentication, this fact is not recognized in the logs nor policies.
Written by Rodrigo Montoro and Alexandre Sieira.
Our thanks to Paul Wakeford and Josh Frantz for their contributions to the Slack thread that motivated this blog post.
