En vSphere 7.0 o versiones posteriores, vCenter Server admite la autenticación federada para iniciar sesión en vCenter Server.
Para habilitar la autenticación federada en vCenter Server, debe configurar una conexión con un proveedor de identidad externo. La instancia del proveedor de identidad que se configura reemplaza a vCenter Server como el proveedor de identidad. Actualmente, vCenter Server solo admite los servicios de federación de Active Directory (Active Directory Federation Services, AD FS) y Okta como proveedores de identidad externos. vCenter Server admite AD FS en vSphere 7.0 y versiones posteriores, y Okta a partir de vSphere 8.0 Update 1.
Cómo funciona la federación de proveedores de identidad de vCenter Server
La federación de proveedores de identidad de vCenter Server le permite configurar un proveedor de identidad externo para autenticación federada. En esta configuración, el proveedor de identidad externo interactúa con el origen de identidad en nombre de vCenter Server.
Conceptos básicos de la federación de proveedores de identidad de vCenter Server
En vSphere 7.0 y versiones posteriores, vCenter Server admite la autenticación federada. En este escenario, cuando un usuario inicia sesión en vCenter Server, vCenter Server redirecciona el inicio de sesión del usuario al proveedor de identidad externo. Ya no se proporcionan las credenciales de usuario directamente a vCenter Server. En su lugar, el usuario proporciona las credenciales al proveedor de identidad externo. vCenter Server confía en el proveedor de identidad externo para realizar la autenticación. En el modelo de federación, los usuarios nunca proporcionan credenciales directamente a ningún servicio ni aplicación, sino solo al proveedor de identidad. Como resultado, con el proveedor de identidad puede "federar" las aplicaciones y los servicios, como vCenter Server.
Compatibilidad con proveedores de identidad externos de vCenter Server
vCenter Server admite los siguientes proveedores de identidad externos:
- AD FS (vSphere 7.0 y versiones posteriores)
- Okta (a partir de vSphere 8.0 Update 1)
Ventajas de la federación de proveedores de identidad de vCenter Server
La federación de proveedores de identidad de vCenter Server proporciona las siguientes ventajas.
- Puede utilizar Single Sign-On con las aplicaciones y la infraestructura federada existentes.
- Puede mejorar la seguridad del centro de datos porque vCenter Server no controla nunca las credenciales del usuario.
- Puede utilizar mecanismos de autenticación, como la autenticación multifactor, compatible con el proveedor de identidad externo.
Arquitectura de la federación de proveedores de identidad de vCenter Server
Para establecer una relación de confianza para usuario autenticado entre vCenter Server y un proveedor de identidad externo, como AD FS u Okta, debe establecer la información de identificación y un secreto compartido entre ellos. vCenter Server usa el protocolo OpenID Connect (OIDC) para recibir un token de identidad que autentique al usuario con vCenter Server.
Los pasos detallados para configurar un proveedor de identidad externo con vCenter Server incluyen:
- Establecer una confianza de usuario autenticado entre vCenter Server y el proveedor de identidad externo mediante la creación de una configuración de OIDC. Para AD FS, cree un grupo de aplicaciones o una aplicación. Para Okta, cree una aplicación nativa de Okta con OpenID Connect como método de inicio de sesión. La configuración de OIDC consta de una aplicación de servidor y una API de Web. Los dos componentes especifican la información que vCenter Server usa para confiar y comunicarse con el proveedor de identidad externo.
- Crear un proveedor de identidad correspondiente en vCenter Server.
- Configurar la pertenencia a grupos en vCenter Server para autorizar el inicio de sesión de usuarios en el dominio del proveedor de identidad externo.
El administrador del proveedor de identidad debe proporcionar la siguiente información para crear la configuración del proveedor de identidad de vCenter Server:
- Identificador de cliente: la cadena UUID que se genera en AD FS al crear el grupo de aplicaciones (o la aplicación) y que identifica al grupo de aplicaciones (o la aplicación), o bien que se genera en Okta al crear la aplicación OpenID Connect.
- Secreto compartido: el secreto que se genera en AD FS al crear el grupo de aplicaciones (o la aplicación) o que se genera en Okta al crear la aplicación de OpenID Connect y que se utiliza para autenticar vCenter Server con el proveedor de identidad externo.
- Dirección de OpenID: la dirección URL del endpoint de detección de proveedores de OpenID correspondiente al servidor del proveedor de identidad externo, que especifica una dirección conocida que suele ser el endpoint del emisor concatenado con la ruta de acceso
/.well-known/openid-configuration. A continuación se muestra un ejemplo de dirección de OpenID para una configuración de AD FS:https://webserver.example.com/adfs/.well-known/openid-configuration
Del mismo modo, a continuación se muestra un ejemplo de dirección de OpenID para una configuración de Okta:https://example.okta.com/oauth2/default/.well-known/openid-configuration
VMware Identity Services y autenticación federada
A partir de vSphere 8.0 Update 1, VMware Identity Services proporciona integración con Okta como proveedor de identidad federado. Puede pensar en la VMware Identity Services como una versión "reducida" de VMware Workspace ONE que está integrada en vSphere.
Al instalar o actualizar a vSphere 8.0 Update 1, VMware Identity Services se activa de forma predeterminada en vCenter Server. Al configurar Okta como proveedor de identidad externo, vCenter Server utiliza VMware Identity Services para comunicarse con el servidor Okta.
vCenter Server admite Okta como proveedor de identidad externo en una configuración de Enhanced Linked Mode. A pesar de que, en este tipo de configuración, varios sistemas vCenter Server ejecutan VMware Identity Services, solo una instancia de vCenter Server y su instancia de VMware Identity Services se comunican con el servidor Okta. Por ejemplo, si tiene una configuración de Enhanced Linked Mode de tres sistemas vCenter Server (A, B y C) y configura el proveedor de identidad de Okta en vCenter Server A, vCenter Server A es el único sistema que controla todos los inicios de sesión de Okta. vCenter Server B y vCenter Server C no se comunican directamente con el servidor Okta.
Proceso de autenticación de Okta
Al configurar vCenter Server para utilizar VMware Identity Services a fin de comunicarse con el servidor Okta, se produce el siguiente proceso de autenticación:
- Un usuario inicia sesión en vCenter Server con vSphere Client.
- vCenter Single Sign-On delega la autenticación del usuario y redirecciona la solicitud de usuario a VMware Identity Services.
- El proceso de VMware Identity Services solicita un token del proveedor de identidad externo de Okta para establecer la sesión de usuario.
- El proveedor de identidad de Okta autentica al usuario (puede usar la autenticación multifactor [MFA] o las credenciales de SSO) y devuelve el token a VMware Identity Services.
El token contiene las notificaciones de usuario.
- El proceso de VMware Identity Services valida el token del proveedor de identidad de Okta, genera un token de VMware Identity Services correspondiente y lo envía a vCenter Single Sign-On.
- vCenter Single Sign-On valida el token y concede la solicitud de inicio de sesión.
Cómo interactúa vCenter Server con usuarios y grupos de Okta
Al configurar Okta como proveedor de identidad externo, vCenter Server utiliza el sistema para la administración de identidades entre dominios (SCIM) a fin de administrar usuarios y grupos. SCIM es un estándar abierto para automatizar el intercambio de información de identidad de usuario. Una aplicación de SCIM que crea en el servidor de Okta administra los usuarios y los grupos en Okta que desea insertar en vCenter Server. vCenter Server también utiliza SCIM al buscar usuarios y grupos para asignar permisos a objetos de vCenter Server.
Componentes de la federación de proveedores de identidad de vCenter Server
Los siguientes componentes incluyen una configuración de federación de proveedores de identidad de vCenter Server:
- Un vCenter Server
- Para AD FS: vCenter Server 7.0 o versiones posteriores
- Para Okta: vCenter Server 8.0 Update 1
- Un servicio de proveedor de identidad configurado en vCenter Server
- Un proveedor de identidad externo (AD FS u Okta)
- Una configuración de OpenID Connect (OIDC):
- Para AD FS: un grupo de aplicaciones (también denominado aplicación)
- Para Okta: una aplicación OpenID Connect
- Un sistema SCIM para la administración de usuarios y grupos (solo para Okta)
- Grupos y usuarios de proveedores de identidad externos que se asignan a grupos y usuarios de vCenter Server
- VMware Identity Services habilitado en vCenter Server (solo para Okta)
Interoperabilidad y advertencias de la federación de proveedores de identidad de vCenter Server
La federación de proveedores de identidad de vCenter Server puede interoperar con muchas otras funciones de VMware.
Cuando planee la estrategia de federación de proveedores de identidad de vCenter Server, considere las posibles limitaciones de interoperabilidad.
Mecanismos de autenticación
En una configuración de la federación de proveedores de identidad de vCenter Server, el proveedor de identidad externo controla los mecanismos de autenticación (contraseñas, MFA, biometría, etc.).
AD FS y compatibilidad con un único dominio de Active Directory
Al configurar la federación de proveedores de identidad de vCenter Server para AD FS, el asistente Configurar proveedor de identidad principal solicita que introduzca la información de LDAP del dominio de AD único que contiene los usuarios y los grupos a los que desea acceder vCenter Server. vCenter Server deriva el dominio de AD que se utilizará para la autorización y los permisos del DN base de usuarios que especifique en el asistente. Puede agregar permisos en los objetos de vSphere solo para usuarios y grupos de este dominio de AD. Los usuarios o los grupos de dominios secundarios de AD u otros dominios del bosque de AD no son compatibles con la federación de proveedores de identidad de vCenter Server.
Okta y compatibilidad con varios dominios
Al configurar la federación de proveedores de identidad de vCenter Server para Okta, el asistente Configurar proveedor de identidad principal solicita que introduzca la información de LDAP de múltiples dominios que contienen los usuarios y los grupos a los que desea acceder vCenter Server.
Directivas de contraseñas, bloqueos y tokens
Cuando vCenter Server actúa como proveedor de identidad, se controlan las directivas contraseñas, bloqueos y tokens de vCenter Server para el dominio predeterminado (vsphere.local o el nombre de dominio que introdujo al instalar vSphere). Cuando se utiliza la autenticación federada con vCenter Server, el proveedor de identidad externo controla las directivas de contraseñas, bloqueo y token para las cuentas almacenadas en el origen de identidad, como Active Directory.
Auditoría y conformidad
Cuando se utiliza la federación de proveedores de identidad de vCenter Server, vCenter Server continúa creando entradas de registro para inicios de sesión de usuarios correctos. Sin embargo, el proveedor de identidad externo es responsable de realizar un seguimiento de las acciones de registro, como los bloqueos de cuentas de usuario y los intentos de entrada de contraseña fallidos. vCenter Server no registra estos eventos porque ya no están visibles para vCenter Server. Por ejemplo, cuando AD FS es el proveedor de identidad, realiza un seguimiento de los errores de inicios de sesión federados y los registra. Cuando vCenter Server es el proveedor de identidad para los inicios de sesión locales, vCenter Server realiza un seguimiento de los errores y los registra para los inicios de sesión locales. En una configuración federada, vCenter Server continúa registrando las acciones del usuario después del inicio de sesión.
Integración de productos VMware existentes con proveedores de identidad externos
Los productos de VMware integrados con vCenter Server (por ejemplo, VMware Aria Operations, vSAN, NSX, etc.) siguen funcionando como antes.
Productos que se integran después del inicio de sesión
Los productos que se integran después del inicio de sesión (es decir, que no requieren un inicio de sesión independiente) continúan funcionando como antes.
Autenticación simple para el acceso a API, SDK y CLI
Los scripts, los productos y otras funcionalidades existentes que se basan en los comandos de API, SDK o CLI que utilizan autenticación simple (es decir, nombre de usuario y contraseña) continúan funcionando como antes. Internamente, la autenticación se realiza pasando el nombre de usuario y la contraseña. Este paso del nombre de usuario y de la contraseña compromete algunas de las ventajas de utilizar la federación de identidades, ya que expone la contraseña a vCenter Server (y sus scripts). Considere la posibilidad de migrar a la autenticación basada en tokens siempre que sea posible.
Acceder a la interfaz de administración de vCenter Server
Si el usuario es miembro del grupo de administradores de vCenter Server, se admite el acceso a la interfaz de administración de vCenter Server (anteriormente denominada "interfaz de administración del dispositivo de vCenter Server" o VAMI).
Introducir texto de nombre de usuario en la página de inicio de sesión de AD FS
La página de inicio de sesión de AD FS no admite el envío de texto para rellenar previamente el cuadro de texto de nombre de usuario. Por ello, durante los inicios de sesión federados con AD FS, después de que introduzca el nombre de usuario en la página de destino de vCenter Server y de que se le redirija a la página de inicio de sesión de AD FS, debe volver a introducir el nombre de usuario en la página de inicio de sesión de AD FS. El nombre de usuario que introduzca en la página de destino de vCenter Server es necesario para redirigir el inicio de sesión al proveedor de identidad adecuado. Asimismo, el nombre de usuario en la página de inicio de sesión de AD FS es necesario para autenticarse con AD FS. La imposibilidad de transferir el nombre de usuario a la página de inicio de sesión de AD FS es una limitación de AD FS. No puede configurar ni cambiar este comportamiento directamente desde vCenter Server.
Introducir el texto del nombre de usuario en la página de inicio de sesión de Okta
La página de inicio de sesión de Okta admite el envío de texto para rellenar previamente el cuadro de texto de nombre de usuario. No es necesario que vuelva a introducir el nombre de usuario en la página de inicio de sesión de Okta.
Compatibilidad con direcciones IPv6
AD FS admite direcciones IPv6. Okta no admite direcciones IPv6.
Configuración de instancia única de VMware Identity Services
De forma predeterminada, cuando instala o actualiza a vSphere 8.0 Update 1, VMware Identity Services se habilitan en vCenter Server. Cuando establezca Okta en una configuración de Enhanced Link Mode, utilice VMware Identity Services en un único sistema vCenter Server. Por ejemplo, si la configuración de Enhanced Mode Link consta de tres sistemas vCenter Server, solo se utiliza una instancia de vCenter Server y su instancia de VMware Identity Services para comunicarse con el servidor Okta.
Reconfigurar el identificador de red principal
La reconfiguración del identificador de red principal (Primary Network Identifier, PNID) de la instancia de vCenter Server tiene los siguientes efectos en la configuración de un proveedor de identidad externo.
- AD FS: agregue los nuevos URI de redireccionamiento al servidor de AD FS.
- Okta: vuelva a configurar Okta. Consulte Configurar la federación de proveedores de identidad de vCenter Server para Okta y siga los pasos para crear el proveedor de identidad en vCenter Server.
Ciclo de vida de la federación de proveedores de identidad de vCenter Server
Al administrar el ciclo de vida de la federación de proveedores de identidad de vCenter Server, hay algunas consideraciones específicas.
Puede administrar el ciclo de vida de la federación de proveedores de identidad de vCenter Server de las siguientes maneras.
Migrar de Active Directory a un proveedor de identidad externo
Si utiliza Active Directory como origen de identidad para vCenter Server, la migración a un proveedor de identidad externo es sencilla. Si las funciones y los grupos de Active Directory coinciden con las funciones y los grupos de proveedor de identidad, no es necesario realizar ninguna acción adicional. Cuando los grupos y las funciones no coinciden, debe realizar algunos trabajos adicionales. Si vCenter Server es un miembro del dominio, considere quitarlo del dominio, ya que no es necesario ni se utiliza para la federación de identidades.
Redireccionar y migrar entre dominios
La federación de proveedores de identidad de vCenter Server admite el redireccionamiento entre dominios, es decir, el movimiento de una instancia de vCenter Server de un dominio SSO de vSphere a otro. La instancia de vCenter Server redireccionada recibe la configuración de proveedor de identidad replicada del sistema, o los sistemas, de vCenter Server a los que se ha señalado.
En general, no es necesario realizar ninguna reconfiguración adicional de proveedor de identidad para un redireccionamiento entre dominios, a menos que se cumpla una de las siguientes condiciones.
- La configuración de proveedor de identidad de la instancia de vCenter Server redireccionada difiere de la configuración de proveedor de identidad de la instancia de vCenter Server a la que se ha señalado.
- Esta es la primera vez que la instancia de vCenter Server redireccionada recibe una configuración de proveedor de identidad.
En estos casos, se requiere algo de trabajo adicional. Por ejemplo, para AD FS, debe agregar los URI de redireccionamiento del sistema de vCenter Server al grupo de aplicaciones correspondiente en el servidor de AD FS. Por ejemplo, si la instancia de vCenter Server 1 con el grupo de aplicaciones de AD FS A (o ninguna configuración de AD FS) se redirecciona a la instancia de vCenter Server 2 con el grupo de aplicaciones de AD FS B, debe agregar los URI de redireccionamiento de la instancia de vCenter Server 1 al grupo de aplicaciones B.
Sincronización de usuarios y grupos de Okta y copia de seguridad y restauración de vCenter Server
En función de cuándo sincronice los usuarios y grupos de Okta con vCenter Server y cuándo realice una copia de seguridad de vCenter Server vCenter Server, es posible que deba volver a sincronizar los usuarios de Okta.
Para restaurar un usuario o un grupo eliminados, no puede simplemente insertar el usuario o el grupo de Okta en vCenter Server. Debe actualizar la propia aplicación SCIM 2.0 de Okta con el usuario o el grupo que falta. Consulte Restaurar usuarios y grupos de Okta eliminados a vCenter Server.
