Prise en charge de l’authentification unique

Introduction

La redirection de contenu de navigateur 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 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 améliore encore 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 informations d’identification à chaque fois, rompant la persistance de l’authentification unique.
• 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 Applications et Bureaux Virtuels 2507
• Citrix Workspace App pour Windows 2511
• Citrix Workspace App pour Linux 2601
• 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, comme 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 les mécanismes ci-dessus, contactez l’équipe produit Citrix.

Configuration

Étape 0 : Introduction

Il existe deux méthodes pour configurer l’authentification unique (Single sign-on) avec la RCR. Le choix de la méthode de configuration dépend du mécanisme d’authentification des sites web RCR 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 RCR existantes dans Web Studio et les utilise 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 d’assurer la continuité du flux.

Avec l’introduction de la prise en charge de l’authentification unique, la RCR exploitera les cookies d’authentification du 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) à la place et l’URL JSON hébergée est appelée dans la stratégie ACL de la RCR. 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’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 façon de le faire.

À 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 quelle 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 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 RCR 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. L’URL de cette 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 RCR et pour vous assurer que vous disposez de 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é de 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 : Choisir une méthode de configuration

1. 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), vous pouvez choisir la méthode 1 pour configurer l’authentification unique.

2. Si vous utilisez une 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’un des allowList spécifiés 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 affiche 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 clé qui doit être définie pour garantir le partage des cookies d’authentification unique et d’autres cookies qui stockent les préférences de l’utilisateur, 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, de sorte qu’aucun site d’authentification ne sera empêché de redirection. 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, de sorte qu’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 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é des 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 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 myWebApp3.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é des 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 se produira.

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 les 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 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 :

• 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 de la liste de contrôle d’accès (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 continue d’effectuer les mêmes actions qu’auparavant.

  • Configuration de la liste de contrôle d’accès (ACL) de redirection du contenu du navigateur : Les URL de l’ACL peuvent désormais être configurées via JSON via 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 via la clé denyList.
  • Sites d’authentification de redirection du contenu du navigateur : Les sites d’authentification peuvent également être configurés via JSON via la clé denyList.