Patrones de arquitectura para la federación de identidades

En este documento, se comparan cuatro patrones de arquitectura para federar Google Cloud con un proveedor de identidad (IdP) externo. También se proporciona orientación para ayudarte a elegir una arquitectura adecuada para tu caso de uso.

Los cuatro patrones de arquitectura son los siguientes:

Factores de decisión

Para elegir un patrón de arquitectura adecuado para tu organización, considera varios factores, incluidos los siguientes:

Portafolio de servicios

Los servicios de Google administran la autenticación y la autorización de manera diferente. Esto afecta la forma en que configuras la federación de identidades. Dos factores determinan estas diferencias: el modelo de servicio SaaS en comparación con PaaS y IaaS, y el modelo de autorización IAM en comparación con el específico del servicio.

Modelos de servicio

  • Software como servicio (SaaS): Google administra por completo servicios como Gmail, Google Ads o la app de Gemini Enterprise. Estos servicios no requieren ningún esfuerzo de desarrollo y están listos para usarse. Debido a que los servicios de SaaS se dirigen a un público amplio, es posible que la mayoría de tus usuarios requieran acceso a ellos.
  • Plataforma como servicio (PaaS) o infraestructura como servicio (IaaS): La mayoría de los Google Cloud servicios son PaaS o IaaS. Estos servicios permiten que los usuarios técnicos desarrollen, implementen y operen cargas de trabajo personalizadas. Debido a que estos servicios se dirigen a un público técnico, solo un subconjunto de tus usuarios requiere acceso.

Modelos de autorización

Los servicios de Google implementan la autorización de una de las siguientes maneras:

  • IAM: La mayoría de los Google Cloud servicios usan IAM para permitir que los administradores administren el acceso detallado a los recursos.
  • Autorización específica del servicio: Los servicios como Google Ads, Looker o Google Workspace no usan IAM. En cambio, los administradores administran el acceso con herramientas específicas para cada servicio.

Estos factores dan como resultado los siguientes grupos de servicios:

SaaS PaaS o IaaS
Autorización basada en IAM Servicios de SaaS, como la app de Gemini Enterprise y NotebookLM Enterprise Google Cloud Servicios de PaaS y IaaS, como BigQuery o Compute Engine Google Cloud
Autorización específica del servicio Servicios de Google que no son de la nube, como Google Ads, Google Workspace, y Google Maps Ninguno

Para elegir un patrón de arquitectura adecuado para tu organización, considera qué grupos de servicios se aplican a tu organización.

Residencia de los datos

Para autenticar a los usuarios y administrar las sesiones, Cloud Identity, Google Workspace y la federación de identidades de personal procesan la información personal del usuario. Esta información del usuario puede incluir lo siguiente:

  • Nombres de usuario o direcciones de correo electrónico
  • Atributos del usuario, como nombres y apellidos
  • Nombres de grupos y membresías

Cloud Identity, Google Workspace y la federación de identidades de personal procesan estos datos según las condiciones de los datos de servicio y pueden almacenarlos fuera de las ubicaciones de la organización o de los usuarios:

  • Cloud Identity y Google Workspace almacenan datos de servicio en centros de datos de Google y pueden replicarlos en todos los centros de datos. Los datos almacenados pueden incluir información que no es esencial para la autenticación, como nombres de departamentos, direcciones o números de teléfono.
  • La federación de identidades de personal almacena datos de servicio en Google Cloud regiones y puede replicarlos en todas las regiones.

Si otorgas acceso a un usuario a un recurso, IAM almacena su identificador principal en un proceso de vinculación de roles. Google Cloud procesa las vinculaciones de roles según las condiciones de los datos de servicio y puede almacenarlos en todas las regiones. Google Cloud

Los patrones de arquitectura que se describen en esta página requieren el almacenamiento de información del usuario, pero difieren en el tiempo que almacenan esa información:

Muchos IdP te permiten automatizar la suspensión o eliminación de cuentas de usuario cuando cambia el estado de la cuenta de usuario correspondiente en el IdP. Según tu IdP y su configuración, el IdP puede retrasar la eliminación de la cuenta de usuario hasta que venza un período de gracia determinado, lo que puede extender el tiempo que almacena esa información del usuario. Google Cloud

Integración de Gemini Enterprise con Microsoft 365

Gemini Enterprise te permite conectarte a los servicios de Microsoft 365 con dos tipos de conectores:

  • Conectores basados en la ingesta de datos: Estos conectores rastrean Microsoft 365 para compilar un índice de búsqueda en Google Cloud. Cuando un usuario envía una instrucción, Gemini Enterprise usa este índice para buscar contenido y realiza verificaciones de acceso de forma local mediante la evaluación de las listas de control de acceso (ACL) obtenidas de Microsoft 365.
  • Conectores federados: Estos conectores consultan Microsoft 365 para cada instrucción. Usan la autorización delegada para permitir que Microsoft 365 realice las verificaciones de acceso directamente.

Los conectores basados en la ingesta de datos introducen requisitos específicos para la federación de usuarios:

  • Conocimiento de la pertenencia a un grupo: Las ACL de Microsoft 365 pueden incluir entradas para grupos y usuarios. Para evaluar si un usuario puede acceder al contenido, los conectores deben considerar todos los grupos a los que pertenece el usuario. Si el conector solo conoce un subconjunto de los grupos del usuario, es posible que permita o deniegue el acceso de forma incorrecta.
  • Conversión de identificadores: Para evaluar las ACL, el conector debe convertir entre los identificadores de usuario y grupo que usa Microsoft 365 y los identificadores que usa Google Cloud.

Cuando usas la federación de identidades de personal, Gemini Enterprise puede convertir identificadores de forma confiable y evaluar las ACL si configuras las asignaciones de atributos para que sean compatibles con Gemini Enterprise.

Cuando usas la federación de Cloud Identity o Google Workspace, Microsoft Entra ID controla las asignaciones de atributos para el aprovisionamiento de usuarios y grupos provisionamiento, en lugar de Google Cloud. Entra determina las reglas de conversión para los identificadores de usuario y grupo, lo que puede implicar transformaciones complejas. Para evaluar una ACL, el conector de Gemini Enterprise debe aplicar las mismas reglas de conversión, pero el conector no tiene visibilidad en la configuración de Entra. Por lo tanto, cuando usas la federación de Cloud Identity o Google Workspace, Gemini Enterprise no puede convertir de forma confiable los identificadores de usuario y grupo, ni evaluar las ACL de forma confiable.

Para determinar qué patrón de arquitectura se adapta a tu organización, considera tu uso de Gemini Enterprise y si planeas usar conectores basados en la ingesta de datos.

Patrones de arquitectura

En el siguiente diagrama de flujo, se muestra cómo estos factores determinan qué patrón cumple con los requisitos de tu organización:

Diagrama de flujo que muestra cómo seleccionar el patrón de federación de identidad.

  1. ¿Una parte importante de tu organización usa Google Workspace?

  2. ¿Usas servicios más allá de Google Cloud como Google Ads o Google Maps?

    • Si la respuesta es Sí, continúa con la decisión 3.
    • Si la respuesta es No, continúa con la decisión 4.

  3. ¿Planeas usar Gemini Enterprise y integrarlo con Microsoft 365?

  4. ¿Planeas usar Gemini Enterprise?

  5. ¿Tienes requisitos de residencia de datos que te obliguen a minimizar el almacenamiento de información del usuario?

Federación de Cloud Identity o Google Workspace

Selecciona este patrón cuando tu organización cumpla con uno de los siguientes criterios:

  • Una parte importante de tu organización ya usa Google Workspace.
  • Usas servicios de Google más allá de Google Cloud , como Google Ads o Google Maps, pero no planeas integrar Gemini Enterprise con Microsoft 365 mediante conectores basados en la ingesta de datos.
  • Solo usas servicios, no planeas usar Gemini Enterprise y no tienes requisitos estrictos de residencia de datos para minimizar el almacenamiento de datos del usuario. Google Cloud

En este patrón, no usas la federación de identidades de personal. En cambio, federas tu cuenta de Cloud Identity o tu cuenta de Google Workspace con tu IdP, y usas el aprovisionamiento de usuarios y el aprovisionamiento de grupos anticipados.

Arquitectura de la federación de Cloud Identity y Google Workspace.

En este patrón, debes aprovisionar usuarios y grupos antes de que los usuarios puedan acceder. De lo contrario, su intento de acceso fallará:

  • Aprovisionamiento de usuarios: Ayuda a garantizar la incorporación y la baja oportunas de los usuarios.
  • Aprovisionamiento de grupos: Te permite usar grupos para administrar el acceso a los servicios y recursos de Google . Google Cloud

Si solo un subconjunto de los usuarios de tu organización necesita Google Workspace, agrega una suscripción a Google Workspace y una suscripción a Cloud Identity a tu cuenta, y asigna licencias de Google Workspace solo a los usuarios que las necesiten.

Beneficios

  • Los usuarios pueden autenticarse en los servicios de Google, independientemente de si esos servicios usan IAM o no. En la cuenta de Cloud Identity o en la cuenta de Google Workspace, controla qué servicios de Google pueden usar los usuarios.
  • Puedes limitar el inicio de sesión único (SSO) y el aprovisionamiento anticipado a un subconjunto de usuarios, y seguir administrando usuarios específicos, como los usuarios de acceso de emergencia, directamente en Cloud Identity o en Google Workspace.
  • Puedes aprovisionar grupos desde tu IdP externo, administrar grupos de forma local en tu cuenta de Cloud Identity o en tu cuenta de Google Workspace, o combinar ambos enfoques.

Limitaciones

  • El aprovisionamiento de cuentas de usuario con anticipación agrega sobrecarga y puede ralentizar el proceso de incorporación.

  • No puedes controlar ni restringir las ubicaciones que usan Cloud Identity o Google Workspace para almacenar datos de usuario y datos de grupo. Debido a que Google procesa y almacena datos de usuario y datos de grupo según las condiciones de los datos de servicio, los controles de región de datos no cubren esos datos, y Google puede replicarlos en las ubicaciones de los centros de datos de Google.

  • Gemini Enterprise proporciona asistencia limitada para conectarse a fuentes de datos de Microsoft cuando usas la federación de Cloud Identity o Google Workspace.

Federación de identidades de personal, sin sincronización

Selecciona este patrón cuando tu organización cumpla con los siguientes criterios:

  • Solo usas Google Cloud servicios.
  • Usas Gemini Enterprise, pero esperas mantenerte dentro de las limitaciones de grupo que impone tu IdP.
  • Tienes requisitos de residencia de datos que requieren minimizar el almacenamiento de información personal del usuario.

Arquitectura de la federación de identidades del personal, sin sincronización.

En este patrón, usas la federación de identidades de personal para federar tu Google Cloud organización con tu IdP externo.

Este patrón no requiere aprovisionamiento de usuarios ni de grupos. Cada vez que un usuario accede, el IdP pasa la información requerida sobre el usuario, incluidas las membresías de grupo y los atributos personalizados, a Google Cloud, y Google Cloud mantiene esa información solo durante la sesión del usuario.

Beneficios

  • No necesitas almacenar ni administrar cuentas de usuario o grupos en Google Cloud.
  • El patrón te permite usar conectores basados en la ingesta de datos para integrar Gemini Enterprise con Microsoft 365.

Limitaciones

  • La federación de identidades de personal es una función de IAM y solo permite que los usuarios accedan a los servicios que usan IAM. Los usuarios que se autentican con la federación de identidades de personal no pueden acceder a los servicios de Google, como Google Ads, Looker o Google Marketing Platform.
  • Los usuarios que se autentican con la federación de identidades de personal no pueden acceder a algunas Google Cloud funciones. Para obtener más detalles, consulta Federación de identidades: productos y limitaciones.
  • Muchos IdP limitan la cantidad de membresías de grupo que pueden pasar a la federación de identidades de personal en una aserción de SAML o un token de ID. Para mantenerte dentro de estos límites, es posible que debas fortalecer la administración de grupos y restringir los tipos de grupos que se incluirán en las aserciones o los tokens.
  • Cuando compartes recursos, como un cuaderno de NotebookLM Enterprise, no puedes buscar un grupo por nombre. En cambio, los usuarios deben ingresar sus identificadores de forma manual.

Si usas Microsoft Entra ID, puedes usar una variación de este patrón configurando atributos adicionales. Cuando configuras atributos adicionales, la federación de identidades de personal ejecuta una devolución de llamada a la API de Microsoft Graph durante la autenticación del usuario para recuperar las membresías de grupo. Esta configuración te permite superar los límites de pertenencia a un grupo de Entra para la aserción de SAML y los tokens de ID, y usar hasta 999 pertenencias a un grupo por usuario.

Federación de identidades de personal con SCIM

Selecciona este patrón cuando tu organización cumpla con los siguientes criterios:

  • Solo usas Google Cloud servicios. Es decir, no usas servicios externos de Google, como Google Ads o Google Maps.
  • Planeas usar Gemini Enterprise o NotebookLM Enterprise, y necesitas admitir hasta 2,000 membresías de grupo por usuario o la capacidad de buscar grupos por nombre cuando compartes recursos.

Arquitectura de la federación de identidades de personal con SCIM.

En este patrón, usas la federación de identidades de personal para federar tu Google Cloud organización. Para aumentar la cantidad de grupos que puedes usar para Gemini Enterprise, también configuras SCIM para aprovisionar información de pertenencia a un grupo con anticipación.

Beneficios

  • El patrón te permite usar conectores basados en la ingesta de datos para integrar Gemini Enterprise con Microsoft 365.
  • Puedes usar hasta 2,000 membresías de grupo por usuario para controlar el acceso a Gemini Enterprise y NotebookLM Enterprise, y permitir que los conectores basados en la ingesta de datos de Gemini Enterprise realicen verificaciones de acceso.
  • Cuando compartes recursos, como un cuaderno de NotebookLM Enterprise, puedes buscar grupos por nombre para mejorar la experiencia general del usuario.

Limitaciones

  • La compatibilidad con los grupos aprovisionados por SCIM se limita a Gemini Enterprise y NotebookLM Enterprise. Otros servicios solo pueden consumir las membresías de grupo que tu IdP pasa en la aserción de SAML o el token de ID.
  • La federación de identidades de personal es una función de IAM y solo permite que los usuarios accedan a los servicios que usan IAM. Los usuarios que se autentican con la federación de identidades de personal no pueden acceder a los servicios de Google, como Google Ads, Looker o Google Marketing Platform.
  • Los usuarios que se autentican con la federación de identidades de personal no pueden acceder a algunas de las Google Cloud funciones. Para obtener más detalles, consulta Federación de identidades: productos y limitaciones.

Federación de identidades de personal y Cloud Identity híbrida

Selecciona este patrón cuando tu organización cumpla con los siguientes criterios:

  • Usas servicios de Google más allá de Google Cloud (como Google Ads o Google Maps).
  • Planeas usar Gemini Enterprise y integrarlo con Microsoft 365.

Arquitectura de la federación híbrida de Cloud Identity y la federación de identidades de personal.

Este patrón combina dos de los patrones anteriores:

  • Usas la federación de identidades de personal (sin sincronización o con SCIM) para administrar el acceso a Gemini Enterprise y NotebookLM Enterprise.
  • Usas la federación de Cloud Identity o Google Workspace para administrar el acceso a otros servicios, incluidos Google Cloud y los servicios de Google que no son de la nube.

Beneficios

Este patrón te permite combinar los beneficios de los dos patrones anteriores:

  • Puedes conectar Gemini Enterprise a fuentes de datos de Microsoft sin limitaciones de funciones.
  • Los usuarios pueden autenticarse en los servicios de Google, independientemente de si esos servicios usan IAM o no.
  • Usa el conjunto completo de Google Cloud funciones.

Limitaciones

  • Debes mantener dos configuraciones de entidad emisora de confianza separadas en tu IdP externo: una para Cloud Identity y otra para la federación de identidades de personal.
  • Según si configuras un usuario para que use Cloud Identity o la federación de identidades de personal, su experiencia de acceso puede ser diferente.
  • Cuando administras políticas de permiso de IAM, debes usar diferentes identificadores principales según cómo se autentique un usuario. Por ejemplo, un usuario que se conoce como bob@example.com en tu IdP externo puede tener el identificador principal bob@example.com o principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID//subject/SUBJECT_ID en IAM, según si ese usuario se autentica con la federación de Cloud Identity o con la federación de identidades de personal.
  • No puedes crear grupos que contengan una combinación de usuarios de Cloud Identity y principales de la federación de identidades de personal. Los grupos de Cloud Identity solo pueden contener usuarios de Cloud Identity, y los grupos de identidades de personal solo pueden contener principales de la federación de identidades de personal.
  • Extender el uso de la federación de identidades de personal más allá de Gemini Enterprise puede requerir que los usuarios cambien entre identidades o que no estén seguros de cómo autenticarse.

¿Qué sigue?