\documentclass{report}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{textcomp}
\usepackage{geometry}
\geometry{top=15mm, bottom=15mm, left=1cm, right=1cm}
\usepackage[french]{babel}
\usepackage{pslatex}
\usepackage[colorlinks=true,urlcolor=black]{hyperref}
\usepackage{graphicx}
\usepackage{fancyhdr}
\pagestyle{fancy}
\renewcommand{\footrulewidth}{0.4pt}
\fancyfoot[L]{Uubu.fr}
\fancyfoot[R]{lun. juin 9 13:58:21 CEST 2014}
\lfoot{\Large \textit{Uubu.fr}}
\hypersetup{pdfinfo={
Title={draft-chu-ldap-ldapi-00},
Author={Sylvain Girod},
Creator={Bash script from uubu.fr's format version 1},
Producer={Bash script and PDFLaTeX},
Subject={LDAP over IPC},
CreationDate={D:20140609135821},
ModDate={D:20140609135821},
Keywords={LDAP;Lightweight Directory Access Protocol}
}}
\begin{document}
 
\begin{center}
{\Huge draft-chu-ldap-ldapi-00 }
\end{center}
\vspace{1cm}
 
\begin{flushleft}
 
{\large LDAP over IPC}
 
\vspace{10mm}
 
\vspace{1cm}{\huge Introduction }
 
\
 
\hspace{1mm}  Bien que LDAP soit un protocole d'accès distribué, il est courant que des clients soient déployés sur la même machine que le serveur. De nombreuses applications embarquent un client et un serveur. Dans ces déploiements intégrés, où il n'y a pas de trafic réseau, l'utilisation de TCP/IP est inutile. Les systèmes type UNIX offrent des mécanismes IPC natives qui fournissent des sémantiques orienté flux d'une session TCP, mais avec une plus grande efficacité.
\vspace{5mm} \\
 
 
\hspace{1mm}  Depuis Janvier 2000, OpenLDAP fournis la possibilité d'établir des sessions LDAP au travers de sockets Unix aussi bien qu'au travers de TCP/IP. De telles sessions sont aussi sécurisée que les sessions TCP sur la boucle local,, mais elles consomment moins de ressources, sont plus rapide à établir, et fournissent une identification sécurisé du client sans nécessiter de mot de passe additionnel ou autres accréditations.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Motivations }
 
\
 
\hspace{1mm}  De nombreuses sessions LDAP consistent seulement en une ou 2 requêtes. L'initialisation et la fermeture des connections deviennent une portion significative du temps nécessaire à traiter ces sessions. Également lors de fortes charges, la contrainte de la limite 2MSL dans TCP devient problématique. Par exemple, un processeur moderne AMD64 dual-core qui fait tourner OpenLDAP peut manipuler 32000 authentification par secondes sur un réseau 100Mbps, avec une connection par requête. Connecté via une interface loopback, le taux est plus élevé, mais les connections sont complètement étranglées en moins d'une seconde à cause de tous les numéros de port utilisés et maintenus à l'état TIME\_WAIT. Donc même quand le traitement de la charge TCP est insignifiante, la contrainte imposée par la RFC793 crée une limite artificielle. De telles contraintes n'existent pas avec IPC.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Spécification visible à l'utilisateur }
 
\
 
\hspace{1mm}  Le seul changement nécessaire des clients pour implémenter cette fonctionnalité est d'utiliser une URL spéciale au lieu de \textbf{ldap://} pour spécifier le serveur cible. Également, le serveur a besoin d'inclure cette URL dans le liste des adresses d'écoute.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Schéma d'URL }
 
\
 
\hspace{1mm}  Le schéma d'URL ldapi: est utilisé pour dénoter une session LDAP sur IPC. La portion d'adresse de l'URL est le nom d'un socket unix, qui est géneralement un chemin complet Unix. les "/" dans le chemin doivent être encodés comme décrit dans la rfc3986. exemple: pour un socket nommé: \textbf{/var/run/ldapi}, l'url du serveur sera \textbf{ldapi://\%26var\%26run\%26ldapi/}. Tous les autres aspects de l'URL sont conformes à la rfc4516.
\vspace{5mm} \\
 
 
\hspace{1mm}  Si aucune adresse n'est spécifiée, une adresse par défaut peut être utilisée implicitement. Dans OpenLDAP, l'adresse par défaut est une constante spécifiée à la compilation.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Détails de l'implémentation }
 
\
 
\hspace{1mm}  Le transport basique utilise un socket unix orienté flux. Les sémantiques de communication dans un tel socket sont essentiellement identiques à utiliser une session TCP. À part l'établissement de la connexion, aucune considération spéciale n'est nécessaire dans le client, les librairies, ou le serveur.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Authentification Client }
 
\
 
\hspace{1mm}  Depuis leurs introduction dans BSD 4.2, les sockets Unix permettent également de passer des accréditifs d'un processus à un autre. Les systèmes moderne peuvent fournir un serveur avec un moyen plus simple.pour obtenir l'identité du client. L'implémentation d'OpenLDAP exploite plusieurs méthodes pour acquérir l'identité du client. La discussion qui suit est nécessairement spécifique à la plateforme.
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{La librairie OpenLDAP fournis getpeereid() pour encapsuler tous les mécanismes utilisé pour acquérir l'identité.}
\item[\hspace{1mm} -]{Sur FreeBSD et MacOsX, getpeereid() natif est utilisé}
\item[\hspace{1mm} -]{Sur les systèmes Solaris modernes, getpeerucred() est utilisé}
\item[\hspace{1mm} -]{Sur les systèmes Linux qui supportent l'option SO\_PEERCRED de getsockopt() est utilisé}
\item[\hspace{1mm} -]{Sur les systèmes qui n'ont pas ces méthodes, le passeur de descripteur est utilisé. Dans ce cas, le client doit envoyer un message contenant le descripteur comme toute première action immédiatement après la connction du socket. Le descripteur est attaché à une requête LDAP Abandon avec le message ID 0, sont le paramètre a également le message ID à 0. Cette requête est un pure no-op, et sera simplement ignoré par tout serveur n'implémentant pas ce protocole.}
\end{description}
 
\hspace{1mm}  Pour des raisons de sécurité, le descripteur passé doit être contrôlé. Le client crée un pipe et envoie le descripteur de pipe dans le message. Le serveur reçois de descripteur et fait un fstat() dessus pour déterminer l'identité du client. Le descripteur reçu doit être un pipe, et ses permissions doivent permettre l'accès à son propriétaire. L'uid et gid sont ainsi utilisé comme identité du client.
\vspace{5mm} \\
 
 
\hspace{1mm}  Noter que ces mécanismes sont simplement utilisés pour que l'identité du client sont disponible au serveur. Le serveur n'utilise pas les informations d'identité sauf si le client fait un Bind SASL en utilisant le mécanisme EXTERNAL.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Autres Plateformes }
 
\
 
\hspace{1mm}  Il est possible d'implémenter une fonctionnalité correspondante sur les systèmes basés sur Microsoft Windows en utilisant les pipes nommés, mais il n'y a pas de demande pour celà, et l'implémentation n'a pas été écrite. Le pipe devrait être créé en mode byte-read, et le client doit spécifier l'accès SECURITY\_IMPERSONATION quand il ouvre le pipe. Le serveur peut ainsi retrouver l'identité du client en utilisant la fonction GetNamePipeHandleState(). Vu que les sockets Windows ne sont pas interchangeable avec IPC, un event handler alternatif devra être fournis au lieu d'utiliser select().
\vspace{5mm} \\
 
\end{flushleft}
\end{document}
