SSO d’entreprise et provisionnement
Configurer l’authentification unique (OIDC, OAuth2, SAML 2.0) et le provisionnement SCIM des utilisateurs et des groupes pour ton organisation. Configuration pas à pas pour Microsoft Entra ID, Google, OIDC générique et SAML, ainsi que le mappage des rôles, la synchronisation groupe-vers-équipe et la désactivation. À lire pour câbler l’identité d’entreprise de l’organisation.
7 min de lecture
Le SSO d’entreprise permet à tes membres de se connecter via ton fournisseur d’identité (IdP) plutôt qu’avec un mot de passe Tale, et SCIM laisse l’IdP créer, mettre à jour et désactiver automatiquement les membres et les groupes — sans invitation manuelle. Une connexion par organisation porte ensemble le protocole de connexion, la politique de provisionnement et le jeton SCIM. Tout se trouve sur une seule page : Paramètres > SSO d'entreprise (administrateurs uniquement).
Tale parle quatre protocoles : OIDC, OAuth2 simple, SAML 2.0 pour la connexion et SCIM 2.0 pour le provisionnement. Tu peux activer la connexion, le provisionnement, ou les deux.
Choisir un protocole
Ouvre Paramètres > SSO d'entreprise, choisis un Protocole et remplis uniquement les champs de ce protocole — les autres restent masqués. Un Guide de configuration sur la même page liste les étapes exactes et affiche les URL à coller dans ton IdP. Utilise Tester la connexion avant d’enregistrer pour valider la configuration, et Enregistrer pour activer la connexion.
- Microsoft Entra ID — l’OIDC de Microsoft, avec synchronisation groupe-vers-équipe via Microsoft Graph.
- OIDC générique — n’importe quel fournisseur OpenID Connect (Google, Okta, Auth0, Keycloak, …). Les points de terminaison sont détectés depuis l’émetteur.
- OAuth2 — fournisseurs sans découverte OIDC ; tu configures manuellement les points de terminaison d’autorisation, de jeton et userinfo.
- SAML 2.0 — SSO basé sur XML ; tu échanges des métadonnées avec l’IdP.
Microsoft Entra ID
- Connecte-toi au centre d’administration Microsoft Entra en tant que développeur d’applications au minimum.
- Va dans Entra ID > Inscriptions d'applications > Nouvelle inscription, nomme-la et choisis Locataire unique.
- Sous URI de redirection, sélectionne la plateforme Web, colle l'URL de redirection affichée sur la page Tale, puis clique sur Inscrire.
- Sur la Vue d'ensemble, copie l'ID d'application (client) et l'ID de répertoire (locataire). Ton URL d’émetteur est
https://login.microsoftonline.com/{tenant-id}/v2.0. - Ouvre Certificats et secrets > Nouveau secret client et copie la Valeur du secret (pas son ID).
- Dans Tale, choisis Microsoft Entra ID et saisis l’ID client, le secret client et l’URL d’émetteur.
- Pour la synchronisation groupe-vers-équipe, ajoute l’autorisation Microsoft Graph GroupMember.Read.All sous Autorisations d'API et accorde le consentement administrateur.
- Pour la synchronisation de documents OneDrive et SharePoint, ajoute les autorisations Microsoft Graph Files.Read et Sites.Read.All sous Autorisations d'API et accorde le consentement administrateur. Une nouvelle connexion demande les deux par défaut — le token SSO sert aussi de token Graph, les membres peuvent donc importer des fichiers dès la connexion. Si l’organisation ne veut que la connexion, retire ces deux scopes du champ Scopes ; l’entrée Microsoft 365 reste alors masquée sur la page des documents.
Google se configure comme un fournisseur OIDC générique.
- Dans la console Google Cloud, ouvre API et services > Identifiants > Créer des identifiants > ID client OAuth.
- Choisis le type d’application Application Web.
- Sous URI de redirection autorisés, ajoute l'URL de redirection affichée sur la page Tale, puis enregistre.
- Copie l'ID client et le secret client en haut de la page du client.
- Dans Tale, choisis OIDC générique, saisis l’ID client et le secret, et définis l’URL d’émetteur sur
https://accounts.google.com. Les points de terminaison sont détectés automatiquement.
L’OIDC standard de Google ne renvoie pas les appartenances aux groupes : la synchronisation groupe-vers-équipe n’est donc pas disponible avec Google seul — elle nécessite l’Admin SDK / l’API Cloud Identity avec un administrateur Workspace. La connexion et le mappage de rôle par claim fonctionnent normalement.
OIDC générique et OAuth2
Pour tout autre fournisseur OIDC (Okta, Auth0, Keycloak), choisis OIDC générique, colle l'URL d'émetteur et l’ID/secret client — Tale lit les points de terminaison d’autorisation, de jeton et userinfo depuis le .well-known/openid-configuration de l’émetteur.
Si un fournisseur expose OAuth2 mais pas de document de découverte, choisis OAuth2 et saisis manuellement les URL des points de terminaison d'autorisation, de jeton et userinfo. Lorsque le fournisseur utilise des noms de claims non standard, mappe e-mail, nom et groupes dans les champs avancés de la connexion (les chemins en points sont pris en charge, p. ex. realm_access.roles).
SAML 2.0
- Dans Tale, choisis SAML 2.0. La page affiche ton URL des métadonnées SP et ton URL ACS (réponse) — copie-les.
- Dans ton IdP, crée une nouvelle application SAML 2.0. Définis son URL ACS et son Entity ID / Audience sur les valeurs SP affichées (ou importe l’URL des métadonnées SP), et le format Name ID sur l’adresse e-mail.
- Sous Importer les métadonnées de l'IdP, colle l’URL des métadonnées de fédération de ton IdP et clique sur Importer — ou clique sur Téléverser le XML si ton IdP ne propose qu’un fichier à télécharger. Tale lit les métadonnées et remplit l’ID d’entité, l’URL de connexion et le certificat de signature dans les champs ci-dessous, sans que tu aies à les ressaisir. Les trois champs restent modifiables — vérifie les valeurs importées (ou saisis-les toi-même si ton IdP ne publie aucune métadonnée) avant d’enregistrer.
- Mappe les attributs e-mail, nom et groupe dans ton IdP ; si leurs noms diffèrent des valeurs par défaut, indique les noms d’attributs correspondants dans les champs avancés de Tale.
Tale prend en charge le SAML initié par l’IdP (l’IdP envoie une assertion à l’URL ACS) et le SAML initié par le SP (un membre clique sur Se connecter avec le SSO et Tale redirige vers l’IdP). Les assertions signées sont requises ; les assertions chiffrées sont prises en charge si tu fournis une paire de clés SP.
Plusieurs organisations sur un même déploiement
Un déploiement peut héberger plusieurs organisations, chacune avec sa propre connexion. Sur la page de connexion, clique sur Continuer avec SSO, puis choisis ton organisation dans la liste — chaque entrée affiche le Nom affiché de la connexion. Ce nom est visible par quiconque sur la page de connexion ; définis un nom clair par connexion dans Paramètres > Enterprise SSO.
Provisionnement : rôles et équipes
Chaque protocole partage une politique de provisionnement :
- Rôle par défaut — le rôle attribué à un membre nouvellement provisionné (Membre par défaut).
- Attribution automatique des rôles — lorsqu’il est activé, des règles de mappage associent un intitulé de poste, un rôle d’application, un groupe ou un claim à un rôle de la plateforme ; le rôle par défaut s’applique si rien ne correspond.
- Synchroniser les groupes en équipes — lorsqu’il est activé, chaque groupe IdP de l’utilisateur devient (ou rejoint) une équipe du même nom à la connexion ; Exclure des groupes ignore les groupes parasites (séparés par des virgules).
Provisionnement SCIM (utilisateurs et groupes)
SCIM permet à ton IdP de transmettre les changements sans que personne ne se connecte. Dans la section Provisionnement SCIM, clique sur Générer un jeton — copie-le une seule fois (il n’est plus jamais affiché) — et colle-le, avec l'URL de base SCIM affichée, dans les paramètres de provisionnement de ton IdP. L’IdP s’authentifie avec le jeton comme identifiant Bearer ; Tale détermine l’organisation à partir du jeton, qui constitue donc la frontière de locataire.
Tale implémente SCIM 2.0 Users et Groups : créer, lire, lister (avec filtres userName/displayName), remplacer, modifier (patch) et supprimer. Les utilisateurs provisionnés correspondent à des membres de l’organisation, les groupes à des équipes. La désactivation est douce — lorsque l’IdP rend un utilisateur inactif (active: false), le rôle du membre passe à disabled (ce qui retire son accès), et une réactivation restaure son rôle précédent. Une suppression SCIM retire l’appartenance à l’organisation ; le compte utilisateur est conservé, et un nouveau provisionnement le rattache avec le rôle par défaut de la connexion. Le propriétaire de l’organisation ne peut jamais être déprovisionné via SCIM.
Vérification
Utilise Tester la connexion pour OIDC/OAuth2 afin de confirmer la découverte et les identifiants avant d’enregistrer. Pour SAML, importe les métadonnées SP dans ton IdP et effectue une connexion de test. Pour SCIM, la plupart des IdP proposent une action « test » ou « provisionner maintenant » qui crée un utilisateur d’exemple — vérifie qu’il apparaît sous Paramètres > Membres. Une connexion SSO de bout en bout se vérifie au mieux contre ton IdP réel dans une organisation de préproduction.