SAML et accès fédéré
Bonne lecture et bon apprentissage ! Junior TSAFACK – 09/10/2026 Temps de lecture estimé : 9 minutes
Comment un utilisateur peut-il accéder aux ressources d’une organisation partenaire sans jamais lui communiquer ses identifiants d’origine ? C’est exactement le problème que résout la gestion d’identité fédérée (FIM), dont SAML est le protocole historique de référence.
Les trois entités du modèle fédéré (FIM)
Section titled “Les trois entités du modèle fédéré (FIM)”| Entité | Rôle |
|---|---|
| Client / mandant | L’utilisateur final qui cherche à accéder à une ressource. |
| Fournisseur d’identité (IdP) | Authentifie l’utilisateur et émet des jetons de sécurité contenant ses informations. |
| Fournisseur de services (SP) / partie se fiant | Fournit la ressource demandée, en s’appuyant sur l’assertion d’authentification de l’IdP pour décider d’accorder l’accès. |
Exemple concret du déroulement : Sue possède un compte chez Any Bank, Inc. et clique sur « Login ». Sa banque envoie une demande de vérification à l’IdP. L’IdP présente un écran de connexion à Sue, qui fournit ses identifiants, vérifiés auprès de la base d’identité de l’IdP. L’IdP informe la banque que l’utilisateur est bien Sue, et la banque autorise la connexion — sans que la banque ait jamais eu à gérer elle-même le mot de passe de Sue.
SAML : structure et composants
Section titled “SAML : structure et composants”Le Security Assertion Markup Language (SAML) est une norme XML largement adoptée pour échanger des informations de sécurité entre domaines de confiance, en particulier entre un IdP et un SP. Il se décompose en quatre composants :
- Assertions — définissent comment attributs, authentification et messages de demande/réponse d’autorisation sont échangés.
- Liaisons — définissent comment ces échanges sont réalisés avec des paires requête/réponse.
- Protocoles — HTTP, SOAP, entre autres.
- Profils — règles spécifiques à un cas d’usage pour combiner attributs, liaisons et protocoles.
Dans le cas d’usage le plus courant (SSO vers une application web), l’utilisateur se connecte une fois à l’IdP. Après authentification réussie, l’IdP émet une assertion SAML contenant l’identité et le statut d’authentification de l’utilisateur. Le navigateur transmet cette assertion au fournisseur de services, qui fait confiance à l’IdP et utilise les informations de l’assertion — rôle, groupe, autres attributs — pour ses propres décisions de contrôle d’accès basées sur les attributs.
SAML face à OAuth 2.0 et OIDC
Section titled “SAML face à OAuth 2.0 et OIDC”Les trois protocoles collaborent mais répondent à des besoins distincts :
- SAML — norme XML pour l’échange d’authentification et d’autorisation entre IdP et SP, SSO cross-domaine.
- OAuth 2.0 — cadre d’autorisation pur, permettant à une application tierce d’accéder à des ressources au nom d’un utilisateur sans connaître ses identifiants.
- OIDC — couche d’authentification construite au-dessus d’OAuth 2.0 (voir chapitre précédent).
Un IdP de fédération d’identité s’appuie généralement sur l’un de ces trois protocoles standardisés pour communiquer avec les fournisseurs de services et échanger les informations d’authentification en toute sécurité — le choix dépend surtout de l’écosystème technique déjà en place (SAML reste dominant dans l’entreprise classique, OIDC dans le web et le mobile modernes).
Synthèse
Section titled “Synthèse”- La gestion d’identité fédérée (FIM) repose sur trois entités — client, IdP, fournisseur de services — qui se font mutuellement confiance sans jamais partager les identifiants bruts de l’utilisateur.
- SAML reste la norme XML de référence pour le SSO cross-domaine en entreprise, structurée en assertions, liaisons, protocoles et profils.
- SAML, OAuth 2.0 et OIDC ne sont pas concurrents mais complémentaires : autorisation (OAuth), authentification (OIDC) et échange d’assertions cross-domaine (SAML).
Prochain chapitre
Section titled “Prochain chapitre”Relations de confiance, zero trust et zones réseau
Junior TSAFACK – 09/10/2026