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 [email protected] 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

21 Informatique de gestion ISNET 76 du partenaire, celui-ci le reconnaîtra sans autre forme de procès et les étapes 2., 3. et 4. décrites ci-dessus ne seront plus effectuées. L'utilisateur a également la possibilité, à tout moment, de renoncer à la fédération. Les systèmes concernés se notifient réciproquement les déconnexions locales de l'utilisateur et ce dernier a la possibilité d'effectuer une déconnexion globale de tous les systèmes auprès desquels il est identifié 40. La sécurité est assurée par le fait qu'à aucun moment, les systèmes de l'entreprise et du partenaire n'échangent effectivement des informations d'identité 41 de l'utilisateur. Celui-ci est représenté dans la fédération par un pseudonyme qui l'identifie. La protection de la sphère privée de l'utilisateur est assurée par le fait que chacun des partenaires ne mémorise que les informations qui concernent strictement l'interaction de l'utilisateur avec leur système. 2.5 L'architecture Dès le départ du projet, Liberty Alliance a défini une architecture modulaire générale des différentes spécifications envisagées dans le but de fixer les grandes lignes directrices du projet d'une part, dans celui de fournir un cadre cohérent et global dans lequel les futures versions pourrons s'inscrire. Cette architecture est illustrée par la figure 2.4. LIBERTY IDENTITY FEDERATION FRAMEWORK (ID-FF) Gestion de la fédération d'identités LIBERTY IDENTITY SERVICES INTERFACE SPECIFICATIONS (ID-SIS) Instanciation de l'implémentation technique définie par ID-WSF LIBERTY IDENTITY WEB SERVICES FRAMEWORK (ID-WSF) Interopérabilité des services à utilisateur authentifié STANDARDS EXISTANTS (SAML, SOAP, HTTP, WSS, etc.) Fig. 2.4 : Architecture modulaire générale [LaA03]. L'ensemble des spécifications s'appuie sur des standards existants ; l'idée étant d'adopter et d'étendre des standards largement présents sur le marché plutôt que d'en définir de nouveaux, propriétaires et incompatibles avec l'existant. Le projet 40 Global Logout. 41 Au sens défini dans le chapitre

22 Informatique de gestion ISNET 76 s'appuie donc sur les résultats des travaux de spécification de standards menés par OASIS 42, W3C 43 et IETF 44. Le module ID-FF est chargé de la gestion de la fédération d'identités comme décrit plus haut 45. Il peut être déployé sans la présence des autres modules et peut fonctionner en collaboration avec des systèmes d'authentification existants. Le module ID-WSF définit un framework permettant de créer, de découvrir et de consommer des Web services communiquant avec des utilisateurs (ou des services) authentifiés. Il s'agit de la spécification d'une couche de base ayant recours à l'id-ff pour gérer l'authentification et sur laquelle s'appuie ID-SIS. Le module ID-SIS est un ensemble de spécifications qui définissent comment construire des services inter opérables se basant sur ID-WSF. La mise à disposition de services tels qu'un agenda partagé, la géo location ou encore des systèmes d'alertes est envisageable Le module ID-FF Dans la présente étude, nous nous intéressons principalement aux fonctionnalités offertes par le module ID-FF. Il s'agit principalement de 46 : Opt-in Account Linking : le mécanisme de fédération. Simplified Sign-On : identification unique d'un utilisateur faisant partie d'un cercle de confiance et entre cercles de confiance. Fundamental Session Management : définition et communication du type d'authentification d'un utilisateur entre les systèmes d'un cercle de confiance ; déconnexion globale 47. Affiliations : proposition aux utilisateurs de recevoir les offres de fédération au cours de la navigation entre systèmes d'un cercle de confiance. Anonymity : possibilité pour un système d'obtenir des attributs concernant un utilisateur sans connaître son identité 48. Toutes ces fonctions sont nécessaires pour mettre en œuvre l'ensemble des mécanismes décrits au chapitre Autres modules Les modules ID-WSF et ID-SIS définissent des fonctionnalités qui permettront de développer les capacités de la fédération d'identité, en particulier en y incluant les 42 OASIS : Organization for the Advancement of Structured Information Standards ( 43 W3C : World Wide Web Consortium ( 44 IETF : Internet Engineering Task Force ( 45 Voir chapitres 2.3 et Les termes anglais sont employés dans la liste pour assurer l'univocité de désignation. 47 Global logout. 48 Par exemple, au moment de la connexion d'un utilisateur à un système, celui-ci peut demander au système auprès duquel cet utilisateur est authentifié si cet utilisateur a accepté de recevoir les offres de fédération. 22

23 Informatique de gestion ISNET 76 Web services. Ils n'ont pas besoin d'être déployés pour gérer la fédération d'identités elle-même. Nous ne les décrirons donc pas ici. 23

24 Informatique de gestion ISNET 76 3 CONFORMITÉ DES IMPLANTATIONS La multiplication des produits offerts sur le marché par de nombreux fournisseurs de logiciels 49 pose la question cruciale de la conformité aux spécifications des implantations proposées. 3.1 Liberty Interoperable Pour résoudre ce problème, les membres du consortium Liberty Alliance ont défini dès 2003 un programme de certification : Liberty Interoperable. L'objectif de ce programme est de mettre à la disposition des fournisseurs de solutions un environnement dans le cadre duquel la conformité de leur produit aux spécifications peut être validée. Les membres des sociétés candidates à la certification doivent passer différents tests basés sur des scripts et des scénarios publiés sur le site Internet de Liberty Alliance 50 et élaborés par un groupe d'experts désignés par le consortium. Ces tests sont organisés en events regroupant différents constructeurs et sont organisés plusieurs fois par année. 3.2 Tests de conformité Les tests de conformité sont organisés par Liberty Alliance et durent en général une semaine au cours de laquelle les sociétés candidates à la certification doivent démontrer leur conformité aux spécifications d'une part, l'inter opérabilité de leur produit d'autre part. Le programme de tests stipule également que les fonctionnalités de base doivent être accomplies dans divers contextes ressemblant à de véritables déploiements du produit. La démonstration de l'inter opérabilité doit être effectuée avec deux autres produits d'entreprises concurrentes participant au programme de certification. Ces concurrents sont choisis au hasard. La réussite du test est certifiée de façon croisée par les paires d'entreprises qui signent un protocole standard attestant du succès ; le protocole est également validé par le groupe d'experts de Liberty Alliance et complété par un journal des messages échangés qui constitue la trace du test. La confidentialité nécessaire à la conduite des affaires est garantie par le fait qu'aucun observateur autre que les membres de l'équipe de test de l'entreprise candidate et ceux de l'organisation n'est admis à ces séances. 3.3 Produits inter opérables Les produits qui ont passé avec succès les tests de conformité peuvent afficher le logo de la figure 3.1. Une liste des produits ayant obtenu cette certification est 49 Le nombre de fournisseurs de logiciels qui proposent des solutions de fédération d'identité augmente sans cesse ; il approche bientôt de la centaine. 50 Voir 24

25 Informatique de gestion ISNET 76 disponible sur le site de Liberty Alliance 51. À ce jour, tous tests confondus, plus de soixante-dix produits ont obtenu cette certification. Fig. 3.1 : Logo certifiant la conformité du produit aux spécifications. Les clients qui font l'acquisition d'un produit muni de ce logo ont l'assurance que celui-ci : est conforme aux spécifications de Liberty Alliance ; sera maintenu conformément aux standards industriels de qualité ; est effectivement la version qui a passé les tests de certification. Si un problème à propos de la qualité ou de la conformité du produit survient dans les deux ans qui suivent l'obtention du logo, Liberty Alliance se réserve le droit d'exiger de la société éditrice de remédier au problème dans un délai de soixante jours, sous peine de retrait de la certification. Ce programme permet ainsi à un client de choisir un produit en toute connaissance de cause et d'envisager une stratégie à moyen terme pour son déploiement au sein de l'entreprise. Il a ainsi la garantie que le choix qu'il a effectué ne sera pas rapidement obsolète et est assuré que la solution qu'il envisage, ce qui est fondamental, sera relativement pérenne. 51 Voir 25

26 Informatique de gestion ISNET 76 4 MISE EN ŒUVRE Nous examinerons tout d'abord, en toute généralité, les principaux concepts qui sont mis en jeu lors de la mise en œuvre d'une fédération d'identité, puis nous recenserons les composants matériels et logiciels nécessaires, enfin, nous définirons comment, dans le cas particulier d'une petite ou moyenne entreprise 52, ces concepts et ces composants doivent être implantés. 4.1 Concepts Pour la mise en œuvre de la fédération d'identité, on distingue trois acteurs principaux : le fournisseur de service, le fournisseur d'identité et le client. Fournisseur d'identité Échange d'informations Fournisseur de service Client Redirection Fig. 4.1 : Les acteurs de la fédération d'identité Le fournisseur de service Le fournisseur de service 53 est l'organisation, l'entreprise qui fournit un certain nombre de services en ligne aux utilisateurs ; l'accès à tout ou partie de ces services n'est donné qu'à des utilisateurs authentifiés. Le fournisseur de service procède à cette authentification, soit via son propre service d'authentification s'il est responsable de la gestion de l'identification principale de l'utilisateur, soit via un fournisseur d'identité dans le cas contraire. Dans le cadre d'une fédération, les identités ne sont pas centralisées, chaque fournisseur de service est libre de les gérer comme il l'entend. La mise en place d'une fédération nécessite la coopération de différents fournisseurs de service et notamment, que chacun accorde sa confiance aux autres puisqu'il délègue l'accès à 52 PME. 53 Service Provider (SP) dans la terminologie Liberty Alliance. 26

27 Informatique de gestion ISNET 76 son application au serveur d'identité. Ces questions se règlent de manière contractuelle 54. Si par exemple, le fournisseur de service est une compagnie d'aviation qui propose une application Internet de vente de ses billets. Cette compagnie peut avoir envie de s'associer avec des hôtels et des entreprises de location de véhicules de sorte que ses clients puissent facilement naviguer de l'application de vente de billets vers celles des entreprises partenaires, sans avoir besoin de s'identifier à nouveau. La compagnie d'aviation devra conserver les coordonnées de ses clients (nom, adresse, numéro de carte de crédit, etc.) et les protéger par un login 55. Chaque ensemble d'informations caractérisant un client et identifié par un login est mémorisé et constitue l'identité au sens de la compagnie d'aviation. Remarquons que suivant le type de fournisseur de service, l'identité d'un utilisateur sera constituée d'informations différentes ; en effet, l'entreprise partenaire de location de véhicules devra connaître le type de permis de conduire dont dispose le client et d'autres informations encore. L'utilisateur du système a alors deux identités distinctes, l'objectif de la fédération étant justement de les mettre en relation Le fournisseur d'identité Le fournisseur d'identité 56 est le serveur qui fait le lien entre les différentes identités des fournisseurs de service ayant conclu un accord de partenariat. C'est au fournisseur d'identité que s'adressent les fournisseurs de service lors de la phase d'authentification pour déterminer si un utilisateur a déjà été identifié par un autre partenaire de la fédération 57. Lorsqu'un fournisseur de service veut faire partie d'une fédération, il doit obligatoirement mettre en place un fournisseur d'identité pour gérer cette fédération Le client Le client 58 des services offerts par les fournisseurs de service d'un cercle de confiance possède des identités chez chacun d'eux (et donc autant de logins). En fédérant ces identités, il va pouvoir éviter de s'identifier auprès de chacun de ces fournisseurs de service. Il lui suffira d'être identifié auprès de l'un d'entre eux pour que les autres arrivent à le reconnaître 59. Le client est généralement matérialisé par un browser via lequel il accède aux informations des fournisseurs de service qui l'intéressent. Les requêtes d'authentification effectuées par l'application des fournisseurs de service sont 54 Le sujet des dispositions contractuelles n'est pas traité par Liberty Alliance. Elles doivent faire partie du business modèle mis en place par le fournisseur de service. 55 Couple identification / mot de passe. 56 Identity Provider (IDP) dans la terminologie Liberty Alliance. 57 Pour une description détaillée du fonctionnement, voir chapitre Personal dans la terminologie Liberty Alliance. 59 Pour une description détaillée du fonctionnement, voir chapitre

28 Informatique de gestion ISNET 76 redirigées vers le ou les fournisseurs d'identité concernés qui, en réponse, transmettent les informations d'identification strictement nécessaires. 4.2 Composants matériels et logiciels nécessaires Le déploiement d'une application Internet au sein d'une fédération d'identité requiert un certain nombre de ressources matérielles et logicielles. Celles-ci devront être installés sur les divers sites des membres de la fédération Logiciel Le premier composant nécessaire est bien sûr l'application Internet fournissant le service en relation avec le métier de l'entreprise et que celle-ci désire intégrer à une fédération d'identité. Si l'application n'a pas été conçue avec ce dernier objectif, il faudra en principe la modifier pour que l'identification de l'utilisateur s'effectue via le fournisseur d'identité. La mise en place du système de fédération d'identité lui-même s'effectue à travers l'installation d'un serveur d'identité respectant les spécifications de Liberty Alliance. Chaque membre de la fédération devra déployer un serveur d'identité respectant ces spécifications. Il n'est évidemment pas nécessaire que les partenaires de la fédération mettent en œuvre le même logiciel ; en effet, si les deux logiciels sont certifiés par Liberty Alliance, alors ils sont par définition compatibles entre eux 60. Le fournisseur de service doit installer un serveur d'identité, ce qui aura pour conséquence d'installer un certain nombre de Web services que l'application Internet va employer pour déterminer si l'utilisateur a déjà été authentifié ou si elle doit présenter une page d'identification. De même, si l'application identifie elle-même l'utilisateur, elle doit le signaler à son serveur d'identité via les Web services qui ont été installés. Le client n'a besoin que d'un simple navigateur Internet par l'intermédiaire duquel il accède aux services offerts par les membres d'une fédération d'identité. En effet, sur le poste du client, la mise en œuvre se résume à l'emploi de fonctionnalités disponibles depuis fort longtemps pour tous les browsers, à savoir la redirection http et les cookies. De ce fait, le client peut se trouver en n'importe quel lieu muni d'une connexion Internet Matériel Concernant le matériel, le fournisseur de service utilise en principe une machine comme serveur d'application pour faire fonctionner ses services propres et les services qu'elle met à disposition de la fédération, une seconde machine fonctionnant comme serveur d'identité et enfin un serveur Internet donnant l'accès à ses services. Ces rôles peuvent bien évidemment être remplis par une seule et unique machine physique, tout comme ils peuvent être répartis sur deux machines dans n'importe laquelle des trois combinaisons 61 possibles. 60 Voir chapitre Si SA : serveur d'application, IDP : serveur d'identité et SI : serveur Internet, on peut combiner (SA+IDP)(SI) ou (SA+SI)(IDP) ou encore (SA)(IDP+SI). 28

29 Informatique de gestion ISNET 76 Cependant, une même machine physique peut jouer plusieurs rôles dans des contextes différents. En effet, il est tout a fait possible que la machine héberge une configuration faisant d'elle un serveur d'identité dans un cercle de confiance donné et en même temps fonctionner comme fournisseur de service dans un autre cercle de confiance. Le client enfin n'a besoin que d'un poste de travail sur lequel il peut faire fonctionner un navigateur Internet. 4.3 Implantation Des expériences de fédération d'identité ont déjà été mises en œuvre ou sont en cours de déploiement dans de très grands groupes d'entreprises parmi lesquels on peut citer, non exhaustivement, France Télécom 62 et General Motors 63. France Télécom est principalement un fournisseur d'accès. Dans son cas, la fédération d'identité est mise en œuvre pour faciliter l'accès de ses clients à des services fournis par d'autres membres du groupe, principalement ses filiales de e-commerce. En fédérant les identités de ses abonnés avec celles de ses filiales, France Télécom espère ainsi encourager ses clients à naviguer et donc à acheter sur les sites de ses filiales plutôt que sur ceux de ses concurrents. En ce qui concerne General Motors, la fédération d'identité est principalement déployée dans le cadre du système intranet de l'entreprise ainsi qu'en interaction avec des services externes que General Motors met à la disposition des ses employés. Parmi ceux-ci, on peut citer le fournisseur d'accès AOL : les identifications AOL des employés de General Motors sont fédérées avec celles de l'intranet de la société. Un employé passe ainsi de façon transparente des activités relevant du domaine de sa sphère privée surfer sur le net au monde de l'entreprise 64. D'autres consortiums ont également envisagé la fédération d'identité comme solution aux problèmes posés par le fait que leur informatique est composée d'un grand nombre de systèmes disparates et non compatibles 65. C'est par exemple le cas de l'administration publique de la République Française [Min02]. Dans un tel environnement, les systèmes sont tout d'abord reliés entre eux par un réseau, puis la fédération d'identité est employée pour mettre en place, sur chaque système individuel, des services disponibles sur Internet auxquels ont peut ensuite accéder sans peine depuis n'importe quelle partie du système Voir [Fra04]. 63 Voir 64 À ce propos, on pourrait d'ailleurs se poser tout un ensemble de questions relevant de l'éthique ; ces questions dépassent le cadre de cette étude. 65 Cette situation est beaucoup plus répandue qu'on ne pourrait le croire. Cette multiplication des systèmes est en général liée à l'historique de la création de l'entreprise et de son développement, sur plusieurs régions et/ou pays, en filiales indépendantes, collaborant toutes avec la maison mère. 66 On voit donc que, même détournée de sa vocation première qui est de gérer des communautés d'utilisateurs, la fédération d'identité trouve des applications dans l'intégration de l'informatique d'entreprise. 29

30 Informatique de gestion ISNET La cible Les grandes entreprises évoquées dans le précédent chapitre disposent en général d'un département informatique conséquent, équipé d'une grande quantité de matériel performant et au sein duquel travaillent plusieurs dizaines, voire plusieurs centaines de collaborateurs. Nous nous proposons de concevoir une solution adaptées aux petites et moyennes entreprises 67 du tissu économique local. On sait que ce type d'entreprises moins de 250 employés représente la très grande majorité des entreprises suisses 68. Parmi ces entreprises, celles qui nous intéressent tout particulièrement sont celles qui gèrent elles-mêmes leur informatique. Une enquête réalisée en auprès de 138 entreprises de la région genevoise a mis en évidence que 64% des entreprises interrogées possédaient un département informatique [Pag05]. Une autre étude, réalisée en et portant sur 465 entreprises de la Suisse Romande, a montré que 38% des entreprises consultées faisaient réaliser leur site Internet par leur propre équipe d'informaticiens ; de plus, pour 21% des entreprises, le site Internet est relié au système d'information de l'entreprise [Leh02]. Nous considérerons donc des entreprises dont le système informatique correspond à l'architecture de la figure 4.2. Fig. 4.2 : L'architecture du système informatique des entreprises considérées. Remarquons que la figure 4.2 illustre les différents éléments conceptuels que sont les serveurs de données, d'applications et Internet par trois machines physiques différentes. Ces trois fonctions peuvent bien sûr être remplies par une unique machine physique, tout comme chacune d'elles peut être remplie par plusieurs machines physiques. Tout va dépendre de la taille de l'entreprise et de la puissance de calcul nécessitée par les différentes applications métier qu'elle fera fonctionner 67 PME. 68 L'Office fédéral de la statistique a déterminé lors de son dernier recensement qui date de 2001 que largement plus de 90% des entreprises étaient des PME ( Cette observation doit tout de même être tempérée par le fait que plus de 80% des entreprises sont des entités employant moins de 10 personnes. 69 Enquête effectuée dans le cadre d'un travail de diplôme à la HEG Genève et portant sur l'asp. 70 Étude réalisée par l'inforge, HEC Lausanne, PSINet et le GRI et portant sur l'utilisation de l'internet dans les entreprises romandes. 30

31 Informatique de gestion ISNET 76 avec son système. Notons enfin que divers éléments de sécurité, tels que des pare-feux 71, doivent également être mis en place et ne sont pas représentés sur ce schéma Architecture du système Comme nous l'avons vu plus haut, pour qu'un fournisseur de service puisse faire partie d'une fédération, il est nécessaire de modifier l'architecture du système et d'y adjoindre un serveur d'identité. La figure 4.3 illustre cette nouvelle architecture du système de l'entreprise. Fig. 4.3 : La nouvelle architecture du système. Comme nous l'avons déjà mentionné, le serveur d'identité n'est pas forcément matérialisé par une machine physique distincte des autres. Cette fonction peut tout à fait être assumée par une des autres machines physiques du site Accès aux services Les services délivrés par un tel système sont ceux qui correspondent au métier de l'entreprise. Très souvent, faute d'accords avec des partenaires potentiels, ces services sont strictement réservés aux employés et ne sont donc disponibles que depuis une connexion effectuée depuis un poste de travail du réseau local de l'entreprise. Si l'activité principale de l'entreprise consiste à effectuer du commerce électronique en ligne ou une activité analogue impliquant des transactions financières telles que des paiements, une partie des utilisateurs du système s'y connecte depuis l'extérieur de l'entreprise, via Internet. Deux cas de figure peuvent alors se présenter : Chaque paiement donne lieu à une transaction sécurisée au cours de laquelle le client transmet ses informations d'identité personnelles telles que l'adresse de livraison et le numéro de sa carte de crédit. 71 Firewall. 31

32 Informatique de gestion ISNET 76 L'entreprise gère, pour chacun de ses clients, un login formé d'une paire identification / mot de passe à laquelle les informations d'identité personnelles sont associées. Lors d'une transaction, seul le login est fourni par le client, le système se chargeant de retrouver les informations qui y sont associées. La première solution a l'inconvénient que le client doit fournir ses informations personnelles chaque fois qu'il effectue une transaction avec l'entreprise ; de plus, des informations confidentielles telles que le numéro de carte de crédit seront transmises lors de chaque transaction, augmentant ainsi les risques de vol. Pour la seconde solution, l'entreprise devra gérer des identifications pour ses clients auxquelles elle associera les informations d'identité personnelles. Cette solution est plus ergonomique pour le client qui doit saisir moins d'information lors de chaque transaction ; elle est plus sûre également, puisque les informations confidentielles ne sont transmises qu'une seule fois Authentification Pour pouvoir faire partie d'une fédération d'identité, le système de l'entreprise doit impérativement authentifier ses utilisateurs. Les utilisateurs doivent être authentifiés au niveau du système de l'entreprise, de telle sorte que cette authentification soit valide pour l'ensemble des applications auxquelles les utilisateurs ont accès. Ces utilisateurs sont bien sûr les employés de l'entreprise, mais également les clients de celle-ci, si ces derniers ont accès au système de l'entreprise par l'intermédiaire d'internet 72. Si aucun système d'authentification n'est mis en place, celui-ci pourra être pris en charge par le serveur d'identités que nous avons ajouté au système. Si un système centralisé d'authentification existe déjà, celui-ci pourra s'intégrer à la nouvelle configuration. Si par contre les identifications s'effectuent au coup par coup, sous la responsabilité individuelle de chacune des applications fournissant les services, ces applications devront être modifiées pour s'intégrer à une authentification centralisée Logiciel De nombreux produits conformes aux spécifications et qui ont donc obtenu une certification de Liberty Alliance sont disponibles sur le marché. Parmi ceux-ci, nous suggérons d'employer Sun Java System Access Manager, car il s'intègre relativement facilement à la plupart des plates-formes du marché et qu'il est possible d'en obtenir des versions gratuitement pour effectuer des développements et tester des configurations 73. De surcroît, Sun Microsystems étant l'initiateur et l'un des acteurs et animateurs principaux du consortium Liberty Alliance, ce choix garantit une implantation la plus conforme possible des spécifications ; on peut compter enfin sur le fait que, étant donné la position de Sun Microsystems, les évolutions des spécifications de Liberty Alliance seront intégrées rapidement dans leurs produits. 72 Notons que toute la partie du site Internet qui représente la vitrine de l'entreprise peut rester en accès libre. Seuls les accès aux services sécurisés doivent être munis d'un système d'authentification. 73 C'est uniquement lorsqu'on décide d'en faire une exploitation commerciale qu'il est nécessaire d'acheter le produit. 32

33 Informatique de gestion ISNET 76 Ce système permet de gérer les identifications de manière centralisée, ainsi que la fédération d'identité. Il fait partie de la suite Sun Java Entreprise System qui comprend un serveur d'applications. Dans le cas d'applications s'exécutant sous le contrôle de ce dernier, il sera donc relativement simple de mettre en place la configuration d'un fournisseur de service intégré à un cercle de confiance. Remarquons que si le système de l'entreprise est déjà muni d'une procédure d'authentification centralisée et que celle-ci est réalisée par un logiciel d'un constructeur offrant par ailleurs un composant de gestion de la fédération d'identité certifié Liberty Alliance, nous conseillons alors de déployer ce dernier. En effet, une telle solution aura pour avantage, en principe 74, de diminuer grandement le temps nécessaire à l'administrateur du système pour se familiariser avec le nouveau composant, puisqu'il aura déjà l'habitude de travailler avec d'autres produits du même constructeur Systèmes Microsoft Windows La compagnie Microsoft ne fait pas partie du consortium Liberty Alliance et offre des solutions propriétaires, aussi bien pour l'authentification des utilisateurs du système que pour la fédération d'identité. Les utilisateurs d'un domaine Windows sont répertoriés via la technologie Active Directory qui est une implémentation du protocole LDAP 75. La fédération d'identité est implantée au moyen du composant ADFS 76 qui implante les spécifications de WS-Federation et fournit la technologie de single sign-on pour les applications Internet dans un environnement Windows. Notre objectif, dans le cadre de ce projet, est de définir une architecture qui permet de fédérer le système de l'entreprise avec des systèmes qui se conforment aux spécifications de Liberty Alliance. Une telle architecture est ouverte et indépendante des spécifications propriétaires d'un constructeur particulier. ADFS n'est pas compatible avec les spécifications ID-FF de Liberty Alliance. Néanmoins, de nombreux produits certifiés Liberty Alliance, dont le logiciel proposé au chapitre 4.3.5, sont capables de s'appuyer sur les services fournis par Active Directory pour gérer les authentifications des utilisateurs. De même, comme démontré dans les prototypes réalisés, il est possible de mettre en place des serveurs multi protocoles qui permettent l'inter opérabilité entre ADFS et Liberty Alliance Procédure L'ensemble des éléments que nous avons évoqués nous amène à définir la procédure de la figure 4.4 qui décrit la suite des différentes opérations à accomplir, en fonction de la configuration initiale du système de l'entreprise, pour rendre ce dernier compatible avec la fédération d'identités. Remarquons que certaines des étapes de cette procédure, bien qu'étant relativement simples, peuvent avoir un coût non négligeable, en particulier l'étape Modifier les applications. 74 Ce n'est bien sûr vrai que si le constructeur s'est préoccupé de maintenir une unité ergonomique entre les différents produits constituant son offre. 75 Lightweight Directory Access Protocol. 76 Active Directory Federation Protocol. 33

34 Informatique de gestion ISNET 76 Fig. 4.4 : Étapes de la mise en conformité du système avec la fédération d'identités. La réalisation de ces étapes permet d'obtenir un système au sein duquel les utilisateurs s'authentifient avec un unique login 77, ce qui est un gain appréciable pour les systèmes pour lesquels ce n'était pas le cas. En effet, les nouvelles applications qui seront développées dans ce cadre pourront aisément être intégrées à ce système et s'appuyer dessus pour gérer l'authentification et les droits d'accès des différents utilisateurs. De plus, ce système est maintenant prêt à fonctionner dans le cadre d'une fédération d'identités. Il peut faire partie d'un cercle de confiance et donc autoriser l'accès à ses services à des utilisateurs externes authentifiés par des partenaires. De même, les utilisateurs du système peuvent naviguer de façon transparente vers les services offerts par les partenaires. 77 Single sign-on. 34

35 Informatique de gestion ISNET 76 5 MODÈLE BUSINESS La gestion de l'authentification et de la fédération d'identité sont essentiellement indépendantes du métier exercé par l'entreprise. Nous nous intéresserons donc principalement aux aspects qui concernent la gestion de l'identité et son partage avec des partenaires. Le modèle que nous allons décrire enrichit donc le modèle business mis en œuvre par l'entreprise pour exercer son métier ; dans certains cas, les revenus seront obtenus par des moyens différents, éventuellement à moindre coût que le modèle de base, dans d'autres, de profits complémentaires et/ou supplémentaires pourront être générés. 5.1 Cadre Les différents concepts formant un business modèle 78 peuvent être schématisés par la figure 5.1. Ces concepts sont répartis en quatre grands piliers qui couvrent les différents aspects à envisager lors de la définition de la structure de l'entreprise et de son réseau de partenaires pour la création, le marketing et la livraison de valeurs avec pour objectif la génération de profits durables [Dub02]. Innovation produit Clientèle ciblée Proposition de valeur Compétences valeur proposée Relation client Stratégie d'information Canaux de distribution Confiance / fidélité nécessaire à Gestion de l'infrastructure Ressources et moyens Configuration activités Réseau partenaires Aspects financiers Modèle de revenu Modèle de profit Structure de coût Fig. 5.1 : Les piliers des modèles business. Ces piliers représentent respectivement les produits offerts 79 par une entreprise qui forment la valeur pour laquelle le client est disposé à payer, l'infrastructure et le réseau de partenaires 80 nécessaires à la création de valeur, les relations que 78 Principalement dans le contexte des nouvelles technologies de l'information. 79 Innovation produit : quoi? 80 Gestion de l'infrastructure : comment? 35

36 Informatique de gestion ISNET 76 l'entreprise entretient avec ses clients 81 pour générer des revenus et les aspects financiers 82 des trois autres piliers tels que les modèles de coûts et de profit. 5.2 Type d'échange La fédération d'identité permet à des systèmes informatiques d'entreprises partenaires de reconnaître mutuellement les authentifications d'utilisateurs qu'ils ont effectué. Le type d'échange de service qui aura lieu sera donc principalement de type B2B 83. Dans certains cas, suivant le métier de l'un des partenaires, des échanges de type B2C 84 peuvent également être affectés par la fédération. Le modèle proposé ci-dessous se base sur un type d'échange du type B2B ; le "client" est donc une personne morale. S'il y a lieu, les éléments affectant une relation B2C que l'un des partenaires pourrait avoir seront mentionnés explicitement. 5.3 Innovation produit Services offerts Chacun des différents partenaires d'une fédération d'identité offre un certain nombre de services aux autres. Ce sont : la reconnaissance d'utilisateurs authentifiés par les entreprises partenaires ; la fourniture d'attributs d'identité aux entreprises partenaires pour les utilisateurs authentifiés. Si l'entreprise est de surcroît engagée dans une relation B2C avec des clients via son site Internet, le service offert au client est : la simplification de sa procédure d'identification pour l'ensemble des sites des partenaires de la fédération par la mise à la disposition d'une identification unique. Proposition de valeur Les valeurs de ces services sont : la simplification de l'accès aux services du système par les utilisateurs authentifiés par les entreprises partenaires ; la fourniture automatique d'informations utiles aux entreprises partenaires pour effectuer leurs transactions. En ce qui concerne les clients d'une relation B2C, les valeurs de ces services sont : l'amélioration ergonomique de la navigation entre les sites Internet des différents partenaires de la fédération ; les valeurs spécifiques du métier de l'entreprise qui sont proposées au client peuvent être ciblées en fonction d'un profil qui peut être établi finement grâce aux différents attributs associés à son identité. 81 Relation client : qui? 82 Aspects financiers : combien? 83 Business to business. 84 Business to customer. 36

37 Informatique de gestion ISNET 76 Clientèle ciblée Dans le cas de la relation B2B : les clients sont les partenaires commerciaux de l'entreprise. Dans le cas de la relation B2C : la clientèle est identique à celle définie pour le métier de l'entreprise ; la fédération peut toutefois générer une nouvelle clientèle atteinte indirectement au travers des partenaires de la fédération. Compétences L'entreprise dispose des compétences nécessaires pour offrir les valeurs proposées par le fait même que le système informatique de l'entreprise est architecturé de telle sorte qu'il puisse gérer la fédération d'identité. Ces compétences sont vraiment disponibles, parce que l'entreprise gère elle-même son système informatique Gestion de l'infrastructure Configuration des activités Pour mettre en œuvre la fédération d'identité, les différents partenaires concernés doivent : définir clairement les responsabilités de chaque entreprise ; établir la liste des risques en cas de litige ou de fraude ; élaborer les procédures de fédération des identités et celles pour terminer une relation de confiance 86 ; définir la nature et le format des attributs à échanger entre les systèmes des entreprises ; rédiger les conditions d'utilisation et les chartes de sécurité. D'un point de vue juridique 87, il faut également : que les données personnelles des utilisateurs soient protégées conformément aux lois en vigueur ; que l'anonymisation des données personnelles transmises soit garantie ; que les procédures de résolution des litiges en cas de fraude ou de panne des services offerts soient définies. Réseau de partenaires Les entreprises partenaires d'une fédération d'identité établissent des contrats de partenariat bilatéraux ; l'objectif stratégique commun étant de regrouper dans un 85 Voir chapitre Il en irait autrement si la gestion de l'informatique de l'entreprise étaient confiée à un tiers dans le cadre d'une solution ASP par exemple. 86 Une relation de confiance peut se terminer en cas de fin de vie d'un service, d'une cessation d'activité de l'un des partenaires ou encore du désengagement de l'association de l'un des partenaires. 87 Les aspects juridiques devront être particulièrement étudiés dans le cas d'établissement de partenariats inter cantonaux ou encore transfrontaliers. En effet, tant les lois sur la protection des données que celles régissant les litiges dépendent en général de la localisation géographique du siège social des partenaires et peuvent être différentes d'une entité juridique à l'autre. 37

38 Informatique de gestion ISNET 76 cercle de confiance un ensemble de métiers complémentaires et dont les services collaborent. Ressources et moyens Les équipements suivants sont nécessaires à la création des valeurs proposées : un serveur qui sera chargé de la gestion des identités et de leur fédération ; comme déjà évoqué au chapitre 4.3.2, une nouvelle machine physique n'est pas forcément nécessaire ; un logiciel de gestion et d'administration de la fédération d'identité ; ce logiciel sera déployé sur la nouvelle machine physique mentionnée ci-dessus ou sur l'un des serveurs existants. Le strict minimum des équipements nécessaires se résume donc au logiciel de gestion de la fédération, le reste pouvant s'appuyer sur des ressources déjà existantes. Remarquons que l'acquisition d'une machine dédiée à la gestion de la fédération augmentera les performances globales du système informatique de l'entreprise, en particulier ses temps de réponse, contribuant ainsi à la consolidation et à l'amélioration de la réputation de l'entreprise auprès de ses partenaires et de ses clients. En ce qui concerne les ressources humaines, il est nécessaire de disposer d'un administrateur système dont les responsabilités sont : l'installation, la configuration et la maintenance du serveur de gestion de la fédération d'identités ; la gestion des identités des utilisateurs du système. Ces ressources sont en partie disponibles, car une entreprise qui gère elle-même son système informatique dispose déjà d'une personne qui s'occupe de l'administration de ce système. Une disponibilité ponctuelle de l'administrateur en phase initiale du projet sera nécessaire pour procéder à l'installation et à la configuration du serveur d'identités. Les activités de maintenance et de gestion des identités quant à elles représentent une charge qu'on peut évaluer au maximum à deux jours par mois ; celles-ci pourront donc être facilement intégrées au cahier des charges de l'administrateur, éventuellement en transférant une partie des ses responsabilités vers d'autres collaborateurs de la division informatique de l'entreprise. 5.5 Relation client Stratégie de l'information Dans le cas de la relation B2B : les clients sont des partenaires qui exercent un métier qui est complémentaire à celui de l'entreprise ; les informations les concernant sont donc a priori connues et ont donc déjà été récoltées ; cette connaissance des caractéristiques des partenaires permet de définir de façon optimale les accords bilatéraux de partenariat. Dans le cas de la relation B2C : les habitudes des clients, leur façon de naviguer dans le site de l'entreprise et entre les différents sites des partenaires sont relevées et exploitées pour définir 38

39 Informatique de gestion ISNET 76 un profil personnalisé du client qui est mémorisé dans les attributs associés à son identité ; en fonction de ce profil, des opportunités d'achat ciblées lui sont proposées. Confiance et fidélité L'entreprise entretient, en principe, un climat de confiance avec ses partenaires commerciaux usuels. Celui-ci est renforcé par : la conclusion d'accords formels de partenariat, spécifiant explicitement et de façon détaillée les droits et devoirs de chacune des parties ; le fait que les accords de partenariat s'inscrivent dans un cadre juridique clairement défini code des obligations, loi fédérale sur la protection des données 88. En offrant des capacités de fédération d'identité pour l'emploi de ses services, l'entreprise s'ouvre à de nouveaux partenaires intéressés par la simplification des procédures d'accès ainsi que l'automatisation des transactions, gagnant par là même des parts de marché sur le terrain de l'échange d'informations d'identité. Dans le cas de la relation B2C, les clients doivent faire confiance à l'entreprise à propos de l'exploitation qui sera faite de leurs données personnelles. Cette confiance est établie et renforcée en : leur rappelant explicitement qu'un cadre juridique contraignant, la loi fédérale sur la protection des données, fixe les limites de l'exploitation des données personnelles ; leur permettant de s'exclure explicitement de listes de publipostages publicitaires et leur garantissant que leurs données personnelles ne seront pas transmises à des tiers ; exploitant le profil du client avec intelligence et parcimonie dans le but de créer une dynamique de relation positive. Les clients des entreprises partenaires sont incités, par la simplification des procédures d'identification et par des liens croisés figurant dans les sites des partenaires, à profiter des services de l'entreprise qui acquiert par ce biais un nouveau segment de clientèle. Canaux de distribution Les valeurs proposées sont diffusées aux partenaires au travers de l'internet, au sein des cercles de confiances établis et formalisés par les divers accords bilatéraux conclus. 5.6 Aspects financiers Modèle de revenu Chaque fourniture d'attributs d'identité aux entreprises partenaires est facturée sous la forme d'un micro paiement, le montant de ces paiements est modulé par la quantité et la qualité des informations fournies. 88 Voir [LPD92]. 39

40 Informatique de gestion ISNET 76 Les transactions effectuées par le partenaire grâce à ces attributs donnent lieu au versement d'une commission. Dans le cadre d'une relation B2C, l'entreprise diversifie son offre de services en proposant à ses clients des liens vers ses partenaires de la fédération, exerçant ainsi un effet de levier sur les sources de revenus qui viennent d'être énoncées. Structure de coût Les coûts supplémentaires à ceux déjà engagés dans l'accomplissement du métier de l'entreprise d'une telle solution sont constitués : du prix d'achat du matériel (serveur) dédié à la gestion de la fédération d'identités ; du montant de la licence d'exploitation du logiciel de gestion et d'administration de la fédération d'identités ; d'une fraction du salaire de l'administrateur chargé de la gestion des identités des utilisateurs du système et de la maintenance du système de fédération. Modèle de profit Les coûts du système sont principalement constitués de coûts fixes le prix du matériel et le montant de la licence qui peuvent rapidement être amortis. La couverture des autres frais et la génération de profit sont déterminées en extrapolant les résultats des opérations effectuées avec les partenaires commerciaux de l'entreprise avant la mise en œuvre du nouveau système. Dans le cas d'une relation B2C, on peut également espérer une augmentation du chiffre d'affaires dans le domaine du métier de l'entreprise dans la mesure où, via le réseau de partenaires de la fédération, elle va atteindre de nouveaux clients. Dans le cas de relations B2B, la productivité des employés est améliorée par le fait que leur navigation au sein des sites des entreprises partenaires de la fédération s'en trouvera simplifiée. Enfin, le temps de développement de nouvelles applications au sein de l'entreprise se trouvera réduit par le fait que tous les aspects de la gestion de l'authentification et de la mémorisation des attributs d'identité nécessaires à l'application sont pris en charge par le composant de fédération. Le temps nécessaire à la gestion des utilisateurs sera également réduit, puisqu'une partie des attributs de ceux-ci seront gérés par les partenaires. 40

41 Informatique de gestion ISNET 76 6 PROTOTYPES L'architecture proposée au chapitre a été testée en réalisant un prototype dont les procédures d'installation sont décrites dans l'annexe A. Différents prototypes d'architectures prenant en compte les différents scénarios envisageables, y compris des solutions basées sur Microsoft Windows, ont été étudiés et réalisés et sont décrits dans l'annexe B. L'inter opérabilité des solutions Windows avec Liberty Alliance est également démontrée. 41

42 Informatique de gestion ISNET 76 7 CONCLUSION Dans le monde économique actuel, les entreprises partagent de plus en plus d'informations avec leurs clients et leurs partenaires commerciaux. Ces différents acteurs évoluent dans un environnement distribué dont Internet est la colonne vertébrale. Les fonctions même de l'internet ont évolué de la simple interconnexion d'ordinateurs vers celle d'applications et de services ; simultanément, le nombre de clients, de dispositifs et de points d'accès à ces applications et services a explosé. Les utilisateurs de ces applications et services, qu'ils soient de simples clients ou des employés de l'entreprise doivent s'authentifier pour y avoir accès. La gestion de l'identité est ainsi devenue un élément vital de toute transaction commerciale effectuée au travers de ces applications et services. L'accès à chaque application ou service est en général protégé par un système d'authentification propre ; la multiplication des identités est ainsi devenu le cauchemar des utilisateurs commerciaux de l'internet. Les spécifications émises par Liberty Alliance définissent une architecture de gestion de l'identité digitale dont le pilier fondamental est la fédération d'identités. Ce concept permet à un utilisateur authentifié par un service d'une entreprise de naviguer librement vers les services d'entreprises partenaires, faisant partie d'un même cercle de confiance. De grands groupes comme General Motors, ou encore France Télécom ont commencé à mettre en œuvre ces principes à grande échelle, en ayant comme objectif l'intégration des dizaines de systèmes disparates et des centaines d'applications legacy des différentes entreprises faisant partie du groupe. Nous avons montré que ces concepts étaient également applicables à beaucoup plus petite échelle et avec un autre objectif. En effet, moyennant un investissement en matériel, logiciel et ressources humaines très raisonnable, une PME peut actuellement transformer l'architecture de son système d'information existant de sorte qu'il soit compatible avec la fédération d'identité. Si ses partenaires commerciaux en font autant, elle peut alors établir un cercle de confiance avec ceux-ci, jetant ainsi les bases de nouvelles formes de collaboration entre les différents partenaires. Les entreprises concernées fonctionnent selon un modèle d'affaires qui est spécifique au métier qu'elles exercent. Nous avons proposé un modèle d'affaires qui complète celui-ci et qui définit les bases de ces collaborations. Nous avons montré que ces collaborations pouvaient être profitables, qu'elles étaient source de nouveaux revenus, qu'elles permettaient de réduire un certain nombre de coûts et, enfin, qu'elles pouvaient être génératrices de nouveaux marchés. Microsoft, l'un des principaux acteurs du marché, ne fait pas partie de Liberty Alliance et a défini un standard de fédération propriétaire. Nos prototypes illustrent comment construire des solutions entièrement Microsoft d'une part, comment définir des solutions inter opérables avec les produits implantant les spécifications de Liberty Alliance d'autre part. Nous avons ainsi défini les bases d'une solution complète et cohérente qui permet aux entreprises de prendre en connaissance de cause les décisions stratégiques techniques et commerciales nécessaires à leur positionnement dans un 42

43 Informatique de gestion ISNET 76 environnement distribué sécurisé et convivial. Pour que les PME adoptent ce type de solution et modernisent leur fonctionnement, il faut bien sûr qu'elles s'affranchissent de l'isolationnisme bien helvétique qui prévaut encore dans nombre d'entreprises, principalement celles à base fortement familiale. Nous devons leur faire comprendre que l'informatique n'est qu'un outil parmi d'autres pour accomplir leur mission. Il n'y a pas de profit direct et immédiat à mettre en œuvre la fédération d'identité ; il s'agit plutôt de mettre en place une structure qui s'inscrit dans une vision à moyen et long terme du mode de fonctionnement de l'entreprise. La fédération d'identité constitue, nous l'avons vu, le pilier fondamental des spécifications de Liberty Alliance. Ces spécifications comportent également la description d'autres services, de plus haut niveau, et pour lesquels les partenaires du consortium vont fournir des implantations dans une seconde phase. Ces services permettront principalement d'assurer l'inter opérabilité des Web Services requérant une authentification et d'implanter de nouvelles fonctionnalités tels que la géo localisation, des carnets de contacts décentralisés, des calendriers partagés, des services de présence ou d'alerte, etc. Nous envisageons, pour nos recherches futures, d'approfondir ces aspects qui sont la base sur laquelle il sera possible de construire une architecture orientée services 89 au sein d'une fédération, architecture qui sera un enjeu stratégique pour l'entreprise de demain. 89 SOA. 43

44 Informatique de gestion ISNET 76 8 BIBLIOGRAPHIE [Ang05] [Ber04] [Boy02] [Cah05] [Cha02] [Cla02] [Cro05] [Dei02a] [Dei02b] [Dub02] [Faj05] [Fra04] [JDN03] [Kem04] Rajeev Angal, Srividhya Narayanan, Pat Petterson, Malla Simhachalam, Building Identity-Enabled Web Services, 18 octobre 2005 Philippe Beraud, Jean-Yves Grasset, Gestion des identités numériques, mai 2004 Danah Boyd, FACETED ID/ENTITY : Managing representation in a digital world, septembre 2002 Conor Cahill & al., Liberty Technology Tutorial, soverviewaol.pdf, 2005 David Chappel, Tyler Jewell, Java Web Services, O'Reilly & Associates, Mars 2002, ISBN Mike Clark, Peter Fletcher, Jeffrey Hanson, Romin Irani, Mark Waterhouse, Jorgen Thelin, Web Services Business Strategies and Architectures, Expert Press, Août 2002, ISBN Pierre Cros, Authentic Guide de l'administrateur, Harvey Deitel, Paul Deitel, J. Gadzik, K. Lomeli, S. Santry, S. Zhang, Java Web Services For Experienced Programmers, Prentice Hall, Août 2002, ISBN Harvey Deitel, Paul Deitel, B. Duwalt, L. Trees, Web Services: A Technical Introduction, Prentice Hall, Août 2002, ISBN Magali Dubosson-Torbay, Alexander Osterwalder, Yves Pigneur, ebusiness Model Design, Classification and Measurements, Thunderbird International Business Review, vol 44, n 1, Janvier 2002 Aries Fajar Dwiputera, Single Sign-On architectures in public networks, INFOTECH Seminar Advanced Communication Services (ACS), 2005, France Telecom, Focus sur Liberty Alliance, 0/print_index1.htm, Octobre 2004 JDN Solutions, Liberty Alliance : les premiers projets voient le jour, 14 novembre 2003 John Kemp, Liberty ID-WSF a Web Services Framework, ty_id-wsf_web_services_framework.pdf,

45 Informatique de gestion ISNET 76 [Koc05] Michael Koch, Kathrin M. Möslein, Identities Management for E-Commerce and Collaboration Applications, International Journal of Electronic Commerce, vol 9, n 3, Spring 2005, [LaA03] Liberty Alliance Project, Introduction to the Liberty Alliance Identity Architecture, %20Identity%20Architecture%20Whitepaper%20Final.pdf, Mars 2003 [LaB03] Liberty Alliance Project, Business Benefits Of Federated Identity, %20Business%20Benefits%20White%20Paper%20v4.pdf, Avril 2003 [LaC03] Liberty Alliance Project, Business Guidelines : Raising the Business Requirements for Wide Scale Identity Federation, ertybusinessguidelines.pdf, Juillet 2003 [Leh02] Patrick Lehner, Utilisation d'internet dans les enterprises romandes, Georg Editeur SA, Mai 2002, ISBN [Lio04] Yves Lions, La gestion de l'identité en ligne, _FICHIER=248, 2002 [LPD92] Loi fédérale sur la protection des données du 19 juin 1992, 19 juin [Mad05] Paul Madsen, Liberty ID-WSF People Service federated social identity, ty_federated_social_identity.pdf, 5 décembre 2005 [Min02] Ministère du budget et de la réforme de l'état, Le projet Liberty Alliance : pour un standard de l identité numérique en réseau, 12 septembre 2002 [Miy06] Teruko Miyata & al., A Survey on Identity Management Protocols and Standards, IEICE Transactions on Information and Systems, vol. E89-D, n 1, pp , D/1/112, Janvier [New04] PR Newswire, Le livre blanc de la Liberty Alliance examine comment l'identité fédérée permet de réduire le vol d'identité, 23 février 2004 [New05] PR Newswire, Liberty Alliance lance les Directives commerciales et de politique pour le déploiement de la gestion de l'identité fédérée, 11 octobre 2005 [Nor02] Eric Norlin, André Durand, Federated Identity Management,

46 Informatique de gestion ISNET 76 [Ola03] Thor Olavsrud, Liberty Alliance Details Identity Architecture, 11 mars 2003 [PaA04] Pat Patterson, Pirasenna Velandai Thiyagarajan, Federated Identity : Access Control and Single Sign-On, tations/sso_presentation.pdf, 5 octobre 2004 [PaB04] Pat Patterson, Pirasenna Velandai Thiyagarajan, Marina Sum, Federated Identity : Single Sign-On Among Enterprises, d.html, 14 octobre 2004 [Pag05] Sophie Page, L'ASP Une nouvelle solution pour la gestion de l'informatique en entreprise. Travail de diplôme à la Haute École de Gestion de Genève, Département Informatique de Gestion, Novembre [Pap03] Greg Papadopoulos, Getting It Right Digital identification and finegrained billing in the Web services world, [Pass] Microsoft Passport, [Pfi03] Birgit Pfitzmann, Michael Waidner, Analysis of Liberty Single-Sign-on with Enabled Clients, Internet Computing, IEEE, Volume 7, Issue 6, Novembre-Décembre [Rit03] Albert Ritch, Les Web Services. Travail de diplôme à la Haute École de Gestion de Genève, Département Informatique de Gestion, Novembre [Sal03] Olivier Salaün, Introduction aux architectures web de Single Sign-On, 15 octobre 2003 [Saml] SAML, [Sem02] Radovan Semancíc, Internet applications security, Novembre 2002 [Sub04] S. Subenthiran, K. Sandrasegaran, R. Shalak, Requirements for Identity Management in Next Generation Networks, Advanced Communication Technology, The 6 th International Conference on, Volume 1, pp , Septmbre 2004, ISBN [Sun02a] Sun Microsystems, Developper s Guide Sun One Application Server 7, [Sun02b] Sun Microsystems, Federation Management, 2 décembre

47 Informatique de gestion ISNET 76 [Sun04] Sun Microsystems, Sun Java System Access Manager Contrôle d'accès et services de fédération d'identité standardisés pour les intranets et les extranets, [Sun05] Sun Microsystems, Sun Java System Application Server, [Tas02] John Taschek, Liberty Alliance or Passeport?, Juin 2002 [Thi05] Pascal Thiaulier, Benard Roy, La gestion de l'identité et des accès, dentite_architecture.ppt, 2005 [Van03] Michelle Vance, Tiffany Van Gorder, Liberty Alliance Releases New Specifications, Privacy and Security Guidelines to Drive Development of Identity-Based Web Services, iance_releases_new_specifications_privacy_and_security_guidelines_to_dri ve_development_of_identity_based_web_services, Avril 2003 [Var03] Christine Varney, Privacy and Security Best Practices, _privacy_security_best_practices.pdf, 12 novembre 2003 [Var05] Christine Varney, Victoria Sheckler, Deployment Guidelines for Policy Decision Makers, oyment_guidelines_v2_9.pdf, 21 septembre 2005 [Vis05] Visual Studio.NET, [Was05] Thomas Wason, IEEE-ISTO, Liberty ID-FF Architecture Overview, V1.2, -liberty-idff-arch-overview-1.2-errata-v1.0.pdf, 2005 [Wss] WS-Security, [Xml02] OMG XML Metadata Interchange Specification version mai [Xpa99] XML Path Language version novembre

48 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 ANNEXES 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

49 Informatique de gestion ISNET 76 ANNEXE A Configuration pour sample1 Sur la base du document d installation du sample1 de Sun. HEG926 : SP1 SERVER_PROTO : http SERVER_HOST : heg926.ge-em.ad.etat-ge.ch SERVER_PORT : SERVICE_DEPLOY_URI : amserver META_ALIAS : heg926.ge-em.ad.etat-ge.ch Root suffix : dc=ge-em,dc=ad,dc=etat-ge,dc=ch Utilisateur à créer sur le serveur : sp1user / ploufman HEG931 : IDP1 SERVER_PROTO : http SERVER_HOST : heg931.ge-em.ad.etat-ge.ch SERVER_PORT : SERVICE_DEPLOY_URI : amserver META_ALIAS : heg931.ge-em.ad.etat-ge.ch Root suffix : dc=ge-em,dc=ad,dc=etat-ge,dc=ch Utilisateur à créer sur le serveur : sp1user / ploufman Répertoires Sun Access Manager : D:\Sun\AccessManager Sun Web Server : D:\Sun\WebServer Répertoire du serveur virtuel dans Sun Web Server : D:\Sun\WebServer\https-<hostname> Autres configurations Les deux machines se trouvant sur le même DNS, il faut modifier le nom du cookie qu elles utilisent pour éviter qu ils ne s écrasent mutuellement sur le browser (voir les notes d installation). 1

50 Informatique de gestion ISNET 76 Notes sur Access Manager Démarrer les services pour démarrer le serveur web, il faut d abord fermer IIS : dans les services windows, il faut arrêter Service de publication World Wide Web. Ensuite on peut démarrer Web Server (https-<hostname>) Configuration des serveurs la configuration des serveurs virtuels se trouve dans : D:\Sun\WebServer\https-<hostname>\config Le fichier server.xml indique notamment le port que le listener de Web Server écoute : <LS id="ls1" port="19709" servername="heg931.ge-em.ad.etatge.ch" defaultvs="https-heg931.ge-em.ad.etat-ge.ch" ip="any" security="false" acceptorthreads="1" blocking="false"/> Si Access Manager est installé sur Web Server, c est donc également sur ce port qu il est accessible. On trouve aussi dans ce fichier la liste des applications web déployées. Admin du serveur web pour accéder à l administration du serveur web, il faut démarrer le service correspondant : Démarrer\Sun Microsystems\Web Server\Start Web Server Administration Server ou aller dans les services Windows et démarrer Web Server Administration Server. On y accède ensuite avec l url du serveur web mais sur le port 8888 Supprimer le password admin du serveur web pour supprimer le mot de passe admin pour Web Server Administration : Dans le fichier D:\Sun\WebServer\https-admserv\config\admpw, le mot de passe est écrit sous la forme login:password Il faut supprimer le mot de passe après le login, et se logger en admin sans mot de passe. 2

51 Informatique de gestion ISNET 76 Pages de login AM pour modifier l aspect des pages de login d Access Manager, il faut éditer les fichiers dans D:\Sun\WebServer\https-HEG931.ge-em.ad.etat-ge.ch\is-webapps\services\config\auth (Supposition : à la création du serveur virtuel https-heg931.ge-em.ad.etat-ge.ch, les fichiers contenus dans D:\Sun\AccessManager\web-src sont copiés dans D:\Sun\WebServer\https-HEG931.ge-em.ad.etat-ge.ch\is-web-apps). Admin AM pour accéder à l interface de gestion d Access Manager, il faut aller sur le serveur web dans le répertoire amconsole, par exemple : Créer un utilisateur Dans la console d administration (ex : aller dans l onglet Gestion des Identités, puis afficher Utilisateurs, cliquer sur Nouveau et remplir les champs obligatoires. Déployer une application web Il y a deux manières de déployer une application web : 1) avec la commande wdeploy, en suivant les instructions du guide d installation. uri_path : /sp1 instance : heg926.ge-em.ad.etat-ge.ch vs_id : https-heg926.ge-em.ad.etat-ge.ch (Attention: sensible à la casse) -d directory : ignoré 2) depuis l interface d administration du serveur web Sun. Il faut pour cela démarrer le serveur d administration (dans les services windows), puis ouvrir la console web de la machine sur le port 8888 (ex : et se logger avec les login choisi à l installation. Sur la page principale, choisir le serveur et cliquer sur manage, puis aller à l onglet virtual server class. Choisir la classe et cliquer sur manage, puis choisir le serveur virtuel et cliquer sur manage. Dans l onglet Web applications, choisir le menu Deploy Web Application (à gauche), sélectionner le fichier war et choisir l URI (par exemple "/sp1"), puis valider. Serveurs IDP et SP sur le même domaine Si les serveurs d identification (IDP) et du fournisseur de service (SP) sont sur le même domaine (ex : heg931.ge-em.ad.etat-ge.ch et heg926.ge-em.ad.etat-ge.ch sont tous les deux dans le domaine ge-em.ad.etat-ge.ch), les cookies se trouvent dans la même 3

52 Informatique de gestion ISNET 76 entrée sur le browser et par conséquent, ils s écrasent mutuellement. Ceci provoque un échec dans la fédération (l utilisateur n arrive jamais sur la page Federation Done). Pour éviter cela, il faut renommer les cookies utilisés par les serveurs pour que chacun porte un nom différent. Par défaut, le cookie est nommé iplanetdirectorypro. Il faut éditer le fichier AMConfig.properties qui se trouve dans le sous-répertoire config du répertoire d installation d Access Manager. Il suffit ensuite de modifier la propriété com.iplanet.am.cookie.name pour que les cookies de chaque serveur soient nommés différemment (ex : com.iplanet.am.cookie.name=idp1cookie sur le serveur IDP1 et com.iplanet.am.cookie.name=sp1cookie sur le serveur SP1) Pour créer une organisation / sous-organisation Aller dans la console d administration, onglet gestion des identités. En haut du menu de gauche est inscrit l organisation courante (ex : ge-em). On peut voir les informations relatives à cette organisation avec la liste déroulante Afficher. En choisissant Organisations et Nouveau, on peut créer une sous-organisation. Ensuite, en cliquant sur cette sous-organisation (sur lien hypertexte, pas sur la flèche à droite), on entre dans la sous-organisation, comme l indique l indication en haut du menu de gauche (ex : ge-em > suborg). 4

53 Annexe B : ISNet76 HEVs Active Directory Federation Services (ADFS)... 4 Système requis... 4 Scénarios... 4 B2B: ADFS Federated Web SSO... 4 B2E: ADFS Extranet Web SSO... 5 B2C : ADFS «Online» Web SSO... 5 Extensions/interopérabilités... 6 Token-based and Claims-aware applications... 6 Lab (Scénario B2B)...7 AD configuration...8 ADFS Configuration... 8 Création d une application claims-aware... 9 Troubleshooting Url du site Scénario B2C ADFS configuration Url du site Erreur Intégration du scénario avec Authorization Manager Fonctionnalités de l application Configuration de l Active Directory et Active Directory Federation Services Configuration de l Authorization Manager Configuration de l application (web.config) Code behind Limitations Erreurs URL du site Application Token-Based Exemple SharePoint AD Configuration SharePoint Configuration ADFS Configuration Url du site Sources MIIS Versions Compatibilité Système requis: Password Management Bon à savoir: Sources: Centrify DirectControl Composants DirectControl Téléchargement de Centrify DirectControl

54 Installation du module Configuration de Tomcat pour l authentification avec Centrify DC Installation de l exemple «ADFS-claims-aware» Configuration du server d application pour SSL Déclaration de l application au niveau du serveur ADFS Tester l application Développez l application claims-aware Rôles Tomcat IfUserInRole tag Source Problème de certificats Source Liberty Alliance Concepts clés Fédération SSO initiation Implémentations libres Membres actuels...30 Liberty Alliance Interoperability PingFederate SymLabs Sun IBM Oracle Novell Liste complète Sources PingFederate Overview Nature du produit Description du produit Concepts clés Adapters et Agent toolkit Interopérabilités Installation du serveur Déploiement des scénarios (SAML 2.0) Paramètres locaux Configuration de l IDAdapter Configuration du SP Adapter Connexion au SP Connexion à l IdP Test du scénario IdP-Initiated Test du scénario SP-Initiated Personnalisation de l application en fonction de l utilisateur Ajout d un attribut Configuration du SpAdapter pour l ajout d un attribut Configuration de l IdPAdapter pour l ajout d un attribut Modification de l application Intégration avec l ADFS (SP connexion)

55 LDAP IdPAdapter Configuration LDAP Data Store Configuration ADFS account partner ADFS SP Connexion Test de l application Erreur Intégration avec l ADFS (IdP connexion) ADFS resource partner ADFS IdP Connexion Test de l application Erreur Sources SourceID Installation du framework et des exemples Test de l application...61 Interopérabilité Erreurs Org.Mentalis.Security System.Security.dll Autres projets d identité fédérée Shibboleth Source Liberty Alliance, Shibboleth et Lemonldap Source Microsoft Passport Standards identités fédérées Tableau des principaux projets d identités fédérées Evolution des standards Tableau de comparaison.net Passport, Ping ID et Shibboleth FAQ Existe-il un méta-annuaire unique pour une fédération? L interopérabilité entre les protocoles Liberty Alliance et ADFS est-elle possible? ADFS ou Liberty Alliance? Sources

56 Active Directory Federation Services (ADFS) ADFS est un composant de Windows Server 2003 R2. Il fournit la technologie SSO (Single Sign-On) pour des applications Web dans des scénarios extranet tels que B2C, B2B ou interne à une compagnie (multi-forest) dans un environnement Windows. ADFS utilise les spécifications WS-Federation. Cependant, il fournit en extension une architecture supportant les assertions SAML et l authentification via Kerberos. Système requis Windows Server 2003 R2 Internet Information Services (IIS) version 6.0 Microsoft ASP.NET 2.0 Microsoft.NET Framework 2.0 Le site Web IIS par défaut configuré avec TLS (Transport Layer Security) ou SSL (Secure Sockets Layer), utilisé par Microsoft IT pour sa solution. ADFS est installé dans le site Web par défaut sur le serveur IIS. Un certificat pour le service de fédération. Microsoft IT utilise le même certificat X.509 pour la signature des jetons et pour l'authentification SSL auprès des sites Web. Scénarios B2B: ADFS Federated Web SSO Dans ce scenario, l utilisateur d une compagnie partenaire n a pas besoin d un compte à l intérieur de l Active Directory du domaine dans lequel se trouve la ressource qu il veut utiliser. Il se connecte en local, initialise sa connexion SSO et peut accéder à la ressource du domaine partenaire grâce à la Federation Trust entre les deux serveurs de fédération : le serveur de fédération account auprès duquel s authentifie l utilisateur et le serveur de fédération resource qui le met en lien avec l application Web qui tourne sur le serveur Web du domaine. [projectdirectory]/adfs/adfs_itforum.ppt 4

57 B2E: ADFS Extranet Web SSO Tous les employés d une compagnie ont un compte dans l Active Directory. Ils peuvent se connecter soit en intranet (Windows Desktop logon) soit à partir d une application Web (Forms-based logon). [projectdirectory]/adfs/adfs_itforum.ppt A noter la nécessité d utiliser un serveur de fédération proxy qui va faire le lien avec le serveur de fédération account, afin de permettre à l utilisateur venant de l internet de s authentifier dans son domaine (Active Directory du domaine, son «royaume») B2C : ADFS «Online» Web SSO Dans ce cas là, les utilisateurs internet sont des clients et ont leur compte dans la DMZ. Ils utilisent un login internet (Form-based login). [projectdirectory]/adfs/adfs_itforum.ppt 5

58 Extensions/interopérabilités ADFS a été conçu pour tourner dans un environnement Windows, selon les scenarios décrits précédemment. Il gère deux types d applications (ressources) aux mécanismes différents, Token-based et Claims-Aware, tournant sur le serveur Web IIS (langage.net). Cependant, il existe des extensions ou toolkits pour étendre l ADFS à d autres plateformes, tels que : a. Centrify b. SourceID L interopérabilité entre ADFS et des plateformes autres que Windows peut se faire à l aide des serveurs de fédération résultants des projets Liberty Alliance et Shibboleth, basés sur les spécifications SAML, mais intégrant également les fédérations basées sur WS-federation. a. Pingfederate (SourceID) b. Shibboleth Token-based and Claims-aware applications Claims-Aware applications: Les Claims sont des déclarations (par exemple: name, identity, key, group, privilege, ou capability) faites sur les utilisateurs et comprises par les deux partenaires dans l ADFS. Elles sont utilisées pour des buts d autorisation dans une application. Ces claims se baladent à travers le service de fédération entre les serveurs de fédérations et entre les serveurs de fédération ressource et la ressource. Une application claims-aware accepte les claims envoyés par le service de Fédération. Lien : Sitemap : Welcome to the Windows Server TechCenter > Windows Server TechCenter > Windows Server 2003 Technical Library > Windows Server 2003: Product Help > R2: Product Help (R2 only) > Active Directory Federation Services (ADFS) > ADFS Concepts > Understanding ADFS Authentication and Authorization > Understanding Claims Et : Welcome to the Windows Server TechCenter > Windows Server TechCenter > Windows Server 2003 Technical Library > Windows Server 2003: Product Help > R2: Product Help (R2 only) > Active Directory Federation Services (ADFS) > ADFS Concepts > Understanding ADFS Authentication and Authorization > Controlling Access to Web-based Applications > Claims-aware applications Token-Based applications: Une application Token-based est une application IIS (sharepoint par exemple) qui utilise les mécanismes d autorisation «natifs» de Windows. Ces applications ne sont pas préparées pour utiliser les claims. Elles ne peuvent être utilisées que par des utilisateurs du royaume local ou d un royaume de confiance (trusted realm). Pour plus d informations, suivez le lien : Sitemap: Welcome to the Windows Server TechCenter > Windows Server TechCenter > Windows Server 2003 Technical Library > Windows Server 2003: Product Help > R2: Product Help (R2 only) > Active Directory Federation Services (ADFS) > ADFS Concepts > Understanding ADFS Authentication and Authorization > Controlling Access to Web-based Applications > Windows NT token-based applications 6

59 Lab (Scénario B2B) L architecture mise en place se présente sous la forme suivante: [projectdirectory]/adfs/adfs_step-by-step_guide.doc J ai donc configuré quatre machines virtuelles : - serveur de fédération resource (domaine treyresearch.net) - serveur de fédération account (domaine adatum.com) - serveur Web (domaine treyresearch.net) où se trouve la resource - poste client (domaine adatum.com) d où un utilisateur du domaine local veut accéder à la ressource du domaine partenaire. Machine virtuelle W2003 Enterprise Edition adfsresource W2003 Enterprise Edition adfsaccount W2003 Standard Edition adfsclient W2003 Standard Edition adfsweb Computer use Federation Server Federation Server Poste Client Web server Computer name adfsresource adfsaccount adfsclient adfsweb Adresse IP Passerelle DNS Alternate DNS Composants Application server (IIS) Application server (IIS) Application server (IIS) Windows Federation service Federation service ADFS web agents Active Directory yes yes no no DNS server yes yes no no Domain treyresearch.net adatum.com adatum.com treyresearch.net NetBios Name treyresearch adatum Softwares IIS Resource kit 6.0 IIS Resource kit 6.0 IIS Resource kit 6.0 SQL Server 2000 SQL Server 2000 SQL Server Express enterprise edition sp 4 enterprise edition sp Others MIIS MIIS PingFederate Java SDK 1.5/Apache SSL Certificate SSL Certificate generated generated Set Set AdfsAppPoolIdentity AdfsAppPoolIdentity (both fed server and domain controller on the same computer) Windows sharepoints services SSL Certificate generated Se référer au document «ADFS_Stepbystep.doc» pour les étapes de l installation. Stepbystep website 7

60 AD configuration Le but était de créer deux utilisateurs dans l Active Directory de leur domaine, pouvant accéder à une petite application Web du domaine partenaire, mais avec des rôles différents. Concrètement, l utilisateur adminis se connecte en local sur son domaine, initie le Web SSO et accède à l application Web du domaine partenaire avec les droits administrateur. Le cheminement est le même pour l autre utilisateur, mise à part qu il n a pas les droits pour accéder à l administration de l application Web. Dans l Active Directory du domaine adatum.com, création des utilisateurs et des groupes d utilisateurs : Création Nom User name Security global group TreyClaimAppAdmins Not applicable Security global group TreyClaimAppUsers Not applicable User Admin Hister Adminis (adminis va pouvoir accéder à l application Claims-aware avec le rôle administrateur) User Alan Shen Alansh (alansh va accéder à l application Claims-aware avec le rôle guests) User Admin Hister Alan Shen Add as a member of: TreyClaimAppAdmins TreyClaimAppUsers ADFS Configuration Le principe est le suivant : on crée des «Organization claims» de type groupe du côté «account» du service de fédération qui sont liés à des groupes d utilisateurs de l Active Directory. A partir des ces «Organization claims», des «Outgoing claims» sont envoyés à travers la fédération. Du côté «resource», ils sont réceptionnés en tant que «Incoming claims» et transformés en «Organization claims». Chaque «claims» requis par l application sont activés, afin qu elle puisse les recevoir : Account Federated Resource Claim type Group Namespace Active Directory Account Organization Claims (incoming/ outgoing) TreyClaimsAppUsers Trey ClaimApp Claim ClaimAppMappi ng TreyClaimsAppAdmin s Trey Claim App Admin ClaimAppAdmin Resource Organization Claims Adatum ClaimApp Claim Adatum ClaimApp Admin Enabled in App Oui Oui 8

61 Schéma du flux des claims à travers la fédération : [projectdirectory]/adfs/adfs_step-by-step_guide.doc Création d une application claims-aware Il reste à construire une application Web en.net qui réceptionne et utilise les claims. Dans mon exemple, j attribue les rôles aux utilisateurs en fonction de leur «Organization claims». J ai d abord créé une petite application avec login qui gère des utilisateurs et des rôles enregistrés dans une base de données SQL (ASPNETDB.mdf). Cette application accepte deux rôles : Administrators et Guests. L utilisateur auquel est attribué le rôle Administrators a accès aux pages d administration, les autres non. Si un utilisateur de la fédération a pour claims l «Organization claims» «Adatum ClaimApp Admin», alors il se voit attribuer le rôle Administrators, autrement il a le rôle «Guests». Pour créer une application qui accepte les claims, voir le fichier Web.config de l application. Dans le fichier de code behind, j ai utilisé le code suivant : using System.Web.Security.SingleSignOn; using System.Web.Security.SingleSignOn.Authorization; protected void Page_Load(object sender, EventArgs e) { SingleSignOnIdentity ssoid = User.Identity as SingleSignOnIdentity; SecurityPropertyCollection spc = ssoid.securitypropertycollection; SecurityProperty sp = spc[1]; } if (sp.value.equals("adatum ClaimApp Admin")) { Roles.AddUserToRole(name, "Administrators"); } 9

62 Pour gérer les droits utilisateurs de manière plus précise et plus personnalisée, il y a la possibilité d utiliser AzMan (Authorization Manager). Le login (basé sur ASP.NET Role Manager) ne fonctionne pas avec les claims. Impossible de se loguer. Troubleshooting En cas de problème de fonctionnement du service de Fédération, le lien suivant permet de mettre en place l environnement permettant le Débogage et d établir un diagnostic des pannes de l ADFS : Sitemap: Welcome to the Windows Server TechCenter > Windows Server TechCenter > Windows Server 2003 Technical Library > Windows Server 2003: Operations > R2: Operations (R2 only) > ADFS Operations Guide > Troubleshooting Active Directory Federation Services Erreur Si éventuellement cette erreur survient et qu en apparence tout est bien paramétré, remplacé dans la configuration des serveurs de fédération l adresse DNS par l adresse IP du serveur. Url du site 10

63 Scénario B2C Le scénario B2C consiste à créer une application Web permettant à un utilisateur internet (mais qui possède un compte dans l Active Directory) de se connecter à l Active Directory, afin d accéder à la ressource du domaine. Comme les machines virtuelles ont des adresses IP privées, je dois installer l application Web d authentification à Active Directory sur le même domaine que l application claims-aware. En cas de succès de l authentification, l application redirige l utilisateur sur l application claims-aware pour l initialisation du SSO. Pour plus d informations sur la manière d utiliser les formulaires d authentification à l Active Directory en ASP.NET 2.0 consultez les sites : Et De même que les fichiers sources du site «formsadauth». ADFS configuration Il faut créer un claim pour un utilisateur du domaine treyresearch.net. Prenons l exemple de l utilisateur Terry Adams (terrya) créé dans l Active Directory du domaine treyresearch.net sous Users. J ai créé un nouvel «Organization Claim» Trey ClaimApp External (Facultatif, car l utilisateur Terry Adams peut être mappé à un «Organization Claim» déjà existant. Ensuite, j ai mappé (populate) l utilisateur depuis l Active Directory au groupe («Organization Claim») («Group Claim Extraction»). Finalement, j ai activé le groupe pour l application claims-aware. Url du site Erreur Impossible de se connecter à l annuaire LDAP du domaine Adatum.com ("Unable to establish secure connection with the server"). Nécessite probablement l installation d un proxy. 11

64 Intégration du scénario avec Authorization Manager L Authorization Manager (AzMan) est une nouvelle fonctionnalité de Windows Server 2003 qui permet à l aide d un «snap-in mmc» (azman.msc) d implémenter l administration d une application basé sur les rôles. Et comme la sécurité sur le framework.net met essentiellement l accent sur les rôles Dans AzMan, on définit les autorisations pour une application pour un utilisateur de l Active Directory. Comme les rôles liés à un utilisateur peuvent contenir des tâches, qui peuvent contenir des opérations, on peut définir de manière plus précise (affiner) et mieux structurée les autorisations pour chaque utilisateur. Plus d infos à l adresse (Concepts + création d un nouveau magasin): n_windows_server_2003_part1.html Fonctionnalités de l application J ai une application Web qui accède à la base de données Northwind et affiche les tables Customer et Order dans un Gridview. Les données comprises dans la table Customer peuvent être effacées ou mise à jour à partir du Gridview. Il est possible d ajouter un nouveau client ou une nouvelle commande. Un lien hypertexte renvoie sur une page de l administration (dossier admin accessible uniquement avec le rôle ASPNET Administrator), qui permet l insertion via un FormView. Chaque fonctionnalité de l application correspond à une opération définie dans AzMan. Selon les rôles affectés à l utilisateur, il pourra accéder à l une ou l autre des fonctionnalités. Les rôles AzMan définissent les fonctionnalités accessibles à un utilisateur (propriétés «enabled» ou «visible» des contrôles), mais ils doivent aussi correspondre aux rôles ASPNET qui définissent l accès aux dossiers et aux fichiers. Ainsi, l utilisateur MrS contenu dans le rôle Manager de AzMan, doit aussi, d après son rôle AzMan être ajouté au rôle Administrator de ASPNET. Le rôle AzMan permet à cet utilisateur d activer l hyperlien qui pointe sur la page d ajout d un nouveau client et le rôle ASPNET donne les droits d accès à cette page ou au dossier dans laquelle elle se trouve. Configuration de l Active Directory et Active Directory Federation Services Il faut créer les utilisateurs qui vont pouvoir accéder à l application. Tous les utilisateurs proviennent du domaine treyresearch.net. Les domaines étant privés, AzMan n arrive pas à accéder à l annuaire LDAP du domaine adatum.com. Utilisateurs créés : terrya, mrs, azbak. Les deux premiers existent déjà et sont configurés dans l ADFS. Par contre l utilisateur Azman Rbac doit figurer dans l ADFS pour la création du claim lisible par l application. Simplement, dans le magasin Active Directory de l ADFS, au niveau du groupe d extraction des claims (*, Trey ClaimApp External), rajouter l utilisateur azbak. Configuration de l Authorization Manager Pour créer un nouveau magasin, une nouvelle application et pour des détails sur les concepts et les objets se trouvant dans AzMan, se référer aux liens «Création d un magasin AzMan» et «Définition des rôles AzMan» de la section source. Voici à quoi ressemble ma configuration AzMan. A noter le nom de l application (très important) : claimsaware : 12

65 Dans le dossier Groups du magasin, j ai créé un groupe admins avec l utilisateur mrs. J ai ensuite défini les opérations suivantes : ID Opération Nom Opération Description Opération 1 Select Customers Active l affichage du GridView des clients 2 Add Customer Active la fonctionnalité d ajout d un nouveau client 3 Delete Customer Active le bouton Delete du GridView des clients 4 Update Customer Active le bouton Edit du GridView des clients 5 Create Customer Active la fonctionnalité d ajout d une commande 6 Select Orders Active l affichage du GridView des commandes Puis les tâches suivantes : ID Tâche Nom Tâche Description Tâche Contient opérations/tâches 1 Display Customer Active l affichage des GridView op:1, op:6 2 Modify Customer Active la gestion des données des grilles op:2, op:3, op:4, tâche:1 Et enfin les rôles suivants : Nom Rôle Description Rôle Contient rôle/tâches/opérations Reader Peut lire les données tâche:1 Manager Gère les données rôle:1, tâche:2, op:5 Ensuite, reste à assigner les utilisateurs aux rôles : Nom Rôle Assignement utilisateurs Reader Manager Restricted (facultatif) [email protected] [email protected] (groupe admins) [email protected] La création des tâches n est pas très utile, car la référence «Microsoft.Interop.Security.AzRoles.dll» en.net ne permet pas d accéder aux tâches, mais uniquement aux opérations en fonction de leurs identifiants. 13

66 Configuration de l application (web.config) Il faut tout d abord rajouter à la section <ConnectionStrings>, la connexion à la base de données (utilisation de SQL Express Server 2005) et la connexion à l annuaire LDAP. <connectionstrings> <add name="northwindconnectionstring" connectionstring="data Source=adfsweb\SQLExpress;integrated security=true;attachdbfilename=c:\sql Server 2000 Sample Databases\NORTHWND.MDF;user instance=true;" providername="system.data.sqlclient" /> <add name="localpolicystore" connectionstring="msldap://adfsresource.treyresearch.net/cn=app,dc=treyresearch,dc=net" /> </connectionstrings> Dans la section <rolemanager>, il faut ajouter le rolemanager d AzMan : <rolemanager enabled="true" cacherolesincookie="true" defaultprovider="aspnetsqlroleprovider" cookiename=".aspxroles" cookiepath="/" cookietimeout="30" cookierequiressl="true" cookieslidingexpiration="true" createpersistentcookie="false" cookieprotection="all"> <providers> <add name="rolemanagerazmanprovider" type="system.web.security.authorizationstoreroleprovider, System.Web, Version= , Culture=neutral, publickeytoken=b03f5f7f11d50a3a" connectionstringname="localpolicystore" applicationname="claimsaware"/> </providers> </rolemanager> Le provider par défaut est le rolemanager AspNet (défini dans machine.config). Si l on met le rolemanager d AzMan comme provider par défaut, alors les rôles utilisés seront ceux d AzMan. Par exemple, le code suivant : if (!User.IsInRole(role)) Roles.AddUserToRole(name, role); Si le provider par défaut est AzMan: le test se fait sur les rôles AzMan et le code «Roles.AddUserToRole» génère une exception. Il ne semblerait pas que l on puisse administrer AzMan avec du code.net (ce qui paraît logique pour des questions de sécurité). De plus, je n ai pas trouvé le moyen de gérer les droits d accès aux dossiers ou fichiers de l application Web avec des donc rôles AzMan, pas d accès à la partie administration. Si le provider par défaut est ASPNET : le test se fait sur les rôles ASPNET et le code cidessus permet de transférer le rôle AzMan en rôle ASPNET. Ainsi, si un utilisateur à le rôle Manager sous AzMan, il obtiendra le rôle Administrator sous ASPNET, lui donnant ainsi accès à la partie admin. Code behind La première chose à faire est d importer la référence «Microsoft.Interop.Security.AzRoles.dll». Elle se trouve dans l onglet «COM» sous le nom de «AzRole 1.0» (je ne sais pas le nom exact) si l on travaille sur Windows Server

67 Sinon, il faut télécharger le runtime «Windows 2000 Server Authorization Manager Runtime» à l adresse Après exécution du setup, la dll se trouve dans le répertoire «[installation _directory]\windows(r) 2000 Authorization Manager Runtime\PIA \1.2\» using Microsoft.Interop.Security.AzRoles; Le code pour se connecter à AzMan, initialiser un magasin et ouvrir l application «claimsaware» est le suivant : AzAuthorizationStoreClass AzManStore = new AzAuthorizationStoreClass(); AzManStore.Initialize(0, ConfigurationManager.ConnectionStrings ["LocalPolicyStore"].ConnectionString, null); IAzApplication azapp = AzManStore.OpenApplication("claimsaware", null); Création du contexte client IPrincipal userprincipal = HttpContext.Current.User; WindowsIdentity useridentity = userprincipal.identity as WindowsIdentity; clientcontext = azapp.initializeclientcontextfromname(name, sp.value, null); où SingleSignOnIdentity ssoid = User.Identity as SingleSignOnIdentity; name = HttpContext.Current.User.Identity.Name.ToString(); SecurityPropertyCollection spc = ssoid.securitypropertycollection; SecurityProperty sp = spc[1]; On récupère ensuite tous les rôles ASPNET de l utilisateur et on les efface. Cette réinitialisation est nécessaire, au cas où on aurait changé le rôle d un utilisateur dans AzMan. Les rôles ASPNET doivent correspondre aux rôles AzMan tels qu il sont définis au moment de lancer l application. String[] myroles = Roles.GetRolesForUser(); Roles.RemoveUserFromRoles(name, myroles); Ensuite, pour chaque rôle AzMan attribué à l utilisateur courant, on va générer le rôle ASPNET correspondant. Array data = (Array)clientContext.GetRoles(null); foreach (string Role in data) { if (Role == "Manager") gogetrole("administrators"); if (Role == "Reader") gogetrole("guests"); if (Role == "Restricted") Label2.Text += "restricted access: no role obtained"; } protected void gogetrole(string role) { if (!User.IsInRole(role)) { Roles.AddUserToRole(name, role); } Label2.Text += role; } 15

68 Cette façon de faire n est pas dynamique et l ajout d un rôle AzMan peut entraîner l ajout d un rôle ASPNET, ce qui dans le code ci-dessus implique que l on doive rajouter une ligne. Pour éviter cette situation, le mieux est de créer des rôles AzMan et ASPNET avec des noms identiques, évitant ainsi les tests : foreach (string Role in data) gogetrole(role); Pour créer un rôle ASPNET dynamique, utiliser le contrôle «CreateUserWizard. Pour activer les fonctionnalités liées à un utilisateur, on va tester pour chaque opération si l utilisateur peut accéder à cette opération. Si oui, fonctionnalité activée. if (op_validation(1)) activeop_selectcustomer(); if (op_validation(2)) activeop_addcustomer(); if (op_validation(3)) activeop_delcustomer(); if (op_validation(4)) activeop_modcustomer(); if (op_validation(5)) activeop_addorder(); if (op_validation(6)) activeop_selectorders(); protected Boolean op_validation(int opid) { object[] operationids = new object[] { opid }; object[] result = (object[])clientcontext.accesscheck("auditstring", new object[1], operationids, null, null, null, null, null); } int accessallowed = (int)result[0]; if (accessallowed!= 0) { return false; } else { return true; } Si on ajoute une opération, il faut ajouter un test avec la méthode qui va avec. Dans le principe, j ai créé une méthode pour chaque fonctionnalité (=pour chaque opération). Limitations Les tâches ne peuvent pas être gérées avec.net. Le code est peut dynamique. Un changement dans AzMan peut entraîner une réécriture du code de l application. Avec une application de type claims-aware, il n est pas possible de se loguer avec un utilisateur ASPNET, malgré que le rôle manager pour ASPNET est activé. Cette solution apporte quand même un plus par rapport à une solution sans AzMan, car il permet un affinage des droits utilisateurs, grâce à la notion d opérations. Sans AzMan, c est possible de gérer l application de la même manière, mais comme la notion d opérations n existe plus, il faudrait créer un rôle pour remplacer chaque opération. Au niveau de l ADFS, 16

69 il faudrait créer des groupes («Claims Aware Applications») pour chaque rôle ASPNET, car on détermine le rôle d un utilisateur en fonction de son groupe claims. C est possible, même si c est moins intéressant avec une structure moins logique. Erreurs 1. Le nom de l application est «claimsaware» et non pas «app» (=magasin). 2. La chaine de connexion à LDAP commence par «msldap» et non «ldap». CN= au nom du magasin. 3. «Database is read-only» Solution: Télécharger l outil SSEUtil de SQLExpress, puis tapez en commande: C:\temp>SSEUtil.exe -child "NT Authority\Network Service" -detach C:\Inetpub\stepbystep\claimapp\App_Data\aspnetdb.mdf 4. Droits d accès insuffisants pour accéder à AzMan (ouverture de l application). Dans AzMan, faites un clique droit sur le nom du magasin > propriétés > security, puis ajouter les droits de lectures à IIS (IIS_WPG). URL du site Application Token-Based Exemple SharePoint L application SharePoint est une application de type Windows Traditionnal ou Token-Based. On va voir avec cet exemple, comment mettre en place l ADFS avec une application de ce type. Dans l idée, on a deux utilisateurs de deux domaines différents : terrya du domaine treyresearch qui à un rôle administrateur et adamcar du domaine adatum qui a un rôle lecteur. AD Configuration Dans l Active Directory du domaine treyresearch: Création Nom User name Security global group Federated users/ Not applicable AdatumTokenAppUsers User Terry Adams Terrya (terrya va pouvoir accéder à l application Token-Based avec le rôle administrateur) Dans l active Directory du domaine adatum : Création Nom User name Security global group TreyTokenAppUsers Not applicable User Adam Carter adamcar (adamcar va pouvoir accéder à l application Token-Based avec le rôle lecteur) Adam Carter est ajouté au groupe TreyTokenAppUsers. Via l ADFS, le groupe TreyTokenAppUsers sera associé au groupe AdatumTokenAppUsers à qui est attribué le droit de lecture dans SharePoint. Ce droit de lecture ne peut pas être attribué directement à Adam Carter dans la configuration de SharePoint, car il appartient à un autre domaine que celui où est installé SharePoint. 17

70 SharePoint Configuration Pour installer SharePoint, se référer au manuel «ADFS_stepbystep.doc» : En résumé, dans «add/remove programs/windows components», il faut installer «SharePoints services» et «ADFS Web Agents», de même qu il faut configurer IIS avec l ADFS Web Agent (Token- Based). Une fois l installation effectuée, il faut configurer les permissions d accès à SharePoint : Création de l utilisateur terrya avec le rôle administrateur et du groupe TreyTokenAppUsers avec le rôle lecteur. ADFS Configuration Adam Carter appartient au groupe TreyTokenAppUsers, qui va se retrouver associé au groupe AdatumTokenAppUsers du serveur resource, via les claims. Claim type Group Account Federated Namespace Active Account (incoming/ Directory Organization outgoing) Claims TreyTokenAppUsers Trey TokenApp Claim TokenAppMappi ng Resource Resource Organization Claims Adatum TokenApp Claim Active Directory Resource group AdatumTokenAp pusers L utilisateur terrya n a pas besoin d être configuré dans l ADFS. Il faut être logué en local sous terrya pour accéder au site. Url du site Sources Windows Server 2003 R2 home: MS IT Showcase ADFS: 97CC93FE2C2D/ADFS-R2ITVC.doc Claims-Aware or Token-Based applications: Troubleshooting ADFS ADFS Overview [projectdirectory]/adfs/adfs_overview.doc Architecture ADFS et interopérabilité [projectdirectory]/adfs/adfs_architecture_drilldown.ppt [projectdirectory]/adfs/adfs_federated_identity.ppt [projectdirectory]/adfs/adfs_itforums.ppt 18

71 Lab/B2B Scénario [projectdirectory]/adfs/adfs_lab.pdf [projectdirectory]/adfs/adfs_step-by-step_guide.doc Création d un magasin AzMan n_windows_server_2003_part1.html Définition des rôles AzMan Windows-Server-2003-Part2.html Définition des opérations et des tâches msdn.microsoft.com/msdnmag/issues/03/11/authorizationmanager/ Authorization Manager et ASP.Net Résolution d erreurs MIIS MIIS est un système qui gère et coordonne les informations d identités provenant de multiples sources de données dans une organisation, permettant ainsi de combiner ces informations en une seule vue logique qui représente toutes les informations d identités pour un utilisateur ou une ressource donné. En d autres termes, il permet de regrouper (centralise et manage) les données utilisateurs, applications ou provenant d autres ressources réseau en une seule vue. Versions - Microsoft Identity Integration Server 2003 SP1, Enterprise Edition - Identity Integration Feature Pack 1a for Microsoft Windows Server Active Directory: o Gratuit, mais utilisable uniquement entre AD, ADAM, Exchange Server. Identity Integration Feature Pack 1a for Microsoft Windows Server Active Directory a été conçu pour intégrer les informations d identités entre plusieurs forêts Active Directory ou entre AD et ADAM. Compatibilité MIIS Server 2003 intègre les informations d identités provenant des sources suivantes : Network operating systems Microsoft Windows NT, Active Directory, Active Directory Application Mode, IBM Directory and directory services Server, Novell edirectory, Resource Access Control Facility (RACF), SunONE/iPlanet Directory, X.500 systems, Global Address Lists (Exchange), LDAP Directory Interchange Format and other met directory products Lotus Notes and Domino, Microsoft Exchange

72 Application Database File-based PeopleSoft, SAP, ERP, telephone switches, XML- and DSML-based systems Microsoft SQL Server, Oracle, Informix, dbase, IBM DB2, Access, Excel, OLE DB via SQL Data Transformation Services (DTS) DSMLv2, LDIF, CSV, delimited, fixed width, attribute value pairs Système requis: - Windows Server 2003 enterprise Edition (y.c. CALs (Client Access Licenses)) - SQL Server 2000 standard ou enterprise Edition SP3 Ceci est valable pour les deux versions. Password Management Cette fonctionnalité permet de regrouper les mots de passe d un utilisateur dans une même vue, afin de faciliter la réinitialisation (resetting) des mots de passe. En effet, l administrateur peut grâce à cette fonctionnalité gérer les mots de passe d un utilisateur depuis une seule application, au lieu de devoir perdre du temps à se déplacer là où il peut le réinitialiser. Exemple : Recherche de l utilisateur Accès à la vue de l ensemble des mots de passe de l utilisateur 20

73 Cette fonctionnalité ne fournit donc pas une solution SSO. Extrait du FAQ MIIS : MIIS 2003 peut-il synchroniser les mots de passe? Permet-il l'implémentation de l'identification unique (single sign-on, également appelé SSO)? Non. MIIS 2003 ne synchronise pas les mots de passe. Il permet à travers une simple interface Web de définir ou réinitialiser les mots de passe de différents systèmes. MIIS 2003 ne permet pas le single sign-on ; ce rôle est dévolu à Active Directory, Kerberos et d autres composants du système d exploitation Windows. Bon à savoir: - MMS n est plus valable. Il est définitivement remplacé par MIIS Avec MIIS, la gestion des mots de passe entraîne également une synchronisation entre MIIS et l Active Directory (ou autre méta-annuaires). ADFS, par contre, est étroitement intégré à Active Directory et ne nécessite pas de méta-annuaires à maintenir ou d architecture de synchronisation à construire. - MIIS et ADFS: ADFS is used for authentication, e.g., for WebSSO and for federated scenarios. MIIS is used for user provisioning with business rules and for directory synchronization. They complement each other.» ( d.mspx) Sources: MIIS 2003 Product Overview: MIIS 2003 SP1 System Requirements: Microsoft Identity Integration Server 2003 Frequently Asked Questions: FAQ MIIS Overview documentation: [projectdirectory]/miis/miis_sp1.doc Password management: [projectdirectory]/miis/miis_2003_password_management.doc Centrify DirectControl Centrify et Microsoft ont collaboré pour donner naissance au produit DirectControl qui permet notamment d étendre l ADFS à des applications Web tournant sur des plateformes Microsoft ou non-microsoft (Unix, Linux, Mac). Avec cette solution, Microsoft ADFS peut être utilisé pour fournir le Web SSO pour des applications Web hébergé sur Apache et différents serveurs J2EE tels qu IBM WebSphere, BEA WebLogic, JBoss, et Tomcat. Les rôles et droits d accès sont gérés dans l Active Directory. Les systèmes Linux et Unix sont intégrés à l Active Directory pour gérer les comptes de manière centralisée. 21

74 Le logiciel DirectControl suit les mêmes mécanismes que l ADFS, c est-à-dire qu il va fournir des Web Agents qui seront chargés d intercepter les claims, de les valider et de les transférer à l application. Il suffit d installer le Web Agent de DirectControl sur le serveur Web qui héberge l application. Composants DirectControl Les composants suivants peuvent être téléchargés dans le «Download Center» de Centrify : - Windows Management Tools : permet de mapper les utilisateurs des environnements Unix ou Linux dans l Active Directory - System Agents : agents systèmes pour les systèmes d exploitation suivants : 22

75 - Les agents web pour les plateformes web suivantes : Téléchargement de Centrify DirectControl Le premier objectif de l utilisation de Centrify DirectControl était d étendre l ADFS à une plateforme Web Apache pour l utilisation d applications java. Comme Centrify ne propose pas de modules d application pour Apache sur Windows, j ai choisi de tester avec Tomcat. A noter que l outil Windows Management Tool et que les agents systèmes ne sont utiles que si l on veut intégrer des utilisateurs Unix ou autres à l Active Directory. Pour tester l ADFS avec une application Java, il suffit de télécharger le module d application Apache Tomcat on Microsoft Windows. Le dossier dézippé contient : - la doc «Web_Java.pdf» - le fichier d installation «install.pl» sous le répertoire «\centrifydc-web\java\» - les exemples d applications sous le répertoire «\centrifydcweb\java\sampleapps\tomcat\tomcat5». Les fichiers «adfs-claims-aware.war» et «adfs-ordering.war» sont les plus intéressants pour nous. 23

76 Installation du module Dans l idéal et selon Centrify, il suffit de lancer l application «install.pl» qui va se charger de configurer Tomcat et mettre en place les exemples d application (Télécharger Perl pour pouvoir exécuter le fichier). Après avoir choisi Tomcat, les options suivantes se présentent : Configuration de Tomcat pour l authentification avec Centrify DC Des trois options proposées, seule la première option [1] fonctionne correctement. Elle copie les librairies Centrify au bon endroit dans l environnement Tomcat. Installation de l exemple «ADFS-claims-aware» L option [2] ne fonctionne pas : le programme n arrive pas à mettre à jour le fichier.war. Deux solutions : soit modifier les fichiers Perl, soit effectuer l installation manuellement. Pour faire fonctionner l option, il suffit de mettre en commentaire la ligne 235 du fichier «FsCommon.pm» du répertoire «C:\temp\centrify_tomcat\centrifydc-web\java\scripts\perl\CentrifyFs» Tel que # return (-4, "Failed to update $tmp_dir/$app_name.war with $CENTRIFYDC_FS_CONFIG_FILE"); C est mieux de vérifier manuellement que les changements ont bien été faits dans les fichiers de configuration de Tomcat. On effectue la vérification pour l exemple «adfs-claimsaware» : Attention : le guide «web_java.pdf», utile pour la modification manuelle des fichiers de config, contient des erreurs de frappe, caractères non UTF et erreurs de case-sensitive. Un copier-coller du code peut entraîner des erreurs de serveur Tomcat. 1. Dans le fichier «server.xml» sous le répertoire C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf : <Context path="/centrifydc-samples" docbase="adfs-main"/> <Context path="/centrifydc-samples/adfs-claims-aware" docbase="adfs-claims-aware"/> Ces deux lignes correspondent plus ou moins aux «Virtual Path» de IIS. Elles mettent en lien l adresse URL de la page Web avec le chemin physique qui contient cette page. 2. Dans le fichier centrifydc_fs.xml sous le repertoire «C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\adfs-claimsaware\WEB-INF», vérifier les lignes suivantes : 24

77 <federationserverurl> rationserverurl> <entryurl> Ces deux lignes sont les mêmes qui se trouvent dans le fichier «web.config» des applications.net et qui font le lien avec le serveur ADFS. Configuration du server d application pour SSL L option [3] ne fonctionne pas du tout. Il faut faire la configuration manuellement. 1. Dans le fichier «server.xml» sous le répertoire C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf, enlever les commentaires à la balise suivante. <Connector port="8443" maxhttpheadersize="8192" maxthreads="150" minsparethreads="25" maxsparethreads="75" enablelookups="false" disableuploadtimeout="true" acceptcount="100" scheme="https" secure="true" clientauth="false" keystorefile="\conf\keystore.jks" sslprotocol="tls" /> 2. Générer un certificat pour ce serveur avec l outil keytool et qui sera stocké dans le fichier «\conf\keystore.jks» : %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA -keystore C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf\keystore.jks 3. Importer le certificat du serveur host du serveur de fédération resource (certificat autosigné généré par selfssl ; exportation dans un fichier.cer depuis le site Web par défaut sous IIS) : Déclaration de l application au niveau du serveur ADFS Dans le snap-in «Active Directory Federation Services» du serveur de fédération resource, créer une nouvelle application «claims-aware». Ajouter à cette application des «organizations claims» déjà existants ou nouveau (voir le chapitre consacré au lab du scénario B2B sous ADFS). L Application URL doit correspondre à la balise <entryurl> du fichier «centrifydc_fs.xml» de l application claims-aware : 25

78 Tester l application L Url du site est le suivant : Après SSO, l application aboutit avec succès : Développez l application claims-aware La bibliothèque «centrifydc_fs_taglib.jar» de Centrify fournit les tags SAML qui permettent de récupérer les informations concernant les assertions SAML et les claims. Il n est pas possible (en tout cas pas fait pour) d appliquer AzMan avec une application Java. Par contre, il est possible d imiter l application.net basée sur les rôles ASPNET. Rôles Tomcat Pour mapper des utilisateurs ou des groupes (group claims) à un rôle Tomcat, modifiez dans le fichier centrifydc_fs.xml de l application la balise <RoleMapping> : <RoleMapping separator=";"> <Role name="role1" group= Adatum ClaimApp Claim user="[email protected]"/> <Role name="admin" group="adatum ClaimApp Admin"/> <Role name="manager" user="[email protected]"/> </RoleMapping> IfUserInRole tag Ce tag permet de tester si un utilisateur appartient à un rôle (=group) ou non. On peut ainsi afficher en fonction du group claim de l utilisateur les éléments de la page qui lui sont visibles ou non. <saml:ifuserinrole role="adatum ClaimApp Admin" var="isadmin" /> <c:when test="${isadmin}"> <a href= Claims-Aware Application ASPNET Role-based Manager</a> </c:when> Source Plus d informations sur le guide [projectdirectory]/centrify/web_java.pdf 26

79 Problème de certificats Lors du lancement de Tomcat, l erreur suivante est générée : GRAVE: RMI error encountered while getting federation service trust info java.rmi.remoteexception: Erreur de transport HTTP : javax.net.ssl.sslhandshakeexception: sun.security.validator.validatorexception: PKIX path building failed: sun.security.provider.certpath.suncertpathbuilderexception: unable to find valid certification path to requested target; nested exception is: Erreur de transport HTTP : javax.net.ssl.sslhandshakeexception: sun.security.validator.validatorexception: PKIX path building failed: sun.security.provider.certpath.suncertpathbuilderexception: unable to find valid certification path to requested target Cette erreur entraine l erreur suivante lors du lancement de l application web : le serveur de fédération ne peut pas être contacté. Cette erreur est due au fait que le certificat du serveur hébergeant le serveur de fédération ressource qui a été importé n est pas reconnu comme Certification d Autorité valide par Sun. Or ce certificat n a pas de CA, puisqu il est auto-signé. Il y a trois outils et trois fichiers importants pour résoudre ce problème. Les outils : - selfssl : outil de Microsoft qui permet de générer des certificats auto-signés. Le certificat du serveur resource a été généré par cet outil. - keytool : outil de Sun qui permet notamment de générer et d importer des certificats (génération de certificats auto-signés) dans des keystores au format JKS ou PKCS12 utilisés par java et Tomcat - install.pl : ce petit programme en Perl de Centrify utilise l outil keytool pour l importation de certificat Les fichiers ou keystores: - C:\Sun\AppServer\jdk\jre\lib\security\cacerts : contient les CA reconnus par Sun. - C:\Documents and Settings\Administrator.ADFSRESOURCE\.keystore: keystore par défaut de l outil keytool ; lorsqu aucun keystore n est précisé dans la ligne de commande. - C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf\keystore.jks: keystore par défaut de Tomcat. Après avoir configuré Tomcat avec SSL, celui-ci va lire les certificats dans ce keystore. Résolution du problème 1. Si ce n est pas déjà fait, exporter le certificat du serveur Host du serveur de fédération resource dans un fichier.cer 2. Ne pas utiliser l outil Centrify, qui ne fonctionne pas. 3. Généré un certificat auto-signé avec keytool dans le keystore par défaut de Tomcat : %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA -keystore C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf\keystore.jks 27

80 4. Importer le certificat du serveur resource dans le fichier cacerts des CA trusted par Sun. Source Centrify et ADFS Centrify et Tomcat [projectdirectory]/centrify/web_java.pdf Tomcat et SSL Perl Liberty Alliance Liberty Alliance, aussi connu sous le nom de Project Liberty, est un projet qui réunit des acteurs des mondes industriel, informatique, bancaire et gouvernemental sous la forme d'un consortium. L'objectif est de définir des ensembles de spécifications de protocoles de fédération d'identité et de communication entre services web. Dans le contexte de Liberty Alliance, l'authentification unique correspond à la possibilité pour l'utilisateur d'accéder, après s'être identifié à l'aide d'un compte unique, à des services proposés par différents fournisseurs appartenant à un même "cercle de confiance" ("Circle of Trust"). Ces spécifications techniques et fonctionnelles décrivent donc les mécanismes qui devraient d'une part simplifier l'usage d'internet (mise en œuvre du principe de signature unique) et d'autre part permettre à un individu de maîtriser la diffusion de ses données personnelles (nom, prénom, adresse électronique, etc., qui définissent en réalité son identité numérique dès lors qu'il fait usage d'internet) en décidant lesquelles il désire partager. Une caractéristique spécifique de Liberty Alliance est la notion de fédération. Au lieu que ce soit un fournisseur de service qui décide si un utilisateur a le droit d'accéder à son service sans se ré-identifier, c'est l'utilisateur qui décide s'il veut accéder à ce service sans se ré-identifier. Cette possibilité ne peut être laissée à l'utilisateur que s'il doit au préalable s'identifier auprès d'un fournisseur d'identité reconnu par le fournisseur du service demandé. 28

81 Concepts clés [projectdirectory]/liberty Alliance/LibertyTechnologyTutorial[1].pdf Dans le chapitre sur PingFederate, ces concepts sont repris plus précisément. Fédération SSO initiation [projectdirectory]/liberty Alliance/LibertyTechnologyTutorial[1].pdf Dans le chapitre sur PingFederate, les concepts d IdP-Initiated SSO et SP-initiated SSO sont repris en détails. 29

82 Implémentations libres - SourceID: SourceID is the #1 open source project for federated identity - Lasso: o Fournit une librairie c++ o Interopérable avec SourceID toolkit for Java ID-FF 1.2 o Langages de développement conseillé : c++, c (pas terrible pour le Web SSO) o Langages possibles : php, java, c# - FederID: le projet FederID est le résultat de l intégration des logiciels libres suivants : o Lasso : une implémentation libre des standards Liberty Alliance. o InterLDAP : un gestionnaire d'annuaire LDAP avancé. o LemonDAP : un mandataire inverse (reverse proxy) SSO. Plus de détails à l adresse: Le projet est en cours et n offre donc pas de solutions pour l instant. Membres actuels Liberty Alliance Interoperability PingFederate PingFederate n apparaît pas sur cette liste, bien qu il intègre le protocole standard SAML 2.0 qui appartient également aux protocoles Liberty Alliance (pas exclusivement). En fait, le serveur PingFederate semble ne pas être interopérable avec le protocole ID-WSF (1.1) pour les web services interopérable avec le protocole SAML 2.0. Et ceci est une des conditions pour être reconnu LA Interoperable. ( Tiré du document «PingFederate3_overview» : Pour l instant PingFederate n intègre pas les protocoles ID-WSF de Liberty Alliance pour les services web. 30

83 SymLabs SymLabs est une entreprise qui a créé un produit «SymLabs Federated Identity Access Manager» et qui a le même objectif que PingFederate, en ce sens qu il est technologiquement neutre. Mais, en plus des protocoles SAML 2.0 et WS-Federation (gérés par PingFederate), il propose des protocoles spécifique à Liberty Alliance tels que ID-FF 1.2 et ID-WSF 1.1. Il mérite donc d être cité. Il est donc encore plus «Liberty Alliance Interoperable» que PingFederate. Ce logiciel n est toutefois pas supporté par les plateformes Windows. Plateformes supportées : Linux (any major distribution on x86 architecture, other architectures on request) Solaris on UltraSparc architecture Solaris for Intel 8-10 HP-UX (any architecture on request) AIX on request Mac OS X on request BSD family operating systems, any architecture, on request Any modern UNIX operating system on any architecture on request Embedded or blade operating systems on request URL : Sun Le produit Sun Java System Federation Manager possède entre autre les fonctions de SSO. Il n est pas encore disponible sur Windows. Il n intègre pas le protocole WS-Federation à sa solution. URL : IBM Produit Tivoli Federated Identity Manager. Allow collaboration with a wide variety of partner organizations, through concurrent support for all leading Federated Single Sign-On protocols Align with open standards and specifications including Liberty, SAML, WS-Federation, WS-Security and WS-Trust. URL : 31

84 Oracle Le produit Oracle Identity management contient notamment la solution de SSO (web y.c.) Oracle Identity Federation qui supporte les protocoles SAML, Liberty et WS-Federation. Supported Platforms Microsoft Windows 2000 Microsoft Windows 2003 Red Hat Linux Supported Directory Servers and Databases Oracle Database Microsoft SQL Server Microsoft Active Directory Oracle Internet Directory Sun Java System Directory Server Supported Platforms and Components Supported Identity & Access Management Systems Oracle Access Manager Oracle Single Sign-On Oracle COREid Access & Identity CA SiteMinder Supported Protocols SAML 2.0 SAML 1.1 SAML 1.0 Liberty ID-FF 1.2 Liberty ID-FF 1.1 WS-Federation Passive Requestor Profile URL: on_10gr3.html Novell Le produit Novell Identity Manager traite du SSO, mais pas du Web SSO, donc sans rapport avec Liberty Alliance. URL : Le produit Novell agréé par Liberty Alliance et appelé Novell Access Manager ou Odyssey, ne semble pas encore disponible sur le commerce (rien trouvé sur le site). Il ne semble pas non plus inclure le protocole WS-Federation. URL : Liste complète Sources Définition Site officiel 32

85 PingFederate Overview Nature du produit L entreprise Ping Identity, qui soutient également le projet sourceid, a mis au point un serveur de fédération PingFederate, qui intègre les protocoles SAML 1.1, 2.0 et WS- Federation. PingFederate ne peut pas être considérée comme une application issue du projet Liberty Alliance. En fait, elle est technologiquement neutre. Elle est tout aussi bien interopérable avec ADFS (WS-Federation) qu avec Liberty Alliance ou Shibboleth (SAML 2.0). Description du produit Le produit PingFederate est un serveur de fédération d identité qui permet le Web SSO pour des scénarios de B2B, B2C et en interne pour les employés. Il supporte également le protocole WS-Federation, ce qui lui permet de se connecter à l Active Directory et de dialoguer avec l Adfs. PingFederate permet aux utilisateurs internes de se connecter SSO entre les domaines de sécurité, mais aussi auprès des applications partenaires. Les utilisateurs partenaires peuvent aussi se connecter SSO auprès des applications internes. 33

86 [projectdirectory]\pingidentity\pingfederate\pingfederate_datasheet.pdf Un seul serveur PingFederate permet de fédérer des applications provenant de multiples domaines de sécurité. Ce serveur fait office de fournisseur de service, alors que chaque domaine de sécurité joue le rôle de fournisseurs d identité. Chaque IdP peut gérer de manière différente son contexte de sécurité. [projectdirectory]\pingidentity\pingfederate\pingfederate_admin_manual.pdfs 34

87 Concepts clés Les derniers standards SAML 2.0 et WS-Federation définissent deux rôles dans un partenariat de fédération d identité : un fournisseur d identité (Identity Provider or IdP) et un fournisseur de service (Service Provider or SP). IdP : c est une entité système qui authentifie un utilisateur et transmet l information de référence de l identité de cet utilisateur basé sur cette authentification. SP : c est le consommateur de l information d identité fournit par les IdPs. Les applications SP déterminent la façon d utiliser l information contenue dans une assertion SAML. Assertions : ce sont des documents XML envoyés depuis un IdP vers un SP et qui contiennent les informations sur un utilisateur qui a initié un SSO. Authentification context : Le contexte d authentification est un supplément d information sur un utilisateur par rapport à une assertion requis par un SP pour permettre l accès à une ressource. Ces contextes d authentification peuvent être fournis par des kits d intégration. IdP-initiated SSO : dans ce scénario, un utilisateur est logué auprès de l IdP et tente d accéder à une ressource sur un serveur SP distant. L utilisateur n est pas logué sur le site SP. [projectdirectory]\pingidentity\pingfederate\pingfederate_admin_manual.pdfs 35

88 SP-initiated SSO : dans ce scénario, un utilisateur essaie d accéder à une ressource protégée directement sur le site SP sans y être logué. L utilisateur n a pas de compte sur le site SP, mais il a un compte fédéré auprès d un IdP tiers. [projectdirectory]\pingidentity\pingfederate\pingfederate_admin_manual.pdfs Account linking : cette méthode fournit un moyen pour un utilisateur de se loguer sur différents sites avec seulement une authentification dans les cas où l utilisateur possède des comptes ou des credentials sur chaque site. [projectdirectory]\pingidentity\pingfederate\pingfederate_admin_manual.pdfs 1. David Smith se logue avec son compte davidsmith sur le site A et décide de se loguer sur le site B via le site A. 3. PingFederate crée un pseudonyme sur le site A et le fait passer sur le site B 4. PingFederate sur le site B retrouve le compte existant sur le site grâce aux informations passées avec le pseudonyme. 36

89 Adapters et Agent toolkit Un des avantages de PingFederate, qui lui permet d intégrer les différentes plateformes Web et selon les protocoles, est qu il constitué d un noyau central sur lequel viennent se greffer des Adapters qui ont comme but de se connecter avec ces plateformes. Des agents sont placés du côté des plateformes Web pour dialoguer avec ces Adapters. Les Adapters pour les protocoles SAML et WS-Federation sont délivrés par défaut avec le serveur PingFederate. Les Agent Toolkits pour les applications Java et.net peuvent être téléchargés sur le site de SourceID. Ils sont déjà présents avec les exemples d application. Voici un schéma qui illustre cela dans un scénario de SSO IdP-initiated. [projectdirectory]\pingidentity\pingfederate\pingfederate_admin_manual.pdfs 1. Login SSO 2. Application IdP insère les attributs de l utilisateur dans un PFTOKEN (Token PingFederate) via l agent toolkit (pour.net) dans notre scénario. 3. PFTOKEN est redirigé vers l IdP serveur de PingFederate 4. A partir du PFTOKEN, génération d une assertion SAML 5. Envoi de l assertion SAML au serveur SP 6. A partir du SAML, génération du PFTOKEN 7. PFTOKEN redirigé vers l application 8. L agent toolkit lit le TOKEN et rend les attributs valables pour l application Interopérabilités 37

90 Installation du serveur Etapes (tirées des docs «PingFederate_Admin_Manual.pdf» et «Quick_start_guide.pdf») 1. Téléchargement du server PingFederate Téléchargement et installation du Framework jdk Demande pour obtenir pour une licence pour le serveur, puis installation de la licence dans le répertoire <pingfederate_directory>/server/default/conf. Attention ce n est pas un fichier txt. Ne pas le sauvegarder comme un fichier txt. 4. Set java_home 5. Installation de PingFederate a. Dezipping b. Démarrage : Run.bat sous le répertoire <pingfederate_directory>/bin c. Console d administration : (hevsidf2.fedserver.idf)>:9030/pingfederate d. New Password Liberty06 (user Administrator, init pwd 2Federate) 6. Téléchargement et installation de Java Cryptography Extension (JCE) dans le répertoire /lib/security du répertoire JAVA_HOME Déploiement des scénarios (SAML 2.0) Le but est de tester les différents scénarios (IdP-initiated et SP-initiated) avec l exemple d application.net. En premier lieu, je monte un serveur unique Pingfederate qui officiera comme serveur IdP et serveur SP. Pour l installation de pingfederate, voir les guides «PingFederate_Admin_Manual.pdf» et «Quick_Start_Guide.pdf». 38

91 Paramètres locaux Attention, le port n est pas 8090, mais

92 Configuration de l IDAdapter 40

93 Configuration du SP Adapter 41

94 Connexion au SP 42

95 43

96 Connexion à l IdP 44

97 Test du scénario IdP-Initiated Lancez l application idp et connectez-vous en local avec joe : Le résultat donne cette page : Maintenant que Joe est authentifié auprès du serveur IdP, il peut initier un SSO en se connectant au serveur SP. Résultat : 45

98 Test du scénario SP-Initiated Lancer l application SP: deux solutions s offrent à vous. La première est de se connecter en local à l application, puis d initier le SSO (avec authentification auprès du server IdP) : L autre solution consiste à se connecter au server IdP qui effectue ensuite un SSO (type IdP initiated). 46

99 Le SSO effectué donne la page suivante : Cette page est la même que la page finale du SSO IdP-initiated, sauf que pingfederate a entre temps été configuré pour l initialisation SP SSO, ce qui a simplement rajouté la colonne de gauche «IdP Connection» à la page. Personnalisation de l application en fonction de l utilisateur Le but est de développer un peu l application, afin de donner des droits ou des restrictions d accès aux utilisateurs. Les exemples d applications stockent les utilisateurs dans des fichiers XML. On peut les stocker dans une base de données pour plus de sécurité. Pour l exemple, on va laisser les informations utilisateurs dans un fichier xml. Ces utilisateurs ne sont pas liés à un data store (base de donnée) qui contiendrait des informations supplémentaires sur les utilisateurs et qui pourraient être utilisées pour personnaliser l application. Ajout d un attribut Le fichier XML «\IdpSample\config\pingfederate-idp-demo-users.xml» contient les infos utilisateurs. Par défaut, il contient l identifiant utilisateur et le mot de passe. On peut rajouter des attributs dans ce fichier. Voyons ce qui ce passe si on rajoute un attribut «group» : a. si on lance l application IdP et que l on se connecte en locale, l attribut group viendra s ajouter aux autres attributs. Ensuite, lors de l initialisation SSO, la page est redirigée vers l application SP, mais l attribut group n est pas transmis. b. Si l on rajoute l attribut group dans le fichier de conf de l application SP, l attribut apparaîtra également après une connexion locale, mais pas après la connexion SSO. 47

100 Pour comprendre le fonctionnement, suivons étape par étape le mécanisme de SSO (SPinitiated): 1. Lancement de l application SP 2. Login local : l attribut group apparaît s il a été ajouté au fichier «\SpSample\config\pingfederate-idp-demo-users.xm» 3. Login SSO (redirection vers la page de login IdP + login) : tout d abord, si l attribut group a été ajouté au fichier «\IdpSample\config\pingfederate-idp-demo-users.xml», il sera chargé dans le PFToken lors de sa création par l application et envoyé au serveur IdP. Ensuite le serveur IdP va générer une assertion SAML à partir de ce PFToken et l envoyer au serveur SP qui va reconstituer le PFToken et le renvoyer à l application resource qui va pouvoir le lire. Si l on suit toute cette dernière étape sur la console du serveur PingFederate qui tourne, on peut remarquer que l attribut group n est pas inscrit dans l insertion SAML et qu il n est donc pas transmis plus loin. De cela, on peut déduire qu il faut, premièrement, configurer l IdPAdapter et la connexion SP afin de permettre la retranscription de l attribut du PFToken dans l assertion SAML (IdP serveur reçoit le PFToken de l application IdP, génère l assertion SAML et l envoie au serveur SP), puis deuxièmement, de configurer le SPAdapter et la connexion IdP afin de retranscrire l attribut de l assertion SAML dans le PFToken (SP serveur reçoit l assertion du serveur IdP, génère le PFToken et l envoie à l application SP). Configuration du SpAdapter pour l ajout d un attribut Dans les paramètres de configuration du SpAdapter, sous la rubrique Extended Adapter Contract, rajoutez l attribut group (le nom doit correspondre exactement à la balise afficher dans le fichier XML). 48

101 Dans les paramètres de configuration de la connexion IdP, sous la rubrique Attribute Contract, rajoutez l attribut group : Puis, sous la rubrique Adapter Mapping & User Lookup, dans la sous-rubrique Adapter Contract Fullfillment, mappez l attribut group à l attribut group provenant de l assertion SAML. Un attribut peut provenir d une Assertion (ce qui est le cas dans notre exemple, étant donné que les attributs ajoutés dans le fichier XML de l application IdP sont enregistrés dans le fichier PFToken, qui sert de base à la création de l assertion SAML dont on a configuré la génération dans l IdPAdapter en précisant qu il fallait retranscrire l attribut group), d un champ text (dont la valeur est écrite à la main dans le champ value), et finalement d un data store (une base de données ou un annuaire active directory). Configuration de l IdPAdapter pour l ajout d un attribut Même mécanisme que pour le SpAdapter. Modification de l application J ai rajouté une rubrique à l application SP qui contient les liens vers lesquels l utilisateur peut accéder (avec les droits d accès correspondants) selon son groupe. 49

102 Problème : l application est en.net 1.1 et le code behind est compilé dans une dll. Je ne peux donc pas modifier le code source directement et je ne peux pas le compiler non plus avec Visual studio (.Net 2.0 et pingfederate non accessible pour les assemblies). Il n y a de toute manière aucun code spécial à rajouter. Il suffit de récupérer le groupe, puis d afficher ou non les liens en fonction du groupe et de transférer le nom d utilisateur et le groupe à l application dont l accès aux fonctionnalités va dépendre de ces paramètres. Intégration avec l ADFS (SP connexion) Dans cette rubrique, on va voir comment réaliser l interopérabilité entre l ADFS et la solution Liberty Alliance de SourceID. L objectif est de permettre à un utilisateur enregistré auprès d un serveur IdP PingFederate d accéder à une application ressource par le truchement du serveur de fédération resource ADFS (L inverse est aussi possible, c est-à-dire qu un utilisateur de l ADFS puisse accéder à une application d un SP configuré sous PingFederate). Si on suit la logique ADFS, il faut créer un partenaire account qui se connecte à un IdPAdapter de PingFederate. L IdPAdapter doit stocker les informations utilisateurs dans un data store (LDAP data store est le mieux indiqué pour cette opération). Ceci correspond à une connexion IdP. Du côté PingFederate, il faut créer une connexion SP avec le serveur ADFS. En première instance, je vais configurer une connexion de type WS-Federation avec un IdPAdapter de type LDAP. Ensuite, je vais tenter de créer une connexion avec un IdPAdaper de type SAML (Remarque : les tokens ou assertions dans l ADFS sont en format SAML 1.1). LDAP IdPAdapter Configuration 50

103 LDAP Data Store Configuration L utilisateur administrator possède les droits d accéder aux utilisateurs de l Active Directory. ADFS account partner Au niveau du serveur de fédération resource : L url endpoint doit correspondre à l IdPAdapter de type LDAP. Incoming claim de type UPN. 51

104 ADFS SP Connexion L Adapter ci-dessus est de type standard, alors que l adapter ci-dessous est de type LDAP. 52

105 Test de l application 1. Lancez l application 2. Choisir le royaume PingFederate 53

106 3. Choisir l IdP Provider auprès duquel l utilisateur doit s identifier 4. a. Adapter Standard : Se connecter Le login ID doit contenir un nom de domaine (adatum.com, treyresearch.net dans ce cas). 54

107 5. b. LDAP Adapter. Se connecter 6. Accès à l application 55

108 Erreur L erreur suivante apparaît : Cette erreur apparaît lorsque le filtre de recherche donne un résultat toujours vrai. On peut ainsi se loguer avec n importe quel nom. Le token ne sera pas créé pour autant, car le login ne correspond à rien. Il faut donc trouver un critère de filtrage qui fonctionne (LDAP query). Mais aussi, il faut que le login utilisateur comprenne un nom de domaine, car du côté ADFS, seuls les utilisateurs avec le suffixe de nom de domaine adatum.com et treyresearch.net (que j ai défini moi) sont acceptés. Intégration avec l ADFS (IdP connexion) Dans ce cas de figure, c est un utilisateur de l ADFS qui doit pouvoir accéder à une application ressource d un SP géré par PingFederate. On va développer le cas de figure où un utilisateur du domaine adatum.com (adfs account federation server) désire accéder à l application samplesp. Ceci nécessite de créer une connexion IdP côté PingFederate entre le SPAdapter déjà existant et le serveur de federation account de l ADFS. Et du côté du serveur account de l ADFS, il faut créer un partenaire resource. ADFS resource partner Au niveau du serveur de fédération account : Outgoing claim type : UPN (tous les suffixes sont remplacés par le suffixe adatum.com) 56

109 ADFS IdP Connexion La connexion est mappée au SP standard. Le groupe ne peut pas être récupéré depuis l assertion, car le mécanisme de «outgoing claim mapp» de l ADFS n est pas compatible avec PingFederate. J ai mis du texte à la place. Pour déterminer un groupe à un utilisateur, il faudrait créer un data store qui stocke les informations sur les utilisateurs provenant de l ADFS et qui indique le groupe auquel appartiendraient ces utilisateurs. 57

110 Test de l application 1. Lancez l application SP 2. Connectez-vous en local avec un utilisateur de votre choix 3. Initialisez le SSO (SP-initiated mode) 58

111 4. Identifiez-vous auprès du fournisseur d identité (account serveur de l ADFS) 5. SSO successful Erreur L erreur suivante apparaît : 59

112 Pour permettre le SSO, il est nécessaire que le login local de l application SP soit lié au login du fournisseur d identité. Exemple : Utilisateur Adam Carter : - AD IdP login : adamcar (Liberty06) - Application SP login : adam (test) L application doit savoir que l identité loguée en tant que adamcar correspond au login local adam. Si ce n est pas le cas, le message d erreur ci-dessus apparaît. Si l on tente un IdP-initiated SSO au premier login et que les deux logins de l utilisateur diffèrent, alors l application ne peut pas associer les deux logins à un utilisateur. Pour remédier à ce problème, il faut effectuer un SP-initiated SSO, c est-à-dire se loguer d abord en local auprès de l application, puis effectuer l identification auprès de l IdP, ainsi l application pourra désormais lier les deux logins. L erreur suivante apparaît : Le serveur PingFederate ne peut pas accéder à un fichier qui se trouve dans le répertoire data. Il semblerait que se soie soit un bug de l application, soit un bug du serveur. Pour y remédier, remplacez dans l URL la page affichée par la page default.aspx. Sources Site officiel Overview [projectdirectory]/pingfederate_datasheet.pdf Interopérabilité Administrator guide [projectdirectory]/pingfederate_admin_manual.pdf Déploiement des exemples [projectdirectory]/ Quick_Start_Guide.pdf 60

113 SourceID SourceID fournit gratuitement des frameworks permettant la gestion d identité fédérée utilisant les spécificités Liberty Alliance. J ai choisi comme premier essai de télécharger le framework utilisant le protocole Liberty ID-FF 1.1 pour les applications.net. Installation du framework et des exemples Se référer au document «[projectdirectory]/sourceid/ ID-FF 1.1.Net Toolkit 1.1\ID-FF 1.1 Toolkit\Documentation\index.html» Test de l application 1. Lancer l application 2. Se connecter en local (SP-Initiated SSO) 3. Initier le SSO en s authentifiant auprès de l IdP 61

114 4. S authentifier auprès de l IdP 5. SSO Successful 62

115 Interopérabilité Cet exemple qui utilise le Framework Liberty ID-FF 1.1 ne fonctionne qu avec des applications intégrant également ce protocole. Autrement dit, il est impossible de se connecter directement à un serveur ADFS (évident), mais aussi à un serveur PingFederate. Celui-ci n inclut pas le protocole ID-FF 1.1, qui bien qu il soit un ancêtre du protocole SAML 2.0 (intégré par PingFederate) n en est pas moins incompatible avec ce dernier. Dans les toolkits sourceid, seuls ceux avec le Framework SAML 1.1 sont interopérables avec PingFederate, mais ce n est pas un protocole Liberty. Quant à un éventuel toolkit pour le Framework SAML 2.0, il serait probablement similaire à l exemple inclut avec PingFederate. Erreurs Org.Mentalis.Security Si l application signale que la bibliothèque Org.Mentalis.Security ne peut pas être trouvée, alors copiez là depuis le répertoire de téléchargement du framework «ID-FF 1.1.Net Toolkit 1.1\ID-FF 1.1 Toolkit\lib» dans le répertoire bin du site SP ou IDP. System.Security.dll Si vous avez une erreur du type : System.ArgumentNullException: Value cannot be null. Parameter name: elem at System.Security.Cryptography.Xml.SignedXml.GetPropagatedAttributes(XmlElement elem) at System.Security.Cryptography.Xml.Reference.CalculateHashValue(XmlDocument document, CanonicalXmlNodeList reflist) at System.Security.Cryptography.Xml.SignedXml.BuildDigestedReferences() at System.Security.Cryptography.Xml.SignedXml.ComputeSignature() La dll System.Security.dll pour ASPNET 1.1 contient un bug. Indiquez dans IIS que le site doit tourner avec ASP 2.0 et tout fonctionnera. Autres projets d identité fédérée Shibboleth Shibboleth est un middleware open-source (Java) basé sur les spécifications OASIS SAML (comme Liberty Alliance) et qui fournit le WEB SSO. Peut-être installé sur les plateformes Windows ou autres. Il possède une extension lui permettant de s intégrer avec un service ADFS. Il existe des implémentations de Shibboleth (essentiellement réalisées par des universités très utilisé dans les milieux universitaires, alors que Liberty Alliance est plutôt utilisé en production). C est donc une alternative au projet Liberty Alliance (mêmes principes Identity Provider et Service Provider). Source WebSite : Fédération d identités avec Shibboleth [projectdirectory]/others/shibboleth - JRES2005.ppt 63

116 Liberty Alliance, Shibboleth et Lemonldap La différence entre ces trois projets est caractérisée par son approche. Lemonldap (Logiciel libre) dispose d une base de données globale et centralisée de tous les utilisateurs. Cette approche est principalement destinée à des services dépendant tous d'une même entité, par exemple à l'intérieur d'une société. Dans l approche de Liberty Alliance, chaque service gère une partie des données d'un utilisateur (l'utilisateur peut donc disposer de plusieurs comptes), mais partage les informations dont il dispose sur l'utilisateur avec les services partenaires. Cette approche a été développée pour répondre à un besoin de gestion décentralisée des utilisateurs, où chaque service partenaire désire conserver la maîtrise de sa propre politique de sécurité, comme par exemple un ensemble de sites marchands indépendants d'un point de vue commercial et organisationnel. Dans l approche de Shibboleth, chaque utilisateur dépend d'une des entités partenaires. Ainsi, lorsqu'il cherche à accéder à un service du réseau, l'utilisateur est authentifié par le partenaire dont il dépend. Comme dans l'approche fédérative, cependant, chaque service du réseau gère indépendamment sa propre politique de sécurité. Cette approche répond notamment aux besoins de structures institutionnelles dans lesquelles les utilisateurs sont dépendants d'une entité, comme par exemple les universités, les laboratoires de recherche, les administrations, etc. Source Microsoft Passport Tout comme le projet Liberty Alliance, Passport est un système standardisé permettant de partager les informations d identification utilisateurs. Il fédère les identités sur le réseau Passport (MSN, Hotmail, ) de Microsoft. Il ne présente aucun intérêt dans le cadre de ce projet, car il n est pas possible d implémenter son propre réseau Passport. Ce réseau est administré par Microsoft et n est accessible par un tiers qu en tant qu utilisateur. Standards identités fédérées Tableau des principaux projets d identités fédérées [projectdirectory]/ Shibboleth/Shibboleth - JRES2005.ppt PingFederate ne figure pas sur ce tableau car il est neutre. Il est interopérable avec tous les projets ci-dessus (A vérifier pour Oblix). 64

117 Evolution des standards [projectdirectory]\adfs\itpro_microsofts_identity_and_access_management_strategy_s teven_adler.ppt Tableau de comparaison.net Passport, Ping ID et Shibboleth.NET/Passport.NET Passport is a service; Liberty is not a service rather Liberty defines a set of specifications. Passport will use Kerberos for its authentication token format; Liberty uses SAML Passport defines a single mechanism for authentication token exchange between sites (through Kerberos); Liberty defines multiple mechanisms by which the authentication token can be exchanged between sites Identity Provider exists in both communities and maps between different token formats Service Provider exists in both communities and chooses appropriate Authentication Authority on a per transaction basis Security Token Exchange 65

118 Ping ID Shibboleth Ping-ID focuses on the nature of the business agreements and policies between sites; Liberty provides a technical framework Shibboleth users not required to have account at Resource site Shibboleth sites exchange attribute information to enable authorization decisions; Liberty sites exchange opaque identifier for principal If both are Ping-ID members, Liberty Identity and Service Providers can base their business trust with respect to each other on that membership Liberty Authentication Context statement can be extended to include PingID PICA score Concept of end-user controlling their privacy preferences is fundamental to both Liberty and Shibboleth Liberty Circle of Trust (COT) and Shibboleth club are similar policy domains Liberty common-domain discovery mechanism and Shibboleth WAYF interchangeable Pour plus de détails, se référer au document : [projectdirectory]/liberty Alliance/Liberty And 3rd Party Identity Systems White Paper.pdf FAQ Existe-il un méta-annuaire unique pour une fédération? Non, une fédération ADFS se base sur les Active Directory des «claims» entrant (provenant de domaines partenaires). L approche fédérative, tel que représentée par Liberty Alliance, répond à un besoin de gestion décentralisée des utilisateurs. [projectdirectory]/liberty Alliance/LibertyTechnologyTutorial.pdf 66

119 L interopérabilité entre les protocoles Liberty Alliance et ADFS est-elle possible? Non, pour se connecter à l ADFS, il faut nécessairement utiliser le protocole WS-Federation de Microsoft. Il n y a aucun moyen de se connecter à l ADFS avec un protocole SAML ou Liberty Alliance. Par contre, l utilisation de serveurs de fédération multi protocoles tels que le serveur PingFederate de Ping Identity ou SLIM de Symlabs règle le problème en intégrant à sa solution les principaux protocoles (SAML, WS-Federation, Liberty ID-FF, Liberty-IDWSF). Il permet ainsi de mettre en relation des utilisateurs et des ressources appartenant à des réseaux ADFS et Liberty Alliance (et d autres ) Les assertions échangées entre les serveurs sont par contre toutes en format SAML. En résumé, il est possible grâce à une application multi protocoles de résoudre le problème d interopérabilité. Toutefois, il n est pas possible de se connecter à l ADFS avec un protocole basé SAML, de même que l ADFS ne permet en aucun cas de se connecter à un partenaire par un autre protocole que le sien (WS-Federation). ADFS ou Liberty Alliance? ADFS est un produit fini alors que Liberty Alliance est un projet. Parmi les implémentations de Liberty Alliance on retrouve des vendeurs comme Sun, Novell, IBM et Oracle. Le choix d un produit plutôt qu un autre va dépendre de la structure informatique de l entreprise et des objectifs qu elle cherche à atteindre. Cependant, rien n empêche non plus de combiner les différents produits, ce qui est d ailleurs un objectif de Liberty Alliance et ce qui en fait son principal intérêt. En effet, pour fédérer des entités provenant de systèmes différents, il faut que ces systèmes aient un protocole commun. Actuellement, la plupart des produits proposés par les principaux vendeurs intègrent les protocoles Microsoft et Liberty Alliance, permettant ainsi de connecter les deux réseaux. Sources Liberty Alliance, le nouveau Big Brother? Liberty Alliance, les premiers projets voient le jour Liberty Alliance, Wikipedia SAML et WS-Security Pingfederate, sourceid et ADFS Standards protocols 67