Driving Your SSO Solution Off Of G Suite Identities

By Rajat Bhargava Posted August 31, 2016

For many organizations, Google Apps logins serve as the central set of credentials to access key IT resources. Every user in the organization has a G Suite identity, and that becomes a central point of control for IT.

When a new employee joins, he or she is given access, and when the employee leaves, access is terminated. G Suite becomes a record of the employees and contractors within the organization.

Ideally, IT admins would be able to drive access to other applications from their users’ G Suite identities.

True Story: G Suite Was Not Built As A True Directory Service

googleapps

Unfortunately, G Suite was not built as a true directory service for a broader set of applications.

Google’s interest in managing user identities was primarily for Google Apps services. Google did provide application developers with the ability to validate credentials via the OAuth 2.0 protocol. While a number of web applications leverage this approach to authenticate access via Google Apps credentials, support is not widespread. Instead, many web-based applications have chosen to support SAML as the standard authentication and authorization protocol. Google, too, provides some basic SAML support via Google Apps (about 15 applications, but slowly growing).

This presents a challenge for IT admins that want to drive access to all of their web-based applications via G Suite user credentials.

Making The Connection Via Single Sign-On

webSSO

This problem created an opportunity for a category of solutions known as Single Sign-on (SSO) providers.

Their goal was to enable an organization’s employees to log in to all of their essential web or cloud applications via one set of credentials. The SSO providers would base the credentials off of a directory service which would be synced with Google Apps. As a result, the credentials used to access G Suite would be the same ones used to authenticate with a wide variety of web applications. The SSO providers were the translation layer between the Google Apps credentials and the protocols leveraged by the web applications.

The common standard in the web application space is SAML, but some websites and applications don’t support either SAML or OAuth. What accommodations were made in those cases? SSO providers created manual integrations, whereby user credentials would still properly work even though protocol integration with SAML or OAuth was lacking.

Benefits of Driving Your SSO Solution Off Of G Suite Identities

google-apps-1


There are significant benefits associated with SSO providers being driven with G Suite credentials. For starters, the leading SSO providers support many thousands of different website and application logins. In addition, nearly every application an organization may use is supported for single sign-on access. If a particular site or application is not supported, most of the SSO providers will immediately add access. IT admins can then request that their users create one set of credentials. Subsequently, those credentials can be used for all of an organization’s “external” applications. Finally, user accounts can be centrally provisioned and deprovisioned to many of the SSO supported applications, thereby reducing work and increasing security.

Identity Management Under One Roof

icon-user-management-83d64dab58eb075b359f6127d7e84ae5 (1)

IT organizations have two distinct paths to leverage their G Suite identities. The first path is to directly import their Google Apps users into the SSO solution. Subsequent access to web applications is driven by the SSO solution. The second path is to insert a cloud-based directory service (Directory-as-a-Service®, or DaaS) which centrally controls identities and federates them to Google Apps and the SSO solution. The same identity is used in both places. The additional benefit of DaaS is being able to provide identity management to on-premises devices and applications as well. Both paths leverage the same Google Apps identities to drive access to a wide variety of web applications.

Learn More About JumpCloud® And Bitium


In addition to potentially leveraging a
Directory-as-a-Service solution to underpin Google Apps identities, SSO solutions such as Bitium can be a valuable addition to any G Suite driven organization. We’d love to hear from you, so drop us a note to learn more about driving your SSO solution off of G Suite identities. In the meantime, please take JumpCloud for a test drive – the first ten users are free forever.

Rajat Bhargava

Rajat Bhargava is co-founder and CEO of JumpCloud, the first Directory-as-a-Service (DaaS). JumpCloud securely connects and manages employees, their devices and IT applications. An MIT graduate with two decades of experience in industries including cloud, security, networking and IT, Rajat is an eight-time entrepreneur with five exits including two IPOs, three trade sales and three companies still private.

Recent Posts