À propos d'Identity Server

UiPath® Identity Server est le service d’authentification d’Orchestrator autonome. Il fournit une authentification sécurisée et une émission de jetons pour Orchestrator et ses portails de gestion. Identity Server implémente les normes OAuth 2.0 et OpenID Connect et s'intègre aux systèmes d'identité d'entreprise tels qu'Active Directory. Consultez le diagramme suivant pour comprendre le fonctionnement d'Identity Server dans Orchestrator autonome.

Graphique 1. Diagramme d'Identity Server

Rôle dans Orchestrator

Identity Server est responsable de :

• Authentification des utilisateurs et des applications accédant à Orchestrator
• Émission de jetons d’accès et d’identité
• Prise en charge des flux OAuth 2.0 et OpenID Connect
• Intégration avec des fournisseurs d’identité externes (par exemple, Active Directory, fournisseurs SAML)
• Activation de l’authentification unique (SSO)
• Sécurisation de la communication entre Orchestrator et le portail de gestion des identités

Orchestrator et ses portails de gestion s'appuient sur Identity Server pour l'authentification.

Flux d’authentification dans Orchestrator

1. Authentification de l’utilisateur

Lorsqu’un utilisateur accède à Orchestrator ou au portail de gestion des identités :

• La demande est redirigée vers Identity Server.
• Identity Server valide l'utilisateur auprès de :
  • Comptes locaux ou
  • Fournisseurs d’identité externes (par exemple, Active Directory, SAML).
• Une fois l'authentification réussie, Identity Server émet un jeton de sécurité.

2. Accès basé sur un jeton

Après l’authentification :

• Un jeton d’accès OAuth est émis.
• Le jeton accompagne les demandes ultérieures à Orchestrator.
• Orchestrator valide le jeton.
• L'autorisation est déterminée en fonction des rôles et des autorisations. Identity Server gère l’authentification. Orchestrator applique l’autorisation.

Intégration Active Directory et Kerberos

Dans les environnements joints à un domaine, Orchestrator autonome prend en charge l'authentification basée sur Kerberos :

• Le client résout le nom d’hôte d’Orchestrator à l’aide de DNS.
• Le client obtient un ticket d’octroi de ticket Kerberos (TGT) à partir d’Active Directory.
• Le client demande un ticket de service pour le nom du principal de service (SPN) configuré.
• Le serveur Web IIS valide le ticket Kerberos.
• Identity Server traite l’identité authentifiée et émet un jeton de plateforme.

Cela permet une authentification unique transparente dans les environnements Windows d'entreprise.

Considérations sur la haute disponibilité

Dans les déploiements multi-nœuds :

• Identity Server s’exécute sur plusieurs nœuds derrière un équilibreur de charge.
• Les clients accèdent à Orchestrator et à Identity Server via un nom d’hôte d’un équilibreur de charge partagé.
• Redis est utilisé pour mettre en cache les données du client OAuth et l’état de la session sur les nœuds, garantissant une authentification cohérente sur l’ensemble du cluster.
• Le nom du principal du service (SPN) doit correspondre au nom d'hôte de l'équilibreur de charge lorsque Kerberos est utilisé.
• Lors du passage d'une configuration à un seul nœud à une configuration multi-nœuds, l'URL publique d'Identity Server doit être mise à jour dans la base de données et dans le fichier UiPath.Orchestrator.dll.config.

Authentification de l’application externe

Orchestrator prend en charge l’accès sécurisé pour :

• Applications externes
• Intégrations d’API
• Communication entre Robot et Orchestrator

Les applications s’authentifient à l’aide de flux OAuth pris en charge (tels que ROPC) et reçoivent des jetons d’Identity Server.

Modèle de sécurité

Orchestrator autonome utilise un modèle d’authentification centralisé :

• Identity Server effectue l’authentification.
• Orchestrator applique l’autorisation.
• L'accès basé sur un jeton sécurise les API et l'IU d'Orchestrator.
• L'intégration avec des fournisseurs d'identité externes (Active Directory, SAML) prend en charge les exigences de sécurité de l'entreprise.