Patterns for authenticating corporate users in a hybrid environment

This article is the second 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 the following articles:

Introduction

When you extend your IT landscape to GCP as part of a hybrid strategy, we recommend that you take a consistent approach to managing identities across environments. As you design and tailor your architecture to meet these constraints and requirements, you can rely on some common patterns. These patterns fall into two categories:

  • Patterns for federating an external identity provider (IdP) with GCP. The aim of these patterns is to enable Google to become an IdP for your corporate users so that Google identities are maintained automatically and your IdP remains the source of truth.
  • Patterns for extending an IdP to GCP. In these patterns, you let applications deployed on GCP reuse your IdP—either by connecting to it directly or by maintaining a replica of your IdP on GCP.

Patterns for federating an external IdP with GCP

To enable access to the GCP Console, the gcloud command-line tool, or any other resource that uses Google as IdP, a corporate user must have a Google identity. Maintaining Google identities for each employee would be cumbersome when all employees already have an account in an IdP. By federating user identities between your IdP and GCP, you can automate the maintenance of Google accounts and tie their lifecycle to accounts that exist. Federation helps ensure the following:

  • Your IdP remains the single source of truth for identity management.
  • For all user accounts that your IdP manages, or a selected subset of those accounts, a Google Account is created automatically.
  • If an account is disabled or deleted in your IdP, the corresponding Google Account is suspended or deleted.
  • To prevent passwords or other credentials from being copied, the act of authenticating a user is delegated to your IdP.

Federating Active Directory with Cloud Identity by using GCDS and AD FS

If you use Active Directory as IdP, you can federate Active Directory with Cloud Identity by using Google Cloud Directory Sync (GCDS) and Active Directory Federation Services (AD FS):

  • Cloud Directory Sync is a free Google-provided tool that implements the synchronization process. Cloud Directory Sync communicates with Google Identity Platform over Secure Sockets Layer (SSL) and usually runs in the existing computing environment.
  • AD FS is provided by Microsoft as part of Windows Server. With AD FS, you can use Active Directory for federated authentication. AD FS usually runs in the existing computing environment.

For more detailed information about this approach, see Federating GCP with Active Directory.

Pattern: Federating Active Directory with Cloud Identity by using GCDS and AD FS

For a variation of this pattern, you can also use Active Directory Lightweight Directory Services (AD LDS) or a different LDAP directory with either AD FS or another SAML-compliant IdP.

User experience

  1. When you request the protected resource, you are redirected to the Google sign-on screen, which prompts you for your email address.
  2. If the email address is known to be associated with an account that has been synchronized from Active Directory, you are redirected to AD FS.
  3. Depending on the configuration of AD FS, you might see a sign-on screen prompting for your Active Directory username and password. Or AD FS might attempt to sign you in automatically based on your Windows login (IWA).
  4. When AD FS has authenticated you, you are redirected back to the protected resource.

Advantages

  • The approach enables a single sign-on experience across on-premises applications and resources on GCP.
  • If you configured AD FS to require multi-factor authentication, that configuration automatically applies to GCP.
  • You don't need to synchronize passwords or other credentials to Google.
  • Because the Cloud Identity API is publicly accessible, there's no need to set up hybrid connectivity between your on-premises network and GCP.

Best practices

  • Active Directory and Cloud Identity use a different logical structure. Make sure you understand the differences and assess which way of mapping domains, identities, and groups suits your situation best. Refer to our guide on federating GCP with Active Directory for more detailed information.
  • Synchronize groups in addition to users. With this approach, you can set up Cloud IAM so that you can use group memberships in Active Directory to control who has access to resources in GCP.
  • Deploy and expose AD FS so that corporate users can access it, but don't expose it more than necessary. Although corporate users must be able to access AD FS, there's no requirement for AD FS to be reachable from Google or from any application deployed on GCP.
  • Consider enabling Integrated Windows Authentication (IWA) in AD FS to allow users to sign in automatically based on their Windows login.
  • If AD FS becomes unavailable, users might not be able to use the GCP Console or any other resource that uses Google as IdP. So ensure that AD FS and the domain controllers AD FS relies on are deployed and sized to meet your availability objectives.
  • If you use GCP to help ensure business continuity, relying on an on-premises AD FS might undermine the intent of using GCP as an independent copy of your deployment. In this case, consider deploying replicas of all relevant systems on GCP:
    • Replicate your Active Directory to GCP and deploy GCDS to run on GCP.
    • Run dedicated AD FS servers on GCP. These servers use the Active Directory domain controllers running on GCP.
    • Configure Cloud Identity to use the AD FS servers deployed on GCP for single sign-on.

Federating Azure AD with Cloud Identity

If you are a Microsoft Office 365 or Azure customer, you might have connected your on-premises Active Directory to Azure AD. If all user accounts that potentially need access to GCP are already being synchronized to Azure AD, you can reuse this integration by federating Cloud Identity with Azure AD, as the following diagram shows.

Federating Cloud Identity with Azure AD

For more detailed information about this approach, see Federating GCP with Azure Active Directory.

User experience

  1. When you request the protected resource, you are redirected to the Google sign-on screen, which prompts you for your email address.
  2. If the email address is associated with an account that has been synchronized from Azure AD, you are redirected to Azure AD.
  3. Depending on how your on-premises Active Directory is connected to Azure AD, Azure AD might prompt you for a username and password. Or it might redirect you to an on-premises AD FS.
  4. After successfully authenticating with Azure AD, you are redirected back to the protected resource.

Advantages

  • You don't need to install any additional software on-premises.
  • The approach enables a single sign-on experience across Office 365, Azure, and resources on GCP.
  • If you configured Azure AD to require multi-factor (MFA) authentication, MFA automatically applies to GCP.
  • If your on-premises Active Directory uses multiple domains or forests and you have set up a custom Azure AD Connect configuration to map this structure to an Azure AD tenant, you can take advantage of this integration work.
  • You don't need to synchronize passwords or other credentials to Google.
  • Because the Cloud Identity API is publicly accessible, there's no need to set up hybrid connectivity between your on-premises network and GCP or between Azure and GCP.
  • You can surface the GCP Console as a tile in the Office 365 portal.

Best practices

  • Because Azure AD and Cloud Identity use a different logical structure, make sure you understand the differences. Assess which way of mapping domains, identities, and groups suits your situation best. For more detailed information, see federating GCP with Azure AD.
  • Synchronize groups in addition to users. With this approach, you can set up Cloud IAM so that you can use group memberships in Azure AD to control who has access to resources in GCP.
  • If you use GCP to help ensure business continuity, relying on Azure AD for authentication might undermine the intent of using GCP as an independent copy of your deployment.

Patterns for extending an external IdP to GCP

Some of the applications you plan to deploy on GCP might require the use of authentication protocols not offered by Cloud Identity. To support these workloads, you must allow these applications to use your IdP from within GCP.

The following sections describe common patterns for allowing your IdP to be used by workloads deployed on GCP.

Exposing an on-premises AD FS to GCP

If an application requires the use of WS-Trust or WS-Federation, or relies on AD FS-specific features or claims when using OpenID Connect, you can allow the application to directly use AD FS for authentication.

Application directly using AD FS for authentication

By using AD FS, an application can authenticate a user. However, because authentication is not based on a Google identity, the application won't be able to perform any API calls on the user's behalf. Instead, any calls to the GCP API must be authenticated using a service account.

User experience

  1. When you request the protected resource, you are redirected to the ADFS sign-on screen, which prompts you for your email address. If AD FS isn't publicly exposed over the internet, accessing AD FS might require you to be connected to your company network or corporate VPN.
  2. Depending on the configuration of AD FS, you might see a sign-on screen prompting for your Active Directory username and password. Or AD FS might attempt to sign you in automatically based on your Windows login.
  3. When AD FS has authenticated you, you are redirected back to the protected resource.

Advantages

  • You can use authentication protocols that aren't supported by Cloud Identity, including WS-Trust and WS-Federation.
  • If the application has been developed and tested against AD FS, you can avoid risks that might arise from switching the application to use Cloud Identity.
  • There's no need to set up hybrid connectivity between your on-premises network and GCP.

Best practices

  • Deploy and expose AD FS so that corporate users can access it, but don't expose it more than necessary. Although corporate users must be able to access AD FS, there's no requirement for AD FS to be reachable from Google or from any application deployed on GCP.
  • If AD FS becomes unavailable, users might not be able to use the application anymore. Ensure that AD FS and the domain controllers it relies on are deployed and sized to meet your availability objectives.
  • Consider refactoring applications that rely on WS-Trust and WS-Federation to use SAML or OpenID Connect instead.
  • If the application relies on group information being exposed as claims in IdTokens issued by AD FS, consider retrieving group information from a different source such as the Directory API. Querying the Directory API is a privileged operation that requires using a service account that is enabled for G Suite domain-wide delegation.

Exposing an on-premises LDAP directory to GCP

Some of your applications might require users to provide their username and password and use these credentials to attempt an LDAP bind operation. If you cannot modify these applications to use other means such as SAML to perform authentication, you can grant them access to an on-premises LDAP directory.

Granting users access to an on-premises LDAP directory

Advantages

  • You don't need to change your application.

Best practices

  • Use Cloud VPN or Cloud Interconnect to establish hybrid connectivity between GCP and your on-premises network so that you don't need to expose the LDAP directory over the internet.
  • Verify that the latency introduced by querying an on-premises LDAP directory doesn't negatively impact user experience.
  • Ensure that the communication between the application and the LDAP directory is encrypted. You can achieve this encryption by using Cloud VPN or by using Cloud Interconnect with LDAP/S.
  • If the LDAP directory or the private connectivity between GCP and your on-premises network becomes unavailable, users might not be able to use an LDAP-based application anymore. Therefore, ensure that the respective servers are deployed and sized to meet your availability objectives, and consider using redundant VPN tunnels or interconnects.
  • If you use GCP to ensure business continuity, relying on an on-premises LDAP directory might undermine the intent of using GCP as an independent copy of your existing deployment. In this case, consider replicating the LDAP directory to GCP instead.
  • If you use Active Directory, consider running a replica on GCP instead, particularly if you plan to domain-join Windows machines running on GCP to Active Directory.

Replicating an on-premises LDAP directory to GCP

Replicating an on-premises LDAP directory to GCP is similar to the pattern of Exposing an on-premises LDAP directory to GCP. For applications that use LDAP to verify usernames and passwords, the intent of this approach is to be able to run those applications on GCP. Instead of allowing such applications to query your on-premises LDAP directory, you can maintain a replica of the on-premises directory on GCP.

Maintaining a replica of the on-premises directory on GCP

Advantages

  • You don't need to change your application.
  • The availability of LDAP-based applications running on GCP doesn't depend on the availability of the on-premises directory or connectivity to the on-premises network. This pattern is well-suited for business continuity hybrid scenarios.

Best practices

  • Use Cloud VPN or Cloud Interconnect to establish hybrid connectivity between GCP and your on-premises network so that you don't need to expose the LDAP directory over the internet.
  • Ensure that the replication between the on-premises LDAP directory is conducted over a secure channel.
  • Deploy multiple LDAP directory replicas across multiple zones or regions to meet your availability objectives. You can use an internal load balancer to distribute LDAP connections among multiple replicas deployed in the same region.
  • Use a separate GCP project with a Shared VPC to deploy LDAP replicas and grant access to this project on a least-privilege basis.

Extending an on-premises Active Directory to GCP

Some of the workloads that you plan to deploy on GCP might depend on Active Directory Domain Services, for example:

  • Windows machines that need to be domain-joined
  • Applications that use Kerberos or NTLM for authentication
  • Applications that use Active Directory as an LDAP directory to verify usernames and passwords

To support such workloads, you can extend your on-premises Active Directory forest to GCP—for example, by deploying a resource forest to GCP and connecting it to your on-premises Active Directory forest, as in the following diagram.

connecting a resource forest to your on-premises Active Directory forest

For more detail about this approach and other ways to deploy Active Directory in a hybrid environment, see Patterns for using Active Directory in a hybrid environment.

Extending your on-premises Active Directory forest to GCP by deploying additional domain controllers on GCP

Advantages

  • Your workloads can take full advantage of Active Directory, including the ability to join Windows machines to the Active Directory domain.
  • The availability of Active Directory-based applications running on GCP doesn't depend on the availability of on-premises resources or connectivity to the on-premises network. The pattern is well-suited for business continuity hybrid scenarios.

Best practices

  • Use Cloud VPN or Cloud Interconnect to establish hybrid connectivity between GCP and your on-premises network.
  • To minimize communication between GCP and your on-premises network, create a separate Active Directory site for GCP deployments. You can use either a single site per Shared VPC or, to minimize inter-region communication, one site per Shared VPC and region.
  • Create a separate Active Directory domain dedicated to resources deployed on GCP and add the domain to the existing forest. Using a separate domain helps reduce replication overhead and partition sizes.
  • To increase availability, deploy at least two domain controllers, spread over multiple zones. If you use multiple regions, consider deploying domain controllers in each region.
  • Use a separate GCP project with a Shared VPC to deploy domain controllers and grant access to this project on a least-privilege basis. By generating a password or accessing the serial console of domain controller instances, rogue project members might otherwise be able to compromise the domain.
  • Consider deploying an AD FS server farm and GCDS on GCP. This approach lets you federate Active Directory with Cloud Identity without depending on the availability of resources or connectivity to the on-premises network.

What's next

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…