Authentification unique (SAML)
Permettez à votre équipe de se connecter à intoCHAT avec votre fournisseur d'identité via SAML 2.0 : configuration pour Okta, Microsoft Entra ID et Google Workspace, vérification des domaines, adhésion automatique à l'équipe, SSO obligatoire, deux facteurs et dépannage. Offre Enterprise.
L'authentification unique (SSO) permet aux personnes de votre entreprise de se connecter à intoCHAT avec votre fournisseur d'identité (IdP), comme Okta, Microsoft Entra ID (anciennement Azure AD) ou Google Workspace, au lieu d'un mot de passe intoCHAT distinct. intoCHAT fonctionne avec tout IdP compatible SAML 2.0.
Fonctionnement
- Vous, le propriétaire du compte, connectez votre IdP sous Settings puis Single sign-on et vérifiez les domaines e-mail qu'utilise votre entreprise, comme
acme.com. - Sur la page de connexion, les personnes cliquent sur Se connecter avec le SSO, saisissent leur e-mail professionnel et sont redirigées vers votre IdP. Une fois connectées là-bas, elles reviennent dans intoCHAT, dans votre compte.
- Une personne qui se connecte par SSO pour la première fois rejoint automatiquement votre équipe, avec le rôle que vous choisissez, si un siège est libre. Personne n'a besoin d'invitation.
- Vous pouvez imposer le SSO à toutes les personnes de vos domaines, pour qu'elles ne puissent pas se connecter à la place avec un mot de passe ou avec Google.
Seul le propriétaire du compte peut configurer et modifier l'authentification unique. Les admins peuvent ouvrir la page et voir comment elle est configurée ; les editors et les viewers ne la voient pas. Un super administrateur qui consulte votre compte pour le support ne peut pas non plus la modifier.
Configurer l'authentification unique
- Allez dans Settings puis Single sign-on et cliquez sur Set up single sign-on. Rien ne change pour personne tant que vous ne l'activez pas.
- Sous Details for your identity provider, copiez l'ACS URL, l'Entity ID et la Metadata URL. Créez avec eux une application SAML dans votre IdP : voir Okta, Microsoft Entra ID ou Google Workspace.
- Sous Identity provider, collez le XML de métadonnées de votre IdP, ou choisissez Enter manually et saisissez son entity ID, son URL de connexion (SSO URL) et son certificat de signature. Cliquez sur Save identity provider.
- Sous Domains, ajoutez vos domaines e-mail et vérifiez-les.
- Choisissez le Role for new members : Viewer, Editor ou Admin.
- Cliquez sur Test sign-in pour vérifier que votre IdP et intoCHAT se comprennent. Voir Tester la connexion.
- Activez Enabled.
Enabled ne peut être activé qu'une fois enregistrés l'entity ID de l'IdP, son URL de connexion et un certificat valide, et au moins un domaine vérifié. D'ici là, la carte Status liste ce qui manque.
Ce que votre IdP doit envoyer
- L'adresse e-mail de la personne comme NameID (format « EmailAddress » ou « Unspecified »), ou dans un attribut nommé
email. intoCHAT l'utilise pour trouver ou ajouter la personne. - Une assertion signée. intoCHAT refuse une réponse dont l'assertion n'est pas signée avec le certificat que vous avez enregistré, même si la réponse qui l'entoure est signée.
- Le nom de la personne (facultatif) dans un attribut nommé
displayName, oufirstNameetlastName. Il est utilisé quand quelqu'un rejoint l'équipe pour la première fois.
intoCHAT ne signe pas ses requêtes et n'a pas besoin d'assertions chiffrées : vous n'avez donc pas à téléverser de certificat intoCHAT dans votre IdP. Le certificat que vous collez est le certificat de signature public de votre IdP. Ne collez jamais de clé privée ; intoCHAT la refuse.
Okta
- Dans l'Okta Admin Console, allez dans Applications puis Applications, cliquez sur Create App Integration, choisissez SAML 2.0 et cliquez sur Next.
- Nommez l'application, par exemple intoCHAT, et cliquez sur Next.
- Renseignez Single sign-on URL avec l'ACS URL d'intoCHAT, et laissez Use this for Recipient URL and Destination URL coché.
- Renseignez Audience URI (SP Entity ID) avec l'Entity ID d'intoCHAT.
- Réglez Name ID format sur EmailAddress et Application username sur Email.
- Facultatif : sous Attribute Statements, ajoutez
emailavec la valeuruser.email, etdisplayNameavecuser.displayName. - Cliquez sur Next, puis sur Finish.
- Dans l'onglet Sign On de l'application, copiez la Metadata URL et ouvrez-la, ou cliquez sur View SAML setup instructions. Collez le XML de métadonnées dans intoCHAT sous Identity provider.
- Dans l'onglet Assignments, attribuez l'application aux personnes ou groupes qui doivent utiliser intoCHAT.
Okta signe l'assertion par défaut. Laissez Assertion Signature sur Signed.
Microsoft Entra ID
- Dans le Microsoft Entra admin center, allez dans Enterprise applications, cliquez sur New application, puis sur Create your own application. Nommez-la, choisissez Integrate any other application you don't find in the gallery (Non-gallery) et cliquez sur Create.
- Ouvrez Single sign-on et choisissez SAML.
- Sous Basic SAML Configuration, cliquez sur Edit. Renseignez Identifier (Entity ID) avec l'Entity ID d'intoCHAT et Reply URL (Assertion Consumer Service URL) avec l'ACS URL. Laissez Sign on URL et Relay State vides. Enregistrez.
- Sous Attributes & Claims, vérifiez que Unique User Identifier (Name ID) vaut
user.mail(ouuser.userprincipalnamesi c'est l'adresse e-mail de chaque personne). Entra envoie aussi l'e-mail dans sa revendicationemailaddress, qu'intoCHAT lit. - Sous SAML Certificates, téléchargez Federation Metadata XML et collez son contenu dans intoCHAT sous Identity provider.
- Sous Users and groups, ajoutez les personnes ou groupes qui doivent utiliser intoCHAT.
Entra signe l'assertion par défaut (Signing Option : « Sign SAML assertion »). Si vous changez ce réglage, choisissez « Sign SAML response and assertion », et non « Sign SAML response » seul.
Google Workspace
- Dans la console d'administration Google, allez dans Apps puis Web and mobile apps, cliquez sur Add app et choisissez Add custom SAML app.
- Nommez l'application, par exemple intoCHAT, et cliquez sur Continue.
- Cliquez sur Download Metadata pour enregistrer les métadonnées de l'IdP, puis sur Continue. Collez le contenu du fichier dans intoCHAT sous Identity provider.
- Renseignez ACS URL avec l'ACS URL d'intoCHAT et Entity ID avec l'Entity ID. Laissez Signed response coché ou non : l'assertion est signée dans les deux cas.
- Réglez Name ID format sur EMAIL et Name ID sur Basic Information, Primary email. Cliquez sur Continue.
- Facultatif : sous Attribute mapping, associez Primary email à
email. Cliquez sur Finish. - Ouvrez User access dans l'application et activez-la avec ON for everyone, ou pour les unités organisationnelles qui doivent utiliser intoCHAT.
Vérifier vos domaines
L'authentification unique ne fonctionne que pour les adresses e-mail des domaines que vous avez vérifiés. Cela prouve que votre entreprise possède le domaine, pour que personne d'autre ne puisse connecter des personnes de ce domaine à son propre compte.
- Sous Domains, saisissez un domaine, comme
acme.com, et cliquez sur Add domain. Saisissez uniquement le domaine : pas dehttps://, pas de@. Les sous-domaines commemail.acme.comsont des domaines distincts. - Ajoutez l'enregistrement TXT affiché,
intochat-verification=…, chez votre fournisseur DNS, sur le domaine lui-même (hôte@chez la plupart des fournisseurs). - Cliquez sur Verify. Le domaine affiche Verified dès qu'intoCHAT trouve l'enregistrement.
Les changements DNS peuvent mettre quelques minutes, parfois jusqu'à 48 heures, à être visibles partout. Si l'enregistrement n'est pas encore trouvé, attendez et cliquez de nouveau sur Verify. Les vérifications sont limitées à 20 toutes les 10 minutes par compte.
- Un domaine ne peut être vérifié que pour un seul compte intoCHAT. Si un autre compte l'a déjà vérifié, son ajout est refusé.
- Un domaine seulement ajouté (en attente) n'a aucun effet. Un autre compte peut avoir le même domaine en attente ; le premier qui le vérifie le garde.
- Une fois vérifié, un domaine le reste. Vous pouvez ensuite supprimer l'enregistrement TXT, mais le garder ne pose aucun problème.
- Pour retirer un domaine, cliquez sur l'icône de corbeille à côté. Retirer votre dernier domaine vérifié désactive l'authentification unique.
Se connecter par SSO
- Sur la page de connexion, cliquez sur Se connecter avec le SSO.
- Saisissez votre e-mail professionnel et cliquez sur Continuer.
- Connectez-vous auprès de votre IdP, si ce n'est pas déjà fait.
- Vous revenez dans intoCHAT, dans le compte de votre entreprise.
La connexion commence toujours sur intoCHAT. Partir de la tuile intoCHAT dans le tableau de bord d'applications de votre IdP (connexion initiée par l'IdP) n'est pas pris en charge et affiche « L'authentification unique n'a pas fonctionné ». Une telle connexion ne peut pas être rattachée à une connexion lancée par quelqu'un dans son propre navigateur, et c'est ce rattachement qui empêche une réponse d'être réutilisée ou glissée dans le navigateur de quelqu'un d'autre. Dans Okta et Google Workspace, vous pouvez masquer la tuile aux utilisateurs.
Qui peut entrer
Quand votre IdP indique qui s'est connecté, intoCHAT vérifie l'adresse e-mail :
- Son domaine doit être vérifié pour votre compte, pour tout le monde, vous et les membres existants compris. Une adresse d'un autre domaine est refusée avec un message indiquant que le domaine n'est pas vérifié.
- Vous, le propriétaire, vous connectez à votre compte.
- Un membre de votre équipe se connecte avec son rôle actuel.
- Une personne avec une invitation en attente rejoint l'équipe avec le rôle de l'invitation, qui est acceptée.
- Toute autre personne rejoint votre équipe avec le Role for new members. Si elle n'a pas encore d'identifiant intoCHAT, un identifiant est créé pour elle, sans mot de passe. Si elle en a déjà un (avec son propre compte), elle le garde et devient aussi membre du vôtre.
Les majuscules et minuscules de l'adresse e-mail n'ont pas d'importance. Les super administrateurs (l'équipe d'intoCHAT) ne peuvent pas se connecter par SSO.
Sièges
Une personne qui rejoint l'équipe par SSO utilise un siège, comme un membre invité. Enterprise comprend des sièges illimités. Si votre compte n'a plus de siège libre, par exemple après un changement d'offre, les personnes qui ne font pas encore partie de votre équipe sont refusées avec « Le compte intoCHAT de votre organisation n'a plus de place pour de nouveaux membres » ; les membres actuels se connectent toujours.
Rôles et retrait de personnes
Le Role for new members ne s'applique qu'aux personnes qui rejoignent l'équipe pour la première fois. Changez le rôle de n'importe qui plus tard dans Settings puis Team ; la connexion SSO suivante ne le rétablit pas. Retirer quelqu'un de l'équipe met fin à son accès à votre compte, mais s'il peut encore se connecter auprès de votre IdP, sa connexion SSO suivante l'ajoute de nouveau avec le rôle par défaut. Pour tenir quelqu'un à l'écart, retirez-lui aussi l'accès à l'application intoCHAT dans votre IdP.
Imposer le SSO
Activez Require SSO for members with these domains pour faire de l'authentification unique le seul moyen d'entrer pour les adresses de vos domaines vérifiés :
- La connexion avec un e-mail et un mot de passe est refusée avec « Votre organisation exige l'authentification unique (SSO) pour cette adresse e-mail », quel que soit le mot de passe saisi.
- La connexion avec Google est refusée de la même façon.
- Vous, le propriétaire du compte, n'êtes jamais refusé : vous pouvez donc toujours entrer pour régler les choses si votre IdP a un problème.
- Les personnes déjà connectées le restent jusqu'à ce qu'elles se déconnectent ou que leur session prenne fin.
- Cela ne s'applique que tant que l'authentification unique est activée et fonctionne (avec Enterprise, avec un certificat valide).
Imposer le SSO concerne toutes les personnes dont l'adresse appartient à vos domaines vérifiés, y compris celles qui utilisent intoCHAT pour leur propre compte plutôt que pour le vôtre.
Authentification à deux facteurs
La connexion par SSO ne demande pas de code d'authentification à deux facteurs intoCHAT, même si la personne l'a activée. C'est votre IdP qui est responsable de l'authentification multifacteur : imposez-la chez lui, par exemple avec une stratégie de connexion Okta, l'accès conditionnel d'Entra ou la validation en deux étapes de Google. L'authentification à deux facteurs s'applique toujours quand la même personne se connecte avec son e-mail et son mot de passe.
Tester la connexion
Test sign-in, sur la carte Status, ouvre votre IdP dans un nouvel onglet et vérifie sa réponse exactement comme lors d'une vraie connexion : signature, audience, horodatages, vos domaines. Cela fonctionne avant que vous activiez l'authentification unique. Un test ne connecte jamais personne et n'ajoute jamais personne à votre équipe. Quand il réussit, la page affiche « La connexion de test a fonctionné » avec l'adresse envoyée par votre IdP (en partie masquée).
Faites le test avec un compte de votre IdP dont l'e-mail appartient à un domaine vérifié.
Supprimer l'authentification unique
Sous Delete single sign-on, cliquez sur Delete single sign-on et confirmez. La connexion par SSO cesse immédiatement de fonctionner et vos domaines sont libérés. Les personnes qui ont rejoint l'équipe par SSO y restent. Celles qui n'ont pas de mot de passe peuvent se connecter avec Google, ou définir un mot de passe avec Mot de passe oublié ? sur la page de connexion.
Si votre compte quitte l'offre Enterprise, la connexion reste configurée mais cesse de fonctionner jusqu'à ce que vous repassiez à Enterprise, et Require SSO ne s'applique plus.
Dépannage
- « L'authentification unique n'est pas configurée pour cette adresse e-mail. » Le domaine de l'adresse n'est pas vérifié pour un compte où l'authentification unique est activée, ou le compte n'est plus sur Enterprise, ou le certificat de son IdP a expiré. Vérifiez Settings puis Single sign-on.
- « L'authentification unique n'a pas fonctionné. » intoCHAT a refusé la réponse de votre IdP. Causes fréquentes :
- l'ACS URL ou l'Entity ID dans votre IdP ne correspond pas exactement à ceux de la page intoCHAT (copiez-les de nouveau) ;
- l'assertion n'est pas signée, ou elle est signée avec un autre certificat que celui enregistré (après le renouvellement du certificat de votre IdP, collez le nouveau) ;
- la connexion a été lancée depuis le tableau de bord d'applications de l'IdP au lieu d'intoCHAT ;
- la connexion a pris plus de 10 minutes, a été lancée dans un autre navigateur, ou la page a été rechargée après la connexion ;
- les horloges de votre IdP et d'intoCHAT diffèrent de plus de 2 minutes.
- « Votre fournisseur d'identité vous a connecté avec une adresse e-mail d'un domaine qui n'est pas vérifié. » L'adresse envoyée par votre IdP n'appartient pas à un domaine vérifié. Vérifiez quelle adresse il envoie (NameID ou attribut
email) et vérifiez ce domaine. - « Le compte intoCHAT de votre organisation n'a plus de place pour de nouveaux membres. » Voir Sièges.
- « Ce lien de connexion a expiré ou a déjà été utilisé. » La dernière étape de la connexion doit avoir lieu dans la minute. Recommencez depuis Se connecter avec le SSO.
- « Trop de tentatives de connexion depuis votre réseau. » Les connexions SSO sont limitées par adresse réseau. Attendez 15 minutes.
- Le certificat affiche « expired ». Téléchargez le certificat de signature actuel depuis votre IdP et enregistrez-le sous Identity provider. Un certificat expiré arrête l'authentification unique.
Limites
- SAML 2.0 uniquement, avec une connexion lancée sur intoCHAT. Pas d'OpenID Connect, pas de connexion initiée par l'IdP.
- Un seul fournisseur d'identité par compte.
- Pas de déconnexion unique (single logout) : vous déconnecter d'intoCHAT ne vous déconnecte pas de votre IdP, et inversement.
- Pas de SCIM. Les personnes sont ajoutées à leur première connexion ; retirer quelqu'un dans votre IdP ne le retire pas de votre équipe intoCHAT.
- Les assertions chiffrées et les requêtes signées ne sont pas prises en charge.
- Les rôles viennent du réglage Role for new members, pas des groupes de l'IdP.