Skip to main content
La fédération d’identité relie la page de connexion 0flaw à votre fournisseur d’identité (IdP) : Microsoft Entra ID, Okta, Google Workspace, Ping… Vos salariés s’authentifient avec leur compte d’entreprise habituel, et c’est votre politique de sécurité — Microsoft Authenticator, clés de sécurité, accès conditionnel — qui protège l’accès à 0flaw.
  • Un seul compte : plus de mot de passe 0flaw à retenir (mode SSO complet).
  • Votre MFA, pas le nôtre : la double authentification est imposée par votre DSI, centralement, comme pour vos autres applications.
  • Offboarding instantané : compte désactivé dans votre annuaire → accès 0flaw coupé.
SSO et SCIM sont complémentaires : le provisioning SCIM crée et archive les comptes, la fédération les authentifie. Ensemble, ils couvrent tout le cycle de vie — arrivée, connexion, départ — sans intervention manuelle.

​
Choisir son protocole et son mode

Protocole — les deux standards du marché sont supportés, au choix : Mode de fédération — deux niveaux d’intégration :
  • SSO complet : l’IdP remplace mot de passe et 2FA. Le salarié saisit son e-mail, clique « Se connecter avec SSO », s’authentifie chez vous, et arrive connecté.
  • SSO comme 2e facteur : le salarié garde son mot de passe 0flaw, puis valide chez votre IdP à la place du code TOTP. Utile si votre politique interne impose un mot de passe applicatif distinct.

​
Prérequis

  • Un compte administrateur 0flaw (la configuration est en self-service).
  • Les droits de créer une application dans votre IdP (Entra : « Administrateur d’application » ; Okta : rôle admin).
  • Les comptes de vos salariés doivent exister dans 0flaw avec le même e-mail que dans l’annuaire — créés manuellement, importés, ou provisionnés par SCIM. (Le provisioning automatique à la première connexion est possible, voir les options avancées.)
  • Licences : avec Microsoft Entra ID, l’OIDC (inscription d’application) est disponible sur toutes les éditions, y compris gratuite. Le SAML via une application d’entreprise personnalisée requiert Entra ID P1 ou supérieur. Chez Okta et Google Workspace, OIDC et SAML sont inclus dans les offres standard. En cas de doute, choisissez OIDC.

​
Sécurité : ce que 0flaw voit — et ne voit pas

​
Étape A — Créer l’application dans votre IdP

1

Ouvrir la carte SSO dans 0flaw

Dashboard : Paramètres avancés → Intégrations annuaire → carte « Fédération d’identité (SSO) ». La colonne de droite « À configurer dans votre IdP » affiche les URLs à copier (Redirect URI pour OIDC ; URL ACS, Entity ID et metadata pour SAML).
2

Microsoft Entra ID — OIDC (le cas le plus courant)

Sur entra.microsoft.com : Identité → Applications → Inscriptions d’applications → Nouvelle inscription. Type de compte : Locataire unique. Plateforme Web, avec la Redirect URI copiée depuis la carte.Récupérez ensuite trois valeurs :
  • ID d’application (client) → votre Client ID ;
  • ID de l’annuaire (locataire) → votre issuer : https://login.microsoftonline.com/<ID-du-locataire>/v2.0 ;
  • Certificats & secrets → Nouveau secret client → copiez la Valeur immédiatement (elle n’est affichée qu’une fois).
3

Ou : Entra ID en SAML / Okta

Entra SAML : Applications d’entreprise → Nouvelle application → hors galerie → Single sign-on : SAML. Collez l’URL ACS (Reply URL) et l’Entity ID affichés dans la carte, puis récupérez l’URL de connexion et le certificat (Base64).Okta : Applications → Create App Integration → OIDC Web Application (ou SAML 2.0). Issuer OIDC : https://<votre-org>.okta.com.

​
Étape B — Configurer la carte SSO dans 0flaw

1

Renseigner la connexion

Choisissez le protocole et le mode, puis collez les valeurs récupérées à l’étape A. Le Client Secret n’est jamais réaffiché après enregistrement (laissez le champ vide pour le conserver lors d’une modification ultérieure).
2

Déclarer vos domaines e-mail

Ajoutez les domaines de vos salariés (ex. acme.fr). Par sécurité, seuls des domaines déjà présents parmi les utilisateurs de votre organisation sont acceptés — et jamais un domaine grand public (gmail.com, orange.fr…).
3

Enregistrer, tester, puis test réel

Enregistrer la configuration, puis « Tester la configuration » (0flaw vérifie que votre IdP est joignable / que le certificat est valide). Enfin, « Lancer un test de connexion réel » ouvre le flux complet dans un nouvel onglet : authentifiez-vous chez votre IdP et vérifiez que vous arrivez connecté.
4

Autoriser les comptes

Section « Comptes autorisés au SSO » : cochez les salariés concernés (ou « Tout activer »). Seuls les comptes cochés voient le bouton « Se connecter avec SSO » — les autres gardent leur connexion habituelle. Déployez progressivement : un pilote, une équipe, puis tout le monde.
N’activez « Exiger le SSO » (blocage du mot de passe pour les employés) qu’après un test réel réussi. Les administrateurs restent toujours exemptés — c’est votre accès de secours si votre IdP est indisponible ou mal configuré.

​
Comment se passe la connexion pour vos salariés

  1. Sur la page de connexion, le salarié saisit son e-mail puis « Continuer ».
  2. Si son compte est autorisé au SSO, le bouton « Se connecter avec SSO » apparaît (ou la redirection est immédiate si vous avez activé « Exiger le SSO »).
  3. Il s’authentifie chez votre IdP — votre MFA s’applique — et revient connecté.
La connexion est liée à l’e-mail saisi : si quelqu’un s’authentifie chez l’IdP avec un autre compte que celui indiqué, la connexion est refusée. Et une identité prouvée par l’IdP ne suffit jamais : le compte doit exister dans 0flaw et être autorisé au SSO.

​
Options avancées — provisioning automatique & mapping

  • Création automatique des comptes inconnus (JIT) : un salarié authentifié par votre IdP mais absent de 0flaw est créé à la volée au premier login (dans la limite de votre quota de licences, avec son secteur déduit du champ département). Désactivé par défaut — si vous utilisez SCIM, laissez SCIM piloter les créations.
  • Rôle par défaut et mapping groupes → rôle : attribuez un rôle 0flaw (employe, admin, dsi, rssi) selon les groupes de l’annuaire. Le rôle n’est appliqué qu’à la création du compte, jamais modifié aux connexions suivantes. Les rôles à privilèges plateforme (creator, MSP, distributeur) ne sont jamais attribuables via le SSO.
  • Mapping d’attributs : si votre IdP n’envoie pas les attributs standard, indiquez les noms d’attributs SAML (e-mail, prénom, nom) ou de claims OIDC (groupes, département) à utiliser.

​
Messages d’erreur courants

​
Questions fréquentes

Le 2FA de 0flaw est-il encore utilisé ? En SSO complet, non : votre IdP applique votre propre MFA. En mode « 2e facteur », le mot de passe 0flaw reste, et l’IdP remplace uniquement le code TOTP. Que se passe-t-il si notre IdP tombe en panne ? Les administrateurs conservent toujours la connexion par mot de passe (accès de secours). Vous pouvez désactiver « Exiger le SSO » à tout moment pour rendre le mot de passe aux employés. Peut-on changer d’IdP ? Oui — remplacez simplement la configuration dans la carte (les comptes et leur historique ne bougent pas, le matching se fait par e-mail).