une traduction de standards, comme cela était le cas avec TLS et EAP-TLS. Cela est dû au rôle tenu par le serveur RADIUS, explicité ci-dessous. Dans la suite de ce rapport, nous désignerons ce proxy par l’appellation plus générale de « serveur frontal ».
Ainsi, la partie dédiée au traitement du protocole RADIUS doit en réalité accomplir les tâches suivantes, que nous décrivons d’abord de manière synthétique :
- Envoi et réception des paquets RADIUS via des sockets UDP[91] ouverts pour communiquer avec le NAS.
- Vérification de la signature des paquets RADIUS émis par le NAS.
- Gestion de l’encapsulation du protocole RADIUS en vue des échanges avec les cartes EAP- TLS.
- Génération et traitement des APDUs échangées avec les cartes EAP-TLS par l’intermédiaire de sockets TCP.
112
Comme nous l’avons souligné, la connexion simultanée à plusieurs cartes de la grille n’a été possible que par simulation via OpenSSL, qui impose la présence du NAS. Un poste client usuel peut traiter convenablement jusqu’à 30 ou 35 ouvertures de connexions TLS simultanées. Au-delà de ce nombre, la puissance de calcul de l’ordinateur fait défaut et nuit à la précision des résultats obtenus. Afin d’alléger la charge d’un poste, il est également possible de répartir les ouvertures de connexions simultanées sur plusieurs ordinateurs, mais à l’échelle de notre expérimentation, cela a un impact sur les performances mesurées, présentées, dans la section 6.4.
Chacune des connexions ouvertes par un client OpenSSL est reçue par le NAS, qui réalise une traduction entre TLS et EAP-TLS, et qui gère également l’encapsulation (et la désencapsulation) RADIUS avant de communiquer avec le serveur RADIUS, localement ou à distance – localement dans le cas de notre expérience. Ce serveur, qui tourne dans un thread sur le port 1812, attend des connexions UDP entrantes. A chaque nouvelle connexion reçue, il crée un thread initiant une connexion avec l’une des cartes EAP-TLS de la grille, en déroulant le scénario suivant (cf. figure 29) :
- Réception du message RADIUS en provenance du NAS et vérification du format et de la signature (attribut 80).
- Extraction de l’attribut 79 du message RADIUS, qui contient le message EAP encapsulé à retransmettre à l’une des cartes de la grille.
- Fragmentation du message EAP en un nombre approprié d’APDUs qui sont construites à ce moment.
- Conversion des APDUs en un format ASCII spécifique reconnaissable par le serveur frontal (proxy). Ce format comprend, en particulier, un numéro identifiant l’une des cartes de la grille à qui les données doivent être envoyées.
- Association d’un identifiant de session RADIUS avec une carte EAP-TLS spécifique de la grille, de manière à ce que la réception de toute ouverture de connexion soit associée à la même carte tout au long de la procédure d’authentification. Cette carte se trouve alors dans un état « bloqué », au sens où elle ne peut accueillir aucune connexion en provenance d’un autre client. Lorsque l’authentification est achevée, lorsque les clés cryptographiques ont été générées ou bien lorsque la notification d’échec de l’authentification est émise, la carte de la grille ayant été sollicitée est libérée. Elle peut désormais être de nouveau réquisitionnée par une nouvelle demande d’authentification EAP-TLS.
- Création de sockets TCP pour établir la connexion avec le serveur frontal placé devant la grille de cartes. Les APDUs, converties au format attendu par le serveur, sont envoyées à travers ces sockets, qui reçoivent également les réponses émises par les cartes de la grille.
- Lors de la réception d’APDUs de type EAP-Request en provenance de l’une des cartes, réassemblage des différents fragments EAP en un paquet unique, s’il y a lieu.
113
- Encapsulation du paquet EAP reconstitué dans un message RADIUS avant retransmission vers le NAS, qui appliquera les traitements adéquats avant retransmission vers le client TLS. Fermeture du thread qui avait été ouvert.
L’ensemble de cette procédure est renouvelé autant de fois que nécessaire pour traiter l’ensemble des sessions aboutissant à l’authentification (ou à son échec) de chacun des clients. Dans le cas où une erreur se produit au cours de la procédure d’authentification, le traitement est le même que dans le cas d’un échec de cette dernière, ce qui implique notamment la libération immédiate de la carte serveur réquisitionnée.
6.2.2.3
Rôle de l’identité dans les cartes serveur
Dans la plateforme que nous avons montée, les cartes EAP-TLS serveur ont toutes une identité par défaut que nous n’exploitons pas dans notre scénario. Néanmoins, cette identité peut avoir beaucoup plus d’importance si l’on considère le cas où des cartes relatives à des serveurs différents cohabitent au sein de la grille de cartes. Cela peut être le cas si plusieurs entreprises délèguent leur procédure d’authentification au même tiers.
Dans un tel contexte, c’est l’identité chargée dans chaque carte qui permettra de faire la différenciation. Notre modèle de conteneur d’identité conserve donc tout son sens dans ce type d’architecture, même s’il est a priori plus difficile d’envisager ici des cas pratiques de déploiement de cartes à plusieurs conteneurs d’identités.
6.3 Une architecture pour la génération sécurisée de jetons SAML
En reprenant la plupart des principes sur lesquels repose l’architecture précédente, il est possible de proposer une architecture alternative qui remplit un objectif différent, en s’inscrivant davantage dans la problématique de la gestion d’identités. La plateforme de démonstration établissant une preuve de concept de notre modèle d’identité, présentée au chapitre 5, mettait à contribution la technologie OpenID. Nous proposons à présent une architecture qui intègre la technologie SAML. Bien qu’elle ait fait l’objet d’une étude théorique à part entière, cette architecture n’a toutefois pas fait l’objet d’une implémentation. La principale raison à cela est la proximité qu’elle entretient à la fois dans la forme, avec la mouture qui a été présentée au paragraphe précédent, et dans le fond, avec la plateforme de démonstration OpenID présentée au chapitre 5. Or, dans les deux cas, les plateformes ont été entièrement montées et ont fait l’objet de mesures de performances, auxquelles les chiffres que nous aurions obtenus avec la présente architecture n’auraient pas apporté d’information pertinente.
Concrètement, la grille de cartes EAP-TLS serveur est conservée à l’identique, toujours placée derrière un serveur frontal qui est en charge de la communication avec chacune des cartes de la grille. En revanche, la partie que nous avions consacrée au traitement du protocole RADIUS est
114
nettement modifiée, notamment par la suppression du serveur RADIUS. Cependant, l’ensemble des traitements logiciels relatifs à la réception de demandes de connexion et à la gestion de la fragmentation des messages EAP-TLS en APDUs sont conservés.
Consumer
Service provider
Identity Provider
Request Service
SAML Auth Request
HTTP POST / SAML Request
EAP-TLS Authentication
{SAML Assertion Response} HTTP POST / SAML Response
Grant / Deny Access to Service
Check SAML Assertion 1 3 5 4 6 7 8 9 IdP Discovery 2