Evalúa el impacto de la consolidación de las cuentas de usuario en la federación

Last reviewed 2024-07-11 UTC

Si planeas federar Cloud Identity o Google Workspace con un proveedor de identidad externo (IdP), pero aún debes consolidar las cuentas personales existentes, este documento te ayudará a comprender y evaluar la interacción entre la federación y la consolidación. En este documento, también se muestra cómo configurar la federación de una manera que no interfiera en la capacidad de consolidar las cuentas personales existentes.

Interacción entre la federación y la consolidación de cuentas de usuario

En una configuración federada, conectas Cloud Identity o Google Workspace a una fuente autorizada externa para que la fuente autorizada pueda aprovisionar de forma automática cuentas de usuario en Cloud Identity o Google Workspace.

Por lo general, estas variantes son válidas para una configuración federada:

  1. La fuente autorizada es la única fuente de identidades.
  2. No hay cuentas de usuario en Cloud Identity ni en Google Workspace que no sean las que aprovisiona la fuente autorizada.
  3. El proveedor de identidad SAML no permite el inicio de sesión único de Google para ninguna identidad distinta de aquellas a las que la fuente autorizada aprovisionó cuentas de usuario.

Si bien estas variables reflejan las prácticas recomendadas para federar Google Cloud con un proveedor de identidad externo, causan problemas cuando deseas migrar cuentas personales existentes:

  1. Las cuentas personales existentes no se originan en la fuente autorizada. Estas cuentas ya existen y ahora deben vincularse a una identidad conocida por la fuente autorizada.
  2. Las cuentas personales existentes, una vez que migran a Cloud Identity o Google Workspace, son cuentas de usuario que la fuente autorizada no aprovisionó. La fuente autorizada debe reconocer y “adoptar” estas cuentas migradas.
  3. Es posible que el proveedor de identidad de SAML no conozca las identidades de las cuentas personales existentes, pero aún se les debe permitir el uso del inicio de sesión único.

Para permitir que se consoliden las cuentas personales existentes, debes configurar de forma temporal la federación de una manera que sea segura para la consolidación de cuentas.

Haz que la federación sea segura para la consolidación de cuentas

En la siguiente tabla, se enumeran los requisitos que se deben tener en cuenta a fin de que la federación sea segura para la consolidación de cuentas. Si planeas usar un IdP externo, pero aún necesitas consolidar las cuentas personales existentes, debes asegurarte de que la configuración cumpla en un principio con estos requisitos. Después de completar la migración de cuentas personales existentes, puedes cambiar la configuración porque los requisitos ya no se mantienen.

Requisito Justificación
Permitir el inicio de sesión único para las identidades con cuentas personales La migración de una cuenta personal requiere una transferencia de cuenta. Un administrador de Cloud Identity o Google Workspace inicia la transferencia de la cuenta, pero para completar la transferencia, el propietario de la cuenta personal debe dar su consentimiento para la transferencia. Como administrador, tienes un control limitado sobre cuándo se expresará el consentimiento y, por lo tanto, cuándo se realizará la transferencia.

Una vez que el propietario exprese su consentimiento y se complete la transferencia, todos los accesos posteriores estarán sujetos al inicio de sesión único mediante el IdP externo.

A fin de que el inicio de sesión único sea exitoso, sin importar cuándo se complete la transferencia, asegúrate de que tu IdP externo permita el inicio de sesión único para las identidades de todas las cuentas personales que planeas migrar.

Evitar el aprovisionamiento automático de usuarios para las identidades con cuentas personales Si aprovisionas una cuenta de usuario para una identidad que ya tiene una cuenta personal, creas una cuenta en conflicto. Una cuenta en conflicto te impide transferir la propiedad de la cuenta personal, su configuración y los datos asociados a Cloud Identity o Google Workspace.

El comportamiento predeterminado de muchos IdP externos es crear cuentas de usuario de forma proactiva en Cloud Identity o Google Workspace. Este comportamiento puede causar que, por accidente, se creen cuentas en conflicto.

Para evitar la creación accidental de cuentas en conflicto y garantizar que las cuentas personales se transfieran de forma correcta, evita el aprovisionamiento automático de usuarios para las identidades con cuentas personales existentes.

Si identificaste cuentas personales sin una identidad coincidente en el IdP externo que consideras legítimas y que deseas migrar a Cloud Identity o Google Workspace, debes asegurarte de que la configuración de la federación no interfiera en tu capacidad para migrar estas cuentas personales.

Requisito Justificación
Evitar la eliminación de cuentas migradas sin una identidad coincidente en el IdP externo Si tienes una cuenta de usuario en Cloud Identity o Google Workspace que no tiene una identidad coincidente en tu IdP externo, entonces tu IdP podría considerar esta cuenta de usuario huérfala y borrarla o borrarla.

Para evitar perder la configuración y los datos asociados con las cuentas afectadas y asegurarte de que puedas conciliar las cuentas de forma manual, evita que el IdP externo suspenda o borre cuentas migradas sin una identidad coincidente en el IdP externo.

Haz que la federación de Microsoft Entra ID (antes Azure AD) sea segura para la consolidación de cuentas

Si planeas federar Cloud Identity o Google Workspace con el ID de Microsoft Entra (antes Azure AD), puedes usar la App de galería de Google Workspace.

Cuando habilitas el aprovisionamiento, el ID de Microsoft Entra ignora las cuentas existentes en Cloud Identity o Google Workspace, que no tienen un equivalente en el ID de Microsoft Entra, por lo que el requisito para evitar la eliminación de cuentas migradas sin una identidad coincidente en el IdP externo siempre se cumple.

Según cómo configures la app de galería, debes asegurarte de hacer lo siguiente:

Existen varias formas de cumplir con estos requisitos. Cada enfoque tiene sus ventajas y desventajas.

Enfoque 1: No configurar el aprovisionamiento

En este enfoque, debes configurar la app de galería para que maneje el inicio de sesión único, pero no debes configurar el aprovisionamiento automático de usuarios. Si no configuras el aprovisionamiento de usuarios, impides el aprovisionamiento automático de usuarios para las identidades con cuentas personales.

Para permitir el inicio de sesión único para las identidades con cuentas personales, asigna la app a todas las identidades que podrían necesitar acceso a los servicios de Google, incluso si las cuentas personales existentes aún están sujetas a migración.

Para un usuario que tiene una cuenta de consumidor existente, la cuenta de usuario de Cloud Identity o Google Workspace correspondiente se crea de forma automática cuando se acepta la solicitud de transferencia. Ese usuario puede usar el inicio de sesión único de inmediato.

Para los usuarios que no tienen una cuenta de usuario en Cloud Identity o Google Workspace, debes crear una de forma manual.

Aunque este enfoque cumple con los requisitos y es el menos complejo para configurarse, viene con la limitación de que los cambios de atributos o las suspensiones de usuarios realizados en Microsoft Entra ID no se propagarán a Cloud Identity ni a Google Workspace.

Enfoque 2: Dos apps con asignación manual

En este enfoque, se supera el límite de tener que crear cuentas de usuario de forma manual en Google Workspace o Cloud Identity para los usuarios que no tienen una cuenta existente. La idea es usar dos apps de galería, una para el aprovisionamiento y otra para el inicio de sesión único:

  • La primera app se usa de forma exclusiva para aprovisionar usuarios y grupos y tiene inhabilitado el inicio de sesión único. Puedes asignar usuarios a esta app para controlar qué cuentas se aprovisionan en Cloud Identity o Google Workspace.
  • La segunda app se usa de forma exclusiva para el inicio de sesión único y no está autorizada para aprovisionar usuarios. Puedes asignar usuarios a esta app para controlar qué usuarios pueden acceder.

Usa estas dos apps para asignar usuarios de la siguiente manera:

Enfoque 3: Dos apps con la creación de usuarios inhabilitada

Cuando configuras el aprovisionamiento, debes autorizar el ID de Microsoft Entra para acceder a Cloud Identity o a Google Workspace a través de una cuenta de Cloud Identity o de Google Workspace. Por lo general, es mejor usar una cuenta de administrador avanzado para este fin, ya que, estas cuentas están exentas del inicio de sesión único (es decir, ninguna configuración del SSO se aplica a ellas, seguirán usando contraseñas para el acceso).

Sin embargo, en esta situación, puedes hacer que Microsoft Entra ID use una cuenta más restringida para la migración; una que no permita que Microsoft Entra ID cree usuarios. De esta manera, evitas que Azure aprovisione cuentas de usuario de forma automática para las identidades con cuentas personales, sin importar los usuarios que estén asignados a la app de aprovisionamiento.

Una cuenta de usuario de administrador restringida en Cloud Identity o Google Workspace solo debe tener los siguientes privilegios:

  • Unidades organizativas > Lectura
  • Usuarios > Lectura
  • Usuarios > Actualización
  • Grupos

Una desventaja de este enfoque es que, para los usuarios sin cuentas no administradas, debes crear cuentas de forma manual en Cloud Identity o Google Workspace.

Comparación de federaciones con Microsoft Entra ID

En la siguiente tabla, se resumen los enfoques.

Permitir el inicio de sesión único para las identidades con cuentas personales Evitar el aprovisionamiento automático de usuarios para las identidades con cuentas personales Evitar la eliminación de cuentas migradas sin una identidad coincidente en el IdP externo Aprovisionamiento automático de cuentas nuevas Actualización automática de las cuentas migradas
Enfoque 1: Sin aprovisionamiento X X
Enfoque 2: Dos apps con asignación manual Propenso a errores manuales
Enfoque 3: Dos apps con la creación de usuarios inhabilitada X

Haz que la federación de Active Directory sea segura para la cuenta

Si planeas federar Cloud Identity o Google Workspace con Active Directory, puedes usar Google Cloud Directory Sync (GCDS) y los Servicios de federación de Active Directory (AD FS). Cuando configuras GCDS y AD FS, debes asegurarte de hacer lo siguiente:

Existen varias formas de cumplir con estos requisitos. Cada enfoque tiene sus ventajas y desventajas.

Enfoque 1: Inhabilita GCDS

En este enfoque, debes configurar el inicio de sesión único con AD FS, pero no habilitas GCDS hasta que terminas de migrar las cuentas de usuario no administradas. Si inhabilitas GCDS, evitarás el aprovisionamiento automático de usuarios para las identidades con cuentas personales.

Para permitir el inicio de sesión único para las identidades con cuentas personales, crea una política de control de acceso personalizada en AD FS y asigna todas las identidades que podrían necesitar acceso a los servicios de Google, incluso si sus cuentas personales existentes todavía están sujetas a migración.

Para un usuario que tiene una cuenta de consumidor existente, la cuenta de usuario de Cloud Identity o Google Workspace correspondiente se crea de forma automática cuando se acepta la solicitud de transferencia. Cuando uses la política de control de acceso personalizado, te asegurarás de que el usuario pueda usar el inicio de sesión único de inmediato.

Para los usuarios que no tienen una cuenta de usuario en Cloud Identity o Google Workspace, debes crear una de forma manual.

Aunque este enfoque cumple con los requisitos y es el más fácil de configurar, viene con la limitación de que los cambios de atributos o las suspensiones de usuarios realizados en Active Directory no se propagarán a Cloud Identity ni a Google Workspace.

Enfoque 2: GCDS con asignación manual

En este enfoque, superas la limitación de tener que crear de forma manual cuentas de usuario en Cloud Identity o Google Workspace para los usuarios que no tienen una cuenta:

Una limitación clave de este enfoque es que no puedes evitar la eliminación de cuentas migradas sin una identidad coincidente en el IdP externo. Por lo tanto, el enfoque solo se aplica si no tienes ninguna cuenta personal sin una identidad coincidente en el IdP externo.

Enfoque 3: No permitir que GCDS cree usuarios

Cuando configures el aprovisionamiento, debes autorizar a GCDS para que acceda a Cloud Identity o Google Workspace. Por lo general, es mejor usar una cuenta de administrador avanzado para este fin, ya que, estas cuentas están exentas del inicio de sesión único (es decir, ninguna configuración del SSO se aplica a ellas y siguen usando contraseñas para el acceso).

Sin embargo, en esta situación, puedes hacer que GCDS use una cuenta más restringida para la migración; una que no permita que cree usuarios. De esta manera, evitas que GCDS aprovisione de forma automática las cuentas de usuario para las identidades con cuentas personales y borre las cuentas migradas sin una identidad coincidente en el IdP externo.

Una cuenta de usuario de administrador restringida en Cloud Identity o Google Workspace solo debe tener los siguientes privilegios:

  • Unidades organizativas
  • Usuarios > Lectura
  • Usuarios > Actualización
  • Grupos
  • Administración del esquema
  • Administración de dominios

Una desventaja de este enfoque es que, para los usuarios sin cuentas no administradas, debes crear cuentas de forma manual en Cloud Identity o Google Workspace.

Comparación de la integración con Active Directory

En la siguiente tabla, se resumen los enfoques.

Permitir el inicio de sesión único para las identidades con cuentas personales Evitar el aprovisionamiento automático de usuarios para las identidades con cuentas personales Evitar la eliminación de cuentas migradas sin una identidad coincidente en el IdP externo Aprovisionamiento automático de cuentas nuevas Actualización automática de las cuentas migradas
Enfoque 1: No configurar el aprovisionamiento X X
Enfoque 2: GCDS con asignación manual Propenso a errores manuales X
Enfoque 3: No permitir que GCDS cree usuarios X

Haz que la federación de Okta sea segura para la consolidación de cuentas

Para federar Cloud Identity o Google Workspace con Okta, puedes usar la app de Google Workspace del catálogo de apps de Okta. Esta app puede controlar el inicio de sesión único y aprovisionar a los usuarios y grupos en Cloud Identity o Google Workspace.

Cuando usas la app de Google Workspace para el aprovisionamiento, Okta ignora a los usuarios existentes en Cloud Identity o Google Workspace que no tienen un equivalente en Okta, por lo que el requisito de evitar la eliminación de las cuentas migradas sin una identidad coincidente en el IdP externo siempre se cumple.

Según cómo configures Okta, aún debes hacer lo siguiente:

Existen varias formas de cumplir con estos requisitos. Cada enfoque tiene sus ventajas y desventajas.

Enfoque 1: No configurar el aprovisionamiento

En este enfoque, configuras la app de Google Workspace para controlar el inicio de sesión único, pero no configuras el aprovisionamiento. Si no configuras el aprovisionamiento de usuarios, impides el aprovisionamiento automático de usuarios para las identidades con cuentas personales.

Para permitir el inicio de sesión único para las identidades con cuentas personales, asigna la app a todas las identidades que podrían necesitar acceso a los servicios de Google, incluso si las cuentas personales existentes aún están sujetas a migración. Los íconos de Google Workspace o Google Cloud aparecen en la página principal de Okta de todas las identidades que se asignaron a la app. Sin embargo, el acceso fallará, a menos que exista una cuenta de usuario correspondiente del lado de Google.

Para un usuario que tiene una cuenta de consumidor existente, la cuenta de usuario de Cloud Identity o Google Workspace correspondiente se crea de forma automática cuando se acepta la solicitud de transferencia. Ese usuario puede usar el inicio de sesión único de inmediato.

Aunque este enfoque cumple con los requisitos y es el más fácil de configurar, viene con la limitación de que los cambios de atributos o las suspensiones de usuarios realizados en Okta no se propagarán a Cloud Identity ni a Google Workspace. Otra desventaja de este enfoque es que debes crear cuentas de forma manual en Cloud Identity o Google Workspace para todos los usuarios que no tengan una cuenta personal existente.

Enfoque 2: Aprovisionamiento con asignación manual

En este enfoque, configuras la aplicación de Google Workspace para controlar el inicio de sesión único y el aprovisionamiento, pero solo habilitar las siguientes funciones de aprovisionamiento:

  • Crear usuarios
  • Actualizar los atributos del usuario
  • Desactivar usuarios

Cuando asignes identidades a la app, incluye las identidades que en algún momento necesitarán acceso a los servicios de Google, pero excluye todas las identidades que tengan una cuenta personal. De esta manera, evitas el aprovisionamiento automático de usuarios para las identidades con cuentas personales.

Apenas un usuario acepta una solicitud de transferencia, asígnale el usuario a la aplicación para que pueda acceder con inicio de sesión único y acceder a Google Workspace o Google Cloud.

Una desventaja de este enfoque es que cualquier error que cometas en la asignación puede generar una cuenta en conflicto, lo que hace que este enfoque sea mucho más riesgoso que otros.

Otra desventaja de este enfoque es que genera bloqueos temporales de cuentas migradas. Después de aceptar una solicitud de transferencia, los usuarios deben realizar cualquier acceso posterior a través de Okta. Estos intentos de acceso fallarán hasta que hayas asignado al usuario a la app en Okta.

Enfoque 3: Aprovisionamiento con la creación de usuarios inhabilitada

En este enfoque, configuras Google Workspace para controlar el inicio de sesión único y el aprovisionamiento, pero solo habilitar las siguientes funciones de aprovisionamiento:

  • Actualizar los atributos del usuario
  • Desactivar usuarios

Deja inhabilitada la opción Crear usuarios y asigna a la app todas las identidades que en algún momento necesitarán acceso a los servicios de Google. Incluye identidades con cuentas personales existentes para permitir el inicio de sesión único para las identidades con cuentas personales.

Al no permitir que Okta cree cuentas, evitas que Okta aprovisione cuentas de usuario de forma automática para las identidades con cuentas personales. Al mismo tiempo, esta configuración permite que Okta propague cambios de atributos y suspensiones de usuarios a Cloud Identity o Google Workspace para aquellos usuarios que tengan una Cuenta de Google correspondiente.

En el caso de las identidades que no tienen una cuenta de usuario correspondiente en Cloud Identity o Google Workspace, Okta podría mostrar un mensaje de error en la Consola del administrador de Okta:

Mensaje de error de Okta.

Para un usuario que tiene una cuenta de consumidor existente, la cuenta de usuario de Cloud Identity o Google Workspace correspondiente se crea de forma automática cuando se acepta la solicitud de transferencia. Ese usuario puede usar el inicio de sesión único de inmediato. Aunque la cuenta de usuario funciona en este momento, es posible que Okta aún no muestre un ícono en la página principal del usuario y, en su lugar, continúe mostrando el mensaje de error en la IU para administrar. Para solucionar este problema, vuelve a realizar la tarea de asignación en el Panel del administrador de Okta.

Este enfoque evita con éxito que Okta aprovisione cuentas de usuario de forma automática para las identidades con cuentas personales, pero permite el inicio de sesión único para las identidades con cuentas personales. El enfoque también es menos propenso a una configuración incorrecta accidental que el segundo enfoque. Una desventaja es que, para los usuarios sin cuentas de consumidor existentes, debes crear cuentas de usuario de forma manual en Cloud Identity o Google Workspace.

Enfoque 4: Dos apps con asignación manual

Puedes superar algunas de las desventajas de los enfoques anteriores a través del uso de dos apps, una para el aprovisionamiento y otra para el inicio de sesión único:

  • Configura una instancia de la app de Google Workspace para que solo administre el aprovisionamiento. No se usa la funcionalidad de inicio de sesión único de la app. Puedes asignar usuarios a esta app para controlar qué cuentas se aprovisionan en Cloud Identity o Google Workspace. Para asegurarte de que esta app esté oculta de manera eficaz para los usuarios, habilita la opción No mostrar el ícono de la aplicación a los usuarios.
  • Configura otra instancia de la app de Google Workspace solo con fines de inicio de sesión único. Puedes asignar usuarios a esta app para controlar quién puede acceder.

Usa estas dos apps para asignar usuarios de la siguiente manera:

Comparación de federaciones con Okta

En la siguiente tabla, se resumen los enfoques.

Permitir el inicio de sesión único para las identidades con cuentas personales Evitar el aprovisionamiento automático de usuarios para las identidades con cuentas personales Evitar la eliminación de cuentas migradas sin una identidad coincidente en el IdP externo Aprovisionamiento automático de cuentas nuevas Actualización automática de las cuentas migradas
Enfoque 1: Sin aprovisionamiento X X
Enfoque 2: Aprovisionamiento con asignación manual X Riesgoso
Enfoque 3: Aprovisionamiento con la creación de usuarios inhabilitada X
Enfoque 4: Dos apps con asignación manual Riesgoso

¿Qué sigue?