En este documento, se presentan arquitecturas típicas que puedes usar como referencia para administrar identidades corporativas. Dos principios básicos de la administración de identidades corporativas son los siguientes:
Una fuente autorizada para las identidades, el único sistema que usas a fin de crear, administrar y borrar identidades para tus empleados. Las identidades administradas en el sistema fuente autorizado pueden propagarse a otros sistemas
Un proveedor de identidad (IdP) central, que es el único sistema de autenticación y que proporciona una experiencia de inicio de sesión único para tus empleados que abarca aplicaciones
Cuando usas Google Cloud y otros servicios de Google, debes decidir qué sistema usar como tu proveedor de identidad y qué sistema usar como fuente autorizada.
Usa Google como IdP
Mediante Cloud Identity Premium o Google Workspace, puedes convertir a Google en tu IdP principal. Google ofrece una gran selección de integraciones listas para usar para aplicaciones populares de terceros, y puedes usar protocolos estándar como SAML, OAuth y OpenID Connect para integrar tus aplicaciones personalizadas.
Google como IdP y fuente autorizada
Puedes usar Cloud Identity Premium o Google Workspace como IdP y fuente autorizada, como se muestra en el siguiente diagrama.
- Usa Cloud Identity Premium o Google Workspace para administrar usuarios y grupos.
- Todos los servicios de Google usan Cloud Identity Premium o Google Workspace como IdP.
- Configuras aplicaciones corporativas y otros servicios de SaaS para usar Google como IdP.
Experiencia del usuario
En esta configuración, para un empleado, la experiencia de inicio de sesión del usuario se ve de la siguiente manera:
- Cuando solicitas un recurso protegido o acceso a una aplicación corporativa, se redirecciona al empleado a la pantalla de Acceso con Google, que te solicita la dirección de correo electrónico y la contraseña.
- Si la verificación en dos pasos está habilitada, se le solicita al empleado que proporcione un segundo factor, como una clave USB o un código.
- Cuando se autentica al empleado, se lo redirecciona al recurso protegido.
Ventajas
Usar Google como IdP y fuente autorizada tiene las siguientes ventajas:
- Puedes aprovechar al máximo las funciones de autenticación de varios factores y de administración de dispositivos móviles de Google.
- No necesitas un IdP adicional, lo que podría ahorrarte dinero.
Cuándo se debe usar esta arquitectura
Considera usar Google como IdP y fuente autorizada en las siguientes situaciones:
- Ya usas Google Workspace como solución de colaboración y productividad.
- No hay una infraestructura local o un IdP existente que debas integrar o que desees mantener separado de todos tus recursos en Google (en Google Cloud, en Google Ads, etc.).
- No necesitas la integración con un sistema de información de recursos humanos (HRIS) para administrar identidades.
Google como IdP con un HRIS como fuente autorizada
Si usas un sistema de información de recursos humanos (HRIS) a fin de administrar el proceso de integración y desvinculación de tus empleados, puedes usar Google como tu IdP. Cloud Identity y Google Workspace proporcionan APIs que permiten que el HRIS y otros sistemas controlen la administración de usuarios y grupos, como se muestra en el siguiente diagrama.
- Puedes usar tus HRIS existentes para administrar usuarios y, de forma opcional, grupos. El HRIS sigue siendo la única fuente de información para la administración de identidades y aprovisiona de forma automática usuarios para Cloud Identity o G Workspace.
- Todos los servicios de Google usan Cloud Identity Premium o Google Workspace como IdP.
- Configuras aplicaciones corporativas y otros servicios de SaaS para usar Google como IdP.
Experiencia del usuario
Para un empleado, la experiencia de inicio de sesión del usuario es equivalente a usar Google como IdP y fuente autorizada.
Ventajas
Usar Google como IdP y fuente autorizada tiene las siguientes ventajas:
- Puedes minimizar la sobrecarga administrativa si reutilizas tus flujos de trabajo de HRIS existentes.
- Puedes aprovechar al máximo las funciones de autenticación de varios factores y de administración de dispositivos móviles de Google.
- No necesitas un IdP adicional, lo que podría ahorrarte dinero.
Cuándo se debe usar esta arquitectura
Considera el uso de Google como tu IdP con un HRIS como fuente autorizada en los siguientes casos:
- Tienes un sistema de tipo HRIS o de otro tipo que funciona como la fuente autorizada para las identidades.
- Ya usas Google Workspace como solución de colaboración y productividad.
- No existe una infraestructura local o un IdP existente que debas integrar o que desees mantener separado de tu estado de Google.
Usa un IdP externo
Si tu organización ya usa un IdP, como Active Directory, Azure AD, ForgeRock, Okta o Ping Identity, puedes integrar Google Cloud a este IdP externo mediante la federación.
Mediante la federación de una cuenta de Cloud Identity o Google Workspace con un IdP externo, puedes permitir que los empleados usen sus credenciales y identidades existentes para acceder a los servicios de Google, como Google Cloud. , Google Marketing Platform y Google Ads.
IDaaS externo como IdP y fuente autorizada
Si usas una identidad como proveedor de servicios (IDaaS), como ForgeRock, Okta o Ping Identity, puedes configurar la federación como se ilustra en el siguiente diagrama.
- Cloud Identity o Google Workspace usan tu IDaaS como IdP para el inicio de sesión único.
- El IDaaS aprovisiona de forma automática usuarios y grupos para Cloud Identity o Google Workspace.
- Las aplicaciones corporativas existentes y otros servicios de SaaS pueden continuar con tus IDaaS como IdP.
Para obtener más información sobre cómo federar Cloud Identity o Google Workspace con Okta, consulta Aprovisionamiento de usuarios de Okta y el inicio de sesión único.
Experiencia del usuario
Para un empleado, la experiencia de inicio de sesión del usuario se ve de la siguiente manera:
- Cuando se solicita un recurso protegido, se redirecciona al empleado a la pantalla de Acceso con Google, que le solicita la dirección de correo electrónico y la contraseña.
- El Acceso con Google te redirecciona a la página de acceso de tu IDaaS.
- Realiza la autenticación con tu IDaaS. Según tu IDaaS, es posible que debas proporcionar un segundo factor, como un código.
- Después de la autenticación, se te redirecciona al recurso protegido.
Ventajas
Usar un IDaaS externo como IdP y fuente autorizada tiene las siguientes ventajas:
- Habilitas una experiencia de inicio de sesión único para tus empleados que se extiende a través de los servicios de Google y otras aplicaciones integradas a tu IDaaS.
- Si configuraste tu IDaaS para que requiera autenticación de varios factores, esa configuración se aplica de forma automática a Google Cloud.
- No necesitas sincronizar contraseñas ni otras credenciales con Google.
- Puedes usar la versión gratuita de Cloud Identity.
Cuándo se debe usar esta arquitectura
Considera usar un IDaaS externo como IdP y una fuente autorizada en las siguientes situaciones:
- Ya usas un proveedor de IDaaS como ForgeRock, Okta o Ping Identity como tu IdP.
Prácticas recomendadas
Consulta nuestras prácticas recomendadas para federar Google Cloud con un proveedor de identidad externo.
Active Directory como IdP y fuente autorizada
Si usas Active Directory como la fuente de información para la administración de identidades, puedes configurar la federación como se ilustra en el siguiente diagrama.
- Usa Google Cloud Directory Sync a fin de aprovisionar usuarios y grupos de forma automática desde Active Directory para Cloud Identity o Google Workspace. Google Cloud Directory Sync es una herramienta gratuita de Google que implementa el proceso de sincronización y se puede ejecutar en Google Cloud o en tu entorno local. La sincronización es unidireccional para que Active Directory continúe siendo la fuente de información.
- Cloud Identity o Google Workspace usan los Servicios de federación de Active Directory (AD FS) para el inicio de sesión único.
- Las aplicaciones corporativas existentes y otros servicios de SaaS pueden seguir usando tu AD FS como IdP.
Para una variación de este patrón, también puedes usar los Servicios de directorio básicos de Active Directory (AD LDS) o un directorio LDAP diferente con AD FS o con otro IdP compatible con SAML.
Para obtener más información sobre este enfoque, consulta Federa Google Cloud con Active Directory.
Experiencia del usuario
- Cuando se solicita el recurso protegido, se redirecciona al empleado a la pantalla de Acceso con Google, que le solicita su dirección de correo electrónico.
- El Acceso con Google redirecciona al empleado a la página de acceso de AD FS.
- Según la configuración de AD FS, el empleado podría ver una pantalla de acceso que solicita su nombre de usuario y contraseña de Active Directory. Como alternativa, AD FS podría intentar que el empleado acceda de forma automática en función de su acceso a Windows.
- Una vez que AD FS haya autenticado al empleado, se lo redireccionará al recurso protegido.
Ventajas
Usar Active Directory como IdP y fuente autorizada tiene las siguientes ventajas:
- Habilitas una experiencia de inicio de sesión único para tus empleados que se extiende a través de los servicios de Google y tu entorno local.
- Si configuraste AD FS para que requiera autenticación de varios factores, esa configuración se aplica de forma automática a Google Cloud.
- No es necesario que sincronices contraseñas ni otras credenciales con Google.
- Puedes usar la versión gratuita de Cloud Identity.
- Debido a que las API que usa Google Cloud Directory Sync son de acceso público, no es necesario configurar la conectividad híbrida entre la red local y Google Cloud.
Cuándo usar esta arquitectura
Considera usar Active Directory como IdP y fuente autorizada en las siguientes situaciones:
- Tienes una infraestructura de Active Directory existente.
- Deseas proporcionar una experiencia de acceso sin interrupciones para los usuarios de Windows.
Prácticas recomendadas
Considera estas prácticas recomendadas:
- Active Directory y Cloud Identity usan una estructura lógica diferente. Asegúrate de comprender las diferencias y evaluar qué método de asignación de dominios, identidades y grupos se adapta mejor a tu situación. Para obtener más información, consulta nuestra guía sobre la federación de Google Cloud con Active Directory.
- Sincroniza grupos además de usuarios. Con este enfoque, puedes configurar IAM para usar las membresías de grupo en Active Directory a fin de controlar quién tiene acceso a qué recursos en Google Cloud.
- Implementa y expón AD FS para que los usuarios corporativos puedan acceder a él, pero no lo expongas más de lo necesario. Aunque los usuarios corporativos deben poder acceder a AD FS, no es necesario que se pueda acceder desde Cloud Identity o Google Workspace, o desde cualquier aplicación implementada en Google Cloud.
- Considera habilitar la autenticación de Windows integrada (IWA) en AD FS para permitir que los usuarios accedan de forma automática en función de su acceso a Windows.
- Si AD FS no está disponible, es posible que los usuarios no puedan usar la consola de Google Cloud o cualquier otro recurso que use Google como IdP. Por lo tanto, asegúrate de que AD FS y los controladores de dominio en los que confía estén implementados y tengan el tamaño adecuado para cumplir con los objetivos de disponibilidad.
Si usas Google Cloud para garantizar la continuidad del negocio, depender de un AD FS local podría socavar la intención de usar Google Cloud como una copia independiente de la implementación. En este caso, considera implementar las réplicas de todos los sistemas relevantes en Google Cloud de una de las siguientes maneras:
- Extiende tu dominio de Active Directory existente a Google Cloud y, luego, implementa Google Cloud Directory Sync para que se ejecute en Google Cloud.
- Ejecuta servidores de AD FS dedicados en Google Cloud. Estos servidores usan los controladores de dominio de Active Directory que se ejecutan en Google Cloud.
- Configura Cloud Identity a fin de usar los servidores de AD FS implementados en Google Cloud para el inicio de sesión único.
A fin de obtener más información, consulta Prácticas recomendadas para federar Google Cloud con un proveedor de identidad externo.
Azure AD como IdP con Active Directory como fuente autorizada
Si eres cliente de Microsoft Office 365 o Azure, es posible que hayas conectado el Active Directory local a Azure AD. Si todas las cuentas de usuario que pueden necesitar acceso a Google Cloud ya se están sincronizando con Azure AD, puedes volver a usar esta integración mediante la federación de Cloud Identity con Azure AD, como se muestra en el siguiente diagrama.
- Azure AD permite que se aprovisionen de manera automática usuarios y grupos a Cloud Identity o Google Workspace. Azure AD puede integrarse a un Active Directory local.
- Cloud Identity o Google Workspace usan Azure AD para el inicio de sesión único.
- Las aplicaciones corporativas existentes y otros servicios de SaaS pueden seguir usando Azure AD como IdP.
Para obtener información más detallada sobre este enfoque, consulta Federa Google Cloud con Azure Active Directory.
Experiencia del usuario
- Cuando se solicita el recurso protegido, se redirecciona al empleado a la pantalla de Acceso con Google, que le solicita su dirección de correo electrónico.
- El Acceso con Google lo redirecciona a la página de acceso de AD FS.
- Según cómo se conecte su Active Directory local a Azure AD, es posible que Azure AD le solicite un nombre de usuario y una contraseña, o que lo redireccione a un AD FS local.
- Una vez que el empleado se autentica con Azure AD, se lo redirecciona al recurso protegido.
Ventajas
Usar Azure AD como tu IdP con Active Directory como fuente autorizada tiene varias ventajas:
- Habilitas una experiencia de inicio de sesión único para tus empleados que se extiende a través de los servicios de Google, Azure y tu entorno local.
- Si configuraste Azure AD para que requiera autenticación de varios factores, esa configuración se aplica de forma automática a Google Cloud.
- No es necesario instalar ningún software local adicional.
- Si Active Directory local usa varios dominios o bosques y tienes una configuración personalizada de Azure AD Connect para mapear esta estructura a un usuario de Azure AD, puedes aprovechar este trabajo de integración.
- No es necesario que sincronices contraseñas ni otras credenciales con Google.
- Puedes usar la versión gratuita de Cloud Identity.
- Puedes mostrar la consola de Google Cloud como un mosaico en el portal de Office 365.
- Debido a que las API que usa Azure AD son de acceso público, no es necesario configurar la conectividad híbrida entre Azure y Google Cloud.
Cuándo se debe usar esta arquitectura
Considera usar Azure AD como IdP con Active Directory como fuente autorizada en las siguientes situaciones:
- Ya usas Azure AD y lo integraste a una infraestructura de Active Directory existente.
- Deseas proporcionar una experiencia de acceso sin interrupciones para los usuarios de Azure y Google Cloud.
Prácticas recomendadas
Sigue las prácticas recomendadas a continuación:
- Azure AD y Cloud Identity usan una estructura lógica diferente, por lo que es importante que comprendas las diferencias. Evalúa qué método de asignación de dominios, identidades y grupos se adapta mejor a tu situación. Para obtener información más detallada, consulta Federa Google Cloud con Azure AD.
- Sincroniza grupos además de usuarios. Con este enfoque, puedes configurar Cloud IAM para usar las membresías de grupo en Azure AD a fin de controlar quién tiene acceso a los recursos en Google Cloud.
- Si usas Google Cloud a fin de garantizar la continuidad del negocio, depender de Azure AD para la autenticación podría socavar la intención de usar Google Cloud como una copia independiente de la implementación.
A fin de obtener más información, consulta Prácticas recomendadas para federar Google Cloud con un proveedor de identidad externo.
¿Qué sigue?
- Obtén más información sobre cómo federar con Active Directory.
- Descubre cómo configurar la federación con Azure AD.
- Revisa nuestras prácticas recomendadas a fin de planificar cuentas y organizaciones y para federar Google Cloud con un proveedor de identidad externo.