La gestion sécurisée des identités et des accès est devenue un enjeu crucial pour les organisations. Parmi les solutions disponibles, le Security Assertion Markup Language (SAML) s’est imposé comme un standard incontournable pour l’authentification unique (SSO).
Ce protocole basé sur XML permet aux utilisateurs de s’authentifier une seule fois et d’accéder à plusieurs applications sans avoir à se reconnecter; simplifiant ainsi l’expérience utilisateur. Cependant, en cas de mauvaise implémentation, des vulnérabilités critiques peuvent être exploitées.
Cet article explore en profondeur les principes et le fonctionnement de SAML. Nous présenterons également les vulnérabilités et attaques courantes auxquelles il peut être exposé; et détaillerons les bonnes pratiques à adopter pour une implémentation sécurisée de SAML.
Guide complet sur le protocole d’authentification SAML
Principes et fonctionnement du SAML
Définition du SAML
Le Security Assertion Markup Language (SAML) est un standard ouvert basé sur XML qui permet l’échange d’informations d’authentification et d’autorisation entre différentes parties, notamment entre un fournisseur d’identité (Identity Provider ou IdP) et un fournisseur de services (Service Provider ou SP).
SAML joue un rôle crucial dans les environnements d’entreprise en facilitant l’authentification unique (SSO), permettant ainsi aux utilisateurs de s’authentifier une seule fois pour accéder à une multitude d’applications et de services sans avoir à se reconnecter à chaque fois.
Architecture et composants du SAML
SAML repose sur une architecture claire et bien définie, qui inclut des composants clés et des principes fondamentaux. Au cœur de cette architecture, on trouve l’IdP et le SP.
Identity Provider
Un Identity Provider (IdP) est une entité responsable de l’authentification des utilisateurs et de la fourniture des informations d’identité nécessaires aux Service Providers (SP). L’IdP joue un rôle central dans la vérification des identités et la gestion des informations d’authentification.
L’IdP est chargé de valider l’identité de l’utilisateur en utilisant divers mécanismes d’authentification, tels que les mots de passe, les certificats numériques, les jetons matériels ou les méthodes d’authentification multifacteur (MFA). Une fois l’utilisateur authentifié, l’IdP génère une assertion SAML, qui contient les informations d’identité et d’autorisation de l’utilisateur. Cette assertion est signée afin de garantir son intégrité et son authenticité.
L’IdP gère les informations d’identité de l’utilisateur, telles que son nom, son adresse email, son rôle et d’autres attributs pertinents. Ces informations sont incluses dans l’assertion SAML envoyée au SP. De nombreux IdP sont disponibles, notamment Okta, Microsoft Azure Active Directory, Google Identity Platform, Auth0 et Keycloak.
Service Provider
Un Service Provider (SP) est une entité qui fournit des services, des applications ou des ressources aux utilisateurs. Le SP délègue la responsabilité de l’authentification à un IdP et utilise les informations fournies par l’IdP pour contrôler l’accès aux ressources.
Lorsqu’un utilisateur tente d’accéder à une application ou à un service, le SP redirige l’utilisateur vers l’IdP pour l’authentification. Il va ensuite traiter l’assertion SAML qui lui sera renvoyé pour connecter l’utilisateur à la plateforme.
Processus d’authentification SAML
Pour comprendre pleinement le fonctionnement de SAML, il est utile d’examiner un flux d’authentification typique en détail. Lorsqu’un utilisateur tente d’accéder à une application protégée par SAML (SP), la demande d’accès déclenche une série d’étapes bien définies.
Tout d’abord, l’utilisateur initie une demande d’accès à l’application (SP). En réponse, le SP redirige l’utilisateur vers l’IdP pour l’authentification. Cette redirection est souvent accompagnée d’une requête SAML contenant les informations nécessaires pour identifier l’utilisateur et le service demandé.
Une fois redirigé, l’utilisateur interagit avec l’IdP pour s’authentifier. Cela peut impliquer la saisie d’un nom d’utilisateur et d’un mot de passe, l’utilisation de méthodes d’authentification multifacteur (MFA) ou d’autres techniques d’authentification. Si l’authentification réussit, l’IdP génère une assertion SAML, qui est essentiellement une preuve d’identité et d’authentification de l’utilisateur.
L’assertion SAML est ensuite transmise au SP. Le SP reçoit l’assertion et vérifie son intégrité et son authenticité. Cette vérification inclut la validation de la signature numérique de l’assertion et la vérification des attributs contenus pour s’assurer qu’ils correspondent aux attentes et aux règles de sécurité du SP.
Si l’assertion est valide et que les attributs correspondent aux critères de sécurité, le SP accorde l’accès à l’utilisateur, lui permettant ainsi d’accéder aux ressources demandées sans avoir à se reconnecter.
Ce processus fluide et sécurisé de SSO améliore non seulement l’expérience utilisateur, mais renforce également la sécurité en centralisant la gestion des identités et en réduisant la surface d’attaque pour les mots de passe.
Clés de signature et clés de chiffrement du SAML
Dans les systèmes de sécurité basés sur SAML, l’utilisation de clés cryptographiques est essentielle pour assurer la sécurité et l’intégrité des échanges.
Deux types de clés sont couramment utilisées : les clés de signature (signing keys) et les clés de chiffrement (encryption keys).
Les clés de signature (Signing Keys)
Les clés de signature sont utilisées pour garantir l’authenticité et l’intégrité des messages SAML. Lorsqu’un Identity Provider (IdP) signe une assertion SAML, il utilise une clé privée pour créer une signature numérique.
Cette signature permet au Service Provider (SP) de vérifier que l’assertion n’a pas été altérée en transit et qu’elle provient bien de l’IdP légitime.
La signature numérique est créée en appliquant un algorithme de signature à l’assertion SAML en utilisant la clé privée de l’IdP. Le SP, en possession de la clé publique correspondante, peut alors vérifier la signature (via la balise <ds:X509Certificate> des métadatas).
Si la signature est valide, cela confirme que l’assertion est authentique et intègre.
Les clés de chiffrement (Encryption Keys)
Les clés de chiffrement, quant à elles, sont utilisées pour protéger la confidentialité des données échangées. Lorsque des informations sensibles sont incluses dans une assertion SAML, elles peuvent être chiffrées pour s’assurer qu’elles ne peuvent être lues que par les parties autorisées.
Le chiffrement des données est réalisé en utilisant une clé publique pour chiffrer l’information. Seule la partie possédant la clé privée correspondante peut déchiffrer les données. Dans le contexte SAML, cela signifie que l’IdP peut chiffrer certaines parties de l’assertion avant de l’envoyer au SP. Cela garantit que seul le SP, possédant la clé privée correspondante, peut lire ces informations.
Quelles sont les différences entre SAML et OpenID ?
Dans le paysage de la gestion des identités et des accès (IAM), SAML et OpenID sont deux des protocoles les plus utilisés pour l’authentification unique (SSO) et l’autorisation. Bien qu’ils partagent des objectifs similaires, leurs architectures, mécanismes et cas d’utilisation diffèrent.
Architecture et principes de fonctionnement
SAML repose sur un échange structuré d’informations d’authentification et d’autorisation à l’aide de documents XML entre un fournisseur d’identité (IdP) et un fournisseur de services (SP). SAML utilise des assertions pour transmettre les informations d’identité et d’autorisation, permettant ainsi une authentification unique sécurisée.
OpenID est un protocole basé sur OAuth 2.0 qui permet l’authentification en utilisant des jetons JSON Web Tokens (JWT).
Contrairement à SAML, OpenID Connect est conçu pour être léger et facile à intégrer; ce qui le rend particulièrement adapté aux applications web et mobiles modernes.
OpenID Connect ajoute une couche d’authentification à OAuth 2.0, permettant aux utilisateurs de se connecter à des applications tierces en utilisant leurs identifiants existants d’un fournisseur d’identité.
Sécurité et gestion des sessions
En termes de sécurité, les deux protocoles offrent des mécanismes robustes pour protéger les informations d’identité et d’authentification.
SAML repose fortement sur des signatures numériques et des certificats pour assurer l’intégrité et l’authenticité des assertions. Cela permet une gestion stricte des sessions et des accès, particulièrement utile dans les environnements réglementés.
OpenID Connect utilise également des signatures et des méthodes de cryptographie pour sécuriser les JWT. Cependant, il se distingue par sa capacité à gérer les sessions de manière plus flexible.
Les jetons d’accès et d’actualisation dans OAuth 2.0 permettent de gérer les sessions utilisateur de manière efficace. Ils offrent également des options pour la révocation et le renouvellement des jetons.
Quelles sont les vulnérabilités et attaques courantes de SAML ?
SAML, bien que robuste, peut être vulnérable à plusieurs types d’attaques si mal configuré ou implémenté.
Parmi les plus critiques, on trouve les attaques par rejeu (Replay attacks), la manipulation des assertions (due à l’absence de signature), les attaques par inclusion de fichier externe (XXE), et les attaques exploitant des erreurs de validation des attributs, telles que les adresses e-mail inter-tenant.
Attaques par rejeu (Replay Attacks)
Une replay attack se produit lorsque des messages SAML valides sont interceptés et réutilisés par un attaquant pour obtenir un accès non autorisé. Ce type d’attaque est possible si le système ne met pas en œuvre des mécanismes adéquats pour empêcher la réutilisation des messages SAML, tels que des horodatages ou des jetons à usage unique.
Dans un scénario classique, l’assertion SAML est valide pendant environ une minute, ce qui est suffisant pour permettre sa génération et son envoi au SP.
Ce délai est indiqué dans la balise saml:Conditions via les attributs NotBefore et NotOnOrAfter.
La durée de vie de l’assertion peut être configurée dans les paramètres de l’IdP. Par exemple, si elle est définie sur 30 jours, cela peut permettre de rejouer une assertion valide et d’accéder de manière non autorisée au compte.
Avec une configuration correcte, l’assertion ne sera plus valide après sa première utilisation, ce qui limite les risques de rejouabilité. En revanche, des configurations incorrectes peuvent ne pas invalider l’assertion après son utilisation, permettant ainsi des attaques par rejeu.
Afin de se prémunir contre les replay attacks, il est nécessaire d’utiliser des jetons à durée de vie limitée : Les assertions SAML doivent inclure des horodatages et des périodes de validité très courtes. De plus, les assertions doivent être invalidées dès qu’elles sont utilisés.
Manipulation des Assertions (en l’absence de signature)
Lorsque les assertions SAML ne sont pas signées, elles peuvent être manipulées par des attaquants. L’absence de signature numérique signifie que l’intégrité et l’authenticité de l’assertion ne peuvent pas être vérifiées, ce qui permet à un attaquant de modifier les attributs de l’assertion, comme les rôles ou les privilèges.
Dans ce cas, toutes les options permettant la validation des assertions ont été désactivées via la configuration du SP. Cela signifie qu’il ne vérifiera pas si l’assertion est chiffrée et signée.
Sur notre IDP, nous allons aussi désactiver la signature et le chiffrement des assertions.
Lors de la connexion à l’identity provider, il va générer une assertion non chiffré, ce qui ne protègera pas l’intégrité des données transmises.
Par défault l’utilisateur “vaadata” possède le rôle “default-roles-master”.
Un attaquant peut alors intercepter la requête SAML lors de l’authentification, puis en ajouter un attribut “Role” avec la valeur “create-client”.
De cette façon, il va modifier l’assertion transmise au serveur en ajoutant un nouveau rôle.
Une fois authentifié, on remarque que le rôle “create-client” à bien été ajouté au compte “vaadata” sur le service provider, lui donnant un accès plus privilégié à la plateforme.
Pour prévenir la manipulation des assertions, il est essentiel que toutes les assertions SAML soient signées numériquement par l’IdP. Cette mesure garantit l’intégrité et l’authenticité des informations transmises.
De plus, les Service Providers (SP) doivent vérifier systématiquement la signature de chaque assertion pour s’assurer qu’elle n’a pas été altérée en transit.
XXE (XML External Entity)
Les attaques XXE (XML External Entity) exploitent des vulnérabilités dans le traitement des documents XML par les parsers mal configurés. Une attaque XXE peut permettre à un attaquant de lire des fichiers sensibles sur le serveur, d’effectuer des requêtes réseau depuis le serveur mais aussi d’executer des commandes distantes sur le serveur distant.
Dans le cas où le serveur SP utilise un parser XML custom ou vulnérable au XXE, il est possible d’injecter un payload dans l’assertion SAML afin d’exploitation une XML External Entity lors du parsing de l’assertion SAML.
Pour en savoir plus, nous vous renvoyons vers notre article : Comprendre les vulnérabilités XXE.
Attaque par renvoi d’email
Cette attaque exploite des failles de validation des attributs dans les assertions SAML, notamment lorsque les emails ne sont pas correctement vérifiés pour appartenir au tenant correct.
Si le système ne vérifie pas que l’email dans l’assertion SAML appartient bien au domaine du tenant, un attaquant peut obtenir un accès non autorisé en utilisant un email valide d’un autre tenant.
Dans un contexte où la plateforme est multi-tenant et utilise SAML pour l’authentification, il est crucial de tester la possibilité de voler un compte d’un autre tenant.
Un manque de contrôle des droits côté Service Provider (SP) peut permettre cette attaque. L’assertion SAML de l’Identity Provider (IdP) renvoie plusieurs attributs, notamment l’email de l’utilisateur, son prénom et son nom, ainsi que d’autres attributs potentiels comme le rôle.
Ces attributs, présents dans les balises <saml:Attribute>, sont ensuite parsés par le SP. Le serveur vérifie alors si l’email est présent dans sa base de données. Si c’est le cas, il authentifie l’utilisateur. Sinon, la connexion échoue car l’utilisateur n’existe pas.
L’attaque consiste donc à renvoyer l’adresse email d’un compte d’un autre tenant au SP afin qu’il effectue la connexion et accorde l’accès de manière non autorisée.
Pour assurer la validation stricte des attributs d’email, les SP doivent vérifier que les emails contenus dans les assertions SAML appartiennent bien au tenant correct.
Cela garantit que seuls les utilisateurs autorisés peuvent accéder aux ressources spécifiques à leur tenant.
Il est également crucial d’implémenter des contrôles de séparation stricte entre les tenants. Cette segmentation évite toute confusion sur les identités entre tenants, renforçant ainsi la sécurité.
Enfin, il est recommandé d’assigner des domaines spécifiques pour chaque tenant. Les SP doivent vérifier que les adresses email appartiennent au domaine assigné au tenant concerné; assurant ainsi que les utilisateurs ne peuvent accéder qu’aux ressources autorisées.
Comment sécuriser les implémentations SAML ?
Validation stricte des attributs
Les Service Providers (SP) doivent valider strictement les attributs d’email contenus dans les assertions SAML pour s’assurer qu’ils appartiennent bien au tenant correct.
Cela empêche les utilisateurs malveillants d’utiliser des adresses e-mail valides mais non autorisées pour accéder à des ressources sensibles.
Une validation rigoureuse des attributs permet de vérifier l’authenticité et la légitimité des informations fournies dans les assertions SAML.
Segmentation stricte des tenants
Il est crucial d’implémenter des contrôles de séparation stricte entre les tenants pour éviter toute confusion ou malentendu sur les identités.
La segmentation stricte des tenants garantit que chaque tenant dispose de son propre espace de gestion des identités, sans interférence possible avec les autres.
Utilisation de domaines spécifiques par tenant
Assigner des domaines spécifiques pour chaque tenant et vérifier que les adresses email appartiennent au domaine assigné est une pratique recommandée.
En s’assurant que les adresses email sont correctement associées à leur tenant respectif, les SP peuvent prévenir les attaques par renvoi d’email.
Utilisation de signatures numériques
Toutes les assertions SAML doivent être signées numériquement par l’Identity Provider (IdP).
Les signatures numériques garantissent l’intégrité et l’authenticité des assertions, empêchant ainsi leur altération par des attaquants.
Les SP doivent vérifier systématiquement la signature de chaque assertion pour s’assurer qu’elle n’a pas été modifiée en transit.
Prévention des attaques par rejeu
Pour éviter les attaques par rejeu, les assertions SAML doivent inclure des jetons à durée de vie limitée et des horodatages précis.
Les SP doivent vérifier rigoureusement ces horodatages et rejeter toute assertion en dehors de la fenêtre de validité.
Surveillance et audits réguliers
Il est important de surveiller et d’auditer régulièrement les échanges SAML pour détecter toute activité suspecte ou anomalie. La mise en place de systèmes de détection des intrusions (IDS) et de journaux d’audit permet de suivre et d’analyser les transactions SAML.
Cette vigilance continue aide à identifier et à réagir rapidement aux incidents de sécurité, renforçant ainsi la posture de sécurité globale de l’organisation.
Implémentation de l’authentification multifacteur (MFA)
L’authentification multifacteur (MFA) ajoute une couche supplémentaire de sécurité au processus d’authentification.
En combinant plusieurs méthodes d’authentification, telles que les mots de passe, les jetons matériels, et les vérifications biométriques, les IdP peuvent renforcer la sécurité des identités des utilisateurs.
L’implémentation d’un MFA réduit le risque de compromission des identifiants et renforce la protection contre les accès non autorisés.
Auteur : Alexis MARTIN – Pentester @Vaadata