SSO entreprise (OIDC, SAML) & authentification multi-facteurs (MFA)

Emplacement de la configuration

Les administrateurs d'entreprise accèdent à ces paramètres via Paramètres → Entreprise, dans les onglets Méthodes de connexion et Double authentification.

VPN, proxy ou pare-feu d'entreprise

Si vos utilisateurs se connectent derrière un VPN, un proxy d'entreprise ou un pare-feu avec inspection SSL, certains flux du SSO peuvent être bloqués ou altérés (cookie d'état supprimé, domaines d'identité inaccessibles). Le symptôme typique est une connexion qui échoue ou tourne en boucle — alors que le SSO fonctionne hors VPN. Communiquez à votre équipe réseau la matrice des flux réseau pour autoriser les domaines nécessaires sans inspection SSL ni réécriture des cookies.

Méthodes de connexion disponibles

FoxPlan supporte plusieurs approches d'authentification :

• Mot de passe
• Google Sign-in
• Microsoft Sign-in
• SSO entreprise (OIDC)
• SSO entreprise (SAML 2.0)

Important

Les administrateurs d'entreprise conservent toujours la connexion par mot de passe, même lorsqu'elle est désactivée pour l'entreprise. Cela évite de se retrouver verrouillé hors de FoxPlan si le fournisseur d'identité devient indisponible.

Exceptions : conserver le mot de passe pour certains utilisateurs

Lorsque vous basculez votre organisation vers le SSO, vous pouvez désactiver la connexion par mot de passe pour tout le monde sauf une liste d'utilisateurs désignés.

Décochez Mot de passe : un sélecteur « Exceptions : utilisateurs conservant le mot de passe » apparaît alors sous les cases à cocher. Choisissez-y les utilisateurs concernés, puis enregistrez.

Ces utilisateurs continueront de voir le champ mot de passe sur l'écran de connexion, tandis que tous les autres devront passer par le SSO ou la connexion Google/Microsoft.

Cas d'usage typiques :

• Comptes de secours (« break-glass ») en cas de panne du fournisseur d'identité
• Prestataires ou externes absents de votre annuaire d'entreprise
• Migration progressive : basculer les équipes vers le SSO par vagues

Le réglage est appliqué par le serveur, pas seulement par la page de connexion : une connexion par mot de passe passée par l'API ou par l'application mobile est refusée, et Avez-vous oublié votre mot de passe ? n'envoie aucun lien. Les administrateurs d'entreprise et les exceptions ci-dessus gardent leur accès. Les comptes d'API, authentifiés par jeton, ne sont pas concernés.

astuce

Le sélecteur n'est visible que si la méthode Mot de passe est décochée : tant qu'elle est active, elle s'applique déjà à tout le monde et aucune exception n'est nécessaire.

Options MFA

Les organisations peuvent choisir parmi :

• TOTP (compatible Google Authenticator, Microsoft Authenticator, Okta, Keycloak)
• Vérification par email
• Pas de MFA

Périmètre : à qui s'applique la double authentification

Dès qu'une méthode est sélectionnée (TOTP ou Email), une section « S'applique à » permet de choisir la population concernée :

Option	Effet
Tous les utilisateurs	La double authentification s'impose à toute l'entreprise (comportement par défaut).
Uniquement les utilisateurs listés	Seuls les utilisateurs sélectionnés passent par la double authentification.
Tous les utilisateurs sauf ceux listés	La double authentification s'applique partout, sauf pour les utilisateurs sélectionnés.

Pour les deux derniers modes, un sélecteur permet de désigner les utilisateurs concernés.

Cas d'usage typiques :

• Déploiement progressif : commencer par « Uniquement les utilisateurs listés » avec une équipe pilote, puis basculer sur « Tous les utilisateurs ».
• Renforcement ciblé : n'exiger la double authentification que pour les administrateurs et les profils sensibles.
• Exclusions techniques : dispenser des comptes qui ne peuvent pas répondre à un défi MFA (comptes de service, bornes partagées) via « Tous les utilisateurs sauf ceux listés ».

Le périmètre est appliqué côté serveur : un utilisateur hors périmètre se connecte directement, sans défi MFA, même si une méthode est active pour l'entreprise.

attention

En mode « Tous les utilisateurs sauf ceux listés », chaque utilisateur exclu constitue un affaiblissement du niveau de sécurité. Revoyez cette liste régulièrement.

Flux de connexion

1. L'utilisateur saisit son email et continue
2. FoxPlan identifie l'entreprise associée
3. Les méthodes d'authentification disponibles pour cette organisation s'affichent
4. L'utilisateur choisit Mot de passe ou SSO selon les options activées

Pour les flux par mot de passe, les défis MFA s'appliquent. Les flux SSO délèguent l'authentification au fournisseur d'identité.

Configuration SSO entreprise (OIDC)

FoxPlan supporte les fournisseurs OIDC : Okta, Keycloak, Google, Microsoft et implémentations personnalisées.

Côté fournisseur d'identité :

• Créer une application OIDC de type Web
• URL de redirection : {origin}/login/oauth2/code/{registrationId}
• Collecter Client ID, Client Secret (ou certificat, voir ci-dessous) et Issuer URI

Côté formulaire SSO FoxPlan :

• Sélection du fournisseur
• Nom d'affichage
• Client ID
• Authentification du client : secret partagé ou certificat
• Issuer URI
• Scopes : openid,profile,email
• Attribut username (typiquement sub ou email)
• Toggle d'activation

Configuration SSO entreprise (SAML 2.0)

Pour les fournisseurs d'identité qui ne parlent que SAML — AD FS antérieur à Windows Server 2016, ou SAML imposé par votre politique de sécurité — et pour tout fournisseur SAML 2.0 : Entra ID, Okta, Keycloak, Shibboleth… Une fois connecté, l'utilisateur obtient exactement la même session qu'en OIDC.

Côté formulaire SSO FoxPlan, choisissez le fournisseur SAML 2.0, puis renseignez de préférence les métadonnées du fournisseur :

• URL des métadonnées — pour AD FS : https://<serveur-adfs>/FederationMetadata/2007-06/FederationMetadata.xml. Elle est relue à chaque connexion : un certificat de signature renouvelé chez le fournisseur est pris en compte sans intervention.
• ou métadonnées XML collées, si le serveur FoxPlan ne peut pas joindre cette URL. Un XML illisible est refusé dès l'enregistrement. Recollez-le quand le fournisseur renouvelle son certificat.

Les métadonnées apportent l'entity ID, l'URL SSO et le certificat de signature du fournisseur. Sans elles, renseignez ces trois champs à la main.

Côté fournisseur d'identité, déclarez FoxPlan avec les valeurs affichées dans l'écran et par Vérifier la configuration :

Donnée	Valeur
Identifiant de FoxPlan (entity ID, Relying party identifier)	{origin}/saml2/service-provider-metadata/{registrationId}
URL de retour (ACS, binding HTTP-POST)	{origin}/login/saml2/sso/{registrationId}
Métadonnées de FoxPlan	La même URL que l'identifiant : elle sert le fichier de métadonnées, importable tel quel (AD FS : « Importer les données sur la partie de confiance publiées en ligne »)

{registrationId} vaut <identifiant de l'entreprise>-saml2.

Attributs. FoxPlan rattache l'utilisateur à son compte par son email. Il le cherche dans l'attribut indiqué en options avancées, puis dans les noms usuels — email, mail, l'URI d'AD FS http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, l'OID LDAP urn:oid:0.9.2342.19200300.100.1.3, l'UPN — et à défaut dans le NameID s'il a la forme d'une adresse. Prénom et nom suivent la même logique (givenName, surname, URI d'AD FS). Sans email, la connexion est refusée.

Avec AD FS, ajoutez à la partie de confiance une règle d'émission « Envoyer les attributs LDAP en tant que revendications » : E-Mail-Addresses → E-Mail Address, Given-Name → Given Name, Surname → Surname.

Binding. La requête d'authentification part en HTTP-Redirect par défaut ; HTTP-POST reste proposé. La réponse du fournisseur revient toujours en HTTP-POST.

Non pris en charge : la signature des requêtes d'authentification, le chiffrement des assertions et la déconnexion SAML (Single Logout). Côté AD FS, ne déclarez pas de certificat de chiffrement sur la partie de confiance et n'exigez pas de requêtes signées.

Installation on-premise

Le serveur FoxPlan télécharge lui-même les métadonnées du fournisseur. Si elles sont servies par un AD FS interne dont le certificat est signé par la PKI de l'entreprise, déposez le certificat de cette autorité dans ca-sortant/ — voir Certificats entrants et sortants.

Provisioning des utilisateurs et groupes AD

Le provisioning laisse votre annuaire (Active Directory, Entra ID, Okta, Keycloak…) piloter FoxPlan. Il fonctionne en OIDC comme en SAML 2.0, donc avec AD FS.

• Création des comptes à la première connexion. Un utilisateur inconnu de FoxPlan, membre d'au moins un groupe AD associé à un groupe FoxPlan, reçoit un compte dès sa première connexion SSO, sans invitation. Il entre dans l'espace de travail de ce groupe en Membre de l'espace de travail : sans droit ni licence. C'est l'administrateur qui lui donne ensuite un rôle.
• Groupes synchronisés à chaque connexion. Les groupes FoxPlan associés suivent les groupes AD de l'utilisateur : il les rejoint ou les quitte à chaque connexion. Ces groupes configurent son interface — menus, fonctions, favoris partagés, modèles de projet.

Groupes et rôles restent séparés : le provisioning ne modifie jamais un rôle. Un utilisateur qui n'appartient à aucun groupe associé est refusé, comme sans provisioning. Un utilisateur supprimé dans FoxPlan n'est pas recréé par le SSO.

Activer le provisioning — dans la configuration SSO, panneau Provisioning des utilisateurs :

• cochez Créer les comptes et synchroniser les groupes à la connexion ;
• Attribut des groupes : laissez vide pour reconnaître les noms usuels (groups, memberOf, revendications Group et Role d'AD FS), ou indiquez l'attribut (SAML) ou le claim (OIDC) utilisé par votre fournisseur.

Associer les groupes — dans l'onglet Accès utilisateurs → Groupes de l'espace de travail, éditez un groupe et renseignez Groupes AD associés, un par ligne. Un groupe AD se désigne par son nom (Finance, CONTOSO\Finance) ou par son identifiant (GUID d'Entra). La comparaison ignore la casse, le préfixe de domaine, et ne garde que le CN d'un DN LDAP. Les groupes par défaut ne s'associent pas : leurs membres découlent des rôles.

Un compte provisionné est aussi membre du groupe par défaut All users. Ses menus et fonctions sont l'intersection de All users et de ses groupes synchronisés : un groupe AD ne peut que restreindre, jamais élargir. Configurez All users largement, et resserrez dans les groupes associés à l'AD.

Dans la liste des membres, un badge AD signale ceux qui ne sont là que par la synchronisation. Ils suivent l'AD, pas l'écran. Un membre ajouté à la main n'est jamais retiré par la synchronisation.

Côté fournisseur d'identité, transmettez les groupes de l'utilisateur :

Fournisseur	Réglage
AD FS	Règle d'émission « Envoyer l'appartenance à un groupe en tant que revendication », ou « Envoyer les attributs LDAP en tant que revendications » : Token-Groups – Unqualified Names → Group
Entra ID	Token configuration → Add groups claim. Entra envoie l'identifiant (GUID) des groupes, et au-delà de 200 groupes n'envoie plus la liste : limitez l'émission aux groupes assignés à l'application
Okta	Groups claim filtré sur les groupes utiles
Keycloak	Mapper Group list (SAML) ou Group Membership (OIDC)

Départs

Avec le seul provisioning à la connexion, un départ de l'AD n'est pris en compte qu'à la prochaine connexion de l'utilisateur. SCIM, ci-dessous, l'applique immédiatement. À défaut, supprimez l'utilisateur dans FoxPlan.

Avec AD FS, décochez aussi Mot de passe dans les méthodes de connexion : un compte désactivé dans l'AD ne peut alors plus entrer du tout, au plus tard à l'expiration de sa session FoxPlan (24 h).

Provisioning automatique par SCIM (Entra ID, Okta)

Avec Entra ID ou Okta, l'annuaire peut aussi pousser lui-même utilisateurs et groupes vers FoxPlan, sans attendre leur connexion : c'est le protocole SCIM 2.0. Les règles restent celles du provisioning à la connexion — compte créé en Membre de l'espace de travail pour les seuls membres d'un groupe associé, rôles jamais modifiés. SCIM y ajoute les départs immédiats : un utilisateur désactivé, ou retiré de l'application dans l'annuaire, perd aussitôt son accès.

1. Dans Paramètres → Entreprise → Provisioning (SCIM), cliquez sur Générer un jeton et copiez-le : il ne sera plus jamais affiché, FoxPlan n'en garde que l'empreinte.
2. Dans l'annuaire :
   • Entra ID : Applications d'entreprise → votre application FoxPlan → Provisioning, mode Automatique. Tenant URL : l'URL affichée par FoxPlan (https://<votre-domaine>/scim/v2) ; Secret Token : le jeton. Tester la connexion, attribuez les utilisateurs et groupes à l'application, puis démarrez le provisioning.
   • Okta : l'application → Provisioning → SCIM. SCIM connector base URL : l'URL ; Unique identifier field : userName ; actions Push New Users, Push Profile Updates et Push Groups ; authentification HTTP Header avec le jeton.
3. Associez les groupes FoxPlan aux groupes poussés, par leur nom ou leur identifiant, comme décrit plus haut.

Dans l'annuaire	Dans FoxPlan
Utilisateur attribué à l'application	En attente ; compte créé dès qu'il appartient à un groupe associé
Ajouté à un groupe, ou retiré	Rejoint ou quitte les groupes FoxPlan associés
Désactivé, ou retiré de l'application	Compte désactivé aussitôt : plus de connexion, retiré des espaces
Réactivé	Compte restauré

L'onglet garde le journal des appels pendant 90 jours. Un utilisateur poussé dont l'email correspond à un compte FoxPlan existant y est rattaché : le désactiver dans l'annuaire désactive aussi ce compte. Régénérer ou révoquer le jeton coupe immédiatement le provisioning, sans toucher aux comptes déjà créés.

Installation on-premise

Ici, c'est l'annuaire qui appelle FoxPlan, sur le port 443 et le chemin /scim/v2. Entra ID et Okta sont des services en ligne : l'URL doit être joignable depuis Internet, sauf à passer par leur agent de provisioning installé sur votre réseau.

Authentification du client : secret ou certificat

L'échange du code d'autorisation contre un jeton est le seul appel que FoxPlan adresse directement au fournisseur d'identité, de serveur à serveur. FoxPlan doit s'y identifier, et le champ Authentification du client offre deux manières de le faire.

Secret client (par défaut). Un secret partagé, saisi des deux côtés. C'est le mode historique, et rien ne change pour les configurations existantes : sans choix explicite, elles restent sur ce mode.

Certificat (clé privée). FoxPlan signe une assertion JWT avec une clé privée, et le fournisseur la vérifie avec le certificat public que vous y avez déclaré (private_key_jwt, RFC 7523). Le secret ne circule alors jamais sur le réseau — c'est pourquoi beaucoup de directions informatiques interdisent aujourd'hui les secrets clients.

Deux champs apparaissent alors :

• Certificat client : le certificat X.509 au format PEM. C'est la moitié publique, à téléverser également chez votre fournisseur d'identité (dans Entra ID : Certificates & secrets → Certificates).
• Clé privée : au format PKCS#8 non chiffré, celui qui commence par -----BEGIN PRIVATE KEY-----. Une clé PKCS#1 (BEGIN RSA PRIVATE KEY) ou protégée par mot de passe est refusée avec la commande de conversion à appliquer.

Pour produire une paire :

openssl req -x509 -newkey rsa:2048 -keyout cle.pem -out certificat.pem -days 730 -nodes -subj "/CN=foxplan-sso"
openssl pkcs8 -topk8 -nocrypt -in cle.pem -out cle-pkcs8.pem

Vous déclarez certificat.pem chez le fournisseur et collez cle-pkcs8.pem dans FoxPlan.

La clé privée est chiffrée en base, n'est jamais renvoyée par l'API et n'est jamais réaffichée à l'écran : en modification, laisser le champ vide conserve la clé enregistrée. Le certificat, lui, est public et reste visible.

Un certificat expire

Contrairement à un secret, un certificat porte une date de fin. Passée cette date, le SSO s'arrête net.

L'échéance est donc affichée en permanence : la liste des configurations porte une colonne Authentification qui indique, pour chaque SSO, s'il s'authentifie par secret ou par certificat — et dans ce dernier cas la date d'expiration, en orange dans le mois qui la précède, en rouge une fois passée. Cette date n'est jamais saisie : elle est lue dans le certificat lui-même à chaque affichage, seule source qui ne puisse pas diverger de la réalité. Vérifier la configuration en donne le détail complet, empreinte comprise.

Configuration par fournisseur

Google — Issuer URI : https://accounts.google.com

Microsoft / Azure — Issuer : https://login.microsoftonline.com/{tenantId}/v2.0

Okta — Type Web app avec assignation et politiques d'accès appropriées

Keycloak — Issuer URI du realm, flow Authorization Code configuré

Être prévenu avant l'expiration

L'affichage suppose que quelqu'un aille regarder. FoxPlan prévient donc de lui-même : un courriel part vers les administrateurs de l'entreprise à trois échéances — trente jours, sept jours, puis le jour où le certificat a expiré. Le message nomme le fournisseur concerné, donne la date, et renvoie vers l'écran de configuration.

Chaque palier n'est annoncé qu'une fois : le balayage retient ce qu'il a déjà envoyé. Dès que le certificat est renouvelé — l'échéance repassant au-delà de trente jours — le compteur se réarme tout seul pour le certificat suivant. Aucune action n'est nécessaire.

Si aucun administrateur d'entreprise n'est déclaré, aucun courriel ne part : c'est une raison de plus de tenir cette liste à jour dans les membres de l'entreprise.

Quand la connexion échoue

Un utilisateur dont la connexion SSO échoue revient sur l'écran de connexion avec une phrase qui nomme la cause, et non un code renvoyé par le fournisseur d'identité :

Ce que voit l'utilisateur	Ce qu'il faut faire
Le certificat de connexion a expiré	Renouveler le certificat et le redéposer des deux côtés
Le certificat est inutilisable	Vérifier que la clé privée déposée est bien celle du certificat
Le fournisseur a refusé les identifiants de FoxPlan	Le secret a été changé côté fournisseur, ou le certificat n'y est pas déclaré
Aucune connexion SSO active	La configuration est désactivée ou absente
Le fournisseur a refusé l'accès	Le compte n'est pas autorisé sur l'application côté fournisseur

Le détail technique — message exact du fournisseur, trace complète — reste dans les journaux du serveur, à l'usage du support. L'utilisateur, lui, reçoit une phrase qui lui dit à qui s'adresser.

Vérifier la configuration avant de tester

Chaque configuration de la liste porte un bouton Vérifier la configuration. Il ouvre un rapport qui ne quitte pas l'écran et ne tente aucune connexion :

• les URL à déclarer chez le fournisseur d'identité, avec un bouton copier : l'URL de redirection et l'URL de lancement de la connexion. Ce sont exactement celles que l'application utilisera, inutile de les reconstituer à la main ;
• les contrôles de cohérence : champs obligatoires renseignés, document de découverte lu depuis le serveur, émetteur et points d'accès conformes à ce que publie le fournisseur. En authentification par certificat, le rapport vérifie en plus que la clé privée correspond bien au certificat, affiche l'empreinte SHA-1 — celle que montre la console du fournisseur — et signale un certificat expiré ou proche de l'être.

Trois niveaux : vert quand c'est conforme, orange pour un point à regarder, rouge pour ce qui empêchera la connexion. Le détail affiché à droite de chaque ligne est la donnée brute — URL, statut HTTP, message du fournisseur — celle qu'on recopie au support.

Un contrôle peut être signalé « URL non sondée » : le serveur n'appelle que des adresses publiques en https, la configuration n'est pas en cause.

Ce rapport est en lecture seule : il ne modifie jamais la configuration.

Dépannage

Commencez par Vérifier la configuration : la majorité des échecs de premier paramétrage y apparaissent directement. Vérifiez ensuite ces éléments :

• L'URL de redirection correspond exactement entre IdP et FoxPlan
• La configuration SSO est bien activée
• L'email de l'utilisateur appartient à la bonne entreprise
• Pour Okta/Azure/Keycloak, vérifiez l'assignation et la conformité aux policies
• Pour les utilisateurs Password+MFA, vérifiez l'enrôlement (secret TOTP ou email valide)
• En authentification par certificat, comparez l'empreinte SHA-1 du rapport de vérification avec celle affichée chez le fournisseur : un certificat téléversé puis remplacé sans être redéposé dans FoxPlan est la cause la plus fréquente de rejet de la signature (AADSTS700027 côté Microsoft)