4.4.1 – Présentation & Objectifs
Le règlement européen « eIDAS » n°910/2014 du 23 juillet 2014 a pour ambition d'accroître la confiance dans les transactions électroniques au sein du marché intérieur. Il établit un socle commun pour les interactions électroniques sécurisées entre les citoyens, les entreprises et les autorités publiques.
Il concerne principalement les organismes du secteur public et les prestataires de services de confiance établis sur le territoire de l’Union européenne. Il instaure un cadre européen en matière d’identification électronique et de services de confiance, afin de faciliter l’émergence du marché unique numérique.
Pour ce faire, le règlement formule des exigences relatives à la reconnaissance mutuelle des moyens d’identification électronique ainsi qu’à celle des signatures électroniques, pour les échanges entre les organismes du secteur public et les usagers.
Afin de pouvoir bénéficier de cette reconnaissance mutuelle, un moyen d’identification électronique doit :
• Avoir été délivré conformément à un schéma d’identification électronique notifié par l’Etat membre concerné et figurant sur la liste publiée par la Commission. Un schéma d’identification électronique est un système pour l’identification électronique en vertu duquel des moyens d’identification électronique peuvent être délivrés à des personnes physiques ou morales.
• Avoir un niveau de garantie égal ou supérieur à celui requis par l’organisme du secteur public concerné pour accéder à ce service en ligne, à condition que ce niveau soit substantiel ou élevé.
Les exigences applicables aux différents niveaux de garantie qui sont prévus par le règlement sont détaillées dans le règlement d’exécution n°2015/1502 du 8 septembre 2015. D’après le règlement (« CELEX_32015R1502_FR_TXT.pdf », s. d.), ces niveaux sont accordés en fonction du respect de spécifications, normes et procédures minimales. Il définit trois niveaux de garantie :
• Faible : l’objectif est simplement de réduire le risque d’utilisation abusive ou d’altération d’identité
• Substantiel : l’objectif est de réduire substantiellement le risque d’utilisation abusive ou d’altération d’identité
• Élevé : l’objectif est d’empêcher l’utilisation abusive ou l’altération de l’identité
4.4.2 – Niveaux d’authentification
J’aborderai dans ce chapitre uniquement les conditions relatives aux personnes physiques et les moyens d’identification utilisables sur un SI.
Trois pré-requis sont indispensables avant de pouvoir générer et délivrer un moyen d’identification électronique. Il faut s'assurer que le demandeur soit informé des conditions associées à l'utilisation du moyen d'identification électronique, des précautions de sécurité recommandées relatives à ce moyen et recueillir les données d'identité pertinentes requises pour la preuve et la vérification de son identité.
Les différents niveaux eIDAS exigent des éléments nécessaires à la preuve et à la vérification de l’identité. Pour atteindre le niveau :
• eidas1 : niveau faible (exemple : authentification par identifiant / mot de passe) La personne peut être présumée en possession d'un élément d'identification • eidas2 : niveau substantiel (exemple : authentification à double facteur)
Doit être de niveau faible et il a été vérifié que la personne est en possession d'un second élément d'identification. Celui-ci doit être unique, faire l'objet d'une vérification visant à déterminer son authenticité et uniquement délivré à son propriétaire. Celui-ci repose sur le principe d'une authentification dynamique : OTP, challenge et réponse correspondante.
L’authentification avec second facteur peut, en fonction du type, être qualifiée de niveau substantiel ou fort. Il est nécessaire pour cela de prendre en compte la notion de non-répudiation
• eidas3 : niveau fort (exemple : utilisation de certificats ou de cartes à puce qui sont également un second facteur mais dont le mot de passe ne circule pas)
Doit être de niveau substantiel et soit :
1. il a été vérifié que la personne est en possession d'un élément d'identification biométrique ou photographique et le demandeur est identifié comme ayant l'identité alléguée par comparaison d'une ou de plusieurs caractéristiques physiques de la personne auprès d'une source faisant autorité
ou
2. lorsque des moyens d'identification électronique sont délivrés sur la base d'un moyen d'identification électronique notifié valide ayant le niveau de garantie élevé et des mesures sont prises pour prouver que les résultats de cette précédente procédure de délivrance d'un moyen d'identification électronique notifié demeurent valides (IGC, PKI).
5 – Synthèse
Dans cette première partie, j’ai introduit les notions d’authentification et les niveaux normalisés eIDAS. Pour ce faire, j’ai présenté les enjeux liés à l’authentification unique, comparé deux solutions SSO complètes AAA puis rappelé quelques principes de base.
Depuis maintenant une quinzaine d’années, la Gendarmerie nationale a mis un place un système d’authentification unique pour permettre à ses personnels d’accéder de façon sécurisée aux nombreuses ressources (applications, fichiers ou services, Internet) disponibles sur son Système d’Information mais également de maîtriser et contrôler les actions des utilisateurs, de manière à assurer une traçabilité permettant d'imputer des actions à leurs auteurs. Cette démarche s’inscrit dans un cadre très strict en termes de contraintes légales, de performances et de limitation des coûts.
Pour ce faire, la Gendarmerie Nationale a choisi de déployer LemonLDAP::NG puis a été imitée par beaucoup d’autres ministères ou administrations. LemonLDAP::NG est devenu le produit SSO AAA prédominant au sein de l’état français.
B – LemonLDAP::NG
Figure 7 : Logo LemonLDAP::NG
Au 15 septembre 2018, la dernière version stable de LemonLDAP::NG est la 1.9.17. La version 2.0.0, prévue pour le second semestre 2018, est actuellement en cours de finalisation et disponible en version « bêta2 » pour tests. Il est important de préciser qu’entre la 1.9.17 et la 2.0.0, le Portail et une partie du Manager ont été réécrits ainsi que les différents agents logiciels.
N’ayant travaillé que sur LLNG 2.0, la suite de ce mémoire sera consacrée uniquement à cette version sauf cas particuliers explicitement précisés.