L'Orchestrator Credentials Proxy

Configurez Orchestrator Credentials Proxy pour connecter les plug-ins de magasin d'informations d'identification personnalisés à Orchestrator.

Vous pouvez ajouter vos propres magasins d'informations d'identification à Orchestrator, afin de contrôler indépendamment la sécurité de vos données de connexion.

Pour ce faire, vous pouvez charger les plug-ins du magasin d'informations d'identification souhaités, sous la forme de fichiers .dll, vers le service web Orchestrator Credentials Proxy. Le kit d'installation contient tous les plug-ins pris en charge par UiPath, mais vous pouvez également développer vos propres fichiers .dll de plug-ins à charger.

Ce service rend ensuite vos plug-ins disponibles sur Orchestrator via un proxy, qui est créé dans Orchestrator en fonction de l'URL publique et de la clé secrète générées par le proxy.

Problème connu

Port personnalisé réinitialisé sur 443 après une mise à niveau

Ce problème se produit uniquement si Orchestrator Credentials Proxy est configuré pour utiliser un port autre que le port 443 par défaut.

Lorsque vous effectuez une mise à niveau à partir de n’importe quelle version comprise entre les versions 1.0.0 et 2.0.1 et que vous avez utilisé un port personnalisé, le port local de la règle entrante UiPathOrchestratorCredentialsProxy est automatiquement remplacé par le port 443, soit le port par défaut. Cela empêche que la connexion au proxy soit établie.

Pour contourner ce problème, vous devez modifier manuellement le port local dans la règle entrante lors de la mise à niveau.

Installation

Le Orchestrator Credentials Proxy peut être installé via un programme d'installation .msi ou via une image Docker fournie par UiPath.

Via le fichier programme d'installation .msi

Prérequis

Orchestrator Credentials Proxy est une application Web ASP.NET Core hébergée dans IIS, vous pouvez donc l’installer sur n’importe quelle édition Windows pouvant héberger IIS 8.0 ou une version ultérieure. Cela inclut à la fois Windows Server et les clients Windows 10 et Windows 11. Windows Server n'est pas une exigence.

Prérequis matériels

Voici la configuration minimale requise pour exécuter le proxy sur une machine Windows avec IIS. Les besoins réels en ressources varient en fonction de l’utilisation individuelle.

Cœurs de processeur (CPU Cores)	RAM
2	4 Go

Prérequis logiciels

La machine qui héberge le proxy doit répondre aux exigences suivantes:

• Système d'exploitation : toute édition Windows qui prend en charge IIS 8.0 ou une version ultérieure. Windows Server 2012 R2, 2016, 2019, 2022 et 2025 répondent tous à cette exigence, tout comme Windows 10 et Windows 11.
• IIS : version 8.0 ou ultérieure.
• Bundle d'hébergement.NET : version 10.0 ou ultérieure pour Orchestrator Credentials Proxy 2.2.2 et versions ultérieures, qui s'exécute sur.NET 10. Les versions de proxy antérieures à la version 2.2.2 nécessitent la version 3.1 ou une version ultérieure. Le bundle installe à la fois le runtime ASP.NET Core et le module ASP.NET Core IIS, dont le proxy a besoin pour s’exécuter sous IIS.
  Important :

  Si vous effectuez une mise à niveau vers Orchestrator Credentials Proxy 2.2.2 ou une version ultérieure à partir d'une version antérieure, installez le Bundle d'hébergement.NET 10 sur la machine hôte et redémarrez IIS avant de démarrer le proxy mis à niveau. Sans cela, le proxy ne démarre pas sous IIS.

En outre, les fonctionnalités suivantes d'IIS doivent être activées:

• IIS-DefaultDocument
• IIS-HttpErrors
• IIS-StaticContent
• IIS-RequestFiltering
• IIS-URLAuthorization
• IIS-Authentification Windows
• IIS-ASPNET45
• IIS-ISAPIExtensions
• IIS-ISAPIFilter
• IIS-WebSockets
• IIS-ApplicationInit
• IIS-ManagementConsole

La façon dont vous activez ces fonctionnalités dépend de l'édition Windows:

• Windows Server : utilisez le Gestionnaire de serveur > Ajouter des rôles et des fonctionnalités.
• Windows 10 et Windows 11 : utilisez l’utilitaire Activer ou désactiver les fonctionnalités Windows sous Panneau de configuration > Programmes.

Remarque :

Le programme d’installation vérifie la version IIS, le module ASP.NET Core IIS et les fonctionnalités IIS répertoriées ci-dessus avant d’installer quoi que ce soit. Si l'un d'eux est manquant, l'installation s'arrête et signale ce qui doit être ajouté.

Étapes d'installation

Suivez ces étapes pour effectuer l'installation :

1. Téléchargez le programme d'installation de UiPath Orchestrator Credential Proxy sur le Customer Portal.
2. Installez le proxy.

Proxy connecté

• URL publique (Public URL) : l'URL du proxy d'identification d'Orchestrator qui est exposée publiquement.
• Certificat SSL (SSL Certificate) : le sujet ou l'empreinte du certificat SSL utilisé pour sécuriser les connexions avec l'Orchestrator Credentials Proxy. Il s'agit du certificat SSL installé sur l'ordinateur ou le serveur Web hébergeant le proxy. Notez que ce certificat doit être émis par un fournisseur de certificat public et qu’il doit être valide pour l’URL publique.
• Port - the port corresponding to the Public URL
• Secret Key - (automatically generated) the key needed for configuring a custom proxy in the Orchestrator interface; make sure to copy it to your clipboard for future use.

Vous pouvez modifier cet élément manuellement, sachant qu'il est également compatible avec la rotation des clés.

Proxy déconnecté

Cette fonctionnalité n'est disponible que si vous utilisez le plan de licence Enterprise - Avancé pour le plan Flex Pricing, ou Enterprise ou Application Test Enterprise pour le plan Unified Pricing.

• Certificat SSL : le sujet ou l'empreinte du certificat SSL utilisé pour sécuriser les connexions avec l'Orchestrator Credentials Proxy. Il s'agit du certificat SSL installé sur l'ordinateur ou le serveur Web hébergeant le proxy. Étant donné que les robots se connectent au proxy à l'intérieur de votre propre infrastructure, ce certificat peut être auto-signé ou émis par votre autorité de certification interne, tant que les machines exécutant vos robots lui donnent confiance.
• Port : le port correspondant à l’URL
• Secret Key - (automatically generated) the key needed for configuring a custom proxy in the Orchestrator interface; make sure to copy it to your clipboard for future use.

Vous pouvez modifier cet élément manuellement, sachant qu'il est également compatible avec la rotation des clés.

Remarque :

Dans le cas d'un proxy déconnecté, les robots se connectent directement au proxy, sans passer par Orchestrator. Cette connexion utilise HTTPS sur le port configuré pour l' URL publique du proxy (443 par défaut). Voir Gestion des proxys du magasin d'informations d'identification pour plus d'informations sur les types de proxy connectés et déconnectés.

Lors de l'installation, le paramètre AppSettings.CredentialsProxyType dans appsettings.Production.json est défini sur Déconnecté (Disconnected). C'est ainsi que le proxy détecte le type au démarrage.

Remarque :

L’option Authentification anonyme doit être définie sur Activé dans IIS pour que le proxy fonctionne.

Chiffrement du paramètre Jwt:Keys

Pour ajouter une couche de sécurité supplémentaire, vous pouvez chiffrer les paramètres Jwt:Keys et SecureStoreConfigurations:Context dans votre fichier appsettings.json .

Remarque :

Cela nécessite UiPath.ConfigProtector.exe la version 1.0.9 ou ultérieure.

Via l'image Docker

Informations préliminaires

Tous les paramètres de l'Orchestrator Credentials Proxy qui peuvent être modifiés sont disponibles dans son fichier appsettings.json. Les paramètres suivants sont importants dans la configuration initiale :

• Jwt:Keys : (initialement vide) ce tableau de chaînes est utilisé pour configurer l'authentification du proxy. Il s'agit de la clé secrète que vous utiliserez lors du processus de création du proxy et qui permet à Orchestrator de récupérer avec succès les données du proxy. Toutes les valeurs non valides sont ignorées. Si aucune valeur valide n'est trouvée, le proxy ne se lancera pas.

Les clés secrètes doivent être au format base64 et peuvent être générées à l'aide de l'un des scripts PowerShell ci-dessous.

$bytes = [System.Security.Cryptography.RandomNumberGenerator]::GetBytes(64)
$jwtSigningKey = [Convert]::ToBase64String($bytes);
Write-Host $jwtSigningKey

Le script ci-dessus génère 64 octets aléatoires (en utilisant SeccureRandom) et les convertit en chaîne base64.

[Byte[]] $bytes = 1..64
$rng = New-Object System.Security.Cryptography.RNGCryptoServiceProvider
$rng.GetBytes($bytes)
$jwtSigningKey = [Convert]::ToBase64String($bytes);
Write-Host $jwtSigningKey

• appSettings:Plugins.SecureStores : (initialement défini sur les magasins d'informations d'identification par défaut disponibles dans Orchestrator) il s'agit d'une chaîne CSV utilisée pour spécifier les assemblys .dll à charger depuis le disque (à partir de path/plugins) afin de permettre l'utilisation des magasins sécurisés par le proxy. L'ajout d'assemblys non valides à la liste n'interrompra pas le démarrage, mais vous recevrez des erreurs de journal lors du déploiement.
• appSettings:SigningCredentialSettings:FileLocation:SigningCredential:FilePath et appSettings:SigningCredentialSettings:FileLocation:SigningCredential:Password : (initialement masqués) à utiliser pour chiffrer les paramètres Jwt:Keys et SecureStoreConfigurations:Context. Il s’agit du chemin d’accès au fichier de votre certificat de signature.
• appSettings:SigningCredentialSettings:StoreLocation:Name, appSettings:SigningCredentialSettings:StoreLocation:Location, appSettings:SigningCredentialSettings:StoreLocation:NameType : (initialement masqués) à utiliser pour chiffrer les paramètres Jwt:Keys et SecureStoreConfigurations:Context.

Configuration et exécution de l'image Docker

Pour exécuter un Orchestrator Credentials Proxy à l'aide de Docker, effectuez les étapes suivantes.

1. Télécharger l'image Docker

Vous pouvez télécharger l'image à l'adresse suivante : http://registre.uipath.com/.

Remarque :

Assurez-vous d'inclure la version requise d'Orchestrator Credentials Proxy dans l'URL. Par exemple, pour télécharger l'image pour la version 2.1.4, utilisez:

http://registry.uipath.com/orchestrator-credentialsproxy:2.1.4

Cette URL pointe vers une image Docker et doit être accessible via la CLI Docker, et non via un navigateur Web.

Notez que la version 1.0.0 ne prend en charge que le proxy connecté, tandis que les versions 2.0.0 et ultérieures prennent également en charge le proxy déconnecté.

Utilisez cette commande pour obtenir l'image :

$bytes = [System.Security.Cryptography.RandomNumberGenerator]::GetBytes(64);
$jwtSigningKey = [Convert]::ToBase64String($bytes);
docker run -e LICENSE_AGREEMENT=accept -e Jwt__Keys__0=$jwtSigningKey -p 8000:8080 registry.uipath.com/orchestrator-credentialsproxy:1.0.0

Il s'agit de l'image UiPath par défaut, qui contient les magasins d'informations d'identification déjà disponibles dans votre compte cloud. Vous pouvez déployer l'image dans l'environnement cloud de votre choix.

La commande ci-dessus génère également la clé secrète.

2. Créer votre propre image Docker personnalisée

Vous pouvez créer votre propre image Docker, avec des assemblys supplémentaires, sur la base de l'image fournie par UiPath et téléchargée à l'étape 1. Pour ce faire :

1. Créez un fichier Dockerfile (à des fins d'illustration, nous le nommerons CustomDockerfile) et ajoutez-y les éléments suivants :

   FROM {docker-image-path}
   RUN rm -rf ./plugins 
   COPY --chown=1001:0 {path of your custom assemblies} ./plugins 
   ENTRYPOINT ["dotnet", "UiPath.OrchestratorCredentialsProxy.dll"]
   

   • Remplacez {docker-image-path} par le chemin d'accès à l'image Docker initiale, fournie par UiPath.
   • Remplacez {path of your custom assemblies} par le chemin d'accès à vos propres fichiers .dll .Découvrez comment Visual Studio utilise ce fichier Dockerfile pour générer vos images et ainsi accélérer le débogage.
2. Générez l'image Docker à l'aide de cette commande, qui inclut le nom du fichier Docker nouvellement créé :

   docker build -f CustomDockerfile . -t customproxy
   

3. Exécutez l'image Docker :

   docker run --publish 8000:8080 -e LICENSE_AGREEMENT="accept" -e Jwt__Keys__0=$jwtSigningKey -e appSettings__Plugins.SecureStores="{your-list-of-assemblies}" customproxy
   

   • Remplacez {your-list-of-assemblies} par les fichiers .dll des magasins d'informations d'identification personnalisés que vous souhaitez ajouter à Orchestrator.

Pour exécuter l'image avec un paramètre Jwt:Keys :

  ```
  docker run --publish 8000:8080 -e LICENSE_AGREEMENT="accept" -e Jwt__Keys__0=$jwtSigningKey {docker-image-name}
  ```

Pour exécuter l'image avec plusieurs paramètres Jwt:Keys :

  ```
  docker run --publish 8000:8080 -e LICENSE_AGREEMENT="accept" -e Jwt__Keys__0==$jwtSigningKey" -e Jwt__Keys__1==$jwtSigningKey" -e Jwt__Keys__2==$jwtSigningKey ... {docker-image-name}
  ```
  * Replace `{docker-image-name}` with the name you set for your custom Docker image.

Pour exécuter l'image avec une valeur personnalisée pour le paramètre appSettings:Plugins.SecureStores (c'est-à-dire avec le magasin d'informations d'identification souhaité), remplacez le contenu de ce paramètre par vos propres fichiers .dll : du magasin d'informations d'identification :

  ```
  docker run --publish 8000:8080 -e LICENSE_AGREEMENT="accept" -e Jwt__Keys__0=$jwtSigningKey -e appSettings__Plugins.SecureStores="UiPath.Orchestrator.CyberArk.dll;UiPath.Orchestrator.AzureKeyVault.SecureStore.dll" {docker-image-name}
  ```

4. (facultatif) Testez la nouvelle image Docker

Pour tester votre image, accédez à son interface Swagger sur http://localhost:8000/swagger/index.html et vérifiez si le point de terminaison /Health non authentifié dédié fonctionne. Une requête réussie renvoie une réponse vide avec un code de statut HTTP 200 OK.

Configuration

Proxy connecté et déconnecté

La première étape de configuration de votre proxy consiste à ajouter les fichiers .dll que vous souhaitez utiliser dans le dossier C:\Program Files\UiPath\CredentialsProxy\plugins.

Certains magasins d’informations d’identification peuvent vous obliger à configurer les paramètres au niveau de l’application, de l’hôte ou du proxy. Les paramètres sont équivalents à leurs homologues Orchestrator. Vous devez spécifier ces paramètres dans le fichier appsettings.Production.json du proxy.

CyberArk

Vous devez ajouter tous les paramètres au niveau de l’hôte tels que CLIPasswordSDKExePath, UsePowerShellCLI et AdditionalAllowedCharacters sous le paramètre Appsettings dans le fichier appsettings.Production.json :

{
// ...
  "AppSettings": {
    "Plugins.SecureStores.CyberArk.CLIPasswordSDKExePath": "D:\\PathName\\CLIPasswordSDK.exe",
    // ...
  }
  // ...
}

CyberArk CCP

Le Credentials Proxy s'exécute sous un compte de service qui n'a aucun profil d'utilisateur chargé. Par défaut, il utilise un magasin de clés qui nécessite un profil d'utilisateur chargé, qui n'est pas disponible pour le compte de service, de sorte que la clé privée du certificat du client CyberArk CCP ne puisse pas se charger et la récupération des informations d'identification via CyberArk CCP échoue. Pour charger le certificat correctement dans ce contexte, vous devez ajouter ce qui suit à appsettings.Production.json:

{
// ...
  "AppSettings": {
    "Plugins.SecureStores.CyberArkCCP.KeyStorageFlags": "MachineKeySet",
    // ...
  }
  // ...
}

HashiCorp Vault

Deux types de paramètres contrôlent les magasins d’informations d’identification HashiCorp Vault et HashiCorp Vault (lecture seule) :

• Les paramètres au niveau de l’hôte régissent le comportement du plug-in pour l’ensemble du proxy. Vous les ajoutez sous AppSettings dans le fichier appsettings.Production.json, préfixé avec le nom du magasin. Ils s’appliquent aux deux types de proxy.
• Les paramètres de contexte décrivent une connexion au coffre. Un proxy déconnecté les lit à partir de la section SecureStoreConfigurations du même fichier, comme illustré dans la section Exemples de configuration . Un proxy connecté les reçoit d'Orchestrator à la place.

Pour connaître la signification de chaque paramètre de contexte et la façon dont SecretsEngineMountPath et DataPath se résolvent au chemin d'une clé secrète individuelle, consultez HashiCorp Vault dans la section Gestion des magasins d'informations d'identification. Chaque clé JSON est le libellé de champ de cette page sans les espaces, à l'exception de LdapUseDynamicCredentials, qui est (Ldap) Utiliser les informations d'identification dynamiques, et KerberosSPN, qui est un SPN complet Kerberos.

Paramètres au niveau de l'hôte

Chaque magasin lit uniquement son propre préfixe — Plugins.SecureStores.HashiCorp Vault. ou Plugins.SecureStores.HashiCorp Vault (read only). — afin de configurer les deux magasins, ajoutez chaque paramètre deux fois.

Paramètre	Default	Description
KerberosEnabled	false	Renvoie les types d'authentification KerberosUserPassword et KerberosDefaultCredentials disponibles. Kerberos n'est pas disponible lorsque le proxy s'exécute à partir de l'image Docker, quel que soit ce paramètre.
ForwardToActiveNode	false	Ajoute l'en-tête X-Vault-Forward: active-node à chaque requête, de sorte qu'un nœud de secours de performances le transmet au nœud actif. Vault Enterprise uniquement.
ClientCacheDurationSeconds	600	Durée pendant laquelle un client Vault authentifié reste mis en cache entre les opérations.
MaxRetries	5	Nombre de fois que le plug-in retente une requête Vault qui renvoie HTTP 403, 412, 429, 500 ou 503.
RetryDelayMilliseconds	3000	Délai entre chaque nouvelle tentative. Avec les valeurs par défaut, une erreur d'autorisation prend environ 15 secondes à apparaître.

Pour activer le protocole d’authentification Kerberos et activer le transfert de noeud pour HashiCorp Vault, ajoutez les paramètres suivants au fichier appsettings.Production.json :

{
// ...
  "AppSettings": {
    "Plugins.SecureStores.HashiCorp Vault.KerberosEnabled": "true", // Optional, for Kerberos enablement
    "Plugins.SecureStores.HashiCorp Vault.ForwardToActiveNode": "true", // Optional, for forwarding to active node
    // ...
  }
  // ...
}

Si le proxy atteint Vault via un proxy de transfert, configurez-le avec les paramètres suivants:

• HttpProxy.Outbound.Enabled
• HttpProxy.Outbound.Address
• HttpProxy.Outbound.Username
• HttpProxy.Outbound.Password

Elles ne sont pas précédées d'un nom de magasin et s'appliquent à chaque plug-in de magasin d'informations d'identification chargé par le proxy.

HashiCorp Vault (lecture seule)

Le magasin en lecture seule accepte les mêmes paramètres de contexte et les mêmes paramètres au niveau de l'hôte que le magasin en lecture seule, avec deux différences:

• Elle accepte également ActiveDirectory, OpenLDAP et LDAP comme valeur SecretsEngine.
• Vous enregistrez vous-même les clés secrètes dans le coffre, dans la disposition attendue par Orchestrator. Voir Stockage des ressources dans HashiCorp Vault (lecture seule) et Stockage des informations d'identification de l'Unattended Robot dans HashiCorp Vault (lecture seule).

Pour activer le protocole d’authentification Kerberos pour HashiCorp Vault (lecture seule), ajoutez les paramètres suivant au fichier appsettings.Production.json :

{
// ...
  "AppSettings": {
    "Plugins.SecureStores.HashiCorp Vault (read only).KerberosEnabled": "true", // Optional, for Kerberos enablement
    "Plugins.SecureStores.HashiCorp Vault (read only).ForwardToActiveNode": "true", // Optional, for forwarding to active node
    // ...
  }
  // ...
}

Proxy déconnecté uniquement

Ce type de proxy est complètement séparé d’Orchestrator, de sorte que vous devez fournir les informations relatives aux coffres d’informations d’identification localement, dans le fichier de configuration appsettings.Production.json. Vous pouvez trouver ce fichier à l’emplacement suivant : C:\Program Files\UiPath\OrchestratorCredentialsProxy\appsettings.Production.json.

Vous devez modifier les champs suivants dans ce fichier, dans la section AppSettings - SecureStoreConfigurations :

• Key : la clé d'identification de la configuration
• Type : le type de coffre d'informations d'identification, tel qu'identifié dans les fichiers .dll configurés via le paramètre Plugins.SecureStores trouvé dans appsettings.json (voir les exemples ci-dessous)
• Context : les informations de connectivité liées à l'implémentation du magasin sécurisé
  Important :

  Une fois que vous avez modifié le fichier de configuration, vous devez redémarrer le service à partir d'IIS.

Exemples de configuration

Vous devez ajouter les exemples suivants au fichier de configuration appsettings.Production.json afin de démarrer le proxy déconnecté. Sinon, le service ne démarrera pas.

Choisissez l'exemple approprié en fonction de votre type de magasin d'informations d'identification ou ajoutez plusieurs magasins d'informations d'identification en utilisant le tout dernier exemple de cette page.

Vous devez modifier les champs suivants dans ce fichier, dans la section AppSettings - SecureStoreConfigurations :

• Key : la clé d'identification de la configuration
• Type : le type de coffre d'informations d'identification, tel qu'identifié dans les fichiers .dll configurés via le paramètre Plugins.SecureStores trouvé dans appsettings.json (voir les exemples ci-dessous)
• Context : les informations de connectivité liées à l'implémentation du magasin sécurisé
  Important :

  Une fois que vous avez modifié le fichier de configuration, vous devez redémarrer le service à partir d'IIS.

Remarque :

Avant d’apporter des modifications au fichier appsettings.Production.json, assurez-vous de créer une sauvegarde du fichier d’origine. Cela vous permet de restaurer facilement la configuration initiale ou de comparer les modifications si des problèmes surviennent pendant la configuration.

AWS Secrets Manager/AWS Secrets Manager (lecture seule)

...
"SecureStoreConfigurations": [
      {
        "Key": "<MyAwsStore>",
        "Type": "AWS Secrets Manager" / "AWS Secrets Manager (read only)",
        "Context": {
          "UseDefaultCredentials": "true",
          "AccessKey": "<AccessKey>",
          "SecretKey": "<SecretKey>",
          "Region": "<SelectedRegion>"
        }
      },
    ]
...

Azure Key Vault (lecture seule)

...
"SecureStoreConfigurations": [
      {
        "Key": "<MyAzureStore>",
        "Type": "AzureKeyVault (read only)",
        "Context": {
          "KeyVaultUri": "<KeyVaultUri>",
          "DirectoryId": "<DirectoryId>",
          "ClientId": "<ClientId>",
          "ClientSecret": "<ClientSecret>"
        }
      },
    ]
...

Important :

Azure Key Vault (lecture/écriture) n'est pas pris en charge.

Comptes gérés sécurisés par mot de passe BeyondTrust (BeyondTrust Password Safe - Managed Accounts)

...
"SecureStoreConfigurations": [
      {
        "Key": "<MyBeyondTrustManagedAccountsSafe>",
        "Type": "BeyondTrust Password Safe - Managed Accounts",
        "Context": {
          "Hostname": "<HostName>",
          "APIRegistrationKey": "<ApiRegistrationKey>",
          "APIRunAsUsername": "<Username>",
          "DefaultManagedSystemName": "", // can be empty or a string
          "SystemAccountDelimiter": "/", // default account delimiter is "/", but it can be changed
          "ManagedAccountType": "<ManagedAccountType>" // expected value is one of "system", "domainlinked", "database", "cloud", "application"
        }
      },
    ]
...

Mots de passe d'équipe sécurisés par mot de passe BeyondTrust (BeyondTrust Password Safe - Team Passwords)

...
"SecureStoreConfigurations": [
      {
        "Key": "<MyBeyondTrustTeamPasswordSafe>",
        "Type": "BeyondTrust Password Safe - Team Passwords",
        "Context": {
          "Hostname": "<HostName>",
          "APIRegistrationKey": "<ApiRegistrationKey>",
          "APIRunAsUsername": "<Username>",
          "FolderPathPrefix" : "/", // default delimiter is "/", but it can be changed
          "FolderPasswordDelimiter" : "/" // default delimiter is "/", but it can be changed
        }
      },
    ]
...

CyberArk - AIM

...
"SecureStoreConfigurations": [
      {
        "Key": "<MyCyberArk>",
        "Type": "CyberArk",
        "Context": {
          "ApplicationId": "<App_MyCyberArk>",
          "Safe": "<Passwords>",
          "Folder": "<MyFolder>"
        }
      },
    ]
...

Tous les paramètres au niveau de l'hôte, tels que CLIPasswordSDKExePath, UsePowerShellCLI ou AdditionalAllowedCharacters doivent être placés sous le paramètre Appsettings de manière similaire à la façon dont cela est fait pour Orchestrator.

{
// ...
  "AppSettings": {
    "Plugins.SecureStores.CyberArk.CLIPasswordSDKExePath": "D:\\<MyPath>\\CLIPasswordSDK.exe",
    "Plugins.SecureStores": "UiPath.Orchestrator.CyberArk.dll;UiPath.Orchestrator.AzureKeyVault.SecureStore.dll;UiPath.Orchestrator.SecureStore.CyberArkCCP.dll;UiPath.Orchestrator.SecureStore.CyberArkConjur.dll;UiPath.Orchestrator.SecureStore.HashiCorpVault.dll;UiPath.Orchestrator.SecureStore.ThycoticSecretServer.dll;UiPath.Orchestrator.SecureStore.BeyondTrust.dll;UiPath.Orchestrator.SecureStore.AWSSecretsManager.dll;UiPath.Orchestrator.SecureStore.GoogleSecretManager.dll;UiPath.Orchestrator.SecureStore.DelineaSecretServer.dll",
    "CredentialsProxyType": "Disconnected"
    // ...
  }
  // ...

CyberArk - CCP

...
"SecureStoreConfigurations": [
      {
        "Key": "<MyCyberArkCCPStore>",
        "Type": "CyberArkCCP",
        "Context": {
          "ApplicationId": "<ApplicationId>",
          "Safe": "<CyberArkSafe>",
          "Folder": "<CyberArkFolder>",
          "WebServiceUrl": "<CentralCredentialProviderUrl>",
          "WebServiceName": "<WebServiceName>",
          "SerializedClientCertificate": "<ClientCertificate>", // must be the ".pfx" file's content as base64 string
          "ClientCertificatePassword": "<ClientCertificatePassword>",
          "SerializedRootCA": "<someServerRootCA>" // must be the ".crt" or ".cer" file's content as base64 string
        }
      },
    ]
...

En fonction de votre configuration d’IIS, vous devrez peut-être configurer des éléments KeyStorageFlags supplémentaires comme suit :

"AppSettings": {
...
"Plugins.SecureStores.CyberArkCCP.KeyStorageFlags": "MachineKeySet",
...
}

Vous pouvez transférer un fichier PFX, CRT ou CER dans une chaîne de caractères base64 comme suit :

$fileContentBytes = get-content 'C:\path\to\the.pfx' -Encoding Byte
[System.Convert]::ToBase64String($fileContentBytes) | Out-File 'C:\path\to\the.txt'

CyberArk® Conjur Cloud (lecture seule)

...
"SecureStoreConfigurations": [
      {
        "Key": "MyCyberArkConjur",
        "Type": "CyberArk Conjur Cloud (read only)",
        "Context": {
          "ServiceUrl": "https://{myCyberArkConjurUrl}/",
          "LoginName": "{myLoginName}",
          "ApiKey": "{myApiKey}",
          "VariableIdPrefix": "{myPrefix}"
        }
      },
    ]
...

CyberArk® Conjur (lecture seule)

...
"SecureStoreConfigurations": [
  {
    "Key": "MyCyberArkConjur",
    "Type": "CyberArk Conjur (read only)",
    "Context": {
      "ApplianceUrl": "https://{company}.secretsmgr.cyberark.cloud/api",
      "Account": "{myAccount}",
      "AuthenticationType": "{Jwt|ApiKey}",
      "JWT":  {
          "JwtServiceId": "{myJwtServiceId}",
          "IdentityProviderUrl": "{myIdentityProviderUrl}",
          "ClientId": "{myClientId}",
          "ClientSecret": "{myClientSecret}",
          "Scope": "{myScope}"
      },
      "ApiKey": {
          "LoginName": "{myLoginName}",
          "Key": "{myApiKey}"
      },
      "HostId": "{myHostId}",
      "VariableIdPrefix": "{myPrefix}"
    }
  },
]
...

Delinea Secret Server (lecture seule)

Remarque :

Delinea Secret Server (lecture seule) nécessite Orchestrator Credentials Proxy 2.2.2 ou versions ultérieures. Son plug-in, UiPath.Orchestrator.SecureStore.DelineaSecretServer.dll, est fourni avec le kit d'installation et est répertorié dans Plugins.SecureStores par défaut, vous n'avez donc pas besoin de l'ajouter manuellement.

Il s'agit d'un magasin d'identifiants en lecture seule. Le proxy peut récupérer les valeurs des ressources et les informations d'identification du robot à partir de celui-ci, mais il ne peut pas créer, mettre à jour ou supprimer des secrets.

...
"SecureStoreConfigurations": [
      {
        "Key": "<MyDelineaServer>",
        "Type": "Delinea Secret Server (read only)",
        "Context": {
          "PlatformServerUrl": "<PlatformServerUrl>",
          "SecretServerUrl": "<SecretServerUrl>",
          "RuleName": "<Rule>",
          "RuleKey": "<Key>",
          "UsernameField": "<Username>",
          "PasswordField": "<Password>"
        }
      },
    ]
...

Les champs Context sont les suivants:

• PlatformServerUrl - (obligatoire) l'URL de votre plate-forme Delinea, par exemple https://<tenant>.delinea.app.
• SecretServerUrl - (obligatoire) l'URL de Secret Server, par exemple https://<tenant>.secretservercloud.eu. Pour le récupérer, accédez à la page de connexion de Secret Server dans votre locataire Delinea.
• RuleName - (obligatoire) le nom de la règle d'intégration du client SDK créée dans Delinea.
• RuleKey: (facultatif) la clé d'intégration de la règle. Laissez ce champ vide si l'option Exiger la clé d'intégration n'a pas été activée dans Delinea. Bien que ce champ soit facultatif, nous vous recommandons de le définir pour une sécurité améliorée.
• UsernameField : (obligatoire) nom du champ de données dynamique du champ Modèle Secret à partir duquel le nom d'utilisateur est lu, par exemple username
• PasswordField - (obligatoire) nom du champ de données dynamique du champ Modèle Secret à partir duquel le mot de passe est lu, par exemple password

Remarque :

Pendant la migration de la plateforme en cours de Delinea, les deux PlatformServerUrl et SecretServerUrl sont requis. Le proxy utilise PlatformServerUrl pour vérifier que la plate-forme Delinea est accessible et SecretServerUrl pour récupérer les clés secrètes.

Vous pouvez trouver le nom du champ de données dynamique d'un champ Modèle Secret dans Admin > Modèle Secret > Modèle > Champs. Les valeurs de UsernameField et PasswordField ne sont pas sensibles à la casse.

Les ressources et les informations d'identification du robot liées à ce magasin doivent utiliser l' ID secret numérique de Delinea Secret Server comme nom externe. Les noms de chaîne ne sont pas pris en charge.

Pour connaître les prérequis et la configuration côté Delinea, telles que l'activation de SDK Client Management et la création de la règle d'intégration, vérifiez la section d'intégration de Delinea Secret Server dans la page Intégration des magasins d'informations d'identification .

HashiCorp Vault/HashiCorp Vault (lecture seule)

L'exemple suivant utilise l'authentification AppRole par rapport à un moteur de secrets KeyValueV2. Pour ce qui signifie que chaque paramètre signifie, lesquelles votre méthode d’authentification et votre moteur de secrets ont besoin et comment SecretsEngineMountPath et DataPath se résolvent au chemin d’une clé secrète individuelle, consultez HashiCorp Vault dans Gestion des magasins d’informations d’identification.

...
"SecureStoreConfigurations": [
      {
        "Key": "<MyHashiCorp>",
        "Type": "HashiCorp Vault", // or "HashiCorp Vault (read only)"
        "Context": {
          "VaultUri": "https://vault.example.com:8200",
          "AuthenticationType": "AppRole", // or "UsernamePassword", "Ldap", "Token"
          "AuthenticationMountPath": "", // optional, defaults to the name of the authentication method
          "RoleId": "<RoleId>",
          "SecretId": "<SecretId>",
          "Username": "", // with "UsernamePassword" or "Ldap"
          "Password": "", // with "UsernamePassword" or "Ldap"
          "Token": "", // with "Token"
          "SecretsEngine": "KeyValueV2", // or "KeyValueV1"; read-only also accepts "ActiveDirectory", "OpenLDAP", "LDAP"
          "SecretsEngineMountPath": "uipath/kv", // the mount only - no "data" segment, no secret path
          "DataPath": "orchestrator/assets", // the prefix inside the mount - no mount, no "data" segment
          "Namespace": "", // Vault Enterprise only
          "LdapUseDynamicCredentials": "false", // with the "LDAP" secrets engine
          "KerberosSPN": "" // with Kerberos authentication
        }
      }
    ]
...

Les paramètres au niveau de l'hôte sont définis sur le paramètre AppSettings, de la même manière que dans Orchestrator. Chaque magasin lit uniquement son propre préfixe, de sorte que pour configurer les deux magasins, ajoutez chaque paramètre deux fois. Pour obtenir la liste complète des paramètres et de leurs valeurs par défaut, consultez Paramètres au niveau de l'hôte.

{
// ...
  "AppSettings": {
    // Optional, for Kerberos enablement
    "Plugins.SecureStores.HashiCorp Vault.KerberosEnabled": "true",
    "Plugins.SecureStores.HashiCorp Vault (read only).KerberosEnabled": "true",
    // Optional, for forwarding to the active node
    "Plugins.SecureStores.HashiCorp Vault.ForwardToActiveNode": "true",
    "Plugins.SecureStores.HashiCorp Vault (read only).ForwardToActiveNode": "true"
    // ...
  }
  // ...
}

Thycotic Secret Server

Important :

Le magasin Thycotic Secret Server est remplacé par le magasin Delinea Secret Server (lecture seule) , documenté dans la section ci-dessus. Les deux magasins partagent le même SDK sous-jacent et le même mécanisme d'intégration basé sur des règles, de sorte que les champs Context sont globalement identiques. Nous vous encourageons fortement à migrer les magasins d'informations d'identification Thycotic existants vers le nouveau magasin Delinea.

...
"SecureStoreConfigurations": [
      {
        "Key": "<MyThicoticServer>",
        "Type": "Thycotic Secret Server",
        "Context": {
          "SecretServerUrl": "<ServerUrl>",
          "RuleName": "<Rule>",
          "RuleKey": "<Key>",
          "UsernameField": "<Username>",
          "PasswordField": "<Password>"
        }
      },
    ]
...

Google Secret Manager

...
"SecureStoreConfigurations": [
      {
        "Key": "<GoogleSecretManager>",
        "Type": "Google Secret Manager",
        "Context": {
          "ProjectId": "<ProjectId>",
          "ServiceAccountKeyJson": "<ServiceAccountKeyJson>",
        }
      },
    ]
...

Google Secret Manager (lecture seule)

...
"SecureStoreConfigurations": [
      {
        "Key": "<GoogleSecretManager>",
        "Type": "Google Secret Manager (read only)",
        "Context": {
          "ProjectId": "<ProjectId>",
          "ServiceAccountKeyJson": "<ServiceAccountKeyJson>",
        }
      },
    ]
...

Plusieurs magasins d'informations d'identification

Si vous utilisez plusieurs magasins d’informations d’identification, vous pouvez les ajouter l’un sous l’autre, comme suit :

{
...
  "AppSettings": {
  ...
    "SecureStoreConfigurations": [
      {
        "Key": "<SecureStoreKey1>",
        "Type": "AzureKeyVault (read only)",
        "Context": {
          "KeyVaultUri": "<Uri>",
          "DirectoryId": "<DirectoryId>",
          "ClientId": "<ClientId>",
          "ClientSecret": "<ClientSecret>"
        }
      },
      {
        "Key": "<SecureStoreKey2>",
        "Type": "BeyondTrust Password Safe - Managed Accounts",
        "Context": {
          "Hostname": "<Host>",
          "APIRegistrationKey": "<ApiKey>",
          "APIRunAsUsername": "<ApiUsername>",
          "DefaultManagedSystemName": "",
          "SystemAccountDelimiter": "/",
          "ManagedAccountType": "system"
        }
      }
    ]
  ...
  }
}

Validation

Important :

Cela s'applique uniquement au Credentials Proxy déconnecté.

Le proxy valide la configuration au démarrage, si le type qu’il détecte est Disconnected.

Voici certaines des étapes de validation effectuées par le proxy :

• Le proxy garantit que appsettings.Production.json contient les configurations attendues, comme détaillé dans la section Configuration ci-dessus.
• Le proxy garantit que SecureStoreConfigurations ne contient pas de paramètres Key en double, autrement dit, que les magasins d’informations d’identification configurés dans le fichier appsettings.Production.json sont uniques.
• Le paramètre SecureStoreConfigurations est un tableau de configurations. Vous pouvez ajouter autant de magasins d’informations d’identification que vous le souhaitez, même du même type. Par exemple, vous pouvez avoir plusieurs instances Azure Key Vault (lecture seule) configurées tant que le champ Key est unique.
• Le proxy vérifie que toutes les valeurs Type sont valides.
• En fonction de l’implémentation de chaque magasin sécurisé, le proxy vérifie que le coffre est accessible avec succès.

Journalisation

Les journaux du Credentials Proxy Orchestrator sont stockés localement, dans le dossier C:\Program Files\UiPath\OrchestratorCredentialsProxy, si le pool d'applications du proxy dispose d'autorisations d'écriture pour ce chemin d'accès. Ils sont configurés dans IIS.

Si vous ne souhaitez pas donner d’autorisations d’écriture pour ce dossier, indiquez le chemin d’accès relatif ou absolu de votre choix via le paramètre NLog.targets.logfile.fileName dans le fichier appsettings.Production.json.

Sur les machines Windows, le proxy stocke également les journaux dans l'Observateur d'événements (Event Viewer) de Windows.

Considérations de sécurité

• Orchestrator autorise uniquement les URL sécurisées pour le proxy. Les exigences de certificat dépendent du type de proxy:
  • Proxy connecté : le certificat HTTPS doit être valide pour l’ URL publique et signé par une autorité de certification qu’Orchestrator peut valider, ce qui signifie qu’un fournisseur de certificat public largement reconnu. Les certificats auto-signés ne sont pas pris en charge.
  • Proxy déconnecté : la communication reste à l’intérieur de votre propre infrastructure, de sorte que les certificats signés par votre autorité de certification interne, ainsi que les certificats auto-signés, sont pris en charge, tant que les machines exécutant vos Robots leur donnent confiance.
• Orchestrator est validé via une clé secrète de client générée par le Orchestrator Credentials Proxy. La clé secrète du client est stockée dans un fichier de configuration sur la machine où le Orchestrator Credentials Proxy est installé, et est chiffrée et stockée dans la base de données par Orchestrator.
• Lorsque vous modifiez un proxy de magasin d’informations d’identification dans Orchestrator et que vous modifiez son URL, vous devez saisir la clé secrète du client.
• Orchestrator Credentials Proxy 2.0.0 et versions ultérieures les actions sont consignées dans l'Observateur d'événements (Event Viewer) dans Windows.
• Les binaires doivent être signés sur la machine Windows.
• L'image Docker doit être signée.

Utiliser l’Orchestrator Credentials Proxy avec un équilibreur de charge

Si vous utilisez le proxy en combinaison avec un équilibreur de charge, assurez-vous de conserver la même configuration sur tous les nœuds.

Éléments qui doivent rester identiques sur les nœuds

• La version du programme d’installation du proxy. Par exemple, si vous utilisez la version 1.0.0, tous les nœuds de l’équilibreur de charge doivent également utiliser la version 1.0.0.
• Les paramètres dans les fichiers de configuration de l’application. Dans la plupart des cas, il s’agit de appsettings.json et appsettings.Production.json. Notez que appsettings.Production.json est unique pour chaque installation, vous devez donc l’ajouter manuellement à chaque nœud afin d’assurer la cohérence.
• Les plug-ins du magasin d’informations d’identification ajoutés à path/plugins. Tous les plugins que nous prenons en charge se trouvent déjà dans ce dossier, vous n’avez donc qu’à faire attention aux plugins personnalisés que vous ajoutez.

Éléments importants à prendre en compte

• Si vous souhaitez apporter des modifications à la configuration de l’image Docker que nous fournissons pour l’installation du proxy, nous vous recommandons fortement de créer une image Docker personnalisée à la place. Vous devez ensuite utiliser cette image personnalisée pour déployer le proxy sur tous les nœuds.
• Certaines variables d’environnement peuvent avoir un impact lors du runtime, comme les variables d’environnement qui remplacent les valeurs de configuration appsettings.json ou celles qui affectent l’environnement .NET.
• Vous pouvez utiliser le point de terminaison non authentifié dédié https://{YourOrchestratorCredentialsProxyURL}/api/v1/Health pour vérifier si le Orchestrator Credentials Proxy est toujours en cours d’exécution.

Mettre à jour le certificat Orchestrator Credentials Proxy

Pour les installations à nœud unique, mettez à jour le certificat SSL comme suit :

1. Importez le nouveau certificat dans le dossier Personnel, sous Certificats, dans la console de certificats de la machine locale (certlm.msc).
2. Dans la console de gestion IIS, développez Sites et sélectionnez UiPath Orchestrator Credential Proxy.
3. Dans le panneau de droite, sélectionnez Liaisons....
4. Dans la vue Liaisons... , sélectionnez l’enregistrement https par défaut, puis utilisez le bouton Sélectionner... pour choisir un certificat.
5. Dans la fenêtre contextuelle Sélectionner un certificat (Select Certificate), sélectionnez le certificat récemment ajouté.
6. Sélectionnez OK jusqu’à ce que la configuration soit terminée.
   Remarque :

   Pour les installations multi-nœuds, veillez à bien mettre à jour le certificat sur toutes les machines.

Pour mettre à jour le certificat pour les installations utilisant un équilibreur de charge, suivez les mêmes étapes que celles décrites ci-dessus. Étant donné que Orchestrator Credentials Proxy est dépourvu d’état, supprimez le nœud de l’équilibreur de charge lors de la mise à jour du certificat.

Rotation des clés

Rotation des clés avec temps d'arrêt

Remarque :

Cette opération nécessite d’arrêter et de redémarrer l’Orchestrator Credentials Proxy en cours d’exécution. Cela peut avoir un impact sur toutes les demandes en direct effectuées par Orchestrator.

1. Générez une nouvelle clé secrète conformément aux normes d'Orchestrator Credentials Proxy.
2. Arrêtez votre Orchestrator Credentials Proxy.
3. Modifiez le fichier appsettings.Production.jsonet remplacez votre clé existante par la nouvelle clé.
4. Démarrez votre Orchestrator Credentials Proxy.
5. Dans Orchestrator, accédez à votre Orchestrator Credentials Proxy et modifiez le champ Secret avec votre nouvelle clé secrète.

Rotation des clés sans temps d'arrêt

Remarque :

Cette opération nécessite un Orchestrator Credentials Proxy avec un équilibreur de charge et un minimum de deux instances de Orchestrator Credentials Proxy. Pour plus de détails, consultez la section Installation .

1. Générez une nouvelle clé secrète conformément aux normes d'Orchestrator Credentials Proxy.
2. Ajoutez la clé nouvellement générée à vos instances de Credentials Proxy. Suivez cette procédure pour chaque instance :
   1. Retirez une instance d'Orchestrator Credentials Proxy de l'équilibreur de charge.
   2. Arrêtez cette instance d'Orchestrator Credentials Proxy.
   3. Ouvrez le appsettings.Production.json fichier. Le fichier doit contenir un code similaire à ce qui suit :

      {
          "Jwt": {
              "Keys": [
                  "{{OldKey}}"
              ],
      

   4. Ajoutez la clé nouvellement générée tout en conservant la clé existante. Le Keys paramètre prend en charge plusieurs valeurs séparées par des virgules :

      {
          "Jwt": {
              "Keys": [
                  "{{OldKey}}",
                  "{{NewKey}}"
              ],
      

   5. Démarrez Orchestrator Credentials Proxy.
   6. Ramenez l'instance d'Orchestrator Credentials Proxy dans l'équilibreur de charge.
3. Dans Orchestrator, accédez à votre Orchestrator Credentials Proxy et modifiez le champ Secret avec votre nouvelle clé secrète.
4. Après un certain temps, prenez votre ancienne clé à partir des instances de Credentials Proxy.Suivez cette procédure pour chaque instance :
   1. Retirez une instance d'Orchestrator Credentials Proxy de l'équilibreur de charge.
   2. Arrêtez cette instance d'Orchestrator Credentials Proxy.
   3. Ouvrez le appsettings.Production.json fichier. Le fichier doit contenir deux clés comme mentionné aux étapes précédentes :

      {
          "Jwt": {
              "Keys": [
                  "{{OldKey}}",
                  "{{NewKey}}"
              ],
      

   4. Supprimez l'ancienne clé du fichier : { "Jwt" : { "Clés" : [ "{{NewKey}}"],
   5. Démarrez Orchestrator Credentials Proxy.
   6. Ramenez l'instance d'Orchestrator Credentials Proxy dans l'équilibreur de charge.