Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cloud.google.com/architecture/identity/reference-architectures below:

Reference architectures | Cloud Architecture Center

Stay organized with collections Save and categorize content based on your preferences.

Last reviewed 2024-07-11 UTC

This document presents typical architectures that you can use as a reference for managing corporate identities. Two core tenets of corporate identity management are the following:

• An authoritative source for identities that is the sole system that you use to create, manage, and delete identities for your employees. The identities managed in the authoritative source system might be propagated to other systems.

• A central identity provider (IdP) that is the sole system for authentication and that provides a single sign-on experience for your employees that spans applications.

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

By using Cloud Identity Premium or Google Workspace, you can make Google your primary IdP. Google provides a large selection of ready-to-use integrations for popular third-party applications, and you can use standard protocols such as SAML, OAuth, and OpenID Connect to integrate your custom applications.

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

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

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

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

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

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

Consider using Google as IdP and authoritative source in the following scenarios:

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

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

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

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

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

• You can minimize administrative overhead by reusing your existing HRIS workflows.
• You can take full advantage of Google's multi-factor authentication and mobile device management features.
• You don't need an additional IdP, which might save you money.

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

• You have an existing HRIS or other system that serves as the authoritative source for identities.
• You already use Google Workspace as your collaboration and productivity solution.
• There is no existing on-premises infrastructure or IdP that you have to integrate with or that you would like to keep separate from your Google estate.

If your organization already uses an IdP such as Active Directory, Azure AD, ForgeRock, Okta, or Ping Identity, then you can integrate Google Cloud with this external IdP by using federation.

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

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 the IdP for single sign-on.
• The IDaaS automatically provisions users and groups for Cloud Identity or Google Workspace.
• Existing corporate applications and other SaaS services can continue to your IDaaS as an IdP.

To learn more about federating Cloud Identity or Google Workspace with Okta, see Okta 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 the Google 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 might require you to provide a second factor such as a code.
4. After you are authenticated, you are redirected back to the protected resource.

Advantages

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

• You enable a single sign-on experience for your employees that extends across Google services and other applications that are integrated with your IDaaS.
• 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 the following scenarios:

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

Best practices

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

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 use Google Cloud Directory Sync (GCDS) to automatically provision users and groups from Active Directory for Cloud Identity or Google Workspace. Google Cloud Directory Sync is a free Google-provided tool that implements the synchronization process and can be run either on Google Cloud or in your on-premises environment. Synchronization is one-way so that Active Directory remains the source of truth.
• Cloud Identity or Google Workspace uses Active Directory Federation Services (AD FS) for single sign-on.
• Existing corporate applications and other SaaS services can continue to use your AD FS as an IdP.

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.

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

1. Upon requesting the protected resource, the employee is redirected to the 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 a sign-on screen prompting for their Active Directory username and password. Alternatively, AD FS might attempt to sign the employee in automatically based on their Windows login.
4. After AD FS has authenticated the employee, they are redirected back to the protected resource.

Using Active Directory as IdP and authoritative source has the following advantages:

• You enable a single sign-on experience for your employees that extends across Google services and your on-premises environment.
• If you configured AD FS to require multi-factor authentication, that configuration 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 publicly accessible, there's no need to set up hybrid connectivity between your on-premises network and Google Cloud.

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

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

Consider these best practices:

• Active Directory and Cloud Identity use a different logical structure. Make sure you understand the differences and assess which method of mapping domains, identities, and groups best suits your situation. For more information, see our guide on federating Google Cloud with Active Directory.
• Synchronize groups in addition to users. With this approach, you can set up IAM so that you can use group memberships in Active Directory to control who has access to which resources in Google Cloud.
• 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 Cloud Identity or Google Workspace, or from any application deployed on Google Cloud.
• 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 Google Cloud 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 Google Cloud to help ensure business continuity, relying on an on-premises AD FS might undermine the intent of using Google Cloud as an independent copy of your deployment. In this case, consider deploying replicas of all relevant systems on Google Cloud in one of the following ways:

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

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

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 Google Cloud are already being synchronized to Azure AD, you can reuse this integration by federating Cloud Identity with Azure AD, as shown in the following diagram.

• You use Azure AD to automatically provision users and groups to Cloud Identity or Google Workspace. Azure AD itself might be integrated with an on-premises Active Directory.
• Cloud Identity or Google Workspace use Azure AD for single sign-on.
• Existing corporate applications and other SaaS services can continue to use Azure AD as an IdP.

For more detailed information about this approach, see Federate Google Cloud with Azure Active Directory.

1. Upon requesting the protected resource, the employee is redirected to the 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 to Azure AD, Azure AD might prompt them for a username and password, or it might redirect them to an on-premises AD FS.
4. After the employee is authenticated with Azure AD, they are redirected back to the protected resource.

Advantages

Using Azure AD as your IdP with Active Directory as authoritative source has several advantages:

• You enable a single sign-on experience for your employees that extends across Google services, Azure, and your on-premises environment.
• If you configured Azure AD to require multi-factor authentication, that configuration 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 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.
• You can use the free version of Cloud Identity.
• You can surface the Google Cloud console as a tile in the Office 365 portal.
• Because the APIs that Azure AD uses are publicly accessible, there's no need to set up hybrid connectivity between Azure and Google Cloud.

Consider using Azure AD as IdP with Active Directory as authoritative source in the following scenarios:

• You already use Azure AD and have integrated it with an existing Active Directory infrastructure.
• You want to provide a seamless sign-in experience for users across Azure and Google Cloud.

Follow these best practices:

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

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

• Learn more about federating with Active Directory.
• Find out how to set up federation with Azure AD.
• Review our best practices for planning accounts and organizations and for federating Google Cloud with an external identity provider.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2024-07-11 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-07-11 UTC."],[[["This document outlines different architectures for managing corporate identities, emphasizing the use of an authoritative source for identities and a central identity provider (IdP)."],["You can use Google as both your IdP and authoritative source with Cloud Identity Premium or Google Workspace, offering advantages like multi-factor authentication and eliminating the need for an additional IdP."],["Organizations can use an existing HRIS as the authoritative source for identities while still utilizing Google as their IdP, allowing for the leveraging of existing workflows and Google's security features."],["If an external IdP such as Active Directory, Azure AD, ForgeRock, Okta, or Ping Identity is already in use, Google Cloud can be integrated via federation, enabling single sign-on across services."],["Integrating with an existing external IdP can allow for the leveraging of existing configurations, such as multi-factor authentication, and in some cases can reduce the need for synchronizing passwords or credentials."]]],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4