5IDEN Jour 3 Part 1 Notes sur l’authentification: Radius, SSO, AD et sécurité réseau (FR)
Aperçu des types d'authentification et les acteurs de l'IAM
Dans cette séance, on fait le tour des différents types d’authentification que l’on peut rencontrer autour d’un système IAM et des liens entre applications métier, fournisseurs d’identité et infrastructure réseau. On parle d’un « provider » ou d’un fournisseur d’identité qui sert de point d’authentification pour un client, avec des exemples comme GLPI, Nextcloud, Moodle, etc. L’idée générale est de comprendre pourquoi certains systèmes utilisent un Active Directory (AD) ou, au contraire, nécessitent l’installation d’un client/driver spécifique pour s’intégrer à plusieurs applications métier (par exemple via Radius, LDAP ou un autre protocole fédérateur). On constate aussi que les protocoles et les droits diffèrent d’une application à l’autre, ce qui peut pousser à déployer des clients d’intégration pour fédérer les identités. Le discours insiste sur le fait que l’objectif est d’optimiser l’application et d’éviter des configurations lourdes lorsque ce n’est pas nécessaire, tout en assurant une compatibilité et une sécurité suffisantes pour l’écosystème. On introduit aussi l’idée que Radius peut jouer le rôle d’un mandataire qui intègre à la fois les équipements réseau et les services d’authentification, et que l’authentification triple A (AAA) se déploie fréquemment dans ces contextes réseau et métier.
Le rôle de Radius et la notion AAA
Radius est présenté comme un « mandataire » qui va faire l’authentification à votre place, en se plaçant entre les postes/client et les ressources d’authentification (AD, IAM, etc.). On rappelle le concept AAA : Authentication, Authorization, Accounting. Autrement dit, Radius permet d’authentifier l’utilisateur ou la machine, d’autoriser l’accès à des ressources et d’enregistrer les événements d’accès pour la traçabilité et l’audit. Dans le cadre des réseaux, Radius est largement associé à l’AS 802.1X pour sécuriser l’accès au réseau sans fil et filaire. On évoque l’idée que les protocoles peuvent différer selon l’application métier et que, pour une même infrastructure, il peut être nécessaire d’ajouter un client Radius afin d’intégrer plusieurs systèmes en un seul point d’authentification.
802.1X, réseau et authentification AAA
L’échange autour de Radius est étroitement lié à l’authentification sur le réseau (802.1X). On demande ce que signifie Radius en un mot, et l’explication donnée le décrit comme un « mandataire qui va faire l’authentification à votre place ». On rappelle que l’authentification triple A peut être mise en œuvre via Radius dans des environnements Wi‑Fi ou câblés, avec des EAP (Extensible Authentication Protocol) tels que EAP-TLS ou PEAP, qui utilisent Radius comme serveur d’authentification. On discute aussi du fait que certains environnements, comme Amazon ou une autre plateforme, n’imposent pas nécessairement AD pour l’accès réseau, parce que le protocole ou le mécanisme fédéré suffit à garantir l’accès et les droits selon le contexte métier.
Modèle en couches et architecture réseau
Le cours rappelle le modèle en couches (OSI) et précise ce que cela implique pour l’authentification réseau. Le réseau sans fil (borne Wi‑Fi) se situe à la couche liaison du modèle OSI et, en s’appuyant sur Radius et 802.1X, permet de faire l’authentification directement au point d’accès. Le routeur et le switch jouent un rôle dans le routage et le passage du trafic, mais l’accès à la ressource métier se fait par l’intermédiaire d’un système d’authentification central (AD ou IAM fédéré). L’authentificationTripleA et le cadre réseau permettent de gérer la sécurité du périmètre, y compris les ports, les certificats et les certificats de machine dans le cadre des machines utilisées par des intervenants externes, afin d’éviter d’exposer des postes non contrôlés à l’environnement métier.
Scénarios d’accès des intervenants et sécurisation du réseau invité
Un cas pratique discuté est celui de l’intervenant qui veut se connecter au réseau, avec un réseau invité et sans contrôle direct sur la machine de l’intervenant. Plusieurs options sont envisagées pour sécuriser ce scenario :
Utiliser une machine distante dédiée pour accéder au réseau invité et déployer une authentification qui passe par Radius, avec des choix de protocole adaptés (AD, IAM, Radius, MFA). Cela évite d’intégrer directement le poste de l’intervenant au domaine.
Utiliser une authentification forte basée sur des certificats (MFA avec Radius) afin d’approuver la machine et de sécuriser l’accès au réseau, tout en maintenant une séparation entre l’ordinateur d’intervention et le réseau métier.
Imaginer une solution basée sur Kerberos et l’interaction avec l’Active Directory pour les tickets, mais en pratique, les appareils réseau ne dialoguent pas directement avec AD/Kerberos. Radius apporte une couche de sécurité et d’orchestration entre les postes et les équipements réseau.
On peut aussi envisager l’authentification via une machine distante qui se connecte au réseau invité et où l’authentification pour accéder à l’application métier dépend d’un ensemble d’éléments (Radius, AD, IAM, MFA, etc.). L’objectif est d’éviter d’exposer des postes non contrôlés et de limiter les risques lorsque les intervenants se connectent.
SSO, protocoles, et tokens
Le sujet du SSO (Single Sign-On) est introduit comme une fonctionnalité clé pour fluidifier les accès. Le SSO s’appuie sur des tokens générés par un IdP (fournisseur d’identité) et consommés par les applications métier (SP). Le mécanisme typique est le suivant : une première connexion conduit à la délivrance d’un token (ou d’un cookie) qui permet d’accéder ensuite à plusieurs ressources sans relogin. Dans l’exemple, on évoque des sources variées : Kerberos pour les tickets Windows, et des protocoles modernes comme OpenID Connect (OIDC) et OAuth2 pour les applications web, ainsi que SAML pour certaines Applications anciennes. On illustre ce flux par le scénario d’un utilisateur qui se connecte à Windows, obtient un ticket, et peut ensuite accéder aux applications via l’IdP et le serveur IAM, qui vérifie les droits (autorisation) et les politiques d’accès. Le ticket Windows et le token IdP jouent un rôle central dans le SSO : si le cookie/token est présent et encore valable, l’accès est fluide; sinon, il faut réauthentifier.
OpenID Connect, OAuth2 et SAML : les différentes familles de protocoles
Plusieurs familles de protocoles sont évoquées pour le SSO et l’authentification :
OAuth2 et OpenID Connect (OIDC) : l’OIDC ajoute une identité à OAuth2 et délivre un ID token qui permet d’identifier l’utilisateur auprès des applications. Le flux typique implique l’IdP qui émet des tokens et les applications qui les valident pour accorder l’accès.
SAML : une autre approche d’échange d’assertions d’authentification entre IdP et SP, plus courante dans des environnements d’entreprise plus anciens.
JWT (JSON Web Token) : le token fréquent dans les architectures modernes OAuth2/OIDC est souvent un JWT, structuré typiquement en trois parties séparées par des points : , avec le header et le payload encodés en base64 et signés pour garantir l’intégrité.
Certificats, PKI et authentification forte
La discussion aborde les certificats comme élément clé de l’authentification forte. En particulier, on peut utiliser des certificats pour approuver une machine, ce qui introduit une authentification mutuelle (certificat du client et du serveur) et renforce la sécurité par rapport à une simple authentification par mot de passe. Le certificat peut venir d’une PKI interne (ou d’un fournisseur comme une extension de l’écosystème IAM). L’idée est de disposer d’un certificat émis par une autorité reconnue (par exemple maîtrisée par l’infrastructure, ou liée à une solution comme Keycloak dans le cadre de l’authentification forte). On mentionne aussi que certaines solutions permettent d’associer MFA et certificats dans Radius, ce qui constitue une « authentification forte » plus robuste que l’AD seul.
MFAs, tokens et authentification machine-to-machine
Le rôle du MFA est souligné comme complémentaire à Radius : on peut activer des facteurs supplémentaires lors de l’authentification ou lors de l’accès à certaines ressources. L’usage du MFA peut être lié à des certificats ou à des mécanismes à facteurs (par exemple une application qui renforce l’authentification lorsque l’événement se produit, ou lorsque la machine accède à l’application métier). Dans ce cadre, on distingue l’authentification faible (mot de passe seul) vs authentification forte avec certificat ou dispositifs MFA, et on montre l’intérêt d’utiliser Radius pour introduire ce niveau supplémentaire de contrôle et de sécurité, notamment pour les accès réseau et les postes distants.
SSO, tokens, et responsabilités des IdP et des Applications
Le flux global du SSO repose sur un IdP qui émet des tokens et sur des applications qui les consomment. L’IdP vérifie les droits (Rôles, Gruppen, politiques) et délivre les tokens (par exemple JWT ou assertion SAML). L’application métier vérifie le token et, si les droits le permettent, autorise l’accès. Cette orchestration peut être réalisée via des technologies comme Kerberos (tickets Windows) et des protocoles modernes (OIDC, OAuth2, SAML). Dans certains cas, Moodle ou d’autres applications peuvent s’appuyer sur l’authentification Microsoft (via OAuth2/OIDC) pour s’intégrer au système global, et certaines plateformes peuvent déployer des tokens fournis par Microsoft ou d’autres IdP selon le cas d’utilisation.
Problèmes pratiques et implications techniques
Plusieurs points pratiques et techniques émergent au cours de la séance :
La DNS peut devenir un goulot d’étranglement ou une source de défaillances lorsque l’authentification et les redirections SSO dépendent de noms de domaine publics ou privés et de l’acheminement réseau. Des difficultés de DNS provoquent des échecs d’authentification ou des difficultés d’accès à certains services (par exemple GitHub, Moodle, AWS ou d’autres applications) lorsque le flux d’authentification traverse des domaines ou des services externes.
Le déploiement d’un SSO peut nécessiter un « centralisateur » (IdP unique) et la compatibilité des applications avec les protocoles disponibles. Certaines applications utilisent OpenID Connect via Microsoft, d’autres utilisent SAML ou OAuth2, et il faut parfois gérer des environnements hétérogènes (Moodle, GitHub, AWS, Microsoft 365, etc.).
Le passage de HTTP à HTTPS (port 80 à 443) peut provoquer des pertes d’accès si les certificats ou les configurations TLS ne sont pas harmonisés, et il faut veiller à la sécurité des API et des endpoints (par exemple, les appels d’API d’authentification). Un cas évoqué est le passage à HTTPS qui peut casser un accès s’il n’est pas correctement déployé.
Enfin, la mise en place d’un reverse proxy (par exemple, Caddy ou d’autres solutions) peut faciliter la gestion des certificats et des flux SSO en centralisant la terminaison TLS et les redirections d’API, tout en supportant des scénarios multi-domaines et multi-protocole.
Liens entre les sujets et implications éthiques et pratiques
Les choix d’authentification impliquent des compromis entre sécurité et simplicité d’accès. Déployer Radius et des MFA augmente la sécurité du réseau et des postes distants, mais introduit une couche supplémentaire d’infrastructure à maintenir, des dépendances vis-à-vis d’un IdP et des risques de verrouillage (vendor lock-in) si l’écosystème est fortement fédéré. L’usage du SSO apporte une expérience utilisateur fluide et peut réduire le nombre de mots de passe à gérer, mais accroît la dépendance à l’IdP et nécessite des mécanismes solides de gestion des sessions, des jetons et des politiques d’authentification. Sur le plan technique, la sécurité repose sur la bonne gestion des certificats, des clés, des tokens et des politiques MFA, ainsi que sur une architecture réseau qui isole les invités et protège les ressources internes.
Synthèse des points clés et notions à retenir
Radius agit comme mandataire d’authentification entre les postes et les ressources réseau/métier et est central dans les déploiables AAA pour le réseau et l’accès wifi.
L’authentification triple A (AAA) est une colonne vertébrale des contrôles d’accès réseau et des services d’authentification centralisés.
Les environnements industriels et les applications métier peuvent nécessiter des clients d’intégration spécifiques (LDAP/AD, Radius, etc.) pour fédérer les identités et les autorisations.
Le SSO repose sur des tokens délivrés par un IdP et exploite des protocoles comme OAuth2, OpenID Connect et SAML, ou des tickets Kerberos dans les environnements Windows.
L’authentification forte avec certificats (MFA par PKI) peut être intégrée via Radius, ajoutant une couche de sécurité supplémentaire par rapport à une authentification par mot de passe seule.
Les questions d’infrastructure (DNS, DNS publiques/privés, TLS/HTTPS, ports) et les choix d’architecture (réseau invité vs réseau d’entreprise) ont un impact direct sur le comportement et la sécurité des flux d’authentification.
Des scénarios pratiques existent pour les intervenants externes: privilégier une machine distante et une authentification contrôlée via Radius et certificats plutôt que d’intégrer directement le poste de l’intervention au domaine, afin de limiter les risques.
Formules et notations utiles (avec LaTeX)
Définition AAA:
JWT typique (token d’accès/ID token utilisé dans OAuth2/OIDC):
Flux SSO (idée générale):
Structure d’un token OpenID Connect (ID Token) et un Access Token, selon le flux choisi (authorization code ou implicit) – principe: token émis par l’IdP et consommé par l’application.
Authentification mutuelle TLS (certificat client/serveur) et PKI associée: gère la vérification de la machine et du service via des certificats X.509.
Remarques finales et connexion avec les cours précédents
Ce contenu se relie directement à des notions vues en cours sur Active Directory, LDAP, Kerberos, et les fondements des protocoles d’authentification modernes (OAuth2/OIDC/SAML), ainsi qu’au modèle OSI et à l’architecture réseau (802.1X, équipements réseau, VLANs, zones DMZ). Il illustre comment les choix d’authentification influent sur la sécurité et la praticité opérationnelle dans un environnement réel et met en lumière les compromis entre sécurité renforcée (Radius, MFA, certificats) et complexité de gestion.
Conclusion pratique
En résumé, comprendre l’interaction entre AD/LDAP, Radius, SSO (OIDC/OAuth2, SAML) et les mécanismes de certificats permet de concevoir une architecture d’authentification cohérente, sécurisée et adaptée aux scénarios réels (utilisateurs internes, intervenants externes, accès réseau invité). Le choix des protocoles et des outils doit être guidé par les besoins métiers, la gestion des identités, les modèles de risque et les contraintes opérationnelles telles que le DNS, le TLS et la maintenance des certificats.