SSO SaaS : cadrer les exigences de vos clients entreprise

Le SSO peut être une exigence importante d’un client entreprise, mais il n’est pas obligatoire pour tous les SaaS B2B. Son intégration doit séparer identité, appartenance à une organisation et autorisations métier. Demandez les exigences de la DSI avant de promettre un protocole ou une compatibilité.

Ce que la connexion unique ne décide pas

Un fournisseur d’identité aide à établir qui se connecte. Le SaaS doit encore déterminer à quelle organisation appartient cette personne et quelles actions lui sont permises. Une adresse email ou une authentification réussie ne doit pas donner accès aux données de toutes les entreprises.

La documentation Supabase SAML décrit une configuration de fournisseurs. Les attributs et les règles de rattachement restent à définir. Les politiques RLS peuvent contrôler les données selon les conditions configurées ; leur présence ne prouve pas que les droits métier sont corrects.

Un questionnaire à utiliser avant le devis

• Quel fournisseur d’identité et quel protocole sont exigés ?
• Quelles métadonnées et quels attributs seront transmis ?
• Comment rattacher l’identité à une organisation sans ambiguïté ?
• Qui crée les comptes et attribue les rôles ?
• Comment gérer les invités, les changements d’équipe et les départs ?
• Quels tests et preuves l’équipe sécurité attend-elle ?
• Quelle procédure d’administration reste disponible en cas de panne ?

La compatibilité doit être démontrée avec la configuration prévue. Partager un protocole standard ne garantit pas que tous les annuaires et mappings fonctionneront sans adaptation.

Traiter le cycle de vie, pas seulement la première connexion

SSO, création de compte à la connexion et provisioning d’annuaire sont des mécanismes différents. Le besoin de synchronisation doit être défini ; la création à la première connexion n’est pas suffisante pour toutes les organisations.

La désactivation d’une identité ne garantit pas l’arrêt immédiat d’une session déjà ouverte dans le SaaS. Précisez comment les sessions, les jetons et les permissions sont révoqués, puis vérifiez le cas d’un départ avec une session encore active. Définissez aussi les règles d’accès des invités, sans contournement improvisé.

Ikovaline cadre ces besoins dans son offre de développement SaaS. Le guide cahier des charges B2B aide à les formaliser. Les prix de départ ne signifient pas que toute intégration SSO est incluse.

Questions fréquentes

Faut-il proposer SAML et OIDC dès le lancement ?

Pas systématiquement. Identifiez les clients visés, leurs exigences et les capacités de votre fournisseur. Chiffrez le protocole réellement nécessaire et gardez une trajectoire explicite pour les autres besoins.

Un SSO rend-il le produit conforme aux exigences d’un grand compte ?

Non. C’est une partie des exigences possibles. Accès, données, exploitation et procédures doivent être analysés séparément. Une connexion réussie n’est pas une preuve de conformité globale.