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.
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’environnementFRONTEND_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 :Fournisseur de services (SP) — EK
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.
Fournisseur d'identité (IdP) — Votre organisation
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.
acme.com), un Super Admin doit terminer les deux côtés de cet échange :
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.
@<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. |
Mode A — SSO à clic unique (VITE_ALLOW_ONLY_SSO_LOGIN=true)
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 Pour que cela fonctionne :
VITE_SSO_ENTERPRISE_ID et redirige immédiatement vers :VITE_SSO_ENTERPRISE_IDdoit ê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).
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.Mode B — SSO modal par messagerie (VITE_ALLOW_ONLY_SSO_LOGIN=false, par défaut)
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 :
- 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.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).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 |
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 queenterprise_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 :
L'utilisateur commence sur le frontend
L’utilisateur ouvre EK à
https://<your-frontend-host> et clique sur le bouton SSO.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.IdP authentifie l'utilisateur
Votre IdP gère l’authentification — mot de passe, MFA, certificat ou tout ce que votre organisation a configuré.
IdP → Backend
L’IdP envoie la réponse SAML au point de terminaison ACS du backend EK :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.
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.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.