Identidad de espacio

La identidad de espacio de trabajo principal de un usuario autoriza el acceso a todas las fuentes de recursos de espacio de trabajo, incluidas microaplicaciones, aplicaciones móviles, aplicaciones virtuales, escritorios virtuales y contenido. Citrix Workspace ofrece a las organizaciones la opción de seleccionar el proveedor de identidades principal del usuario.

Proveedor de identidades (IdP)

Un proveedor de identidad es la autoridad final de la identidad del usuario. El proveedor de identidades es responsable de las directivas para proteger y proteger la identidad del usuario, que incluye directivas de contraseña, directivas de autenticación multifactor y directivas de bloqueo.

Antes de la era de la nube, las organizaciones tenían una única opción para un proveedor de identidades: Windows Active Directory. Pero ahora, casi todos los sistemas o servicios que requieren una cuenta de usuario única están actuando como un proveedor de identidades. Facebook, LinkedIn, Twitter, Workday y Google son proveedores de identidad, ya que cada uno es la autoridad final sobre la identidad de un usuario dentro de su servicio. Además, una recomendación de seguridad común, que rara vez se sigue, es utilizar contraseñas diferentes para cada identidad para limitar el impacto de una contraseña robada.

El enfoque tradicional de la identidad proporciona una de las peores experiencias de usuario imaginables. Los usuarios se ven constantemente desafiados a autenticarse. Los usuarios se ven obligados a recordar contraseñas únicas y complejas para cada servicio. Los usuarios están dedicando un tiempo valioso a restablecer contraseñas y cuentas desbloqueadas debido a credenciales olvidadas.

Citrix Workspace proporciona una mejor alternativa al statu quo. Citrix Workspace permite a cada organización elegir una identidad principal de una lista creciente de opciones, que actualmente incluye.

  • Windows Active Directory
  • Azure Active Directory
  • Okta
  • Citrix Gateway

Identidad de Workspace

Citrix Workspace confía en el microservicio del agente de identidades para administrar la autenticación en el proveedor de identidades configurado. Una autenticación correcta del espacio de trabajo permite que la fuente de recursos µ-service cree una lista de recursos autorizados disponibles para el usuario.

Sin embargo, muchos de estos servicios tienen, o requieren una identidad diferente de la identidad de espacio de trabajo principal del usuario, ya que utilizan un proveedor de identidades diferente. El sistema de inicio de sesión único µ-service traduce la identidad del espacio de trabajo principal del usuario en una identidad específica del recurso mediante enfoques apropiados como:

  • SAML
  • Kerberos
  • Formularios
  • Tarjetas inteligentes virtuales

El enfoque de Citrix Workspace de identidades primarias y secundarias crea una experiencia en la que los usuarios se autentican físicamente una vez y todos los desafíos de autenticación posteriores se satisfacen automáticamente.

Intermediación de identidades

Un proveedor de identidades, y la base de datos de identidades relacionada, es la autoridad final para la identidad de un usuario. Sin embargo, cada proveedor de identidades es diferente. Cada proveedor de identidades incorpora diferentes parámetros, directivas y criterios para la identidad de un usuario.

Dentro de Citrix Workspace, el agente de identidades µ-service redirige la solicitud de autenticación principal al proveedor de identidades configurado. Una vez que la solicitud de autenticación se transfiere al proveedor de identidades, las directivas de autenticación, dentro del proveedor de identidades, determinan cómo debe autenticarse el usuario, que a menudo incluye directivas de autenticación multifactor.

Una vez que el proveedor de identidades autentica correctamente al usuario, el agente de identidades µ-service recibe una respuesta de autenticación correcta. La ventaja de este enfoque es que las organizaciones pueden cambiar las directivas de autenticación dentro del proveedor de identidades sin afectar a Citrix Workspace.

Además de una respuesta de autenticación correcta del proveedor de identidades, el agente de identidades µ-service recibe y traduce la información única del proveedor de identidades en un conjunto estándar de reclamaciones sobre el usuario.

Las reclamaciones sobre un usuario son simplemente información que identifica al usuario, que puede ser un UPN, SID, GUID, correo electrónico o cualquier otra cosa contenida en la base de datos del proveedor de identidades. Las notificaciones permiten a Citrix Workspace generar una lista de recursos y servicios a los que el usuario está autorizado a acceder. Por ejemplo, si la identidad principal del usuario es un ID de Google, Citrix Workspace utiliza el ID de Google para controlar la autorización a otros recursos y servicios no vinculados a Google ID, como Workday, SAP, Windows, Slack y otros. Dicho de otra manera, con Citrix Workspace, los usuarios pueden utilizar un solo ID de Google para iniciar sesión en cada recurso autorizado, incluyendo Windows.

Dentro de Citrix Workspace, el agente de identidades µ-service continúa ampliándose para incluir opciones adicionales para el proveedor de identidades principal. El agente de identidades µ-service incluye proveedores de identidades que pueden estar disponibles desde una ubicación local o el agente de identidades µ-service puede utilizar proveedores de identidades basados en la nube. El siguiente diagrama proporciona una descripción general de la plataforma de identidades Citrix Workspace y todas las opciones actuales del proveedor de identidades, que más adelante se analizarán con más detalle.

Introducción a la identidad de Workspace

Cada uno de los proveedores de identidades es único; pero al final, cada proveedor de identidades le dice a Citrix Workspace algunas cosas sobre el usuario:

  1. El nombre de usuario
  2. El usuario se ha autenticado correctamente
  3. Reclamaciones sobre el usuario

Para comprender mejor los detalles de cada proveedor de identidad, revise las siguientes secciones sobre proveedores de identidad principales

  • Active Directory
  • Active Directory con TOTP
  • Azure Active Directory
  • Citrix Gateway
  • Okta
  • Google

Active Directory

Cuando se configura, los usuarios pueden autenticarse en Citrix Workspace mediante credenciales de Active Directory.

IdP de Active Directory

Para integrar Citrix Workspace con un dominio de Active Directory local, Workspace debe poder comunicarse con un controlador de dominio. Al implementar un conjunto de conectores en la nube de alta disponibilidad dentro del entorno local, los conectores de nube establecen un canal de control saliente con la suscripción a Citrix Cloud de la organización. El canal de control saliente permite a Citrix Workspace túnel de comunicación de forma segura, a través del puerto 443, con componentes locales sin necesidad de modificar el puerto del firewall entrante.

El conector en la nube incluye un servicio de proveedor de AD que permite a Citrix Workspace leer información de usuarios y grupos desde el dominio de Active Directory. Cuando un usuario se autentica con Citrix Workspace, las credenciales se envían al controlador de dominio local a través del servicio Proveedor de AD del conector de nube.

Puertos de Active Directory

Active Directory con TOTP

Para muchas organizaciones, proporcionar acceso a servicios de aplicaciones y escritorios con un nombre de usuario y contraseña no proporciona la seguridad adecuada. Citrix Workspace incorpora un TOTP entregado en la nube Contraseña única basada en tiempo (TOTP) que proporciona autenticación multifactor mediante la introducción de un “algo que tienes”, que es el token TOTP, con el “algo que sabes”, que es la contraseña.

TOTP genera un código aleatorio de 6 dígitos que cambia cada 30 segundos. Este código se basa en una clave secreta que se comparte entre la aplicación móvil del usuario y la infraestructura back-end. La clave secreta es el factor “algo que tienes” para la autenticación multifactor. Para generar el código aleatorio, se aplica un algoritmo hash seguro estándar de la industria a la clave secreta y a la hora actual. Para autenticarse, el código de la aplicación móvil se compara con el código de la infraestructura back-end.

Para registrarse en el servicio TOTP, cada usuario crea e instala una clave secreta previamente compartida dentro de la aplicación de autenticación en un dispositivo móvil.

Active Directory con registro TOTP

Una vez que el usuario se registra correctamente con el microservicio TOTP, el usuario debe usar el token, junto con sus credenciales de Active Directory, para autenticarse correctamente en Citrix Workspace.

Active Directory con autenticación TOTP

Dado que TOTP se incorpora como una capacidad dentro de Citrix Workspace, se elimina la complejidad de configurar y mantener una solución de tipo TOTP dentro de un entorno local. Con esta capacidad dentro de Citrix Workspace, los administradores habilitan el servicio y los usuarios registran dispositivos.

Hay algunos elementos a tener en cuenta al habilitar la autenticación multifactor basada en TOTP:

  • Aplicaciones de autenticación: TOTP utiliza un algoritmo estándar de la industria para generar el token basado en el tiempo. Los usuarios pueden utilizar cualquier número de aplicaciones móviles para generar los tokens, incluidos: Citrix SSO, Microsoft Authenticator y otros.
  • Recuento de tokens: a los usuarios se les permite un token (clave) por cuenta de usuario.
  • Recuento de dispositivos: aunque los usuarios están limitados a un único token (clave), los usuarios pueden instalar el token en varios dispositivos. Sin embargo, la instalación debe realizarse durante la fase de registro, ya que los usuarios no pueden revelar el código QR o la clave secreta una vez finalizado el registro.
  • Reemplazo de dispositivos: siempre que un usuario reemplace su dispositivo móvil, debe registrar el dispositivo con el servicio TOTP. Cuando el usuario pasa por el proceso de registro TOTP de nuevo, se elimina la clave secreta antigua. Cualquier dispositivo que utilice la clave secreta antigua no puede generar el token correcto, lo que da como resultado una autenticación de Workspace fallida.
  • Restablecimiento de tokens: los administradores pueden restablecer manualmente el token de un usuario. Una vez restablecido, los usuarios no pueden completar la autenticación sin volver a registrarse con el servicio TOTP.
  • Implementación: Al igual que todos los cambios en la configuración de administración de identidades y acceso, la habilitación de TOTP en una suscripción de Workspace afecta a todos Cuando está habilitada, cualquier nuevo intento de autenticación fallará hasta que el usuario se registre correctamente en el servicio TOTP.

El Vídeo TOTP Tech Insight proporciona detalles adicionales sobre la experiencia del usuario y del administrador.

Azure Active Directory

Citrix Workspace permite a los usuarios autenticarse con una cuenta de Azure Active Directory. La autenticación puede ser tan simple como un nombre de usuario y una contraseña o utilizar cualquier directiva de autenticación multifactor disponible en Azure Active Directory. La integración entre Citrix Workspace y Azure Active Directory da como resultado que Azure Active Directory gestione el proceso de autenticación mientras devuelve un token de identidad para el usuario.

IdP de Azure Active Directory

Para integrar Citrix Workspace y Azure Active Directory, Citrix Workspace crea automáticamente una aplicación empresarial en Azure y establece los permisos correctos. Estos permisos incluyen los siguientes (capacidades de solo lectura):

  • Iniciar sesión y leer el perfil del usuario
  • Leer los perfiles básicos de todos los usuarios
  • Leer los perfiles completos de todos los usuarios
  • Leer datos de directorio
  • Leer todos los grupos

Azure Active Directory autentica al usuario. Una vez que el usuario se ha autenticado correctamente, Azure proporciona a Citrix Workspace un token de identidad de Azure que incluye notificaciones sobre el usuario para identificarlos de forma única en el directorio correcto.

Citrix Workspace utiliza las notificaciones de Azure Active Directory para autorizar al usuario a los recursos y servicios de Citrix Workspace.

Autorizar el acceso a un recurso requiere una única “fuente de verdad”. La fuente de la verdad es la autoridad final sobre las decisiones de autorización. Cuando se utiliza Azure Active Directory como directorio de usuario principal, el tipo de recurso Workspace dicta el origen de la verdad.

  • Content Collaboration Service: para archivos de usuario y contenido, Content Collaboration Service es el origen de la verdad. Cuando Azure Active Directory es el proveedor de identidades para Workspace, una identidad de Azure Active Directory y la cuenta de Content Collaboration deben usar la misma dirección de correo electrónico. Para obtener información sobre la pertenencia a grupos, Content Collaboration Service es la fuente de la verdad. La información de pertenencia al grupo se basa en la dirección de correo electrónico del usuario.
  • Endpoint Management Service: para aplicaciones móviles, Endpoint Management Service utiliza Active Directory como el origen de la verdad. Cuando Azure Active Directory es el proveedor de identidades para Workspace, una identidad de Azure Active Directory debe contener notificaciones específicas de Active Directory (SID, UPN y una Id inmutableId que no cambia). Estas notificaciones asocian una identidad de Azure Active Directory con una identidad de Active Directory. Si Endpoint Management Service utiliza la pertenencia a grupos, Active Directory es el origen de la verdad.
  • Servicio de puerta de enlace: para SaaS y aplicaciones web, el servicio de puerta de enlace utiliza Azure Active Directory como el origen de la verdad. El servicio de puerta de enlace puede usar cuentas de usuario de Azure Active Directory o una pertenencia a un grupo de usuarios de Azure Active Directory para autorizar el acceso a los recursos.
  • Servicio de Microapps: para aplicaciones de microaplicaciones, el servicio Microapps utiliza Azure Active Directory como fuente de la verdad. El servicio Microapps puede usar cuentas de usuario de Azure Active Directory o una pertenencia a un grupo de usuarios de Azure Active Directory para autorizar el acceso a los recursos.
  • Servicio de Virtual Apps and Desktops: dado que los recursos basados en Windows (VDI) requieren una identidad de usuario basada en Active Directory, el origen de la verdad depende de la integración subyacente de Active Directory y Azure Active Directory.
    • Las identidades de usuario de Azure Active Directory deben contener notificaciones específicas de Active Directory (SID, UPN y una Id inmutableId que no cambia). Estas notificaciones asocian una identidad de Azure Active Directory con una identidad de Active Directory. Para una identidad de usuario específica, Azure Active Directory es el origen de la verdad.
    • Si las decisiones de autorización se basan en la pertenencia a un grupo, el origen de verdad es Active Directory. Workspace envía posteriormente solicitudes de pertenencia a grupos a Active Directory a través del conector en la nube.

El proceso para vincular parámetros de Active Directory con un identificador de Azure Active Directory se simplifica enormemente con el uso de la herramienta de sincronización de Azure Active Directory.

El Vídeo de Azure Active Directory Tech Insight proporciona detalles adicionales sobre la configuración del administrador y la experiencia del usuario cuando se utiliza una FIDO2 YubiKey.

Citrix Gateway

Los usuarios pueden autenticarse en Citrix Workspace mediante un Citrix Gateway local. La autenticación de Citrix Gateway acomoda directivas de autenticación simples que utilizan un único origen para la autenticación de usuarios, como Active Directory, así como directivas de autenticación en cascada más complejas que dependen de varios proveedores y directivas de autenticación.

La integración entre Citrix Workspace y Citrix Gateway da como resultado que Citrix Gateway gestione el proceso de autenticación inicial. Una vez que Citrix Gateway valida la autenticación del usuario, Workspace valida las credenciales de Active Directory antes de generar una lista de recursos y servicios autorizados.

IdP de Citrix Gateway

Para integrar Citrix Workspace y Citrix Gateway, se debe crear una directiva de IdP de OAuth dentro de Citrix Gateway local, que es un protocolo de autenticación basado en la especificación OAuth 2.0. Citrix Workspace se conecta a la URL exclusiva de Citrix Gateway de la organización para acceder a la aplicación OpenID Connect haciendo referencia al ID de cliente de la aplicación, que está protegido con una clave secreta compartida.

La aplicación OpenID Connect, configurada en Citrix Gateway, utiliza las directivas de autenticación avanzadas enlazadas al servidor virtual de autenticación para autenticar al usuario. Una vez que el usuario se ha autenticado correctamente en Citrix Gateway, Citrix Gateway devuelve las credenciales de Active Directory del usuario a Citrix Workspace.

El Vídeo de información sobre Citrix Gateway Tech proporciona detalles adicionales sobre la configuración del administrador y la experiencia del usuario.

Con el uso de Factor nFactor, Citrix Gateway permite a las organizaciones crear un flujo de autenticación más dinámico, teniendo en cuenta funciones como la pertenencia a grupos de usuarios, la propiedad del dispositivo y la ubicación del usuario.

En un ejemplo, mediante la configuración más básica, las organizaciones pueden integrar Citrix Gateway con Citrix Workspace para proporcionar autenticación a Active Directory.

Citrix Gateway - Active Directory

Este tipo de configuración requiere una directiva de IdP de OAuth configurada con Citrix Workspace y una directiva LDAP configurada para un dominio de Active Directory local. Sin embargo, esta directiva de autenticación básica se puede lograr sin utilizar un Citrix Gateway.

En muchas organizaciones, los usuarios deben autenticarse en una implementación RADIUS, como DUO, antes de autenticarse en Active Directory, lo que ayuda a proteger las credenciales de Active Directory.

Citrix Gateway - DUO

Esta configuración requiere la directiva de autenticación para validar primero una autenticación RADIUS. Si se realiza correctamente, el flujo de autenticación continúa hasta el siguiente factor de autenticación, que es la autenticación LDAP.

Con Citrix Gateway, las organizaciones pueden implementar la autenticación contextual, donde el flujo de autenticación del usuario depende del contexto del usuario actual. Por ejemplo, una organización puede implementar diferentes directivas de autenticación para dispositivos propiedad de la empresa frente a los usuarios.

Citrix Gateway - Certificados

En esta configuración, Citrix Workspace envía la solicitud de autenticación a Citrix Gateway. Citrix Gateway solicita un certificado basado en el cliente, que solo está disponible en dispositivos propiedad de la empresa. Si el certificado está disponible y es válido, el usuario simplemente proporciona una contraseña de Active Directory. Sin embargo, si el certificado no es válido o no existe, lo que sería el caso de un dispositivo propiedad de un usuario, Citrix Gateway desafía al usuario a proporcionar un código TOTP seguido de credenciales de Active Directory.

Otro ejemplo de autenticación contextual proporciona diferentes directivas de autenticación basadas en la pertenencia a grupos de Active Directory.

Citrix Gateway - Grupos de usuarios

Los usuarios que interactúen con datos financieros, datos personales o datos de propiedad intelectual deben encontrar directivas de autenticación más estrictas, como se muestra con Group2 en el diagrama.

Cuando se utiliza un Citrix Gateway local como proveedor de identidades, los usuarios pueden utilizar la autenticación basada en push con Citrix Workspace, como se detalla en la Video Push Authentication Tech Insight.

Independientemente del tipo de directiva de autenticación configurada, una vez que el usuario valida correctamente su identidad, Citrix Gateway debe responder a la solicitud inicial de Citrix Workspace con las credenciales de Active Directory del usuario. Para que Citrix Workspace complete el proceso de autenticación y genere una lista de recursos autorizados, cada cuenta de usuario de Active Directory debe tener definidos los siguientes parámetros:

  • Dirección de correo electrónico
  • Nombre simplificado
  • Nombre común
  • sAMAccountName
  • Nombre principal del usuario
  • Identificador de objeto (OID)
  • Identificador de seguridad (SID)

Okta

Cuando se configura, los usuarios pueden autenticarse en Citrix Workspace mediante credenciales de Okta. La autenticación puede ser tan simple como un nombre de usuario y una contraseña o utilizar cualquier directiva de autenticación multifactor disponible en Okta. La integración entre Citrix Workspace y Okta da como resultado que Okta gestione el proceso de autenticación mientras devuelve un token de identidad y acceso para el usuario.

IdP Okta

Para integrar Citrix Workspace y Okta, se debe crear una aplicación OpenID Connect dentro de Okta. Citrix Workspace se conecta a la URL exclusiva de Okta de la organización para acceder a la aplicación OpenID Connect haciendo referencia al ID de cliente de la aplicación, que está protegido con una clave secreta compartida.

La aplicación OpenID Connect autentica al usuario. Una vez que el usuario se ha autenticado correctamente en Okta, Okta proporciona a Citrix Workspace dos tokens de seguridad:

  • Token de acceso: token que demuestra que el usuario tiene autorización para acceder al recurso Okta (aplicación OpenID Connect), eliminando la necesidad de volver a autenticarse continuamente.
  • Token de identidad: un token que demuestra la identidad del usuario. El token de identidad contiene notificaciones (información) sobre el usuario autenticado. El token está codificado para demostrar que no ha sido manipulado.

Estos tokens permiten a Citrix Workspace acceder a la aplicación OpenID Connect y generar una lista de recursos autorizados en función de la identidad Okta del usuario.

Autorizar el acceso a un recurso requiere una única “fuente de verdad”. La fuente de la verdad es la autoridad final sobre las decisiones de autorización. Cuando se utiliza Okta como directorio de usuario principal, el tipo de recurso Workspace dicta el origen de la verdad.

  • Content Collaboration Service: para archivos de usuario y contenido, Content Collaboration Service es el origen de la verdad. Cuando Okta es el proveedor de identidades principal para Workspace, una identidad de Okta y la cuenta de Content Collaboration deben usar la misma dirección de correo electrónico. Para obtener información sobre la pertenencia a grupos, Content Collaboration Service es la fuente de la verdad. La información de pertenencia al grupo se basa en la dirección de correo electrónico del usuario. En este caso, Okta solo se utiliza como proveedor de identidades para Workspace.
  • Endpoint Management Service: para aplicaciones móviles, Endpoint Management Service utiliza Active Directory como el origen de la verdad. Cuando Okta es el proveedor de identidades principal para Workspace, una identidad de Okta debe contener notificaciones específicas de Active Directory (SID, UPN y GUID). Estas afirmaciones asocian una identidad Okta con una identidad de Active Directory. Si Endpoint Management Service utiliza la pertenencia a grupos, Active Directory es el origen de la verdad.
  • Servicio de puerta de enlace: para SaaS y aplicaciones web, el servicio Gateway utiliza Okta como la fuente de la verdad. El Servicio Gateway puede utilizar cuentas de usuario de Okta o una pertenencia a un grupo de usuarios de Okta para autorizar el acceso a los recursos.
  • Servicio de Microapps: Para aplicaciones de microaplicaciones, el Servicio de Microapps utiliza Okta como fuente de verdad. El Servicio Microapps puede usar cuentas de usuario de Okta o una pertenencia a un grupo de usuarios de Okta para autorizar el acceso a los recursos.
  • Servicio de Virtual Apps and Desktops: dado que los recursos basados en Windows (VDI) requieren una identidad de usuario basada en Active Directory, el origen de la verdad depende de la integración subyacente de Active Directory y Okta.
    • Las identidades de usuario de Okta deben contener notificaciones específicas de Active Directory (SID, UPN y GUID). Estas afirmaciones asocian una identidad Okta con una identidad de Active Directory. Para una identidad de usuario específica, Okta es la fuente de la verdad.
    • Si las decisiones de autorización se basan en la pertenencia al grupo, la fuente de verdad se basa en los parámetros de sincronización entre Active Directory y Okta. Si algún grupo de Active Directory se sincroniza con Okta e incluye notificaciones de Active Directory (SID), Okta se convierte en el origen de verdad para los grupos que utilizan el atributo ObjectSID. Este atributo Okta solo se devuelve para grupos de Active Directory tal como se define en Especificaciones de Okta. Los grupos nativos de Okta no tendrán este atributo establecido, lo que resulta en que Active Directory se convierta en la fuente de la verdad. Workspace envía posteriormente solicitudes de pertenencia a grupos a Active Directory a través del conector en la nube.

El proceso para vincular parámetros de Active Directory con un ID de Okta se simplifica enormemente con el uso de la herramienta de sincronización Okta Active Directory. Las reclamaciones de Active Directory deben cumplir con el siguiente estándar de nomenclatura dentro de Okta.

Okta - Parámetros

La configuración y configuración de Okta como proveedor de identidades se detallan en el Vídeo de Okta Tech Insight.

Identidad de espacio