SAML 2.0 : la fédération enterprise

SAML 2.0 reste le protocole de fédération dominant en entreprise. Même si OIDC est plus moderne, la majorité des applications SaaS enterprise (Salesforce, ServiceNow, Workday…) supportent SAML en premier. Si vous intégrez des applications d’entreprise, vous rencontrerez SAML. Ce guide vous donne les clés pour le comprendre, le configurer et le déboguer.

Ce que vous allez apprendre

Ce guide vous explique SAML 2.0 — le protocole de fédération dominant dans les grandes entreprises. À la fin, vous saurez :

• Comprendre pourquoi SAML reste omniprésent malgré OIDC
• Distinguer les flux SP-initiated et IdP-initiated
• Configurer les assertions, signatures et mapping d’attributs
• Diagnostiquer les erreurs SAML les plus courantes

Prérequis : avoir lu OpenID Connect.

Pourquoi SAML existe encore

SAML 2.0 date de 2005. Pourquoi est-il encore partout ?

Réponse courte : parce que les grandes applications enterprise (Salesforce, ServiceNow, Workday, SAP…) le supportent depuis des années, et qu’il fonctionne.

SAML vs OIDC : pas un remplacement

OIDC ne “remplace” pas SAML. Les deux coexistent :

• OIDC : nouvelles applications, mobile, SPAs, APIs
• SAML : applications enterprise existantes, intégrations B2B

Quand utiliser SAML

Situation	Protocole recommandé
L’application ne supporte que SAML	SAML
Intégration B2B avec un partenaire SAML	SAML
Nouvelle application web/mobile	OIDC
API à sécuriser	OAuth 2.0

Glissez pour voir

SAML vs OIDC : différences clés

Comprendre ces différences vous aide à choisir le bon protocole selon votre contexte. SAML reste incontournable en entreprise, tandis qu’OIDC domine les architectures modernes.

Aspect	SAML	OIDC
Année	2005	2014
Format	XML	JSON/JWT
Taille des messages	Verbeux (~5-15 KB)	Compact (~1-2 KB)
Signature	XML-DSig + certificats	JWS (signature JWT)
Chiffrement	XML-Enc (optionnel)	JWE (optionnel)
Configuration	Échange de fichiers metadata	Discovery endpoint
Mobile/SPA	Difficile	Natif
Enterprise legacy	Excellent support	Variable
Debugging	Complexe (XML, signatures)	Simple (jwt.io, JSON)

Glissez pour voir

Les acteurs SAML

Trois acteurs interviennent dans chaque échange SAML. Connaître leur rôle est essentiel pour déboguer les problèmes de fédération.

Acteur	Rôle	Équivalent OIDC
Identity Provider (IdP)	Authentifie l’utilisateur, émet les assertions	OpenID Provider
Service Provider (SP)	Application qui consomme les assertions	Relying Party
Principal	L’utilisateur qui s’authentifie	—

Glissez pour voir

Les deux modes SSO

SP-initiated (recommandé)

L’utilisateur commence par l’application (Service Provider).

1. Accès à l’application

   L’utilisateur tente d’accéder à https://salesforce.example.com

2. Génération de l’AuthnRequest

   Le SP génère une demande d’authentification SAML (AuthnRequest).

3. Redirection vers l’IdP

   Le navigateur est redirigé vers l’IdP avec l’AuthnRequest.

4. Authentification

   L’IdP authentifie l’utilisateur (login, MFA…).

5. Génération de l’assertion

   L’IdP crée une assertion SAML signée contenant l’identité.

6. Retour au SP (POST)

   Le navigateur envoie l’assertion au SP (généralement via HTTP-POST).

7. Validation et session

   Le SP valide la signature et crée une session pour l’utilisateur.

Avantages :

• L’application contrôle le flux
• Protection CSRF native (le SP génère un ID de requête)

IdP-initiated

L’utilisateur commence par le portail IdP.

1. Accès au portail IdP

   L’utilisateur accède au portail enterprise (ex: Okta dashboard).

2. Clic sur l’application

   L’utilisateur clique sur l’icône de l’application.

3. Génération directe de l’assertion

   L’IdP génère une assertion SAML sans AuthnRequest préalable.

4. Envoi au SP

   L’assertion est envoyée directement au SP.

5. Validation et session

   Le SP valide et crée la session.

Risques :

• Pas d’AuthnRequest = pas de InResponseTo à valider
• Risque de CSRF si le RelayState n’est pas vérifié

Préférez SP-initiated

Quand c’est possible, utilisez SP-initiated. IdP-initiated est pratique pour les portails enterprise mais offre moins de protections.

L’assertion SAML

Une assertion SAML est un document XML signé qui contient :

• L’identité de l’utilisateur (NameID)
• Les attributs (email, groupes, rôles…)
• Les conditions de validité (dates, audience)
• La signature de l’IdP

Structure simplifiée

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                ID="_abc123" IssueInstant="2024-02-06T10:00:00Z">

  <!-- Qui a émis l'assertion -->
  <saml:Issuer>https://idp.example.com</saml:Issuer>

  <!-- Signature XML -->
  <ds:Signature>...</ds:Signature>

  <!-- Subject : l'utilisateur authentifié -->
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      alice@example.com
    </saml:NameID>
  </saml:Subject>

  <!-- Conditions de validité -->
  <saml:Conditions NotBefore="2024-02-06T10:00:00Z"
                   NotOnOrAfter="2024-02-06T10:05:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://salesforce.example.com</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>

  <!-- Contexte d'authentification -->
  <saml:AuthnStatement AuthnInstant="2024-02-06T10:00:00Z">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
      </saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>

  <!-- Attributs -->
  <saml:AttributeStatement>
    <saml:Attribute Name="email">
      <saml:AttributeValue>alice@example.com</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="groups">
      <saml:AttributeValue>developers</saml:AttributeValue>
      <saml:AttributeValue>admins</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>

</saml:Assertion>

Éléments clés

Élément	Description
Issuer	URL de l’IdP qui a émis l’assertion
NameID	Identifiant principal de l’utilisateur
Conditions	Période de validité, audience autorisée
AuthnStatement	Preuve de l’authentification
AttributeStatement	Attributs additionnels (email, groupes…)
Signature	Signature XML de l’IdP

Glissez pour voir

Signatures et certificats

SAML utilise XML-DSig pour signer les assertions (et optionnellement les chiffrer).

Ce qui est signé

Élément	Signé par
Assertion	L’IdP (obligatoire)
Response	L’IdP (recommandé)
AuthnRequest	Le SP (optionnel)

Glissez pour voir

Gestion des certificats

Certificats qui expirent

Les certificats SAML ont une date d’expiration. Planifiez la rotation :

1. Ajoutez le nouveau certificat dans les metadata
2. Attendez que tous les SP l’aient importé
3. Basculez la signature sur le nouveau certificat
4. Retirez l’ancien certificat

Vérification côté SP

Le SP doit :

1. Obtenir le certificat public de l’IdP (via metadata ou import manuel)
2. Valider la signature de l’assertion
3. Valider la chaîne de certificats (optionnel selon la config)

Metadata : l’échange de configuration

Les fichiers metadata contiennent la configuration SAML d’un IdP ou d’un SP.

Metadata IdP

<EntityDescriptor entityID="https://idp.example.com">
  <IDPSSODescriptor>
    <KeyDescriptor use="signing">
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>MIIC...</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>
    <SingleSignOnService
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
      Location="https://idp.example.com/sso"/>
  </IDPSSODescriptor>
</EntityDescriptor>

Metadata SP

<EntityDescriptor entityID="https://salesforce.example.com">
  <SPSSODescriptor>
    <KeyDescriptor use="signing">
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>MIID...</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>
    <AssertionConsumerService
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://salesforce.example.com/saml/acs"
      index="0"/>
  </SPSSODescriptor>
</EntityDescriptor>

Échange de metadata

1. Exporter le metadata de l’IdP

2. Importer dans le SP (ou donner l’URL du metadata)

3. Exporter le metadata du SP

4. Importer dans l’IdP (créer un “realm” ou “application”)

5. Configurer le mapping d’attributs

Mapping d’attributs

Les attributs SAML ne sont pas standardisés. Chaque vendor utilise ses propres noms.

NameID : l’identifiant principal

Format	Valeur	Usage
emailAddress	alice@example.com	Le plus courant
persistent	ID opaque stable	Recommandé pour la sécurité
transient	ID temporaire	Sessions anonymes
unspecified	Quelconque	À éviter

Glissez pour voir

Mapping des attributs courants

Ce que le SP attend	Ce que l’IdP a	Solution
User.Email	email	Mapper email → User.Email
memberOf	groups	Mapper groups → memberOf
firstName	givenName	Mapper givenName → firstName

Glissez pour voir

Configuration Keycloak

Dans Keycloak, les “mappers” permettent de :

• Renommer des attributs
• Formater des valeurs (ex: préfixer les groupes)
• Filtrer les groupes à inclure

Dépannage SAML

Outils de diagnostic

Outil	Usage
SAML-tracer (extension navigateur)	Capturer les requêtes/réponses SAML
samltool.com	Décoder, valider, générer des assertions
Keycloak logs	Erreurs côté IdP
Logs applicatifs	Erreurs côté SP

Glissez pour voir

Erreurs courantes

Symptôme	Cause probable	Solution
Invalid signature	Certificat mal importé, mauvais certificat	Ré-importer le certificat de l’IdP
Assertion expired	Clock skew (décalage d’horloge)	Synchroniser NTP sur tous les serveurs
Invalid audience	Audience ne correspond pas à l’entityID du SP	Vérifier la config côté IdP
ACS URL mismatch	L’URL de retour ne correspond pas	Vérifier AssertionConsumerService dans les metadata
Missing attribute	Attribut non mappé	Configurer le mapper côté IdP
NameID format mismatch	Le SP attend un format différent	Aligner les formats NameID

Glissez pour voir

Checklist de dépannage

1. Capturer le trafic avec SAML-tracer

2. Décoder la Response sur samltool.com

3. Vérifier les timestamps (NotBefore, NotOnOrAfter)

4. Vérifier l’Audience

5. Valider la signature (certificat correct ?)

6. Vérifier les attributs présents dans l’assertion

Clock skew

SAML a une tolérance de quelques minutes sur les timestamps. Si vos serveurs ont un décalage d’horloge > 2-3 minutes, les assertions seront rejetées. Synchronisez NTP.

Sécurité SAML

Risques et mitigations

Risque	Mitigation
Signature bypass	Toujours valider la signature de l’assertion ET de la response
XML injection	Parser XML sécurisé, désactiver les entity references
Replay attack	Vérifier InResponseTo, tracker les assertion IDs consommées
IdP-initiated CSRF	Valider RelayState, préférer SP-initiated
Assertion interception	HTTPS obligatoire, chiffrement optionnel

Glissez pour voir

Bonnes pratiques

• Signez les assertions ET les responses
• Chiffrez les assertions si elles contiennent des données sensibles
• Validez l’audience (AudienceRestriction)
• Limitez la durée de validité des assertions (< 5 min)
• Utilisez SP-initiated quand possible

Erreurs fréquentes

Erreur	Conséquence	Solution
Certificat expiré non détecté	SSO cassé	Alerting sur les dates d’expiration
Pas de validation InResponseTo	Vulnérable au replay	Valider l’ID de la requête originale
Clock skew > 5 min	Assertions toujours rejetées	NTP sur tous les serveurs
Metadata pas à jour	Échecs intermittents	URL de metadata + refresh automatique

Glissez pour voir

À retenir

Les 7 points clés

1. SAML est le standard enterprise historique — utilisez-le pour les apps qui ne supportent pas OIDC
2. SP-initiated est plus sécurisé qu’IdP-initiated
3. L’assertion contient NameID, attributs, conditions et signature
4. Les metadata échangent la configuration entre IdP et SP
5. Le mapping d’attributs est souvent nécessaire (noms non standardisés)
6. Clock skew et certificats expirés sont les causes d’erreur #1
7. SAML-tracer + samltool.com pour le debugging

Références

• OASIS SAML 2.0 Technical Overview
• SAML 2.0 Core Specification
• SAML-tracer Extension
• samltool.com

Prochaines étapes

SCIM et provisioning Automatisez la création des comptes dans les applications.

MFA et WebAuthn Renforcez l'authentification SAML avec le MFA.

Déployer Keycloak Configurer SAML avec Keycloak comme IdP.

×

📖 Voir la documentation →