- Erste Schritte
- Best Practices
- Organisationsmodellierung im Orchestrator
- Beste Praktiken für die Automatisierung (Automation Best Practices)
- Optimieren von Unattended-Infrastruktur mithilfe von Maschinenvorlagen
- Organisieren von Ressourcen mit Tags
- Exportieren von Rastern im Hintergrund
- Durchsetzung der Governance der Integration Service-Verbindung auf Benutzerebene
- Mandant
- Über den Kontext „Mandant“
- Suche nach Ressourcen in einem Mandanten
- Verwaltung von Robotern
- Verbindung von Robotern mit Orchestrator
- Speicherung von Roboterzugangsdaten in CyberArk
- Speichern der Kennwörter von Unattended-Robotern im Azure Key Vault (schreibgeschützt)
- Speichern der Anmeldeinformationen von Unattended-Robotern im HashiCorp Vault (schreibgeschützt)
- Speichern der Anmeldeinformationen von Unattended-Robotern im AWS Secrets Manager (schreibgeschützt)
- Löschen von getrennten und nicht reagierenden Unattended-Sitzungen
- Roboter-Authentifizierung
- Roboter-Authentifizierung mit Client-Anmeldeinformationen
- Konfigurieren von Automatisierungsfunktionen
- Solutions (Lösungen)
- Audit
- Einstellungen
- Registrierung
- Cloud Robots
- Übersicht über Cloud Robots
- Ausführen von Unattended-Automatisierungen mit Cloud Robot – VM
- Hochladen Ihres eigenen Image
- Wiederverwenden von benutzerdefinierten Maschinen-Images (für manuelle Pools)
- Zurücksetzen der Anmeldeinformationen für eine Maschine (für manuelle Pools)
- Überwachung
- Sicherheitsupdates
- Testversion anfordern
- Häufig gestellte Fragen
- Konfigurieren einer VPN für Cloud-Roboter
- Konfigurieren einer ExpressRoute-Verbindung
- Live-Streaming und Remotesteuerung
- Events
- Anzeigen und Zugreifen auf Benachrichtigungen
- Anzeigen und Zugreifen auf E-Mail-Benachrichtigungen
- Es werden nur ungelesene Benachrichtigungen angezeigt
- Alle Benachrichtigungen als gelesen markieren
- Alle Benachrichtigungen löschen
- Löschen von Benachrichtigungen
- Abonnieren von Ereignissen
- Abbestellen von Ereignissen
- Automation Suite-Roboter
- Ordnerkontext
- Prozesse
- Jobs
- Apps
- Auslöser
- Protokolle
- Überwachung
- Indizes
- Warteschlangen
- Assets
- Über Assets
- Verwalten von Assets in Orchestrator
- Verwalten von Assets in Studio
- Speichern von Assets im Azure Key Vault (schreibgeschützt)
- Speichern von Assets im HashiCorp Vault (schreibgeschützt)
- Speichern von Assets im AWS Secrets Manager (schreibgeschützt)
- Speichern von Assets in Google Secret Manager (schreibgeschützt)
- Verbindungen
- Geschäftsregeln
- Speicher-Buckets
- MCP-Server
- Testverfahren in Orchestrator
- Ressourcenkatalogdienst
- Integrationen
- Fehlersuche und ‑behebung
MCP-Verbindungen zum Authentifizieren von Remote-MCP-Servern bei externen Diensten unter Verwendung einer gemeinsamen Standardverbindung oder Verbindungen pro Benutzer.
Eine MCP-Verbindung ist eine Integration Service-Verbindung, die ein Remote-MCP-Server zur Authentifizierung ausgehender Aufrufe an den externen Server verwendet, den er weiterleitet. Sie autorisieren die Verbindung einmal für den Remotedienst und hängen sie dann an den Remote-MCP-Server an. Da eine Verbindung an eine bestimmte URL gebunden ist, kann sie nur mit einem Server verwendet werden, dessen URL übereinstimmt.
Zur Aufrufzeit fordert der Orchestrator ein neues Zugriffstoken von der Verbindung an und sendet es im Authorization -Header an den Remoteserver. Die Anmeldeinformationen werden von der Integration Service-Verbindung gespeichert und der MCP-Server speichert nur einen Verweis darauf, niemals das Token oder das Kennwort selbst.
Ihr UiPath-Bearer-Token wird niemals an den Remoteserver weitergeleitet. Der Remoteserver sieht nur die Anmeldeinformationen, die von der Verbindung oder von benutzerdefinierten Headern bereitgestellt werden, sodass Ihre UiPath-Identität die Plattform nie verlässt. Setup-Schritte finden Sie unter Erstellen eines Remote-MCP-Servers und Verwalten von MCP-Verbindungen.
So authentifiziert ein Remote-MCP-Server ausgehende Verbindungen
Ein Remote-MCP-Server unterstützt drei Möglichkeiten zur Authentifizierung beim Endpunkt, den er fortsetzt. Die richtige hängt davon ab, wie der Remotedienst aufgerufen werden soll.
| Method | Wie es konfiguriert ist | Wann es zutrifft |
|---|---|---|
| Keine ausgehende Authentifizierung | Sowohl Header als auch Verbindung sind leer. | Der Remoteserver ist geöffnet oder authentifiziert sich über einen Mechanismus, der hier nicht angegeben werden muss. |
| Benutzerdefinierte Header | Headerzeilen, die auf dem Server hinzugefügt wurden, z. B. Authorization: Bearer ... oder X-Api-Key: .... Eine Orchestrator-Asset-Referenz vermeidet das Speichern des Werts in Klartext, z. B. Authorization: %ASSETS/MyApiKey%. | Der Remotedienst verwendet ein statisches Token oder einen API-Schlüssel. |
| MCP-Verbindung | Eine Integration Service-Verbindung, die mit dem Server verbunden ist, entweder standardmäßig für jeden oder pro Benutzerkonto. | Der Remotedienst verwendet OAuth oder verschiedene Benutzer müssen mit ihren eigenen Anmeldeinformationen agieren. |
Wenn eine Verbindung angehängt ist, liefert sie den Authorization -Header für jeden Aufruf. Jeder Authorization -Header, der auch in benutzerdefinierten Headern festgelegt ist, wird in diesem Fall ignoriert, sodass nur das Token der Verbindung gesendet wird. Weitere Informationen zu Asset-gestützten Headern finden Sie unter Verwenden von Orchestrator-Assets auf MCP-Servern.
Standardverbindungen und benutzerspezifische Verbindungen
Ein Remote-MCP-Server kann Verbindungen auf zwei Ebenen verwenden:
- Standardverbindung: Eine einzelne Verbindung, die auf dem Server festgelegt und für alle freigegeben wird, die sie aufrufen. Nur Verbindungen aus einem freigegebenen Ordner können als Standard dienen. Wenn sich die Verbindung in einem anderen Ordner als dem MCP-Server befindet, benötigt der Aufrufer Zugriff auf beide Ordner.
- Verbindungen pro Benutzer: Verbindungen, die einzelnen Benutzerkonten zugeordnet sind. Wenn ein Benutzer den Server aufruft, wird seine eigene Verbindung anstelle der Standardverbindung verwendet. Eine Verbindung pro Benutzer kann aus einem freigegebenen Ordner oder aus dem persönlichen Arbeitsbereich dieses Benutzers stammen.
Zum Zeitpunkt des Aufrufs wählt UiPath eine Verbindung in der folgenden Reihenfolge aus:
- Die eigene Verbindung pro Benutzer des Aufrufers, wenn eine konfiguriert ist.
- Die Standardverbindung des Servers.
- Keine Verbindung. UiPath greift auf die benutzerdefinierten Header zurück oder sendet keine Authentifizierung, wenn keine festgelegt ist.
Eine Standardverbindung reicht aus, wenn eine gemeinsame Identität jeden Aufrufer bedient. Verbindungen pro Benutzer sind geeignet, wenn jeder Benutzer als er selbst gegenüber dem Remotedienst agieren muss.
Verbindungsstatus
Die Seite Verbindungen pro Benutzerkonto zeigt einen Status für jeden konfigurierten Benutzer an, der auf einen Blick angegeben ist, ob die Aufrufe dieses Benutzers authentifiziert werden.
| Status | Bedeutung | Resolution |
|---|---|---|
| Aktiv | Die Verbindung ist autorisiert und bereit. Aufrufe von diesem Benutzer verwenden es. | Nichts erforderlich. |
| Authentifizierung erforderlich | Für diesen Benutzer ist keine funktionierende Verbindung verfügbar: Es ist keine konfiguriert, oder die eigene Verbindung des Benutzers muss erneut autorisiert werden. | Der Benutzer oder ein Administrator fügt eine Verbindung für diesen Benutzer hinzu oder verbindet sie erneut. |
| Nicht verfügbar | Die freigegebene Standardverbindung fehlt, ist deaktiviert, abgelaufen oder nicht erreichbar. | Ein Administrator korrigiert oder ersetzt die Standardverbindung des Servers. |
| Inaktiv | Der Server ist nicht aktiv, oder die Verbindung ist deaktiviert. | Der Server ist aktiviert, oder die Verbindung ist in Integration Service aktiviert. |
Schritte zum Konfigurieren und Überprüfen von Verbindungen finden Sie unter Verwalten von MCP-Verbindungen.
Verbindung im Vergleich zum Verbindungstyp
Das Formular Remote-MCP-Server verfügt über zwei Einstellungen, deren Namen ähnlich aussehen, aber unterschiedlichen Zwecken dienen:
- Verbindung ist Authentifizierung: Die Integration Service-Verbindung, die zur Authentifizierung beim Remoteserver verwendet wird, wie auf dieser Seite beschrieben.
- Der Verbindungstyp ist Netzwerkweiterleitung: Standard erreicht den Remoteserver direkt über das öffentliche Internet, während Privat (Relay) einen lokalen Server über UiPath Relay erreicht, ohne eingehende Ports zu öffnen.
Der Verbindungstyp beeinflusst nicht, welche Anmeldeinformationen gesendet werden.