vCenter Single Sign-On permite que los componentes de vSphere se comuniquen entre sí a través de un mecanismo de token seguro.

vCenter Single Sign-On utiliza los siguientes servicios.
  • Autenticación de usuarios a través de la federación de proveedores de identidad externo o el proveedor de identidad integrado de vCenter Server. El proveedor de identidad integrado admite cuentas locales, Active Directory u OpenLDAP, autenticación de Windows integrada (Integrated Windows Authentication, IWA) y mecanismos de autenticación diversos (tarjeta inteligente, RSA SecurID y autenticación de sesión de Windows).
  • La autenticación de usuarios de soluciones a través de certificados.
  • Servicio de token de seguridad (Security Token Service, STS).
  • SSL para proteger el tráfico.

Descripción general del proveedor de identidad

Antes de vSphere 7.0, vCenter Server incluye un proveedor de identidad integrado. De forma predeterminada, vCenter Server utiliza el dominio vsphere.local como el origen de identidad (pero se puede cambiar durante la instalación). Puede configurar el proveedor de identidad integrado de vCenter Server para que utilice Active Directory (AD) como su origen de identidad mediante LDAP/S, OpenLDAP/S y la autenticación de Windows integrada (IWA, Integrated Windows Authentication). Estas configuraciones permiten a los clientes iniciar sesión en vCenter Server a través de sus cuentas de AD.

A partir de vSphere 7.0, puede configurar vCenter Server para un proveedor de identidad externo mediante la autenticación federada. En una configuración de este tipo, debe reemplazar a vCenter Server como el proveedor de identidad. Actualmente, vSphere admite los servicios de federación de Active Directory (Active Directory Federation Services, AD FS) como proveedor de identidad externo. En esta configuración, AD FS interactúa con los orígenes de identidad en nombre de vCenter Server.

Inicio de sesión del usuario con autenticación federada del proveedor de identidad de vCenter Server

En la siguiente figura, se muestra el flujo de inicio de sesión del usuario para la federación de proveedores de identidad de vCenter Server.

Figura 1. Inicio de sesión de usuario de la federación de proveedores de identidad de vCenter Server

Esta figura muestra el flujo del proceso de inicio de sesión de un usuario en vCenter Server con federación de proveedores de identidad.

vCenter Server, AD FS y Active Directory interactúan de la siguiente manera:

  1. El usuario comienza en la página de destino de vCenter Server e introduce allí un nombre de usuario.
  2. Si el nombre de usuario es para un dominio federado, vCenter Server redirecciona la solicitud de autenticación a AD FS.
  3. Si es necesario, AD FS solicita al usuario que inicie sesión con las credenciales de Active Directory.
  4. AD FS autentica al usuario con Active Directory.
  5. AD FS emite un token de seguridad con información de grupo de Active Directory.
  6. vCenter Server utiliza el token para iniciar la sesión del usuario.
Ahora el usuario está autenticado, y puede ver y modificar todos los objetos sobre los que tiene privilegios por su función.
Nota: Al principio, se asigna la función Sin acceso a cada usuario. Un administrador de vCenter Server debe asignar al menos la función Solo lectura al usuario para que pueda iniciar sesión. Consulte la documentación de Seguridad de vSphere.

En caso de que no se pueda acceder al proveedor de identidad externo, el proceso de inicio de sesión vuelve a la página de destino de vCenter Server, donde se muestra un mensaje de información adecuado. Los usuarios también pueden iniciar sesión con sus cuentas locales en el origen de identidad vsphere.local.

Inicio de sesión del usuario con el proveedor de identidad integrado de vCenter Server

En la siguiente figura, se muestra el flujo de inicio de sesión del usuario cuando vCenter Server actúa como el proveedor de identidad.

Figura 2. Inicio de sesión del usuario con el proveedor de identidad integrado de vCenter Server
Cuando el usuario inicia sesión en vSphere Client, el servidor Single Sign-On establece el protocolo de enlace de la autenticación.
  1. El usuario inicia sesión en vSphere Client con un nombre de usuario y una contraseña para acceder al sistema vCenter Server o a otro servicio de vCenter.

    Cuando se configura la autenticación de Windows integrada (Integrated Windows Authentication, IWA), los usuarios también pueden iniciar sesión sin tener que volver a introducir su contraseña de Windows; para ello, se debe activar la casilla Utilizar autenticación de sesión de Windows.

  2. vSphere Client pasa la información de inicio de sesión al servicio vCenter Single Sign-On, que comprueba el token SAML de vSphere Client. Si vSphere Client tiene un token válido, vCenter Single Sign-On comprueba si el usuario se encuentra en el origen de identidad configurado (por ejemplo, Active Directory).
    • Si solo se emplea el nombre de usuario, vCenter Single Sign-On comprueba el dominio predeterminado.
    • Si se incluye un nombre de dominio con el nombre de usuario (DOMAIN\user1 o user1@DOMAIN), vCenter Single Sign-On comprueba ese dominio.
  3. Si el usuario puede autenticarse en el origen de identidad, vCenter Single Sign-On devuelve un token que representa al usuario en vSphere Client.
  4. vSphere Client pasa el token al sistema vCenter Server.
  5. vCenter Server comprueba con el servidor de vCenter Single Sign-On que el token sea válido y que no haya caducado.
  6. El servidor de vCenter Single Sign-On devuelve el token al sistema vCenter Server mediante el marco de autorización de vCenter Server para otorgar acceso a los usuarios.
Ahora el usuario está autenticado, y puede ver y modificar todos los objetos sobre los que tiene privilegios por su función.
Nota: Al principio, se asigna la función Sin acceso a cada usuario. Un administrador de vCenter Server debe asignar al menos la función Solo lectura al usuario para que pueda iniciar sesión. Consulte la documentación de Seguridad de vSphere.

Inicio de sesión para usuarios de solución

Los usuarios de solución son conjuntos de servicios que se usan en la infraestructura de vCenter Server, por ejemplo, las extensiones de vCenter Server. Las extensiones de VMware y las posibles extensiones externas también pueden autenticarse en vCenter Single Sign-On.

Nota: vCenter Server utiliza certificados de usuarios de solución solo para comunicación interna. Los certificados de usuarios de solución no se utilizan para la comunicación externa.

En la siguiente figura, se muestra el flujo de inicio de sesión para usuarios de solución.

Figura 3. Inicio de sesión para usuarios de solución
El protocolo de enlace entre un usuario de solución, vCenter Single Sign-On y otros componentes de vCenter sigue los pasos detallados en el siguiente texto.
  1. El usuario de solución intenta conectarse a un servicio de vCenter Server.
  2. Se redirige al usuario de solución a vCenter Single Sign-On. Si el usuario de solución es nuevo en vCenter Single Sign-On, debe presentar un certificado válido.
  3. Si el certificado es válido, vCenter Single Sign-On asigna un token SAML (token de portador) al usuario de solución. vCenter Single Sign-On firma el token.
  4. El usuario de solución se redirige a vCenter Single Sign-On y puede realizar tareas según sus permisos.

    La próxima vez que el usuario de solución deba autenticarse, podrá usar el token SAML para iniciar sesión en vCenter Server.

De forma predeterminada, este protocolo de enlace se aplica automáticamente, ya que VMCA aprovisiona a los usuarios de solución con certificados durante el inicio. Si la directiva de la empresa exige certificados externos firmados por una entidad de certificación, se pueden utilizar esos certificados para reemplazar los certificados de los usuarios de solución. Si esos certificados son válidos, vCenter Single Sign-On asigna un token SAML al usuario de solución. Consulte Usar certificados personalizados con vSphere.

Cifrado compatible

Se admite el cifrado AES, que es el nivel más alto de cifrado. El cifrado compatible también afecta a la seguridad cuando vCenter Single Sign-On utiliza Active Directory como un origen de identidad.

También afecta a la seguridad cada vez que un host ESXi o vCenter Server se une a Active Directory.