Unterstützung für Single Sign-On

Einführung

Die Browser Content Redirection bietet jetzt eine optimierte Benutzererfahrung mit Single Sign-On-Unterstützung, die die VDA-seitige Authentifizierung und das Cookie-Sharing ermöglicht.

Diese Verbesserung eliminiert redundante Anmeldungen und steigert die Produktivität, indem die Authentifizierung und Cookie-Persistenz über BCR-Sitzungen hinweg aufrechterhalten wird, selbst nachdem das BCR-Fenster geschlossen wurde.

Diese nahtlose Erfahrung erhöht die Sicherheit zusätzlich, indem sie sicherstellt, dass die Authentifizierung vom VDA und nicht vom Client ausgeht.

Ohne Single Sign-On

• Das Öffnen einer authentifizierten Seite innerhalb von BCR erforderte von den Benutzern jedes Mal die erneute Eingabe ihrer Anmeldeinformationen, wodurch die SSO-Persistenz unterbrochen wurde.
• SSO wurde nur aufrechterhalten, solange das BCR-Fenster geöffnet blieb; das Schließen und erneute Öffnen des Fensters zwang die Benutzer, den Anmeldevorgang zu wiederholen.
• Der Authentifizierungsfluss erfolgte vom Client aus, wodurch Administratoren gezwungen waren, dem Clientgerät Netzwerkzugriff auf sichere Authentifizierungsseiten zu ermöglichen.

Mit Single Sign-On

• Benutzer werden nicht mehr zur Eingabe von Anmeldeinformationen aufgefordert (wenn sie bereits auf dem VDA authentifiziert sind), da SSO nahtlos vom VDA-Browser beibehalten wird.
• Die Authentifizierung erfolgt vom VDA aus, was die Sicherheit verbessert, indem clientseitige Netzwerkanforderungen und -exposition begrenzt werden, und eine deutlich verbesserte und unterbrechungsfreie Erfahrung bietet.

Mindestanforderungen

• Citrix Virtual Apps und Desktops 2511
• Citrix Workspace App für Windows 2511
• Citrix Workspace App für Linux 2511 (Vorschau)
• Browser-Umleitungs-Erweiterung (Chrome oder Edge) 25.11 oder höher

Unterstützte Authentifizierungssequenzen

Derzeit werden zwei Arten von Authentifizierungssequenzen mit BCR Single Sign-On unterstützt.

Umleitungsbasierte Authentifizierung

Bei dieser Standardmethode verwendet die Anwendung eine HTTP-Umleitung, um den Benutzer zu einer dedizierten Seite für die Authentifizierung zu zwingen.

Beispiel: Wenn ein Benutzer versucht, https://my.intranet.app ohne die erforderlichen Sitzungscookies zu erreichen, antwortet die Webanwendung mit einer HTTP 302-Umleitung zum Authentifizierungsendpunkt, z. B. https://my.intranet.app/auth .

Sobald sich der Benutzer auf dieser Seite erfolgreich authentifiziert hat, wird der Browser zurück zur ursprünglichen Anwendungs-URL umgeleitet, die nun die erforderlichen Authentifizierungscookies enthält.

Formularbasierte Authentifizierung auf der Seite [Preview]

Diese Methode hält den Benutzer auf der beabsichtigten Anwendungs-URL, während die Anmeldeschnittstelle dynamisch präsentiert wird.

Beispiel: Wenn ein Benutzer zu einer geschützten Seite navigiert, z. B. https://my.intranet.app , lädt die Seite das Authentifizierungsformular direkt, ohne eine Umleitung auszulösen, da die erforderlichen Cookies fehlen. Dieser Prozess kann mehrere interne Austausche zwischen der Seitenschnittstelle und dem Identitätsanbieter (IDP) umfassen. Diese Austausche werden fortgesetzt, bis ein endgültiges, gültiges Cookie bereitgestellt und verwendet wird, das dem Benutzer den Zugriff auf den Inhalt der ursprünglichen Seite gewährt.

Hinweis:

Falls Ihr Szenario nicht von den oben genannten Mechanismen abgedeckt wird und es nicht möglich ist, Ihre Webanwendung so einzurichten, dass sie die oben genannten Mechanismen verwendet, wenden Sie sich an das Citrix Produktteam.

Konfiguration

Schritt 0: Einführung

Es gibt zwei Methoden, um Single Sign-On mit BCR zu konfigurieren. Die Wahl der Konfigurationsmethode hängt vom Authentifizierungsmechanismus für die gewünschten BCR-Websites und der Flexibilität ab, die Sie benötigen, um mehrere Webanwendungen für die Single Sign-On-Unterstützung zu konfigurieren.

Methode 1: Diese Methode verwendet die vorhandenen BCR-Richtlinien in Web Studio und nutzt diese, um Single Sign-On-Unterstützung zu erreichen.

Vor der Einführung der Single Sign-On-Unterstützung wurde die Richtlinie „Browser Content Redirection Authentication Sites“ verwendet, um die URLs für die Authentifizierung (oder Zwischenseiten) anzugeben, die an den Client umgeleitet werden sollten, um einen Unterbruch im Ablauf zu vermeiden.

Mit der Einführung der Single Sign-On-Unterstützung nutzt BCR die Authentifizierungs-Cookies im VDA-seitigen Browser. Daher müssen die URLs in der Authentifizierungs-Sites-Richtlinie nun stattdessen in der Richtlinie „Browser Content Redirection Block List“ konfiguriert werden. Dies stellt sicher, dass die Authentifizierung über den VDA erfolgt.

Methode 2: Diese Methode funktioniert nach einer ähnlichen Logik wie Methode 1, aber die URLs werden stattdessen über JSON (bcrconfig.json) konfiguriert, und die gehostete JSON-URL wird in der BCR-ACL-Richtlinie aufgerufen. Die JSON-Konfiguration bietet zusätzliche Flexibilität.

1. Unternehmen verwenden in ihrer Umgebung mehrere Webanwendungen, und jede Anwendung kann je nach Implementierung einen anderen Authentifizierungsmechanismus verwenden. Die neue JSON-Methode ermöglicht eine intuitivere, robustere und skalierbarere Konfiguration.
2. Bei der Formularbasierten In-Page-Authentifizierung bietet Methode 1 keine Möglichkeit, ein spezifisches Authentifizierungs-Cookie festzulegen, da es keine vorhandenen Richtlinien gibt, die eine solche Konfiguration unterstützen. Wenn Ihre Website also eine Formularbasierte In-Page-Authentifizierung erfordert, ist JSON der einzige Weg, dies zu tun.

Mit Blick auf die Zukunft bietet JSON eine skalierbare Möglichkeit, robustere Funktionen einzuführen, und Citrix empfiehlt, die JSON-basierte Konfiguration auszuprobieren.

Schritt 1: Bestimmen des Authentifizierungsmechanismus

Um zu bestimmen, welche Methode Sie für Ihre Konfiguration verwenden sollen, müssen Sie zunächst herausfinden, welche Art von Authentifizierungsmechanismus Ihre Anwendung verwendet. Um die Authentifizierungsmethode der Webanwendung genau zu bestimmen, ist es am besten, den Administrator der Webanwendung zu kontaktieren.

Wenn dies keine Option ist, müssen Sie die Anforderungs-/Antwortinteraktionen in den Entwicklertools des Browsers unter der Registerkarte „Netzwerk“ überprüfen, während Sie den Authentifizierungsfluss ohne installierte BCR-Erweiterung durchführen. Die folgenden Ergebnisse können Ihnen helfen, den Authentifizierungstyp zu bestimmen:

Für umleitungsbasierte Authentifizierung: Suchen Sie in der Spalte „Status“ nach einer oder mehreren 302-Antworten (Umleitung). Die 302-Antworten sollten einen „Location“-Header enthalten, der auf die Authentifizierungsseite verweist. Diese Seiten-URL muss in der Richtlinie „Browser Content Redirection Block List“ festgelegt werden, wenn Sie Methode 1 verwenden, und im Abschnitt denyList der App-Konfiguration in der Datei bcrconfig.json, wenn Sie Methode 2 verwenden.

Für formularbasierte In-Page-Authentifizierung: Suchen Sie in der Spalte „Methode“ nach mehreren POST-Anfragen. Eine der späteren Antworten auf eine POST-Anfrage sollte einen „set-cookie“-Header mit dem webanwendungsspezifischen Authentifizierungs-Cookie zurückgeben. Dieses Cookie sollte im Abschnitt „cookies“ der App-Konfiguration in der Datei bcrconfig.json festgelegt werden. Da Methode 1 keine formularbasierte In-Page-Authentifizierung unterstützt, ist Methode 2 die einzige Konfigurationsoption für dieses Szenario.

Beispiel: Hier ist ein Beispiel mit github.com. Diese Methode kann für jede Website verwendet werden, die Sie mit BCR umleiten möchten, und stellt sicher, dass Sie die richtige Konfiguration haben.

1. Öffnen Sie Chrome und drücken Sie dann STRG+UMSCHALT+I, um die Entwicklertools aufzurufen.
2. Klicken Sie auf die Registerkarte Netzwerk.
3. Aktivieren Sie die Einstellung Protokoll beibehalten.
4. Klicken Sie auf den Filter Doc, um die Netzwerkprotokolle zu vereinfachen.
5. Klicken Sie mit der rechten Maustaste neben Name und fügen Sie die Spalte URL hinzu.
6. Navigieren Sie zu github.com, während die Entwicklertools noch geöffnet sind.
7. Melden Sie sich bei github.com an.
8. Beachten Sie alle Zwischenschritte zwischen der Startseite von github.com und dem Ziel, nachdem die Anmeldung erfolgt ist.
9. Analysieren Sie die Anforderungs-/Antwort-Header, um den Authentifizierungstyp wie oben angegeben zu bestimmen.

Schritt 2: Wählen Sie eine Konfigurationsmethode

1. Wenn Sie es nur mit umleitungsbasierter Authentifizierung zu tun haben und Sie keine Notwendigkeit haben, mehrere Webanwendungen mit unterschiedlichen Anforderungen umzuleiten (z. B. eine Webanwendung mit umleitungsbasierter Authentifizierung und eine andere Webanwendung mit seiteninterner formularbasierter Authentifizierung), können Sie Methode 1 wählen, um Single Sign-On zu konfigurieren.

2. Wenn Sie es mit seiteninterner formularbasierter Authentifizierung zu tun haben (oder) Sie es mit mehreren Webanwendungen mit unterschiedlichen Authentifizierungsmechanismen zu tun haben (oder) Sie einfach mehr Flexibilität wünschen, selbst wenn Sie nur umleitungsbasierte Authentifizierung haben, können Sie Methode 2 wählen.

Schritt 3: Konfigurieren

Methode 1: BCR Single Sign-On mit vorhandenen Richtlinien konfigurieren

1. Aktivieren Sie die Funktion im VDA, indem Sie den folgenden Registrierungswert in der HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HDXMediaStream key: Dword BrowserProfileSharing value 1 erstellen.
2. Konfigurieren Sie die Richtlinie zur ACL-Konfiguration der Browserinhaltsumleitung mit den umzuleitenden Websites. Keine Konfigurationsänderung in dieser Hinsicht.
3. Falls Sie bereits URLs in der Richtlinie für Authentifizierungswebsites konfiguriert haben, kopieren Sie diese in die Richtlinie für die Browserinhaltsumleitung-Blockierungsliste und deaktivieren Sie die Richtlinie für Authentifizierungswebsites.
4. Falls Sie zuvor keine Authentifizierungs-/Zwischenwebsites konfiguriert haben, identifizieren Sie die Zwischen-URLs (aus den Anforderungs-/Antwortinteraktionen in den Entwicklertools des Browsers, unter der Registerkarte „Netzwerk“, während Sie den Authentifizierungsfluss ohne installierte BCR-Erweiterung durchführen) und konfigurieren Sie diese in der Blockierungsliste.

Methode 2: BCR-Single Sign-On mit JSON konfigurieren

Erstellen von bcrconfig.json

Die bcrconfig.json kann mehrere Web-App-Konfigurationen enthalten. Die BCR-Erweiterung versucht, die angeforderte URL mit einer der allowList abzugleichen, die von einer der Apps im Apps-Array angegeben sind, und wendet dynamisch die zugehörigen Regeln an, um zu entscheiden, wie die Seitenumleitung und die Single Sign-On-Verarbeitung gehandhabt werden sollen. Die folgenden Schlüssel können verwendet werden, um zu steuern, wie eine Web-App von der BCR-Erweiterung behandelt wird (bitte beachten Sie, dass boolesche Werte gemäß den JSON-Spezifikationen klein geschrieben werden müssen – nur true oder false):

• appName [string value, mandatory]: Dies wird hauptsächlich intern von der Erweiterung und zu Protokollierungszwecken verwendet.

• allowList [string array, mandatory]: Eine App muss mindestens eine URL in allowList enthalten, die die URL ist, die umgeleitet werden soll, damit der Client die Seite rendert und nicht der VDA. Es können mehrere URLs definiert werden, und Platzhalter werden akzeptiert. Die Platzhalterregeln sind genau dieselben wie bei der Browserinhaltsumleitung-ACL-Konfiguration. Um beispielsweise alle Google-Apps zur Umleitung zu konfigurieren, verwenden Sie das folgende Array:

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

• denyList [string value, optional]: Definieren Sie die URLs, zu denen die Webanwendung den Benutzer umleitet, wenn eine Authentifizierung erforderlich ist. Diese Konfiguration ist hauptsächlich für die umleitungsbasierte Authentifizierung unerlässlich, kann aber auch verwendet werden, um bestimmte Umleitungen in einigen formularbasierten Authentifizierungsabläufen zu verhindern. In diesem Schlüssel aufgeführte URLs werden nicht umgeleitet, sodass eine serverseitige Authentifizierung erfolgt. Sie können dies auch verwenden, wenn keine Profilfreigabe erforderlich ist, um bestimmte Unter-URLs einer Domäne so einzuschränken, dass sie nicht an den Client umgeleitet werden.
• profileSharing [boolean value, mandatory]: Dies ist der Schlüsselwert, der festgelegt werden muss, um sicherzustellen, dass Single Sign-On-Authentifizierungscookies und andere Cookies, die Benutzereinstellungen speichern, gemeinsam genutzt werden, um ein konsistentes Verhalten zwischen serverseitig und clientseitig gerenderten Seiten zu gewährleisten.
• cookies [string array, optional]: Definieren Sie ein oder mehrere Authentifizierungscookies, die für das Laden der Webanwendung ohne Benutzeraufforderung erforderlich sind. Die Erweiterung verhindert dann die clientseitige Umleitung, bis alle hier aufgeführten Cookies für die angegebene Web-App-URL als gesetzt erkannt werden. Diese Einstellung wird hauptsächlich für die In-Page-Formularbasierte Authentifizierung verwendet, kann aber in bestimmten Szenarien auch für die umleitungsbasierte Authentifizierung zusätzlich zur Angabe von denyList genutzt werden.
• deleteClientCache[boolean value, optional]: Wenn der bcrconfig.json Konfigurationsmechanismus verwendet wird, löscht der BCR-Client standardmäßig seinen Browser-Cache zur Verbesserung der Sicherheit. Dieser Vorgang findet statt, wenn der Benutzer alle umgeleiteten Registerkarten schließt oder eine umgeleitete Seite zum ersten Mal in einer Sitzung startet. Setzen Sie den Wert dieses Schlüssels auf false, um dieses Verhalten zu verhindern. Wenn das Clientgerät vertrauenswürdig ist, kann das Setzen dieses Schlüssels auf false die Benutzerfreundlichkeit verbessern. Wenn das Clientgerät nicht vertrauenswürdig ist, kann das Nichtsetzen dieses Schlüssels (oder) das Setzen dieses Schlüssels auf true die Sicherheitslage verbessern.
• schemaVersion [string value, mandatory]: Dies wird hauptsächlich intern von der Erweiterung und zu Protokollierungszwecken verwendet. Zum Zeitpunkt der Erstellung dieses Dokuments sollte der Wert auf 2511 gesetzt sein.

Beispielkonfiguration

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

Hier ist eine Beispiel-bcrconfig.json-Datei. Ihre Elemente werden unten ausführlich erläutert:

Die obige JSON-Struktur enthält 3 Apps mit unterschiedlichen Konfigurationen:

myWebApp1-Szenario, kein SSO:

• Der String-Array-Wert des Schlüssels allowList gibt an, dass alle Pfade innerhalb von https://myWebApp1.com an den Client umgeleitet werden sollen, mit Ausnahme der im Schlüssel denyList aufgeführten Werte, falls vorhanden.
• Der String-Array-Wert des Schlüssels denyList ist leer, sodass keine Authentifizierungsseiten von der Umleitung ausgeschlossen werden. Die Authentifizierung wird also nicht strikt serverseitig gehalten.
• Der boolesche Wert des Schlüssels profileSharing ist auf false gesetzt, sodass keine Cookies, die sich auf die allowList-Einträge beziehen, mit dem Client geteilt werden.
• Das String-Array des Cookies-Schlüssels ist leer, wäre aber ohnehin ignoriert worden, da der Freigabeschlüssel profileSharing auf false gesetzt ist.

myWebApp2, umleitungsbasiertes Authentifizierungsszenario:

• Der String-Array-Wert des Schlüssels allowList gibt an, dass alle Pfade innerhalb von https://myWebApp2.com an den Client umgeleitet werden sollen, mit Ausnahme der im Schlüssel denyList aufgeführten Werte, falls vorhanden.

• Der String-Array-Wert des Schlüssels denyList gibt an, dass Pfade, die mit /authPortal/ unter der Domäne myWebApp2.com beginnen, von der clientseitigen Umleitung ausgeschlossen werden, damit eine serverseitige Authentifizierung durchgeführt werden kann.

• Der boolesche Wert des Schlüssels profileSharing ist auf true gesetzt, sodass Cookies, die sich auf die allowList-Einträge beziehen, mit dem Client geteilt werden und Single Sign-On durchgeführt wird.

• Das String-Array des Cookies-Schlüssels ist leer, sodass die Erweiterung nicht darauf wartet, dass ein bestimmtes Cookie nach der serverseitigen Authentifizierung gesetzt wird, bevor es mit dem Client geteilt wird.

myWebApp3, formularbasiertes Authentifizierungsszenario:

• Der String-Array-Wert des Schlüssels allowList gibt an, dass alle Pfade innerhalb von https://myWebApp3.com an den Client umgeleitet werden sollen, mit Ausnahme der im Schlüssel denyList aufgeführten Werte, falls vorhanden.
• Der String-Array-Wert des Schlüssels denyList gibt an, dass Pfade, die mit /authPortal/ unter der Domäne myWebApp2.com beginnen, von der clientseitigen Umleitung ausgeschlossen werden, damit eine serverseitige Authentifizierung durchgeführt werden kann.
• Der boolesche Wert des Schlüssels profileSharing ist auf true gesetzt, sodass Cookies, die sich auf die allowList-Einträge beziehen, mit dem Client geteilt werden.
• Das String-Array des Cookies-Schlüssels enthält einen Cookie-Namen, sodass die Erweiterung darauf wartet, dass dieser Cookie nach der serverseitigen Authentifizierung gesetzt wird. Der Cookie für die zugehörige URL in allowList wird mit dem Client geteilt und eine clientseitige Umleitung erfolgt.

Einstellungen

• Der Schlüssel deleteClientCache ist auf true gesetzt, sodass der BCR-Client standardmäßig seinen Browser-Cache löscht, um die Sicherheit zu erhöhen. Dies ist das Standardverhalten, auch wenn der Schlüssel nicht gesetzt ist.

Konfigurieren der BCR-Richtlinie

Nachdem Sie die bcrconfig.json erstellt haben, führen Sie die folgenden Schritte aus, um die Browser Content Redirection ACL-Konfiguration zu konfigurieren, um den Inhalt der JSON-Datei zu verwenden.

• Benennen Sie die Datei mit der Erweiterung .bcrconfig.json, zum Beispiel myrules.bcrconfig.json

• Hosten Sie die JSON-Datei auf einem Webserver, der für den VDA zugänglich ist, und notieren Sie die URL.

  Hinweis:

  Der Server muss Dateidownloads zulassen; Microsoft IIS-Sites erlauben JSON-Dateidownloads standardmäßig.

• Fügen Sie in Citrix Studio unter den Richtlinien die URL aus dem vorherigen Schritt zur Einstellung „Browserinhaltsumleitung ACL-Konfiguration“ hinzu:

  Hinweis:

  Andere Einträge in der Einstellung „Browserinhaltsumleitung ACL-Konfiguration“ können bestehen bleiben. Die BCR-Erweiterung priorisiert die bcrconfig.json-Einstellungen, wenn Konflikte auftreten. Citrix empfiehlt, die gesamte Konfiguration zur einfacheren Verwaltung, Anwendungskonfiguration und Skalierbarkeit auf JSON umzustellen.

• Speichern Sie die Richtlinie und starten Sie eine Sitzung, um die Richtlinienkonfiguration zu testen.

  Hinweis:

  Nachdem Sie die Richtlinie festgelegt haben, können Sie die gehostete bcrconfig.json-Datei jederzeit zur Feinabstimmung bearbeiten. Die Datei wird neu geladen und wendet Änderungen nur an, wenn der Hauptbrowserprozess, der die BCR-Erweiterung ausführt, gestartet oder neu gestartet wird.

Hinweis:

• Im Wesentlichen müssen Sie aus Richtliniensicht nur die Richtlinie zur Browserinhaltsumleitung (die standardmäßig aktiviert ist) aktivieren und die Richtlinie zur Browserinhaltsumleitung-ACL-Konfiguration mit der URL konfigurieren, die auf die JSON-Datei verweist.

• Die JSON-Konfiguration gilt derzeit für die folgenden Richtlinien und macht sie flexibel, aber die restlichen Richtlinien führen weiterhin die gleichen Aktionen wie zuvor aus.

  • Browserinhaltsumleitung-ACL-Konfiguration: URLs in der ACL können jetzt über JSON über den allowList Schlüssel konfiguriert werden.
  • Browserinhaltsumleitung-Blocklistenkonfiguration: Die Blockliste kann jetzt über JSON über den denyList Schlüssel konfiguriert werden.
  • Browserinhaltsumleitung-Authentifizierungswebsites: Authentifizierungswebsites können auch über JSON über den denyList Schlüssel konfiguriert werden.