Google has been taking a different approach recently with Google Identity Management. Their previous approach had been to decouple the Google identity from G Suite into its own object, but their new approach is aiming to make Google identities more universal across virtually all Google services including G Suite, Google Cloud, and other services. For Google’s cloud identity management ambitions, this is an appropriate model.
But, the model is still 100% focused on Google resources. As we have said many times before, Google’s Identity Management Service is not a replacement for Active Directory or LDAP, but rather a user management system for Google Apps and a few, select web services.
Google Identity Services and Core Directory Services
The good news is that with this approach to Google identity services, solutions that are focused on being the core directory service for an organization can more easily work with Google identities and federate them across a wide range of Google services easily.
In fact, one of the core reasons organizations are so eager to leverage Directory-as-a-Service® is to centralize the identity and ensure that when an employee is onboarded, all resources connect to that one centralized identity. It’s the approach Microsoft’s Active Directory® took in the on-prem legacy world, but adapted for the new cloud era (with all of our cloud resources, apps, and infrastructure) by a cloud directory service.
Stepping back, you can visualize what one identity across your IT resources can mean. When an organization adopts Directory-as-a-Service, the JumpCloud identity is the authoritative identity. They simply add a user to the cloud directory, add that user to a specific Group (or Groups), and the various protocols are supported to provide account provisioning and access to the various IT resources.
Application of Groups
Take, for example, a new DevOps employee. Day 1, the IT admin builds the identity in the cloud directory and subsequently adds them to the “DevOps” group. This group is connected to:
- The user’s personal new Macbook.
- The user’s Linux and Windows cloud servers they need access to (along with their SSH keys). Perhaps these servers are hosted at AWS, Google Cloud, or within their own data center.
- The user’s access to web and on-prem apps via single sign-on (LDAP and SAML integration).
- The user’s secure VPNs and wireless networks.
- The user’s G Suite and/or Office 365 account.
- The user’s on-prem resources (file servers, ticketing systems, Jenkins machines, etc).
- The user’s Github repo.
The goal is connecting a user to their IT resources from one central identity. Microsoft Active Directory has done this on-prem for Microsoft resources. Directory-as-a-Service is doing this for all major resources across all major platforms, granting IT a deep level of control in an environment that can be independent of platform, protocol, provider, or location.
So, in the case of Google services, a user’s identity would be provisioned by JumpCloud’s Directory-as-a-Service to the Google cloud IAM or to G Suite directory. The account would then be able to access other Google services. This is similar to how an identity is provisioned to Microsoft Office 365. By decoupling Google identities from G Suite, third party directory services can be powerful enough to centrally manage access to IT resources.
Decoupling Google Identities
If you would like to learn more about the impact of decoupling Google identities on Google Apps, Google Cloud, and more, drop us a note. We’d be happy to walk you through how you can still centrally manage user access to a wide variety of IT resources. Additionally, feel free to try our IDaaS platform to see how it can integrate with Google Identity Management approaches. Your first 10 users are free forever.