Skip to main content

1. September 2026

Horizon Cloud-Umgebung mit Universal Broker – Architektur der Integration in Omnissa Access und Intelligent Hub-Dienste

Das folgende Diagramm veranschaulicht die Architektur und den Kommunikationsfluss der Komponenten in einer Horizon Cloud-Umgebung, die mit Universal Broker konfiguriert und in Access- und Intelligent Hub-Dienste integriert ist.

Architektur- und Kommunikationsflussdiagramm für die Integration zwischen Access, Hub-Diensten und Horizon Cloud-Mandant mit Universal Broker

  1. Während des Aktivierungsworkflows wird der Access-Mandant für die Integration in Ihren Horizon Cloud-Mandanten registriert.
  2. Der Access Connector synchronisiert den Access-Mandanten mit den Active Directory-Benutzern und -Gruppen.
  3. Der Benutzer authentifiziert sich über Access und fordert das Laden des Hub-Katalogs an.
  4. Die Workspace ONE Intelligent Hub-Dienste rufen Informationen über die Berechtigungen des Benutzers aus allen konfigurierten Quellen des Katalogs ab. Zu den Quellen können Access, Workspace ONE UEM, Okta und der Universal Broker-Dienst gehören.
  5. Der Hub-Katalog stellt dem Benutzer einen einheitlichen Katalog von Berechtigungen zur Verfügung. Der Katalog enthält die Zuweisungsberechtigungen des Benutzers, die vom Universal Broker-Dienst abgerufen wurden.
  6. Der Benutzer klickt im Katalog auf einen zugewiesenen Desktop oder eine zugewiesene Anwendung, um eine Verbindungssitzung zu starten.
  7. Die Workspace ONE Intelligent Hub-Dienste bereiten die Start-URL für die zugewiesene Ressource vor, indem sie mit Access kommunizieren und ein SAML-Artefakt generieren, das an die Universal Broker-URL angehängt wird. Die Dienste senden dann die Start-URL an den Workspace ONE Intelligent Hub-Client.
  8. Der Workspace ONE Intelligent Hub-Client startet den Horizon Client-Desktop oder die Webanwendung.
  9. Horizon Client leitet die Authentifizierungsanforderung an den Universal Broker-Dienst weiter.
  10. Durch die Kommunikation mit Access löst der Universal Broker-Dienst das SAML-Artefakt auf und validiert den vertrauenswürdigen Benutzer.
  11. Horizon Client fordert den zugewiesenen Desktop oder die zugewiesene Anwendung vom Universal Broker-Dienst an.
  12. Nachdem ermittelt wurde, welcher Pod die zugewiesene Ressource am besten bereitstellen kann, sendet der Universal Broker-Dienst eine Meldung an den Universal Broker-Client, der in diesem Pod ausgeführt wird. Der Universal Broker-Client leitet die Meldung an das Universal Broker-Plug-In weiter, das auf dem Verbindungsserver ausgeführt wird (für einen Horizon-Pod) oder an den aktiven Pod-Manager (für einen Pod in Microsoft Azure). Das Universal Broker-Plug-in oder der aktive Pod-Manager identifiziert die beste verfügbare Ressource, die dem Endbenutzer zugeteilt werden soll.
  13. Der Universal Broker-Dienst gibt eine Verbindungsantwort an Horizon Client zurück, die den eindeutigen FQDN des Pods enthält. Der eindeutige FQDN ist in der Regel entweder der FQDN des lokalen Lastausgleichs des Horizon-Pods oder des Lastausgleichsdiensts von Microsoft Azure.
  14. Nach dem Durchlaufen des Lastausgleichsdiensts wird die Anforderung an das Unified Access Gateway für den Pod übergeben. Unified Access Gateway überprüft, ob die Anforderung vertrauenswürdig ist, und bereitet Blast Secure Gateway, PCoIP Secure Gateway und den Tunnelserver vor.
  15. Der Benutzer erhält den zugewiesenen Desktop oder die zugewiesene Anwendung und richtet eine Verbindungssitzung basierend auf dem konfigurierten sekundären Protokoll (Blast Extreme, PCoIP oder RDP) ein.

War diese Seite hilfreich?

Feedback zu diesem Thema geben

War dieses Thema hilfreich?

Bitte geben Sie keine personenbezogenen oder vertraulichen Daten an.

Link wird erstellt…