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 :

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 :

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.

Mis à jour le : 24/08/2026