This article is the first part of a multi-part series that discusses how to extend your identity management solution to Google Cloud Platform (GCP) to enable your corporate users to authenticate and consume services in a hybrid computing environment.
The series consists of these parts:
- Authenticating corporate users in a hybrid environment (this article)
- Patterns for authenticating corporate users in a hybrid environment
Managing user accounts and controlling employee access to applications and computing resources is a key responsibility of enterprise IT departments. To ensure consistency and administrative efficiency, most enterprises consider identity management a central function and use a unified system to manage identities. Most commonly, enterprises rely on Microsoft Active Directory Domain Services (AD DS) for this purpose.
When you extend an IT landscape to GCP as part of a hybrid strategy, you want to maintain a single point where identities are managed. A unified identity management system minimizes administrative effort in managing accounts and access control. This system also helps ensure that users and applications can authenticate securely across a hybrid environment.
This article looks at the ways to integrate GCP with your identity management system. The article helps you choose the approach that best fits your requirements.
Assessing requirements for hybrid identity management
The best way to extend your identity management system to GCP depends on multiple factors:
- The pools of identities in your organization
- The identity providers used to provide authentication services for your corporate identities
- The resources and applications you want corporate users to be able to access on GCP
- Your business continuity requirements
The following sections look at each of these factors.
The first factor to look at when integrating GCP and your identity management system is how you manage and distinguish between identity types. Most organizations use the following types of identities:
- Corporate identities are the identities you manage for employees of your organization. These identities are used for signing in to workstations, accessing email, or using corporate applications.
- External identities are the identities you manage for non-employees such as contractors or partners which need to be given access to corporate resources.
- Guest identities are identities managed by a different party such as a customer or partner who need access to corporate resources.
- Customer identities are the identities you manage for users in order to interact with your website or customer-facing applications.
- Application identities are the identities you manage to enable applications to interact with other applications or the underlying platform.
Often, corporate identities form a single pool of identities, where each employee has a single identity and all identities managed in the same way, using the same systems. However, this doesn't have to be the case—as a result of a merger or acquisition, for example, you might have multiple pools of corporate identities, each managed differently using different systems. Technically, this means that you might have to integrate multiple LDAP sources, Active Directory forests, or Azure AD tenants with GCP.
Integrating multiple pools adds to the complexity of integrating with GCP. Therefore, you should evaluate:
- Do all identity pools need access to GCP, or only a select subset?
- Should all identity pools have access to the same organization in GCP, or each to a different one?
- Are there options to reduce the number of pools, for example, by creating cross-forest trusts between Active Directory forests or by using Azure B2B to reduce the number of Azure tenants to integrate with?
External identities are often treated similarly to corporate identities, with these exceptions:
- Their account might be valid for only a limited time.
- They might be granted fewer rights by default.
- They might be managed by a separate LDAP directory, Active Directory forest, or Azure AD tenant.
Unlike external identities, guest identities are not managed by you but by a different party. In SaaS applications such as G Suite, guest identities can remove the need for maintaining external identities for customers or partners. You rarely encounter guest identities in on-premises environments.
This article focuses on corporate identities and external identities.
If you have used services such as Google Ads, some of your employees might already have a Google Account that isn't connected to their corporate identity, meaning they have two identities. If so, consider consolidating these identities.
The second factor to look at is your identity providers. An identity provider (IdP) is a system that provides authentication services for your workloads and ultimately decides whether to authenticate a user.
In addition to providing authentication services, IdPs often manage the identities themselves. This doesn't have to be the case, though, because identities might also be provisioned from a separate human resources system.
Common identity providers include:
- Active Directory (AD DS)
- Azure Active Directory (Azure AD)
- IDaaS providers such as Okta or Ping Identity
- Other LDAP directories, including Active Directory Lightweight Directory Services (AD LDS)
Instead of using only one system, you might be using several systems—to manage different user pools, to handle external accounts, or to provide different authentication services for the same user pools. Examples where multiple IdPs are used to manage the same pools include:
- Active Directory federated with Azure AD
- Active Directory federated with an IDaaS provider such as Okta or Ping Identity
- Active Directory with AD LDS replicas
To use your IdP on GCP, you can follow two basic approaches:
- Federate your identity provider with Cloud Identity: By federating with Cloud Identity, you enable Google to become an additional IdP that your corporate users can use and that applications deployed on GCP can rely on. Instead of maintaining Google identities for each of your users, you can depend on the federation relationship to maintain identities automatically. This relationship also helps ensure that your IdP remains the source of truth.
- Extend your identity provider to GCP: You can allow applications deployed on GCP to reuse your IdP—by connecting to it directly or by maintaining a replica of your IdP on GCP.
Depending on the other identity management factors, you might need to combine both approaches to support your hybrid usage scenarios.
The third factor to look at is which GCP resources you plan to
grant your corporate users access to. This factor includes GCP
itself—you must allow responsible teams to manage GCP by using the
command-line tool, or APIs.
Additional resources might include:
- Applications deployed on App Engine, Compute Engine, or Google Kubernetes Engine (GKE)
- Applications protected with Cloud Identity Aware Proxy (IAP)
- Linux VMs, accessed using SSH
- Windows VMs, accessed using RDP
- Other Google tools and services such as G Suite, Data Studio, or Google Ads
These resources differ in whether they must, could, or cannot use Google as identity provider. The following sections look at these three cases.
Resources that must use Google as IdP
Resources that must use Google as IdP include the GCP Console, the
gcloud tool, applications protected with Cloud IAP, and other Google
tools and services. To grant your corporate users access to these resources, you
must provision a Google identity for each user.
Maintaining separate Google identities runs counter to the idea of unified identity management. So granting users access to any of these resources implies that you must federate your IdP with GCP.
After you federate your IdP with GCP, consider using Google as IdP for more resources—including applications that might use other means to authenticate users.
Resources that could use Google as IdP
Resources that could use Google as IdP, but currently don't, include:
- New applications, aimed at corporate users, that you plan to deploy on GCP.
- Existing applications, aimed at corporate users, that you plan to lift and shift or transform and move to GCP.
Whether these applications can use Google as IdP depends on the protocols you use for authentication and authorization.
Web single sign-on protocols
Google supports several industry standard protocols for handling authentication, authorization, and single sign-on. Supported protocols include:
- OAuth 2.0, which applies to mobile clients, fat clients, and other non-browser applications.
- OpenID Connect 1.0 (OIDC), which applies to browser-based applications.
- SAML 2.0, which applies to integrating third-party applications
For applications that you plan to develop, OAuth 2.0 or OIDC should be your preferred choice. These protocols are widely adopted, and you can take advantage of many well-tested libraries and tools. Also, relying on these protocols implies that you can optionally use Google as IdP while you retain the flexibility of switching identity providers as needed.
If you have applications that use SAML, OAuth 2.0, or OIDC, switching them to using Google as identity provider should be possible with little or no code changes.
One of the most versatile and relied-on protocols for authentication and authorization is the Lightweight Directory Access Protocol (LDAP). There are multiple ways an application can use LDAP for authentication and authorization. The two most common scenarios are:
Using LDAP for authentication and querying user information: In this scenario, an application doesn't use single sign-on. Instead, it shows the user a sign-on form asking for username and password and then uses the provided credentials to attempt an LDAP
bindoperation. If the attempt succeeds, the credentials are considered valid. And further information about the user such as name and group membership might be queried from the directory and used to authorize access.
Using SAML for authentication and LDAP for querying user information: In this scenario, the application authenticates the user by using a single sign-on protocol—applications often use SAML for this purpose. After the user has been authenticated, the application uses the LDAP server to query additional information about the user such as name and group memberships.
The critical difference between the two scenarios is that the first scenario requires both the application and the LDAP server to have access to the user's password in order to verify credentials. In the second scenario, the application and the server don't require access to the user's password; the application can perform its LDAP queries by using a dedicated service user.
With Secure LDAP, you can access user and group information in Cloud Identity by using the LDAP protocol. If Google is your primary IdP, Secure LDAP enables you to support both scenarios. However, if you integrate Cloud Identity with an external IdP, Cloud Identity doesn't maintain a copy of user passwords. As a result, only the second scenario can be enabled with Secure LDAP.
Kerberos and NTLM
If you plan to migrate Windows-based workloads to GCP, some of these applications might rely on Integrated Windows Authentication (IWA) instead of using standard protocols. IWA is a common choice for ASP.NET-based applications running on Microsoft IIS. IWA is popular because it allows a seamless single sign-on experience for users who have logged in to their Windows workstation using domain credentials.
One consequence of relying on NTLM and Kerberos is that an application using IWA cannot use Google as IdP. However, you might still be able to refactor the application to use OIDC. OIDC doesn't require the user's workstation or the server to be domain-joined. So refactoring might simplify deployment and help you pursue alternative deployment options.
- If you federate GCP with Active Directory and AD FS, any authentication methods configured in AD FS apply. If you configure AD FS to allow IWA, users who have logged in to their Windows workstation using domain credentials can be authenticated seamlessly to any application that uses Google as IdP.
- If you federate GCP with Azure AD, you can enable Azure AD Seamless SSO to the same effect.
The following diagram shows a simplified example of how you can use Cloud Identity, AD FS, and IWA to implement seamless single-sign on for a web application:
- The browser requests a protected page using a web browser.
- The web application initiates a login using OIDC (OIDC authentication flow). This flow redirects the browser to the Google Identity Server.
- The Google Identity Server returns the Google sign-on page to the user, prompting for the email address.
- The user enters their corporate email address.
- Based on the email address, the Google Identity Server identifies the Cloud Identity account and recognizes that it is configured to use SSO. The identity server then initiates a SAML login with AD FS.
- AD FS, configured to use IWA, requests the browser to present a Kerberos ticket, which triggers the browser to request the underlying Windows operating system to obtain a suitable ticket.
- Unless a suitable ticket has been cached, Windows contacts the Active Directory key distribution center (KDC) and requests a suitable service ticket to be issued based on the ticket granting ticket (TGT) that was obtained when the user signed in to Windows.
- The browser presents the newly obtained ticket to AD FS.
- AD FS validates the ticket by checking its cryptographic signature, extracts the user identity from the ticket, and issues a SAML token to Google Identity Server.
- Using the authentication information from the SAML token, Google Identity Server completes the OIDC login and issues OpenID Connect tokens to the web application.
- When the user is authenticated, the protected page can be returned to the user.
SSH public-key authentication
When you plan to run Linux virtual machines (VMs) on GCP, you likely need SSH access to these machines. The most common authentication method for SSH is public-key authentication.
Unlike the single sign-on protocols previously discussed, SSH public-key authentication doesn't rely on a centralized IdP to make authentication decisions. Instead, authentication decisions are decentralized—each machine handles authentication based on a local set of authorized public keys.
You can bridge the gap between decentralized SSH public-key authentication and centralized identity management. You do this by tying three provisioning activities to the lifecycle of user accounts managed by the central IdP:
- Creating a key pair when a user is created or is attempting to use SSH for the first time.
- Provisioning the user's public key to machines a user is entitled to access.
- Deprovisioning the user's public key when the account is revoked access, disabled, or deleted.
Instead of using custom tooling to bridge the gap, you can install the Linux guest environment on Linux VMs. This environment includes a set of scripts and daemons that automate the management of user accounts and SSH keys based on Cloud IAM. Using this environment makes Cloud Identity the IdP for your Linux instances.
Resources that cannot use Google as IdP
Some resources cannot directly use Google as IdP. But you can still accommodate these resources on GCP by combining two approaches:
- Federate your external IdP with GCP
to allow corporate users to use the GCP Console, the
gcloudtool, and other resources that must or could use Google as IdP.
- Extend your IdP to GCP to enable resources that cannot use Google as IdP to be run on GCP.
If a resource relies on protocols that the Google IdP doesn't support, that resource cannot use Google as IdP. Such protocols include:
LDAP for authentication: Although you can use Secure LDAP to facilitate querying user information from Cloud Identity through LDAP, Cloud Identity does not support using LDAP for authentication when federated with an external IdP.
WS-Trust, WS-Federation: Especially if you use AD FS, you might still rely on WS-Trust or WS-Federation to handle token-based authentication. Unless you can change affected applications to use SAML or OpenID Connect, it's best to expose your on-premises AD FS to GCP and have the applications use AD FS directly.
OpenID Connect with AD FS-specific claims: AD FS and Google support OpenID Connect. If you have been using AD FS as an OpenID Connect provider, you might rely on certain AD FS-specific claims that Google doesn't support. If so, consider exposing your on-premises AD FS to GCP and have affected applications directly use AD FS.
Kerberos, NTLM: If some of your applications use Kerberos or NTLM for authentication, you might be able to modify them to use OpenID Connect or SAML instead. If this isn't possible, you can deploy these applications on domain-joined Windows servers and either expose or replicate your on-premises Active Directory to GCP.
Windows virtual machines: If you run Windows workloads on GCP, you must be able to log in to these VMs through Remote Desktop Protocol (RDP), through a Remote Desktop Gateway, or by other means. If a user has write access to the GCP project where the VM was created, GCP lets the user create a user and password, which creates an account in the VM's local Security Account Manager (SAM) database. Crucially, the resulting Windows SAM account isn't connected to the user's Google Account and isn't subject to the same account lifecycle. If you suspend or delete the user's Google Account, the Windows SAM account is unaffected and might continue to provide access to the VM.
If you have a moderate number of Windows VMs and users that must be able to log in to these machines, then letting users generate Windows user accounts and passwords might be a viable approach. But when managing larger fleets of Windows servers, it can be better to extend an on-premises Active Directory to GCP and domain-join the respective servers. Domain-joining servers is also a requirement if you rely on Network Level Authentication.
The final factor to look at is availability. The ability to authenticate users is likely critical for many of your workloads, and an IdP outage can have far-reaching consequences. The right approach to ensuring suitable availability depends on how you intend to use GCP and how it fits into your hybrid strategy.
To capitalize on the unique capabilities that each computing environment offers, you might use a hybrid multi-cloud approach to distribute workloads across those environments. These environments might have dependencies on one another that are critical to availability of your workloads. Dependencies might include VPN tunnels or interconnects, applications communicating with one another, or systems accessing data across computing environments.
When federating or extending your external IdP to GCP, ensure that availability of your external IdP and other systems required for authentication meets or exceeds the availability of other critical dependencies. This requirement means that you might need to both redundantly deploy the external IdP and its dependencies and ensure redundant network connectivity.
If you use GCP for ensuring business continuity, your workloads on GCP are going to mirror some of the workloads you have in your computing environment. The purpose of such a setup is to enable one computing environment to take over the role of the other environment if a failure occurs. So you need to look at every dependency between these environments.
By having GCP rely on an external IdP running on-premises, you create a dependency. That dependency could undermine the intent of having GCP be an independent copy of your computing environment.
Try to replicate your IdP to GCP so that all workloads on GCP are unaffected by an outage of your on-premises computing environment or of connectivity between GCP and your on-premises network.
- Read about common patterns for authenticating corporate users in a hybrid environment
- Find out more about best practices for setting up GCP organizations for your enterprise.
- Try out other Google Cloud Platform features for yourself. Have a look at our tutorials.