This document presents typical architectures that you can use as a referencefor managing corporate identities. Two core tenets of corporate identitymanagement are the following:

• Anauthoritative source for identities that is the sole system thatyou use to create, manage, and delete identities for your employees. Theidentities managed in the authoritative source system might be propagatedto other systems.

• A centralidentity provider (IdP) that is the sole system forauthentication and that provides a single sign-on experience for youremployees that spans applications.

When you use Google Cloud or other Google services, you must decide whichsystem to use as your identity provider and which system to use as yourauthoritative source.

Use Google as an IdP

By usingCloud Identity Premium orGoogle Workspace,you can make Google your primary IdP. Google provides alarge selection of ready-to-use integrations for popular third-party applications, and you can use standard protocols such asSAML,OAuth,andOpenID Connect to integrate your custom applications.

Google as IdP and authoritative source

You can use Cloud Identity Premium or Google Workspace as bothIdP and as authoritative source, as in the following diagram.

• You use Cloud Identity Premium or Google Workspace tomanage users and groups.
• All Google services use Cloud Identity Premium orGoogle Workspace as the IdP.
• You configure corporate applications and other SaaS services to useGoogle as the IdP.

User experience

In this configuration, to an employee, the sign-on user experience looks likethis:

1. Upon requesting a protected resource or access to a corporateapplication, the employee is redirected to the Google Sign-In screen, whichprompts you for your email address and your password.
2. If2-step verification is enabled, the employee is prompted to provide a second factor such as aUSB key or code.
3. When the employee is authenticated, they are redirected back to theprotected resource.

Advantages

Using Google as your IdP and authoritative source has the followingadvantages:

• You can take full advantage of Google'smulti-factor authentication andmobile device management features.
• You don't need an additional IdP, which might save you money.

When to use this architecture

Consider using Google as IdP and authoritative source in the followingscenarios:

• You already use Google Workspace as your collaboration andproductivity solution.
• There is no existing on-premises infrastructure or IdP that you have tointegrate with or you would like to keep it separate from all of yourresources on Google (in Google Cloud, in Google Ads, and soon).
• You don't require integration with a human resources information system(HRIS) to manage identities.

Google as IdP with an HRIS as authoritative source

If you use a human resources information system (HRIS) to manage the onboardingand offboarding process for your employees, you can still use Google as yourIdP. Cloud Identity and Google Workspace provide APIs that let HRISand other systems take control of managing users and groups, as shown in thefollowing diagram.

• You use your existing HRIS to manage users and optionally groups. TheHRIS remains the single source of truth for identity management andautomatically provisions users for Cloud Identity orGoogle Workspace.
• All Google services use Cloud Identity Premium orGoogle Workspace as the IdP.
• You configure corporate applications and other SaaS services to useGoogle as the IdP.

User experience

To an employee, the sign-on user experience is equivalent to usingGoogle as IdP and authoritative source.

Advantages

Using Google as the IdP and authoritative source has the following advantages:

• You can minimize administrative overhead by reusing your existing HRISworkflows.
• You can take full advantage of Google'smulti-factor authentication andmobile device management features.
• You don't need an additional IdP, which might save you money.

When to use this architecture

Consider using Google as your IdP with an HRIS as authoritative source in thefollowing scenarios:

• You have an existing HRIS or other system that serves as theauthoritative source for identities.
• You already use Google Workspace as your collaboration andproductivity solution.
• There is no existing on-premises infrastructure or IdP that you have tointegrate with or that you would like to keep separate from your Googleestate.

Use an external IdP

If your organization already uses an IdP such as Active Directory, MicrosoftEntra ID (formerly Azure AD), ForgeRock, Okta, or Ping Identity, then you canintegrate Google Cloud with this external IdP by using federation.

Byfederating a Cloud Identity or Google Workspace account with an external IdP, you can let employees use their existing identity andcredentials to sign in to Google services such as Google Cloud,Google Marketing Platform, and Google Ads.

External IDaaS as IdP and authoritative source

If you use an identity as a service (IDaaS) provider such as ForgeRock, Okta, or Ping Identity,then you can set up federation as illustrated in the following diagram.

• Cloud Identity or Google Workspace uses your IDaaS as theIdP for single sign-on.
• The IDaaS automatically provisions users and groups forCloud Identity or Google Workspace.
• Existing corporate applications and other SaaS services can continue toyour IDaaS as an IdP.

To learn more about federating Cloud Identity or Google Workspacewith Okta, seeOkta user provisioning and single sign-on.

User experience

To an employee, the sign-on user experience looks like this:

1. Upon requesting a protected resource, the employee is redirected to theGoogle Sign-In screen, which prompts them for their email address.
2. Google Sign-In redirects you to the sign-in page of your IDaaS.
3. You authenticate with your IDaaS. Depending on your IDaaS, this mightrequire you to provide a second factor such as a code.
4. After you are authenticated, you are redirected back to the protectedresource.

Advantages

Using an external IDaaS as IdP and authoritative source has the followingadvantages:

• You enable a single sign-on experience for your employees that extendsacross Google services and other applications that are integrated with yourIDaaS.
• If you configured your IDaaS to require multi-factor authentication,that configuration automatically applies to Google Cloud.
• You don't need to synchronize passwords or other credentials with Google.
• You can use the free version of Cloud Identity.

When to use this architecture

Consider using an external IDaaS as IdP and authoritative source in thefollowing scenarios:

• You already use an IDaaS provider such as ForgeRock, Okta, or Ping Identity as your IdP.

Best practices

See ourbest practices for federating Google Cloud with an external identity provider.

Active Directory as IdP and authoritative source

If you use Active Directory as the source of truth for identity management,then you can set up federation as illustrated in the following diagram.

• You useGoogle Cloud Directory Sync (GCDS) to automatically provision users and groups from Active Directory forCloud Identity or Google Workspace.Google Cloud Directory Sync is a free Google-provided tool that implementsthe synchronization process and can be run either on Google Cloud orin your on-premises environment. Synchronization is one-way so thatActive Directory remains the source of truth.
• Cloud Identity or Google Workspace uses Active DirectoryFederation Services (AD FS) for single sign-on.
• Existing corporate applications and other SaaS services can continue touse your AD FS as an IdP.

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

For more information about this approach, seeFederate Google Cloud with Active Directory.

User experience

1. Upon requesting the protected resource, the employee is redirected tothe Google Sign-in screen, which prompts them for their email address.
2. Google Sign-In redirects the employee to the sign-in page of AD FS.
3. Depending on the configuration of AD FS, the employee might see asign-on screen prompting for their Active Directory username and password.Alternatively, AD FS might attempt to sign the employee in automaticallybased on their Windows login.
4. After AD FS has authenticated the employee, they are redirected back tothe protected resource.

Advantages

Using Active Directory as IdP and authoritative source has the followingadvantages:

• You enable a single sign-on experience for your employees that extendsacross Google services and your on-premises environment.
• If you configured AD FS to require multi-factor authentication, thatconfiguration automatically applies to Google Cloud.
• You don't need to synchronize passwords or other credentials to Google.
• You can use the free version of Cloud Identity.
• Because the APIs that GCDS uses are publiclyaccessible, there's no need to set uphybrid connectivity between your on-premises network and Google Cloud.

When to use this architecture

Consider using Active Directory as the IdP and authoritative source in thefollowing scenarios:

• You have an existing Active Directory infrastructure.
• You want to provide a seamless sign-in experience for Windows users.

Best practices

Consider these best practices:

• Active Directory and Cloud Identity use a different logicalstructure. Make sure you understand the differences and assess which methodof mapping domains, identities, and groups best suits your situation. Formore information, see ourguide on federating Google Cloud with Active Directory.
• Synchronize groups in addition to users. With this approach, you can setup IAM so that you can use group memberships in ActiveDirectory to control who has access to which resources inGoogle Cloud.
• Deploy and expose AD FS so that corporate users can access it, but don'texpose it more than necessary. Although corporate users must be able toaccess AD FS, there's no requirement for AD FS to be reachable fromCloud Identity or Google Workspace, or from any applicationdeployed on Google Cloud.
• Consider enabling Integrated Windows Authentication (IWA) in AD FS toallow users to sign in automatically based on their Windows login.
• If AD FS becomes unavailable, users might not be able to use theGoogle Cloud console or any other resource that uses Google as IdP. So ensurethat AD FS and the domain controllers AD FS relies on are deployed andsized to meet your availability objectives.

• If you use Google Cloud to help ensure business continuity,relying on an on-premises AD FS might undermine the intent of usingGoogle Cloud as an independent copy of your deployment. In this case,consider deploying replicas of all relevant systems on Google Cloudin one of the following ways:

  • Extend your existing Active Directory domain to Google Cloud and deploy GCDS to run onGoogle Cloud.
  • Run dedicated AD FS servers on Google Cloud. These serversuse the Active Directory domain controllers that are running onGoogle Cloud.
  • Configure Cloud Identity to use the AD FS serversdeployed on Google Cloud for single sign-on.

To learn more, seeBest practices for federating Google Cloud with an external identity provider.

Entra ID as IdP with Active Directory as authoritative source

If you are a Microsoft 365 or Azure customer, you might have connectedyour on-premises Active Directory to Entra ID. If all user accounts thatpotentially need access to Google Cloud are already being synchronized toEntra ID, you can reuse this integration by federating Cloud Identitywith Entra ID, as shown in the following diagram.

• You use Entra ID to automatically provision users and groups toCloud Identity or Google Workspace. Entra ID itself might beintegrated with an on-premises Active Directory.
• Cloud Identity or Google Workspace use Entra ID for singlesign-on.
• Existing corporate applications and other SaaS services can continue touse Entra ID as an IdP.

For more detailed information about this approach, seeFederate Google Cloud with Microsoft Entra ID.

User experience

1. Upon requesting the protected resource, the employee is redirected tothe Google Sign-In screen, which prompts them for their email address.
2. Google Sign-In redirects them to the sign-in page of AD FS.
3. Depending on how their on-premises Active Directory is connected toEntra ID, Entra ID might prompt them for a username and password, or itmight redirect them to an on-premises AD FS.
4. After the employee is authenticated with Entra ID, they are redirectedback to the protected resource.

Advantages

Using Entra ID as your IdP with Active Directory as authoritative source hasseveral advantages:

• You enable a single sign-on experience for your employees that extendsacross Google services, Entra, and your on-premises environment.
• If you configured Entra ID to require multi-factor authentication, thatconfiguration automatically applies to Google Cloud.
• You don't need to install any additional software on-premises.
• If your on-premises Active Directory uses multiple domains or forestsand you have set up a custom Entra ID Connect configuration to map thisstructure to an Entra ID tenant, you can take advantage of this integrationwork.
• You don't need to synchronize passwords or other credentials to Google.
• You can use the free version of Cloud Identity.
• You can surface the Google Cloud console as a tile in the Office 365portal.
• Because the APIs that Entra ID uses are publicly accessible, there's noneed to set uphybrid connectivity between Entra and Google Cloud.

When to use this architecture

Consider using Entra ID as IdP with Active Directory as authoritative source inthe following scenarios:

• You already use Entra ID and have integrated it with an existing ActiveDirectory infrastructure.
• You want to provide a seamless sign-in experience for users across Entraand Google Cloud.

Best practices

Follow these best practices:

• Because Entra ID and Cloud Identity use a different logicalstructure, make sure you understand the differences. Assess which method ofmapping domains, identities, and groups best suits your situation. For moredetailed information, seeFederate Google Cloud with Microsoft Entra ID.
• Synchronize groups in addition to users. With this approach, you can setup IAM so that you can use group memberships in Entra ID to control who has access to which resources inGoogle Cloud.
• If you use Google Cloud to help ensure business continuity,relying on Entra ID for authentication might undermine the intent of usingGoogle Cloud as an independent copy of your deployment.

To learn more, seeBest practices for federating Google Cloud with an external identity provider.

What's next

• Learn more aboutfederating with Active Directory.
• Find out how toset up federation with Entra ID.
• Review ourbest practices for planning accounts and organizations and forfederating Google Cloud with an external identity provider.