AWS SSO increases security with MFA support

AWS SSO is a managed service from AWS that enables granting users access to AWS accounts and third-party business applications using SAML, Security Assertion Markup Language, an open standard for exchanging identity and security information.

AWS SSO is a highly available service that requires no infrastructure provisioning or operation that you can start using at no cost, and has been receiving new features since it was announced in December 2017.

Some of those features include:

• Available now in 9 regions, including Sydney
• Native integration with AWS Organizations, making it easier to set up and manage user access across all accounts within an AWS Organisation.
• Easy access to Command Line credentials through the portal. This makes it simple to get temporary access keys and secret access keys for command line operations.
• Built in directory for user management, at no cost. With this feature I started using AWS SSO for my personal create-play-destroy AWS accounts.
• Email-based verification. Before this feature and with only username and password verification, AWS SSO was a bit behind other services.
• Audit Single Sign-on activity. AWS SSO logs to CloudTrail

These features translate into multiple options that can cater for many requirements.

You have a handful of users and some cloud applications like Office 365, Jira, BlueJeans or 10000ft. You don’t have a Corporate Directory. In this case you can get started with AWS SSO and the default directory. This default directory will cost you nothing and will require no infrastructure management or operation. The current limit sits at 500 users and 100 groups.

You run an AD to manage users, whether that’s AWS Directory Services AD or on-prem, and want to extend it to access AWS accounts. You can use AWS SSO. AWS SSO will still be at no cost, but you may incur charges associated with running AD.

Long waited MFA is here

On October 25th 2019, AWS announced Multifactor Authentication using authenticator apps. This means that we don’t have to rely on Email-based verification to add that extra layer of security and we can now start using apps like Authy and Google Authenticator to generate time-based one-time 6-digit codes.

Not only is this an improvement in terms of security, it also opens the possibility to use AWS SSO to access your cloud-based email services like Gmail for business and Office 365. Imagine you enable email-based verification to log onto your SSO platform and can’t get the code because your email service is behind SSO. This was actually flagged out in the documentation. I guess someone got a lot of angry users locked out at some point…

Setting it all up

Setting up MFA is very straight forward. First log into the AWS SSO console, and go to settings.

In the User portal authentication section, there are 4 properties that can be configured.

• Prompt users for multi-factor authentication (MFA): You can enable or disable MFA, or pick a third option, context aware, which lets you login with user as password if your device and location are known, or asks you for MFA in case you are in an unknown device or location.
• When prompted for an MFA code: Single option to use app-based authenticator.
• If user does not have a registered MFA device: You can block or allow access or require a one-time email-based code.
• Who can manage MFA devices: You can allow users to manage their MFA devices or have the AWS SSO administrators do it.

As for new users, when they receive the email notification to verify their email and create their password for the first time, if you have enabled user access to manage MFA devices, they will be able to set it up. On the top right corner click on devices and follow the steps to set it up. It is the standard flow where you scan a QR code with Authy or Google Authenticator and enter the time based generated 6-digit code to complete the setup.

Don’t break it! I like to explore services and see what they need to run and do on your behalf. This means sometimes they create resources, like IAM roles and policies. Because of the nature of AWS SSO some of these resources are created across many accounts and can grow overtime as you create more access patterns that map out to user groups. Do not delete them.

When you enable AWS SSO, AWS Organizations grants SSO service permissions to create service-linked roles in your AWS accounts named AWSServiceRoleForSSO. This role is necessary for SSO to create resources in the target accounts on your behalf to enable access.

For every account within your AWS Organization that you enable access to, AWS SSO will create an Identity Provider, or IdP. This resource clearly says DO_NOT_DELETE in the name.

When you create different Permission Sets for an AWS Account, SSO will create an IAM Role for that Permission Set. This role will be assumed by the user when requesting access to the account. All these Roles start with AWSReservedSSO_ and have a trust relationship with the Identity Provider. The description you enter through the SSO console will flow to the Role’s description in the target account. You may want to use this to flag where the role comes from. Unfortunately, SSO is not tagging the role.

Wish List

MFA support is a great new feature, and like a lot of the features that AWS releases, customer requests probably had a lot to do with it, so here is my feature request list for AWS SSO (which I should send through the proper channels)

• Tagging: SSO creates resources on your behalf as we have already seen. It would be ideal to see the service tagging those resources, at least some basic tags that could let us know that resource is managed by SSO.
• API: This is a big one. Currently there is one single way to create all the necessary resources and configuration for SSO to work: the console. This is a bit painful in some cases. Say you are creating accounts with automation and want to add these accounts to SSO and provide access based on some parameters. Today this is not possible. Interestingly enough, these API calls are already logging to CloudTrail and you can capture them with CloudWatch Events.
• Multiple roles support for External AWS accounts: External AWS accounts are those that do not form part of the AWS Organization. Each external AWS Account will show up in the user portal as an application. What we can’t do today is provide SSO more than one role from the external account to present to the user for access, only one IAM Role attribute mapping per application instance is supported. This means you would have to create multiple External AWS Account application instances to use multiple roles, which starts to create many applications in your SSO portal. Not ideal. Thanks to my friend Adam for pointing out this one.
• Physical MFA: Currently this feature only allows you to set up virtual type MFAs like Authy or Google Authenticator, not physical types like Yubikey. You can do this for IAM users though.

Conclusion

AWS SSO is becoming a very good alternative in many use cases. From a free to use configuration for smaller user counts to large scale AD backed user management, AWS SSO will give you that central location to manage access to your ever-growing number of AWS accounts.

Adding MFA is a great feature that was long awaited. I can’t imagine Control Tower deployments for example, with SSO and not being able to enforce MFA for your users.

We are still missing the API to be available for us to consume. It is the missing piece to bring AWS SSO into automated account creation solutions that lets you spin up AWS accounts on demand and provide access to users without manual intervention.

This article was written by Jesus Rodriguez, Cloud Solutions Architect at AC3. Jesus has over 8 years of experience in IT, Certified AWS Solutions Architect Professional, Certified AWS DevOps Professional, and Certified AWS Big Data - Specialty, with a strong focus on implementing, deploying and provisioning secure, high available, scalable and cost optimized applications utilizing the best AWS services for each use case.