TD:LR

What

Feature Requirement

The system must support Single Sign-On (SSO) integration, allowing users to authenticate through a centralised identity provider to access the platform without needing separate credentials.

Requirement Rationale

SSO enhances security by centralising authentication management, improves user convenience by reducing the need for multiple logins, and streamlines access control across different systems and applications.

How

Why

When we started building the AgileData Platform, we used Google Identity and Access Management (IAM) by default from day one, it just made sense.

We also use Google IAM to provide both Authentication capability and Single Sign On (SSO) capability for the AgileData App.

A quick definition of Authentication vs SSO:

• Authentication verifies a user’s identity to grant access to a specific system. 

• SSO enables a user to log in once and access multiple systems without re-entering credentials.

There were a few reasons why using Google IAM made sense to us.

We used GSuite for our internal systems, email, Google Docs, Google Sheets etc.  As a result Nigel and I already had Google Accounts.

When you start using the Google Cloud platform you typically start by accessing it via a Google Account to use the cloud services, which is what we did.

Our initial interface for Change Rules leveraged Google Sheets, so again we could easily access this via our Google Accounts.

When we started to build out the AgileData App on top of the AgileData Platform, we needed to decide how we would authenticate users to the App and how we would support SSO.

We had a few choices:

• Keep using Google IAM

• Introduce the capability for us to store usernames and passwords in the AgileData Platform

• Use a third party OAuth provider, for example Okta or Microsoft Active Directory

For us creating and storing usernames and passwords directly in the AgileData Platform was not a pattern we wanted to adopt, we didn’t want to store Passwords in the AgileData Platform.

It introduces a massive amount of risk when you directly hold those passwords, a risk we did not want to incur.

That left as with the option of using Google IAM or a third party provider such as Okta or Microsoft Active Directory (or whatever Active Directory is called by Microsoft these days)

Both of those products are aimed at Enterprise Customers and at that time we had not identified what our ideal customer type was.  Plus there was an additional and quite substantial cost to both licence those products and to integrate them within our product.

One of our core Principles we operate at AgileData is to leverage serverless capabilities available within the Google Cloud Platform wherever possible.  So naturally that led us to keep using Google IAM as our primary authentication method.

We also started using Google Groups as a foundational service for managing Authorisation and role level security, i.e controlling who could access what.  That felt like a pretty weird pattern, but it is what the Google Cloud Platform uses itself to control role based access, so was the logical pattern for us to adopt.

One of the downsides of using Google IAM is each AgileData User has to have a Google Account to be able to login.  Luckily Google provides an easy way to link a Google Account to an external email address, which meant our customers could log into the AgileData App using their standard corporate email address and didn’t need a gmail address.

A downside of this linked Google Account pattern has been the fact they can’t use the password they use for their corporate email (well they can, but it is not automagically sync’d) to login. We always thought we would eventually integrate Google IAM with our customers’ Microsoft Active Directory environments when needed, a pattern that is well documented.  But we have yet to have a customer where that integration was required.

We did think about opening up the SSO capability to allow users to login into the AgileData App via their social media account, i.e Meta (well Facebook back then) X, (well Twitter back then) etc.  But we felt that most customers would not be comfortable with their users accessing their organisational data via these personal social media accounts.

One of the other benefits of using Google IAM as both our SSO and Authentication service is we automatically inherit the scale and might of Google to identify and mitigate threats.  Something we couldn’t afford to do well ourselves.

Keep making data simply magical