Configura el proveedor de identidad

Para aplicar el control de acceso a la fuente de datos y proteger los datos en Gemini Enterprise, debes configurar un proveedor de identidad. Esto implica configurar el proveedor de identidad y administrar los permisos para tus fuentes de datos. Google usa tu proveedor de identidad para identificar al usuario final que realiza una búsqueda y determinar si tiene acceso a los documentos que se muestran como resultados.

Elige el tipo de proveedor de identidad

El tipo de proveedor de identidad que elijas dependerá de las fuentes de datos conectadas a tu app de Gemini Enterprise. Gemini Enterprise admite las siguientes opciones:

Tipo de proveedor de identidad Cuándo usar
Google Identity Google Identity es el proveedor de identidad recomendado para Gemini Enterprise.

Google Identity admite lo siguiente:
  • Todas las fuentes de datos de origen de Google que usan la transferencia de datos o la federación de datos. Debes usar Google Identity cuando te conectes a fuentes de datos de Google Workspace.
  • Todas las fuentes de datos de terceros que usan la federación de datos, en las que los usuarios se autentican directamente con el servicio de terceros a través de OAuth.
  • Todas las fuentes de datos externas que usan la transferencia de datos, con la excepción de las fuentes de datos de Microsoft 365, como SharePoint, OneDrive o Outlook, que requieren Microsoft Entra ID y la federación de identidades de personal.
Antes de configurar Google Identity, determina el atributo de usuario único que usa tu organización, que suele ser el correo electrónico del usuario. Si los usuarios tienen más de una dirección de correo electrónico, debes agregar un alias de correo electrónico.
Proveedor de identidad de terceros Cuando conectas Gemini Enterprise solo a fuentes de datos de terceros y ya usas un proveedor de identidad de terceros que admite OIDC o SAML 2.0, como Microsoft Entra ID, Okta o AD FS, puedes usar Google Identity o la federación de identidades de personal. Google recomienda usar Google Identity para las configuraciones nuevas. Los clientes existentes que ya usan la federación de identidades de personal pueden optar por seguir usándola. Para obtener más información, consulta federación de identidades de personal.

Antes de configurar la federación de identidades de personal, determina los atributos de usuario únicos que usa tu organización y asígnalos a la federación de identidades de personal.

Control de acceso para los conectores de Google Workspace

Cuando usas la búsqueda y la fundamentación de datos empresariales con conectores de Google Workspace (como Personas de Google Workspace o Grupos de Google), Gemini Enterprise respeta estrictamente las listas de control de acceso (LCA) y los permisos del sistema de origen.

Principio fundamental: No hay elevación de privilegios

Un usuario que interactúa con Gemini Enterprise solo puede ver y fundamentar las respuestas en la información a la que ya tiene autorización para acceder directamente en la aplicación de origen de Google Workspace. Gemini Enterprise nunca omite los controles de acceso del sistema fuente ni otorga permisos adicionales.

  • Personas de Google Workspace (Directorio): La visibilidad de los usuarios en los resultados de la búsqueda y de la fundamentación respeta la configuración de visibilidad del directorio de tu organización. Por ejemplo, si la visibilidad de un usuario en el directorio de Google Workspace se limita a su propio departamento o unidad organizativa, solo podrá encontrar a sus compañeros de ese departamento con Gemini Enterprise. No pueden ver los perfiles de los empleados de los departamentos restringidos.

  • Grupos de Google: El descubrimiento y la fundamentación del contenido se adhieren a la membresía del grupo y a la configuración de acceso. Un usuario solo puede buscar y ver contenido de los Grupos de Google de los que es miembro y tiene permiso para ver. Los usuarios que no son miembros no pueden descubrir ni ver conversaciones de grupos privados a través de Gemini Enterprise.

Dónde administrar los permisos

No configures los parámetros de configuración de visibilidad y control de acceso en la configuración del conector de Gemini Enterprise en la consola de Google Cloud . En cambio, un administrador de Google Workspace configura los parámetros de permiso, membresía y visibilidad en el sistema fuente:

  • Visibilidad del perfil del usuario: El administrador de Google Workspace configura la visibilidad del perfil del usuario en la Consola del administrador de Google. Para obtener más información, consulta Cómo configurar el uso compartido de directorios.

  • Acceso y membresía del grupo: El administrador de Google Workspace configura el acceso y la membresía del grupo en Grupos de Google o en la Consola del administrador de Google. Para obtener más información, consulta Configura y administra grupos.

Federación de identidades de personal para proveedores de identidad externos

En esta sección, se describe cómo configurar la federación de identidades de personal para proveedores de identidad externos. De manera opcional, puedes verificar si la configuración de la federación de identidades de personal funciona según lo previsto.

Configura la federación de identidades de personal

Para obtener detalles sobre la configuración de la federación de identidades de personal con tu conector de identidades externo, consulta los siguientes recursos:

Proveedor de identidad Recursos
Entra ID
Okta
OIDC o SAML 2.0

Configura la asignación de atributos

La asignación de atributos te ayuda a conectar tu información de identidad de terceros con Google a través de la federación de identidades de personal.

Cuando configures la asignación de atributos en la federación de identidades de personal, ten en cuenta lo siguiente:

  • El atributo google.subject se usa para la asignación de atributos, la asignación de licencias y el uso compartido de notebooks. Te recomendamos que asignes google.subject a la dirección de correo electrónico del usuario en minúsculas, ya que la asignación de licencias distingue mayúsculas de minúsculas.

  • Si tu organización tiene más de un identificador único, asigna estos atributos organizacionales únicos con el atributo attribute.as_user_identifier_number between 1 and 50.

    Por ejemplo, si tu organización usa tanto el correo electrónico como el nombre principal como identificadores de usuario en diferentes aplicaciones, y el nombre principal se establece como preferred_username en tu proveedor de identidad externo, puedes asignarlo a Gemini Enterprise con la asignación de atributos de la Federación de identidades de personal (por ejemplo, attribute.as_user_identifier_1=assertion.preferred_username).

En los siguientes ejemplos, se muestran las asignaciones de atributos requeridas para los proveedores de identidad comunes. Puedes agregar más asignaciones de atributos para admitir identificadores únicos adicionales, como se describió anteriormente.

  • Entra ID con protocolo OIDC
    En este ejemplo, se usa el correo electrónico para identificar a los usuarios de manera inequívoca.

    google.subject=assertion.email.lowerAscii()
google.groups=assertion.groups
google.display_name=assertion.given_name

  • Entra ID con protocolo SAML
    En este ejemplo, se usa el correo electrónico para identificar a los usuarios de manera inequívoca.

    google.subject=assertion.attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'][0].lowerAscii()
google.groups=assertion.attributes['http://schemas.microsoft.com/ws/2008/06/identity/claims/groups']
google.display_name=assertion.attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname'][0]

  • Okta con protocolo OIDC
    En este ejemplo, se usa el correo electrónico para identificar a los usuarios de manera inequívoca.

    google.subject=assertion.email.lowerAscii()
google.groups=assertion.groups

  • Okta con protocolo SAML
    En este ejemplo, se usa la aserción del sujeto del JWT para identificar de manera inequívoca a los usuarios.

    google.subject=assertion.subject.lowerAscii()
google.groups=assertion.attributes['groups']

Opcional: Verifica la configuración de la federación de identidades de personal

Para verificar que los accesos se hayan realizado correctamente y que la asignación de atributos sea correcta con la función de registro de auditoría de la federación de identidades de personal, haz lo siguiente:

  1. Habilita los registros de auditoría para la API de Security Token Service de la actividad de acceso a los datos.

    1. En la consola de Google Cloud , ve a la página Registros de auditoría:

      Ir a Registros de auditoría

      Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es IAM y administrador.

    2. Selecciona un Google Cloud proyecto, una carpeta o una organización existentes.
    3. Habilita todos los registros de auditoría de acceso a los datos
      1. Consulta la documentación de Logging para obtener los pasos detallados sobre cómo habilitar los registros de auditoría.
      2. Para la API de Security Token Service, selecciona el tipo de registro de auditoría Lectura de administración. Para obtener más información, consulta Registros de ejemplo para la federación de identidades de personal.

  2. Habilita el registro detallado en tu grupo de trabajadores. La función de grupos extendidos de la federación de identidades de personal para Microsoft Entra ID no genera información detallada de registro de auditoría.

    1. Ve a la página federación de identidades de personal.

      Ir a Grupos de identidades de personal

    2. En la tabla, elige el grupo.

    3. Haz clic en el botón de activación Habilitar el registro de auditoría detallado para llevarlo a la posición activada.

    4. Haz clic en Guardar grupo.

  3. En la sección Proveedores, haz clic en la URL de acceso de tu proveedor y accede a la consola de Google Cloud como usuario del grupo de personal.

  4. Consulta los registros de auditoría que se generaron cuando accediste.

    1. Ve a la página federación de identidades de personal.

      Ir a Grupos de identidades de personal

    2. En la tabla, selecciona el grupo en el que accediste.

    3. Haz clic en Ver junto a Registros.

    4. En la página del registro de auditoría, borra el filtro protoPayload.resourceName de la consulta.

    5. Haz clic en Ejecutar consulta.

  5. Verifica los registros de auditoría para encontrar una entrada con el método google.identity.sts.SecurityTokenService.WebSignIn que coincida con la marca de tiempo de acceso.

  6. Confirma que el campo metadata.mapped_attributes del registro coincida con el atributo que usaste cuando configuraste la federación de identidades de personal para proveedores de identidad de terceros.

    Por ejemplo:

    "metadata": {
  "mapped_attributes": {
    "attributes.as_user_identifier_1": "alex@admin.altostrat.com"
    "google.subject": "alex@altostrat.com"
    "google.groups": "[123abc-456d, efg-h789-ijk]"
  }
},

Limitaciones

Cuando conectas tus fuentes de datos con un conector para crear almacenes de datos, se aplican las siguientes limitaciones:

  • Se permiten 3,000 lectores por documento. Cada principal se considera un lector, y una principal puede ser un grupo o un usuario individual.

  • Puedes seleccionar un tipo de proveedor de identidad por ubicación admitida en Gemini Enterprise.

  • Si se actualiza la configuración del proveedor de identidad cambiando el tipo de proveedor de identidad o el grupo de personal, los almacenes de datos existentes no se actualizarán automáticamente con la nueva configuración. Debes borrar y volver a crear estos almacenes de datos para aplicar la nueva configuración de identidad.

  • Para establecer una fuente de datos como controlada por acceso, debes seleccionar este parámetro de configuración durante la creación del almacén de datos. No puedes activar ni desactivar este parámetro de configuración para un almacén de datos existente.

  • Para obtener una vista previa de los resultados de la IU de las apps de búsqueda que usan el control de acceso de terceros, debes acceder a la consola federada o usar la app web. Consulta Obtén una vista previa de tu app.

Conéctate a tu proveedor de identidad

En la siguiente sección, se describe cómo conectarte a tu proveedor de identidad con la consola deGoogle Cloud .

Antes de comenzar

Antes de conectar el proveedor de identidad, haz lo siguiente:

  • Otorga permisos a los administradores.

  • Si conectas un proveedor de identidad externo con la federación de identidades de personal, configura la federación de identidades de personal.

Conecta un proveedor de identidad

Para especificar un proveedor de identidad para Gemini Enterprise y activar el control de acceso a la fuente de datos, sigue estos pasos:

  1. En la consola de Google Cloud , ve a la página Gemini Enterprise.

    Gemini Enterprise

  2. Haz clic en Configuración > Autenticación.

  3. Haz clic en Agregar proveedor de identidad para la ubicación que deseas actualizar.

  4. Haz clic en Agregar proveedor de identdad y selecciona el tipo de proveedor de identidad.
    Si seleccionas Identidad de terceros, también debes seleccionar el grupo de personal que se aplica a tus fuentes de datos.

  5. Haz clic en Guardar cambios.

Otorga permisos a los usuarios

Los usuarios necesitan el rol de Usuario de Gemini Enterprise (roles/discoveryengine.agentspaceUser) para acceder a las apps, administrarlas y compartirlas.

Tipo de proveedor de identidad Descripción
Google Identity
  • Si usas Google Identity, Google recomienda crear un Grupo de Google que incluya a todos los empleados que usan la app.
  • Si eres administrador de Google Workspace, puedes incluir a todos los usuarios de una organización en un grupo de Google siguiendo los pasos que se indican en Agrega a todos los usuarios de tu organización a un grupo.
  • Otorga el rol de Usuario de Gemini Enterprise (roles/discoveryengine.agentspaceUser) a los usuarios. Para obtener más información sobre cómo agregar el rol, consulta Otorga permisos a tus usuarios.
Proveedor de identidad de terceros

Impacto de los cambios en la configuración del proveedor de identidad en los conectores de transferencia de datos

Cuando cambias la configuración de identidad, como el proveedor de identidad o el grupo de federación de identidades de personal, los almacenes de datos existentes que usan la transferencia de datos no se actualizan automáticamente. Para aplicar la nueva configuración de identidad, debes borrar y volver a crear los almacenes de datos afectados.

En la siguiente tabla, se resumen los cambios en la configuración de identidad que requieren volver a crear el almacén de datos:

Tipo de cambio Requiere volver a crear el almacén de datos
Cambiar entre Google Identity y un proveedor de identidad externo Sí
Cambiar por completo a un nuevo grupo de federación de identidades de personal Sí
Editar la asignación de atributos en el proveedor de identidad actual No
Cambiar a un proveedor nuevo dentro del mismo grupo de federación de identidades de personal. Por ejemplo, usar Entra en lugar de Okta No

Cambios en la identidad del usuario

Gemini Enterprise asocia el historial de chat, los notebooks y los agentes que crea el usuario con el identificador principal del usuario. Si usas la federación de identidades de personal, el identificador de la principal incluye el valor que tu asignación de atributos asigna a google.subject. Por ejemplo:

principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE

Impacto de un cambio en el valor del sujeto

Si el valor asignado a google.subject cambia para un usuario, Gemini Enterprise lo trata como un usuario nuevo. Por ejemplo, esto sucede cuando el nombre principal de usuario (UPN) o la dirección de correo electrónico del usuario cambian en Microsoft Entra ID y tu asignación de atributos usa ese atributo. Los identificadores principales distinguen mayúsculas de minúsculas, por lo que un cambio en el uso de mayúsculas y minúsculas también es un cambio.

Después del cambio, se aplica lo siguiente:

  • El usuario no puede acceder al historial de chat, los notebooks ni los agentes que están asociados con el identificador de principal anterior.
  • Gemini Enterprise no migra datos del identificador de principal anterior al nuevo.
  • Las licencias y los roles de IAM que se otorgan al identificador de principal anterior no se aplican al identificador de principal nuevo.

Prepárate para un cambio de valor del asunto

Para reducir el impacto de un cambio en el valor del asunto, haz lo siguiente:

  • Antes de cambiar el UPN o la dirección de correo electrónico de un usuario en tu proveedor de identidad, infórmale al usuario y pídele que comparta los agentes privados o los notebooks que quiera conservar.
  • Asigna una licencia de Gemini Enterprise al nuevo identificador de principal y otórgale los roles necesarios. Para obtener más información, consulta Otorga permisos a los usuarios.
  • Transfiere la propiedad de los agentes que el usuario compartió con otros al nuevo identificador principal. No puedes transferir la propiedad de los agentes que no se comparten.

Soluciona problemas de autenticación

Si los usuarios reciben errores de HTTP 401 que informan credenciales de autenticación no válidas cuando acceden a Gemini Enterprise, verifica lo siguiente.

Verificaciones básicas

  • Estado del navegador: Pídele al usuario que borre la caché y las cookies del navegador, o que acceda desde una ventana de incógnito o de navegación privada.
  • Cuenta con la que se accedió: Asegúrate de que el usuario acceda con la cuenta que espera la configuración de tu proveedor de identidad. Si usas la federación de identidades de personal, la identidad del usuario debe coincidir con tu asignación de atributos.
  • Reloj del dispositivo: Asegúrate de que el reloj del dispositivo esté sincronizado, por ejemplo, con el protocolo NTP. La desviación del reloj en el dispositivo puede provocar que falle la autenticación.

Políticas de red y del proveedor de identidad

  • Proxies y firewalls: Los proxies, los firewalls o las puertas de enlace web seguras que inspeccionan el tráfico de TLS pueden quitar o cambiar el encabezado Authorization. Asegúrate de que estos dispositivos no modifiquen las solicitudes a los dominios de Google.
  • Políticas de acceso del proveedor de identidad: Verifica si las políticas de acceso de tu proveedor de identidad, como las políticas de acceso condicional en Microsoft Entra ID, bloquean el acceso debido al cumplimiento del dispositivo, los rangos de direcciones IP o la ubicación.
  • Acceso adaptado al contexto: Si tu organización usa el Acceso adaptado al contexto con Google Cloud o Google Workspace, verifica si un nivel de acceso basado en IP bloquea las solicitudes que Gemini Enterprise realiza en nombre del usuario. Estas solicitudes se originan en los servidores de Google, no en la red del usuario, por lo que no coinciden con los rangos de IP corporativos. Agrega un nivel de acceso que permita el ID de cliente de OAuth 2.0 que usa Gemini Enterprise, combinado con el nivel de acceso basado en IP como una condición OR. Las solicitudes rechazadas aparecen en los registros de auditoría de tu organización para contextawareaccess.googleapis.com.
  • Resolución de DNS: Asegúrate de que tus solucionadores de DNS resuelvan correctamente los dominios de Google, incluidos *.google.com y *.googleapis.com.

Recopila información de diagnóstico

Si el error persiste, captura un archivo HAR (archivo HTTP) y los registros de la consola del navegador mientras reproduces el error y, luego, comunícate con Atención al cliente de Cloud. Los archivos HAR pueden contener información sensible, como cookies y tokens.

Próximos pasos