- Démarrage
- Meilleures pratiques
- Modélisation de l'organisation dans Orchestrator
- Meilleures pratiques d'automatisation
- Optimisation de l'infrastructure Unattended à l'aide de modèles de machine
- Organisation des ressources avec des balises
- Exportation des grilles dans l'arrière-plan
- Appliquer la gouvernance de la connexion Integration Service au niveau de l'utilisateur
- Locataire
- À propos du contexte du locataire
- Recherche de ressources dans un locataire
- Gestion des Robots
- Connexion des Robots à Orchestrator
- Enregistrement des identifiants du Robot dans CyberArk
- Stockage des mots de passe de l’Unattended Robot dans Azure Key Vault (lecture seule)
- Stockage des informations d’identification de l’Unattended Robot dans HashiCorp Vault (lecture seule)
- Stockage des informations d'identification du robot Unattended dans AWS Secrets Manager (lecture seule)
- Suppression des sessions Unattended déconnectées et qui ne répondent pas
- Authentification du Robot
- Authentification du Robot avec les informations d'identification du client
- Configurer les capacités d’automatisation
- Solutions
- Audit
- Paramètres
- Registre
- Cloud Robots
- Présentation des robots cloud
- Exécution d'automatisations Unattended à l'aide de Cloud Robots - VM
- Téléchargement de votre propre image
- Réutilisation des images de machines personnalisées (pour les pools manuels)
- Réinitialisation des informations d'identification d'une machine (pour les pools manuels)
- Surveillance
- Mises à jour de sécurité
- Demander un essai
- Questions fréquemment posées
- Configuration du VPN pour les robots du cloud
- Configurer une connexion ExpressRoute
- Diffusion en direct et contrôle à distance
- Robots Automation Suite
- Contexte des dossiers
- Processus (Processes)
- Tâches (Jobs)
- Apps
- Déclencheurs (Triggers)
- Journaux (Logs)
- Surveillance
- Index
- Files d'attente (Queues)
- Actifs
- À propos des actifs
- Gestion des actifs dans Orchestrator
- Gestion des actifs dans Studio
- Stockage des ressources dans Azure Key Vault (lecture seule)
- Stockage des ressources dans HashiCorp Vault (lecture seule)
- Stockage des ressources dans AWS Secrets Manager (lecture seule)
- Stocker des ressources dans Google Secret Manager (lecture seule)
- Connexions
- Règles métier
- Compartiments de stockage
- Serveurs MCP
- Tests d'Orchestrator
- Service de catalogue de ressources
- Intégrations
- Résolution des problèmes
Guide de l'utilisateur d'Orchestrator
Lorsque les serveurs MCP s'exécutent localement (à l'aide de uipath run), l'authentification se produit à deux couches distinctes:
- Runtime vers le cloud: le runtime local s’authentifie afin de pouvoir enregistrer le serveur MCP auprès du cloud.
- Client vers le cloud: les clients externes s’authentifient lorsqu’ils appellent le point de terminaison du serveur MCP orienté vers le cloud.
Couche 1: runtime vers cloud (enregistrement du serveur)
La commande uipath run a besoin de son propre jeton pour enregistrer le serveur MCP auprès du Cloud. Il s'agit de l'authentification du développeur, de l'identité de la personne exécutant le serveur localement.
# Authenticate the runtime — interactive login
uipath auth
# Or authenticate the runtime — client credentials
uipath auth --client-id "..." \
--client-secret "..." \
--base-url "https://cloud.uipath.com/{org}/{tenant}" \
--scope "OR.Default"
# Start the local server
uipath run mcp-server
# Authenticate the runtime — interactive login
uipath auth
# Or authenticate the runtime — client credentials
uipath auth --client-id "..." \
--client-secret "..." \
--base-url "https://cloud.uipath.com/{org}/{tenant}" \
--scope "OR.Default"
# Start the local server
uipath run mcp-server
Le runtime utilise ce jeton pour établir une connexion SignalR au cloud et enregistrer les outils du serveur.
Couche 2: client vers cloud (appel du serveur)
Les clients externes (tels que Inspecteur MCP, cURL, un IDE ou tout client HTTP) s'authentifient auprès du cloud via l'une des quatre méthodes standard décrites dans Authentification du serveur MCP. L’URL est la même que pour tout autre serveur MCP:
https://cloud.uipath.com/{org}/{tenant}/agenthub_/mcp/{folderKey}/{slug}
https://cloud.uipath.com/{org}/{tenant}/agenthub_/mcp/{folderKey}/{slug}
Flux des demandes
Le jeton du porteur du client n'atteint jamais le runtime local. Le Cloud valide le jeton et transmet uniquement le message du protocole MCP via Redis. Le runtime local et le processus du serveur MCP ne voient pas le jeton.
Types de serveur MCP applicables
L’authentification « Ground-to-Cloud » s’applique aux types de serveur MCP qui ont un runtime local:
- Auto-hébergé: s’exécute toujours localement, utilise toujours l’authentification du terrain au cloud.
- Codé et commande: utilisez l’authentification du terrain vers le cloud lors de l’exécution locale via
uipath runlors du développement. Une fois déployés dans Orchestrator, ils s'exécutent sous forme de tâches cloud et aucun runtime local n'est impliqué.
Informations d’identification du client avec serveurs locaux
Lorsque vous utilisez les informations d'identification du client avec uipath run, définissez la variable d'environnement UIPATH_FOLDER_KEY . L’appel GetFoldersForCurrentUser du SDK Python ne prend pas en charge les informations d’identification du client. Pour plus de détails, consultez la section Limitation connue: GetFoldersForCurrentUser.