IDENTITÉ DIGITALE FÉDÉRÉE

Transcription

1 Informatique de gestion HEG Genève Laboratoire de Technologies Objet Campus de Battelle Bâtiment F Route de Drize 7 CH-1227 Genève Tél : Fax : IDENTITÉ DIGITALE FÉDÉRÉE RAPPORT DÉTAILLÉ Projet déposé dans le cadre du programme de la réserve stratégique de la HES-SO Novembre 2006 Sous la direction de Peter DAEHNE, professeur HES

2 Informatique de gestion ISNET 76 TABLE DES MATIÈRES 1 Le problème Les enjeux pour l'entreprise La sécurité Les failles Le Single Sign-On Le cas d'internet Intranet Extranet Au-delà de l'entreprise Spécifications de Liberty Alliance Le concept d'identité Les objectifs Identité réseau fédérée Cercle de confiance L'architecture Le module ID-FF Autres modules Conformité des implantations Liberty Interoperable Tests de conformité Produits inter opérables Mise en œuvre Concepts Le fournisseur de service Le fournisseur d'identité Le client Composants matériels et logiciels nécessaires Logiciel Matériel Implantation La cible Architecture du système Accès aux services

3 Informatique de gestion ISNET Authentification Logiciel Systèmes Microsoft Windows Procédure Modèle business Cadre Type d'échange Innovation produit Gestion de l'infrastructure Relation client Aspects financiers Prototypes Conclusion Bibliographie

4 Informatique de gestion ISNET 76 TABLE DES FIGURES Fig. 1.1 : Le dilemme entre accessibilité de l'information et exigences de sécurité... 6 Fig. 1.2 : Les multiples identifications d'un utilisateur... 7 Fig. 1.3 : Identification d'un utilisateur sur différents systèmes interconnectés... 9 Fig. 1.4 : Single Sign-On d'un utilisateur sur un ensemble de systèmes interconnectés 10 Fig. 1.5 : Succession des opérations dans un contexte single sign-on / intranet Fig. 2.1 : Les attributs définissant l'identité d'un utilisateur Fig. 2.2 : Première connexion d'un utilisateur dans un environnement fédéré Fig. 2.3 : Première connexion auprès d'un partenaire du même cercle de confiance Fig. 2.4 : Architecture modulaire générale Fig. 3.1 : Logo certifiant la conformité du produit aux spécifications Fig. 4.1 : Les acteurs de la fédération d'identité Fig. 4.2 : L'architecture du système informatique des entreprises considérées Fig. 4.3 : La nouvelle architecture du système Fig. 4.4 : Étapes de la mise en conformité du système avec la fédération d'identités Fig. 5.1 : Les piliers des modèles business

5 Informatique de gestion ISNET 76 1 LE PROBLÈME Aujourd'hui, l'internet est devenu le principal moyen de communication et d'échange d'informations de notre société. Tout individu équipé d'un ordinateur et d'une ligne de communication 1 peut accéder aux nombreux services proposés par ce média. Son ubiquité a naturellement séduit les entreprises et les administrations qui se sont appuyées sur ce formidable moyen de communication pour développer toutes sortes de services en ligne. Certains de ces services sont destinés au grand public. Le tout premier d'entre eux est bien sûr la messagerie 2 ; mais l'usager peut également employer l'internet pour administrer son compte bancaire, gérer son portefeuille d'actions et ses investissements, payer ses factures, opérer des transactions immobilières, effectuer des achats de vêtements, de films, de musique, etc. D'autres sont à usage interne de l'entreprise qui les utilise pour accomplir sa mission. Parmi ceux-ci, on peut citer l'interconnexion des divers départements et succursales dans un contexte d'architecture distribuée, le télétravail des employés, le contact avec les collaborateurs mobiles ainsi que les relations commerciales avec les fournisseurs et/ou les clients ou encore la gestion de la connaissance 3. Notons encore que l'internet est un vecteur fondamental pour toutes les entreprises, qu'elles soient des SSCI 4 ou non, qui confient la réalisation de leurs développements informatiques à des tiers 5 ; ces derniers sont en effet souvent localisés à l'autre bout du monde. Remarquons enfin que, ces dernières années, la fonction de l'internet a évolué de l'interconnexion d'ordinateurs vers l'interconnexion d'applications et de services. Le nombre de clients ainsi que le nombre de dispositifs et points d'accès à ces applications et services ont également explosé. 1.1 Les enjeux pour l'entreprise Parallèlement à l'essor de l'internet et des systèmes de communication, les plateformes logicielles et matérielles des entreprises se sont multipliées. Pour faire face à la demande croissante de services en ligne, tant de la part des usagers que des collaborateurs et partenaires de l'entreprise, de nouveaux systèmes ont dû être développés. Les entreprises se sont donc retrouvées confrontées au problème de la gestion efficace de nombreux systèmes devant être déployés, maintenus et intégrés à un nombre croissant de réseaux et de plateformes différents. 1 Cette ligne de communication peut être la ligne fixe du téléphone, une connexion via un réseau coaxial ou hertzien, un réseau d'entreprise ou encore une connexion mobile. 2 Historiquement s'entend, mais ces services se sont également développés en direction de la messagerie instantanée ou encore de la vidéoconférence. 3 Cette liste est bien sûr loin d'être exhaustive. Régulièrement de nouvelles applications de l'internet ayant pour objectif d'améliorer la productivité, la performance et la visibilité de l'entreprise voient le jour. 4 SSCI : Société de Services et de Conseils en Informatique. 5 Outsourcing. 5

6 Informatique de gestion ISNET 76 Simultanément à ce défi de gestion, elles ont dû affronter, de la part d'usagers et de partenaires commerciaux de plus en plus dynamiques, des exigences toujours croissantes en matière de quantité, qualité, actualité et disponibilité d'information. Les départements informatiques furent soumis à une forte pression de la part de leur management pour qu'ils augmentent et améliorent l'accès à l'information tant pour les collaborateurs 6 que pour les partenaires et clients de l'entreprise 7. Ces exigences les ont conduits à réévaluer tant l'architecture du système d'information que la sécurisation de l'accès à ce système. En effet, les parties en présence sont très hétéroclites, jouissent de droits d'accès aux informations très variés et désirent par ailleurs communiquer de manière dynamique et transparente. Le dilemme 8 qui se présente alors est le suivant : comment concilier à la fois une diffusion à grande échelle de l'information avec les exigences de sécurité et de confidentialité nécessaires à la préservation des secrets de l'entreprise et à la bonne marche des affaires. Accessibilité Disponibilité Utilisabilité Expérience Transparence Contrôle Consistance Risque Responsabilité Coût Fig. 1.1 : Le dilemme entre accessibilité de l'information et exigences de sécurité [Nor02]. L'enjeu majeur de cette situation pour l'entreprise est la maîtrise des coûts engendrés par la mise en place d'une architecture ayant les caractéristiques requises pour satisfaire à ces spécifications. La figure 1.1 illustre cette situation. 1.2 La sécurité La sécurisation de l'accès aux informations vitales de l'entreprise, nous l'avons vu, est une des composantes principales des défis que doit relever l'entreprise dont le 6 Intranet. 7 Extranet. 8 Désigné dans [Nor02] par le terme : the IT dilemma. 6

7 Informatique de gestion ISNET 76 système d'information s'appuie sur des réseaux ouverts au public, en particulier Internet. Pour les services accessibles à travers le réseau, la principale mesure de sécurité généralement mise en place est l'authentification de l'identité de l'utilisateur. Nous ne discuterons pas ici des autres mesures qui doivent impérativement être prises, parmi lesquelles on peut citer non exhaustivement : la sécurisation physique de l'accès aux locaux hébergeant le matériel lui-même, le cryptage des informations confidentielles transmises ainsi que la mise en place de pare-feux protégeant le réseau de l'entreprise contre les intrusions malveillantes et les virus. Le fournisseur du service doit s'assurer qu'un client 9 qui a recours à ce service est un utilisateur autorisé et non pas un imposteur. C'est dans ce contexte qu'interviennent les concepts de nom d'utilisateur et de mot de passe ; en fournissant au service un couple nom d'utilisateur/mot de passe valide, le client fait état de son identité et prouve ainsi qu'il dispose des autorisations et des droits d'accès requis pour bénéficier des fonctionnalités offertes par le service. 1.3 Les failles Dans le contexte actuel, un utilisateur standard d'un réseau d'entreprise peut posséder des dizaines d'identifications (voir : figure 1.2 ci-dessous) qu'il utilise pour accéder aux divers sites, portails, applications et services qu'il emploie, tant pour gérer ses affaires privées que pour accomplir les tâches de son cahier des charges d'employé d'une entreprise. Fig. 1.2 : Les multiples identifications d'un utilisateur. 9 Le client en question peut être un soit utilisateur physique soit un utilisateur virtuel, à savoir une application qui requiert des informations de façon automatique en invoquant le service. 7

8 Informatique de gestion ISNET 76 Pour chacune des applications avec lesquelles il interagit, il doit non seulement définir un couple nom d'utilisateur/mot de passe, mais encore s'en souvenir. Il doit de plus composer avec le fait que les règles imposées par les différents points d'accès pour la définition de ces informations varient grandement. Ces variations peuvent porter sur le nombre minimal de caractères nécessaires ou encore sur les combinaisons de caractères alphabétiques et numériques ainsi que les changements de casse imposées. L'existence de ces différentes règles fait qu'il est dès lors pratiquement impossible, pour des raisons de convenance et de facilité de mémorisation, de définir à chaque fois le même couple nom d'utilisateur/mot de passe. La tentation est alors grande pour l'utilisateur de noter ces informations d'identification, soit sous forme manuscrite, soit sous forme électronique 10, soit encore de les faire mémoriser par le navigateur Internet de son poste de travail. Si de plus l'utilisateur est amené à changer souvent de poste de travail, cette dernière solution aura pour effet de laisser les traces de ces informations d'identification sur chacun des postes employés. Ces comportements fautifs et inconsidérés des utilisateurs sont induits par la jungle d'informations d'identification avec lesquels ils doivent composer tous les jours. Ils créent ainsi des failles dans le système de sécurité, justement en raison du fait que la plupart des applications auxquelles ils sont confrontés quotidiennement sont sécurisées. Il devient dès lors clair que trop de sécurité tue la sécurité. Si la multiplication des procédures d'identification que l'utilisateur doit subir tout au long de la journée est éventuellement supportable pour un usager privé, elle est contraire aux règles élémentaires de l'ergonomie, et, lorsque cet utilisateur est un employé d'une entreprise, elle a tendance à le lasser et finit par le rendre nettement moins productif. 1.4 Le Single Sign-On Comme nous l'avons vu, l'interconnexion des systèmes dans les entreprises complique singulièrement la tâche d'un utilisateur qui doit s'identifier auprès de chaque application qu'il emploie pour effectuer sa tâche. Lorsque l'application en cours d'utilisation en référence une autre dont elle requiert un service ou des informations 11, l'utilisateur doit également s'identifier auprès de cette dernière 12. À chaque fois, il sera soumis à une procédure interactive d'identification au cours de laquelle il va être amené à fournir des couples nom d'utilisateur/mot de passe éventuellement différents. L'administrateur du système devra quant à lui gérer des comptes ainsi que les droits qui y sont associés pour chacune des applications employées dans l'accomplissement de la mission de l'entreprise. Ces comptes devront être gérés de manière coordonnée, de telle sorte que l'intégrité globale du système de sécurité soit garantie. Le scénario que nous venons de décrire est illustré par la figure Ces informations peuvent aussi bien être mémorisées dans un simple fichier texte du poste de travail que sur un post-it électronique déposé sur le bureau ou encore dans un PDA ou un téléphone portable. 11 Cette situation est illustrée sur la figure 1.3 où l'application du domaine 1 invoque un service de l'application du domaine Cette seconde identification peut être requise longtemps après le démarrage de la première application. Le système la demandera au moment où l'application principale invoquera effectivement le service auprès de la seconde. 8

9 Informatique de gestion ISNET 76 Une telle architecture est en général la conséquence de l'histoire de l'entreprise 13 et de l'informatisation progressive de ses diverses missions. Les divers composants du système global ont été peu a peu assemblés et leur intégration s'est effectuée par juxtaposition des différentes applications existantes ou nouvellement développées 14. Domaine 1 Identification Domaine 1 Informations des comptes du domaine 1 Application Domaine 1 Utilisateur Identification Domaine k Identification Identification Domaine 3 Domaine Application 2 Domaine k Application Application Domaine 3 Domaine 2 Domaine k Domaine 3 Domaine 2 Informations des comptes du domaine 2 Administrateur du système Fig. 1.3 : Identification d'un utilisateur sur différents systèmes interconnectés. La croissance de tels systèmes hétéroclites, la dégradation de l'ergonomie générale pour l'utilisateur et la baisse du niveau de sécurité engendrée par la multiplication des procédures d'identification ont favorisé le développement de nouveaux services dont l'objectif est de favoriser la coordination et l'intégration des fonctions d'identification et d'administration des comptes à travers l'ensemble des domaines de gestion de l'entreprise. Un tel service est susceptible de rentabiliser réellement les coûts d'exploitation en : diminuant le temps passé par les utilisateurs à s'identifier auprès des différents domaines et en réduisant les possibilités que cette opération échoue ; améliorant considérablement la sécurité du système par le fait qu'un utilisateur ne doit plus se rappeler de nombreux couples nom d'utilisateur/mot de passe ; réduisant le temps que les administrateurs du système doivent consacrer à la création et à la suppression des différents comptes ainsi qu'à la gestion des droits qui y sont associés ; augmentant l'intégrité du système de sécurité par le fait que les administrateurs gèrent les comptes utilisateurs de façon globale en leur attribuant de manière consistante les droits d'accès à l'ensemble des ressources qui leur sont nécessaires. 13 Existence d'unlegacy System, c'est-à-dire d'un assemblage hétérogène d'applications développées progressivement durant l'existence de l'entreprise et héritées du passé. 14 Nous pouvons même nous trouver face à des applications fonctionnant sur des plateformes matérielles différentes, mues par des systèmes d'exploitation différents. 9

10 Informatique de gestion ISNET 76 Ce service a été baptisé Single Sign-On en référence à la perception de l'impact qu'en ont les utilisateurs finaux ; remarquons toutefois que l'aspect gestion des comptes est tout aussi important que celui du confort de l'utilisateur. La figure 1.4 illustre le principe de fonctionnement de cette approche. Domaine 1 Utilisateur Identification Domaine 1 Application Domaine 1 Identification Domaine k Identification Identification Domaine 3 Domaine Application 2 Domaine k Application Application Domaine 3 Domaine 2 Informations des comptes du domaine 1 Domaine k Domaine 3 Domaine 2 Informations des comptes du domaine 2 Système de gestion des comptes Administrateur du système Fig. 1.4 : Single Sign-On d'un utilisateur sur un ensemble de systèmes interconnectés. Dans ce contexte, l'utilisateur s'identifie une seule fois auprès du domaine sous le contrôle duquel s'exécute l'application principale qu'il emploie. À cette occasion, il peut être amené à fournir des informations supplémentaires qui prouveront qu'il possède également les droits d'accès aux domaines secondaires auxquels son application fera référence pour accomplir sa tâche. Ces informations sont transmises au service de gestion du Single Sign-On qui se charge ensuite de l'authentification automatique de l'utilisateur auprès de tous les domaines auprès desquels celui-ci jouit de droits d'accès. Une relation de confiance a ainsi été établie entre le domaine d'identification de l'utilisateur et ceux auxquels il accède par la suite. Ce modèle simplifie grandement la tâche des administrateurs du système lors de la gestion des comptes des utilisateurs. Ils ne sont en effet confrontés plus qu'à un seul logiciel d'administration 15 au moyen duquel les identifications pour l'ensemble des domaines du système d'information de l'entreprise peuvent être gérées de façon coordonnée et synchronisée. D'un point de vue technique, les informations d'identification échangées entre le domaine principal d'identification et les domaines secondaires en raison de la relation de confiance devront être protégées d'une éventuelle interception, particulièrement si ces informations transitent par des réseaux publics. Celles-ci peuvent en effet être employés par des tiers malveillants pour s'introduire de façon non autorisée dans le système d'information de l'entreprise. 15 Dans les versions les plus modernes de ce service, le logiciel d'administration des comptes utilisateurs s'appuie sur un service d'annuaire qui, entre autres, répertorie et se charge de la gestion des informations concernant les utilisateurs. 10

11 Informatique de gestion ISNET 76 À partir du moment où un tel service est déployé pour gérer l'ensemble des identifications nécessaires aux applications de l'entreprise, l'employé peut être muni d'un unique badge qui lui permettra non seulement de s'identifier auprès du système d'information au moyen d'un lecteur idoine, mais aussi de commander les portes d'accès sécurisées aux locaux de l'entreprise. Le danger de la communication éventuelle, volontaire ou non, d'un mot de passe à un tiers est alors complètement écarté. 1.5 Le cas d'internet L'approche que nous venons de décrire est pertinente tant du point de vue logistique qu'économique. Elle est relativement facile à mettre en place pour le système d'information d'une entreprise 16 ou pour celui d'un ensemble d'entreprises faisant partie d'un même groupe 17. Nous avons vu plus haut que l'internet prenait une place de plus en plus importante dans la connexion des systèmes d'entreprises, ceci tant pour l'interaction avec les collaborateurs que pour celle avec les clients et/ou les fournisseurs. Les applications du système d'information informatisé d'une entreprise moderne sont également largement déployées en s'appuyant sur le réseau des réseaux. Le problème de l'identification se pose alors de manière encore plus accrue. En effet, les utilisateurs doivent non seulement s'identifier auprès des applications de l'entreprise, mais aussi auprès de portails, de fournisseurs de services, etc Intranet Dans le cas de l'intranet, la situation est relativement semblable à celle du système d'information interne à l'entreprise. En effet, l'ensemble des applications et services ainsi que le service de gestion des comptes sont, en principe, sous le contrôle total de l'entreprise. Il est donc relativement aisé de définir une architecture du système adaptée aux besoins de gestion de l'identification des utilisateurs de telle sorte que ces derniers n'aient besoin de s'identifier qu'une seule fois pour avoir accès aux diverses ressources de l'intranet 18. Une architecture possible du système pourrait être conçue en s'appuyant sur le modèle suivant : La gestion des accès est contrôlée par un service spécialisé : le gestionnaire d'accès. Celui-ci est déployé sur un serveur Web ou encore hébergé par le serveur d'applications. Il est responsable de contrôler de façon centralisée l'ensemble des accès des utilisateurs aux divers services mis à disposition par l'intranet. Pour la vérification des autorisations d'accès, celui-ci s'appuie sur un 16 Remarquons toutefois que l'impact économique du cas particulier de l'adaptation d'applications anciennes dont le mécanisme d'authentification est profondément enterré dans le code peut être non négligeable, voire prohibitif. 17 Ce n'est pas toujours le cas bien sûr. Nous pourrions citer comme exemple certains grands groupes du luxe français qui sont constitués d'une telle myriade d'entreprises différentes qu'il est pratiquement impossible pour eux d'intégrer les systèmes d'information spécifiques de chaque enseigne. La grande mobilité du secteur fait par ailleurs que cette intégration n'est pas toujours un objectif stratégique, bien au contraire. 18 L'adaptation d'une architecture de gestion des droits ad hoc héritée du passé et conçue sans dessein global peut toutefois se révéler difficile. 11

12 Informatique de gestion ISNET 76 système de gestion des comptes semblable à celui que nous avons décrit plus haut 19. Les différents domaines et applications représentés dans les figures 1.3 et 1.4 sont également déployés sur des serveurs Web. À chaque domaine est associé un contrôleur d'accès fonctionnant en collaboration avec le gestionnaire d'accès. Le contrôleur d'accès est responsable de la reconnaissance d'un utilisateur déjà identifié ainsi que de la vérification des droits d'accès de cet utilisateur au domaine et/ou à l'application. Lorsqu'un utilisateur est reconnu par le système, le gestionnaire d'accès lui ouvre une session 20 et ses informations d'identification ainsi que la description de ses droits d'accès sont représentés par un jeton qui est en général implanté au moyen d'un cookie. Il n'est pas nécessaire que les serveurs Web mentionnés soient tous différents ni qu'ils résident sur des machines différentes. L'architecture décrite peut très bien résider sur une seule machine physique sous le contrôle d'un seul serveur Web. La figure 1.5 illustre la succession des opérations engendrées par une session de travail d'un utilisateur s'identifiant dans un contexte de single sign-on au sein d'une telle architecture. Contrôleur d'accès Contrôleur d'accès Utilisateur Application 1 Gestionnaire d'accès Application 2 1. Demande d'accès 2. Jeton présent? 3. Redirection page login 4. Authentification et création du jeton 5. Redirection vers la page originale avec jeton 6. Répétition demande Jeton présent? 8. Autorise ou refuse l'accès 9. Autre demande d'accès 10. Jeton présent? 11. Autorise ou refuse l'accès Fig. 1.5 : Succession des opérations dans un contexte single sign-on / intranet [PaB04] Voir chapitre La session a en général une durée limitée. 21 Cette architecture est celle qui est mise en place par Java Sun Access Manager qui est le module du serveur d'applications de Sun Microsystems responsable de la gestion des authentifications d'utilisateurs. Il ne s'agit toutefois pas d'une solution originale ; la plupart des solutions de single sign-on déployées dans le cadre de solutions intranet et/ou internet fonctionnent en se basant sur une architecture semblable. 12

13 Informatique de gestion ISNET 76 Description du processus de la figure L'utilisateur demande l'accès à une application de l'intranet auprès de laquelle il faut s'identifier et pour laquelle il faut disposer de droits d'accès. 2. Le contrôleur d'accès installé sur le serveur Web hébergeant l'application intercepte la requête de l'utilisateur et vérifie si celui-ci dispose d'un jeton d'identification valide muni des droits d'accès adéquats. 3. En cas d'absence du jeton, le contrôleur d'accès redirige le navigateur Web de l'utilisateur vers une page de login à laquelle l'url de la requête originale est passée comme paramètre. 4. L'utilisateur s'identifie auprès du gestionnaire d'accès 22. Celui-ci crée alors une session pendant la durée de laquelle l'utilisateur est identifié avec tous ses droits ainsi qu'un jeton mémorisant ces informations. 5. Le gestionnaire d'accès envoie le cookie contenant le jeton au navigateur de l'utilisateur et redirige ce dernier vers l'url mémorisée et reçue lors des opérations 3. et Suite à cette redirection, la requête d'accès initiale à l'application est à nouveau effectuée. 7. Comme lors de l'opération 2., le contrôleur d'accès installé sur le serveur Web hébergeant l'application intercepte la requête et vérifie que l'utilisateur possède un jeton valide. 8. Si le jeton de l'utilisateur est muni des droits nécessaires pour accéder à l'application, la page demandée est retournée à son navigateur, dans le cas contraire, l'accès lui est refusé. 9. L'utilisateur peut ensuite effectuer des requêtes d'accès à d'autres applications sous le contrôle du gestionnaire d'accès. 10. L'utilisateur est ici muni d'un jeton valide (obtenu lors de l'opération 4.), il n'aura donc pas besoin de s'identifier à nouveau. 11. L'accès à l'application est autorisé ou refusé par le contrôleur d'accès en fonction des droits dont dispose l'utilisateur. Le processus peut se répéter tant que l'utilisateur est muni d'un jeton valide ; toutes ses requêtes seront en effet accompagnées du jeton que le gestionnaire d'accès lui a fourni lors de l'opération 4. Les différents contrôleurs d'accès associés aux applications accessibles depuis l'intranet autoriseront ou refuseront l'accès en fonction des droits associés au jeton, sans que l'utilisateur ait besoin de s'identifier à nouveau. Le processus se termine lorsque la session expire ou lorsque l'utilisateur effectue explicitement une procédure de déconnexion. La circulation du cookie contenant le jeton au travers du réseau est le point critique du point de vue de la sécurité d'une telle architecture. On peut aisément se protéger contre un vol du jeton en l'encryptant. Le gestionnaire d'accès peut également émettre des jetons à usage unique pour chaque ressource dont il gère l'accès. 22 Cette identification peut s'effectuer en fournissant un couple (nom d'utilisateur, mot de passe) valide ou, comme nous l'avons vu plus haut dans le chapitre 1.4, au moyen d'un badge, d'une smartcard, d'un certificat émis par le navigateur Web ou encore par des moyens d'identification biométriques. 13

14 Informatique de gestion ISNET Extranet La résolution du problème du single sign-on dans le cas de l'extranet est plus problématique. Dans ce contexte, les applications auxquelles un utilisateur est susceptible d'avoir accès pour effectuer sa mission sont en général détenues par des entreprises différentes. En effet, le gestionnaire d'un garage peut par exemple avoir accès aux applications de sa banque pour effectuer et vérifier ses paiements, aux applications de son entreprise pour émettre et gérer ses factures, à celles de plusieurs fournisseurs de pièces détachées pour commander les pièces nécessaires à l'entretien des véhicules dont il représente la marque, à celles des entreprises dont il assure l'entretien de la flotte, etc. Techniquement, le problème peut se résoudre en mettant en place une architecture pratiquement identique à celle que nous avons décrite dans le chapitre ci-dessus 23. Le problème principal réside dans le fait que le gestionnaire d'accès est l'élément central de cette architecture. Ce dernier doit en effet avoir la connaissance des informations d'identité des différents utilisateurs employant les applications contrôlées par les contrôleurs d'accès qui lui sont associés. Or, les utilisateurs sont répartis dans les différentes entreprises qui mettent à disposition les applications que nous avons mentionnées dans notre exemple. Ces entreprises considèrent en général que les informations concernant leurs employés sont vitales pour leur fonctionnement et, par conséquent, voient leur diffusion à des tiers d'un assez mauvais œil. De même, elles répugnent assez naturellement à renoncer au contrôle de la gestion de l'accès à leurs applications ou à déléguer celui-ci. Pour mettre en place une telle architecture, il sera nécessaire que les entreprises partenaires concluent des accords bilatéraux, voire multilatéraux qui spécifieront explicitement les conditions de mise à disposition des informations concernant les utilisateurs, la répartition des responsabilités dans les gestion de ces informations d'identité, les procédures de définition des droits d'accès, etc. S'il est certainement possible d'envisager une telle solution lorsqu'on se trouve en présence de deux ou trois entreprises différentes, il devient franchement impossible de le faire lorsque le nombre de protagonistes augmente. La cause principale de l'impasse sera presque toujours le problème de la mise à disposition d'informations cruciales pour le métier de l'entreprise dans le cadre d'une association dont les participants sont souvent également concurrents. Remarquons tout de même que si les entreprises appelées à collaborer dans une architecture de ce type font partie d'un même groupe, les principales objections relevées ci-dessus ne sont plus pertinentes Notons tout de même qu'un système plus sophistiqué que les cookies devra être mis en place pour la transmission et l'échange des jetons contenant les informations d'identification et les différents droits d'accès. En effet, l'usage d'un cookie est, de par la définition même du concept de cookie, limité à un seul nom de domaine Internet (DNS). 24 Certains groupes se prêtent bien sûr mieux que d'autres à de telles collaborations entre les différentes entreprises qui les composent. Toutefois, lorsqu'on est en présence d'un secteur d'activité à forte mobilité, comme par exemple le luxe (LVMH, Richemond, Prada, PPR, ), il est fort possible que cette collaboration aille à l'encontre de la stratégie générale du groupe, principalement en raison des liens de dépendance qui sont alors, de facto, créés. 14

15 Informatique de gestion ISNET Au-delà de l'entreprise Nous venons de montrer comment la multiplication des partenaires rendait problématique la mise en commun d'informations en vue de gérer l'accès aux différents sites concernés via une procédure de single sign-on. Les systèmes, les réseaux physiques par lesquels transitent les informations et même parfois les postes de travail sont différents ; le contrôle de tous ces éléments est réparti entre les différents acteurs concernés. De plus, la centralisation de la gestion de l'identification des utilisateurs d'une application et/ou d'un système en augmente considérablement la vulnérabilité et la sensibilité aux attaques extérieures. En effet, une telle architecture possède un unique composant critique du point de vue de la sécurité : la base de données mémorisant les informations d'authentification des utilisateurs 25. Un viol de cette base de données peut être exploité par des pirates pour effectuer des opérations non autorisées sur l'ensemble des sites et applications contrôlés par le processus d'identification 26. Toutes ces raisons mettent en évidence l'importance qu'il y a de concevoir un nouveau modèle, s'affranchissant des contraintes imposées par une gestion centralisée du processus d'identification. 25 Cette base de données contient non seulement les informations privées se rapportant aux différents utilisateurs du système, mais également le ou les mots de passe qui leur sont associés ainsi que la description des droits d'accès aux différents sites et applications du système dont ceux-ci disposent. 26 Single sign-on = single point of failure. 15

16 Informatique de gestion ISNET 76 2 SPÉCIFICATIONS DE LIBERTY ALLIANCE La Liberty Alliance est un consortium qui a été créé en décembre 2001 par un groupe d'environ 30 entreprises. Leur objectif commun était de définir un ensemble de bonne pratiques et de standards ouverts permettant une gestion fédérée de l'identité et prenant en compte les besoins actuels et futurs des individus et des entreprises dans un environnement où les applications et les services sont déployés sur l'internet 27. Cet objectif a été atteint dès 2002, date de la publication des premières spécifications définissant les fondations de la gestion de l'identité dans un environnement hétérogène et distribué. Depuis lors, de nombreuses entreprises, actives dans des domaines aussi divers que les technologies de l'information, la finance, les télécommunications, les médias, l'industrie ou encore les organisations gouvernementales, ont rejoint le consortium. Celui-ci comprend actuellement plus de 150 entreprises. 2.1 Le concept d'identité L'identité d'un individu n'est pas seulement définie par les nom, prénom et date de naissance qu'il acquiert à sa venue au monde. Elle évolue au fur et à mesure de l'interaction de l'individu avec la société qui l'entoure et les organisations (administrations, entreprises, etc.) auxquelles il a recours. À ces contacts, elle s'enrichit d'informations nouvelles, pertinentes pour ces interlocuteurs. Utilisateur Nom: Jean DUPOND jd@abc.ch Identification Passeport: Permis: A, B, F4 Fonction: directeur des RH Préférences Musique: Jazz, Disco Train: Silence, marche Fumeur: oui Langues: français, anglais... Fig. 2.1 : Les attributs définissant l'identité d'un utilisateur. On distingue principalement les caractéristiques d'identification pures de celles qui définissent des attributs plus informels tels que les goûts ou les préférences d'un individu [LaA03]. Les caractéristiques d'identification sont définies par des organismes gouvernementaux 28, des entreprises 29 et par la biométrie 30 de l'individu 27 "The Liberty Vision : To enable a networked world in which individuals and businesses can more easily conduct transactions while protecting the privacy and security of vital identity information" [LaB03]. 28 Parmi celles-ci, on peut noter principalement le numéro de passeport, les différents permis de conduire détenus, le numéro AVS ou encore le numéro de contribuable. 16

17 Informatique de gestion ISNET 76 lui-même. Les préférences sont en général inhérentes à l'individu 31, à son comportement ou encore à son environnement 32. Un désignera par identité (d'un individu) l'ensemble des caractéristiques énoncées ci-dessus 33. Aucune entité, qu'elle soit réelle ou virtuelle, qui est en relation avec l'individu n'en mémorise toutes les informations constitutives de l'identité. C'est la nature de la relation que l'individu entretient avec l'entité qui détermine quelles sont les informations pertinentes susceptibles d'être échangées entre les deux parties en présence. Les informations échangées devraient être réduites à un strict sous-ensemble nécessaire et suffisant pour que la relation entre l'individu et l'entité puisse se dérouler à la satisfaction des deux parties. Les raisons principales de cette restriction sont la protection de la sphère privée et des considérations de sécurité. 2.2 Les objectifs Les objectifs principaux poursuivis par les spécifications éditées par la Liberty Alliance sont [Was05] : de permettre aux utilisateurs d'un réseau d'employer une identité digitale en assurant la protection de leur sphère privée ainsi que la sécurité de leurs transactions ; de permettre aux entreprises de gérer et d'administrer les relations qu'elles entretiennent avec leurs clients sans intervention de tiers ; de définir un standard ouvert de single sign-on qui permet aussi bien une authentification décentralisée que l'obtention d'autorisations d'accès auprès de plusieurs fournisseurs différents ; de créer une infrastructure de gestion de l'identité en réseau qui prenne en compte tous les dispositifs d'accès au réseau, actuels et émergents 34. Dans le monde de l'internet, la protection de la sphère privée et le contrôle de l'identité sont d'une importance capitale. D'un coté, les entreprises désirent avant tout assurer la sécurité des transactions effectuées, de l'autre coté, les utilisateurs ont des exigences ergonomiques telles que la simplicité d'emploi et l'accès rapide aux informations. Il s'agit donc de définir un modus vivendi qui satisfait à la fois les exigences des entreprises et celles des utilisateurs. 29 Les informations associées par les entreprises aux individus comprennent notamment le statut de l'employé au sein de l'entreprise, sa fonction ou encore le nom d'utilisateur qui lui est attribué pour accéder au système d'information de l'entreprise. 30 Les informations biométriques usuellement répertoriées sont les empreintes digitales et/ou rétiniennes ainsi que l'adn de l'individu. 31 Parmi celles-ci, on peut trouver les préférences musicales, celles relatives à la position préférée de l'individu dans un train (sens de la marche ou non, fumeur ou non fumeur, wagon silence, etc.), l'historique de ses achats auprès d'une entreprise de vente en ligne, son dossier médical, etc. 32 Numéros de téléphone, adresse, langues comprises et parlées, type de terminal mobile employé, etc. 33 Voir aussi figure En particulier, cette gestion ne devrait pas nécessiter des modifications du logiciel d'accès à Internet employé (et devrait donc être compatible avec les browsers du marché). 17

18 Informatique de gestion ISNET 76 La réponse de Liberty Alliance à ces problèmes est la définition du concept d'identité réseau fédérée 35. Ce concept permet principalement de définir une association entre les différentes identités qu'un utilisateur peut posséder au sein d'un réseau. 2.3 Identité réseau fédérée Le concept d'identité fédérée procure aux utilisateurs un processus d'identification simplifié pour employer les ressources pour lesquelles ils bénéficient de droits d'accès. Un stockage centralisé des informations personnelles d'identité n'est plus nécessaire ; la vulnérabilité des systèmes aux attaques malicieuses s'en trouve ainsi diminuée. Un utilisateur s'identifie une seule fois et peut contrôler les attributs de son identité 36 qui sont mémorisés par les différents fournisseurs de services. Ceux-ci ne stockent donc que les informations qui sont strictement nécessaires à la fourniture du service demandé. L'utilisateur bénéfice ainsi d'un confort d'utilisation des systèmes accru ainsi que d'un contrôle fin des informations qu'il divulgue. Les fournisseurs de services peuvent aisément personnaliser l'interaction qu'ils entretiennent avec l'utilisateur en fonction des informations d'identité recueillies. Quant aux entreprises, elles peuvent mener des transactions commerciales avec des clients, des partenaires et des employés formellement authentifiés. Ils ont ainsi la garantie que leurs interlocuteurs sont bien ceux qu'ils prétendent être. 2.4 Cercle de confiance Le concept de cercle de confiance 37 définit un ensemble de fournisseurs de services qui partagent des identités réseau et qui sont liés par un contrat spécifiant les conditions sous lesquelles ces identités sont partagées. Les règles principales régissant ce partage sont [LaA03] : il existe un contrat clair entre les fournisseurs de services comme mentionné ci-dessus ; les utilisateurs sont avertis quelles sont les informations les concernant qui sont mémorisées par le système et doivent donner un accord formel autorisant leur stockage ; la notification à l'utilisateur et son accord sont mémorisés par le système en vue d'audit. Un utilisateur qui s'identifie auprès d'un fournisseur de services faisant partie d'un cercle de confiance sera automatiquement reconnu par les autres membres ayant adhéré au cercle. De plus, seules les informations strictement nécessaires à la gestion des droits de l'utilisateur seront mémorisées localement auprès des autres membres du cercle de confiance. 35 Federated network identity. 36 Voir chapitre Il est à noter que ce concept n'a rien de nouveau. En effet, c'est exactement le type d'accord qui liait à l'origine les différents partenaires de la Lloyd's de Londres. 18

19 Informatique de gestion ISNET 76 Une session d'un utilisateur à partir du poste de travail de son entreprise peut alors donner lieu à différents cas d'utilisation. La figure 2.2 illustre le processus qui se déroule lors de la première connexion d'un utilisateur dans un environnement fédéré. Fig. 2.2 : Première connexion d'un utilisateur dans un environnement fédéré. Première connexion d'un utilisateur (figure 2.2) : 0. Un contrat régissant les conditions du partage d'identité des utilisateurs est conclu entre l'entreprise est ses divers partenaires. 1. Un utilisateur se connecte via son browser Internet depuis un poste de travail de l'entreprise, usuellement en fournissant au système un nom d'utilisateur et un mot de passe. 2. Le serveur d'authentification vérifie les informations de connexion fournies par l'utilisateur. S'il est reconnu, il est considéré comme authentifié par le système. 3. L'entreprise faisant partie d'un cercle de confiance, le serveur d'identité permet à l'utilisateur de choisir s'il désire recevoir des propositions de fédération de la part des partenaires lorsqu'il s'identifiera auprès d'eux. 4. Si l'utilisateur accepte de recevoir ces propositions, le fait est signalé aux autres membres du cercle de confiance. 5. L'utilisateur étant authentifié, il peut travailler normalement en ayant recours aux services du système de son entreprise. Les étapes 3. et 4. ci-dessus n'ont lieu que lors de la première connexion d'un utilisateur et ne se dérouleront plus lors de ses connexions ultérieures. Une fois que l'utilisateur est authentifié par le système de l'entreprise, il peut être amené au cours de son travail à s'identifier auprès de l'un ou l'autre des partenaires 19

20 Informatique de gestion ISNET 76 faisant partie du même cercle de confiance 38. Ce cas d'utilisation est illustré par la figure 2.3. Fig. 2.3 : Première connexion auprès d'un partenaire du même cercle de confiance. Première connexion auprès d'un partenaire du même cercle de confiance (fig 2.3) : 0. L'utilisateur a été authentifié par le système de l'entreprise. 1. L'utilisateur se rend sur le site d'un partenaire, soit explicitement, soit en suivant un hyperlien. 2. Le partenaire gère lui-même un ensemble d'utilisateurs ayant divers droits d'accès à son système. Il demande à l'utilisateur de fournir la paire nom / mot de passe par laquelle il le reconnaît Le partenaire vérifie les informations de connexion et authentifie l'utilisateur. 4. Comme cet utilisateur a autorisé les partenaires à lui proposer la fédération de ses identités, cette proposition est émise par le partenaire. Sa réponse est enregistrée. 5. L'utilisateur est authentifié normalement et peut recourir aux services offerts par le système du partenaire (il reste bien sûr authentifié également auprès du système de l'entreprise). Ces services peuvent être personnalisés en fonction du profil enregistré auprès du partenaire. L'utilisateur est maintenant reconnu réciproquement par les systèmes de l'entreprise et du partenaire. Lors d'une session ultérieure, lorsque l'utilisateur (après s'être identifié auprès du système de son entreprise) essayera de se connecter au système 38 En se rendant explicitement sur le site du partenaire ou en suivant un hyperlien d'une page Internet. 39 En général, cette paire est différente de celle que l'utilisateur a fourni au système de son entreprise. 20