Attaques SAML 2026 : Golden SAML, XSW & Défense IdP

Les attaques SAML sont l'un des vecteurs d'account takeover les plus rentables pour les attaquants en 2026. Le protocole SAML 2.0, standardisé en 2005 par OASIS, reste la colonne vertébrale de l'authentification fédérée d'entreprise — il transporte assertions XML signées entre un Identity Provider (Microsoft ADFS, Entra ID, Okta, OneLogin, PingFederate, Keycloak) et des Service Providers (Salesforce, AWS, GitHub Enterprise, Atlassian, Workday, et des milliers de SaaS). Une attaque réussie sur la couche SAML donne un accès persistant et silencieux à des dizaines d'applications critiques — souvent indétectable côté SOC car les logs SP montrent une authentification SAML normale. Ce panorama 2026 couvre les trois familles d'attaques (Golden SAML, XSW, IdP compromis ou malveillant), les CVE 2026 majeures, les techniques d'investigation forensique, et les défenses concrètes pour ADFS, Entra ID, Okta, Keycloak.

1. Rappels — Comment fonctionne SAML 2.0

SAML 2.0 repose sur trois acteurs : (1) l'Identity Provider (IdP) qui authentifie l'utilisateur et émet une assertion signée, (2) le Service Provider (SP) qui consomme cette assertion et accorde l'accès, (3) l'utilisateur. Le flux SP-initiated typique : l'utilisateur arrive sur le SP, le SP redirige vers l'IdP avec une AuthnRequest, l'IdP authentifie, génère une Response XML contenant une Assertion signée (signature XML-DSig) avec attributs (NameID, email, groupes), redirige vers le SP via POST. Le SP valide la signature contre le certificat IdP référencé dans ses métadonnées SP metadata XML, vérifie NotBefore/NotOnOrAfter, valide l'Audience, puis ouvre la session. Le point critique : tout ce qui est dans l'Assertion signée est de facto autoritaire — un attaquant qui contrôle la signature contrôle l'identité.

2. Golden SAML — la forge complète d'assertion

L'attaque Golden SAML, publiée par CyberArk en novembre 2017 et popularisée par l'incident SolarStorm/Nobelium en décembre 2020, exploite la confiance IdP→SP de manière définitive. Mécanique : un attaquant qui a compromis l'IdP peut exporter la clé privée de signature SAML (généralement stockée dans ADFS DB pour Microsoft, ou en HSM/KeyVault chez les autres). Avec cette clé, il forge n'importe quelle assertion SAML pour n'importe quel utilisateur, signée légitimement, vers n'importe quel SP fédéré. L'assertion est indistinguable d'une assertion légitime — le SP la valide et accorde l'accès. C'est l'équivalent d'un golden ticket Kerberos mais à l'échelle fédération, et qui résout en plus le problème du MFA : l'attaquant peut écrire dans l'assertion AuthnContextClassRef = MultiFactorAuthentication sans avoir jamais réalisé le MFA.

3. Extraction de la clé ADFS — le scénario type

Le scénario d'extraction classique sur ADFS Microsoft : (1) l'attaquant obtient des droits Local Admin sur un serveur ADFS — typiquement via une chaîne kerberoasting + RBCD ; (2) il utilise ADFSDump (Mandiant), ADFSpoof ou AADInternals (Dr. Nestori Syynimaa) pour extraire les secrets ADFS : Token Signing Certificate avec sa clé privée DKM (Distributed Key Management), Encryption Certificate, configuration relying parties. La clé DKM est stockée chiffrée dans la base ADFS et déchiffrée à l'aide d'un secret stocké dans Active Directory (objet CN=ADFS,CN=Microsoft,CN=Program Data) ; (3) avec le certificat et la clé privée extraits, l'attaquant utilise des outils comme SAMLRaider (Burp), SAML Tracer, ou des scripts Python custom pour forger les assertions ; (4) il déclenche les flux SAML vers SP cibles (Microsoft 365 fédéré, Azure, AWS, Salesforce, Atlassian) et obtient des sessions valides. Détection : surveiller les accès à la base ADFS et aux objets DKM dans AD, alerter sur le service account ADFS s'exécutant depuis un nouveau process, monitorer les exports certificats sur les DC et serveurs ADFS.

4. XML Signature Wrapping (XSW) — manipulation structurelle

L'attaque XSW (XML Signature Wrapping) exploite une faiblesse historique de XML-DSig : la signature couvre certains nœuds XML mais l'application lit les nœuds non signés. L'attaquant intercepte une assertion légitime (via phishing, MitM ou compte standard), duplique la structure : il garde la Signature originale couvrant l'Assertion d'origine, mais insère une seconde assertion avec ses propres attributs (par exemple, NameID = admin@corp.com) en position où le parseur applicatif la lira en priorité. Les variantes XSW1 à XSW8 (Mainka, Somorovsky, Schwenk 2012) exploitent différentes confusions parseur. Les bibliothèques affectées historiquement : Apache Axis2, OpenSAML pre-3.0, SimpleSAMLphp pre-1.13, OneLogin Ruby SAML pre-1.10. En 2026, les CVE actuelles concernent davantage les implémentations maison ou les libraries non maintenues : CVE-2026-41103 (mai 2026) : Jira/Confluence Server pré-9.4 — signature SAML forgeable via XSW2 avec CVSS 9.1. Voir CVE-2026-41103 : SAML SSO Jira/Confluence forgeable.

5. IdP malveillant et SP vulnérables — CVE-2026-42354 Sentry

Une troisième famille d'attaques exploite la confiance inverse : un attaquant qui contrôle un IdP malveillant peut, dans certains SP mal configurés, obtenir une prise de compte. CVE-2026-42354 (mai 2026) : Sentry SAML SSO permettait à un IdP malveillant attaché à un compte cible de forger une assertion avec l'email d'une victime ; le SP Sentry liait alors automatiquement la session à la victime — prise de compte complète, CVSS 9.1. Voir CVE-2026-42354 : Sentry SAML SSO. Le pattern est récurrent : tout SP qui permet à un utilisateur d'attacher son propre IdP ou qui résout l'identité via NameID = email sans vérification de domaine présente un risque. Le contre-modèle : binding strict IdP↔domaine email validé, refus de tout NameID avec un domaine non listé dans la configuration tenant.

6. CVE-2026-3055 Citrix NetScaler — fuite de tokens SAML

CVE-2026-3055 (publiée mars 2026) affecte Citrix NetScaler ADC en mode SAML SP : une condition de course dans le module SAML AAA permettait la fuite mémoire de tokens SAML d'autres utilisateurs vers un attaquant authentifié. CVSS 8.6, exploitée dans la nature depuis avril 2026 par au moins deux groupes APT. Le patch (NetScaler 14.1 build 25.56+, 13.1 build 53.22+) corrige le bug, mais la rotation post-incident des sessions actives est nécessaire — sans rotation, un attaquant ayant exfiltré des tokens peut les rejouer pendant leur durée de validité (souvent 8h). Voir CVE-2026-3055 Citrix NetScaler. Leçon : les ADC SAML (NetScaler, F5 BIG-IP APM, A10) traitent les assertions en bordure réseau et sont des cibles privilégiées — patcher en J+7 max.

7. Détection — IoC et requêtes SIEM

Détecter les attaques SAML dans un SIEM requiert l'ingestion de plusieurs sources : logs ADFS / Entra ID / Okta côté IdP, logs SP authentification côté Microsoft 365, AWS CloudTrail, Salesforce Event Monitoring, Atlassian audit logs, sessions VPN/SaaS. Indicateurs prioritaires : (1) NotOnOrAfter > 1h depuis NotBefore dans une assertion ADFS (configuration standard = 60 min) ; (2) InResponseTo absent ou ne matchant aucun AuthnRequest récent ; (3) multiple Signature elements dans une seule Response ; (4) certificat IdP différent du fingerprint configuré ; (5) connexions SAML depuis IP non-IdP habituelle ; (6) AuthnContextClassRef = PasswordProtectedTransport alors que la policy IdP exige MFA. KQL Sentinel exemple : SigninLogs | where AuthenticationDetails contains "SAML" | where AuthenticationContextClassReferences !contains "MultiFactorAuthentication" | where ResultType == 0. Côté ADFS Event Logs : Event ID 4886 (Token Signing Certificate access), 1200/1202 (Token Issuance), corrélation avec Event ID 4624 Type 9 (NewCredentials) sur le serveur ADFS.

8. Défense ADFS et Entra ID — durcissement concret

Sur ADFS Windows Server : (1) déployer ADFS sur un PAW dédié sans interactive logon pour les comptes admins ; (2) restreindre les Local Admins à un groupe AD strict ; (3) auditer accès DKM via SACL sur l'objet CN=ADFS ; (4) activer extranet smart lockout ; (5) limiter la durée du Token Signing Certificate à 1 an et rotation auto via Set-AdfsCertificate ; (6) déplacer la clé DKM en HSM physique (Thales, Yubico HSM2, Entrust nShield) ou Azure Managed HSM ; (7) basculer vers Entra ID / Azure AD dès que possible — Microsoft pousse la migration ADFS→Entra depuis 2023, Entra élimine la classe d'attaques Golden SAML en stockant la clé en HSM Azure inaccessible. Sur Entra ID : appliquer Conditional Access stricte avec require MFA et compliant device, activer Continuous Access Evaluation, monitorer les service principal sign-ins avec Workload Identity Premium.

9. Défense Okta, Keycloak, OneLogin

Côté Okta : activer FastPass (passkey/FIDO2) pour tous les comptes admin ; restreindre SuperAdmin à 2 personnes max ; configurer API token rate limiting ; surveiller le journal System Log pour application.lifecycle et group.lifecycle. Côté Keycloak (Red Hat / projet open source) : déployer Realm dédié SSO, activer require SSL, configurer les client signature algorithms à RS256 minimum (pas SHA1 ni MD5), durcir session timeouts, et stocker les realm keys dans un Vault externe (HashiCorp Vault, Bitwarden Secret Manager). Côté OneLogin / PingFederate : appliquer les bulletins éditeur, audit régulier des relying parties (suppression des SP obsolètes), monitoring exports XML metadata.

10. Investigation forensique post-incident SAML

Sur incident SAML suspecté, prioriser : (1) collecter les logs IdP 90 jours arrière (ADFS Security event log, Entra SignInLogs + AuditLogs, Okta System Log) ; (2) identifier les sessions SAML actives sur tous les SP fédérés et révoquer en masse (Microsoft 365 : Revoke-AzureADUserAllRefreshToken ; AWS : invalidation des temporary credentials via STS ; Salesforce : Session Management → Kill all sessions) ; (3) extraire la liste des relying parties et certificats de chiffrement attendus pour comparaison ; (4) checker l'intégrité du Token Signing Certificate (fingerprint vs configuration documentée) ; (5) si Golden SAML confirmé : rotation immédiate du Token Signing Certificate (qui implique rotation du tenant Entra fédéré et reconfiguration de tous les SP fédérés — opération de 4-12h), passage à HSM, audit des accès machine ADFS sur 12 mois. Voir notre guide Audit Sécurité Microsoft 365 pour le post-mortem 365.

11. SAML vs OIDC vs OAuth2 — pertinence en 2026

En 2026, SAML reste dominant en enterprise legacy (Microsoft 365, AWS, Salesforce, ADP, Workday) tandis que OIDC domine en cloud-native et mobile. Les attaques SAML restent un sujet majeur car le parc SAML représente toujours 60-70 % des fédérations entreprise. La migration vers OIDC ne résout pas le problème — OIDC a ses propres classes d'attaques (Token confusion, JWT none algorithm, OIDC provider takeover) mais évite XSW grâce au format JWT signé en JOSE plutôt qu'en XML-DSig. Voir OAuth2 vs OpenID Connect vs SAML : Comparatif Protocoles.

12. Cas réels — Nobelium, APT41, BlackByte

Trois cas publics illustrent les attaques SAML à l'échelle. (1) SolarStorm / Nobelium (décembre 2020) : compromission de SolarWinds Orion, mouvement latéral vers ADFS de victimes Microsoft 365 fédérées, extraction Token Signing Certificate, forge Golden SAML pour persistence multi-cloud — opération attribuée à SVR Russie (APT29). (2) APT41 vs entreprises tech US (2022-2024) : compromission Okta admin via téléphone helpdesk social engineering, ajout d'un device MFA contrôlé, accès console Okta, modification policies, accès SP fédérés. (3) BlackByte ransomware (2024) : exploitation CVE Veeam pour pivot vers ADFS, extraction certificats, Golden SAML vers Microsoft 365 admin, chiffrement Exchange Online. Trois leçons communes : l'IdP est aussi critique que le DC, l'extraction des clés signing est silencieuse, et la rotation post-incident est longue.

Sources : MITRE ATT&CK technique T1606.002 (Forge Web Credentials : SAML Tokens) ; CyberArk Labs research "Golden SAML" 2017 ; Mandiant report "Remediation and Hardening Strategies for Microsoft 365 to Defend Against UNC2452" 2021 ; Microsoft Security Response Center advisories 2023-2026 ; ANSSI CERT-FR alerte SAML 2024.

13. Articulation avec NIS2, DORA et ISO 27001 — comprendre les obligations 2026

Le sujet du attaques saml s'inscrit en 2026 dans un cadre réglementaire européen et français dense qui structure les obligations des organisations. Trois textes majeurs encadrent désormais la posture cyber. (1) Directive NIS2 (UE 2022/2555) transposée en droit français par la loi de novembre 2024 — élargit considérablement le périmètre par rapport à NIS1 : passage de ~300 à ~10 000 entités françaises classées soit Entités Essentielles (EE), soit Entités Importantes (EI). Les obligations centrales (article 21.2) incluent l'analyse de risques annuelle, la gestion des incidents avec notification ANSSI < 24h, la continuité d'activité, la sécurité de la chaîne d'approvisionnement, la sécurité de l'acquisition/développement/maintenance, l'évaluation de l'efficacité, la formation cyber, les politiques cryptographie et contrôle d'accès, l'authentification multifacteur. Les pratiques liées à attaques SAML et la sécurisation des fédérations d'identité touchent directement plusieurs de ces obligations. (2) Règlement DORA (UE 2022/2554) applicable depuis janvier 2025 — concerne les entités financières (banques, assurances, sociétés de gestion, fintechs). Cinq piliers : gestion des risques ICT, gestion des incidents, tests de résilience opérationnelle (TLPT triennal pour entités critiques), gestion des risques tiers ICT, échange d'informations. (3) ISO 27001:2022 — norme internationale du SMSI avec 10 clauses de management et 93 contrôles Annexe A organisés en 4 thèmes : organisationnel, personnel, physique, technologique. La certification ISO 27001 fournit un cadre robuste qui couvre l'essentiel des exigences NIS2 et DORA, avec mapping documenté. Voir ISO 27001:2022 Guide Complet Certification Expert et NIS2, DORA et RGPD : Cartographie des Exigences Croisées.

14. KPI et indicateurs de pilotage — mesurer l'efficacité

Au-delà de la mise en œuvre initiale, le pilotage des sujets relatifs au attaques saml exige des indicateurs mesurables et révisés mensuellement ou trimestriellement. Cinq familles d'indicateurs structurent un tableau de bord cyber moderne 2026. (1) Couverture : pourcentage d'actifs couverts par la mesure (endpoints sous EDR, comptes en MFA, applications avec WAF, etc.) avec cible >= 95 % pour les mesures critiques. (2) Performance opérationnelle : MTTD (Mean Time To Detect) cible < 4h pour incident critique, MTTR (Mean Time To Respond) cible < 24h, taux de remédiation des vulnérabilités critiques dans le SLA (cible > 90 % patchés J+15 du Patch Tuesday). (3) Conformité : score d'audit interne ou externe (cible > 75/100), nombre de non-conformités majeures (cible 0 par trimestre), avancement plan d'action (cible > 80 % à 6 mois). (4) Maturité : score CMMI par domaine (Initial / Managed / Defined / Quantitatively Managed / Optimizing), évolution annuelle attendue +1 niveau par domaine prioritaire. (5) Risque résiduel : nombre de risques résiduels élevés non traités, valeur en € des risques résiduels selon analyse EBIOS RM, vraisemblance / gravité moyennes. Ces KPIs alimentent les revues de direction trimestrielles (ISO 27001 clause 9.3) et les rapports COMEX trimestriels. Voir Tableau de Bord KPI ISMS ISO 27004 : Excel.

15. Retour d'expérience terrain — 3 missions anonymisées

Trois cas concrets observés sur missions 2024-2026 illustrent les enjeux pratiques autour du attaques saml. Cas A — ETI industrielle 1 800 postes multi-sites (anonymisée) : initiative de modernisation de la posture cyber lancée en 2024 à la demande du COMEX après tentative de ransomware (chiffrement partiel évité grâce à EDR). Périmètre : 5 sites France + 2 Allemagne, AD complexe avec 3 forêts, mix Windows/Linux/OT. Démarche : audit complet (12 jours), pentest externe + interne (15 jours), pentest applicatif sur 2 apps métier critiques (10 jours), plan d'action 18 mois. Investissement total accompagnement : 380 000 € HT sur 18 mois (audits + remédiation + formation). Résultats à 18 mois : score posture cyber passé de 48/100 à 84/100, certification ISO 27001 obtenue, posture NIS2 conforme, 0 incident critique post-remédiation. Cas B — PME services 220 salariés (anonymisée) : remplacement d'un ancien prestataire d'audit jugé trop superficiel, demande pour audit complet en première intention. Périmètre : 1 site principal + 3 antennes commerciales, M365 + AD basique, 1 application web SaaS interne. Démarche : audit cybersécurité PME 15 contrôles (8 jours), pentest externe léger (4 jours), accompagnement remédiation 60 jours. Investissement : 22 000 € HT total. Résultats : MFA déployée 100 %, EDR en place sur 100 %, sauvegardes 3-2-1 testées trimestriellement, conformité cyber-assurance obtenue avec réduction de prime 18 %. Cas C — Collectivité 8 000 agents (anonymisée) : préparation à homologation RGS renforcée d'une plateforme de téléservices avec 1,2 M usagers. Périmètre : portail web, back-office, base de données, intégrations multiples (FranceConnect, INSEE, ANTAI). Démarche : analyse EBIOS RM (3 mois), audit PASSI architecture + configuration + tests d'intrusion (6 semaines), constitution dossier d'homologation, commission, signature. Investissement : 145 000 € HT. Résultats : homologation niveau renforcé délivrée fin 2025, validité 3 ans avec revue annuelle, intégration smooth avec FranceConnect+, fréquentation usagers en croissance +27 %.

16. Erreurs fréquentes et bonnes pratiques 2026

Six erreurs récurrentes observées sur les sujets liés au attaques saml en 2024-2026, et leurs contournements. Erreur 1 — démarrage sans cadrage : se lancer dans la mise en œuvre sans phase préalable d'analyse de contexte, d'inventaire et de cartographie. Conséquence : périmètre mal défini, budget dérapant, livrable inadapté. Bonne pratique : 5-10 % du temps total en cadrage, ateliers contradictoires avec parties prenantes, RACI clair. Erreur 2 — copier-coller des bonnes pratiques sans adaptation : appliquer une checklist générique sans contextualiser à la taille, secteur, contraintes de l'organisation. Conséquence : surinvestissement ou sous-investissement, démotivation équipe. Bonne pratique : référentiel proportionné au profil (CIS Implementation Group 1 pour PME, IG2 pour ETI, IG3 pour grands comptes). Erreur 3 — focus sur l'outil au détriment du processus : acheter une solution technique (EDR, SIEM, IAM) sans définir au préalable les processus opérationnels et les rôles. Conséquence : outil sous-exploité, alertes ignorées, ROI faible. Bonne pratique : processus avant outil, formation équipes, runbooks documentés. Erreur 4 — absence de plan post-projet : finaliser la mise en œuvre sans plan de continuité opérationnelle, de revue périodique, de mise à jour. Conséquence : dérive lente de la posture, retour à l'état initial en 12-24 mois. Bonne pratique : plan annuel de mise à jour, revue trimestrielle KPI, audit annuel externe. Erreur 5 — sous-estimation de la conduite du changement : déployer techniquement sans accompagner les utilisateurs et opérationnels. Conséquence : résistance, contournements (post-it mots de passe, désactivation MFA, etc.). Bonne pratique : 15-25 % du budget projet en communication, formation, support. Erreur 6 — pas d'évaluation indépendante : s'auto-évaluer sans regard externe critique. Conséquence : angle mort persistants, biais de confirmation. Bonne pratique : audit externe annuel par prestataire différent de l'intégrateur, alternance des auditeurs tous les 2-3 ans.

17. Écosystème des acteurs cyber français 2026

L'écosystème cyber français en 2026 comporte plusieurs catégories d'acteurs complémentaires à mobiliser selon les besoins liés au attaques saml. (1) Cabinets de conseil cyber généralistes : Big 4 (Deloitte, EY, KPMG, PwC), Capgemini, Sopra Steria, Atos Eviden, Wavestone, Mazars, Beijaflore. Forces : couverture globale, références grands comptes, méthodologies normalisées. Limites : prix élevés, parfois trop pyramidal. (2) Cabinets cyber spécialisés : Synacktiv, Wallix, Stormshield Audit, Almond, Devoteam Cyber Trust, Wavestone Cybersecurity, Algosecure, Itrust, HarfangLab Services, et acteurs régionaux. Forces : expertise technique pointue, agilité, prix compétitifs. Limites : ressources limitées sur très gros projets. (3) Cabinets d'expertise pure-players souvent < 30 consultants, spécialisés (AD, cloud, OT, IA security) — typiquement ce que nous représentons. Forces : profondeur d'expertise, contact direct expert, flexibilité. Limites : capacité limitée projet très grande taille. (4) MSSP et MDR managés : Orange Cyberdefense, Thales Cyber Solutions, Atos Big Fish, Sopra Steria CyberSecurity Services. Forces : opérations 24/7, SLA, mutualisation. (5) Solutions software éditeurs : Wallix (PAM), Stormshield (UTM), Tehtris (XDR), HarfangLab (EDR), Datadog (observability), Snyk (DevSecOps). (6) Acteurs publics : ANSSI (autorité nationale), CERT-FR, Cybermalveillance.gouv.fr, France 2030 / Plan France Relance cyber, BPI France Diag Cyber, régions (BoosterCyber Île-de-France). (7) Communautés et écosystème : Clusif, Hexatrust, FIC (Forum International de la Cybersécurité, devenu InCyber Forum), Le Hack, BSides Paris, OSSIR, Cesin. Construire un écosystème de prestataires complémentaires plutôt que dépendre d'un acteur unique réduit le risque et améliore la couverture expertise.

FAQ

Comment savoir si mon ADFS a été compromis par une attaque Golden SAML ?

Quatre signaux à corréler : (1) accès Local Admin inhabituels sur les serveurs ADFS (Event ID 4624 Type 10), (2) export ou copie de la base ADFS hors maintenance prévue, (3) requêtes LDAP sur l'objet CN=ADFS,CN=Microsoft,CN=Program Data, (4) sessions SAML émises sans correspondance dans les logs ADFS Token Issuance. La détection définitive passe souvent par un audit forensique externe car les outils Golden SAML laissent peu de traces.

Faut-il abandonner SAML au profit d'OIDC en 2026 ?

Pas systématiquement. SAML reste robuste si l'IdP est correctement durci (HSM, monitoring, MFA admin), et son écosystème SP est plus mature dans l'enterprise (Microsoft 365, AWS Identity Center, Salesforce, Atlassian fédéré). Migrer vers OIDC quand c'est possible (applications cloud-native, mobile) mais ne pas migrer SAML→OIDC pour la sécurité car OIDC a sa propre surface d'attaque (token theft, JWT confusion).

Quelle est la durée recommandée pour les sessions SAML ?

Pour les sessions standard utilisateur : 8 heures max avec re-authentification quotidienne. Pour les sessions admin / privilégiées : 1 heure max avec re-authentification + step-up MFA. Pour les service accounts SAML (rarement nécessaire) : tokens dédiés courts (15 min) avec rotation auto et monitoring spécifique. Configuration ADFS : Set-AdfsRelyingPartyTrust -TokenLifetime 60.

XSW est-il encore exploitable en 2026 sur les SP modernes ?

Sur les libraries SAML majeures patchées (Microsoft .NET SAML 2.0, OpenSAML 4.x, Spring Security SAML 6+, Keycloak 23+), XSW classique est mitigé depuis 2014-2018. Mais les CVE 2025-2026 montrent que les implémentations maison ou les vieilles versions (Apache CXF, Axis2, anciennes versions Atlassian, Sentry pré-patch) restent vulnérables. Tester systématiquement avec SAMLRaider Burp lors d'un pentest applicatif.

Combien coûte un audit SAML complet d'une entreprise ?

Pour une entreprise française moyenne (1 IdP central + 30-80 SP fédérés) : entre 12 000 et 28 000 € HT. Le périmètre couvre audit configuration IdP (ADFS/Entra/Okta), revue des relying parties, tests XSW sur SP critiques, scénario Golden SAML en lab, revue chaîne PKI signing, recommandations HSM, monitoring SIEM. Livrable : rapport technique + plan de remédiation priorisé + scénario incident response.

Pour aller plus loin

• Attaques SAML & ADFS 2026 : Golden SAML, Vulnérabilités
• OAuth2 vs OpenID Connect vs SAML : Comparatif Protocoles
• SAML vs OIDC vs OAuth2 : choisir le bon protocole SSO
• CVE-2026-42354 : prise de compte Sentry via SAML SSO
• CVE-2026-3055 Citrix NetScaler : fuite de tokens SAML
• Notre service Pentest Active Directory