Les exigences sont souvent formulées en termes d'authentification (mutuelle), d'intégrité et de confidentialité, laissant le choix du mécanisme de sécurité aux responsables de la mise en œuvre et des déploiements. Le principal cas d'utilisation de SAML est appelé authentification unique par navigateur Web (SSO). Un utilisateur utilise un agent utilisateur (généralement un navigateur Web) pour demander une ressource Web protégée par un fournisseur de services SAML. Le fournisseur de services, souhaitant connaître l'identité de l'utilisateur demandeur, émet une demande d'authentification auprès d'un fournisseur d'identité SAML via l'agent utilisateur.
Sécurité SAML générale
Les sections suivantes analysent les risques de sécurité liés à l'utilisation et à la mise en œuvre de SAML et décrivent les contre-mesures utilisées par le plug-in/module miniOrange SAML SSO pour atténuer les risques.
- Affirmations SAML :
Au niveau de l'assertion SAML elle-même, il y a peu à dire sur les problèmes de sécurité : la plupart des problèmes surviennent lors des communications dans le protocole requête/réponse, ou lors de la tentative d'utilisation de SAML au moyen de l'une des liaisons. Bien entendu, le consommateur est toujours censé respecter la période de validité de l'assertion et tous les éléments présents dans l'assertion. Cependant, un problème au niveau des assertions mérite analyse : une assertion, une fois émise, échappe au contrôle de l'émetteur. Ce fait a plusieurs conséquences. Par exemple, l'émetteur n'a aucun contrôle sur la durée pendant laquelle l'assertion sera conservée dans les systèmes du consommateur ; L'émetteur n'a pas non plus de contrôle sur les parties avec lesquelles le consommateur/prestataire de services partagera les informations d'assertion. Ces préoccupations s'ajoutent aux préoccupations concernant un attaquant malveillant qui peut voir le contenu des assertions qui transitent sur le réseau en clair (ou insuffisamment chiffré). Bien que des efforts aient été faits pour résoudre bon nombre de ces problèmes dans la spécification SAML, rien dans la spécification n'effacera l'exigence d'un examen attentif de ce qu'il faut mettre dans une assertion. À tout moment, les émetteurs doivent considérer les conséquences possibles si les informations contenues dans l'assertion sont stockées sur un site distant, où elles peuvent être directement utilisées à mauvais escient, ou exposées à des pirates potentiels, ou éventuellement stockées pour des utilisations frauduleuses plus créatives. Les émetteurs devraient également envisager la possibilité que les informations contenues dans l'assertion puissent être partagées avec d'autres parties, ou même rendues publiques, intentionnellement ou par inadvertance.
1.1. Protocole SAML :
Les sections suivantes décrivent les considérations de sécurité pour le protocole de demande-réponse SAML lui-même, indépendamment de toute menace résultant de l'utilisation d'une liaison de protocole particulière.
1.1.1. Déni de service:
Le protocole SAML est sensible à une attaque par déni de service (DOS). La gestion d'une requête SAML est potentiellement une opération très coûteuse, comprenant l'analyse du message de requête (impliquant généralement la construction d'une arborescence DOM), la recherche dans la base de données/le magasin d'assertions (potentiellement sur une clé non indexée), la construction d'un message de réponse et potentiellement un ou plusieurs opérations de signature numérique. Ainsi, l’effort requis par un attaquant pour générer des requêtes est bien inférieur à l’effort nécessaire pour traiter ces requêtes.
1.1.2. Exiger des demandes signées
Le plugin/module miniOrange SAML SSO signe la demande, réduit également l'ordre de l'asymétrie entre le travail effectué par le plugin SAML et le répondeur. Le travail supplémentaire requis du répondeur pour vérifier la signature représente un pourcentage relativement faible du travail total requis du répondeur, tandis que le processus de calcul de la signature numérique représente une quantité de travail relativement importante pour le demandeur. Réduire cette asymétrie diminue le risque associé à une attaque DOS. Notez cependant qu’un attaquant peut théoriquement capturer un message signé puis le relire continuellement, contournant ainsi cette exigence. Cette situation peut être évitée en exigeant l'utilisation de l'élément XML Signature contenant un horodatage ; l'horodatage peut ensuite être utilisé pour déterminer si la signature est récente. Ainsi, plus la fenêtre de signature valide après l'émission de la réponse est étroite, plus vous disposez d'une sécurité élevée contre les attaques par déni de service par réexécution.
2. Sécurité des liaisons SAML :
Les considérations de sécurité dans la conception du protocole demande-réponse SAML dépendent dans une large mesure de la liaison de protocole particulière (telle que définie dans la spécification des liaisons SAML [SAMLBind]) qui est utilisée. Les liaisons sanctionnées par le comité technique des services de sécurité OASIS sont la liaison SOAP, la liaison SOAP inversée (PAOS), la liaison de redirection HTTP, la liaison de redirection HTTP/POST et la liaison d'artefact HTTP et les liaisons d'URI SAML. Les plugins miniOrange SAML SSO prennent en charge les liaisons Http-Redirect et Http-POST.
2.1. Liaison de redirection HTTP
2.1.2. Déni de service
Menace: Redirections malveillantes vers des cibles de fournisseur d'identité ou de fournisseur de services.
Description: Une fausse entité pourrait émettre une redirection vers un agent utilisateur afin que l'agent utilisateur accède à une ressource qui perturbe l'authentification unique. Par exemple, un attaquant pourrait rediriger l'agent utilisateur vers une ressource de déconnexion d'un fournisseur de services, ce qui entraînerait la déconnexion du principal de toutes les sessions d'authentification existantes.
Contre-mesures: L'accès aux ressources qui produisent des effets secondaires est spécifié avec un qualificatif transitoire qui doit correspondre à la session d'authentification en cours. Alternativement, une boîte de dialogue de confirmation pourrait être interposée et s'appuyer sur un qualificatif transitoire avec une sémantique similaire.
2.2. Liaison HTTP POST
2.2.1. Affirmation volée
Menace: Si un espion peut copier la réponse SAML de l'utilisateur réel et les assertions incluses, alors il pourrait construire un corps POST approprié et être capable de se faire passer pour l'utilisateur sur le site de destination.
Contre-mesures: Nous maintenons la confidentialité chaque fois qu'une réponse est communiquée entre le plugin SAML SSO et le navigateur de l'utilisateur. Cela offre une protection contre une écoute indiscrète qui obtiendrait la réponse et les assertions SAML d'un utilisateur réel. Si une écoute indiscrète déjoue les mesures utilisées pour garantir la confidentialité, des contre-mesures supplémentaires sont disponibles :
● Les sites du fournisseur d'identité et du fournisseur de services DEVRAIENT faire des efforts raisonnables pour garantir que les paramètres d'horloge sur les deux sites diffèrent d'au plus quelques minutes. De nombreuses formes de services de synchronisation temporelle sont disponibles, à la fois sur Internet et à partir de sources propriétaires.
● Lorsqu'un profil SAML non SSO utilise la liaison POST, il doit garantir que le destinataire peut effectuer une confirmation du sujet en temps opportun. À cette fin, une assertion d'authentification SAML pour le principal DOIT être incluse dans la réponse du formulaire POST.
● Les valeurs des attributs NotBefore et NotOnOrAfter des assertions SSO DEVRAIENT avoir la période de validité la plus courte possible compatible avec une communication réussie de l'assertion du fournisseur d'identité au site du fournisseur de services. Cela prend généralement quelques minutes. Cela garantit qu’une assertion volée ne peut être utilisée avec succès que dans un court laps de temps.
● Le plugin miniOrange SAML SSO vérifie la période de validité de toutes les assertions obtenues à partir du site Identity Provider et rejette les assertions expirées. Nous choisissons de mettre en œuvre un test de validité plus strict pour les assertions SSO, par exemple en exigeant que la valeur de l'attribut IssueInstant ou AuthnInstant de l'assertion soit à quelques minutes de l'heure à laquelle l'assertion est reçue sur le site du fournisseur de services.
● Si une déclaration d'authentification reçue inclut un élément avec l'adresse IP de l'utilisateur, le site du fournisseur de services PEUT vérifier l'adresse IP du navigateur par rapport à l'adresse IP contenue dans la déclaration d'authentification.
2.2.2. Affirmation forgée
Menace: Un utilisateur malveillant, ou l'utilisateur du navigateur, pourrait falsifier ou modifier une assertion SAML.
Contre-mesures: Le profil navigateur/POST nécessite que la réponse SAML contenant les assertions SAML soit signée, assurant ainsi à la fois l'intégrité et l'authentification du message. Le plugin miniOrange SAML SSO vérifie la signature et authentifie l'émetteur.
2.2.3. Exposition à l’état du navigateur
Menace: Le profil navigateur/POST implique le téléchargement d’assertions du navigateur Web vers le site d’un fournisseur de services. Ces informations sont disponibles dans le cadre de l'état du navigateur Web et sont généralement stockées dans un stockage persistant sur le système utilisateur de manière totalement non sécurisée. La menace ici est que l’affirmation puisse être « réutilisée » ultérieurement.
Contre-mesures: Les assertions communiquées à l'aide de ce profil doivent toujours avoir une durée de vie courte et doivent avoir une Affirmation SAML élément. Les sites des fournisseurs de services doivent garantir que les assertions ne sont pas réutilisées.
2.2.4. Replay
Menace: Les attaques par rejeu reviennent à resoumettre le formulaire afin d'accéder frauduleusement à une ressource protégée.
Contre-mesures: Le plugin miniOrange SAML SSO exige que les assertions transférées aient la propriété à usage unique, empêchant ainsi les attaques par relecture de réussir.
2.2.5. Modification ou exposition des informations d'état
Menace: Falsification ou fabrication de l’état du relais. Certains messages peuvent porter un élément dont il est recommandé que le producteur protège l'intégrité et éventuellement la confidentialité. Si ces pratiques ne sont pas suivies, un adversaire pourrait déclencher des effets secondaires indésirables. De plus, en ne protégeant pas la confidentialité de la valeur de cet élément, une entité système légitime pourrait, par inadvertance, exposer des informations au fournisseur d'identité ou à un attaquant passif.
Contre-mesure : Suivez la pratique recommandée en matière de protection de la confidentialité et de l’intégrité des données RelayState. Remarque : Étant donné que la valeur de cet élément est à la fois produite et consommée par la même entité système, des primitives cryptographiques symétriques pourraient être utilisées.
3. Sécurité du profil SAML
La spécification des profils SAML [SAMLProf] définit les profils SAML, qui sont des ensembles de règles décrivant comment intégrer et extraire des assertions SAML dans un cadre ou un protocole.
3.1. Profils d'authentification unique (SSO) pour navigateur Web
Notez que l'authentification des utilisateurs sur le site source est explicitement hors de portée, tout comme les problèmes liés à l'authentification de ce site source. La notion clé est que l'entité du système source doit être capable de s'assurer que l'entité du système client authentifiée avec laquelle elle interagit est la même que celle de l'étape d'interaction suivante. Une façon d'y parvenir consiste à effectuer ces étapes initiales en utilisant TLS comme couche de session sous le protocole utilisé pour cette interaction initiale (probablement HTTP).
3.1.1. Profil SSO
3.1.1.1. Modification des messages
Menace: La possibilité de modification des messages dans le flux existe pour cet ensemble de profils. Certains résultats indésirables potentiels sont les suivants :
● La modification de la demande initiale peut entraîner un rejet chez l'émetteur SAML, ou
création d'un artefact ciblé sur une ressource différente de celle demandée
● La modification de l'artefact peut entraîner un déni de service au niveau du consommateur SAML.
● La modification des assertions elles-mêmes pendant le transit pourrait entraîner toutes sortes de
de mauvais résultats (s'ils ne sont pas signés) ou de déni de service (s'ils sont signés et
le consommateur les rejette).
Contre-mesures: Pour éviter toute modification des messages, le trafic doit être transporté au moyen d'un système garantissant l'intégrité des messages d'un point de terminaison à l'autre. Pour les profils basés sur un navigateur Web, la méthode recommandée pour assurer l'intégrité des messages en transit est l'utilisation de HTTP sur TLS/SSL avec une suite de chiffrement qui assure la vérification de l'intégrité des données.
3.1.2. Profil de déconnexion unique
Menace: Un attaquant passif peut collecter l'identifiant du nom d'un principal. Durant les étapes initiales, un attaquant passif peut collecter les informations lorsqu'elles sont émises dans la redirection. L’exposition de ces données constitue une menace pour la vie privée.
Contre-mesures: Tous les échanges doivent être effectués via un transport sécurisé tel que SSL ou TLS.
Menace: Un non signé pourrait être injecté par une entité système parasite, refusant ainsi le service au Principal. En supposant que le NameID puisse être déduit ou dérivé, il est alors concevable que l'agent utilisateur puisse être invité à fournir un message fabriqué. message.
Contre-mesures: Le plugin/module miniOrange SAML SSO signe le message. Le fournisseur d'identité peut également vérifier l'identité d'un mandant en l'absence de demande signée.
3.2. Profils de gestion des identifiants de nom
Menace: Autoriser les entités du système à corréler des informations ou à exposer de manière inappropriée des informations d'identité, nuisant ainsi à la vie privée.
Contre-mesures: IDP doit veiller à utiliser des identifiants de nom différents avec différents fournisseurs de services pour le même principal. L'IDP doit chiffrer le nom d'identifiant qu'il renvoie au fournisseur de services, permettant ainsi aux interactions ultérieures d'utiliser un identifiant opaque.
3.2.1. Profils d'attribut
Les menaces liées aux liaisons associées aux profils d'attributs sont abordées ci-dessus. Aucune menace supplémentaire spécifique au profil n’est connue.
4. Résumé
La sécurité et la confidentialité doivent être abordées de manière systématique, étant donné que les problèmes humains tels que les attaques d'ingénierie sociale, les problèmes de politique, la gestion des clés et la gestion de la confiance, la mise en œuvre sécurisée et d'autres facteurs sortent du champ d'application de ce document. Les solutions techniques de sécurité ont un coût, c'est pourquoi les exigences et les alternatives politiques doivent également être considérées comme des exigences légales et réglementaires incontournables. Ce document non normatif résume les problèmes et approches de sécurité généraux ainsi que les menaces et contre-mesures spécifiques pour l'utilisation des assertions, protocoles, liaisons et profils SAML d'une manière sécurisée qui préserve la confidentialité. Les exigences normatives sont spécifiées dans les spécifications normatives SAML.
