Prise en charge de l’authentification unique

Introduction

Browser Content Redirection offre désormais une expérience utilisateur simplifiée avec la prise en charge de l’authentification unique, permettant l’authentification côté VDA et le partage de cookies.

Cette amélioration élimine les connexions redondantes, augmentant la productivité en maintenant la persistance de l’authentification et des cookies entre les sessions BCR, même après la fermeture de la fenêtre BCR.

Cette expérience transparente améliore davantage la sécurité en garantissant que l’authentification provient du VDA, et non du client.

Sans authentification unique

• L’ouverture d’une page authentifiée dans BCR obligeait les utilisateurs à ressaisir leurs identifiants à chaque fois, rompant la persistance SSO.
• L’authentification unique (SSO) n’était maintenue que tant que la fenêtre BCR restait ouverte ; la fermeture et la réouverture de la fenêtre obligeaient les utilisateurs à répéter le processus de connexion.
• Le flux d’authentification se produisait depuis le client, obligeant les administrateurs à fournir un accès réseau aux sites d’authentification sécurisés depuis le périphérique client.

Avec authentification unique

• Les utilisateurs ne sont plus invités à saisir leurs identifiants (lorsqu’ils sont déjà authentifiés sur le VDA), car l’authentification unique (SSO) est préservée de manière transparente depuis le navigateur VDA.
• L’authentification se produit depuis le VDA, ce qui améliore la posture de sécurité en limitant les exigences réseau et l’exposition côté client, offrant une expérience considérablement améliorée et ininterrompue.

Configuration minimale requise

• Citrix Virtual Apps et Desktops 2511
• Citrix Workspace App pour Windows 2511
• Citrix Workspace App pour Linux 2511 (Aperçu)
• Extension de redirection de navigateur (Chrome ou Edge) 25.11 ou version ultérieure

Séquences d’authentification prises en charge

Deux types de séquences d’authentification sont actuellement pris en charge avec l’authentification unique BCR.

Authentification basée sur la redirection

Dans cette méthode standard, l’application utilise une redirection HTTP pour forcer l’utilisateur vers une page dédiée à l’authentification.

Par exemple, si un utilisateur tente d’accéder à https://my.intranet.app sans les cookies de session nécessaires, l’application web répondra par une redirection HTTP 302 vers le point de terminaison d’authentification, tel que https://my.intranet.app/auth .

Une fois que l’utilisateur s’est authentifié avec succès sur cette page, le navigateur est redirigé vers l’URL de l’application d’origine, incluant désormais les cookies d’authentification requis.

Authentification basée sur des formulaires intégrés à la page [Preview]

Cette méthode maintient l’utilisateur sur l’URL de l’application prévue tout en présentant dynamiquement l’interface de connexion.

Par exemple, si un utilisateur navigue vers une page protégée, telle que https://my.intranet.app , la page charge directement le formulaire d’authentification sans déclencher de redirection, car les cookies nécessaires sont manquants. Ce processus peut impliquer plusieurs échanges internes entre l’interface de la page et le fournisseur d’identité (IDP). Ces échanges se poursuivent jusqu’à ce qu’un cookie final et valide soit fourni et utilisé, accordant à l’utilisateur l’accès au contenu de la page d’origine.

Remarque :

Si votre scénario n’est pas couvert par les mécanismes spécifiés ci-dessus et qu’il n’est pas possible de configurer votre application web pour utiliser ces mécanismes, contactez l’équipe produit Citrix.

Configuration

Étape 0 : Introduction

Il existe deux méthodes pour configurer l’authentification unique (SSO) avec la redirection de contenu de navigateur (BCR). Le choix de la méthode de configuration dépend du mécanisme d’authentification des sites web BCR souhaités et de la flexibilité dont vous avez besoin pour configurer plusieurs applications web pour la prise en charge de l’authentification unique.

Méthode 1 : Cette méthode utilise les stratégies BCR existantes dans Web Studio et les applique pour prendre en charge l’authentification unique.

Avant l’introduction de la prise en charge de l’authentification unique, la stratégie « Sites d’authentification de redirection de contenu de navigateur » était utilisée pour spécifier les URL utilisées pour l’authentification (ou les pages intermédiaires) à rediriger vers le client afin de garantir l’absence d’interruption du flux.

Avec l’introduction de la prise en charge de l’authentification unique, la BCR exploitera les cookies d’authentification du navigateur côté VDA. Par conséquent, les URL de la stratégie des sites d’authentification doivent désormais être configurées dans la stratégie de liste de blocage de la redirection de contenu de navigateur. Cela garantit que l’authentification se fait via le VDA.

Méthode 2 : Cette méthode fonctionne sur une logique similaire à la Méthode 1, mais les URL sont configurées via JSON (bcrconfig.json) et l’URL JSON hébergée est appelée dans la stratégie ACL BCR. La configuration JSON offre une flexibilité supplémentaire.

1. Les entreprises utilisent plusieurs applications web dans leur environnement, et chaque application peut utiliser un mécanisme d’authentification différent en fonction de son implémentation. La nouvelle méthode JSON permet une configuration plus intuitive, robuste et évolutive.
2. Lorsqu’il s’agit d’authentification basée sur des formulaires intégrés à la page, la Méthode 1 n’offre pas de moyen de définir un cookie d’authentification spécifique, car il n’existe pas de stratégies pour prendre en charge une telle configuration. Par conséquent, si votre site web nécessite une authentification basée sur des formulaires intégrés à la page, JSON est la seule solution.

À l’avenir, JSON offre un moyen évolutif d’introduire des fonctionnalités plus robustes, et Citrix recommande d’essayer la configuration basée sur JSON.

Étape 1 : Déterminer le mécanisme d’authentification

Pour déterminer la méthode à utiliser pour votre configuration, la première étape consiste à déterminer le type de mécanisme d’authentification utilisé par votre application. Pour déterminer avec précision la méthode d’authentification de l’application web, la meilleure approche est de contacter l’administrateur de l’application web.

Si ce n’est pas une option, vous devez inspecter les interactions de requête/réponse dans les outils de développement du navigateur, sous l’onglet Réseau, tout en effectuant le flux d’authentification sans l’extension BCR installée. Les résultats suivants peuvent vous aider à déterminer le type d’authentification :

Pour l’authentification basée sur la redirection : Recherchez dans la colonne État une ou plusieurs réponses 302 (Redirection). Les réponses 302 doivent contenir un en-tête d’emplacement pointant vers la page d’authentification. Cette URL de page doit être définie dans la stratégie de liste de blocage de la redirection de contenu de navigateur si vous utilisez la Méthode 1 et dans la section denyList de la configuration de l’application dans le fichier bcrconfig.json si vous utilisez la Méthode 2.

Pour l’authentification basée sur des formulaires intégrés à la page : Recherchez dans la colonne Méthode plusieurs requêtes POST. L’une des dernières réponses à une requête POST doit renvoyer un en-tête set-cookie avec le cookie d’authentification spécifique à l’application web. Ce cookie doit être défini dans la section des cookies de la configuration de l’application dans le fichier bcrconfig.json. Comme la Méthode 1 ne prend pas en charge l’authentification basée sur des formulaires intégrés à la page, la Méthode 2 est la seule option de configuration pour ce scénario.

Exemple : Voici un exemple avec github.com. Cette méthode peut être utilisée pour tout site web que vous souhaitez rediriger avec BCR et vous assurer que vous avez la bonne configuration.

1. Ouvrez Chrome, puis appuyez sur CTRL+MAJ+I pour afficher ses outils de développement.
2. Cliquez sur l’onglet Réseau.
3. Cochez le paramètre Conserver le journal.
4. Cliquez sur le filtre Doc pour simplifier les journaux réseau.
5. Faites un clic droit à côté du Nom et ajoutez la colonne URL.
6. Accédez à github.com tant que les outils de développement sont ouverts.
7. Connectez-vous à github.com
8. Notez tous les sauts intermédiaires entre la page initiale de github.com et sa destination après la connexion.
9. Analysez les en-têtes de requête/réponse pour déterminer le type d’authentification comme spécifié ci-dessus.

Étape 2 : Choisissez une méthode de configuration

1. Si vous utilisez uniquement l’authentification basée sur la redirection et que vous n’avez pas besoin de rediriger plusieurs applications web avec des besoins différents (par exemple, une application web avec authentification basée sur la redirection et une autre application web avec authentification basée sur des formulaires intégrés), vous pouvez choisir la Méthode 1 pour configurer l’authentification unique.

2. Si vous utilisez l’authentification basée sur des formulaires intégrés (ou) si vous utilisez plusieurs applications web avec des mécanismes d’authentification différents (ou) si vous souhaitez simplement plus de flexibilité même si vous n’avez qu’une authentification basée sur la redirection, vous pouvez choisir la Méthode 2.

Étape 3 : Configurer

Méthode 1 : Configurer l’authentification unique BCR avec les stratégies existantes

1. Activez la fonctionnalité dans le VDA en créant la valeur de registre suivante dans le HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HDXMediaStream key: Dword BrowserProfileSharing value 1
2. Configurez la stratégie de configuration ACL de redirection de contenu de navigateur avec les sites web à rediriger. Aucun changement de configuration à ce niveau.
3. Si vous avez déjà configuré des URL dans la stratégie de sites d’authentification, copiez-les dans la stratégie de liste de blocage de redirection de contenu du navigateur et désactivez la stratégie de sites d’authentification.
4. Si vous n’avez pas configuré de sites d’authentification/intermédiaires auparavant, identifiez les URL intermédiaires (à partir des interactions requête/réponse dans les outils de développement du navigateur, sous l’onglet Réseau, lors de l’exécution du flux d’authentification sans l’extension BCR installée) et configurez-les dans la liste de blocage.

Méthode 2 : Configurer l’authentification unique BCR avec JSON

Création de bcrconfig.json

Le bcrconfig.json peut contenir plusieurs configurations d’applications web. L’extension BCR tentera de faire correspondre l’URL demandée à l’une des allowList spécifiées par l’une des applications du tableau d’applications et appliquera dynamiquement ses règles associées pour décider comment gérer la redirection de page et le traitement de l’authentification unique. Les clés suivantes peuvent être utilisées pour contrôler la manière dont une application web est traitée par l’extension BCR (veuillez noter que les valeurs booléennes doivent être en minuscules, conformément aux spécifications JSON - true ou false uniquement) :

• appName [string value, mandatory] : Ceci est principalement utilisé en interne par l’extension et à des fins de journalisation.

• allowList [string array, mandatory] : Une application doit contenir au moins une URL dans allowList, qui est l’URL destinée à être redirigée afin que le client rende la page, et non le VDA. Plusieurs URL peuvent être définies, et les caractères génériques sont acceptés. Les règles de caractères génériques sont exactement les mêmes que la configuration ACL de redirection de contenu du navigateur. Par exemple, pour configurer toutes les applications Google à rediriger, utilisez le tableau suivant :

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

• denyList [string value, optional] : Définit les URL vers lesquelles l’application web redirige l’utilisateur lorsque l’authentification est requise. Cette configuration est principalement essentielle pour l’authentification basée sur la redirection, mais elle peut également être utilisée pour empêcher des redirections spécifiques dans certains flux d’authentification basés sur des formulaires. Les URL listées dans cette clé ne seront pas redirigées afin que l’authentification côté serveur ait lieu. Vous pouvez également l’utiliser lorsque le partage de profil n’est pas nécessaire pour empêcher la redirection de sous-URL spécifiques d’un domaine vers le client.
• profileSharing [boolean value, mandatory] : C’est la valeur de clé qui doit être définie pour garantir que les cookies d’authentification unique et les autres cookies qui stockent les préférences de l’utilisateur soient partagés, assurant un comportement cohérent entre les pages rendues côté serveur et côté client.
• cookies [string array, optional] : Définit un ou plusieurs cookies d’authentification nécessaires au chargement de l’application web sans inviter l’utilisateur. L’extension empêchera alors la redirection côté client jusqu’à ce que tous les cookies listés ici soient détectés comme définis pour l’URL de l’application web donnée. Ce paramètre est principalement utilisé pour l’authentification basée sur des formulaires intégrés à la page, mais il peut également être utilisé pour l’authentification basée sur la redirection en plus de la spécification de denyList dans certains scénarios.
• deleteClientCache[boolean value, optional] : Si le mécanisme de configuration bcrconfig.json est utilisé, le client BCR supprime son cache de navigateur par défaut pour une sécurité renforcée. Ce processus se produit lorsque l’utilisateur ferme tous les onglets redirigés ou ouvre une page redirigée pour la première fois dans une session. Définissez la valeur de cette clé sur false pour empêcher ce comportement. Si le périphérique client est fiable, la définition de cette clé sur false peut améliorer l’expérience utilisateur. Si le périphérique client n’est pas fiable, ne pas définir cette clé (ou) la définir sur true peut améliorer la posture de sécurité.
• schemaVersion [string value, mandatory] : Ceci est principalement utilisé en interne par l’extension et à des fins de journalisation. Au moment de la rédaction de ce document, sa valeur doit être définie sur 2511.

Exemple de configuration

{
  "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-->

Voici un exemple de fichier bcrconfig.json. Ses éléments sont expliqués en détail ci-dessous :

La structure JSON ci-dessus contient 3 applications avec des configurations différentes :

Scénario myWebApp1, pas de SSO :

• La valeur du tableau de chaînes de la clé allowList spécifie que tous les chemins d’accès au sein de https://myWebApp1.com doivent être redirigés vers le client, à l’exception des valeurs listées dans la clé denyList, le cas échéant.
• La valeur du tableau de chaînes de la clé denyList est vide, donc aucun site d’authentification ne sera empêché de rediriger. Ainsi, l’authentification ne sera pas strictement conservée côté serveur.
• La valeur booléenne de la clé profileSharing est définie sur false, donc aucun cookie relatif aux entrées allowList ne sera partagé avec le client.
• Le tableau de chaînes de la clé des cookies est vide, mais il aurait été ignoré de toute façon puisque la clé de partage profileSharing est définie sur false.

myWebApp2, scénario d’authentification basé sur la redirection :

• La valeur du tableau de chaînes de la clé allowList spécifie que tous les chemins d’accès au sein de https://myWebApp2.com doivent être redirigés vers le client, à l’exception des valeurs listées dans la clé denyList, le cas échéant.

• La valeur du tableau de chaînes de la clé denyList spécifie que les chemins d’accès qui commencent par /authPortal/ sous le domaine myWebApp2.com seront empêchés de la redirection côté client afin que l’authentification côté serveur puisse être effectuée.

• La valeur booléenne de la clé profileSharing est définie sur true, donc les cookies relatifs aux entrées allowList seront partagés avec le client et l’authentification unique est effectuée.

• Le tableau de chaînes de la clé des cookies est vide, donc l’extension n’attendra pas qu’un cookie spécifique soit défini après l’authentification côté serveur avant qu’ils ne soient partagés avec le client.

myWebApp3, scénario d’authentification basé sur les formulaires :

• La valeur du tableau de chaînes de la clé allowList spécifie que tous les chemins d’accès au sein de https://myWebApp3.com doivent être redirigés vers le client, à l’exception des valeurs listées dans la clé denyList, le cas échéant.
• La valeur du tableau de chaînes de la clé denyList spécifie que les chemins d’accès qui commencent par /authPortal/ sous le domaine myWebApp2.com seront empêchés de la redirection côté client afin que l’authentification côté serveur puisse être effectuée.
• La valeur booléenne de la clé profileSharing est définie sur true, donc les cookies relatifs aux entrées allowList seront partagés avec le client.
• Le tableau de chaînes de la clé des cookies contient un nom de cookie, l’extension attendra donc que ce cookie soit défini après l’authentification côté serveur. Le cookie pour l’URL associée dans allowList sera partagé avec le client et une redirection côté client aura lieu.

Préférences

• La clé deleteClientCache est définie sur true, de sorte que le client BCR supprime son cache de navigateur par défaut pour une sécurité renforcée. C’est le comportement par défaut même si la clé n’est pas définie.

Configuration de la stratégie BCR

Une fois que vous avez créé le bcrconfig.json, suivez les étapes ci-dessous pour configurer la configuration ACL de redirection de contenu de navigateur afin d’utiliser le contenu du fichier JSON.

• Nommez le fichier avec l’extension .bcrconfig.json, par exemple, myrules.bcrconfig.json

• Hébergez le fichier JSON sur un serveur web accessible au VDA et notez l’URL.

  Remarque :

  Le serveur doit autoriser les téléchargements de fichiers ; les sites Microsoft IIS autorisent les téléchargements de fichiers JSON par défaut.

• Dans Citrix Studio, sous Stratégies, ajoutez l’URL de l’étape précédente au paramètre de configuration ACL de redirection de contenu de navigateur :

  Remarque :

  Les autres entrées du paramètre de configuration ACL de redirection de contenu de navigateur peuvent rester. L’extension BCR donne la priorité aux paramètres bcrconfig.json en cas de conflits. Citrix recommande de déplacer l’intégralité de la configuration vers JSON pour faciliter la gestion, la configuration au niveau de l’application et l’évolutivité.

• Enregistrez la stratégie et lancez une session pour tester la configuration de la stratégie.

  Remarque :

  Après avoir défini la stratégie, vous pouvez modifier le fichier bcrconfig.json hébergé à tout moment pour l’ajuster. Le fichier se recharge et applique les modifications uniquement lorsque le processus de navigateur principal exécutant l’extension BCR se lance ou se relance.

Remarque :

• En substance, du point de vue de la stratégie, il vous suffit d’activer la stratégie de redirection du contenu du navigateur (qui est activée par défaut) et de configurer la stratégie de configuration ACL de redirection du contenu du navigateur avec l’URL qui pointe vers le fichier JSON.

• La configuration JSON s’applique actuellement aux stratégies suivantes et les rend flexibles, mais le reste des stratégies continuent d’effectuer les mêmes actions qu’auparavant.

  • Configuration ACL de redirection du contenu du navigateur : Les URL dans l’ACL peuvent désormais être configurées via JSON à l’aide de la clé allowList.
  • Configuration de la liste de blocage de redirection du contenu du navigateur : La liste de blocage peut désormais être configurée via JSON à l’aide de la clé denyList.
  • Sites d’authentification de redirection du contenu du navigateur : Les sites d’authentification peuvent également être configurés via JSON à l’aide de la clé denyList.