Über den Identity Server

UiPath® Identity Server ist der Authentifizierungsdienst des eigenständigen Orchestrators.Es bietet eine sichere Authentifizierung und Tokenausgabe für Orchestrator und seine Verwaltungsportale.Identity Server implementiert die Standards OAuth 2.0 und OpenID Connect und lässt sich in Enterprise-Identitätssysteme wie Active Directory integrieren.Im folgenden Diagramm finden Sie Informationen zur Funktionsweise von Identity Server im eigenständigen Orchestrator.

Abbildung 1. Identity Server-Diagramm

Rolle innerhalb von Orchestrator

Identity Server ist verantwortlich für:

• Authentifizieren von Benutzern und Anwendungen, die auf Orchestrator zugreifen
• Zugriffs- und Identitätstoken ausstellen
• Unterstützung von OAuth-2.0- und OpenID-Connect-Flows
• Integration mit externen Identitätsanbietern (z. B. Active Directory, SAML-Anbieter)
• Single Sign-On (SSO) aktivieren
• Sichern der Kommunikation zwischen Orchestrator und dem Identity Management Portal

Orchestrator und seine Verwaltungsportale sind zur Authentifizierung auf Identity Server angewiesen.

Authentifizierungsflow in Orchestrator

1. Benutzerauthentifizierung

Wenn Sie auf den Orchestrator oder das Identitätsverwaltungsportal zugreifen:

• Die Anforderung wird an Identity Server umgeleitet.
• Identity Server validiert den Benutzer anhand von:
  • Lokale Konten, oder
  • Externe Identitätsanbieter (z. B. Active Directory, SAML).
• Bei erfolgreicher Authentifizierung stellt Identity Server ein Sicherheitstoken aus.

2. Tokenbasierter Zugriff

Nach der Authentifizierung:

• Ein OAuth-Zugriffstoken wird ausgestellt.
• Das Token begleitet nachfolgende Anfragen an Orchestrator.
• Orchestrator validiert das Token.
• Rollen und Berechtigungen bestimmen die Autorisierung.Identity Server übernimmt die Authentifizierung.Orchestrator erzwingt die Autorisierung.

Integration von Active Directory und Kerberos

In domänenverbundenen Umgebungen unterstützt der eigenständige Orchestrator die Kerberos-basierte Authentifizierung:

• Der Client löst den Orchestrator-Hostnamen mithilfe von DNS auf.
• Der Client erhält ein Kerberos Ticket Granting Ticket (TGT) von Active Directory.
• Der Client fordert ein Dienstticket für den konfigurierten Dienstprinzipalnamen (SPN) an.
• Der IIS-Webserver validiert das Kerberos-Ticket.
• Identity Server verarbeitet die authentifizierte Identität und stellt ein Plattformtoken aus.

Dies ermöglicht ein nahtloses Single Sign-On in Enterprise-Windows-Umgebungen.

Überlegungen zur hohen Verfügbarkeit

In Bereitstellungen mit mehreren Knoten:

• Identity Server läuft auf mehreren Knoten hinter einem Load Balancer.
• Clients greifen über einen gemeinsam genutzten Load-Balancer-Hostnamen auf Orchestrator und Identity Server zu.
• Redis speichert OAuth-Clientdaten und den Sitzungsstatus über Knoten hinweg zwischen und gewährleistet so eine konsistente Authentifizierung im gesamten Cluster.
• Der Service Principal Name (SPN) muss mit dem Hostnamen des Load Balancers übereinstimmen, wenn Kerberos verwendet wird.
• Wenn Sie von einem Setup mit einem einzelnen Knoten zu einem Setup mit mehreren Knoten wechseln, müssen Sie die öffentliche URL des Identity Server in der Datenbank und in der Datei UiPath.Orchestrator.dll.config aktualisieren.

Authentifizierung der externen Anwendung

Orchestrator unterstützt sicheren Zugriff für

• Externe Anwendungen
• API-Integrationen
• Kommunikation zwischen Roboter und Orchestrator

Anwendungen authentifizieren sich mit unterstützten OAuth-Flows (z. B. ROPC) und erhalten Token von Identity Server.

Sicherheitsmodell

Der eigenständige Orchestrator verwendet ein zentrales Authentifizierungsmodell:

• Identity Server führt die Authentifizierung durch.
• Orchestrator erzwingt die Autorisierung.
• Der tokenbasierte Zugriff sichert APIs und die Orchestrator-UI.
• Die Integration mit externen Identitätsanbietern (Active Directory, SAML) unterstützt Enterprise-Sicherheitsanforderungen.