By Rajat Bhargava Posted March 20, 2017
IT organizations always hope that the tools that they pick can play multiple roles. This has been especially true for many IT admins when it comes to G Suite (formerly known as Google Apps). Google Apps burst onto the scene in the mid-to-late 2000s and has steadily increased its market share. Often, a key role that IT admins would like to see G Suite play is the role of the authoritative directory service. Even if it can’t play that role (G Suite Directory is not a replacement to Active Directory®), the thought is to have G Suite Directory act as a federation tool.
Unfortunately, it doesn’t really do that either – except in limited circumstances. To understand Google’s approach to identity management, we need to step back and analyze Google’s overall strategy when it comes to G Suite, Google Cloud, and Cloud IAM.
Google’s Identity Management Services Approach
It’s not hard to surmise that Google is all about the cloud. Google is reticent to build any solutions that sit on-prem or even really interact too heavily with on-prem resources. Google’s philosophy has been to build solutions that are eminently scalable. When you start to involve on-prem IT resources and people, you break the model of scalability.
G Suite Takes On Exchange and Office
What was the thought process behind Google Apps when it first emerged? GApps could be the outsourced email server for an organization – even a large organization – without having to customize the solution, provide intensive support, and require professional services. They could scale the business because there were standard protocols available to them and email servers spoke to each other with those standards – and it worked.
GApps took a lot of market share away from Microsoft Exchange and Office.
G Suite’s Cloud-Only Approach is No Match for Active Directory
Since GApps was virtually 100% in the cloud, end users didn’t have to worry about installing components and configuring complex software. They could simply use their browser of choice and do their work. Microsoft didn’t react to this winning model until they started to lose significant market share and customers.
However, Microsoft had an ace in the hole that they have been using to their advantage to beat back G Suite. That advantage has been Active Directory.
Positioning G Suite Directory as a Federation Tool
Controlling a user’s identity and what they can easily access is the key to winning in the cloud. Google knows this. It is why they are trying to position their G Suite Directory as a federation tool. Leveraging standard protocol, for example, SAML and OAuth, G Suite is trying to use their identities to log into other web applications.
This ends up working well for the select few applications that support this process. Yet it doesn’t work well for the rest of an IT organization’s items. G Suite Directory doesn’t connect to on-prem systems (Windows, Mac, and Linux), applications (non-SAML or OAuth based), and network infrastructure. Ultimately, it’s really just a user management system for GApps and a few web applications.
JumpCloud® Extends G Suite Credentials
IT admins are looking for something a bit different. They want to extend G Suite identities to all of their IT resources. They want to use G Suite credentials to access machines, servers, WiFi, on-prem and cloud applications, and much more. In short, they want a cloud-hosted directory service that complements G Suite. While G Suite Directory isn’t that solution, a third-party platform that seamlessly integrates with G Suite is. It’s called Directory-as-a-Service®.
Learn more about why you can’t use G Suite directory as a federation tool, but with the help of Directory-as-a-Service, your G Suite identities will extend to virtually all of your IT resources – systems, applications, and networks. Give our IDaaS platform a try for yourself. Your first 10 users are free forever.