Des accès qui suivent l'évolution de votre organisation

Le SSO fonctionne avec tout fournisseur d'identité compatible SAML 2.0 ou OIDC, dont Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud, Rippling, Ping Identity et Auth0. Le provisionnement SCIM suit la norme SCIM 2.0 et accepte les formats de requête d'Okta et d'Entra ID, les deux cas les plus courants. D'autres clients SCIM 2.0 fonctionnent aussi s'ils filtrent avec une seule condition d'égalité, car Basedash ne prend pas en charge les opérations groupées, le tri ni les ETags.

Le SCIM synchronise les utilisateurs, les groupes et leurs appartenances. Pour chaque utilisateur, il transmet l'adresse e-mail (le userName SCIM, qui ne peut plus changer après le provisionnement), le prénom, le nom affiché, le poste, le statut actif et l'identifiant externe de votre annuaire. Les groupes sont créés, renommés et supprimés depuis le fournisseur d'identité, et y ajouter ou retirer quelqu'un met à jour son appartenance dans Basedash. Les rôles et les permissions ne sont pas synchronisés : les personnes provisionnées arrivent comme membres, et les admins décident dans Basedash de ce à quoi chaque groupe accède.

Les groupes synchronisés deviennent des groupes Basedash, et un admin accorde des accès à chacun. Les accès aux sources de données déterminent qui peut interroger une source dans le chat, les dashboards, les exports, l'éditeur SQL et les variables, et les dashboards peuvent être partagés avec des groupes précis. Sur Postgres, Basedash transmet aussi les groupes de la personne à la base via la variable de session basedash.groups, pour que les politiques de sécurité au niveau des lignes filtrent ce que chaque réponse IA peut lire. Les intégrations destinées à vos clients sont, elles, limitées par des jetons signés, comme décrit dans la page embedding.

Quand votre fournisseur d'identité désactive ou désassigne quelqu'un, il envoie une requête SCIM et Basedash désactive son appartenance à l'organisation dès réception. La personne perd l'accès aux données de l'organisation et ses chats ouverts sont restreints immédiatement : le délai dépend uniquement de la rapidité de votre fournisseur. Ses dashboards, graphiques et son historique d'audit restent en place pour l'équipe. Une suppression SCIM désactive aussi sans effacer, un nouveau provisionnement du même e-mail restaure la même appartenance, et le dernier admin actif ne peut pas être désactivé.

Oui. Une fois le SSO configuré pour un domaine vérifié, toute personne ayant une adresse sur ce domaine doit se connecter ou s'inscrire via votre fournisseur d'identité. Vous ajoutez le domaine dans les paramètres, le vérifiez avec un enregistrement DNS TXT, et pouvez laisser les personnes de ce domaine rejoindre l'organisation automatiquement. Les organisations qui n'utilisent pas SAML peuvent plutôt imposer la connexion Google à tous leurs membres.

Le SSO et le SCIM font partie de l'offre Enterprise, avec les journaux d'audit, et seuls les admins de l'organisation peuvent les configurer. Ils sont aussi inclus dans les déploiements auto-hébergés, où le SCIM utilise les mêmes endpoints sur votre propre URL de base, sans variable d'environnement supplémentaire. Si les requêtes SCIM renvoient 403 Forbidden, le jeton est valide mais l'organisation n'a pas d'offre incluant le provisionnement. Voir Enterprise pour le reste de l'offre, ou l'auto-hébergement pour faire tourner Basedash dans votre infrastructure.

Un admin de l'organisation ouvre Paramètres, puis Sécurité, et crée un jeton SCIM nommé. Il commence par bd_scim_ et ne s'affiche qu'une fois, car Basedash n'en stocke qu'un hachage. Dans Okta ou Entra ID, créez une application SCIM 2.0, indiquez l'URL de base https://charts.basedash.com/scim/v2 et utilisez le jeton comme bearer token. Testez la connexion, puis assignez les personnes et les groupes qui ont besoin d'accès. Pour une rotation, créez un nouveau jeton, remplacez-le, testez, puis révoquez l'ancien.