Dolibarr : comment réussir SSO orienté performance

Le Single Sign‑On (SSO) est devenu la porte d’entrée incontournable des applications d’entreprise. Dans le cadre de Dolibarr, le challenge est de combiner simplicité d’accès et performance optimale, surtout lorsqu’on gère des milliers d’utilisateurs ou des environnements à forte charge.

1. Pourquoi le SSO dans Dolibarr ?

Avantage Impact sur la performance
Réduction du nombre de login/logout Moins de requêtes HTTP, moins de charge sur la base de données.
Gestion centralisée des droits Une seule authentification → moins de frais de validation côté serveur.
Synchronisation LDAP/AD Accès instantané aux changements d’organigramme sans re‑déployer Dolibarr.
Facilité d’intégration avec SSO Possibilité d’utiliser des caches partagés (Redis, Memcached).

2. Architecture recommandée d’un SSO performant

[ Navigateur ] → HTTPS → [ Reverse Proxy (NGINX/Traefik) ] → 

                → [ Auth Service (Keycloak / Auth0 / Azure AD) ] → 

                → [ Dolibarr (via OIDC/LDAP) ]

  1. Reverse Proxy : Termine le TLS, gère le cache de session et la ré‑écriture d’URL. 2. Auth Service : Fournit le token JWT ou session opaque.

  2. Dolibarr : Vérifie le token (OAuth2‑Login) ou interroge le serveur LDAP. > Astuce performance : Placez NGINX en front‑office avec proxy_cache_valid pour mettre en cache les réponses statiques (CSS, JS) et même les pages de connexion lorsqu’elles sont peu dynamiques.

3. Choix du protocole SSO

Protocole Points forts Points faibles (performance)
OAuth2 / OpenID Connect (OIDC) Tokens légers, introspection, support natif dans Keycloak. Nécessite la validation du JWT à chaque requête.
SAML 2.0 Très mature, bonne intégration avec les ADFS. XML lourd → surcharge réseau et CPU.
LDAP/AD Direct Authentification ultra‑rapide si le serveur est local. Pas de SSO global – chaque appel démarre une nouvelle requête.
Kerberos Single sign‑on au niveau du réseau (Windows). Complexité d’installation et de monitoring.

Recommandation : OIDC avec Keycloak (ou Auth0) : token JWT signé, petite charge, possible mise en cache côté reverse‑proxy.

4. Étapes détaillées pour mettre en place le SSO “orienté performance”

4.1. Préparer l’infrastructure de base

Action Commande / Exemple
Installer NGINX apt-get install nginx
Configurer le cache de session nginx<br> location / {<br> proxy_cache_key $scheme$request_method$host$request_uri;<br> proxy_cache_valid 200 5m;<br> add_header Cache-Control no-store;<br> }<br>
Activer HTTP/2 & TLS 1.3 ssl_protocols TLSv1.3;
Déployer Redis (ou Memcached) apt-get install redis-server – utilisé pour stocker les sessions partagées entre plusieurs instances Dolibarr.

4.2. Configurer le service d’authentification (Keycloak) 1. Créer un realm dolibarr.

  1. Définir un client dolibarr-app :

    • Access Type → openid-connect

    • Valid Redirect URIs → https://dolibarr.example.com/*

    • Web Origins → https://dolibarr.example.com

  2. Activer le “Offline Access” pour les refresh tokens.

  3. Définir les mappages d’attributs : email, preferred_username, groups. 5. Activer le “Fine‑Grained” (option “Authorization”) → vous pourrez contrôler les droits directement depuis le client, évitant des appels LDAP supplémentaires.

4.3. Intégrer Dolibarr au flux OIDC

Dolibarr ne possède pas nativement un module OIDC, mais on peut le faire fonctionner via le plugin “Single Sign On” (disponible depuis Dolibarr 18+).

Étape Détail
Installer le plugin Copiez le répertoire sso du dépôt officiel dans htdocs/custom/.
Configurer le sso.conf php<br>$sso_conf['provider'] = 'keycloak';<br>$sso_conf['client_id'] = 'dolibarr-app';<br>$sso_conf['realm'] = 'dolibarr';<br>$sso_conf['oauth_authorization_endpoint'] = 'https://keycloak.example.com/realms/dolibarr/protocol/openid-connect/auth';<br>$sso_conf['oauth_token_endpoint'] = 'https://keycloak.example.com/realms/dolibarr/protocol/openid-connect/token';<br>$sso_conf['oauth_userinfo_endpoint'] = 'https://keycloak.example.com/realms/dolibarr/protocol/openid-connect/userinfo';<br>
Mapper les groupes Dans Dolibarr Setup → Authentication → SSO → Groups Mapping → associez les groupes Keycloak aux droits Dolibarr (ex. facture, projet).
Désactiver login/password Supprimez ou commentez dans conf.php le paramètre FORCE_AUTHENTIFICATION=0.

Optimisation du plugin

Astuce Explication
Cache du token Ajoutez dans sso.inc.php : session_set_cache_limiter('private'); + ini_set('session.cache_expire_time', 3600);. Cela évite de refaire le token tant que la session est valide.
Réduire les validations SAML Si vous utilisez Keycloak en mode public (pas de client secret) le nombre d’appels HTTPS diminue.
Utiliser le mode “Redirect” (auto‑redirect) → évite les requêtes supplémentaires de refresh token côté serveur.

4.4. Synchronisation LDAP / AD avec le microservice d’identité

  • Configurer Keycloak pour import LDAP via le Realm‑level User Federation.

  • Planifier un job de synchronisation (cron toutes les heures) pour éviter des recherches LDAP à chaque authentification.

  • Filtrer les groupes : ne synchronisez que les groupes réellement utilisés par Dolibarr (dolibarr_facture, dolibarr_projets).

Performance : Une fois importée, la cache interne de Keycloak garde les utilisateurs en mémoire, ce qui rend chaque validation O(1).

4.5. Scaling & haut‑disponibilité | Technique | Impact sur la performance |

|———–|—————————|
| Cluster NGINX (Active/Passive) | Répartition de la charge, pas de perte de session grâce au cache partagé Redis. |
| Dolibarr hors‑boîte (Docker) | Chaque conteneur possède son propre cache de session, mais le partage Redis garantit la cohérence. |
| Auto‑scaling (K8s HPA) | Ajoute des pods lorsqu’CPU > 70% → garde le temps de réponse sous 200 ms. |
| Database read‑replica | Charge des requêtes de validation de groupe sur les replicas, pas sur le master. |

5. Tests de charge : mesurer les gains

Outil Métrique clé Référence
k6 RPS (requêtes par seconde), latence 95ᵉ percentile bash<br>k6 run -e USERS=200 -e DURATION=30m script.js<br>
Siege Temps de réponse moyen, erreurs 5xx siege -c 500 -t 10M https://dolibarr.example.com/
JMeter Nombre de sessions concurrentes soutenues Configurer HTTP Request Defaults → Authentication → OAuth2 Token (include token in header).

Résultat attendu : Après mise en place du cache et du SSO OIDC, on observe généralement :

Avant Après
Latence moyenne 1 200 ms, RPS 45 Latence moyenne 210 ms, RPS 280
15 % d’erreurs 5xx sous 200 concurrent users 0 % d’erreurs sous 1 000 concurrent users

6. Bonnes pratiques “Performance‑First”

  1. Minimiser les redirections : chaque 302 ajoute ~30 ms. Privilégiez les Redirect unique (client directement vers / après token). 2. Utiliser le mode “Stateless” : ne stockez jamais de sessions côté serveur, utilisez des tokens signés.

  2. Compresser les réponses : gzip on; dans NGINX.

  3. Désactiver les modules inutiles : mod_auth_openidc désactivé si vous avez déjà le plugin SSO. 5. Surveiller le TTL du cache : Un cache trop long peut servir des pages obsolètes ; réglage de 5 min est un bon compromis.

  4. Activer Cache-Control: private, max-age=300 sur les pages d’authentification pour éviter les requêtes redondantes.

7. Dépannage fréquent

Symptomeme Cause probable Solution
Pages d’erreur 401 après login client_secret manquant ou mal configuré. Ajoutez le secret côté client dans sso.conf.
Session expirée trop vite session.cache_expire_time réglé à 60 s. Augmentez à 3600 s ou désactivez le cache.
Token “invalid signature” Clock skew entre Keycloak et serveur (plus de 5 min). Synchronisez les horloges via chronyd ou NTP.
Utilisateurs LDAP non visibles Filtre d’import trop restrictif. Réduisez le filtre à (&(objectClass=person)(mail=*)).
Latence > 500 ms sous charge Cache Redis saturé. Scale‑out Redis (cluster) ou passez à une instance plus grande.

8. Checklist de déploiement “SSO Performant”

✅ Action
1 Reverse proxy configuré avec cache et TLS 1.3.
2 Keycloak (ou autre IdP) installé, realm et client créés.
3 Plugin SSO installé dans Dolibarr, mapping des groupes appliqué.
4 Synchronisation LDAP planifiée (cronHourly).
5 Sessions partagées via Redis, TTL réglé à 1 h.
6 Tests de charge réalisés, seuils de latence définis.
7 Monitoring (Prometheus + Grafana) configuré pour suivre sso_token_requests, nginx_cache_hits.
8 Documentation interne mise à jour (procédures de rollback).

9. Conclusion

Le SSO orienté performance dans Dolibarr repose sur trois piliers :

  1. Une couche d’authentification légère (OIDC) et un cache partagé.

  2. Une synchronisation asynchrone des groupes LDAP pour éviter des requêtes répétées.

  3. Une architecture micro‑services (NGINX → SSO → Dolibarr) qui répartit la charge et minimise les temps de réponse.

En suivant ce cadre, vous obtenez une authentification quasi‑instantanée même sous plusieurs centaines d’utilisateurs simultanés, sans sacrifier la sécurité ni la maintenabilité.

💡 Pro tip : Re‑exécutez les tests de charge chaque trimestre lorsqu’un nouveau lot de données (ex. nouveaux partenaires) est importé ; ainsi vous gardez la performance sous contrôle tout au long du cycle de vie de votre instance Dolibarr.

Écrit par l’équipe performance & sécurité Dolibarr – 2025

Publications similaires