Citrix Virtual Apps and Desktops

Prise en charge de l’authentification unique

April 8, 2026

Contributeur:

C C

Introduction

La redirection de contenu de navigateur (BCR) offre désormais une expérience utilisateur simplifiée grâce à 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 l’authentification et la persistance des cookies sur les sessions BCR, même après la fermeture de la fenêtre BCR.
Cette expérience fluide renforce 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 au sein de la BCR exigeait des utilisateurs qu’ils saisissent à nouveau leurs informations d’identification à chaque fois, rompant la persistance de l’authentification unique (SSO).
L’authentification unique n’était maintenue que tant que la fenêtre BCR restait ouverte ; la fermeture et la réouverture de la fenêtre forçaient 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 informations d’identification (lorsqu’ils sont déjà authentifiés sur le VDA), car l’authentification unique 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 et l’exposition du réseau côté client, offrant une expérience considérablement améliorée et ininterrompue.

Configuration minimale requise

Citrix Virtual Apps and 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 [Aperçu]

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 les mécanismes ci-dessus, contactez l’équipe produit Citrix.

Configuration

Étape 0 : Introduction

Il existe deux méthodes pour configurer l’authentification unique avec la 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 de 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 qu’il n’y ait pas d’interruption dans le flux.

Avec l’introduction de la prise en charge de l’authentification unique, la RCN exploitera les cookies d’authentification sur le navigateur côté VDA et, par conséquent, les URL de la stratégie de sites d’authentification doivent désormais être configurées dans la stratégie de liste de blocage de redirection de contenu de navigateur. Cela garantit que l’authentification s’effectue 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 de RCN. La configuration JSON offre une flexibilité supplémentaire.

Les entreprises utilisent plusieurs applications web dans leur environnement, et chaque application peut utiliser un mécanisme d’authentification différent basé sur son implémentation. La nouvelle méthode JSON permet une configuration plus intuitive, robuste et évolutive.
Lorsqu’il s’agit d’une 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.

Pour 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étermination du 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 consiste à contacter l’administrateur de l’application web.
Si ce n’est pas une option, vous devez inspecter les 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 RCN 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 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 réponses ultérieures à 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 la RCN et vous assurer que vous disposez de la bonne configuration.

Ouvrez Chrome, puis appuyez sur CTRL+MAJ+I pour afficher ses outils de développement.
Cliquez sur l’onglet Réseau.
Cochez le paramètre Conserver le journal.
Cliquez sur le filtre Doc pour simplifier les journaux réseau.
Cliquez avec le bouton droit à côté de Nom et ajoutez la colonne URL.
Naviguez vers github.com pendant que les outils de développement sont toujours ouverts.
Connectez-vous à github.com.
Notez tous les sauts intermédiaires entre la page initiale de github.com et sa destination après la connexion.
Analysez les en-têtes de requête/réponse pour déterminer le type d’authentification comme spécifié ci-dessus.

Étape 2 : Choix d’une méthode de configuration

Si vous ne traitez qu’une authentification basée sur la redirection et que vous n’avez pas besoin de rediriger plusieurs applications web avec des besoins variés (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 à la page), vous pouvez choisir la méthode 1 pour configurer l’authentification unique.
Si vous traitez une authentification basée sur des formulaires intégrés à la page (ou) si vous traitez 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 : Configuration

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

Activez la fonctionnalité dans le VDA en créant la valeur de registre suivante dans la clé HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HDXMediaStream : Dword BrowserProfileSharing valeur 1
Configurez la stratégie de configuration ACL de redirection de contenu de navigateur avec les sites web à rediriger. Aucun changement de configuration à ce niveau.
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 de navigateur et désactivez la stratégie de sites d’authentification.
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 RCN installée) et configurez-les dans la liste de blocage.

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

Création de bcrconfig.json

Le fichier bcrconfig.json peut contenir plusieurs configurations d’applications web. L’extension RCN 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 RCN (veuillez noter que les valeurs booléennes doivent être en minuscules conformément aux spécifications JSON - true ou false uniquement) :

appName [valeur de chaîne, obligatoire] : Ceci est principalement utilisé en interne par l’extension et à des fins de journalisation.
allowList [tableau de chaînes, obligatoire] : 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 de navigateur. Par exemple, pour configurer toutes les applications Google à rediriger, utilisez le tableau suivant :

[“.google.com/”, “.google.com”, “.youtube.com”, “.youtube.com/”]
denyList [valeur de chaîne, facultatif] : Définissez 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 [valeur booléenne, obligatoire] : 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 [tableau de chaînes de caractères, facultatif] : Définissez 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 répertorié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 spécifier une liste de refus (denyList) dans certains scénarios.
deleteClientCache [valeur booléenne, facultatif] : 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 démarre 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 l’appareil client est fiable, la définition de cette clé sur false peut améliorer l’expérience utilisateur. Si l’appareil client n’est pas fiable, ne pas définir cette clé (ou) la définir sur true peut renforcer la posture de sécurité.
schemaVersion [valeur de chaîne de caractères, obligatoire] : 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 différentes configurations :

Scénario myWebApp1, sans 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, de sorte qu’aucun site d’authentification ne sera empêché de redirection. Ainsi, l’authentification ne sera pas strictement maintenue côté serveur.
La valeur booléenne de la clé profileSharing est définie sur false, de sorte qu’aucun cookie relatif aux entrées allowList ne sera partagé avec le client.
Le tableau de chaînes de la clé 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 commençant par /authPortal/ sous le domaine myWebApp2.com seront empêchés de 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, de sorte que les cookies relatifs aux entrées allowList seront partagés avec le client et que l’authentification unique sera effectuée.
Le tableau de chaînes de la clé cookies est vide, de sorte que 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 des 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 commençant par /authPortal/ sous le domaine myWebApp2.com seront empêchés de 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, de sorte que les cookies relatifs aux entrées allowList seront partagés avec le client.
Le tableau de chaînes de la clé cookies contient un nom de cookie, de sorte que l’extension attendra 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 fichier 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 :

D’autres entrées dans le paramètre de configuration ACL de redirection de contenu de navigateur peuvent rester. L’extension BCR priorise les 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 est lancé ou relancé.

Remarque :
- Essentiellement, du point de vue de la stratégie, il vous suffit d’activer la stratégie de redirection de contenu de navigateur (qui est activée par défaut) et de configurer la stratégie de configuration ACL de redirection de contenu de 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 continue d’effectuer les mêmes actions qu’auparavant.
  - Configuration ACL de redirection de contenu de 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 de contenu de navigateur : La liste de blocage peut désormais être configurée via JSON à l’aide de la clé denyList.
  - Sites d’authentification de redirection de contenu de navigateur : Les sites d’authentification peuvent également être configurés via JSON à l’aide de la clé denyList.

La version officielle de ce document est en anglais. Certains contenus de la documentation Cloud Software Group ont été traduits de façon automatique à des fins pratiques uniquement. Cloud Software Group n'exerce aucun contrôle sur le contenu traduit de façon automatique, qui peut contenir des erreurs, des imprécisions ou un langage inapproprié. Aucune garantie, explicite ou implicite, n'est fournie quant à l'exactitude, la fiabilité, la pertinence ou la justesse de toute traduction effectuée depuis l'anglais d'origine vers une autre langue, ou quant à la conformité de votre produit ou service Cloud Software Group à tout contenu traduit de façon automatique, et toute garantie fournie en vertu du contrat de licence de l'utilisateur final ou des conditions d'utilisation des services applicables, ou de tout autre accord avec Cloud Software Group, quant à la conformité du produit ou service à toute documentation ne s'applique pas dans la mesure où cette documentation a été traduite de façon automatique. Cloud Software Group ne pourra être tenu responsable de tout dommage ou problème dû à l'utilisation de contenu traduit de façon automatique.

Cela vous a-t-il été utile ?

Prise en charge de l’authentification unique

April 8, 2026

Contributeur:

C C

April 8, 2026

Contributeur:

C C

Dans cet article

Introduction
Configuration minimale requise
Séquences d’authentification prises en charge
Configuration

Cela vous a-t-il été utile ?

Prise en charge de l’authentification unique

Introduction

Sans authentification unique

Avec authentification unique

Configuration minimale requise

Séquences d’authentification prises en charge

Authentification basée sur la redirection

Authentification basée sur des formulaires intégrés à la page [Aperçu]

Configuration

Étape 0 : Introduction

Étape 1 : Détermination du mécanisme d’authentification

Étape 2 : Choix d’une méthode de configuration

Étape 3 : Configuration

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

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

Création de bcrconfig.json

Exemple de configuration

Préférences

Configuration de la stratégie BCR

Dans cet article