> ## Knowledge Base Index > Fetch the complete knowledge base index at: https://help.umamy.io/sitemap.xml > Use this file to discover available pages before exploring further. > Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash). # Se connecter avec le fournisseur d'identité de votre entreprise (SSO SAML) Umamy prend en charge l'authentification unique d'entreprise via SAML 2.0. Vos équipes se connectent avec votre propre fournisseur d'identité — Microsoft Entra ID, Okta, Google Workspace ou tout fournisseur SAML 2.0 — et les nouveaux arrivants obtiennent leur accès dès leur première connexion, sans invitation à envoyer. La mise en place demande trois choses : votre équipe informatique configure une application de son côté, vous nous indiquez l'URL de métadonnées de votre fournisseur d'identité, et vous prouvez les domaines de messagerie pour lesquels il parle. Rien n'est appliqué avant que vous ne nous demandiez de l'activer. ## Ce dont votre équipe informatique a besoin de notre part Umamy est le **fournisseur de service** (SP). Voici ses valeurs : | Champ | Valeur | | ---- | | Identificateur / Entity ID | https://auth.umamy.io/auth/v1/sso/saml/metadata | | URL de réponse / ACS | https://auth.umamy.io/auth/v1/sso/saml/acs | | URL de métadonnées | https://auth.umamy.io/auth/v1/sso/saml/metadata | | Fichier de métadonnées (pour les outils qui demandent un import) | même URL + `?download=true` | | URL de déconnexion unique (SLO) | https://auth.umamy.io/auth/v1/sso/slo | | Format du `NameID` | `emailAddress` | | URL de connexion (pour une connexion initiée par l'IdP) | https://app.umamy.io/sign-in | Ces mêmes valeurs sont affichées dans **Paramètres → Authentification unique** dans Umamy, avec des boutons de copie. En cas de divergence, fiez-vous à cette page plutôt qu'à ce document : elle est générée depuis la configuration réelle. ## Ce dont nous avons besoin de votre part 1. **L'URL de métadonnées SAML de votre fournisseur d'identité** (à privilégier) ou son fichier XML de métadonnées. Vous pouvez la saisir vous-même dans \*\*Paramètres → Authentification unique\*\*. 2. **Le ou les domaines de messagerie qui apparaissent dans vos assertions.** C'est le détail qui pose problème le plus souvent : le domaine de vos adresses de contact n'est pas toujours celui que votre fournisseur asserte. Indiquez-nous le domaine exact que portera le `NameID` de vos utilisateurs, ainsi que tous les domaines supplémentaires (filiales, alias) qui doivent pouvoir se connecter. 3. **Les noms d'attributs pour l'e-mail et le nom complet**, s'ils diffèrent des valeurs par défaut d'Entra ID (`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress` et `.../claims/name`). ## Configurer Microsoft Entra ID 1. \*\*Centre d'administration Entra → Applications d'entreprise → Nouvelle application → Créer votre propre application.\*\* Nommez-la *Umamy* et choisissez \*Intégrer une autre application introuvable dans la galerie (hors galerie)\*. 2. **Authentification unique → SAML.** 3. **Configuration SAML de base → Modifier :** * *Identificateur (Entity ID)* → l'Entity ID du tableau ci-dessus. * *URL de réponse (Assertion Consumer Service)* → l'URL ACS. * *URL de connexion* → https://app.umamy.io/sign-in (nécessaire uniquement pour une connexion initiée par l'IdP). * *URL de déconnexion* → l'URL SLO. 4. **Attributs et revendications.** Le jeu de revendications par défaut d'Entra porte déjà l'e-mail et le nom : laissez-le tel quel, sauf si votre tenant a été personnalisé. Vérifiez que l'*identificateur d'utilisateur unique (Name ID)* est bien l'**adresse e-mail**. 5. **Utilisateurs et groupes** → affectez les personnes ou groupes qui doivent avoir accès à Umamy. Umamy crée leur compte à la première connexion ; il n'y a rien à provisionner à l'avance de notre côté. 6. Récupérez l'**App Federation Metadata Url** dans la section *Certificats SAML* et saisissez-la dans **Paramètres → Authentification unique**. Okta et Google Workspace suivent la même logique : créez une application SAML personnalisée, renseignez l'Entity ID et l'URL ACS, faites du NameID l'adresse e-mail, et fournissez l'URL de métadonnées (Google Workspace ne propose qu'un **fichier** de métadonnées — c'est très bien, transmettez-le nous). ## Vérifier vos domaines de messagerie Une fois votre fournisseur d'identité enregistré, un administrateur de votre espace Umamy ajoute chaque domaine dans **Paramètres → Authentification unique** et publie un enregistrement TXT pour en prouver le contrôle : | Champ | Valeur | | ---- | | Type | `TXT` | | Nom / hôte | le domaine lui-même (`@` à la racine de la zone) | | Valeur | `umamy-verification=` | Cliquez ensuite sur **Vérifier**. La propagation DNS prend généralement quelques minutes. Un domaine ne sert à rien tant qu'il n'est pas vérifié : il n'achemine aucune connexion et n'accorde aucun accès. C'est délibéré — c'est la vérification qui rend sûr le fait que vous déclariez vos propres domaines, plutôt que de nous ouvrir un ticket pour chacun. ## Ce qui se passe à la première connexion Une personne qui s'authentifie via votre fournisseur d'identité est ajoutée automatiquement à votre espace, en tant que **membre**. Si elle avait déjà été invitée comme administrateur, le rôle de cette invitation est conservé — arriver d'abord par le fournisseur d'identité ne la rétrograde pas. Une fois le SSO activé pour votre espace, \*\*y entrer exige une session établie via votre fournisseur d'identité\*\*. Une personne dont la session a été obtenue autrement est invitée à se reconnecter par ce biais. Cela s'applique à la frontière de l'espace de travail, et non à la connexion. Si l'une de vos personnes appartient aussi à un autre espace Umamy — celui d'un partenaire, par exemple — cet espace n'est pas affecté et reste accessible. C'est volontaire : votre politique SSO régit vos données, et ne doit pas pouvoir exclure quelqu'un de celles d'une organisation tierce. ## Limites à connaître avant de valider * **Pas de SCIM ni de déprovisionnement automatique.** SAML ne transporte aucun signal « cette personne est partie ». Retirer quelqu'un de votre fournisseur d'identité l'empêche de se connecter, mais son appartenance à Umamy, les clés d'API qu'elle a créées et toute session qu'elle détient déjà subsistent jusqu'à leur suppression. Révoquez l'accès dans \*\*Paramètres → Membres de l'équipe\*\*. Si le déprovisionnement automatique compte pour vous, dites-le nous : le SCIM est un chantier à part, pas un réglage. * **Pas de déconnexion unique câblée.** Le point de terminaison SLO existe, mais se déconnecter d'Umamy ne vous déconnecte pas de votre fournisseur d'identité, et inversement. * **La durée de session est un réglage global de la plateforme**, non un réglage par client. Si votre politique de sécurité impose une durée maximale précise, parlez-en nous plutôt que de supposer qu'elle est configurable pour votre seul tenant. * **Les clés d'API ne sont pas soumises au SSO.** Ce sont des identifiants machine, émis et révoqués séparément dans **Paramètres → Clés d'API**. Activer le SSO ne casse pas vos intégrations, et ne les place pas non plus derrière votre fournisseur d'identité. ## En cas de problème **« Aucune authentification unique n'est configurée pour ce domaine. »** Le domaine saisi n'est pas un domaine vérifié d'un fournisseur enregistré. Vérifiez l'orthographe exacte, et que le domaine a bien été vérifié dans **Paramètres → Authentification unique** : un domaine ajouté mais non vérifié donne ce message. **Un domaine affiche « Connexions pas encore acheminées ».** Il est prouvé, mais notre service d'identité ne l'a pas encore accepté : une connexion par ce biais échouera. Contactez-nous, la réparation est de notre côté et prend un instant. **La connexion fonctionne, mais la personne n'arrive nulle part.** Le domaine de l'e-mail asserté n'est probablement pas l'un de vos domaines vérifiés. C'est l'écart décrit plus haut : vérifiez ce que votre fournisseur met réellement dans le `NameID`, et non ce à quoi ressemblent vos adresses de contact.