Goodbye SAML, Hello OpenID

At ayloNet, we are currently working on a major project to migrate all of our authentication federation from SAML (Security Assertion Mark-up Language) to OpenID / OAuth. We have done this for a number of reasons and as part of this migration we are:

  1. Centralising all authentication and authorisation to Azure Active Directory and decommissioning FusionAuth (also known as ayloAuth).
  2. Migrating SAML only applications (such as Google Workspace login) to Azure Active Directory.
  3. Migrating all suitable applications to OAuth / OpenID.

Why are we making this change?

OAuth and OpenID are now our platform of choice for a number of reasons:

  • Use of JSON rather than XML, which is better supported and understood within our environment.
  • Better support with modern applications and the ability to add additional attributes quickly and from a verity of different services.
  • Easy to secure, manage and maintain.

Why are we using Azure AD?

We have already been using Azure Active Directory as our primary IDP for over 18 months and it already acts as a single-source of authentication truth. Azure AD also comes with a number of other advantages within our enviroment:

  • Our Machines are all Azure AD joined, providing a true Single-Sign-On experience to our users, without the need to re-authenticate.
  • We have started rolling out Passwordless Authentication to our non-privileged accounts.
  • It improves consistency between our Exchange, Google and Azure environments without the added complexity of an intermediate IDP.
  • For applications that don’t support SAML or OpenID, we use Microsoft’s Password Based Single-Sign-On technology so the login process remains transparent of the end user and service specific passwords are not required.

The Current Authentication Flow

Our current authentication flow is a bit of a mess due to different app compatibilities and a number of issues with our FusionAuth IDP implementation. In summary, most apps look like this:

Existing Authentication Flow

When a user visits an application, they are taken to the ayloAuth connection broker, which provides the user with a list of authentication providers that they can use. For most applications, the user selects “Login with ayloNet” which redirects them to Azure AD, but for some applications additional options are available to provide high-availability should a problem occur with Azure AD.

The biggest problem we have with this is that our entire HA solution revolves on the user having an active Google Workspace token. If they don’t, they are stuck because we use Azure AD to sign in to Google (see the issue there?).

This authentication flow consists of a mix of SAML and OpenID service providers with all sorts of garbled security settings depending on the specific app.

The Future

The user authentication flow now becomes very simple and simply involves calls between the application and Azure Active Directory. No authentication will take place using Google Workspace going forwards and therefore the need for an identity broker is no longer required.

We are also advising that all authorisation uses OAuth or OpenID protocols and we aim to remove all SAML connections within our environment. This leads to a number of applications that need to be changed, including:

  • Jira
  • Confluence
  • GitLab
  • Google Workspace.

Some of these applications already have native support for Active Directory (or generic OAuth) including GitLab, other applications will need new plugins (including Jira and Confluence) and finally some applications are unable to be upgraded at this time due to vendor constraints (Google Workspace).

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *