Open source SAML SSO Setup : configuration SAML pour une authentification centralisée sécurisée

Préparer l’open source SAML SSO setup : IdP, SP, métadonnées et certificats

Mettre en place un SSO SAML fiable commence par une préparation rigoureuse des rôles et des artefacts cryptographiques. Dans un schéma SAML, vous avez au minimum un IdP (Identity Provider) et un SP (Service Provider). L’objectif est simple: l’utilisateur s’authentifie une fois auprès de l’IdP, puis le SP accepte cette assertion SAML pour ouvrir une session. La difficulté, elle, se cache dans les détails: métadonnées, endpoints, formats d’identifiants, signatures, validation des certificats et cohérence des paramètres entre les deux côtés.

1) Identifier votre IdP et votre SP

• IdP: par exemple un annuaire fédéré ou une solution IAM open source auto-hébergée. Si vous partez d’un projet IAM moderne, vous pouvez vous appuyer sur une base solide pour gérer Kerberos, SAML et OIDC. Voir aussi: guide open source IAM auto hébergé pour SSO moderne (Kerberos, SAML, OIDC).
• SP: votre application (web, portail, API derrière un front web, ou SaaS interne). Le SP doit exposer un endpoint ACS (Assertion Consumer Service) et gérer la session.

2) Collecter et échanger les métadonnées

Les métadonnées SAML sont le document XML qui décrit:

• l’EntityID (identifiant unique du IdP ou du SP),
• les endpoints (SSO, SLO si utilisé, ACS),
• les certificats utilisés pour signer les assertions ou les réponses,
• parfois des informations de chiffrement (si vous activez l’option).

Concrètement, vous allez:

1. exporter les métadonnées côté IdP (souvent un fichier idp-metadata.xml),
2. les importer dans le SP,
3. exporter les métadonnées côté SP (souvent sp-metadata.xml),
4. les importer dans l’IdP.

3) Certificats et signatures: le point critique

En SAML, la sécurité repose sur la signature. Vous devez décider ce que vous signez et ce que vous vérifiez:

• Signature des assertions (courante),
• Signature des réponses (selon configuration),
• Validation côté SP avec le certificat public de l’IdP.

Exemple de checklist de préparation (à faire avant toute mise en production):

• les EntityID correspondent exactement (pas d’espace, pas de slash final inattendu),
• l’endpoint ACS du SP est bien déclaré dans les métadonnées,
• le certificat utilisé par l’IdP pour signer est présent côté SP,
• l’horloge système est synchronisée (NTP), car SAML inclut des contraintes temporelles (NotBefore/NotOnOrAfter).

4) Exemple de configuration “propre” (tableau)

Une fois ces fondations posées, la configuration SAML devient une question de mapping et de validation, pas de dépannage permanent.

Configurer la configuration SAML : mapping des attributs, NameID, ACS et validation

Après la préparation, la réussite dépend de la cohérence fonctionnelle entre IdP et SP. Un SAML “qui fonctionne” n’est pas seulement un SAML “qui répond”. Il doit produire une identité stable, des attributs correctement mappés, et une validation stricte des assertions.

1) NameID: choisir un identifiant stable

Le NameID (ou identifiant de sujet) est souvent la clé de votre logique applicative: il sert à retrouver l’utilisateur, à lier une session, et à éviter les doublons. Les IdP proposent généralement plusieurs formats:

• urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
• urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
• parfois des formats “transformation” selon l’implémentation.

Recommandation pratique: choisissez un attribut stable et unique dans votre organisation. Par exemple:

• un identifiant interne immuable (souvent employeeId ou uidNumber),
• ou un email si vous êtes certain qu’il ne change pas (ce qui est rarement vrai sur le long terme).

Exemple concret:

• Si votre IdP expose uid=jsmith et mail=jsmith@exemple.com, utilisez uid comme NameID pour éviter les problèmes lors d’un changement de domaine email.

2) Mapping des attributs: transformer pour l’application

Le SP attend souvent des attributs comme:

• email
• firstName
• lastName
• groups ou roles
• un identifiant applicatif (par exemple userId)

Le mapping se fait côté SP (ou parfois côté IdP). Vous devez vérifier:

• les noms exacts des attributs SAML,
• le format (string, tableau, multi-valeurs),
• la présence systématique des attributs.

Exemple de mapping courant:

• SAML attribute mail -> champ email
• givenName -> firstName
• sn -> lastName
• memberOf -> roles (avec normalisation)

3) ACS: endpoint, méthode et cohérence d’URL

L’ACS (Assertion Consumer Service) est l’URL que le IdP appelle pour déposer l’assertion. Les erreurs fréquentes viennent de:

• URL incorrecte (HTTP vs HTTPS),
• chemin différent entre environnement (staging vs prod),
• reverse proxy qui modifie le schéma ou le host.

Si votre SP est derrière un reverse proxy, assurez-vous que les en-têtes et la redirection sont cohérents. Pour approfondir la partie routage et sécurisation des endpoints d’authentification, vous pouvez consulter: Nginx et reverse proxy : sécuriser le routage des endpoints d’authentification.

4) Validation: signatures, audience, conditions temporelles

La validation SAML doit être stricte. Les contrôles typiques côté SP incluent:

• Signature valide (certificat de l’IdP),
• AudienceRestriction: l’assertion doit être destinée à votre SP (souvent via EntityID),
• Conditions temporelles: NotBefore et NotOnOrAfter,
• InResponseTo (si vous corrélez une requête AuthnRequest),
• réutilisation: éviter les assertions rejouées (selon implémentation).

Exemple de scénario de diagnostic (chiffré, mais sans inventer de chiffres): Si vous voyez des erreurs “Assertion expired” ou “NotOnOrAfter”, la cause la plus fréquente est un décalage d’horloge. Une vérification simple consiste à:

• comparer l’heure du serveur SP et celle du IdP,
• vérifier la synchronisation NTP,
• contrôler le fuseau horaire et la dérive.

5) Exemple de configuration “mapping + validation” (pseudo-checklist)

1. Définir NameID format attendu.
2. Mapper mail vers email.
3. Mapper givenName et sn.
4. Mapper memberOf vers roles (et normaliser les préfixes).
5. Activer la vérification de signature avec le certificat IdP.
6. Activer la vérification d’audience vers l’EntityID du SP.
7. Vérifier l’ACS URL exacte (schéma, host, chemin).

6) Tableau de correspondance IdP -> SP

Une fois ces éléments alignés, vous réduisez drastiquement les incidents “ça marche chez moi” et vous obtenez une authentification centralisée cohérente, auditable et maintenable.

Sécuriser et fiabiliser l’authentification centralisée : bonnes pratiques, rotation et diagnostic

Une fois le SAML setup fonctionnel, la phase suivante est la fiabilisation et la sécurité opérationnelle. En production, les problèmes ne viennent pas uniquement de la configuration initiale. Ils viennent de la dérive des certificats, des changements d’attributs, des évolutions d’infrastructure, et des erreurs de routage derrière des reverse proxies. L’objectif est de rendre votre SSO résilient, traçable et facile à diagnostiquer.

1) Bonnes pratiques de sécurité SAML (niveau production)

Voici des règles concrètes, applicables dans la plupart des stacks SAML modernes:

• Forcer HTTPS sur toutes les URLs (ACS, endpoints, redirections).
• Limiter les algorithmes: privilégier des signatures robustes et éviter les configurations “compatibilité” trop permissives.
• Valider strictement:
• signature,
• audience,
• conditions temporelles,
• cohérence de l’EntityID.
• Réduire la surface d’attaque:
• protéger l’endpoint ACS contre les accès non attendus,
• appliquer des règles de pare-feu ou de WAF si disponible,
• éviter d’exposer des informations sensibles dans les erreurs.

2) Rotation des certificats: planifier avant la panne

La rotation est l’un des sujets les plus critiques. Si le certificat de signature côté IdP change et que le SP ne trust pas le nouveau, vous obtenez des échecs d’authentification. Une stratégie robuste consiste à:

• prévoir une période de chevauchement (double trust),
• mettre à jour le trust store du SP avant l’activation côté IdP,
• documenter la date de rotation et les responsables.

Concrètement, vous pouvez gérer plusieurs certificats dans le SP:

• l’ancien certificat (encore valide),
• le nouveau certificat (ajouté en avance).

Exemple de procédure opérationnelle (à adapter):

1. J-30: ajouter le nouveau certificat dans le SP (trust store).
2. J-7: vérifier dans un environnement de test que la validation fonctionne.
3. J0: activer la signature côté IdP.
4. J+30: retirer l’ancien certificat après confirmation.

Même sans chiffres “universels”, cette approche de chevauchement est une pratique de sécurité largement adoptée car elle réduit le risque de coupure.

3) Diagnostic: logs, corrélation et scénarios de test

Pour fiabiliser, vous devez pouvoir répondre rapidement à:

• “Pourquoi l’assertion a été rejetée ?”
• “Quel certificat a été utilisé ?”
• “Quel attribut manque ?”
• “L’ACS a-t-elle été appelée avec le bon host et le bon schéma ?”

Mettez en place une stratégie de logs structurés:

• loggez l’issue de validation (signature OK ou KO),
• loggez l’audience attendue et reçue (sans exposer de données sensibles),
• loggez les erreurs temporelles (NotBefore/NotOnOrAfter),
• loggez l’EntityID du IdP utilisé.

4) Erreurs de sécurité fréquentes à éviter

Pour éviter les pièges classiques, consultez aussi: les erreurs de sécurité fréquentes à éviter lors de la mise en place d’un SSO.

Voici une liste orientée “incidents réels” (sans inventer de statistiques):

• Désactiver la vérification de signature pour “tester”. C’est une faille majeure.
• Accepter des assertions non signées ou avec validation partielle.
• Ne pas vérifier l’audience: vous risquez d’accepter des assertions destinées à un autre SP.
• Ignorer les contraintes temporelles: augmente le risque de replay.
• Mauvaise gestion des attributs: par exemple, mapper roles à partir d’un attribut non garanti, ce qui peut conduire à des autorisations incorrectes.

5) Exemple de matrice de contrôle (sécurité et fiabilité)

6) Checklist de mise en production (pratique)

Avant de déclarer votre SSO prêt:

1. Tester un login complet en staging et en prod.
2. Tester un compte sans certains attributs (que se passe-t-il ?).
3. Vérifier la rotation en mode “dry run” (ajout du nouveau certificat sans activation).
4. Vérifier la résilience reverse proxy (host, schéma, headers).
5. Mettre en place une alerte sur les échecs d’authentification SAML (taux d’erreurs, logs).

En appliquant ces principes, vous transformez un “setup qui marche” en une authentification centralisée sécurisée, maintenable et diagnostiquable. C’est précisément ce qui fait la différence entre un projet expérimental et une brique d’infrastructure de confiance, adaptée aux exigences des environnements SaaS, des plateformes internes et des architectures modernes.