UNIVERSITÉ DU QUÉBEC À MONTRÉAL ANALYSE DES DIFFÉRENTES PLATEFORMES DE SIGNATURE À CODE SOURCE LIBRE

UNIVERSITÉ DU QUÉBEC À MONTRÉAL ANALYSE DES DIFFÉRENTES PLATEFORMES DE SIGNATURE À CODE SOURCE LIBRE RAPPORT DE PROJET PRÉSENTÉ COMME EXIGENCE PARTIELLE DE LA MAÎTRISE EN GÉNIE LOGICIEL PAR SÉBASTIEN GRAVEL JUILLET 2011

REMERCIEMENTS Nos remerciements vont à tous ceux qui ont contribué de près ou de loin à la réalisation de ce travail en particulier : Monsieur Normand Séguin pour sa direction, ses orientations, et sa compréhension. Ma femme Sonya, pour son aide, et son soutien, tout au long de mon cursus universitaire.

iv TABLE DES MATIÈRES REMERCIEMENTS...III LISTE DES FIGURES... IIX LISTE DES TABLEAUX... IX RÉSUMÉ... XI INTRODUCTION... 1 0.1 Contexte... 1 0.2 But... 1 CHAPITRE I IDENTIFICATION ET ANALYSE DE LA SIGNATURE UNIQUE... 3 1.1 Définition de la signature unique... 3 1.2 Architecture type (théorique)... 4 1.3 Caractéristiques... 7 1.3.1 Points forts... 7 1.3.2 Points faibles... 8 CHAPITRE II MÉTHODE D ANALYSE... 10 2.1 Démarche relative à l analyse du produit... 10 2.2 Critères généraux... 10 2.3 Description de l échelle utilisée... 11 2.4 Définitions des critères retenus et poids relatif assigné... 13 2.4.1 Compatibilité avec les systèmes de stockage de données (3)... 13 2.4.2 Gestion des comptes et des accès (3)... 14 2.4.3 Intégration dans un environnement hétérogène (3)... 16 2.4.4 Journalisation (3)... 17 2.4.5 Sécurité des connections avec les applications (3)... 19 2.4.6 Distribution de la plateforme (2)... 20

v 2.4.7 Personnalisation des interfaces utilisateurs (2)... 22 2.4.8 Certificats (1)... 24 2.4.9 Intégration/Installation de la solution (1)... 26 2.4.10 Langage de programmation (1)... 27 2.4.11 Exigences matérielles/logicielles (1)... 28 2.5 Matrice de distribution des points... 29 2.6 Justifications... 30 CHAPITRE III LES SOLUTIONS À CODE SOURCE LIBRE... 32 3.1 Description... 32 3.2 Solutions retenues... 33 3.3 Autres solutions... 34 CHAPITRE IV SOLUTION 1, CAS... 36 4.1 Présentation... 36 4.2 Description... 37 4.3 Évaluation... 38 4.3.1 Critères généraux... 39 4.3.2 Compatibilité avec les systèmes de stockage de données... 39 4.3.3 Gestion des comptes et des accès... 43 4.3.4 Intégration dans un environnement hétérogène... 44 4.3.5 Journalisation... 45 4.3.6 Sécurité des connections avec les applications... 47 4.3.7 Distribution de la plateforme... 48 4.3.8 Personnalisation des interfaces utilisateurs... 48 4.3.9 Certificats... 49 4.3.10 Intégration/Installation de la solution... 50 4.3.11 Langage de programmation... 51 4.3.12 Exigences matérielles/logicielles... 52 4.4 Matrice de la solution... 53 4.5 Notes... 53 CHAPITRE V

vi SOLUTION 2, OPENSSO (OPENAM)... 55 5.1 Présentation... 55 5.2 Description... 56 5.3 Évaluation... 58 5.3.1 Critères généraux... 58 5.3.2 Compatibilité avec les systèmes de stockage de données... 60 5.3.3 Gestion des comptes et des accès... 61 5.3.4 Intégration dans un environnement hétérogène... 63 5.3.5 Journalisation... 64 5.3.6 Sécurité des connections avec les applications... 66 5.3.7 Distribution de la plateforme... 67 5.3.8 Personnalisation des interfaces utilisateurs... 68 5.3.9 Certificats... 70 5.3.10 Intégration/Installation de la solution... 70 5.3.11 Langage de programmation... 71 5.3.12 Exigences matérielles/logicielles... 72 5.4 Matrice de la solution... 73 5.5 Notes... 73 CHAPITRE VI SOLUTION 3, JOSSO... 75 6.1 Présentation... 75 6.2 Description... 77 6.3 Évaluation... 79 6.3.1 Critères généraux... 79 6.3.2 Compatibilité avec les systèmes de stockage de données... 80 6.3.3 Gestion des comptes et des accès... 82 6.3.4 Intégration dans un environnement hétérogène... 83 6.3.5 Journalisation... 84 6.3.6 Sécurité des connections avec les applications... 85 6.3.7 Distribution de la plateforme... 86 6.3.8 Personnalisation des interfaces utilisateurs... 87 6.3.9 Certificats... 89

vii 6.3.10 Intégration/Installation de la solution... 89 6.3.11 Langage de programmation... 91 6.3.12 Exigences matérielles/logicielles... 91 6.4 Matrice de la solution... 92 6.5 Notes... 92 CHAPITRE VII SYNTHÈSE... 94 7.1 Buts et objectifs... 94 7.2 Résultats... 96 7.2.1 Attentes et problématique... 97 7.2.2 Avantages... 98 7.2.3 Inconvénients... 99 CONCLUSION...101 BIBLIOGRAPHIE...108

LISTE DES FIGURES Figure 1.1 Architecture plateformes de signature unique. (HP, 2010)... 5 Figure 1.2 Architecture de type agent.(hp, 2010)... 5 Figure 1.3 Architecture de type serveur mandataire inversé. (HP, 2010)... 6 Figure 2.1 Formule utilisée pour déterminer la note globale... 12 Figure 4.1 Représentation de CAS (Dune, 2003)... 37 Figure 4.2 log4j.properties (Jasig, 2010a)... 46 Figure 5.1 Connexion initiale à OpenAM (Shin, 2009)... 57 Figure 5.2 Connexion subséquente à OpenAM (Shin, 2009)... 58 Figure 5.3 Système de stockages externe disponibles pour les données utilisateurs... 61 Figure 5.4 Gestion des usagers... 62 Figure 5.5 Répertoire de journalisation... 64 Figure 5.6 Ajout d un serveur a une installation existante... 68 Figure 6.1 Connexion à JOSSO (Brigandi, 2005)... 78 Figure 6.2 Schéma de base de donnée (Confluence, 2009a)... 81 Figure 6.3 Journalisation dans JOSSO... 85

LISTE DES TABLEAUX Tableau 1.1 Architecture de type agent et de type serveur mandataire inversé. 6 Tableau 2.1 Pondération associée à l importance d un critère d évaluation... 12 Tableau 2.2 Pointage lié à la compatibilité avec les systèmes de stockage de données.... 14 Tableau 2.3 Pointage lié à la gestion des comptes et des accès.... 15 Tableau 2.4 Pointage lié à l intégration dans un environnement hétérogène... 17 Tableau 2.5 Pointage lié à la journalisation.... 19 Tableau 2.6 Pointage lié à la sécurité des connections avec les applications.. 20 Tableau 2.7 Pointage lié à la distribution de la plateforme... 22 Tableau 2.8 Pointage lié à la personnalisation des interfaces utilisateurs.... 24 Tableau 2.9 Pointage lié aux certificats... 26 Tableau 2.10 Pointage lié à l intégration/installation de la solution... 27 Tableau 2.11 Pointage lié au langage de programmation... 28 Tableau 2.12 Pointage lié aux exigences matérielles/logicielles... 29 Tableau 2.13 Matrice de distribution des points... 30 Tableau 4.1 Langages de programmation disponible pour l application client de CAS.... 38 Tableau 4.2 Matrice de distribution des points (CAS)... 53 Tableau 5.1 Emplacement des principaux fichiers de l interface OpenAM... 69 Tableau 5.2 Matrice de distribution des points (OpenAM)... 73

x Tableau 6.1 Agents disponibles pour la plateforme JOSSO (Confluence, 2010b)... 84 Tableau 6.2 Paramètre à implémenter dans une page personnalisée... 88 Tableau 6.3 Matrice de distribution des points (Josso)... 92 Tableau 7.1 Résumé des critères de comparaisons.... 96 Tableau 7.2 Compilation des résultats... 97 Tableau 7.3 Connaissances en génie logiciel (tronc commun)...105

RÉSUMÉ La multitude de systèmes et environnements informatiques auxquels les utilisateurs sont confrontés peut facilement amener à une multiplication d identifiants et de mots de passe à retenir. Cette multitude amène donc plusieurs problèmes de sécurité, de coûts et de complexité qui sont résumés ici-bas : Les utilisateurs sont inondés d information à retenir (compte utilisateurs, mots de passes, ) et à sécuriser. Les administrateurs doivent gérer les accès indépendamment pour chaque environnement et donc avoir accès à tous les sous-systèmes. Les concepteurs doivent créer et tester le mécanisme de connexion et d authentification pour chaque système. Le but de ce projet est donc d évaluer les principales caractéristiques de trois plateformes de signature unique afin d identifier celles qui sont les plus intéressantes. Afin de contourner cette problématique, la solution la plus populaire reste l utilisation de plateforme de signature unique. Afin d atteindre cet objectif, nous avons défini ce qu est une plateforme de signature unique, l architecture générale de celle-ci ainsi que les points forts et les points faibles qui y sont généralement attribués. Par la suite, nous avons identifié les principales caractéristiques des plateformes, ce qui nous a permis d identifier onze (11) critères de comparaison. En comparant, entre elles, les trois solutions de signature unique à code source libre les plus intéressantes sur le marché (CAS, OpenAM, JOSSO) nous avons été en mesure de sélectionner celle qui correspond le mieux à nos critères. Les résultats obtenus pour chaque plateformes nous permettent d affirmer que OpenAM est en avance, par rapport à nos critères, aux autres. En fait, pour ce qui est des résultats quantitatifs, OpenAM a obtenu 85 alors que CAS et JOSSO sont arrivés à égalité en deuxième avec une note de 71. Ceci ne veut pas dire que les autres solutions (OpenSSO et JOSSO) ne sont pas intéressantes mais bien qu elles le sont moins compte tenu de notre situation et de nos objectifs. Malgré le fait que les résultats de la plateforme OpenAM sont grandement supérieurs aux deux autres, nous sommes très au courant que dans certaines situations, OpenSSO et JOSSO pourraient être supérieurs.

INTRODUCTION 0.1 Contexte La multitude de systèmes et environnements informatiques auxquels les utilisateurs sont confrontés peut facilement amener à une multiplication d identifiants 1 et de mots de passe à retenir. Cette multitude amène donc plusieurs problèmes de sécurité, de coûts et de complexité. Afin de contourner cette problématique, la solution la plus populaire reste l utilisation de plateforme de signature unique. Plusieurs types de plateforme de signature unique existent sur le marché, mais elles n offrent pas toutes les mêmes caractéristiques, avantages et faiblesses. Alors que certaines de ces solutions sont propriétaires, plusieurs autres testées à grande échelle sont à code source libre. Puisque l information et les systèmes sont de plus en plus axés vers les intranets et le web, les solutions préconisées seront surtout axées vers les techniques et les systèmes basés web. Il est important de savoir que ceci ne veut pas dire que les bases d utilisateurs existantes de type LDAP ou Active Directory ne seront pas réutilisées ou compatibles avec ces plateformes. Tout au contraire, les bases existantes doivent être compatibles le plus possible avec les solutions. 0.2 But Le but de ce projet est d évaluer les principales caractéristiques de trois plateformes de signature unique afin d identifier celles qui sont les plus intéressantes. Ces plateformes 1 Dans le cadre de ce travail, le terme identifiant a été utilisé comme la traduction de «credentials».

2 faciliteront l accès des utilisateurs à une multitude d applications à l aide d un seul identifiant. Afin d atteindre cet objectif, nous avons divisé le présent rapport comme suit : D abord, nous allons voir ce qu est une plateforme de signature unique. Quelle est l architecture générale de ces plateformes et quels sont les points forts et les points faibles qui y sont généralement attribués. Fort de ces informations, nous allons par la suite établir les principales caractéristiques des plateformes. Par le fait même, nous allons identifier les points de comparaison et les méthodes qui seront utilisés pour les fins de notre analyse. Ensuite, nous allons voir les différentes solutions de plateformes de signature unique disponibles sur le marché. Ceci nous amènera naturellement à effectuer une sélection des plateformes que nous allons analyser. Dans les chapitres suivants, nous effectuerons une analyse et une comparaison des différentes plateformes précédemment sélectionnées en donnant pour chacune d elles une note globale qui représente à quel point une solution correspond ou non aux différents critères que nous avons fixés. Finalement, nous allons analyser les résultats et sélectionner la ou les plateformes qui correspondent le mieux à nos critères et à nos sous-objectifs. Cette méthode nous permettra sans doute de trouver une plateforme très flexible qui permettra de résoudre les différentes problématiques en minimisant l insertion de nouvelles problématiques ou contraintes.

CHAPITRE I IDENTIFICATION ET ANALYSE DE LA SIGNATURE UNIQUE 1.1 Définition de la signature unique unique : Dans le cadre de ce travail, nous allons utiliser la définition suivante de la signature «L'authentification unique (ou identification unique ; en anglais Single Sign-On ou SSO) est une méthode permettant à un utilisateur de ne procéder qu'à une seule authentification pour accéder à plusieurs applications informatiques (ou sites Web sécurisés).» (Wikipedia, 2010a) Cette définition nous permet de jeter les bases de notre analyse et de comparer les différentes plateformes de signature unique. Dans le cadre de ce projet nous nous concentrerons uniquement aux plateformes de signature unique basées Web. Afin de pouvoir comparer les différentes plateformes de signature unique entre elles, nous utiliserons une série de critères qui seront présentés au chapitre 2 de ce travail. Ceux-ci ont été sélectionnés et créés afin de pouvoir s assurer que les principaux objectifs relatifs aux plateformes de signature unique sont atteints. «Les objectifs sont multiples : Simplifier pour l'utilisateur la gestion de ses mots de passe : plus l'utilisateur doit gérer de mots de passe, plus il aura tendance à utiliser des mots de passe similaires ou simples à mémoriser, abaissant par la même occasion le niveau de sécurité que ces mots de passe offrent ; Simplifier la gestion des données personnelles détenues par les différents services en ligne, en les coordonnant par des mécanismes de type méta-annuaire ;

4 Simplifier la définition et la mise en œuvre de politiques de sécurité.» (Wikipedia, 2010a) 1.2 Architecture type (théorique) Le but de cette section est d effectuer un survol de l architecture d une plateforme de signature unique. Le but étant de comprendre et d exposer ce qui est commun à chaque plateforme et ainsi pouvoir identifier les différences et les forces de chacune lors des phases de comparaison. Il y a deux grandes familles de plateformes de signature unique, le type agent et le type serveur mandataire inversé 2 («reverse proxy»). Nous pouvons voir les principales caractéristiques et les différences architecturales et fonctionnelles entre les deux types de solutions. 2 Un serveur mandataire inversé est un «Élément de coupe-feu servant d'intermédiaire entre le navigateur d'un internaute utilisant un réseau local et le serveur Web qu'il veut consulter, permettant ainsi à des données de sortir du réseau local et d'y entrer, sans mettre en danger la sécurité du réseau.». (Office Québécois de la langue française, Grand dictionnaire terminologique ). Il est la traduction de proxy server. Le reverse proxy est placé côté serveur entre Internet et les serveurs.

5 Figure 1.1 Architecture plateformes de signature unique. (HP, 2010) L architecture de type agent est celle représentée dans la section de gauche de la figure 1.1. Comme on peut le voir, l agent est installé sur chaque serveur web et c est ce dernier qui vérifie avec le serveur d authentification afin de voir si l utilisateur est autorisé et authentifié. Dépendamment de la situation, le serveur web donne accès à l information (ou l application) ou alors affiche lui-même le message d erreur à l utilisateur. Le tout est résumé dans la figure 1.2. Figure 1.2 Architecture de type agent.(hp, 2010)

6 Dans le second cas, celui de type serveur mandataire inversé, le flot est similaire à ce qui est représenté dans la figure 1.3. Figure 1.3 Architecture de type serveur mandataire inversé. (HP, 2010) Dans ce type d architecture, la connexion s effectue sur la plateforme de signature unique qui fait aussi office de serveur mandataire inversé. Ce dernier vérifie si l utilisateur est connecté et si non, il gère l authentification et l autorisation. Lorsque complété, la plateforme de signature unique relaie l utilisateur à l application. Compte tenu que l utilisateur doit toujours passer par la plateforme de signature unique et qu il n a pas accès directement à l application ou le site web, on peut considérer que celle-ci fait aussi office de pare feu applicatif. Les avantages et les inconvénients liés à l une ou l autre des différentes architectures sont relativement évidents à isoler. Le tableau suivant adapté de la même source (HP, 2010) nous présente les principales caractéristiques. Tableau 1.1 Architecture de type agent et de type serveur mandataire inversé. Avantages Inconvénients Agent Moins de goulot d étranglement donc plus performant. L agent doit être installé sur chaque serveur web (ou application). En conséquence le travail de configuration et d implémentation est plus long et fastidieux. Certaines technologies ou serveur web pourraient ne pas être compatibles avec l agent. Serveur mandataire inversé Aucune restriction vis-à-vis du type de serveur Web. Aucune modification de l'application ou de la page Web n'est nécessaire. Plus sécuritaire puisque le serveur Web n'est pas visible directement. Toutes les requêtes doivent passer par la plateforme de signature unique. La charge résultante sur celle-ci est donc très grande.

7 Nous allons voir dans les sections suivantes les caractéristiques, c est-à-dire les forces et les faiblesses, des plateformes de signature unique. Ce qui sera retenu ne tiendra pas compte des architectures utilisées et n analysera pas ce qui est lié aux différentes technologies puisque le tout sera évalué lors de la comparaison et l analyse de chacune des plateformes. 1.3 Caractéristiques Comme toute technologie, les plateformes de signature unique, ont plusieurs points forts et quelques points faibles. Les deux sous-sections suivantes ont pour objectif de les identifier. Nous les identifions de façon générique c est-à-dire sans tenir compte et sans analyser en détail les différentes technologies et solutions disponibles sur le marché. En s assurant de choisir des objectifs et des critères de comparaisons (chapitre 2) qui révisent les points forts et les points faibles, il sera possible de voir si les différentes plateformes de signature sont en mesure de maximiser les uns et de minimiser les autres. 1.3.1 Points forts Nous avons identifiés plusieurs points forts liés à l utilisation de plateformes de signature unique. Ces derniers sont de plusieurs ordres. D abord, pour les utilisateurs, ensuite les administrateurs, suivi par les concepteurs et finalement les gestionnaires. En nous basant sur plusieurs sources (Kumar ; Secude, 2010a, 2010b ; Wikipedia, 2010g, 2010a) nous avons identifiés les caractéristiques qui s appliquent aux plateformes de signature WEB: Une augmentation de la productivité puisque les utilisateurs n ont pas à se rappeler d une myriade de mots de passe et n ont pas constamment à entrer leurs mots de passe. Le nombre d appels relatifs aux réinitialisations de mots de passe est diminué puisqu il y a moins de mots de passe à retenir.

8 En diminuant le nombre de mots de passe, la gestion des TI s en trouve simplifiée. La sécurité globale des systèmes est augmentée grâce à plusieurs éléments dont les principaux sont : o La centralisation de l authentification; o La sécurisation des points d entrées, de sorties et d accès aux différents systèmes (tout en ne redemandant pas constamment aux utilisateurs d entrer leurs identifiants); o Le regroupement des informations relatives aux contrôles d accès afin de standardiser les processus et de faciliter l adhésion aux différentes normes de sécurités. La conception d application qui seront liés à la plateforme de signature unique sera simplifiée et accélérée puisque les considérations d accès et de connections n ont pas à être gérées. Les caractéristiques mentionnées ci-dessus permettent d avoir une bonne idée des principaux éléments intéressants relatifs aux plateformes de signature unique. Celles-ci seront utilisées afin de permettre d établir les objectifs ainsi que les critères de comparaison afin de vérifier si les différentes plateformes implémentent des caractéristiques qui les exploitent. 1.3.2 Points faibles Pour les mêmes raisons que celles énumérées précédemment, c est-à-dire afin de pouvoir réutiliser ces caractéristiques pour identifier les objectifs et les critères de comparaison, nous avons identifié les principaux points faibles relatifs à l utilisation et l implémentation des plateformes de signature unique. Les sources utilisées pour déterminer les principaux points forts et points faibles des plateformes de signature unique sont les mêmes (Kumar ; Secude, 2010a, 2010b ; Wikipedia, 2010g, 2010a).

9 Notons qu il y a principalement deux critiques qui sont formulées relativement aux plateformes de signature unique. Par exemple, il y a le fait que puisque la plateforme de signature unique donne accès à plusieurs ressources, souvent critiques et accessibles par un seul point d accès, les pertes et les conséquences potentielles peuvent être énormes si quelqu un réussissait à se brancher illicitement (ou encore si les identifiant sont mal configurés ou utilisés). Il faut donc pour minimiser les impacts négatifs, trouver des mécanismes de sécurité efficaces et éprouvés. Le second élément qu il faut surveiller est lié à la disponibilité. En effet, comme la plateforme représente un point d entrée unique de plusieurs systèmes, il faut qu elle soit toujours disponible et fonctionnelle. Autrement dit, si la plateforme est indisponible, aucune application n est disponible. Il faut donc en conséquence pouvoir optimiser la disponibilité et la stabilité de la plateforme.

CHAPITRE II MÉTHODE D ANALYSE 2.1 Démarche relative à l analyse du produit Afin de pouvoir effectuer l analyse des différentes plateformes de signature unique sélectionnées, une démarche méthodique et normalisée sera utilisée. Premièrement, nous allons installer chaque plateforme à analyser dans des sessions virtuelles ayant les ressources nécessaires afin de pouvoir s exécuter. Les sessions virtuelles seront toutes identiques. Donc en contrôlant les réactions et la stabilité de celles-ci lorsque la plateforme de signature unique sera installée et configurée, nous allons obtenir une bonne première impression de chacune d elles. Par la suite, nous allons passer au travers de la matrice des critères (voir section 3.6) et ainsi évaluer pour chaque critère si la plateforme le satisfait. Dans la mesure où l expérimentation ne serait pas possible pour évaluer un critère, nous nous baserions alors sur la documentation disponible et sur la communauté (forums, sites Web, Wiki, courriels de masse) afin de trouver la réponse. À la fin de l évaluation, le pointage final obtenu par la plateforme sera analysé. Le pointage le plus élevé correspondra à la plateforme qui répond le mieux aux besoins. Les sections suivantes donnent le détail relatif à l évaluation des critères. 2.2 Critères généraux Dans le cadre de ce travail, nous allons analyser différentes plateformes de signature uniques et les comparer entre elles à l aide de onze critères définis et documentés à la section

11 2.4. Afin de pouvoir identifier les caractéristiques et les objectifs qui seront utilisés dans ce travail, nous nous sommes basés sur plusieurs sources (Kumar ; Secude, 2010a, 2010b ; Wikipedia, 2010g, 2010a) et plusieurs caractéristiques. D abord nous avons utilisé la liste des points forts et des points faibles déjà identifiés dans la section 1.3 (et les sous-sections 1.3.1 et 1.3.2) afin de composer des caractéristiques qui permettent de d identifier si ceux-ci sont bien implémentés dans la solution à évaluer. Les caractéristiques et les objectifs ainsi identifiés ont par la suite été comparés avec la liste des différentes particularités («features») que l on devrait rechercher dans une plateforme de signature unique (Taylor, 2002). De cette façon, on s assure d évaluer les caractéristiques les plus importantes et critiques pour le choix d une plateforme de signature unique. Évidemment, ce type de critère ne tient pas compte de facteurs plus subjectifs tels que la facilité d utilisation et l élégance de la solution. En conséquence, nous allons pour chaque plateforme voir à commenter ces critères plus subjectifs. Il est à noter que ces critères subjectifs ne seront pas tenus en compte dans la sélection de la plateforme et dans le pointage final de celles-ci. 2.3 Description de l échelle utilisée Pour ce qui est des onze critères d évaluations définis dans les sections suivantes, nous pouvons chiffrer leur satisfaction (ou non). Les différents critères retenus ont été classés selon trois catégories (peu important, important et très important). La justification et les raisonnements relatifs à cette décision, ainsi que la description de chaque critère se retrouvent dans les sections 2.4.1 à 2.4.11. Afin de pouvoir donner une évaluation quantitative de chaque plateforme de signature unique, nous allons donc utiliser une technique très simple qui permettra de voir laquelle des plateformes de signature unique correspondent le mieux à nos besoins.

12 Tel que mentionné précédemment, nous avons identifié douze critères et chacun d eux a été classé selon leur importance. Afin que les critères de moindre importance aient un effet moindre sur la note globale obtenue par une plateforme de signature unique (et vice-versa), nous avons décidé de pondérer chaque critère selon son importance. En conséquent, voici l échelle des pondérations. Tableau 2.1 Pondération associée à l importance d un critère d évaluation Importance Pondération Très important 3 Important 2 Peu Important 1 De plus, un critère est évalué sur un maximum de quatre. La distribution des points pour chaque critère est définit dans les sections 2.4.1 à 2.4.11. Le pointage correspondant à chacun des échelons (la distribution des points) sera défini indépendamment pour chaque critère et chaque sous objectif. Ce qu il faut retenir à ce point c est que plus le plus critère (ou l objectif) est atteint, plus le pointage est grand. Le sous total pour chaque objectif sera comptabilisé en multipliant la pondération par le pointage. Finalement, la note globale d une plateforme de signature unique pourra être calculée en effectuant la somme de la note obtenue pour chaque critère ou sous objectif. Autrement dit : 11 1 (Pondération * Pointage) Figure 2.1 Formule utilisée pour déterminer la note globale

13 Afin de faciliter la compréhension de la méthode d évaluation, nous avons créé un tableau effectuant un sommaire des différentes notes obtenues. Le gabarit est fourni à titre indicatif dans la section 2.5 du présent document. 2.4 Définitions des critères retenus et poids relatif assigné 2.4.1 Compatibilité avec les systèmes de stockage de données (3) Afin de pouvoir les faire fonctionner correctement, les plateformes de signature unique doivent avoir accès à l information des utilisateurs. Cette information est normalement centralisée à l aide de plusieurs techniques et/ou technologies différentes. Ce critère d évaluation a comme principal but d évaluer la possibilité et la facilité avec laquelle la plateforme de signature unique s intègre aux différents systèmes de stockage de données. L importance de ce critère est très grande et par conséquent nous l avons classé dans la catégorie très important et le facteur de pondération est de 3. Dans plusieurs cas, les plateformes de signature unique viennent avec un système de gestion de stockage intégré (LDAP, fichier texte ) afin de faciliter l installation et la configuration de la plateforme. Par contre, ces derniers sont peu adaptés à des environnements très complexes et à demande élevée. Ceux-ci sont peu adaptés puisqu ils ne permettent pas la redondance des serveurs de stockage de données tout en permettant difficilement à des serveurs externes (ou installés en redondance) de se connecter aux données. Finalement, il est presque impossible de déplacer le système de stockage sur un serveur externe. Dans un autre ordre d idées, pour ce qui est des environnements existants, le travail de migration du système de stockage de données existant à celui intégré peut être très problématique. Il est donc important de pouvoir évaluer et reconfigurer la plateforme de signature unique afin de le lier aux systèmes de stockages de données déjà existants (LDAP, Active Directory, SQL, CSV, etc.). Afin d évaluer le critère de compatibilité avec les systèmes de stockage de données, on doit donc tenir compte des facteurs ci haut mentionnés dont l échelle est répartie comme suit :

14 Tableau 2.2 Pointage lié à la compatibilité avec les systèmes de stockage de données. Pointage Définition 0 s il est impossible de lier la plateforme avec un système de stockage de données externe. 1 si la liaison est possible mais que certains modules ou connecteurs ont du être crées afin de rendre le tout compatible. 2 s il est nécessaire de modifier le code source de la plateforme et la structure du système de stockage de données afin de permettre la liaison de ceux-ci. 3 s il est nécessaire de modifier le code source de la plateforme ou la structure du système de stockage de données afin de permettre la liaison de ceux-ci. 4 s il est possible de lier la plateforme avec un système de stockage externe sans effectuer de modification de code ou de modification de structure de données. Dans le cadre de ce travail, nous allons uniquement analyser la liaison de la plateforme de signature unique avec les systèmes de stockages externes LDAP, Active Directory et les systèmes de gestion de bases de données compatibles SQL (principalement MySQL). La raison de ces choix repose sur le fait que ce sont les plus communs pour stocker les informations relatives aux utilisateurs. 2.4.2 Gestion des comptes et des accès (3) Outre le fait de simplifier les accès des utilisateurs, c est-à-dire de minimiser la recapture des mots de passe et de diminuer le nombre de mots de passe différents à retenir, un des très grands intérêts des plateformes de signature unique est de pouvoir centraliser la gestion des comptes utilisateurs. Cette centralisation permet aux administrateurs et au

15 personnel de support de créer, modifier et de supprimer les comptes à partir d un point centralisé. Puisque ce critère est un facteur très important et que sans celui-ci il est impossible d utiliser efficacement la plateforme, nous l avons donc classifié comme étant très important. En conséquence, nous lui avons assigné une pondération de 3. L idée est de faciliter au maximum la gestion des comptes en permettant aux personnels de facilement s y brancher et d effectuer les tâches de base. Évidemment, les moyens d atteindre ces objectifs sont multiples et il est toujours possible de se brancher directement dans le système de stockage de données afin d effectuer ces tâches, mais il serait plus efficace dans ce cas d utiliser une application ou un module externe afin de faire ce travail. Le présent critère veut donc vérifier s il est possible à l aide de l interface web de la plateforme de gérer les comptes utilisateurs et si oui à quel point ce dernier atteint les objectifs de sécurité, d efficacité et d utilisation. Il est à noter que dans le cas de l évaluation de ce critère, le pointage est cumulatif. En conséquent, le maximum potentiel est de 4 et le minimum est de 0. Voici donc comment nous allons identifier le pointage relatif à ce critère. Tableau 2.3 Pointage lié à la gestion des comptes et des accès. Pointage Définition 1 Il est possible de visualiser la liste des utilisateurs. 1 Il est possible de visualiser les données liés à chaque compte utilisateur (par exemple : nom, prénom, nom d utilisateur, département, les accès) à chaque utilisateur. 1 L option est graphique et basé Web. 1 Il est possible d éditer l information (modifier les comptes ou les accès) sans passer par un outil externe.