SSO at Grabyo

Continuous improvement of security posture is core to our Security policy and best practices, and so at the beginning of the year, we migrated our internal tools from a secure username and password with multifactor authentication to a Single Sign On authentication system.

Why SSO?

If you’ve ever used your Google or Facebook login to access an app, you’ve used SSO. In simple terms, it is the ability to login into another application using your identity from another platform (i.e. Google, Facebook, Okta, etc.).

In this blog post, we will uncover how SSO has transformed our user management for our internal tools, exploring its benefits and the main technologies we have used to make it happen.

To fully understand the benefits of SSO, let’s compare the different user workflows before and after implementing SSO.

Access to AWS accounts

Before SSO

Before we implemented SSO to access our AWS accounts, we had a dedicated AWS account for user management called “the Identity account” as per AWS recommendation.

For better governance, this account only held IAM user permissions to other AWS accounts and did not run any other workflows or services.

When a new employee joined or left the business, our operations team would need to create or destroy a new user manually.

In the old setup, to access our AWS accounts, our employees had to first log into the Identity account with usernames and passwords and then assume a role to access other accounts.

One of the most significant downsides of this approach was letting our engineers know which roles they had access to in our different accounts.

After SSO

With the introduction of SSO, we migrated our user permissions from the Identity account to AWS IAM Identity Center (we’ll cover this technology in more detail later in this post). Unfortunately, our operations team still requires to manually provision users and permissions on this tool for all our AWS users.

User access is one of the most significant benefits of SSO. Users no longer need to manage multiple usernames and passwords. Instead, they log in using their Identity Provider account (IdP from now on – we’ll cover this technology later) to access the following portal:

As you can see, this console lets the user know the accounts and roles he has access. Furthermore, accessing these accounts is as simple as clicking a button.

Finally, when a user leaves the business, their access to our AWS accounts will get immediately revoked as soon as their IdP account is revoked (the first offboarding step).

Access to AWS Client VPN

Before SSO

Before we implemented SSO, the workflow for provisioning new users required:

• First, create an individual certificate for every user.
• Then, generate a custom VPN configuration file so the VPN client can connect to the VPN endpoint with the certificate.
• Finally, distribute these files safely to the end user.

If you are unfamiliar with SSL certificates, let me tell you that storing and distributing them securely is not a trivial process!

The end users of our VPN needed to download the previously mentioned files to their computer, install the VPN client software and load the given configuration. Once the setup was completed, connecting to the VPN required a simple button click. However, please note that this connection does not require any additional password prompt bringing an additional security risk.

Revoking access for a user to our VPN required the revocation of the certificate on the VPN endpoint.

After SSO

AWS Client VPN has direct integration with AWS IAM Identity Center. Providing access to our VPN requires an AWS user with the right IAM permission to access the VPN client. Once the user is created, they can log into the SSO portal using their IdP account.

On the SSO portal, they get direct access to AWS Client VPN Self-Service Portal.

On this portal, they can easily download a fully auto-generated configuration for their user and the right client for its architecture.

Once they set up the client, connecting to the VPN will prompt a browser tab where the user will need to authenticate with their IdP account without any need for certificates or passwords.

Finally, when a user leaves the business, their access to our AWS Client VPN will get immediately revoked as soon as their IdP account is revoked (the first offboarding step).

Access to Grabyo Tools

Grabyo Tools is a web application built in-house whose primary purpose is to help Grabyo employees to manage the Grabyo platform for our customers.

Before SSO

These tools had their user database, and these users were created by any of the admin users of the tool. Revoking access was again a manual process driven by the same admins.

All users of these tools must be connected to our VPN and use multifactor authentication when logging in for added security.

After SSO

The workflow for user provisioning is almost identical to before. An admin user on the Tools platform must create a user inside tools. However, there is no need to set up passwords or MFA because users will now log in using their IdP account instead.

Finally, when a user leaves the business, their access to our Grabyo Tools will get immediately revoked as soon as their IdP account is revoked (the first offboarding step).

In summary

Now that you have seen how our workflows changed with the introduction of SSO, I think it’s worth highlighting the significant benefits we were seeking with the introduction of SSO.

Passwordless logins

In conjunction with a good password policy, employees have to use unique passwords for each tool and service, and these passwords should be rotated regularly.

However, with SSO, managing these many different passwords is no longer needed as access to tools and platforms is federated through the identity provider.

Centralize user access management

Before SSO, when an employee left the company, we needed to revoke their access individually on all these tools manually. This was time-consuming and a considerable security risk in case one of the platforms was forgotten.

With the introduction of SSO, we only need to revoke the user access to Grabyo’s Identity Provider, and access to all other tools will immediately be revoked.

A final comment about user provisioning

User provisioning is the process of assigning permissions based on roles and event changes throughout an account’s lifecycle. Provisioning (and de-provisioning) grants, modifies or revokes access and privileges based on triggers such as:

• New hire.
• Role change.
• A move to a different business unit.
• Termination.

It’s important to clarify that user provisioning is a future milestone of our security roadmap. However, it was not a requirement for this project, where we solely focused on implementing SSO.

Let’s get technical

We don’t want to dive deep into the technologies and protocols used to leverage SSO. You can find tons of material online explaining these concepts in great detail.

Instead, we want to discuss the architecture and main technologies used to highlight that most of this work was achieved with minimal development effort.