Federated authentication and single sign-on in AWS part 1 – SSO solutions for smaller companies

Lauri Sten • jouluk. 19, 2019

In the first part of the blog series, Lauri will present how smaller companies can easily achieve federated SSO by using SaaS services. In the next part, we will take a look at AzureAD and AWS-provided SSO services.

Introduction

Our company has grown steadily last 24 months. While still small, we have close to 20 professionals working daily with AWS. On top of our base accounts we have a bunch of our own internal service accounts. We have sandbox accounts for each developer. Finally we operate various customer accounts, all with different authorisation requirements.

In the late 2018 we were utilising a standard, centralised IAM account. Everyone had their own, personal IAM user attached to various IAM Groups depending on the tasks-at-hand. Policies attached to Groups defined cross-account access policies and either allowed or denied access to actual workload accounts.

While we were able to have fine-grained access control and follow the principle of least privilege, approach was rather cumbersome. While I was able to switch roles rather easily in the CLI I was forced to have close to 50 different profiles on my configuration file. When using a console I had to use my personal cheat sheet to figure out the account and role I wanted to assume. Our password policy was rather strict, forcing IAM password change rather often. Whenever a consultant returned from a longer gig, password had expired requiring actions from administrators. Personally, after using MFA with push feature previously I felt typing MFA codes were rather clumsy process.

Single Sign-On with SAML

Take a look at any modern enterprise and you notice single sign-on services are everywhere. Employees sign into workstations using domain (Active Directory) username and password after which internal services can be used without providing credentials. Similarly, federation can be used to access external SaaS services.

Single Sign-On has many benefits. Users need to spend less time typing passwords or having means to store various credentials. On the other hand, company needs to spend less on IT costs thanks to unified user administration and reduced number of service desk calls. Similarly, SSO mitigates security risks as credentials are no longer handled externally when using federation.

The most typical example of single sign-on and federation has traditionally been Microsoft Active Directory with ADFS (Active Directory Federation Service). Active Directory stores user and group information. ADFS acts as an identity provider used to establish trust between the organisation and resource (e.g. 3rd party SaaS).

Whenever a user wants to access a resource, ADFS uses identity provider to verify user has sufficient privileges. ADFS issues a token which is passed to the resource using a security protocol (e.g. SAML 2.0). Once verified, access is granted and resources can be used.

Once set up, granting or revoking access to resources is straightforward. Users can be added or removed from groups in Active Directory, instantly allowing or blocking access to respective resources.

The next image illustrates how Active Directory and ADFS can be used to grant federated access to AWS. [1] and [2] provide documentation on how to set up federation.

ADFS Federation explained

User browses to ADFS site with a client.
Identity provider authenticates user against Active Directory. With correct domain, browser and operating system settings user can be logged in using already established (e.g. logged into workstation) session. If not the case, user will be prompted for username and password.
If successful, identity provider will provide a SAML assertion to the client. This XML -formatted authentication response includes e.g. list of allowed roles and SAML providers.
Client posts the assertion to AWS SAML sign-in endpoint. In the background, an API call is performed using the information provided and if successful, access is granted with temporary security credentials.
Client is redirected to AWS management console.

Similar approach can be used with AWS command line tools [3] .

Federation with Google G-Suite

Like many companies our size, we use Google -based services instead of enterprise level tools like Exchange or Active Directory. This leads into less management overhead but unfortunately also less integration opportunities.

On early 2019 I had some spare time between customer projects. Finding our AWS login flow being suboptimal I decided to find a way to make our AWS login flow smoother with less management overhead. I had a few criteria for the solution: I wanted to be able to create user into single a directory, add user into respective groups and access into AWS would be granted automatically. Optimally, I wanted to be able to integrate other SaaS platforms into the solution. The Tool had to be able to support our in-house tool, built on top of Cognito using G-Suite user directory as identity pool.

Upon initial investigation it was discovered that Google G-Suite supports SAML 2.0 -based federation [4]. Since we already use the tool we decided to start our investigation with the tool already at hand. Testing the approach was easy. I was able to set up federation in less than 60 minutes. While being fast, setup also revealed some caveats:

Examples presented were manual and tooling would need to be implemented ourselves.
Required SAML attributes required custom schemas in G-Suite User Profiles. Custom Schemas cannot be added to groups.
Custom Schemas had size limits. Due to the lack of documentation it was unclear what was the current limit.

While being easy to set up, we felt G-Suite -based federation would require too much development compared to ROI.

Federation with Okta

After tests with our existing tools were unsuccessful, we decided to look into other SSO services [5]. Some options (Shibboleth) were ruled out since we don’t want to maintain any infrastructure ourselves, others for various reasons (e.g. pricing, lack of information available, not satisfied with the product specifications). Finally, we had a few alternatives we thought would suit our needs:

Fills the requirements above
SaaS
Established player on the market.

After comparing features and integrations [6] , we decided Okta would be the optimal candidate for our next round.

Taking the tool into use was a rather easy task. After creating a user directory, initial test users and groups, we were able to implement SSO into a single AWS account within minutes. Hooking up multiple accounts was rather easy as well; Okta utilises a cross-account role when scanning accounts for suitable roles. All you need to do is to create a role and provide a list of accounts. Once set up, the application would detect rules suitable for federation after which roles could be assigned to users and roles within Okta. From an end user perspective, the tool is rather straightforward. Users can login to Okta console with credentials and Google Authenticator or push-based Okta Authenticator. Once authenticated, logging into AWS follows a process similar to the one using ADFS above. Similarly, AWS CLI can be used with a separate script [7].

Taking Okta into use

Within a few days we realised capabilities of Okta would be enough for our company. However, we would need some automation to make life of the administrators a bit easier.

We already utilise automation heavily on all possible maintenance tasks. Creating new accounts is performed with AWS API tools. A dedicated maintenance role is also created upon account creation. What we were missing was an automated way to create Okta -related IDP, user roles and cross-account-role (for scanning accounts for suitable roles).

Lots of coffee was spent while delivering the solution.

We have been avid users of Sceptre [8] , a wrapper for CloudFormation. However, we also have an internal CloudFormation wrapper, Takomo [9] , which is built from the ground up to support multi-account environments and extensions. Therefore, it was an obvious choice to utilise Takomo when creating IAM resources for SSO integration.

Our initial workflow for IAM resource automation formed out to be the following:

We have a custom configuration file listing all our accounts. Each account has a definition which stacks to deploy into the account.
Our default stack will create standard user roles (administrator, developer, read-only) and Okta cross-account-role. The stack will also create a custom CloudFormation resource which takes care of creating the IDP.
Since we use standard CloudFormation in the background, we can create fully customised roles to accounts that require more strict policies.
Whenever a new account is created and added to the list, CI/CD launches a deployer script that goes through custom configuration file, running Takomo on the respective account and launching each CloudFormation stack defined for the account.

We still have few manual steps not yet automated. Newly created AWS account ID has to be added to Okta manually (more about this later) before the tool is able to scan accounts for SSO -compatible roles. Once successful, we configure group and role associations manually in Okta.

Conclusion

Our proof of concept turned out to be a great success. After an initial testing phase we hooked up the tool with our user directory and performed the final migration and roll-out.

8 months later, we are very satisfied with the results. The tool has been running smoothly, however we have done some small tweaks here and there. Our initial automation was done with Sceptre before we migrated to Takomo in late 2019. We could add more features to the automation flow but so far we have tried to keep it simple. Biggest issue we’ve faced so far was related to deprecated AWS accounts. We were unable to sync Okta with newly created roles. Upon investigation we noticed the sync process was trying to fetch information from deprecated accounts not removed from a manually maintained Okta configuration, failing and exiting the whole process without noticeable output. This could be automated. However we delete accounts so rarely this is more related to the process and following the documentation.

There has been talk about hooking up Okta with other tools we use. This way we could utilise Okta more efficiently. Even with just AWS, mail and office services we find the solution worth using. It is reducing management overhead and making day-to-day operations more secure.

I recommend every organisation to have a look into utilising federated SSO with Amazon Web Services. We have done multiple implementations using various different sources (Okta, ADFS, AzureAD among others) and the end result has always been the same: increased security, less management overhead and improved efficiency due to easy access to the resources.

In the next part of the blog series we will take a closer look at AzureAD and AWS’s own SSO tool offering. Stay tuned!