Add authz course ; fix trailing spaces

posts/cours-id-authn.md

@@ -75,11 +75,11 @@ flowchart LR
 
 ### Des référentiels d'identités centraux
 
-La portée d'une identité peut être plus large et une identité peut être connue de plusieurs membres d'un système d'information ; on parle alors d'une identité **centralisée**. 
+La portée d'une identité peut être plus large et une identité peut être connue de plusieurs membres d'un système d'information ; on parle alors d'une identité **centralisée**.
 
-Un **référentiel d'identités central** contient les identités d'un ensemble d'acteurs. 
+Un **référentiel d'identités central** contient les identités d'un ensemble d'acteurs.
 
-L'intérêt d'un tel référentiel devient évident à mesure qu'un système d'information s'agrandit ; gérer manuellement des identités locales sur de nombreux systèmes peut mener à des incohérences, et des oublis. En rassemblant les informations dans un référentiel central, il n'y alors qu'une seule **source de vérité**, faisant autorité pour l'ensemble du système d'information concerné. Il convient également de noter qu'il peut exister des **copies** de ces informations conservées en local sur les différents systèmes assujettis à ce référentiel d'identité. Ces copies ne font pas autorité, et il convient de surveiller leur cohérence avec la source de vérité et de les invalider ou les mettre à jour, le cas échéant. 
+L'intérêt d'un tel référentiel devient évident à mesure qu'un système d'information s'agrandit ; gérer manuellement des identités locales sur de nombreux systèmes peut mener à des incohérences, et des oublis. En rassemblant les informations dans un référentiel central, il n'y alors qu'une seule **source de vérité**, faisant autorité pour l'ensemble du système d'information concerné. Il convient également de noter qu'il peut exister des **copies** de ces informations conservées en local sur les différents systèmes assujettis à ce référentiel d'identité. Ces copies ne font pas autorité, et il convient de surveiller leur cohérence avec la source de vérité et de les invalider ou les mettre à jour, le cas échéant.
 
 Les copies sont souvent nécessaires à des fins **de performance et de résilience**. En effet, centraliser les identités présente des défis techniques notamment en matière de disponibilité ; une **panne du référentiel central** peut être de nature à stopper net l'ensemble des activités d'un système d'information.
 
@@ -303,7 +303,7 @@ L’authentification est un sujet complexe, que ce cours va aborder sous de nomb
 
 ## Aspects juridiques de l'authentification
 
-L'authentification est un sujet traité à la fois par les juridictions nationales et internationales. Un défaut de conformité à ces dispositions peut entrainer des sanctions parfois sévères. 
+L'authentification est un sujet traité à la fois par les juridictions nationales et internationales. Un défaut de conformité à ces dispositions peut entrainer des sanctions parfois sévères.
 
 La Commission Nationale Information et Libertés (CNIL) a à plusieurs reprises sanctionné des sociétés mettant en place des **mécanismes d'authentification** trop faibles[^free], des **politiques de sécurité** entourant les moyens d'authentifications insuffisantes[^weakpass], ou des **mécanismes de stockage** des éléments authentifiants trop faibles, mal déployés ou mal composés[^doctissimo].
 
@@ -311,9 +311,9 @@ La Commission Nationale Information et Libertés (CNIL) a à plusieurs reprises
 [^weakpass]: https://www.legifrance.gouv.fr/cnil/id/CNILTEXT000042203965/
 [^doctissimo]: https://www.legifrance.gouv.fr/cnil/id/CNILTEXT000047552103
 
-Parmi les textes juridiques encadrant l'authentification, on peut notamment évoquer le **règlement européen "Electronic Identification, Authentication and Trust Services" (eiDAS)[^eidas]** et la **"directive révisée sur les services de paiement" (DSP2)**[^dsp2]. 
+Parmi les textes juridiques encadrant l'authentification, on peut notamment évoquer le **règlement européen "Electronic Identification, Authentication and Trust Services" (eiDAS)[^eidas]** et la **"directive révisée sur les services de paiement" (DSP2)**[^dsp2].
 
-En France, la directive DSP2 a été transposée notamment dans les articles L133-4[^cmfl1334] et L133-44[^cmfl13344] du **code monétaire et financier**. 
+En France, la directive DSP2 a été transposée notamment dans les articles L133-4[^cmfl1334] et L133-44[^cmfl13344] du **code monétaire et financier**.
 
 Pour le règlement eiDAS, des spécifications techniques viennent compléter les textes juridiques, notamment à des fins d'**interopérabilité**[^interopeidas]. Des précisions techniques sont également apportées sur les contraintes pour satisfaire les différents **niveaux de garantie** définis par le règlement[^authnleveleidas]. Une ordonnance[^ordoanssieidas] donne le pouvoir à l'Agence Nationale de la Sécurité des Systèmes d'Information (ANSSI)[^ANSSI] de certifier des moyens d'authentification permettant de satisfaire ces niveaux de garantie. De plus amples informations sur le règlement eiDAS peuvent être trouvées sur le site de l'ANSSI[^anssieidas].
 
@@ -341,11 +341,11 @@ Le respect des règles et "recommandations" listées dans ces documents est requ
 ## Les facteurs d'authentification
 
 Le règlement d'exécution (UE) 2015/1502[^authnleveleidas] définit trois types de facteurs d'authentification.
-	
+
 > a) "**facteur d'authentification basé sur la possession**", un facteur d'authentification dont il revient au sujet de démontrer la possession;
-> 
+>
 > b) "**facteur d'authentification basé sur la connaissance**", un facteur d'authentification dont il revient au sujet de démontrer la connaissance;
-> 
+>
 > c) "**facteur d'authentification inhérent**", un facteur d'authentification qui est basé sur un attribut physique d'une personne physique, et dont il revient au sujet de démontrer qu'il possède cet attribut physique.
 
 Cette définition est également présente dans le code monétaire et financier, ainsi que dans le RGS (à une subtilité prête ; voir le chapitre concernant la force de l'authentification).
@@ -372,7 +372,7 @@ Les **jetons d'authentification** (*authentication token* ou *bearer token*) son
 
 L'authentification par des facteurs inhérents est une question épineuse en France. En effet, l'ANSSI a longtemps été une pourfendeuse de la biométrie, indiquant que les facteurs inhérents sont au mieux un facteur d'identification et non d'authentification, ou dans le pire des cas une méthode de déverrouillage pour un autre facteur d'authentification. Cette position a dû être partiellement révisée par la contrainte européenne, au travers du règlement eiDAS et la directive DSP2.
 
-Cette méfiance vis-à-vis de la biométrie n'est pourtant pas sans justification. 
+Cette méfiance vis-à-vis de la biométrie n'est pourtant pas sans justification.
 
 La vérification des facteurs inhérents s'effectue de manière **probabiliste** ; contrairement à la vérification des mots de passe ou des signatures cryptographiques, l'acquisition des données nécessaires à ce type de vérification n'est pas "parfaite", et les algorithmes sont paramétrés avec des taux de faux positifs (validation d'une personne non autorisée) et de faux négatifs (refus d'une personne autorisée). Suivant le paramétrage, l'utilisateur fait alors face soit à un risque en confidentialité et en intégrité, soit à un risque en disponibilité. Ces paramétrages doivent d'ailleurs tenir compte qu'au cours du temps, certaines caractéristiques physiques changent ou s'estompent.
 
@@ -385,7 +385,7 @@ Ensuite, les facteurs inhérents ne sont **pas renouvelables** à l'infini ; si
 
 ### Remarques concernant l'authentification des processus
 
-La notion de facteurs d'authentification n'a réellement de sens que pour les utilisateurs. Par définition, un processus ne peut posséder un équipement ou mettre en œuvre un attribut physique. 
+La notion de facteurs d'authentification n'a réellement de sens que pour les utilisateurs. Par définition, un processus ne peut posséder un équipement ou mettre en œuvre un attribut physique.
 
 Pourtant, l'exigence 9.6, alinéa f du référentiel SecNumCloud dispose que :
 
@@ -396,7 +396,7 @@ Pourtant, l'exigence 9.6, alinéa f du référentiel SecNumCloud dispose que :
 
 Avec une lecture littérale, il semblerait donc *impossible* d'authentifier des processus autonomes (par exemple, les tâches planifiées ou les traitements de chaines d'intégration ou de déploiement continu (*CI/CD*)) pour l'administration d'un cloud qualifié SecNumCloud. Fort heureusement, les auditeurs SecNumCloud ne suivent pas à la lettre cette exigence mal écrite, et les prestataires de Cloud qualifiés proposent pour la plupart des interfaces d'administration programmables (*API*) sans avoir recours à une authentification multifacteur.
 
-Il convient cependant de noter que strictement parlant, il pourrait être considéré qu'un processus puisse mettre en œuvre un facteur d'authentification basé sur la possession à l'aide d'équipements de sécurité particuliers : les ***Trusted Platform Module* (TPM)**[^TPM], les ***Hardware Security Module* (HSM)**[^HSM], et les ***Key Management Services* (KMS)**[^KMS]. Ces équipements permettent la manipulation ou l'exercice de secrets sans en permettre l'extraction, la copie ou la falsification. 
+Il convient cependant de noter que strictement parlant, il pourrait être considéré qu'un processus puisse mettre en œuvre un facteur d'authentification basé sur la possession à l'aide d'équipements de sécurité particuliers : les ***Trusted Platform Module* (TPM)**[^TPM], les ***Hardware Security Module* (HSM)**[^HSM], et les ***Key Management Services* (KMS)**[^KMS]. Ces équipements permettent la manipulation ou l'exercice de secrets sans en permettre l'extraction, la copie ou la falsification.
 
 [^TPM]: https://en.wikipedia.org/wiki/Trusted_Platform_Module
 [^HSM]: https://en.wikipedia.org/wiki/Hardware_security_module
@@ -414,7 +414,7 @@ La directive européenne DSP2 transposée dans le code monétaire et financier d
 
 Cette définition de l'article L133-44 du code monétaire et financier vient en contradiction avec la définition de l'authentification forte que l'ANSSI emploie parfois. En effet, la définition de l'authentification forte dans le RGS est (presque) conforme à la définition du droit français:
 
-> Cette recommandation est en cohérence avec la notion traditionnelle « d’authentification forte », qui préconise de combiner deux mécanismes parmi ce que l’on sait, ce que l’on a, ce que l’on est ou ce que l’on sait faire. 
+> Cette recommandation est en cohérence avec la notion traditionnelle « d’authentification forte », qui préconise de combiner deux mécanismes parmi ce que l’on sait, ce que l’on a, ce que l’on est ou ce que l’on sait faire.
 
 On notera au passage que le RGS évoque "ce que l'on sait faire" qui est un facteur qui n'est ni reconnu par le règlement eiDAS, ni le code monétaire et financier.
 
@@ -467,7 +467,7 @@ sequenceDiagram
 
   peggy ->> victor:"Je m'appelle Peggy. Mon mot de passe est #quot;Bonjour1!#quot;."
 
-  victor ->> victor:Calcule la dérivée du mot de passe reçu 
+  victor ->> victor:Calcule la dérivée du mot de passe reçu
 
   victor ->> db:"Quel est la dérivée du mot de pase de Peggy ?"
   db ->> victor:"Voici la dérivée du mot de passe de Peggy"
@@ -497,13 +497,13 @@ Le vérificateur génère un nonce et l'envoie au prouveur. Ce dernier utilise a
 
 L'intérêt supposé de ce mécanisme d'authentification est que le mot de passe n'est à aucun moment transmis dans la requête HTTP. Celui-ci est protégé par la résistance de la fonction de hachage cryptographique à la découverte d'une préimage[^preimage].
 
-[^preimage]: Une des propriétés de sécurité attendues des fonctions de hachage cryptographiques est qu'il soit virtuellement impossible de déterminer, autrement que par la recherche exhaustive, une valeur qui, passée à la fonction de hachage en entrée, produirait un résultat connu.  
+[^preimage]: Une des propriétés de sécurité attendues des fonctions de hachage cryptographiques est qu'il soit virtuellement impossible de déterminer, autrement que par la recherche exhaustive, une valeur qui, passée à la fonction de hachage en entrée, produirait un résultat connu.
 
 Cet intérêt supposé est cependant assez peu pertinent étant donné que l'essentiel des communications HTTP est de nos jours transporté sur des canaux de communication chiffrés (par TLS ou HTTP/3 qui intègrent directement le chiffrement).
 
 Un intérêt notable de ce mécanisme d'authentification est l'inclusion d'un nonce. Ce dernier permet de contrer les attaques par rejeu ; en effet, même en cas d'interception d'une preuve, il n'est pas possible de l'utiliser pour réaliser des tentatives d'authentification futures par simple rejeu.
 
-En revanche, ce mécanisme d'authentification requiert que le vérificateur connaisse le mot de passe de l'utilisateur[^passworddigest] et qu'il le stocke tel quel, ou sous un format réversible. En conséquence, en cas de fuite de la base de données du vérificateur, un attaquant pourrait immédiatement utiliser les valeurs récupérées pour usurper l'identité de tous les acteurs auprès de ce vérificateur. Cet inconvénient majeur disqualifie totalement ce mécanisme d'authentification, qui ne doit jamais être employé. 
+En revanche, ce mécanisme d'authentification requiert que le vérificateur connaisse le mot de passe de l'utilisateur[^passworddigest] et qu'il le stocke tel quel, ou sous un format réversible. En conséquence, en cas de fuite de la base de données du vérificateur, un attaquant pourrait immédiatement utiliser les valeurs récupérées pour usurper l'identité de tous les acteurs auprès de ce vérificateur. Cet inconvénient majeur disqualifie totalement ce mécanisme d'authentification, qui ne doit jamais être employé.
 
 [^passworddigest]: Le serveur peut également stocker une dérivée du mot de passe, mais pour ce protocole, cette dérivée de mot de passe a la même sensibilité que le mot de passe lui-même : le connaitre est suffisant pour s'authentifier.
 
@@ -528,13 +528,13 @@ sequenceDiagram
   peggy ->> peggy: Calcule le condensat, avec son nom, son mot de passe, X, Y et le nonce
 
   peggy ->> victor:"Je m'appelle Peggy. Je voudrais faire X sur l'adresse Y. Voici le nonce et mon condensat."
-  
+
   victor ->> db: "C'est quoi le mot de passe de Peggy ?"
 
   db ->> victor: "Le mot de passe de Peggy est #quot;Bonjour1!#quot;..."
 
   victor ->> victor:Calcule le condensat, avec le nom #quot;Peggy#quot;, le mot de passe de Peggy, X, Y et le nonce
-  
+
   alt Les condensats correspondent
     victor ->> peggy:"Bonjour Peggy. Voici le résultat de X sur Y."
   else Les condensats ne correspondent pas
@@ -596,7 +596,7 @@ sequenceDiagram
   victor ->> victor:Vérifie l'authenticité du certificat
 
   victor ->> victor:Calcule le condensat cryptographique de l'ensemble des messages reçus (sauf la signature).
-  
+
   victor ->> victor:Vérifie la signature cryptographique reçue avec la clé publique du certificat
 
   alt La signature est valide
@@ -616,7 +616,7 @@ sequenceDiagram
 
 ### La preuve par déchiffrement
 
-La preuve par déchiffrement repose sur la capacité du prouveur à démontrer la connaissance d'un secret arbitraire qui lui a été transmis sous une forme chiffrée par le vérificateur. 
+La preuve par déchiffrement repose sur la capacité du prouveur à démontrer la connaissance d'un secret arbitraire qui lui a été transmis sous une forme chiffrée par le vérificateur.
 
 Pour déchiffrer ce secret arbitraire, le prouveur doit disposer d'une clé symétrique ou d'une clé privée. La clé symétrique peut être issue d'un calcul, comme le résultat d'une fonction de dérivation de mot de passe (voir chapitre sur le stockage des éléments authentifiants pour en apprendre plus sur ces fonctions).
 
@@ -636,7 +636,7 @@ sequenceDiagram
   actor victor as Victor (Client TLS)
 
   victor ->> victor:Tire un nonce
-  
+
   victor ->> peggy:"Je voudrais consulter https://broken-by-design.fr. Voici un nonce."
 
   peggy ->> peggy:Tire un autre nonce
@@ -697,7 +697,7 @@ sequenceDiagram
       victor ->> peggy:"[Chiffré] Voici le condensat de nos échanges"
       peggy ->> peggy:Calcule un condensat cryptographique de tous les messages échangés jusqu'ici sauf le dernier reçu
       peggy ->> peggy:Compare le condensat reçu à celui qu'il a calculé
-      
+
       alt Les condensats ne correspondent pas
         peggy ->> victor: "Je ne crois pas, non."
       else Les condensats correspondent
@@ -737,7 +737,7 @@ sequenceDiagram
   trent ->> db:"C'est quoi la clé de Victor ?"
   db ->> trent:"La clé de Victor est..."
   trent ->> trent:Tire une clé A
-  trent ->> peggy:"[Chiffré avec la dérivée du mot de passe de Peggy] Voici la clé A. 
+  trent ->> peggy:"[Chiffré avec la dérivée du mot de passe de Peggy] Voici la clé A.
   trent ->> peggy:"[Chiffré avec la clé de Victor] Elle dit s'appeler Peggy. Ce message est valide M secondes/minutes/heures. Voici la clé A."
   peggy ->> peggy:Dérive son mot de passe
   peggy ->> peggy:Déchiffre la clé A avec la dérivée de son mot de passe
@@ -747,7 +747,7 @@ sequenceDiagram
   alt La période de validité est expirée
     victor ->> peggy:"Je ne crois pas, non."
   else La période de validité est en cours
-    peggy ->> victor:"[Chiffré avec la clé A] "Je suis Peggy. Je veux accéder au serveur X."  
+    peggy ->> victor:"[Chiffré avec la clé A] "Je suis Peggy. Je veux accéder au serveur X."
     victor ->> victor:Déchiffre le message Peggy avec la clé A
     victor ->> victor:Vérifie que le nom Peggy figure bien dans les deux messages déchiffrés
     alt Peggy ne connait pas véritablement la clé A, car c'était le mauvais mot de passe. Son nom ne figure pas dans son message après déchiffrement.
@@ -848,7 +848,7 @@ sequenceDiagram
   p --> p:Déchiffre le message reçu avec 1/R, ce qui donne "[Chiffré avec S]La dérivée de mon mot de passe est..."
   alt Peggy ne connait pas son mot de passe
     Note right of p:Utiliser "[Chiffré avec S]La dérivée de mon mot de passe est..." comme clé ne permet pas de déchiffrer le coffre-fort. "Peggy" ne peut continuer le protocole.
-  else 
+  else
     p ->> p:Utilise "[Chiffré avec S]La dérivée de mon mot de passe est..." comme clé pour déchiffrer le coffre-fort
     p ->> p:Utilise la clé privée contenue dans le coffre pour signer le nonce
     p ->> v:"Voici le nonce signé"
@@ -892,7 +892,7 @@ Une meilleure méthode consiste à stocker non pas le mot de passe lui-même, ma
 
 Finalement, la meilleure méthode reste encore de ne pas transmettre du tout le mot de passe au vérificateur, mais plutôt d'utiliser le mot de passe pour générer une preuve vérifiable ; cette preuve est alors l'unique élément transmis au vérificateur qui ignore tout du mot de passe de l'acteur ! C'est le cas avec le protocole OPAQUE présenté précédemment dans ce cours.
 
-Concernant la dérivation des mots de passe, les principales attaques sont : 
+Concernant la dérivation des mots de passe, les principales attaques sont :
 
 * la recherche exhaustive ou guidée (*bruteforce*) ;
 * le précalcul ;
@@ -902,11 +902,11 @@ Concernant la dérivation des mots de passe, les principales attaques sont :
 [^stuffing]: https://www.cloudflare.com/fr-fr/learning/bots/what-is-credential-stuffing/
 [^shucking]: https://www.scottbrady91.com/authentication/beware-of-password-shucking
 
-Pour ce qui est de la recherche exhaustive ou guidée, si le mot de passe est trop faible, la méthode de dérivation utilisée n'aura pas d'incidence sur la difficulté à retrouver le mot de passe. Même avec la meilleure fonction théoriquement possible, le mot de passe "password" sera cassé presque instantanément. Le guide ANSSI "Recommandations relatives à l'authentification multifacteur et aux mots de passe" indique qu'un mot de passe doit avoir une entropie allant de 65 bits à plus de 100 bits en fonction du niveau de risque associé au compte protégé par ce mot de passe. L'entropie est calculée avec le log_2 du nombre de combinaisons possibles d'un jeu de caractères sur une longueur donnée. Par exemple, si un mot de passe est uniquement numérique, et composé de 10 chiffres, alors l'entropie est de 10 puissance 10, et l'entropie est donc log_2(10^10), soit 33 bits. 
+Pour ce qui est de la recherche exhaustive ou guidée, si le mot de passe est trop faible, la méthode de dérivation utilisée n'aura pas d'incidence sur la difficulté à retrouver le mot de passe. Même avec la meilleure fonction théoriquement possible, le mot de passe "password" sera cassé presque instantanément. Le guide ANSSI "Recommandations relatives à l'authentification multifacteur et aux mots de passe" indique qu'un mot de passe doit avoir une entropie allant de 65 bits à plus de 100 bits en fonction du niveau de risque associé au compte protégé par ce mot de passe. L'entropie est calculée avec le log_2 du nombre de combinaisons possibles d'un jeu de caractères sur une longueur donnée. Par exemple, si un mot de passe est uniquement numérique, et composé de 10 chiffres, alors l'entropie est de 10 puissance 10, et l'entropie est donc log_2(10^10), soit 33 bits.
 
 De même, si l'acteur utilise le même mot de passe auprès de plusieurs vérificateurs, alors la sécurité du stockage de ce mot de passe est équivalente à la sécurité de la méthode de stockage la plus faible employée par l'un de ces vérificateurs. Si cette méthode de stockage est trop faible, alors le mot de passe peut être recouvré puis utilisé auprès d'un vérificateur ayant pourtant une bonne méthode de stockage ; c'est ce qu'on appelle le "bourrage" de mots de passe. Dans ce cas, peu importe la fonction de dérivation employée : le mot de passe peut être cassé en une seule tentative, puisque le mot de passe est en fait déjà connu.
 
-Pour freiner la recherche exhaustive, il convient d'utiliser une fonction de dérivation qui soit raisonnablement couteuse à calculer. Plus la fonction est couteuse, plus il faudra de temps pour retrouver le mot de passe à partir de sa dérivée. Il y a cependant un arbitrage à faire, car pour chaque tentative de vérification d'un mot de passe, le vérificateur devra utiliser cette fonction couteuse également. S'il y a peu d'utilisateurs, comme c'est le cas pour une authentification locale sur un poste de travail, cela ne présente pas un gros problème, mais sur un site web avec des millions d'utilisateurs et d'utilisatrices, le cout peut rapidement devenir prohibitif. 
+Pour freiner la recherche exhaustive, il convient d'utiliser une fonction de dérivation qui soit raisonnablement couteuse à calculer. Plus la fonction est couteuse, plus il faudra de temps pour retrouver le mot de passe à partir de sa dérivée. Il y a cependant un arbitrage à faire, car pour chaque tentative de vérification d'un mot de passe, le vérificateur devra utiliser cette fonction couteuse également. S'il y a peu d'utilisateurs, comme c'est le cas pour une authentification locale sur un poste de travail, cela ne présente pas un gros problème, mais sur un site web avec des millions d'utilisateurs et d'utilisatrices, le cout peut rapidement devenir prohibitif.
 
 Le précalcul est une attaque qui vise à précalculer un grand nombre de dérivées de mots de passe, et d'indexer efficacement le résultat de ces calculs. Cet index permet d'optimiser le temps nécessaire pour casser les mots de passe dont les dérivées auraient fuité. Plus besoin d'exécuter la fonction de dérivation pour chaque mot de passe à attaquer ! Il suffit de regarder si la dérivée est présente dans l'index, et si oui de regarder quel mot de passe lui correspond. Ces index sont appelés des tables arc-en-ciel (*rainbow tables*).
 
@@ -922,11 +922,11 @@ Il existe d'autres fonctions, moins efficaces que argon2id, qui peuvent être me
 
 L'utilisation d'un même moyen permettant de prouver son identité n'est pas recommandée. Les conséquences sont cependant assez diverses en fonction du moyen.
 
-La réutilisation d'un moyen dans le cadre d'un mécanisme d'authentification par divulgation a des conséquences catastrophiques si le canal de communication ou la sécurité logicielle du prouveur et du vérificateur sont insuffisamment protégés en confidentialité. En effet, l'attaquant ou l'attaquante pourra alors apprendre le secret et le réutiliser en l'état auprès d'un autre vérificateur. 
+La réutilisation d'un moyen dans le cadre d'un mécanisme d'authentification par divulgation a des conséquences catastrophiques si le canal de communication ou la sécurité logicielle du prouveur et du vérificateur sont insuffisamment protégés en confidentialité. En effet, l'attaquant ou l'attaquante pourra alors apprendre le secret et le réutiliser en l'état auprès d'un autre vérificateur.
 
 La réutilisation de mots de passe pose également des difficultés relatives au stockage par le vérificateur. Le stockage du mot de passe lui-même, en clair ou sous un format réversible, signifie que l'attaquant ou l'attaquante ayant accès à ce stockage peut apprendre le mot de passe et le réutiliser tel quel auprès d'autres vérificateurs. Même si le stockage ne contient que des dérivées des mots de passe, le risque reste réel si l'entropie de ces mots de passe est trop faible. En effet, ils pourront être retrouvés par recherche exhaustive, avec les mêmes conséquences que s'ils avaient été stockés en clair.
 
-Avec les mécanismes d'authentification utilisant la signature électronique, l'utilisation d'une même clé privée auprès de plusieurs vérificateurs présente également des risques. 
+Avec les mécanismes d'authentification utilisant la signature électronique, l'utilisation d'une même clé privée auprès de plusieurs vérificateurs présente également des risques.
 
 D'une part, il arrive que des erreurs d'implémentation permettent à un vérificateur malveillant d'exploiter une vulnérabilité dans le code du prouveur, menant à la divulgation de la clé privée utilisée pour prouver son identité [^cvessh].
 
@@ -1009,6 +1009,206 @@ sequenceDiagram
   end
 ```
 
+# Autorisation
+
+L'autorisation est le fait d'**accorder ou non**, à un **sujet** (c'est-à-dire un acteur, une organisation, ou un groupe), à l'issue d'un contrôle d'accès, les droits, permissions ou privilèges, lui permettant d'effectuer une **activité** sur un **objet** ou une **vue**.
+
+Derrière cette définition assez générique se cachent des réalités simples et intuitives, mais aussi des modèles de sécurité permettant l'application de politiques plus ou moins abstraites (modèles de Bell-Lapadula, Biba, Clark-Wilson, Multilevel Security (MLS)...). Ce chapitre détaillera ces différents modèles.
+
+## Étiquetage explicite ou intrinsèque
+
+Les sujets, actions et objets soumis à un système de contrôle d'accès ont besoin d'être identifiés de manière à pouvoir y faire référence lors de l'écriture de règles de contrôle d'accès.
+
+Pour les sujets, nous avons déjà discuté assez largement de la manière de les identifier dans ce cours.
+
+Pour ce qui est des objets, l'identification peut être effectuée de manière explicite, par l'ajout d'une étiquette (*label*). Cette étiquette peut décrire une identité individuelle pour cet objet. Néanmoins, la plupart du temps, il s'agit plutôt d'une identité d'appartenance à un groupe. Par exemple, il pourrait s'agir d'une étiquette "objets correspondant à des données bancaires" ou "objets contenant des données personnelles".
+
+L'étiquetage s'effectue généralement par l'ajout d'une métadonnée associée à l'objet. Sous Linux, cela s'effectue le plus souvent avec les attributs étendus[^xattr].
+
+[^xattr]: https://man7.org/linux/man-pages/man7/xattr.7.html
+
+L'étiquetage est le système le plus répandu d'identification des objets, mais il est également possible d'identifier un objet de manière intrinsèque, par exemple en fonction de son nom ou de sa localisation. Ce système est notamment utilisé par le Linux Security Module (LSM) AppArmor qui définit des politiques de sécurité sur des fichiers en fonction de leur chemin d'accès dans le système de fichiers. Un autre exemple est le contrôle d'accès sur un site web, en fonction de la section "chemin" d'une adresse réticulaire (URL Path).
+
+## Contrôle d'accès discrétionnaire (DAC)
+
+La plupart des personnes manipulant un ordinateur sont familières avec le contrôle d'accès discrétionnaire (DAC), même si la désignation leur est inconnue.
+
+Ce type de contrôle d'accès consiste à laisser la liberté au **propriétaire** d'un **objet** de déterminer les droits d'accès à ce dernier. C'est le modèle de contrôle d'accès par défaut sous Linux, avec les appels système `chown(2)` et `chmod(2)` qui permettent respectivement de changer le propriétaire d'un fichier et les droits (lecture, écriture, exécution) qui sont associés à l'utilisateur propriétaire, à un groupe d'utilisateurs, et aux autres utilisateurs.
+
+Ce contrôle d'accès est parfaitement adapté pour la gestion du contrôle d'accès à des données personnelles. Néanmoins, dans une entreprise, le contrat de travail contient quasi systématiquement une clause de cession des droits patrimoniaux de l'ensemble des productions du personnel. Pour le dire plus vulgairement, l'entreprise est la propriétaire des documents produits. Comme il n'est pas raisonnable d'attendre du chef ou de la cheffe d'entreprise de prendre toutes les décisions d'attribution des droits, des politiques de sécurité sont établies, qui s'appliquent ensuite de manière verticale sur l'ensemble des objets produits par le personnel de l'entreprise. L'étiquetage entre alors en jeu.
+
+## Contrôle d'accès obligatoire (MAC)
+
+Le contrôle d'accès obligatoire (*Mandatory Access Control*) a parfois été incorrectement appelé "contrôle d'accès mandataire" par les agents du gouvernement français, probablement pour des raisons de proximité phonétique avec "*mandatory*"...
+
+Ce type de contrôle d'accès consiste en l'établissement d'une politique de sécurité qui s'applique de manière verticale à l'ensemble des sujets, des actions et des objets d'un système d'information.
+
+Les politiques sont des descriptions abstraites des relations entre les sujets, les actions et les objets. Bien qu'elles puissent établir des règles à propos de sujets ou d'objets individuels spécifiques, elles portent plus généralement sur des étiquettes pouvant être associées à plusieurs sujets ou objets.
+
+### Les modèles théoriques
+
+#### Les modèles de MAC classiques
+
+La littérature contient de nombreuses variantes et approches au contrôle d'accès obligatoire. Certaines sont assez intuitives, par exemple en attribuant des **rôles** aux sujets (*Role-based Access Control* (RBAC)). D'autres approches utilisent des **attributs** arbitraires associés aux sujets, actions ou objets (*Attribute-based Access Control* (ABAC)), ou encore des informations contextuelles à propos du sujet (*Context-based Access Control* (CBAC)) : (heure d'accès, géolocalisation, capacités du terminal, force de l'authentification, etc...).
+
+#### OrBAC
+
+Certaines approches au contrôle d'accès obligatoires rajoutent des couches d'abstraction supplémentaires, en bâtissant sur ceux déjà cités. Par exemple, le modèle de **contrôle d'accès fondé sur l'organisation** (*Organization-based Access Control* (OrBAC)) repose sur les approches par rôles (RBAC), par actions (*Task-based Access Control* (TBAC)), par vues (*View-based Access Control* (VBAC)) et par équipes (*Team-based Access Control* (TBAC, à nouveau...)). Le modèle OrBAC abstrait le triplet "sujets, action, objets" en un nouveau triplet "**rôles**, **activités**, **vues**".
+
+Des règles de contrôle d'accès peuvent alors être écrites concernant ce nouveau triplet en faisant abstraction du contexte d'implémentation, c'est-à-dire de l'organisation (société, association, etc.) pour laquelle elles sont écrites. Cela permet ainsi de les écrire une fois pour toutes, pour un nombre arbitraire d'organisations qui y auront recours.
+
+Une couche de "traduction" spécifique à chaque organisation doit alors être utilisée pour transposer ces règles abstraites en des règles pragmatiques concernant des acteurs, les actions et les objets de chaque organisation.
+
+#### Sécurité multiniveau
+
+L'approche par sécurité multiniveau (*Multilevel Security* (MLS)) est assez ancienne. Elle est particulièrement appréciée dans les domaines militaires et gouvernementaux, du fait de la verticalité intrinsèque de cette approche.
+Néanmoins, cette approche a également ses mérites en dehors du domaine exécutif. Elle est, par exemple, intéressante pour la centralisation des données de santé (*monitoring*) et de journalisation d'un système d'information.
+
+Le principe général de la sécurité multiniveau est, en effet, d'établir une hiérarchie de niveaux d'autorisation. Les acteurs associés à un niveau sont alors autorisés à effectuer un jeu d'actions restreint avec les objets associés aux niveaux situés en dessous du niveau de l'acteur. Un autre jeu d'actions, généralement distinct et disjoint, est également autorisé pour cet acteur avec les objets associés aux niveaux situés au-dessus du niveau de l'acteur.
+
+Parmi les modèles de sécurité reposant sur la sécurité multiniveau, on peut notamment citer le modèle de Bell-Lapadula[^bl-model], le modèle Biba[^biba-model], ou encore celui de Clark-Wilson[^cw-model].
+
+[^bl-model]: https://websites.umich.edu/~cja/LPS12b/refs/belllapadula1.pdf
+[^biba-model]: https://www.researchgate.net/publication/235043659_Integrity_Considerations_for_Secure_Computer_Systems
+[^cw-model]: https://groups.csail.mit.edu/ana/Publications/PubPDFs/A%20Comparison%20of%20Commercial%20and%20Military%20Computer%20Security%20Policies.pdf
+
+##### Le modèle Bell-Lapadula
+
+Le modèle Bell-Lapadula utilise la sécurité multiniveau à des fins de confidentialité. Le principe général est qu'un acteur situé à un certain niveau de sécurité ne peut qu'écrire aux niveaux supérieurs et ne peut que lire aux niveaux inférieurs. En anglais, on parle d'une approche "*Write Up, Read Down* (WURD)". Avec cette approche, les acteurs de la hiérarchie peuvent concentrer les informations confidentielles, sans qu'aucune information notamment agrégée ne puisse redescendre.
+
+Ce modèle est implémenté dans Linux à l'aide de SElinux (*Security-Enhanced Linux*), qui dispose d'une fonctionnalité multiniveau grâce aux étiquettes de niveaux de sensibilité.
+
+##### Le modèle Biba
+
+Le modèle Biba utilise la sécurité multiniveau à des fins d'intégrité. Le principe général est comparable à celui de Bell-Lapadula, bien qu'il soit en quelque sorte inversé. Avec le modèle Biba, il n'y pas d'écriture aux niveaux supérieurs, et pas de lecture aux niveaux inférieurs. Ainsi, les niveaux les plus privilégiés sont protégés de toute interférence ou corruption de la part des niveaux inférieurs. En anglais, on parle d'une approche "*Read Up, Write Down* (RUWD)".
+
+Ce modèle peut être adroitement utilisé conjointement avec le modèle de Bell-Lapadula afin d'agréger des données confidentielles au niveau du commandement, et permettre ensuite au commandement de faire redescendre des ordres qui sont fonction de ces données agrégées.
+
+##### Le module de Clark-Wilson
+
+Le modèle de Clark-Wilson s'intéresse également à l'intégrité. Son approche est plus dynamique et modélise le triplet "sujet,programme, objets". Ce triplet signifie que les sujets ne peuvent manipuler les objets que par des programmes spécifiques. Ceci est plus restrictif que dans les autres modèles où le contrôle d'accès s'effectue en fonction de l'acteur, sans tenir compte de comment il y accède.
+
+Ce modèle est notamment implémentable sous Linux grâce aux politiques de contrôles des types (*type enforcement* (TE)) de SElinux.
+Le *type enforcement* permet d'associer notamment à chaque utilisateur système ou rôle (ce qui est une autre notion de SElinux), à chaque programme exécutable, à chaque fichier, à chaque **socket** un type. Une politique TE régit ensuite les interactions entre les types (écriture, lecture, exécution, modification des métadonnées, etc.), ainsi que les transitions entre les types : tel utilisateur de type W peut exécuter un programme de type X, ce qui lui permet de lire les fichiers de type Y et d'écrire les fichiers de type Z.
+
+#### Modèle de Brewer et Nash ou de la muraille de Chine
+
+Le modèle de Brewer et Nash consiste à appliquer une politique de sécurité permettant de prévenir les conflits d'intérêts, notamment en matière commerciale. Dans ce modèle, le contrôle d'accès est dynamique ; par défaut l'acteur a virtuellement accès à toutes les données. Néanmoins, en fonction des données auxquelles il accède, il se voit au fur et à mesure restreindre l'accès à d'autres données. Par exemple, si les sociétés A et B sont concurrentes, accéder aux données de la société A fait que l'on perdra automatiquement les accès aux données de la société B.
+
+Un exemple d'implémentation de ce modèle est l'outil StemJail[^stemjail] pour Linux, développé par Mickaël Salaün (ANSSI), avec Marion Daubignard (ANSSI) et sous la coulpe d'Hérvé Debar (SudParis Télécom), dans le cadre de la thèse de doctorat de Mickaël.
+
+[^stemjail]: https://stemjail.github.io/
+
+### Des rôles et des groupes
+
+Avec l'approche *Role-based Access Control* (RBAC), des rôles sont attribués à des sujets. Comme vu précédemment dans ce cours, le terme de sujet recouvre plusieurs réalités : des acteurs mais aussi des groupes d'acteurs. Or, dans certaines définitions de ce que sont les rôles, il est retenu que les rôles sont des groupes d'acteurs et de permissions, tandis que d'autres définitions retiennent que les rôles sont des collections de permissions[^groupsvsroles]. Ainsi, certaines implémentations considérant que les rôles sont des groupes d'acteurs et de permissions n'implémentent pas du tout la notion de groupes d'acteurs (sans permissions), considérant celle-ci redondante avec celle des rôles. Pour rajouter un peu de confusion, certaines implémentations ne nomment pas les rôles "rôles" mais "groupes" (e.g. Gitlab) ou "équipes" (e.g. Gitea/Forgejo).
+
+[^groupsvsroles]: https://profsandhu.com/workshop/role-group.pdf
+
+D'une manière générale, il est fortement déconseillé d'attribuer des permissions à des acteurs de façon nominative, à moins qu'il ne soit possible de placer un commentaire explicite à côté de ces permissions accordées nominativement, afin de justifier leur attribution.
+
+Prenons l'exemple d'un personnel d'entreprise, inspiré d'un cas réel : au cours de sa vie professionnelle au sein de cette entreprise, ce personnel intègre une équipe de développement et obtient les permissions nécessaires à l'accomplissement de son affectation. Plus tard, ce même personnel réoriente sa carrière et devient ingénieur avant-vente, et se voit attribuer en conséquence de nouvelles permissions pour l'accomplissement de sa nouvelle affectation. Finalement, ce personnel bascule totalement dans l'équipe commerciale, et obtient encore de nouvelles permissions. Comme prévu dans la politique de sécurité de la société, les permissions sont auditées annuellement, afin de s'assurer que personne ne détient des permissions indues. Lorsque la personne en charge de l'audit vérifiera les permissions de ce personnel, il lui sera très difficile de s'assurer de la légitimité de chaque permission unitaire sans investigation. Si les permissions avaient été accordées en fonction de l'appartenance ou non à un groupe d'acteurs, il suffirait de contrôler la pertinence de l'appartenance aux groupes des développeurs, des avant-ventes et des commerciaux.
+
+En conséquence, même lorsque la notion de rôles est celle de groupes d'acteurs et de permissions, il est fortement conseillé de créer des rôles composés uniquement d'acteurs et de rôles composés exclusivement de permissions et de créer une hiérarchie entre ces rôles, de façon à ce que les rôles "groupes" héritent des permissions des rôles "permissions".
+
+## OAuth2, OpenID Connect et assertions de sécurité
+
+Les protocoles OAuth2 et OpenID Connect sont détaillés dans cette section en préparation du TP compagnon de ce cours. Il existe d'autres protocoles d'autorisation, comme Kerberos ou SAML, qui ne seront pas abordés dans ce cours, mais qui offrent des propriétés de sécurité intéressantes ou comparables.
+
+### OAuth2
+
+OAuth2 est un protocole standard d'autorisation, extensible, principalement utilisé dans le contexte web. Une partie de sa spécification, ce qui est appelé le "cadriciel OAuth2" (*framework*), repose dans la RFC 6749[^RFC6749]. Cette RFC est également completée par les RFC 6750[^RFC6750] et 8252[^RFC8252]. Le principe général d'OAuth2 repose sur un protocole impliquant quatre participants :
+
+* une personne propriétaire d'une ressource (en anglais "*resource owner*");
+* un serveur de ressources (en anglais "*resource server*");
+* une tierce partie souhaitant obtenir accès à cette ressource ; il s'agit généralement d'une application (en anglais "*client*" ou "*relying party*");
+* un serveur d'autorisation (en anglais "*authorization server*).
+
+[^RFC6749]: https://www.rfc-editor.org/rfc/rfc6749.html
+[^RFC6750]: https://www.rfc-editor.org/rfc/rfc6750.html
+[^RFC8252]: https://www.rfc-editor.org/rfc/rfc8252.html
+
+
+```mermaid
+---
+title: Représentation simplifiée des interactions entre les parties du protocole OAuth2
+---
+sequenceDiagram
+  autonumber
+  actor p as Propriétaire
+  actor a as Serveur d'autorisation
+  actor r as Serveur de ressources
+  actor c as Client
+
+  c ->> r:"Je souhaite accéder à la ressource X."
+  r ->> c:"Il faut un jeton d'accès. Va voir le serveur d'autorisation."
+  c ->> a:"J'aurais besoin d'un jeton d'accès pour la ressource X. Je redirige le propriétaire vers toi."
+  a ->> p:"T'es qui ?"
+  p ->> a:"Je suis Peggy, et en voici la preuve."
+  a ->> a:Vérifie la preuve.
+  a ->> p:"OK, Peggy. J'ai ce Client qui voudrait accéder à X dont tu es propriétaire. T'en penses quoi ?"
+  p ->> a:"OK pour donner accès à Client à la ressource X."
+  a ->> c:"OK, voici un jeton d'accès pour X."
+  c ->> r:"Je souhaite accéder à la ressource X. Voici le jeton d'accès."
+  r ->> r:Vérifie le jeton d'accès.
+  alt Le jeton d'accès est valide
+    r ->> c:"Voici la ressource X."
+  else Le jeton d'accès est invalide, forgé ou expiré
+    r ->> c:"Accès refusé."
+  end
+```
+
+Le serveur de ressources et le serveur d'autorisation ont établi une relation de confiance au préalable. Cette relation de confiance permet au serveur de ressources de reconnaitre et vérifier des jetons d'accès émis par le serveur d'autorisation.
+
+De même, la personne propriétaire d'une ressource a préalablement établi une relation de confiance avec le serveur d'autorisation ; elle est notamment capable de lui prouver son identité, d'une part, et de le convaincre qu'elle est propriétaire d'une certaine donnée, d'autre part.
+
+Finalement, la tierce partie et le serveur d'autorisation ont également préalablement établi une relation de confiance qui permet à la tierce partie de prouver son identité au serveur d'autorisation.
+
+Ainsi, lorsque la tierce partie manifeste le besoin d'accéder à la ressource, elle sollicite le serveur d'autorisation pour obtenir un jeton d'accès et s'authentifie auprès de lui. Après avoir vérifié l'identité de la personne propriétaire de la ressource, le serveur d'autorisation lui demande l'accord pour délivrer un jeton d'accès à cette ressource pour cette tierce partie spécifique. En cas d'accord, un jeton est délivré. La tierce partie peut alors contacter le serveur de ressources et présenter le jeton d'accès. Le serveur de ressources vérifie le jeton d'accès, et s'il est valide, donne accès à la ressource.
+
+Ce protocole permet de délivrer des autorisations d'accès à des ressources protégées, avec une granularité réglable, sans révéler à la tierce partie l'identité ou les moyens d'identification (les "authentifiants") du propriétaire de la ressource. De surcroit, ce protocole permet de délivrer à la tierce partie des jetons d'accès à usage restreint : ils sont incessibles et potentiellement limités dans le temps.
+
+Une critique récurrente qui peut être adressée contre le cadriciel d'OAuth2 est la multitude de ces modes opératoires, certains étant par essence d'une sécurité relativement douteuse. C'est notamment le cas du mode implicite, ou lorsque sont utilisés des clients "publics". Ce cours ne rentrera pas plus avant dans ces considérations, mais de plus amples informations peuvent être trouvées dans la RFC de référence, à la section "Considérations de sécurité".
+
+Une utilisation "abusive" ou "détournée" du protocole d'OAuth2 est souvent constatée pour l'authentification décentralisée. Dans ce contexte d'usage, le serveur de ressources et le serveur d'autorisation sont la même entité. Lorsqu'une personne veut s'authentifier auprès d'une application tierce, elle demande à cette application de demander une autorisation d'accès au serveur d'autorisation. Le serveur d'autorisation demande à cette personne de s'authentifier, puis renvoie à la tierce partie un jeton d'accès pour une ressource quelconque contenant une information identifiant la personne qui s'est authentifiée. Si la tierce partie est en mesure d'obtenir cette ressource grâce au jeton d'accès, alors elle peut déduire que la personne a été capable de prouver son identité au serveur d'autorisation.
+
+Cette utilisation abusive a été normalisée par une extension au protocole OAuth2 : OpenID Connect.
+
+### OpenID Connect
+
+OpenID Connect (OIDC)[^oidc] est une extension au protocole OAuth2. Elle rajoute notamment une couche d'identité, qui permet de normaliser la communication de l'identité d'une personne connue du serveur OIDC à la tierce partie (appelée en anglais *relying party*), et de fournir également des informations complémentaires à son sujet. Ces informations sont appelées des assertions (*claims*), qui peuvent être de nature arbitraire, tant qu'elles sont exprimables dans le format JWT (*JSON Web Token*)[^jwt].
+
+[^oidc]: https://openid.net/developers/specs/
+[^jwt]: https://www.rfc-editor.org/rfc/rfc7519.html
+
+Le principe général d'OAuth 2 est appliqué avec OpenID Connect. La différence majeure est que le serveur d'autorisation est également le serveur de ressources, et que la ressource consultée est un document appelé "*ID Token*", contenant des assertions relatives à la personne s'étant authentifiée au serveur d'autorisation.
+
+Le document *ID Token* contient diverses assertions requises ou optionnelles. Les assertions requises sont :
+
+* `iss` : "issuer" : l'identifiant de l'émetteur de cet ID Token ;
+* `sub` : "subject" : l'identifiant de la personne cherchant à prouver son identité à la tierce partie ;
+* `aud` : "audience" : l'identifiant de la tierce partie ;
+* `exp` : "expiry date" : la date d'expiration de cet ID Token ;
+* `iat` : "issued at" : la date d'émission de cet ID Token.
+
+Les assertions suivantes sont parfois requises, parfois optionnelles :
+
+* `auth_time` : "authentication time" : heure de la dernière authentification réussie de la personne cherchant à prouver son identité à la tierce partie auprès du serveur OpenID Connect. Cette assertion est requise si l'application tierce a explicitement exprimé le besoin d'en connaitre à propos cette information.
+* `nonce` : une valeur arbitraire ajoutée à l'ID Token à la demande de la tierce application, en vue de contrer des attaques par rejeu éventuelles.
+
+Les serveurs OpenID Connect peuvent être généralement configurés pour ajouter des assertions additionnelles arbitraires. Certaines peuvent ainsi spécifier les groupes auxquels appartient le sujet de l'ID Token ou les rôles dont il disposerait.
+
+### User-managed Access
+
+User-managed Access (UMA) est une autre extension au protocole OAuth2. Spécifiée par la Kantara Initiative[^umaspec], elle permet au propriétaire d'une ressource d'établir à l'avance des règles régissant l'émission de jetons d'accès à cette ressource.
+L'application tierce sera alors autonome pour obtenir des jetons d'accès à cette ressource sous réserve de satisfaction des règles édictées par le propriétaire et sans interaction explicite avec ce dernier.
+
+[^umaspec]: https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html
+
+Cette extension permet notamment la création d'un référentiel central d'autorisation, seule source de vérité des autorisations d'accès sur l'ensemble des ressources d'un système d'information.
+
+Hélas, s'il y a bon nombre de fournisseurs de service pour le protocole UMA, son adoption par les applications tierces est encore modeste.
+
 # Remerciements
 
 Je tiens à remercier mes relecteurs et relectrices pour leurs contributions à ce cours. Un merci tout spécial à [@karl@infosec.exchange](https://infosec.exchange/@karl) et [@bortzmeyer@mastodon.gougere.fr](https://mastodon.gougere.fr/@bortzmeyer) pour leurs suggestions d'amélioration nombreuses et détaillées.