Citrix Virtual Apps and Desktops

Compatibilidad con el inicio de sesión único

Introducción

La Redirección de contenido del navegador ahora ofrece una experiencia de usuario optimizada con compatibilidad con el inicio de sesión único, lo que permite la autenticación del lado del VDA y el uso compartido de cookies.

  • Esta mejora elimina los inicios de sesión redundantes, lo que aumenta la productividad al mantener la persistencia de la autenticación y las cookies en todas las sesiones de BCR, incluso después de cerrar la ventana de BCR.

  • Esta experiencia fluida mejora aún más la seguridad al garantizar que la autenticación se origine en el VDA y no en el cliente.

  • Sin inicio de sesión único

  • Abrir una página autenticada dentro de BCR requería que los usuarios volvieran a introducir sus credenciales cada vez, rompiendo la persistencia del SSO.
  • El SSO solo se mantenía mientras la ventana de BCR permanecía abierta; cerrar y volver a abrir la ventana obligaba a los usuarios a repetir el proceso de inicio de sesión.
  • El flujo de autenticación se producía desde el cliente, lo que obligaba a los administradores a proporcionar acceso a la red a sitios de autenticación seguros desde el dispositivo cliente.

  • Con inicio de sesión único

  • Ya no se solicita a los usuarios las credenciales (cuando ya están autenticados en el VDA), ya que el SSO se conserva sin problemas desde el navegador del VDA.
  • La autenticación se produce desde el VDA, lo que mejora la postura de seguridad al limitar los requisitos de red y la exposición del lado del cliente, proporcionando una experiencia significativamente mejorada e ininterrumpida.

Requisitos mínimos

  • Citrix Virtual Apps and Desktops 2511
  • Citrix Workspace App para Windows 2511
  • Citrix Workspace App para Linux 2511 (Vista previa)
  • Extensión de Redirección del navegador (Chrome o Edge) 25.11 o posterior

Secuencias de autenticación admitidas

Actualmente se admiten dos tipos de secuencias de autenticación con el inicio de sesión único de BCR.

Autenticación basada en redirección

En este método estándar, la aplicación utiliza una redirección HTTP para forzar al usuario a una página dedicada para la autenticación.

Por ejemplo, si un usuario intenta acceder a https://my.intranet.app sin las cookies de sesión necesarias, la aplicación web responderá con una redirección HTTP 302 al punto de conexión de autenticación, como https://my.intranet.app/auth .

Una vez que el usuario se autentica correctamente en esa página, el navegador se redirige de nuevo a la URL de la aplicación original, incluyendo ahora las cookies de autenticación requeridas.

Autenticación basada en formularios en la página [Vista previa]

Este método mantiene al usuario en la URL de la aplicación prevista mientras presenta dinámicamente la interfaz de inicio de sesión.

Por ejemplo, si un usuario navega a una página protegida, como https://my.intranet.app , la página carga el formulario de autenticación directamente sin activar una redirección, porque faltan las cookies necesarias. Este proceso puede implicar varios intercambios internos entre la interfaz de la página y el Proveedor de Identidad (IDP). Estos intercambios continúan hasta que se proporciona y utiliza una cookie final y válida, lo que otorga al usuario acceso al contenido de la página original.

Nota:

En caso de que tu escenario no esté cubierto por los mecanismos especificados anteriormente y no sea posible configurar tu aplicación web para usar los mecanismos anteriores, ponte en contacto con el equipo de producto de Citrix.

Configuración

Paso 0: Introducción

Existen dos métodos para configurar el inicio de sesión único con BCR. La elección del método de configuración depende del mecanismo de autenticación de los sitios web de BCR deseados y de la flexibilidad que necesites para configurar varias aplicaciones web para la compatibilidad con el inicio de sesión único.

Método 1: Este método utiliza las políticas de BCR existentes en Web Studio y las utiliza para lograr la compatibilidad con el inicio de sesión único.

Antes de la introducción del soporte de inicio de sesión único, la directiva de sitios de autenticación de redirección de contenido del navegador se utilizaba para especificar las URL empleadas para la autenticación (o páginas intermedias) que debían redirigirse al cliente para asegurar la continuidad del flujo.

Con la introducción del soporte de inicio de sesión único, BCR aprovechará las cookies de autenticación en el navegador del lado del VDA y, por lo tanto, las URL de la directiva de sitios de autenticación ahora deben configurarse en la directiva de lista de bloqueo de redirección de contenido del navegador. Esto asegura que la autenticación se realice a través del VDA.

Método 2: Este método funciona con una lógica similar a la del Método 1, pero las URL se configuran a través de JSON (bcrconfig.json) y la URL de JSON alojada se invoca en la directiva ACL de BCR. La configuración JSON ofrece flexibilidad adicional.

  1. Las empresas utilizan varias aplicaciones web en su entorno, y cada aplicación puede emplear un mecanismo de autenticación diferente según su implementación. El nuevo método JSON permite que la configuración sea más intuitiva, robusta y escalable.
  2. Al tratar con la autenticación basada en formularios en la página, el Método 1 no ofrece una forma de establecer una cookie de autenticación específica, ya que no existen directivas para admitir dicha configuración. Por lo tanto, si tu sitio web requiere autenticación basada en formularios en la página, JSON es la única forma de hacerlo.
  • De cara al futuro, JSON ofrece una forma escalable de introducir funciones más robustas, y Citrix recomienda probar la configuración basada en JSON.

  • Paso 1: Determinar el mecanismo de autenticación

  • Para determinar qué método usar para tu configuración, el primer paso es identificar qué tipo de mecanismo de autenticación utiliza tu aplicación. Para determinar con precisión el método de autenticación de la aplicación web, el mejor enfoque es contactar con el administrador de la aplicación web.

  • Si esa no es una opción, debes inspeccionar las interacciones de solicitud/respuesta en las herramientas de desarrollador del navegador, en la ficha Red, mientras realizas el flujo de autenticación sin la extensión BCR instalada. Los siguientes resultados pueden ayudarte a determinar el tipo de autenticación:

Para la autenticación basada en redirección: Busca en la columna Estado una o más respuestas 302 (Redirección). Las respuestas 302 deben contener un encabezado de ubicación que apunte a la página de autenticación. Esta URL de página debe establecerse en la directiva de lista de bloqueo de redirección de contenido del navegador si usas el Método 1 y en la sección denyList de la configuración de la aplicación en el archivo bcrconfig.json si usas el Método 2.

Para la autenticación basada en formularios en la página: Busca en la columna Método varias solicitudes POST. Una de las respuestas posteriores a una solicitud POST debe devolver un encabezado set-cookie con la cookie de autenticación específica de la aplicación web. Esta cookie debe establecerse en la sección de cookies de la configuración de la aplicación en el archivo bcrconfig.json. Como el Método 1 no admite la autenticación basada en formularios en la página, el Método 2 es la única opción de configuración para este escenario.

Ejemplo: Aquí tienes un ejemplo con github.com. Este método se puede usar para cualquier sitio web que quieras redirigir con BCR y asegurar que tienes la configuración correcta.

  1. Abre Chrome y, a continuación, pulsa CTRL+MAYÚS+I para abrir sus herramientas de desarrollador.
  2. Haz clic en la ficha Red.
  3. Marca la opción Conservar registro.
  4. Haz clic en el filtro Doc para simplificar los registros de red.
  5. Haz clic derecho junto a Nombre y agrega la columna URL.
  6. Navega a github.com mientras las herramientas de desarrollador siguen abiertas.
  7. Inicia sesión en github.com.
  8. Anota todos los saltos intermedios entre la página inicial de github.com y su destino después de que se haya producido el inicio de sesión.
  9. Analiza los encabezados de solicitud/respuesta para determinar el tipo de autenticación como se especificó anteriormente.

Paso 2: Elegir un método de configuración

  1. Si solo tratas con autenticación basada en redirección y no necesitas redirigir varias aplicaciones web con diferentes necesidades (por ejemplo, una aplicación web con autenticación basada en redirección y otra aplicación web con autenticación basada en formularios en la página), puedes elegir el Método 1 para configurar el inicio de sesión único.

  2. Si tratas con autenticación basada en formularios en la página (o) tratas con varias aplicaciones web con diferentes mecanismos de autenticación (o) simplemente quieres más flexibilidad incluso si solo tienes autenticación basada en redirección, puedes elegir el Método 2.

Paso 3: Configurar

Método 1: Configurar el inicio de sesión único de BCR con directivas existentes

  1. Habilita la función en el VDA creando el siguiente valor de registro en la clave HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HDXMediaStream: Dword BrowserProfileSharing valor 1.
  2. Configura la directiva de configuración ACL de redirección de contenido del navegador con los sitios web que se van a redirigir. No hay cambios en la configuración en este aspecto.
  3. Si ya tienes URL configuradas en la directiva de sitios de autenticación, cópialas en la directiva de lista de bloqueo de redirección de contenido del navegador y deshabilita la directiva de sitios de autenticación.
  4. Si no has configurado sitios de autenticación/intermediarios previamente, identifica las URL intermedias (a partir de las interacciones de solicitud/respuesta en las herramientas de desarrollador del navegador, en la ficha Red, mientras realizas el flujo de autenticación sin la extensión BCR instalada) y configúralas en la lista de bloqueo.

Método 2: Configurar el inicio de sesión único de BCR con JSON

Crear bcrconfig.json

El archivo bcrconfig.json puede contener varias configuraciones de aplicaciones web. La extensión BCR intentará hacer coincidir la URL solicitada con una de las allowList especificadas por una de las aplicaciones en el array de aplicaciones y aplicará dinámicamente sus reglas relacionadas para decidir cómo manejar la redirección de página y el procesamiento de inicio de sesión único. Las siguientes claves se pueden utilizar para controlar cómo la extensión BCR trata una aplicación web (ten en cuenta que los valores booleanos deben estar en minúsculas según las especificaciones de JSON - solo true o false):

  • appName [valor de cadena, obligatorio]: Se utiliza principalmente de forma interna por la extensión y para fines de registro.
  • allowList [array de cadenas, obligatorio]: Una aplicación debe contener al menos una URL en allowList, que es la URL que se pretende redirigir para que el cliente renderice la página, no el VDA. Se pueden definir varias URL y se aceptan comodines. Las reglas de comodín son exactamente las mismas que las de la configuración ACL de redirección de contenido del navegador. Por ejemplo, para configurar todas las aplicaciones de Google para que se redirijan, utiliza el siguiente array:

    [“.google.com/”, “.google.com”, “.youtube.com”, “.youtube.com/”]

  • denyList [valor de cadena, opcional]: Define las URL a las que la aplicación web redirige al usuario cuando se requiere autenticación. Esta configuración es principalmente esencial para la autenticación basada en redirección, pero también se puede usar para evitar redirecciones específicas en algunos flujos de autenticación basados en formularios. Las URL enumeradas en esta clave no se redirigirán para que se produzca la autenticación del lado del servidor. También puedes usar esto cuando no se necesita compartir el perfil para restringir que sub-URL específicas de un dominio no se redirijan al cliente.
  • profileSharing [valor booleano, obligatorio]: Este es el valor clave que debe establecerse para asegurar que las cookies de autenticación de inicio de sesión único y otras cookies que almacenan las preferencias del usuario se compartan, garantizando un comportamiento consistente entre las páginas renderizadas del lado del servidor y del lado del cliente.

  • cookies [matriz de cadenas, opcional]: Define una o varias cookies de autenticación necesarias para que la aplicación web se cargue sin pedirte al usuario. La extensión evitará la redirección del lado del cliente hasta que se detecte que todas las cookies aquí enumeradas están configuradas para la URL de la aplicación web dada. Esta configuración se usa principalmente para la autenticación basada en formularios en la página, pero también se puede usar para la autenticación basada en redirección, además de especificar una lista de denegación (denyList) en ciertos escenarios.
  • deleteClientCache[valor booleano, opcional]: Si se usa el mecanismo de configuración bcrconfig.json, el cliente de BCR elimina la caché de su navegador de forma predeterminada para mejorar la seguridad. Este proceso ocurre cuando el usuario cierra todas las fichas redirigidas o inicia una página redirigida por primera vez en una sesión. Establece el valor de esta clave en false para evitar este comportamiento. Si el dispositivo cliente es de confianza, establecer esta clave en false puede mejorar la experiencia del usuario. Si el dispositivo cliente no es de confianza, no establecer esta clave (o establecerla en true) puede mejorar la postura de seguridad.
  • schemaVersion [valor de cadena, obligatorio]: Esto se usa principalmente de forma interna por la extensión y para fines de registro. En el momento de redactar este documento, su valor debe ser 2511.
Configuración de ejemplo
{
-  "apps": [
-  {
-  "appName": "myWebApp1",
-  "allowList": [
        "https://myWebApp1.com/*"
-  ],
-  "denyList": [],
-  "requires": {
-  "profileSharing": false,
        "cookies": []
-  }
-  },
-  {
-  "appName": "myWebApp2",
      "allowList": [
-  "https://myWebApp2.com/*"
      ],
      "denyList": [
-  "https://myWebApp2.com/authPortal/*"
-  ],
      "requires": {
        "profileSharing": true,
        "cookies": []
-  }
    },
    {
      "appName": "myWebApp3",
-  "allowList": [
        "https://*.myWebApp3.com/"
      ],
      "denyList": [
        "https://myWebApp3.com/authPortal/*"
      ],
      "requires": {
        "profileSharing": true,
        "cookies": [
          "requiredAuthCookie1",
          "requiredAuthCookie2"
        ]
      }
    }
  ],
  "preferences": {
    "deleteClientCache": true
  },
  "schemaVersion": "2511"
}
<!--NeedCopy-->

Aquí tienes un archivo bcrconfig.json de ejemplo. Sus elementos se explican en detalle a continuación:

La estructura JSON anterior contiene 3 aplicaciones con diferentes configuraciones:

Escenario myWebApp1, sin SSO:

  • El valor de la matriz de cadenas de la clave allowList especifica que todas las rutas dentro de https://myWebApp1.com deben redirigirse al cliente, excepto los valores que se enumeren en la clave denyList, si los hubiera.
  • El valor de la matriz de cadenas de la clave denyList está vacío, por lo que no se impedirá la redirección de ningún sitio de autenticación. Por lo tanto, la autenticación no se mantendrá estrictamente en el lado del servidor.
  • El valor booleano de la clave profileSharing se establece en false, por lo que no se compartirán con el cliente las cookies relacionadas con las entradas de allowList.
  • La matriz de cadenas de la clave cookies está vacía, pero se habría ignorado de todos modos, ya que la clave profileSharing está establecida en false.

myWebApp2, escenario de autenticación basado en redirección:

  • El valor de la matriz de cadenas de la clave allowList especifica que todas las rutas dentro de https://myWebApp2.com deben redirigirse al cliente, excepto los valores que se enumeren en la clave denyList, si los hubiera.

  • El valor de la matriz de cadenas de la clave denyList especifica que las rutas que comienzan con /authPortal/ bajo el dominio myWebApp2.com se evitarán de la redirección del lado del cliente para que se pueda realizar la autenticación del lado del servidor.

  • El valor booleano de la clave profileSharing se establece en true, por lo que las cookies relacionadas con las entradas de allowList se compartirán con el cliente y el inicio de sesión único se realizará correctamente.

  • La matriz de cadenas de la clave cookies está vacía, por lo que la extensión no esperará a que se establezca una cookie específica después de la autenticación del lado del servidor antes de que se compartan con el cliente.

myWebApp3, escenario de autenticación basado en formularios:

  • El valor de la matriz de cadenas de la clave allowList especifica que todas las rutas dentro de https://myWebApp3.com deben redirigirse al cliente, excepto los valores que se enumeren en la clave denyList, si los hubiera.
  • El valor de la matriz de cadenas de la clave denyList especifica que las rutas que comienzan con /authPortal/ bajo el dominio myWebApp2.com se evitarán de la redirección del lado del cliente para que se pueda realizar la autenticación del lado del servidor.
  • El valor booleano de la clave profileSharing se establece en true, por lo que las cookies relacionadas con las entradas de allowList se compartirán con el cliente.
  • La matriz de cadenas de la clave cookies contiene un nombre de cookie, por lo que la extensión esperará a que se establezca esta cookie después de la autenticación del lado del servidor. La cookie para la URL relacionada en allowList se compartirá con el cliente y se producirá la redirección del lado del cliente.
Preferencias
  • La clave deleteClientCache se establece en true, por lo que el cliente de BCR elimina su caché del navegador de forma predeterminada para mejorar la seguridad. Este es el comportamiento predeterminado incluso si la clave no está establecida.
Configurar la política de BCR

Una vez que hayas creado el archivo bcrconfig.json, sigue los pasos a continuación para configurar la configuración de la ACL de redirección de contenido del navegador para usar el contenido del archivo JSON.

  • Nombra el archivo con la extensión .bcrconfig.json, por ejemplo, myrules.bcrconfig.json.

  • Aloja el archivo JSON en un servidor web accesible para el VDA y anota la URL.

    Nota:

    El servidor debe permitir las descargas de archivos; los sitios de Microsoft IIS permiten las descargas de archivos JSON de forma predeterminada.

  • En Citrix Studio, en Políticas, agrega la URL del paso anterior a la configuración de la ACL de redirección de contenido del navegador:

    Nota:

    Otras entradas en la configuración de la ACL de redirección de contenido del navegador pueden permanecer. La extensión BCR prioriza la configuración de bcrconfig.json si surgen conflictos. Citrix recomienda trasladar toda la configuración a JSON para facilitar la administración, la configuración a nivel de aplicación y la escalabilidad.

  • Guarda la política e inicia una sesión para probar la configuración de la política.

    Nota:

    Después de establecer la política, puedes modificar el archivo bcrconfig.json alojado en cualquier momento para ajustarlo. El archivo se recarga y aplica los cambios solo cuando el proceso principal del navegador que ejecuta la extensión BCR se inicia o se reinicia.

    Nota:

    • En esencia, desde la perspectiva de la política, solo necesitas habilitar la política de redirección de contenido del navegador (que está habilitada de forma predeterminada) y configurar la política de configuración de la ACL de redirección de contenido del navegador con la URL que apunta al archivo JSON.

    • La configuración JSON se aplica actualmente a las siguientes políticas y las hace flexibles, pero el resto de las políticas continúan realizando las mismas acciones que antes.

      • Configuración de la ACL de redirección de contenido del navegador: Las URL en la ACL ahora se pueden configurar a través de JSON mediante la clave allowList.
      • Configuración de la lista de bloqueo de redirección de contenido del navegador: La lista de bloqueo ahora se puede configurar a través de JSON mediante la clave denyList.
      • Sitios de autenticación de redirección de contenido del navegador: Los sitios de autenticación también se pueden configurar a través de JSON mediante la clave denyList.
Compatibilidad con el inicio de sesión único