G Suite and SSO

G Suite and Single Sign-On (SSO)

Google has meaningfully simplified life for IT administrators with G Suite. First brought to market in August 2005, G Suite has quickly exposed the power of SaaS: powerful tools for employee communication, file storage and collaboration tools, accessible anywhere on the Internet, through any browser. G Suite also provided a foundational example of single-sign on (SSO), as the array of products could all be seamlessly accessed with a single Google account login.

What is Single-Sign-On?

Single sign-on (commonly called “SSO”) is a user authentication process which enables an employee to leverage a single user ID (e.g. a username or an email) along with an accompanying password in order to seamlessly access multiple applications. The technology and process allowing for this authenticates employees for all the applications to which they have been given access. The principle benefit of SSO is the ability to sign in once and not be prompted to sign in again by another application.

Technologies Enabling SSO

SSO can be implemented in myriad ways. A few example protocols that facilitate SSO are highlighted below, but note that this isn’t an exhaustive list.

  • LDAP (Lightweight Directory Access Protocol) – In many large organizations, an LDAP directory is the ‘central source of truth’ of a user’s identity, storing the authentication and authorization policies of the employee. Applications will leverage the identity in LDAP in addition to the authorization policies to enable the required/allowed level of access. LDAP directories are designed and implemented in larger organizations primarily to enable high performance look-ups, which eliminate latency and wait-time. LDAP directories are often leveraged for 3rd party SSO ‘tools’ to authenticate against.
  • Kerberos – Most common in the Microsoft Windows workstation world, Kerberos is protocol enabling a workstation connected to a central directory-backed domain (e.g. LDAP or Active Directory) to provide the authentication launch point for accessing resources. Employees can visit any workstation connected to the domain, login, and gain access to all of the resources (e.g., applications, file shares, etc) they have been granted via policies set within the directory.
  • SAML (Security Assertion Markup Language) – SAML is protocol which is predicated on exchanging authentication and subsequent authorization between an identity provider (“IdP” – e.g., a directory or some other authoritative identity store) and a service provider (“SP” – e.g., a web-based application). SAML’s most notable capability in authentication and authorization of identity is utilized in web browser application sign on.

Why Implement SSO?

SSO greatly simplifies authorization and access to IT resources. Reasons to implement a unified sign on technology strategy range from improved security to more efficient employee onboarding and auditing. A more complete list of SSO benefits are:

  • Reduce password fatigue – Increase employee productivity by providing them with a uniform user name and password scheme to log into their resources.
  • Eliminate bespoke authentication layers – Application developers can benefit by leveraging a common authentication scheme rather than recreating a new one for each application.
  • Simplify Auditing – SSO will allow for traceability of employee sessions for security and reporting needs.
  • Improve IT Helpdesk Efficiency – SSO will normally reduce the workload of helpdesk staff by not handling requests for password resets on various enterprise applications

G Suite and SSO

Google’s interpretation of SSO is implemented via SAML. It will look for an Identity Provider (“IdP”) to authenticate and then return authorize the access to the applications. Setting up Google’s SSO requires the generation of a set of public and private keys and an X.509 certificate (e.g., a “cacert.pem”) that contains the public key. According to Google, “The public keys and certificates must be generated with either the RSA or DSA algorithm and registered with Google.”

Enabling SSO for Google with JumpCloud

Enabling JumpCloud as the IdP for single sign-on to Google is straightforward. JumpCloud enables employees of your organization to sign into supported SaaS applications with one-click. Our Single Sign-On (SSO) capabilities leverage the identities managed within the user store in Directory-as-a-Service® as the authentication mechanism allowing “single sign-on” access.

How does JumpCloud’s Single Sign On work?

JumpCloud leverages the standard SAML 2.0 protocol to securely perform authentication operations between our user directory (the ‘identity provider’ or IdP) and G Suite (the ‘service provider’ or SP). JumpCloud enables both IdP-initiated* and SP-initiated authentication.

  • IdP-Initiated: Employees will click the SP application button on their JumpCloud user console to gain access.
  • SP-Initiated: Employees will utilize your domains URL to gain access (e.g., http://mail.google.com/a/)

How do employees access single sign on?

Employees can visit the URL directly for the service providers supported by JumpCloud that have been configured and activated by the JumpCloud Administrator. The URL can be directly launched in a user’s browser or triggered from hyperlinks on webpages or embedded links in emails. Employees can also launch the SaaS application from JumpCloud’s system user console (the ‘employee console’). The system user console provides launch points for each SaaS application supported by JumpCloud and activated by an Administrator.

10 users free forever.