Aller au contenu

Configuration du SSO (Single Sign-On)

Confiez l’authentification de Cord au fournisseur d’identité de votre entreprise (Okta, Google Workspace, Azure AD).

Sécurité d’entreprise

À mesure que les organisations grandissent, gérer les utilisateurs et les mots de passe un par un devient un risque ingérable. Cord prend en charge les intégrations SSO via SAML 2.0 avec son propre moteur (pas une simple case à cocher cosmétique) : validation de la signature XML-DSig, protection contre le rejeu, provisionnement automatique des comptes, attribution des rôles par attribut et un mécanisme d’urgence en cas de panne de votre fournisseur d’identité.

En activant le SSO dans votre organisation Cord :

  • Vos collaborateurs se connectent automatiquement s’ils sont déjà authentifiés sur le portail professionnel de leur entreprise.
  • Toute politique de MFA que vous imposez déjà dans votre fournisseur d’identité (Okta, Azure AD, Google Workspace) s’applique : Cord délègue entièrement l’authentification, il ne voit donc jamais ce second facteur et ne le gère pas.
  • Activer « Exiger le SSO » bloque le mot de passe, Google, Apple et les clés d’accès pour tous les membres, sauf le propriétaire du compte, qui conserve toujours son mot de passe en secours — le seul accès qui ne dépend pas de la disponibilité de votre IdP.
  • L’exigence s’applique à votre organisation, pas au compte : une personne qui appartient aussi à une autre organisation dotée de son propre SSO ne peut pas se connecter par celui-ci puis basculer vers la vôtre. Lorsqu’elle ouvre votre organisation, Cord l’invite à se connecter avec votre fournisseur d’identité.

Prérequis

  1. Votre organisation doit disposer de l’offre Scale de Cord ou d’une offre supérieure (Developer) — le SSO n’est pas disponible dans les offres Gratuite, Starter et Professionnel.
  2. Vous avez besoin du droit equipo (équipe) dans votre rôle Cord (le Propriétaire et l’Administrateur l’ont par défaut ; un rôle personnalisé peut aussi l’avoir).
  3. Vous devez disposer des privilèges d’administrateur dans votre fournisseur d’identité (Okta, Azure AD / Microsoft Entra, Google Workspace ou tout IdP SAML 2.0).

Où le configurer

Paramètres › Équipe et droits › SSO (il ne se trouve pas sous Sécurité — le SSO fait partie du même groupe qu’Équipe et rôles, car il détermine qui accède à l’organisation, et il partage le droit equipo).

Étapes de configuration SAML

L’échange se fait dans les deux sens, mais l’ordre réel inverse ce que beaucoup attendent : vous fournissez d’abord à Cord les données de votre IdP, et Cord génère les siennes à partir de celles-ci — et non l’inverse.

  1. Dans votre fournisseur d’identité, créez une nouvelle application SAML pour Cord et téléchargez ou copiez son XML de métadonnées (la plupart des IdP l’exposent à une URL publique ou via un bouton « Download metadata »).
  2. Dans Cord, allez dans Paramètres › Équipe et droits › SSO › Connecter un fournisseur, donnez un nom à la connexion et collez ce XML. Cord l’analyse automatiquement : il extrait l’Entity ID de l’IdP, son URL de connexion, son ou ses certificats X.509 de signature et, s’il existe, son URL de Single Logout — inutile de saisir ces champs à la main (le détail de la connexion les laisse toutefois modifiables par la suite, au cas où votre IdP renouvellerait son certificat).
  3. Une fois la connexion créée, Cord vous affiche trois valeurs propres à votre organisation : l’ACS URL (Assertion Consumer Service — l’adresse à laquelle votre IdP doit envoyer la réponse SAML), l’Entity ID de Cord et la Metadata URL. Revenez dans votre fournisseur d’identité et renseignez-les dans l’application créée à l’étape 1.
  4. Faites un test avec un seul utilisateur avant d’exiger le SSO pour toute l’équipe — une mauvaise correspondance d’attributs peut bloquer l’accès (lock out) de tout votre personnel.

Provisionnement et rôles, pas seulement la connexion

Dans Cord, le SSO ne se limite pas à « se connecter autrement » — il décide automatiquement quel compte est créé et avec quel rôle :

  • Provisionnement JIT (Just-in-Time) : activé par défaut. La première fois qu’une personne se connecte via cette connexion, Cord crée son compte et l’ajoute à l’organisation lors de cette même connexion — inutile de l’inviter d’abord manuellement depuis Équipe.
  • Attribution des rôles par attribut : définissez des règles du type « si l’attribut groups envoyé par mon IdP contient finance-admin, attribuer le rôle Administrateur ». Chaque règle compare un attribut SAML (equals, contains ou regex) à une valeur et à un rôle Cord ; les règles sont évaluées dans l’ordre et la première qui correspond l’emporte. Si aucune ne s’applique, le compte reçoit le rôle par défaut que vous configurez pour la connexion (par ex. Lecture seule).
  • Connexion initiée par l’IdP : vous pouvez permettre à un collaborateur de se connecter directement depuis le portail d’applications de son IdP (Okta, MyApps de Microsoft), sans passer d’abord par cordhq.app. Comme cet accès n’a pas commencé dans son navigateur, Cord lui indique avec quelle adresse e-mail il va se connecter et lui demande de confirmer avec Continuer avant d’ouvrir la session.

Domaines vérifiés (facultatif, recommandé)

Vous pouvez lier une connexion SSO à un ou plusieurs domaines de messagerie (votreentreprise.com) au moyen d’un enregistrement TXT dans votre DNS — le même principe de vérification que pour un domaine d’envoi d’e-mails. Avec au moins un domaine vérifié, seules les adresses de ce domaine peuvent se connecter via cette connexion ; sans domaine vérifié, la connexion n’applique aucune restriction de domaine.

En cas de panne de votre fournisseur d’identité (break-glass)

Lorsque « Exiger le SSO » est activé, un fournisseur d’identité indisponible bloque l’accès de toute l’organisation — sauf celui du propriétaire du compte. Si le reste de l’équipe doit se connecter temporairement avec un mot de passe, le propriétaire peut utiliser le bouton d’urgence sur le même écran : il se réauthentifie avec son mot de passe et désactive l’exigence de SSO pendant 1 heure. Passé ce délai (ou si vous la réactivez manuellement avant), l’exigence se rétablit d’elle-même.

Important : testez l’intégration avec un seul utilisateur avant d’activer « Exiger le SSO » pour toute l’équipe — une erreur de correspondance d’attributs peut bloquer l’accès (lock out) de tout votre personnel, à l’exception du propriétaire du compte.