Tous les Handlers sont écrits en programmation de classes avec Perl et basés sur le module Plack implémentant le protocole PSGI sauf le Handler Node.js, écrit en JavaScript. La programmation de classes est un modèle particulier permettant de coder sans créer d’objet donc pratiquement sans empreinte mémoire. Le « choix » de Perl et de la programmation de classes sont des héritages du serveur web Apache pour lequel avait été écrit LemonLDAP::NG à l’origine. Celui-ci n’autorisait que ce type de programmation et n’offrait que les modules Mod_Perl (« mod_perl », 2018) ou le langage C pour manipuler les requêtes HTTP. Le choix a donc été fait d’utiliser Mod_Perl, plus pratique à utiliser.
L’interception des requêtes par les Handlers fonctionne de la façon suivante. Le serveur web reçoit les requêtes HTTP provenant du client (navigateur) et les « passe », les transmet au(x)
Handler(s) via une interface de type CGI (Common Gateway Interface) (« Common Gateway
Interface », 2016). En effet, au lieu d'envoyer le contenu d'un fichier, le serveur HTTP exécute un programme, ici le Handler, puis retourne le contenu généré. CGI est le standard industriel qui indique comment transmettre la requête du serveur HTTP au programme, et comment récupérer la réponse générée.
La norme RFC3875 (Robinson <drtr@apache.org>, s. d.) impose un format de nommage des en-têtes HTTP. En effet, le serveur HTTP utilise un ensemble de variables d’environnement pour transmettre des informations aux scripts CGI. Certaines de ces variables d’environnement sont utilisées pour communiquer certains aspects de la requête HTTP, comme le type de contenu, le port TCP, le nom d’hôte ou la méthode de requête (par exemple GET ou POST). Il y a un ensemble de variables d’environnement différent, que la norme appelle « Meta-Variables spécifiques au protocole », qui servent à transmettre les valeurs d’en-têtes HTTP au script CGI. La mise en correspondance des en-têtes HTTP avec les variables d’environnement suit une procédure standard : le nom d’en-tête HTTP est converti en majuscules, « - » est remplacé par « _ », et « HTTP_ » est le préfixe. Par exemple, l’en-tête « Cookie » est traité avec la variable d’environnement « HTTP_COOKIE ».
4.3.1 – Serveurs de type PSGI (Starman, Corona, Twiggy, …)
Le serveur passe les requêtes directement au Handler. Celui-ci « lit » la clef de session transmise par le cookie SSO. Il récupère les informations utilisateur puis les sauvegarde dans son cache local (15 secondes). Ensuite, il vérifie les règles d’accès et initialise les en-têtes HTTP à transmettre à l’application, en-têtes qui ont été déclarés dans le Manager. Enfin, le Handler construit l’en-tête de la requête en y incluant les en-têtes HTTP et retourne la requête construite au serveur web qui la transmet au client.
4.3.2 – Serveur Nginx
(« nginx », 2018) Nginx est un serveur Web ainsi qu'un proxy inverse écrit par le mathématicien Igor Sysoev, dont le développement a débuté en 2002 pour les besoins d'un site russe à très fort trafic.
Nginx est un système asynchrone par opposition aux serveurs synchrones où chaque requête est traitée par un processus dédié. Au lieu d'exploiter une architecture parallèle et un multiplexage temporel des tâches par le système d'exploitation, Nginx utilise les changements d'état pour gérer plusieurs connexions en même temps. Le traitement de chaque requête est découpé en de nombreuses mini-tâches et permet ainsi de réaliser un multiplexage efficace entre les connexions. Afin de tirer parti des ordinateurs multiprocesseurs, plusieurs processus peuvent être démarrés. Ce choix d'architecture se traduit par des performances très élevées, mais également par une charge et une consommation de mémoire particulièrement faibles comparativement aux serveurs HTTP classiques, tels qu'Apache. Nginx supporte nativement les protocoles FastCGI et uWSGI qui sont deux implémentations optimisées d’une CGI.
D’après (« FastCGI », 2017), FastCGI a été créée en 1996 pour gérer les applications dynamiques des applications web. Avec CGI, chaque requête lance une nouvelle instance de CGI qui appellera le programme à exécuter. Le binaire CGI recrée à chaque appel le contexte de l'environnement d'exécution et ne permet pas de limiter le nombre de processus simultanés. Ce nombre sera donc dépendant du nombre de processus simultanés du serveur web. En revanche, avec FastCGI, une variable est introduite permettant de déterminer le nombre minimum et maximum de processus CGI à exécuter, indépendamment du nombre de processus HTTP maximum.
uWSGI, comme FastCGI, est un protocole permettent à un serveur web de déléguer des traitements à un autre programme. A l’origine WSGI et uWSGI avaient été développés pour servir des applications Python.
Nginx reçoit les requêtes HTTP et les transmet à un serveur d’échange FastCGI ou uWGSI emportant le module PSGI. LLNG fournit un serveur FastCGI par défaut utilisant le moteur FCGI. Celui-ci peut être remplacé par d’autres implémentations : FCGI::Engine::ProcManager, FCGI::Async ou autres. Le serveur FastCGI / uWSGI passe les requêtes au Handler pour traitement qui les retourne en suivant le parcours inverse.
Le Handler Nginx a pour particularité de ne pas pouvoir ajouter directement les en-têtes HTTP aux requêtes transmises à l’application protégée. Deux solutions sont possibles, soit ajouter les en-têtes manuellement dans les « vHosts » soit utiliser un script LUA qui ajoute les directives. Le script fournit par LLNG (nginx-lua-headers.conf) est en fait une « simple boucle » qui permet de transmettre au maximum dix en-têtes HTTP par défaut. Il peut facilement être modifié pour transmettre plus d’en-têtes.
LUA (« Lua », 2018) est un langage de script libre, réflexif et impératif. Créé en 1993, il est conçu de manière à pouvoir être embarqué au sein d'autres applications afin d'étendre celles-ci. L'interpréteur Lua est écrit en langage C ANSI strict. De ce fait, il est compilable avec une grande variété de systèmes. Il est également très compact et est souvent utilisé dans des systèmes embarqués.
4.3.3 – Serveur Apache 2.X (2.2 ou 2.4)
(« Apache HTTP Server », 2018) Ce serveur web était le plus populaire sur le web. Apache est conçu pour prendre en charge de nombreux modules lui donnant des fonctionnalités supplémentaires : interprétation du langage Perl, PHP, Python et Ruby, serveur proxy, Common Gateway Interface, réécriture d'URL, négociation de contenu, protocoles de communication additionnels, etc... Néanmoins, il est à noter que l'existence de nombreux modules Apache complexifie la configuration du serveur web et de nombreuses failles de sécurité affectant uniquement les modules sont régulièrement découvertes.
Dans le cas du serveur Apache, les requêtes sont transmises directement au Handler via le module Mod_Perl. Le Handler Apache est en réalité constitué de deux modules : le Handler lui- même et un module « PerlHeaderParserHandler » qui ajoute les en-têtes HTTP aux requêtes. Il existe également une implémentation FastCGI pour Apache (Mod_fstcgi). En revanche, ce module n’offre pas la possibilité de déléguer l’autorisation d’accès à un processus externe ou de modifier l’en-tête des requêtes. Il permet uniquement de générer du contenu dans le corps de la requête. De ce fait, l’utilisation de Mod_Perl reste donc obligatoire.
4.3.4 – Node.js
(« Des-applications-ultra-rapides-avec-node-js.pdf », s. d.) & (« Node.js », 2018) Node.js est une plateforme logicielle libre et événementielle écrite en JavaScript orientée vers les applications réseau qui doivent pouvoir monter en charge. Elle utilise la machine virtuelle V8 développée par Google. Le moteur V8 est un moteur javascript libre écrit en C++. Parmi les modules natifs de Node.js, on retrouve « HTTP » qui permet le développement de serveur HTTP. Node.js est un environnement bas niveau permettant l’exécution de JavaScript côté serveur.
Node.js dispose de nombreux modules comme « Express.js » permettant d’étendre ses fonctionnalités notamment un module FastCGI. C’est par son intermédiaire que le serveur web Node.js transmet les requêtes au Handler. De plus, le Handler Node.js nécessite un module spécifique comme « nodedbi.js » pour pouvoir interroger une base de données pour le stockage du cache.
Ce Handler étant développé en JavaScript, les règles doivent être écrites sous cette forme dans le Manager : $uid eq « dwho » devient $uid === « dwho » et les applications qu’il protège doivent être explicitement déclarées dans la section NodeHandler du fichier de configuration de LLNG : lemonldap-ng.ini.