> ## Documentation Index
> Fetch the complete documentation index at: https://ai-kb.automationanywhere.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SAML SSO dans EK — Comment ça marche

> Comprenez comment EK s'intègre avec votre fournisseur d'identité pour l'authentification SAML 2.0 avant de commencer la configuration.

<Note>
  Ce guide est rédigé à l'intention des administrateurs IT et d'identité gérant une instance EK sur site. Toute référence à « votre fournisseur d'identité », « votre administrateur de fournisseur d'identité » ou « votre domaine de messagerie » fait référence à l'infrastructure de votre propre organisation — non à quelque chose géré par Automation Anywhere.
</Note>

EK prend en charge **l'authentification SAML 2.0** pour les déploiements sur site, permettant à vos utilisateurs de se connecter via le **fournisseur d'identité (IdP)** existant de votre organisation. La configuration se fait entièrement via l'onglet **Tableau de bord Super Admin → Métadonnées SSO** — aucune modification de code requise.

EK fonctionne avec tout **fournisseur d'identité SAML 2.0 conforme aux normes** — Okta, Azure AD / Entra ID, Ping, ADFS, OneLogin, Auth0, Keycloak, Google Workspace, et autres. Une fois que vous téléchargez les métadonnées IdP pour un domaine de messagerie, EK acheminera automatiquement l'authentification pour tout utilisateur dont le courrier électronique appartient à ce domaine.

## Comprendre vos deux noms d'hôtes EK

Un déploiement EK sur site a deux noms d'hôtes ayant des rôles distincts :

* `<your-backend-host>` — gère tout le trafic SAML : métadonnées SP, initiation SSO et point de terminaison ACS. **C'est le seul hôte que votre IdP doit connaître.** *(Exemple : `ek-api.corp.acme.com`)*
* `<your-frontend-host>` — l'interface Web que vos utilisateurs ouvrent dans leur navigateur. EK redirige les utilisateurs ici après une connexion réussie, configurée via la variable d'environnement `FRONTEND_ROOT_URL`. **Cet hôte n'apparaît jamais dans votre configuration IdP.** *(Exemple : `ek.corp.acme.com`)*

## Comment fonctionne l'authentification SAML SSO dans EK

La configuration de l'authentification SAML SSO nécessite un échange mutuel de confiance entre deux systèmes. Chaque côté doit savoir qui est l'autre avant que toute authentification puisse se produire :

<CardGroup cols={2}>
  <Card title="Fournisseur de services (SP) — EK" icon="server">
    Votre instance EK sur site. EK publie les métadonnées SP pour que votre IdP sache où envoyer les réponses SAML, quel format NameID utiliser et quel certificat de signature faire confiance sur les AuthnRequests.
  </Card>

  <Card title="Fournisseur d'identité (IdP) — Votre organisation" icon="shield-halved">
    Votre organisation Okta, Entra ID, Ping, ADFS, etc. Votre IdP publie ses propres métadonnées XML décrivant son émetteur, son point de terminaison SSO et son certificat de signature — EK en a besoin pour valider les assertions que votre IdP retourne.
  </Card>
</CardGroup>

Pour activer l'authentification pour un domaine de messagerie (par exemple `acme.com`), un Super Admin doit terminer les deux côtés de cet échange :

<Steps>
  <Step title="Partager les métadonnées SP avec votre IdP">
    Donnez à votre administrateur IdP les métadonnées SP publiées par votre instance EK afin qu'il puisse enregistrer EK en tant qu'application SAML dans votre IdP.
  </Step>

  <Step title="Télécharger les métadonnées IdP vers EK">
    Une fois l'application IdP créée, téléchargez le fichier XML de métadonnées IdP résultant vers EK via **Super Admin → Métadonnées SSO**, lié au domaine de messagerie avec lequel les utilisateurs se connecteront.
  </Step>
</Steps>

Une fois les deux côtés en place, tout utilisateur avec un courrier électronique se terminant par `@<domain>` peut se connecter à EK via l'authentification SAML SSO via votre IdP d'entreprise.

## Comment l'utilisateur accède au flux SSO

L'écran de connexion EK affiche toujours une option « Se connecter avec SSO ». Ce qui se passe lorsqu'un utilisateur clique dessus dépend de deux variables d'environnement frontend intégrées dans votre génération d'interface Web EK :

| Variable                    | Objectif                                                                                         |
| --------------------------- | ------------------------------------------------------------------------------------------------ |
| `VITE_ALLOW_ONLY_SSO_LOGIN` | Détermine quel mode SSO l'écran de connexion utilise.                                            |
| `VITE_SSO_ENTERPRISE_ID`    | Utilisé uniquement en mode à clic unique pour spécifier le domaine de messagerie à authentifier. |

<AccordionGroup>
  <Accordion title="Mode A — SSO à clic unique (VITE_ALLOW_ONLY_SSO_LOGIN=true)">
    L'écran de connexion affiche uniquement un bouton SSO — aucun champ de courrier électronique ou de mot de passe. C'est la configuration typique pour un déploiement sur site desservant un seul domaine de messagerie.

    Lorsque l'utilisateur clique sur le bouton, le frontend lit `VITE_SSO_ENTERPRISE_ID` et redirige immédiatement vers :

    ```
    https://<your-backend-host>/sso/login?enterprise_id=<VITE_SSO_ENTERPRISE_ID>&target_url=https://<your-frontend-host>/okta/authenticate
    ```

    Pour que cela fonctionne :

    * `VITE_SSO_ENTERPRISE_ID` doit être défini sur le frontend.
    * Sa valeur doit correspondre à un domaine qui a des métadonnées IdP téléchargées dans l'onglet **Métadonnées SSO**.
    * Lors du téléchargement de métadonnées, le **domaine de messagerie de l'équipe SSO** doit correspondre exactement à `VITE_SSO_ENTERPRISE_ID` (insensible à la casse ; les valeurs sont normalisées en minuscules lors de l'enregistrement).

    Si `VITE_SSO_ENTERPRISE_ID` n'est pas défini, l'utilisateur voit *« Impossible de déterminer le domaine pour la connexion SSO »* et ne peut pas continuer. S'il est défini mais qu'aucune métadonnée n'existe pour ce domaine, la redirection se fait mais l'authentification échoue au backend.
  </Accordion>

  <Accordion title="Mode B — SSO modal par messagerie (VITE_ALLOW_ONLY_SSO_LOGIN=false, par défaut)">
    L'écran de connexion affiche le courrier électronique/mot de passe et les contrôles SSO ensemble. Cliquer sur le bouton SSO ouvre une modale *« Entrez votre e-mail »*. Après que l'utilisateur soumette son courrier électronique, le frontend extrait le domaine et vérifie auprès du backend si l'authentification est configurée via `POST https://<your-backend-host>/sso/verify_enterprise_id`.

    * Si **oui**, le frontend redirige vers :
      ```
      https://<your-backend-host>/sso/login?enterprise_id=<email-domain>&target_url=https://<your-frontend-host>/okta/authenticate
      ```
    * Si **non**, l'utilisateur voit *« Votre organisation n'est pas configurée pour la connexion SSO. Veuillez contacter votre administrateur. »*

    `VITE_SSO_ENTERPRISE_ID` n'est pas utilisé dans ce mode. Plusieurs domaines peuvent coexister — chacun doit avoir ses propres métadonnées IdP téléchargées dans l'onglet Métadonnées SSO.
  </Accordion>
</AccordionGroup>

<Info>
  Les deux modes utilisent le même point de terminaison backend `/sso/login` avec le même paramètre `enterprise_id`. La seule différence est si cette valeur est codée en dur par une variable d'environnement frontend (Mode A) ou dérivée de l'e-mail de l'utilisateur à la connexion (Mode B).
</Info>

## Ce que le backend fait avec `enterprise_id`

Lorsque le backend reçoit `GET /sso/login?enterprise_id=acme.com`, il recherche les métadonnées IdP téléchargées pour `acme.com` et crée une configuration SAML SP à la volée :

| Paramètre                     | Valeur                                                                                                                                                                      |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **ID entité**                 | `CUSTOM_ENTITY_ID_FOR_GENERIC_SSO` s'il est défini au moment du déploiement ; sinon, la valeur par défaut est `https://<your-backend-host>/user/generic/sso/saml/acs/admin` |
| **Point de terminaison ACS**  | `https://<your-backend-host>/user/generic/sso/saml/acs/admin` (liaison HTTP-POST)                                                                                           |
| **Format NameID**             | `emailAddress`                                                                                                                                                              |
| **Métadonnées IdP distantes** | Une URL signée pointant vers le XML téléchargé en stockage                                                                                                                  |

Si aucune métadonnée n'est en file pour l'`enterprise_id` fourni, le backend ne peut pas créer une configuration SAML SP et la tentative d'authentification échoue.

## Chaîne de redirection au niveau du navigateur

Une fois que `enterprise_id` est résolu en métadonnées téléchargées, l'authentification se déroule comme une série de redirections de navigateur :

<Steps>
  <Step title="L'utilisateur commence sur le frontend">
    L'utilisateur ouvre EK à `https://<your-frontend-host>` et clique sur le bouton SSO.
  </Step>

  <Step title="Frontend → Backend">
    Le frontend redirige le navigateur vers le point d'entrée SSO du backend :

    ```
    GET https://<your-backend-host>/sso/login?enterprise_id=acme.com&target_url=https://<your-frontend-host>/okta/authenticate
    ```
  </Step>

  <Step title="Backend → IdP">
    Le backend crée un AuthnRequest SAML à partir des métadonnées IdP téléchargées pour `acme.com` et redirige le navigateur vers votre point de terminaison SSO IdP.
  </Step>

  <Step title="IdP authentifie l'utilisateur">
    Votre IdP gère l'authentification — mot de passe, MFA, certificat ou tout ce que votre organisation a configuré.
  </Step>

  <Step title="IdP → Backend">
    L'IdP envoie la réponse SAML au point de terminaison ACS du backend EK :

    ```
    POST https://<your-backend-host>/user/generic/sso/saml/acs/admin
    ```

    Le backend valide l'assertion par rapport au certificat de signature IdP à partir des métadonnées téléchargées, puis connecte l'utilisateur à son compte EK existant ou en approvisionne un nouveau.
  </Step>

  <Step title="Backend → Frontend">
    Le backend redirige le navigateur de l'utilisateur vers EK à `<your-frontend-host>`. L'URL exacte est déterminée par la variable d'environnement `FRONTEND_ROOT_URL` sur le backend — si elle est mal configurée, l'utilisateur semble terminer l'authentification mais atterrit sur la mauvaise page.
  </Step>
</Steps>

<Note>
  L'IdP n'interagit qu'avec `<your-backend-host>`. L'hôte frontend apparaît au tout début du flux (où l'utilisateur commence) et à la fin (où il atterrit après la connexion) — il n'apparaît jamais dans aucune URL adressée à l'IdP.
</Note>

Prêt à configurer l'authentification ? Consultez le [Guide de configuration des métadonnées SSO](/super-admin/sso/saml-sso-metadata-setup-guide) pour des instructions étape par étape.