Single Sign-On-Unterstützung
Einleitung
Browser Content Redirection bietet jetzt eine optimierte Benutzererfahrung mit Single Sign-On-Unterstützung, die VDA-seitige Authentifizierung und das Teilen von Cookies ermöglicht.
-
Diese Verbesserung eliminiert redundante Anmeldungen und steigert die Produktivität durch die Aufrechterhaltung der Authentifizierung und Cookie-Persistenz über BCR-Sitzungen hinweg, selbst nachdem das BCR-Fenster geschlossen wurde.
-
Diese nahtlose Erfahrung verbessert die Sicherheit zusätzlich, indem sichergestellt wird, 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, ihre Anmeldeinformationen jedes Mal erneut einzugeben, 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, was Administratoren dazu zwang, Netzwerkzugriff auf sichere Authentifizierungsseiten vom Client-Gerät aus bereitzustellen.
-
Mit Single Sign-On
- Benutzer werden nicht mehr zur Eingabe von Anmeldeinformationen aufgefordert (wenn bereits am VDA authentifiziert), da SSO nahtlos vom VDA-Browser beibehalten wird.
- Die Authentifizierung erfolgt vom VDA aus, was die Sicherheitslage verbessert, indem clientseitige Netzwerkanforderungen und -exposition begrenzt werden, und eine erheblich verbesserte und unterbrechungsfreie Erfahrung bietet.
Mindestanforderungen
- Citrix Virtual Apps and Desktops 2511
- Citrix Workspace App für Windows 2511
- Citrix Workspace App für Linux 2511 (Vorschau)
- Browser Redirection Extension (Chrome oder Edge) 25.11 oder höher
Unterstützte Authentifizierungssequenzen
Es gibt zwei Arten von Authentifizierungssequenzen, die derzeit mit BCR Single Sign-On unterstützt werden.
Umleitungsbasierte Authentifizierung
Bei dieser Standardmethode verwendet die Anwendung eine HTTP-Umleitung, um den Benutzer auf eine dedizierte Seite zur Authentifizierung zu leiten.
Beispiel: Wenn ein Benutzer versucht, https://my.intranet.app ohne die erforderlichen Session-Cookies zu erreichen, antwortet die Webanwendung mit einer HTTP 302-Umleitung zum Authentifizierungsendpunkt, wie 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 Authentifizierungs-Cookies enthält.
In-Page-Formularbasierte Authentifizierung [Vorschau]
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, wie 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 Seitenoberfläche und dem Identitätsanbieter (IDP) umfassen. Diese Austausche dauern an, bis ein endgültiges, gültiges Cookie bereitgestellt und verwendet wird, wodurch dem Benutzer Zugriff auf den Inhalt der ursprünglichen Seite gewährt wird.
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: Einleitung
Es gibt zwei Methoden zur Konfiguration von Single Sign-On mit BCR. Die Wahl der Konfigurationsmethode hängt vom Authentifizierungsmechanismus für die gewünschten BCR-Websites und von 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 bestehenden BCR-Richtlinien in Web Studio und nutzt diese, um Single Sign-On-Unterstützung zu erreichen.
Vor der Einführung der Unterstützung für Single Sign-on wurde die Richtlinie für Authentifizierungswebsites der Browserinhaltsumleitung verwendet, um die URLs für die Authentifizierung (oder Zwischenseiten) anzugeben, die an den Client umgeleitet werden sollten, um einen unterbrechungsfreien Ablauf zu gewährleisten.
Mit der Einführung der Single Sign-on-Unterstützung nutzt BCR die Authentifizierungscookies im VDA-seitigen Browser. Daher müssen die URLs in der Richtlinie für Authentifizierungswebsites nun stattdessen in der Richtlinie für die Blockierungsliste der Browserinhaltsumleitung konfiguriert werden. Dies stellt sicher, dass die Authentifizierung über den VDA erfolgt.
Methode 2: Diese Methode basiert auf 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.
- 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.
- Bei der Formularbasierten In-Page-Authentifizierung bietet Methode 1 keine Möglichkeit, ein spezifisches Authentifizierungscookie 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 feststellen, welche Art von Authentifizierungsmechanismus Ihre Anwendung verwendet. Um die Authentifizierungsmethode der Webanwendung genau zu bestimmen, ist es am besten, den Webanwendungsadministrator 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 Authentifizierungsablauf 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 für die Blockierungsliste der Browserinhaltsumleitung 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 Authentifizierungscookie zurückgeben. Dieses Cookie sollte im Abschnitt cookies der App-Konfiguration in der Datei bcrconfig.json festgelegt werden. Da Methode 1 die formularbasierte In-Page-Authentifizierung nicht 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.
- Öffnen Sie Chrome, und drücken Sie dann <Strg>+<Umschalt>+I, um die Entwicklertools aufzurufen.
- Klicken Sie auf die Registerkarte Netzwerk.
- Aktivieren Sie die Einstellung Protokoll beibehalten.
- Klicken Sie auf den Filter Doc, um die Netzwerkprotokolle zu vereinfachen.
- Klicken Sie mit der rechten Maustaste neben Name und fügen Sie die Spalte URL hinzu.
- Navigieren Sie zu github.com, während die Entwicklertools noch geöffnet sind.
- Melden Sie sich bei github.com an.
- Beachten Sie alle Zwischenschritte zwischen der Startseite von github.com und dem Ziel nach der Anmeldung.
- Analysieren Sie die Anforderungs-/Antwort-Header, um den oben angegebenen Authentifizierungstyp zu bestimmen.
Schritt 2: Wählen Sie eine Konfigurationsmethode
-
Wenn Sie es nur mit umleitungsbasierter Authentifizierung zu tun haben und keine Notwendigkeit besteht, mehrere Webanwendungen mit unterschiedlichen Anforderungen umzuleiten (z. B. eine Webanwendung mit umleitungsbasierter Authentifizierung und eine andere Webanwendung mit formularbasierter In-Page-Authentifizierung), können Sie Methode 1 zur Konfiguration von Single Sign-on wählen.
-
Wenn Sie es mit formularbasierter In-Page-Authentifizierung zu tun haben (oder) mit mehreren Webanwendungen mit unterschiedlichen Authentifizierungsmechanismen (oder) 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
- Aktivieren Sie die Funktion im VDA, indem Sie den folgenden Registrierungswert im Schlüssel
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HDXMediaStreamerstellen:Dword BrowserProfileSharing value 1 - Konfigurieren Sie die BCR-ACL-Konfigurationsrichtlinie mit den umzuleitenden Websites. Es gibt keine Änderung in der Konfiguration in dieser Hinsicht.
- Falls Sie bereits URLs in der Richtlinie für Authentifizierungswebsites konfiguriert haben, kopieren Sie diese in die Richtlinie für die Blockierungsliste der Browserinhaltsumleitung und deaktivieren Sie die Richtlinie für Authentifizierungswebsites.
- Falls Sie zuvor keine Authentifizierungs-/Zwischenseiten konfiguriert haben, identifizieren Sie die Zwischen-URLs (aus den Anforderungs-/Antwortinteraktionen in den Entwicklertools des Browsers unter der Registerkarte „Netzwerk“, während Sie den Authentifizierungsablauf ohne installierte BCR-Erweiterung durchführen) und konfigurieren Sie diese in der Blockierungsliste.
Methode 2: BCR Single Sign-on mit JSON konfigurieren
bcrconfig.json erstellen
Die Datei bcrconfig.json kann mehrere Web-App-Konfigurationen enthalten. Die BCR-Erweiterung versucht, die angeforderte URL mit einer der in allowList angegebenen URLs einer der Apps im apps-Array abzugleichen und wendet dynamisch ihre 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äß JSON-Spezifikationen klein geschrieben werden müssen – nur true oder false):
- appName [String-Wert, obligatorisch]: Dies wird hauptsächlich intern von der Erweiterung und zu Protokollierungszwecken verwendet.
-
allowList [String-Array, obligatorisch]: Eine App muss mindestens eine URL in
allowListenthalten, die umgeleitet werden soll, damit der Client die Seite rendert, nicht der VDA. Es können mehrere URLs definiert werden, und Wildcards werden akzeptiert. Die Wildcard-Regeln sind genau dieselben wie bei der Browser Content Redirection ACL configuration. Um beispielsweise alle Google-Apps zur Umleitung zu konfigurieren, verwenden Sie das folgende Array:[“*.google.com/*”, “*.google.com”, “*.youtube.com”, “*.youtube.com/*”] - denyList [String-Wert, 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 die serverseitige Authentifizierung erfolgt. Sie können dies auch verwenden, wenn die Profilfreigabe nicht erforderlich ist, um bestimmte Unter-URLs einer Domäne von der Umleitung zum Client auszuschließen.
-
profileSharing [Boolescher Wert, obligatorisch]: 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 Authentifizierungs-Cookies, die für das Laden der Webanwendung ohne Benutzeraufforderung erforderlich sind. Die Erweiterung verhindert dann die clientseitige Weiterleitung, 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 formularbasierte In-Page-Authentifizierung verwendet, kann aber in bestimmten Szenarien auch zusätzlich zur Angabe einer Deny-Liste für die umleitungsbasierte Authentifizierung genutzt werden.
-
deleteClientCache [Boolescher Wert, optional]: Wenn der Konfigurationsmechanismus
bcrconfig.jsonverwendet wird, löscht der BCR-Client standardmäßig seinen Browser-Cache, um die Sicherheit zu erhöhen. Dieser Vorgang findet statt, wenn der Benutzer alle umgeleiteten Tabs 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 Client-Gerät vertrauenswürdig ist, kann das Setzen dieses Schlüssels auf false die Benutzererfahrung verbessern. Wenn das Client-Gerät nicht vertrauenswürdig ist, kann das Nichtsetzen dieses Schlüssels (oder) das Setzen dieses Schlüssels auf true die Sicherheitsposition verbessern. - schemaVersion [String-Wert, obligatorisch]: 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 im Folgenden detailliert erläutert:
Die obige JSON-Struktur enthält 3 Anwendungen mit unterschiedlichen Konfigurationen:
Szenario myWebApp1, kein SSO:
- Der String-Array-Wert des Schlüssels
allowListgibt an, dass alle Pfade innerhalb von https://myWebApp1.com zum Client umgeleitet werden sollen, mit Ausnahme der im SchlüsseldenyListaufgeführten Werte, falls vorhanden. - Der String-Array-Wert des Schlüssels
denyListist leer, sodass keine Authentifizierungsseiten von der Umleitung ausgeschlossen werden. Die Authentifizierung wird also nicht strikt serverseitig gehalten. - Der boolesche Wert des Schlüssels
profileSharingist auf false gesetzt, sodass keine Cookies, die sich auf dieallowList-Einträge beziehen, mit dem Client geteilt werden. - Der String-Array des Schlüssels
cookiesist leer, wäre aber ohnehin ignoriert worden, da derprofileSharing-Schlüssel auf false gesetzt ist.
myWebApp2, umleitungsbasiertes Authentifizierungsszenario:
-
Der String-Array-Wert des Schlüssels
allowListgibt an, dass alle Pfade innerhalb von https://myWebApp2.com zum Client umgeleitet werden sollen, mit Ausnahme der im SchlüsseldenyListaufgeführten Werte, falls vorhanden. -
Der String-Array-Wert des Schlüssels
denyListgibt 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
profileSharingist auf true gesetzt, sodass Cookies, die sich auf dieallowList-Einträge beziehen, mit dem Client geteilt werden und Single Sign-On erfolgt. -
Der String-Array des Schlüssels
cookiesist leer, sodass die Erweiterung nicht auf das Setzen eines bestimmten Cookies nach der serverseitigen Authentifizierung wartet, bevor diese mit dem Client geteilt werden.
myWebApp3, formularbasiertes Authentifizierungsszenario:
- Der String-Array-Wert des Schlüssels
allowListgibt an, dass alle Pfade innerhalb von https://myWebApp3.com zum Client umgeleitet werden sollen, mit Ausnahme der im SchlüsseldenyListaufgeführten Werte, falls vorhanden. - Der String-Array-Wert des Schlüssels
denyListgibt 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
profileSharingist auf true gesetzt, sodass Cookies, die sich auf dieallowList-Einträge beziehen, mit dem Client geteilt werden. - Der String-Array des Schlüssels
cookiesenthält einen Cookienamen, sodass die Erweiterung auf das Setzen dieses Cookies nach der serverseitigen Authentifizierung wartet. Das Cookie für die zugehörige URL inallowListwird mit dem Client geteilt und eine clientseitige Umleitung erfolgt.
Einstellungen
- Der Schlüssel
deleteClientCacheist auf true gesetzt, sodass der BCR-Client seinen Browser-Cache standardmäßig für erhöhte Sicherheit löscht. 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 so zu konfigurieren, dass sie den Inhalt der JSON-Datei verwendet.
-
Benennen Sie die Datei mit der Erweiterung
.bcrconfig.json, zum Beispielmyrules.bcrconfig.json. -
Hosten Sie die JSON-Datei auf einem für den VDA zugänglichen Webserver 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 „Browser Content Redirection ACL-Konfiguration“ hinzu:
Hinweis:
Andere Einträge in der Einstellung „Browser Content Redirection 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, anwendungsspezifischen Konfiguration und Skalierbarkeit auf JSON umzustellen. -
Speichern Sie die Richtlinie und starten Sie eine Sitzung, um die Richtlinienkonfiguration zu testen.
Hinweis:
Nach dem Festlegen der Richtlinie können Sie die gehostete
bcrconfig.json-Datei jederzeit zur Feinabstimmung bearbeiten. Die Datei wird neu geladen und Änderungen werden nur angewendet, 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 „Browser Content Redirection“ aktivieren (die standardmäßig aktiviert ist) und die Richtlinie „Browser Content Redirection 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 flexibler, aber die restlichen Richtlinien führen weiterhin die gleichen Aktionen wie zuvor aus.
-
Browser Content Redirection ACL-Konfiguration: URLs in der ACL können jetzt über JSON mittels des Schlüssels
allowListkonfiguriert werden. -
Browser Content Redirection Blocklist-Konfiguration: Die Blocklist kann jetzt über JSON mittels des Schlüssels
denyListkonfiguriert werden. -
Browser Content Redirection Authentifizierungsseiten: Authentifizierungsseiten können auch über JSON mittels des Schlüssels
denyListkonfiguriert werden.
-
Browser Content Redirection ACL-Konfiguration: URLs in der ACL können jetzt über JSON mittels des Schlüssels
-