A Case Study comparing Azure and Okta

‍

Introduction

Identity management systems play a vital role in many organisations, not just in reducing the cost burden of improving response times in user access to applications, but also increasingly as a key pillar of “zero trust” security.  Integrating, consolidating and improving a user’s identity systems will go a long way to improving overall security where traditional ‘trusted’ boundaries are increasingly blurred.

In this blog post, I will be providing a brief overview of the benefits of identity management systems and then relaying my technical experience through a case study in setting up automatic user and group provisioning of Google Workspace User & Group accounts using Microsoft’s Azure Active Directory and Okta. I will also briefly compare Azure Active Directory and Okta.

This case study would achieve the following outcomes for an organisation:

• Eliminates the requirement for new Google accounts and passwords to be given out to Employees.
• Significantly lowers risk for employees accessing Google data via the organization’s identity provider e.g. Azure AD, including Azure AD password, MFA (SMS, Phone Authenticator and/or FIDO2 keys) and potentially advanced Azure identity protection mechanisms such as risk-based policy detections and conditional access.
• Ensures Google accounts are automatically deactivated (and license costs reduced) when for example Azure AD accounts are disabled.

Why have an Identity Management system?

Identity Management (often just ‘IdM’ or ‘IDAM’) systems, if properly implemented, can reduce organisational cost and improve security by:

• Providing single sign on (SSO), such as implementing federation, and eliminating multiple application specific passwords.
• Allowing Multi Factor Authentication (MFA) to be introduced more rapidly.
• Enabling identity governance and User Access Review (UAR) systems, which in turn avoid an explosion of administrator roles.
• Allowing HR or payroll systems to tie into user authentication systems (such as Azure AD) to rapidly provision or deprovision access when an employee or contractor starts or stops providing services.
• Providing the foundation for introducing a ‘Zero Trust’ architecture which brings significant security benefits.

Application vendors are also increasingly looking at cloud-based customer identity (often abbreviated to ‘CIAM’) systems such as Auth0 and Azure B2C, to introduce MFA and risk detections around customer logins, to reduce the risk of data breaches caused by weak customer password practices.

The downside to IdM systems (and hence reasons why they may not be widely adopted) are that they can be costly to implement, require significant testing and are not often agile or responsive to the changing requirements of an organisation.

IdM systems can also require a lot of custom code  and often this code is not maintained or kept up to date as applications change.  This is especially true of cloud based or SaaS applications which, due to CI/CD & DevOps, are in a continual state of code change.

However, in an increasingly cloud based world, where especially new organisations are increasingly relying on almost 100% provided cloud-based IT services and not investing in any on premises systems (even in private cloud models) – ‘cloud to cloud’ identity architectures are becoming increasingly common.

Advantages of ‘Low Code’ Cloud Identity solutions – Case Study

I’ll now outline how simple it can be trying to synchronize your authentication system with ‘cloud to cloud’ synchronization model using a ‘low code’ approach.    As I will outline later in this blog, I never set an expectation of ‘zero code’ as often cloud vendors will present some short comings that can only be overcome with custom code.

This example will look at both cloud identity providers, Azure & Okta, including synchronizing your user accounts and groups with the cloud application: Google Workspace (formerly Google GSuite).

SAML and Open ID Connect (OIDC) federation setups are generally relatively easy to setup to allow for centralised SSO and MFA from your cloud provider, but they require users & groups to be present in the target application before a user can sign on.  This can be achieved using ‘provisioning’ features of a cloud identity system such as Azure and Okta.

I thought I’d relate my technical experiences recently setting up the automatic user & group provisioning of Google Workspace User & Group accounts using Microsoft’s Azure Active Directory, and Okta.

Azure to Google Technical Setup

Azure Active Directory (AAD), as well as other cloud based IdM systems such as Okta, have worked with application vendors, including Google, to provide ‘templates’ – that not only allowing an organisation to ‘federation’ and use your AAD user credentials to login to these applications (using SAML or Open ID Connect protocols), but increasingly these ‘templates’ are providing user & group provisioning capabilities as well.

Azure calls these ‘templates’, found in the ‘Enterprise Applications’ in the ‘Gallery’. Okta calls these Okta Integration Network or ‘OIN’ templates (https://www.okta.com/okta-integration-network/).").

These documents are fairly straight forward to follow.

Azure AD User to Google Provisioning Azure guide:

https://docs.microsoft.com/en-au/azure/active-directory/saas-apps/google-apps-provisioning-tutorial

In comparison to Azure, Okta has a newer connector that has specifically been updated with the recent rebranding of GSuite to Google Workspace.

Okta User to Google Workspace user & group provisioning guide:

https://help.okta.com/en/prod/Content/Topics/Provisioning/Google/google-provisioning.htm

I won’t repeat the above steps here, but after a day, I was up and running with at least the SAML portion of Azure to Google (w/ both Azure & Okta) – so users could login to Google with their Azure user credentials and Microsoft Multi Factor Authentication (MFA) to Google Workspace based applications.

The user and group provisioning aspects prove more complex and therefore worthy of more guidance.

Azure and Okta Learnings

Following the ‘User Provisioning Azure guide’, linked above, here are some major learnings that aren’t with both Azure and Okta:

Learning #1: Google Workspace won’t allow you to create accounts whose email values end in a domain suffix (@somewhere.com) that is not verified in the ‘Domain’ section of Workspace (https://admin.google.com/u/3/ac/domains/manage)

Learning #2: You’ll need a minimum of four attributes in Azure AD and Okta to provision to Workspace - the two mandatory attributes: User Name & Name, but also ‘First name’ and ‘Last Name’ too.

Azure example:

If your Azure AD or Okta accounts aren’t properly data enriched, like the above, you’ll see something similar to this in the Azure Provisioning Logs: “Invalid Given/Family Name”:

The connector will assume control of accounts that are already created in Workspace.  So, if you had previously created accounts manually, they’ll effectively be under Azure control after the provisioning is enabled.   Be careful not to lock yourself out!

If a user is removed from the Azure or Okta ‘application assignment’ list, it will send a ‘disable’ action to Workspace:

The user will then have a status of ‘suspended by admin’ in Google Workspace:

However, you can right-click on the user and ‘reactivate’ them manually if you want them to login if they’ve been unassigned from Azure’s Workspace application (handy if you’ve accidentally locked yourself out!)

Azure Specific Learnings

Learning #5:  It wasn’t clear to me reading the documentation but the full system logs for the Azure Workspace connector can be found in the ‘Audit Logs’. When I first setup the connector the ‘Provisioning Logs’ were initially empty for me.  If you’re trying to understand any errors and the ‘Provisioning Logs’ are empty, review the ‘Audit Logs’ for more information.

Learning #6:  Azure AD groups, including Active Directory synchronized groups, do not store an ‘email’ attribute for that group (unless you’re only using Exchange Online synchronized Distribution List groups).

For that reason, the default synchronization rules need to be adjusted to ‘inject’ an email address domain suffix onto them, otherwise they will not be able to be pushed to Google Workspace (as it will reject those that don’t have an email value).

I’m not sure why this isn’t included in the default rules to avoid this problem, however I used the following code to add a simple text string for the domain suffix to allow the groups to reach Google:

Append([displayName], “@.com”),  ‘email’ G Suite (Workspace) attribute:

Comparing Azure with Okta

Okta versus Azure - Logging

It’s probably strange to bring up ‘logging’ but with cloud-based provisioning systems, but your only opportunity to really understand how these systems work at a deep level is to review the audit logs of these provisioning systems.

I’ll quickly compare Azure AD and Okta logging:

Azure

Azure group sync log example:

This presents a clear outline, per synchronized object, as to the exact actions that occurs in the remote cloud directory.

Okta

Okta group sync log example:

Okta conversely will instead present a high-level summary e.g.: “Group Push – pushing memberships” but no outline as to the exact action that occurs making it more difficult to diagnose if there’s missing data in Google Workspace.

Okta versus Azure - Group Assignments

Azure

Azure currently only gives you two options in terms of the ‘Scope’ of which users & groups should be provisioned, effectively:

1. ALL users & groups in Azure AD, or:
2. Those ‘assigned’ to the Azure application

If you look into the Assignment tab of the Azure application, you only have effectively the option to assign people & groups in a static list:

‍

Okta

Okta by contrast can push a dynamic list of groups using ‘Groups By Rule’ – this essentially means you can send groups starting with ‘GSuite_’ e.g. ‘GSuite_All_Finance_Users’.   Other ‘By Rule’ options includes ‘ends with’ or ‘contains’.

This essentially allows for a lot more flexibility with Okta, by changing the naming standard for Google based Azure AD groups (e.g. role-based groups based on Google data sets), Okta will automatically detect and push all groups per that naming standard e.g. ‘name starts with ‘Google_’’ etc.

Azure, however, will only push either ‘Assigned groups’ – groups that are manually or with code assigned to the Google application (which grants access to the Google application).   This presents significant management overhead and ongoing script maintenance.

I recently integrated this for a customer and we ended up having to write some Python code that resided in an Azure Function, that would detect new groups reaching Azure AD (that started with a naming standard e.g., ‘Google_’) and then assign them to the Azure application.   We could not use the ‘Sync all users and groups’ to the sheer volume of groups in Azure AD plus avoiding filling up Google Workspace with unnecessary group objects.

Summary Table – Azure v Okta, provisioning to Google

Finally, a summary table comparing the two provisioning engines features is outlined below. Obviously, there are many more IDM products on the market today, so be sure to compare your requirements to as many available vendors as possible.

‍

General Provisioning Integration Recommendations

I would recommend the following when looking at implementing SAML or OIDC federation and provisioning:

• Test both SAML federation and provisioning features in a non-prod environment (if one is available to you).  Often organizations don’t want to spend money on cloud tenants dedicated to non-prod, so if you’re doing this only in production then integrate provisioning FIRST, and make sure both systems are synchronizing and working end to end for all test scenarios.    Do not integrate with SAML first, as a newly onboarded user will not be able to login until their accounts using SAML federation, until their accounts are synchronized to the target application through provisioning.
• Not all applications require provisioning, such as Amazon Web Services (AWS) which tracks users via SAML attributes but doesn’t store any type of user account with a credential after the session is finished, so adapt your strategy for the target application’s requirements.
• Be aware some cloud-based web applications support ‘Just In Time’ (JIT) provisioning, which essentially allows for a user account to be created when the user logs in first time through federation.  This allows for a simpler provisioning architecture, as there is no wait for any synchronization processes before a user can access an application, but many often lack any kind of user account removal process.   Many will rely on account expiration processes (e.g. disable an account not used for 3 months etc.) but this might leave application access potentially exposed if not periodically reviewed by administrators.   Federation should disable access in the medium to long term, but short-term access might still be achieved if session lengths are long.

Conclusion

This case study is just one example where some low code, rapid identity integrations, often using technologies that customers already have such as Azure AD, can drive quick security wins and protect organisations from identity-based attacks.