Single sign-on (SSO) for Google Workspace

Google Workspace (formerly Google Apps) felt radical when it launched in 2006. One of the first major applications to run in the cloud, it was hosted on someone else’s infrastructure using a software delivery model that would later be known as software-as-a-service (SaaS). It also introduced what seemed like an interesting innovation: the ability to sign into multiple applications using a single set of credentials.  

But this relief was short-lived. As more applications moved to SaaS, the number of credentials users had to manage kept growing. Today, while the cloud model Google helped pioneer is the norm, it’s created a new challenge: how to manage all those accounts and credentials.

Back in 2006, most networks were still on-prem. That meant users could authenticate using a single credential. The shift to SaaS broke that model. Each cloud app came with its own login, creating friction for users and security headaches for IT.

Over time, SaaS sprawl has scaled badly, risking overwhelming users with too many credentials.

Today, the solution to this credential bloat is single sign-on (SSO). With SSO, employees use a single gateway credential that authenticates them to multiple applications. No need to remember or enter separate credentials. In Google environments, this typically involves setting up a cloud identity provider (IdP), like Google’s own Cloud Identity, to perform the SSO authentication.

But there’s a catch. This setup forces organizations to rely on a cloud identity provider (IdP), which makes them reliant on an external authentication provider.

For teams committed to on-premises Active Directory (AD), whether for compliance, security, or cost reasons, this can be a deal breaker. Implementing SSO through an external IdP also raises the total cost of ownership, especially when adding vital security measures such as multi-factor authentication (MFA).

There’s also the risk that SSO becomes a single point of failure. If attackers compromise an SSO login, they can gain access to every connected app. That’s why best-practice SSO setups always include layered security, including strong password policies and MFA.

UserLock SSO offers a simple, secure path to solving common cost and risk blockers to implementing SSO. It’s built for organizations that want to simplify hybrid Active Directory security, without moving away from their on-premises identity infrastructure

Instead of forcing you to adopt a third-party IdP, UserLock lets you build SSO directly on the in-house authentication platform you already have: Windows Active Directory. It’s a one-server solution that removes the need to pay for or use an external IdP.

Admins can use built-in tools and wizards to configure UserLock SSO for Google Workspace, turning a potentially onerous setup into a manageable project. Importantly, you don’t have to pay to add essential security layers such as granular MFA and user access control to the Windows platform, which are included as part of UserLock SSO out of the box.       

With UserLock SSO in place, users no longer sign in directly through Google Workspace. Instead, access to Google Workspace becomes just one of many services granted through the single AD credential, authenticated at the Windows logon.  

Here’s how to set it up:

1. Workspace to use SSO via a third-party IdP via the Google Workspace console (Admin → Authentication → “SSO with third party IdP”).

2. SSO can be applied either to a single Google Workspace OU or Group, or to an entire organization. The instructions on how to do this in either case are outlined in detail in the UserLock Google Workspace configuration guide.

3. Activate Google Workspace in UserLock in the SSO configuration, adding Google Workspace as a provider and restarting the service if necessary.            

That’s it. Google Workspace is now part of your UserLock SSO setup.