Choisir l’authentification

Tale prend en charge les comptes locaux par e-mail et mot de passe, le SSO propre à chaque organisation et les identités transmises par un reverse proxy de confiance. Choisis selon l’endroit où ton équipe gère ses identités et la personne responsable des comptes. L’authentification et le provisionnement sont distincts : le SSO authentifie, tandis que les invitations, le provisionnement à la connexion ou SCIM gèrent l’appartenance.

Choisir l’intégration adaptée

Le SSO d’entreprise et les en-têtes de confiance se configurent tous deux par organisation. Prépare et teste la correspondance des identités avant de changer le mécanisme de comptes existants.

Fixer d’abord l’URL publique

Définis SITE_URL et l’éventuel chemin de base pris en charge avec l’adresse réellement utilisée. Termine la configuration TLS et des domaines avant d’enregistrer les redirections chez le fournisseur d’identité.

Garde BETTER_AUTH_SECRET identique entre les processus backend de l’instance. Utilise le secret généré par le déploiement ou injecte-le depuis ton gestionnaire. Des valeurs différentes peuvent interrompre la connexion même si le fournisseur d’identité accepte la personne.

Utiliser des comptes locaux

La connexion locale conserve des empreintes de mots de passe dans la base applicative. La première configuration crée le Propriétaire initial ; les membres suivants rejoignent l’organisation sur invitation. Configure l’envoi d’e-mails si ton parcours d’invitation ou de récupération en dépend.

Vérifie avec un compte de test l’invitation, la connexion, la déconnexion et la récupération. Une session Propriétaire qui fonctionne ne prouve pas qu’un nouveau membre peut rejoindre l’organisation.

Tale n’envoie aucun courriel de vérification : une adresse est donc confirmée par qui crée le compte. Le premier Propriétaire issu de la configuration initiale, une personne ajoutée par un administrateur dans Paramètres > Membres et le compte créé par le déploiement valent tous comme confirmation, et le compte est utilisable immédiatement. Les applications connectées lisent cela dans l’attribut email_verified de l’identité délivrée par Tale : un collègue qui vient d’être ajouté peut donc s’y connecter tout de suite. Un compte issu du SSO d’entreprise, de SCIM ou d’en-têtes de confiance conserve en revanche ce qu’indique son annuaire.

Connecter le SSO d’entreprise

Configure l’organisation sous Paramètres > SSO d’entreprise. Microsoft Entra ID et OIDC générique découvrent les endpoints depuis l’émetteur ; OAuth2 utilise des URL explicites d’autorisation, de token et de userinfo. SAML utilise des métadonnées, une URL de réception des assertions et des certificats de signature.

Utilise les URL de callback et de métadonnées affichées. Les callbacks OIDC natifs utilisent /api/sso/callback ; la route de compatibilité /http_api/api/sso/callback reste prise en charge pour les anciennes inscriptions. L’URL enregistrée chez l’IdP doit correspondre à celle utilisée dans le parcours.

Suis SSO d’entreprise et provisionnement pour les protocoles, les claims, les rôles par défaut, les équipes et SCIM. Teste la connexion dans une session distincte avant de fermer ta session d’administration. Une découverte validée ne prouve ni les claims, ni les droits sur les groupes, ni une connexion complète.

Faire confiance à un proxy d’authentification

Une application qui connecte déjà ses utilisateurs peut les faire entrer dans une organisation via son reverse proxy. Un administrateur active la fonction dans Paramètres > SSO d’entreprise, carte En-têtes de confiance : choisis le rôle le plus élevé que le proxy peut attribuer, puis crée une clé et copie-la, car elle ne s’affiche qu’une fois. Fais pointer la connexion du proxy vers /api/trusted-headers/authenticate, avec cette clé dans l’en-tête Remote-Internal-Secret et les en-têtes d’identité Remote-Email, Remote-Name, Remote-Role et Remote-Teams. La référence d’environnement indique les variables TRUSTED_*_HEADER qui permettent de renommer ces en-têtes.

La clé détermine l’organisation. Un membre de cette organisation est connecté ; une adresse que l’instance n’a jamais vue devient un nouveau membre avec le rôle attribué ; un compte existant d’une autre organisation est refusé. Le rôle Propriétaire ne peut jamais être attribué, et un rôle au-dessus du plafond de l’organisation est ramené à ce plafond. À chaque connexion, le siège du membre suit le rôle attribué, si bien que Paramètres > Membres montre ce que le proxy a attribué ; un siège Propriétaire ne change jamais. Désactiver la carte refuse toutes les clés sans en révoquer aucune ; révoquer une clé ne met pas fin aux sessions qu’elle a ouvertes.

Remote-Teams contient des noms d’équipe séparés par des virgules, par exemple Finance,Operations ; une entrée id:name comme t-fin:Finance est aussi acceptée. Les équipes sont rapprochées et créées par nom. Un en-tête absent laisse les équipes inchangées ; un en-tête présent mais vide retire les appartenances accordées par cette synchronisation. Des entrées invalides peuvent donc supprimer ces appartenances. Celles accordées manuellement restent intactes.

Un visiteur qui arrive par le proxy est connecté dès la première requête que l’application fait pour elle-même : si cette requête porte la clé et l’en-tête d’identité mais aucun cookie de session, le backend crée la session sur place et l’application s’ouvre connectée — sans page de connexion, sans redirection. Si l’application atterrit malgré tout sur sa page de connexion (un cookie périmé, par exemple), la page envoie elle-même le navigateur vers l’adresse de passage, et un refus revient sur cette page avec sa raison. Rediriger /log-in du proxy directement vers l’adresse de passage reste possible ; l’adresse répond à un succès par une redirection vers l’application et à un refus par une page avec son code d’état. Le proxy possédant la session, l’application ne propose pas de déconnexion à un membre connecté ainsi ; après une déconnexion pour inactivité, la connexion automatique marque une pause jusqu’à ce que le membre continue depuis l’avis.

Pour afficher Tale dans la page de l’application elle-même plutôt que dans un onglet, un administrateur ajoute l’origine de cette page sous Intégration dans un cadre, sur la même page de paramètres. Les pages de Tale répondent alors avec une règle frame-ancestors qui nomme 'self' et les origines listées au lieu de refuser tout cadre, et l’en-tête X-Frame-Options disparaît. La liste appartient à une organisation, mais l’enveloppe de connexion est un seul document pour toute l’instance : une origine admise par n’importe quelle organisation peut donc la charger. Le navigateur n’envoie le cookie de session dans un cadre que si la page englobante est sur le même site que Tale, par exemple un sous-domaine de l’hôte ou Tale servi sous le domaine de l’hôte ; un cadre d’un autre site affiche la page de connexion.

Diagnostiquer les échecs de connexion

Teste les changements de correspondance dans une organisation de staging et garde un accès administratif de secours déjà vérifié. Ces changements peuvent affecter tous les membres dont l’identité dépend de la connexion.