2. COMPONENTE EMPÍRICA
2.1. Formulação do Problema
LemonLDAP-NG supporte la plupart des protocoles de gestion des identités numériques, à
sa-voir :Login/PSW, OpenID, OAuth, SSL X509, CAS, et cela en tant que fournisseur et consommateur
d’identité. Par conséquent, nous proposons d’utiliser LemonLDAP-NG comme une“passerelle”entre
différents mécanismes d’authentification existants. Techniquement, nous utilisonsLemonLDAP-NGen
tant que client de gestion d’authentification au niveau des communautés collaboratives du RSE, et
ce en se basant sur les mécanismes d’authentification des entreprises comme fournisseurs d’identité
numériques.
Du coté entreprise, nous proposons de mettre en place LemonLDAP-NGsur une surcouche
lo-gicielle de gestion des identités collaboratives. LemonLDAP-NGfera office de fournisseur de jetons
d’authentification :SAML, OpenIDet CASauprès des acteurs de l’entreprise. Parallèlement il agira
en tant que consommateur d’identité (i.e.fournisseur de services) vis-à-vis des communautés
colla-boratives dans lesquelles sont impliqués les acteurs de l’entreprise. La procédure de consommation
a pour but la validation de l’identité de chaque acteur externe. Elle se déclenche suite à la réception
d’un jeton de demande d’approbation d’un acteur de la part du gestionnaire d’authentification de la
communauté en question.
En effet, pour la conception de notre architecture d’authentification distribuée et fédérée nous
nous sommes basés sur une extension de la conceptionCredentials-based. Ce choix permet de
préser-ver la confidentialité des expériences collaboratives de l’acteur afin d’éviter une éventuelle traçabilité
50. Le Portal du domaine de l’application sollicitée.
51. Qui fournit les informations de session de l’utilisateur en question. 52. La base d’information sur les utilisateurs est disponible en interne.
4.2. Gestion et administration des identités et ressources
de la part de tiers malveillants. En outre, la conceptionCredentials-basedpermet de réduire la charge
de traitement pour le fournisseur d’identités vu qu’il ignore l’objet de chaque requête et se contente
seulement de fournir desCredentialsuniversels permettant d’identifier l’acteur en question.
Pour qu’un acteur puisse s’authentifier, il demande dans un premier temps desCredentialsà son
fournisseur d’identités (i.e.,son entreprise). LesCredentialsseront générés en fonction du protocole
d’authentification du fournisseur d’identités,e.g., format OpenID, ou SAML. Ensuite, l’acteur
four-nit lesCredentialsau gestionnaire d’authentification de la communauté qu’il souhaite rejoindre. Ce
dernier, étant compatible (grâce àLemonLDAP) avec tous les formats deCredentialsfournis, sera en
mesure de procéder à une procédure d’authentification en vue de la consommation d’une ressource
collaborative au sein de la communauté. Pour cela, une solution classique et typiqueCredentials-based
consisterait à partager une clé secrète entre le fournisseur d’identités de l’entreprise de l’acteur et le
gestionnaire d’identité de la communauté. Comme nous l’avons présenté précédemment, cette
dé-marche n’est pas très sécurisée, ni facile à gérer dans un contexte ouvert tel qu’une communauté RSE.
Par conséquent, nous avons modifié la configurationCredentials-based(illustrée dans la figure4.6)
en y ajoutant une interaction entre les deux parties d’authentification afin de vérifier que l’identité
de l’acteur en question n’a pas été usurpée tout en préservant la confidentialité des interactions
col-laboratives de l’acteur. La figure4.8 montre le déroulement de notre processus d’authentification
fédérée.
1 2 3 Certificat d'authentification 4 Fournisseur d'identité LemonLDAP::NG Fournisseur de service LemonLDAP::NG Entreprise Acteur Cre dent ials Credentials + Id_externe Communauté FédérationF
IGURE4.8 – Processus d’authentification.
Jusqu’à maintenant, nous avons discuté les deux premières étapes (1 et2 de la figure4.8) du
processus d’authentification. La troisième étape illustre l’interaction entre les deux parties. En effet,
grâce à notre procédure de gestion des identités des acteurs dans les communautés, nous pouvons
Chapitre 4. Architecture et gestion des identités numériques
vérifier l’authenticité d’un propriétaire de Credentials sans avoir besoin de procédures
cryptogra-phiques avancées telles que le partage de clés privées. Plus précisément, notre gestion d’identité est
basée sur les notions d’identifiant interne immuable et propre à l’entreprise de l’acteur et un
iden-tifiant externe généré par le gestionnaire d’identité de l’entreprise et lié à l’ideniden-tifiant interne pour
une utilisation externe au sein d’une communauté donnée. La génération desCredentialsest
égale-ment dépendante de l’identifiant interne. Ainsi, ce mix d’attributs permet de vérifier au niveau du
fournisseur d’identités si l’identifiant externe de l’acteur ainsi que lesCredentialsqu’il présente sont
conformes, et ce par l’intermédiaire de l’identifiant interne de l’acteur. Plusieurs solutions peuvent
être proposées dans le cadre de cette procédure. Une solution très simple serait d’associer une clé
unique à chaque identifiant interne et la décomposer en deux parties qui seront associées
séparé-ment à chaque instance d’identifiant externe etCredentials. Une fois les Credentials validés par le
fournisseur d’identités de l’entreprise, l’acteur sera authentifié auprès du gestionnaire d’identité de
la communauté en question.
Cependant, le processus ne s’arrête pas à cette dernière étape, car l’acteur voudra accéder à des
ressources déployées dans le cadre de la communauté mais appartenant à d’autres entreprises. Par
conséquent, il est primordial que l’identité de l’acteur soit validée auprès du mécanisme
d’authentifi-cation de l’entreprise propriétaire de la ressource collaborative désirée. Pour cela, nous nous servons
de la confiance mutuelle établie dans le cadre de la fédération. Plus précisément, étant déjà
authen-tifié auprès du mécanisme d’authentification de la communauté, l’identité de l’acteur sera approuvée
auprès du mécanisme d’authentification de l’entreprise propriétaire par le serviceLemonLDAPde la
communauté. Techniquement, l’approbation se fait au moyen de la communication d’un jeton
53d’au-thentification de la part deLemonLDAP de la communauté au mécanisme d’authentification choisi
par l’entreprise
54. Cette conception est très avantageuse, car elle permet, d’un côté d’éviter déjà de
nombreuses procédures d’authentification vis-à-vis de chaque entreprise appartenant à la
commu-nauté ; et d’un autre côté, elle permet également de résoudre le problème d’interopérabilité entre les
différents mécanismes d’authentification des entreprises partenaires.
Pour résumer, comme illustré dans la figure Fig 4.9
55, le gestionnaire d’authentification d’une
communauté vérifie l’identité d’un acteur donné en interrogeant le gestionnaire d’identité de son
entreprise au moyen des Credentials d’identité fournis par le sujet de l’authentification. Une fois
authentifié, l’identité de l’acteur sera approuvée auprès de toutes les entreprises appartenant à la
communauté (fédération) par le gestionnaire d’identité de la communauté au moyen d’un échange
de jetons compatibles (i.e. LemonLDAP).
LemonLDAP-NGne vise pas à remplacer le mécanisme de base de gestion d’identité de l’entreprise.
Il sert plutôt à offrir une ouverture à plus de diversité et une flexibilité concernant l’utilisation de
mécanismes d’authentification (éventuellement incompatibles) entre les entreprises collaboratives.
53. Le jeton prend la forme d’un cookie.
54. Sur la base des différents protocoles d’authentification proposés parLemonLDAP.