Un seul mécanisme à maîtriser : l’application ne vous demande pas un mot de passe, elle vérifie une assertion de confiance.
Fiche opérationnelle réutilisable pour contrôler une intégration SSO (SAML/OIDC) entre votre entreprise et une application tierce.
La fédération d’identité, c’est un contrôle central (IdP) qui remet un “laissez-passer” utilisable par une application partenaire (SP).
Le point critique n’est pas “SSO activé”. Le point critique est “l’assertion est-elle vérifiée correctement, à chaque connexion ?”.
Cette ressource suit un seul trajet. Un employé de votre entreprise se connecte à une application SaaS. Et vous vérifiez ce que le SaaS accepte, ce qu’il refuse, et ce que vous devez pouvoir prouver après coup.
Objectif : éviter la confiance implicite. Vous devez pouvoir expliquer, vérifier, puis retirer l’accès sans casser le reste.
##Ce que vous devez vérifier (avant d’appeler ça “de la confiance”)
- -L’application (SP) valide l’émetteur, la signature, le destinataire et la durée de l’assertion (NIST SP 800-63C https://pages.nist.gov/800-63-4/sp800-63c.html).
- -L’assertion est bien destinée à cette application (pas réutilisable ailleurs).
- -La durée de validité est courte et cohérente avec votre usage (session, MFA, accès admin).
- -Les autorisations dans l’application existent et ne sont pas “tout ouvert parce que SSO”.
- -Le retrait d’accès au départ d’un salarié coupe aussi l’accès au SaaS (pas seulement au compte interne).
- -Les logs existent côté IdP et côté application (et vous savez les relier).
- -Vous pouvez décrire le mécanisme sans citer un produit (pour repérer les zones floues).
##Suivre une connexion unique (de l’entreprise vers une appli SaaS)
##Checklist opérationnelle : contrôles + preuves à garder
Groupe 1 : A. Validation de l’émetteur (qui a “signé” l’accès ?)
- ->Valider l’émetteur : l’application n’accepte que l’IdP attendu (pas un autre IdP).
- ->Comparer l’identifiant d’émetteur à la config attendue (pas juste “ça marche”).
- ->Vérifier le certificat ou la clé de signature utilisée pour l’assertion.
- ->Preuve à garder : capture de la configuration IdP/SP (émetteur + clé/certificat).
Groupe 2 : B. Durée et contexte (une assertion ne doit pas vivre longtemps)
- ->Limiter la durée : l’assertion expire vite et l’application refuse une assertion trop ancienne.
- ->Contrôler le destinataire : l’assertion est liée à cette application (audience/destinataire).
- ->Décider une règle claire sur l’horloge : quoi faire si l’heure IdP et SaaS diffère (tolérance minimale).
- ->Preuve à garder : un exemple d’assertion (masquée) montrant durée + destinataire.
Groupe 3 : C. Déprovisionnement (le départ doit couper l’accès)
- ->Retirer l’accès lors du départ : la désactivation côté entreprise doit empêcher une nouvelle session SaaS.
- ->Vérifier le comportement des sessions existantes : expiration, révocation, ou durée maximale de session.
- ->Tester un cas réel : utilisateur désactivé → tentative de connexion → résultat attendu (refus).
- ->Preuve à garder : ticket/trace du test de départ + log IdP/SP correspondant.
Groupe 4 : D. Autorisations dans l’application (SSO n’est pas “autorisé”)
- ->Lister les rôles dans l’application et la règle d’attribution (groupes, claims, mapping).
- ->Vérifier le “par défaut” : que se passe-t-il si aucun rôle n’est mappé ?
- ->Confirmer qu’un rôle admin n’est pas attribué par erreur via un attribut trop large.
- ->Preuve à garder : export de la matrice rôles ↔ groupes/attributs (même en capture d’écran).
##Carte de contrôle (modes de panne + signaux utiles)
Vue rapide “où ça casse” et quoi chercher dans les logs et les configs IdP/SP.
- ├─Contrôle : MFA et politiques d’accès appliquées avant émission d’assertion (si requis).
- ├─Panne typique : MFA contournée via une exception, ou politique non appliquée à l’appli SaaS.
- └─Signal : logs IdP montrant méthode d’authentification et politique utilisée pour cette appli.
- ├─Contrôle : assertion signée, et uniquement pour le bon SP.
- ├─Panne typique : mauvais destinataire (audience) ou assertion réutilisable sur un autre service.
- └─Signal : exemple d’assertion (masquée) + métadonnées de fédération côté IdP/SP.
- ├─Contrôle : valider émetteur, signature, destinataire, durée (NIST SP 800-63C).
- ├─Référence : https://pages.nist.gov/800-63-4/sp800-63c.html
- └─Signal : logs SP avec cause de refus (signature, expiration, destinataire).
- ├─Contrôle : droits locaux appliqués et traçables (rôles, groupes, claims).
- ├─Panne typique : “SSO = accès partout”, ou rôle trop permissif par défaut.
- └─Signal : audit log de l’appli montrant rôle attribué + actions sensibles réalisées.
##Questions rapides (pour éviter les erreurs classiques)
Idée fausse : “SSO = accès partout”. Vrai ou faux ?
Faux. Le SSO gère l’authentification. Chaque application doit encore appliquer ses propres autorisations (rôles, droits, périmètres).
Qu’est-ce que l’application doit vérifier exactement sur l’assertion ?
Minimum : émetteur, signature, destinataire, durée. C’est attendu côté service (NIST SP 800-63C https://pages.nist.gov/800-63-4/sp800-63c.html).
Quelles sont les 3 actions “minimum vital” à faire valider ?
Valider l’émetteur. Limiter la durée. Retirer l’accès lors du départ. Si vous ne pouvez pas démontrer ces 3 points, la fédération est fragile.
Qu’est-ce que je dois être capable de montrer après un incident ?
Qui s’est connecté, via quel IdP, avec quelle politique (MFA ou non), quelle application a accepté l’assertion, et quels droits ont été accordés.
Test simple : comment savoir si l’intégration est comprise par l’équipe ?
Demandez : “Expliquez ce mécanisme sans citer le nom d’un produit.” Si l’explication reste claire (IdP, assertion, vérifs côté SP, droits locaux), c’est bon signe.