SP3_Gestion_des_identities

documentclass12pt?{article}

usepackage{graphicx} usepackage{wasysym} usepackage{setspace}

topmargin -1.5cm oddsidemargin -0.04cm evensidemargin -0.04cm textwidth 16.59cm textheight 21.94cm %pagestyle{empty} parskip 7.2pt parindent 0pt

renewcommand{contentsname}{Sommaire}

begin{document} begin{center} {Gestion des identit'es sur Xwiki} end{center}

tableofcontents pagebreak{}

section{Objet}

L'objectif de ce document est de d'ecrire les r`egles de gestion des identit'es sur un r'eseau P2P, il s'inscrit dans le cadre du projet Xwiki. Il r'epond aussi aux questions pos'ees par les diff'erents acteurs du projet concernant les diff'erents aspects de s'ecurit'e sur le produit Xwiki, notamment la gestion des identit'es, la multiplication des identit'es sur les serveurs ou par les utilisateurs.

section{Pr'esentation} label{Présentation} La gestion des identit'es utilisateurs est un sujet majeur sur Xwiki, sp'ecialement en absence d'un serveur centralisant les donn'ees des utilisateurs. La question donc se pose de la mani`ere suivante : comment peut-on prot'eger les identit'es des utilisateurs sur un r'eseau d'ecentralis'e tel que Xwiki ? Plusieurs solutions sont envisageables. En effet, je pr'esente dans ce document le concept de gestion des identit'es sur un r'eseau P2P. `A noter que dans le premier livrable de l''etat de l'art de la s'ecurit'e durant la phase T1, plusieurs produits ont 'et'e pr'esent'es et qui r'epondent `a ce probl`eme, on peut mentionner dans ce cadre l`a, OpenID comme un produit open source.

begin{tabular}{|*{2}{c|}l r|} hline includegraphicsheight=90mm?{fig1.eps}
hline end{tabular}

vspace{2in}

Sur le sch'ema ci-dessus on voit deux clients sollicitant un ensemble des serveurs pour cr'eer leurs identit'es, en effet la demande pourra se faire `a n'importe quel serveur. L'utilisateur pourra choisir un serveur pr'ecis ou laisser le choix au client Xwiki de choisir un parmi les serveurs disponible, la connexion sur ces serveurs n'est pas indispensable pour se connecter sur le r'eseau.

subsection{Tomber en panne} label{Tomber en panne} L'existence de plusieurs serveurs n'est pas obligatoire, mais, en cas de tomber en panne de l'un deux, les autres peuvent continuer `a fournir des identit'es. Dans le cas contraire, s'il y a un seul serveur, l'utilisateur ne peut cr'eer son identit'e sauf en cas de disponibilit'e de ce dernier.

subsection{R'eplication des donn'ees sur les serveurs} label{Réplication des données sur les serveurs} Les donn'ees sur chaque serveur peuvent ^etre identiques ou non, selon le choix de d'eploiement, si les donn'ees doivent ^etre identiques sur tous les serveurs, alors, une proc'edure de r'eplication des donn'ees sera n'ecessaire.

subsection{Les diff'erentes fac cons de gestion d'identit'es} label{Les différentes façons de gestion d'identités}

Il existe deux fac cons de gestion d'identit'es sur un r'eseau P2P. La premi`ere est celle de s'assurer que l'utilisateur dispose d'un compte unique sur le r'eseau (signature forte). Dans ce cas l`a il faut associer avec ces informations personnelles une signature digitale. Par exemple ses emprunts digitaux. La deuxi`eme fac con est de consid'erer que l'utilisateur ait le droit de cr'eer plusieurs comptes. Dans ce cas on consid`ere que le compte lui-m^eme doit ^etre unique.

Dans un r'eseau P2P tel que Xwiki, en raison de besoin de mobilit'e et flexibilit'e et parce que Xwiki sera utilisateur sur des machines portables, la deuxi`eme fac con s'impose ; c ca veut dire on donne la possibilit'e `a l'utilisateur de cr'eer plusieurs compte mais chaque compte sera trait'e comme 'etant un utilisateur unique. Le serveur recevant la demande v'erifiera bien 'evidement les donn'ees de l'utilisateur en question, si les informations existent dans sa base de donn'ees, il avertit l'utilisateur et lui demande de changer son login et son mot de passe. D'autre contr^ole pourrait se faire sur les informations utilisateur. Comme validation de la date et lieu de naissance ou m^eme avoir comme r'ef'erence unique le num'ero de sa carte d'identit'e.

subsection{Le m'ecanisme de demande de cr'eer un compte utilisateur.} label{Le mécanisme de demande de créer un compte utilisateur.}

Le mode de connexion doit ^etre connect'e.

begin{itemize}

item L'utilisateur saisit les donn'ees li'ees `a son compte sur le client Xwiki. Il y saisit sp'ecialement son login et son mot de passe.
* item Xwiki signera les informations fournies par l'utilisateur (cryptage des informations avec un algorithme de chiffrage, RSA par exemple). Il les envoie `a un serveur disponible sur le r'eseau. La recherche d'un serveur disponible peut s'effectuer d'une mani`ere al'eatoire. On peut adopter les m^emes m'ecanismes de recherche et d'ecouverte entre deux pairs. Mais il s'agit ici d'une recherche sp'eciale pour trouver un type des pairs bien sp'ecifiques : Les serveurs fournissant des identit'es.
* item En cas d'absence d'un serveur sur le r'eseau pour une raison ou autre, l'utilisateur ne pourra pas cr'eer un compte. Et donc, il conservera ses donn'ees dans un endroit sur Xwiki pour relancer la requ^ete de cr'eation du compte lorsqu'un serveur soit disponible.
* item Le serveur qui a rec cu les donn'ees effectue une recherche dans sa base de donn'ees pour v'erifier si ces donn'ees sont d'ej`a enregistr'ees. Si c''etait le cas, il demande `a l'utilisateur de changer ces donn'ees. Il peut aussi lui proposer plusieurs possibilit'es de changement, comme par exemple lorsqu'il s'agit du mot de passe ou de login.
* item Une fois que le serveur ait enregistr'e les donn'ees, il g'en`ere une r'ef'erence unique et l'envoyer `a l'utilisateur concern'e.
* item L'utilisateur peut donc, se connecter `a Xwiki on utilisant cette r'ef'erence. Il faut noter aussi que l'utilisateur peut se connecter en mode offline sur Xwiki. `a cause de cette raison, les informations envoy'ees par le serveur doivent ^etre enregistr'ees sur le poste local de l'utilisateur.
*

end{itemize}

section{Comment limiter les nombres des identit'es par utilisateur} label{Comment limiter les nombres des identités par utilisateu}

Il existe plusieurs m'ecanismes permettant de limiter la multiplication des comptes pour un seul utilisateur. Ici je pr'esente un m'ecanisme qui s'appelle s'inscrire pas invitation.

subsection{Inscription par invitation} label{Inscription par invitation} Le concept est simple, il s'agit de recevoir une invitation avant de s'inscrire sur Xwiki. L'objectif 'etant de limiter la cr'eation de plusieurs identit'es par la m^eme personne. On estime que celui qui invite l'utilisateur le connait personnellement. Ce fait permet de cr'eer ce qu'on appelle un r'eseau social sur Xwiki. Ce type du r'eseau a plusieurs avantages, il limite les nombres des utilisateurs malveillants ou les utilisateurs qui ont tendance `a multiplier leurs identit'es sans aucune raison.

subsection{Le sc'enario de l'inscription par invitation est expliqu'e ci-dessous} label{3.2. Le scénario de l'inscription par invitation est expliqué ci-dessous}

Acteurs : Utilisateur (Invit'e) : Personne souhaitant s'inscrire et utiliser Xwiki Inviteur : administrateur du parc Xwiki ou un utilisateur disposant d'un nombre limit'e d'invitations.

begin{itemize} item Un utilisateur souhaitant s'inscrire et utiliser Xwiki, il envoie une demande `a l'inviteur item L'inviteur v'erifie l'information de l'utilisateur en question, il v'erifie notamment s'il est d'ej`a existe dans le syst`eme ou non. Si non, il lui envoie une invitation permettant `a l'utilisateur de cr'eer un compte dans Xwiki. item Lorsqu'il rec coit l'invitation, l'utilisateur devienne capable de r'eer son compte sur Xwiki avec les m^emes informations fournies lors de l'envoi de la demande de l'invitation. end{itemize}

begin{tabular}{|*{2}{c|}l r|} hline includegraphicsheight=70mm?{fig2.eps}
hline end{tabular}

end{document}