Diplôme 2005 / 2006
Etudiant : Cédric Tabin Professeurs : Yann Bocchi
Karim Mazouni
Filière informatique de gestion
www.hevs.ch
Table des matières
1 Introduction...4
1.1 Contexte...4
1.2 Objectifs...4
1.3 Plan du rapport...4
2 Contexte technique...5
2.1 Gestion des identités...5
2.1.1 Notion d’identité...5
2.1.2 Single Sign On...8
2.1.3 Fédération d’identités...10
2.1.4 Liberty...13
2.2 Service Oriented Architecture...15
2.2.1 Web Services...15
2.2.2 Orchestration BPEL...16
3 Spécifications des scénarii...17
3.1 Contexte des scénarii...17
3.2 Scénario 1...18
3.2.1 Objectifs...18
3.2.2 Description...18
3.2.3 Limitations...19
3.3 Scénario 2...20
3.3.1 Objectifs...20
3.3.2 Description...20
3.3.3 Limitations...21
3.4 Scénario 3...22
3.4.1 Objectifs...22
3.4.2 Description...22
3.4.3 Limitations...23
4 Mise en œuvre...24
4.1 Scénario 1...24
4.1.1 Fonctionnalités...24
4.1.2 Outils...28
4.1.3 Architecture...29
4.1.4 Implémentation...30
4.1.5 Déploiement...44
4.2 Scénario 2...45
4.2.1 Introduction...45
4.2.2 Fonctionnalités...48
4.2.3 Outils...59
4.2.4 Architecture...60
4.2.5 Implémentation...61
4.2.6 Configuration...63
4.2.7 Déploiement...76
4.3 Scénario 3...77
4.3.1 Introduction...77
4.3.2 Fonctionnalités...79
4.3.3 Outils...83
4.3.4 Architecture...84
4.3.5 Implémentation...86
4.3.6 Configuration Access Manager...101
4.3.7 Déploiement...102
5 Conclusion...103
5.1 Liberty...103
5.2 Travail de diplôme...103
5.2.1 Etat final...103
5.2.2 Etapes...103
5.2.3 Gestion de projet...105
5.3 Conclusion...108
6 Ressources...109
7 Glossaire...110
1 Introduction
1.1 Contexte
Le travail de diplôme (TD) s’est déroulé au sein de l’entreprise Sun Microsystems à Gland (VD). Il a été supervisé par le Dr. Karim Mazouni qui s’est principalement occupé du suivi technique et par le Pr. Yann Bocchi qui a assuré le suivi administratif à la Haute Ecole Valaisanne de Sierre.
1.2 Objectifs
L’objectif principal du TD était de réaliser une application de démonstration mettant en oeuvre les deux thèmes d'actualité que sont la gestion des identités (Identity Management ou IdM) et l'architecture orientée-services (Service-Oriented Architecture ou SOA). Dans le contexte du TD, le volet IdM a concerné principalement la fédération d’identités avec les protocoles définis par la Liberty Alliance1 alors que le volet SOA a porté sur les Web Services et leur orchestration. Ces thèmes ont été illustrés sur une application réalisant une agence virtuelle de voyage simple.
1.3 Plan du rapport
Le chapitre 2 présente les concepts IdM et SOA utilisé dans le TD. Le chapitre 3 présente les scenarii mis en oeuvre dans l'application de démonstration. Le chapitre 4 décrit les détails de mise en oeuvre de chaque scénario. Le chapitre 5 fait le bilan sur le TD.
2 Contexte technique
2.1 Gestion des identités
La gestion des identités fait partie intégrante de la vie quotidienne : quel âge vous avez, où vous habitez, quelle voiture vous possédez, etc. Cela comprend non seulement les attributs de la personne ou de l'objet (la notion d’identité peut être endossée par une personne morale par exemple), mais aussi son authentification (est-elle vraiment celle qu'elle prétend être ?) et ses autorisations (a-t-elle le droit de faire telle ou telle chose ?).
Voici un exemple simple illustrant la notion d'authentification dans la vie quotidienne : lorsque vous vous faites arrêter par un policier, celui-ci vous demande votre carte d’identité. Cette carte délivrée par la Confédération va lui servir à s’assurer que vous êtes bien monsieur X ou Y.
Il saura que les informations de votre carte d’identité sont valides car elles sont issues d’un organisme digne de confiance (en l’occurence la Confédération) et que cette carte est sensée être infalsifiable. Il pourra par ailleurs vous associer à votre carte d’identité grâce à votre photographie !
2.1.1 Notion d’identité
Qu’est-ce qu’une identité
Prenons un exemple avec JackBauer, célèbre héros de la série ’24 heures chrono’ :
Figure 1
Dans le cas présenté sur la Figure précédente, nous avons notre entité représentée par Jack Bauer qui possède différents attributs : il a une fille, il aime l’action, il a les yeux bleus, etc.
Maintenant, comment s’assurer que l’entité que nous avons devant nous est bien Jack Bauer et non pas quelqu’un (ou quelque chose) se faisant passer pour lui ? Et bien tout simplement en nous basant sur son permis de conduire ou sa carte d’identité. C’est ce que l’on appelle une authentification.
À présent que nous sommes certains que l’entité est bien celle qu’elle prétend être, nous pouvons l’autoriser à accéder à certains services spécifiques. Typiquement dans notre exemple, Jack Bauer étant membre de la Cellule Anti-Terroriste (Counter Terrorist Unit ou CTU) de Los Angeles aura non seulement accès aux locaux mais aussi à certains dossiers secrets (autorisation que n’auront pas certains de ses collègues).
Tous ces éléments mis ensembles forment ce que l’on appelle une identité au sens global.
Dans ce rapport, nous nous occuperons principalement des identités virtuelles !
Identité réelle et identité virtuelle
Une identité virtuelle représente simplement une identité au format électronique. Cela peut représenter un compte que vous avez au sein d’un forum ou d’un site de vente tel que Amazon.
L’idée est qu’une identité virtuelle puisse être associée à une identité réelle.
Malheureusement ceci n’est pas possible dans la globalité car il n’y a aucun moyen de s’assurer que les données fournies par l’utilisateur soient authentiques. Cela signifie que les données d’une identité virtuelle pourraient ne correspondre à aucune identité réelle : c’est à nouveau de l’authentification.
Problèmes liés aux identités virtuelles
Comme évoqué précédemment, différents problèmes surgissent lorsque l’on parle d’identités virtuelles. Tout d’abord nous tombons sur celui du stockage des données.
Dans le cas d’une identité réelle, c’est l’entité en question qui connaît ses attributs.
Certains de ceux-ci sont aussi connus par un organisme fédéral (Contrôle des Habitants par exemple).
Pour une identité virtuelle, les attributs doivent être stockés, généralement dans une base de données. La question est de savoir quelles sont les données qui seront enregistrées et pour combien de temps ?
Autre risque lié directement au précédent : comment être sûr que nos données ne se retrouvent pas publiées sur Internet à la vue de tous ? Comment savoir qui a accès à la base de données où sont stockés mes attributs ? En d’autre mots, nous touchons la à la
Qu’en est-il de l’authentification ? La question est de s’assurer qu’un utilisateur se connecte avec sa propre identité virtuelle et pas une autre. Ce cas arrive lorsque quelqu’un donne son mot de passe à une autre personne et que celle-ci usurpe l’identité dudit compte.
Ce dernier risque est l’un des plus important car l’entité endossant une identité virtuelle pourra alors agir au nom d’une autre. De plus ce risque est multiplié du fait qu’une entité peut avoir de multiples identités virtuelles !
Actuellement, les fournisseurs de services (Service Provider ou SP) gèrent eux-même leur propres identités. Cela implique non seulement aux entités de saisir plusieurs fois les mêmes données, mais aussi de s’authentifier auprès de chacun des fournisseurs...
Une ébauche de solution
Afin d’éviter cette multiplication des données et des authentifications, l’idée est de créer un (et même plusieurs !) organisme dédié à la gestion des identités (Identity Provider ou IdP) et auquel les différents Service Provider pourront faire confiance.
Il existe déjà certains organismes digne de confiance tels que la Poste, les banques, etc qui pourront automatiquement faire office d’Identity Provider.
Le but est donc de créer un cercle de confiance (Circle of Trust ou CoT) entre l’Identity Provider et les Service Providers :
Figure 2
C’est précisément sur ce problème d’authentification unique (Single Sign On ou SSO) que la norme Liberty apporte une solution ! Les buts principaux de Liberty sont les suivants :
- Single Sign On : l’utilisateur ne rentre qu’une seule fois son identifiant et son mot de passe. Les Service Providers savent ensuite de qui il s’agit.
- Sécurité : le choix du mécanisme d’authentification (par ex. mot de passe, certificat numérique, …) est laissé à l’Identity Provider et les communications sont sécurisées à l’aide d’assertions SAML2.
- Stockage décentralisé des données des utilisateurs : les données des utilisateurs ne se trouvent pas toutes au même endroit. Un IdP peut déléguer la sauvegarde d’attributs à d’autres systèmes (Attribute Provider ou AP). Il n’y a donc beaucoup moins de risques que toutes les données d'un utilisateur se retrouvent en de mauvaises mains.
- Cercle de confiance : les sites font partie d’un cercle de confiance ce qui permet à un utilisateur de connaître quels sont les autres sites à qui il peut faire confiance.
- Choix de l’utilisateur : chaque utilisateur peut décider à tout moment de fédérer ou dé-fédérer une identité avec un fournisseur de services (cf chapitre 2.1.3).
Microsoft avait défini la première version de Passeport.NET avec une approche centralisée. Le gros frein que les utilisateurs ont vu à cette solution était que toutes leurs données étaient stockées chez le même fournisseur (Microsoft en l’occurrence).
La norme Liberty prévoit justement une approche fédérée avec laquelle les attributs concernant les utilisateurs sont stockées de manière décentralisée sur tous les sites participants à la fédération. Ainsi chacun d’eux aura une partie de l'information et cela minimise les risques liés aux vols d’identité par rapport à une approche centralisée ou toutes les données sont stockées sur un seul site.
2.1.2 Single Sign On
Qu’est-ce que c’est ?
Le Single Sign On (SSO) est une forme d’authentification permettant à un utilisateur de s’authentifier une seule fois pour atteindre de multiples ressources. Il existe plusieurs approches pour réaliser du Single Sign On :
- Liberty - Kerberos
Comment est-ce que ça fonctionne ?
Lorsque l’utilisateur s’authentifie au sein d’un système permettant le Single Sign On, le serveur lui transmet un Single Sign On Token (SSO Token). Cela peut se présenter sous forme d’une chaîne de caractères encodée comprenant diverses informations telles que le temps de session, le Principal, …
La notion de Principal (ou Subject) est souvent utilisée lorsque l’on parle de sécurité.
Dans notre cas, Jack Bauer est l’entité (ou l’Object) et ses différentes identités virtuelles seront assimilées à la notion de Principal.
Lorsque l’utilisateur ira sur une autre application au sein de ce système, ce dernier va vérifier l’existence et la validité dudit Token et va pouvoir ainsi automatiquement authentifier l’utilisateur.
Figure 3
1) L’utilisateur arrive sur l’application AAA
2) Il n’est pas connecté, l’application lui demande de s’authentifier 3) L’utilisateur fournit son identifiant et mot de passe
4) L’application authentifie l’utilisateur et lui crée un SSO Token 5) Il peut à présent accéder à l’application AAA
6) Il accède à l’application BBB
7) L’application détecte le SSO Token et authentifie automatiquement l’utilisateur
8) Il peut accéder à l’application BBB
2.1.3 Fédération d’identités
Qu’est-ce que c’est ?
Maintenant que nous avons défini ce qu’est une identité, intéressons-nous à la notion la plus importante spécifiée par la norme Liberty : la fédération d’identités !
Une fédération d’identités consiste à faire le lien entre deux identités virtuelles définies sur des sites différents mais appartenant à la même entité.
Pourquoi cherche-t-on à fédérer des identités ? Tout simplement car dans l’état actuel des choses, une personne peut avoir une multitude d’identités virtuelles avec différents identifiants, différents mots de passe et différentes sortes d’authentification.
L’idée est de mettre en place un site tiers en lequel chacun des sites a confiance. Si l’utilisateur est authentifié auprès de ce site tiers, alors lesdits sites pourront le considérer aussi comme étant authentifié.
Principes
Dans un premier temps, nous posons nos Service Provider comme suit :
Figure 4
Dans cette première étape, l’entité Jack Bauer s’est créé deux identités virtuelles, une sur chacun des Service Provider. Le seul à connaître la relation entre la première identité et la deuxième, c’est lui. Il est important de noter qu’à ce point, chacun des Service Provider gère lui-même ses propres identités !
jbauer@hotmail.com jackb@myspace.com
Nous allons à présent mettre en place un Identity Provider qui va s’occuper de gérer les données des différentes identités :
Figure 5
Dans cette deuxième phase, nous établissons un cercle de confiance entre l’Identity Provider et les Service Providers. Désormais, les deux Service Providers sont connus de l’Identity Provider. Chaque Service Provider fait confiance à l’Identity Provider mais ils restent méfiants envers l’autre Service Provider (méfiance mutuelle).
Nous remarquons aussi que Jack Bauer a désormais 3 identités virtuelles dont il doit se souvenir… Voyons maintenant ce qu’il se passe lorsque Jack a fédéré ses identités :
Figure 6
A présent, l’Identity Provider sait que l’identité herojb@idp est fédérée avec le Service Provider 1 et 2. Qu’est-ce que cela signifie ? Tout simplement, maintenant Jack Bauer va pouvoir s’authentifier sur l’Identity Provider et lorsqu’il arrivera sur le Service Provider 1, celui-ci va automatiquement savoir qu’il s’agit de l’identité jbauer@sp1 sans que Jack n’ait besoin de faire quoi que ce soit !
Ci-dessous, voici le cheminement que Jack Bauer suivra pour accéder au Service Provider 1 :
Figure 7
1) Jack arrive sur le site du Service Provider 1.
2) Il veut s’authentifier : il clique sur « Connexion ».
3) Il est redirigé automatiquement vers l’Identity Provider.
4) Jack entre l’identifiant herojb@idp et le mot de passe correspondant.
5) Il est automatiquement redirigé vers le site du Service Provider 1.
6) Le site fait automatiquement la lisaison avec l’utilisateur jbauer@sp1 et l’authentifie en tant que tel.
2.1.4 Liberty
Nous avons souvent parlé de la norme Liberty auparavant dans ce document. Les chapitres suivants expliquent plus en détail en quoi consiste cette norme.
Liberty Alliance
C’est une association formée en septembre 2001 par plusieurs entreprises (environ 150 à ce jour) dont Sun Microsystems, Oracle, IBM, Intel, … Elle vise à créer un réseau mondial basé sur des standards ouverts dans lequel les consommateurs, citoyens, entreprises et gouvernements puissent facilement effectuer des transactions en ligne tout en conservant la confidentialité et la sécurité de leur données.
Les membres de l’alliance travaillent ensemble pour :
- créer des spécifications ouvertes basées sur des standards concernant la fédération d’identités et Web Services y relatifs.
- diriger des solutions globales concernant le vol d’identité.
- fournir des tests d’interopérabilité.
- offrir un programme de certification formel pour les logiciels utilisant la norme Liberty. Lorsqu’un logiciel est cité comme ‘Liberty Enabled’ cela signifique que celui-ci est capable de communiquer en utilisant les spécifications Liberty.
- établir un guide des meilleures pratiques, règles, responsabilités et fil conducteur.
- collaborer avec d’autres organismes de normalisation, avocats et groupes politiques.
- répondre aux questions de confidentialité et de protection de la vie privée (privacy) des utilisateurs finaux.
Liberty Project
Le projet Liberty consiste en la création des spécifications Liberty et de leurs implémentations. Ci-dessous un schéma représentant les différentes interactions qui se passent lorsque l’on utilise la norme Liberty :
Figure 8
(source: http://www.projectliberty.org)
Les spécifications suivantes sont définies par Liberty :
- ID-FF (v. 1.2) : établit la possibilité de gérer et de fédérer une identité par le biais de fonctionnalités telles que la liaison de comptes et le SSO.
- ID-SIS (v. 1.0) : établit un service d’identité tel que le profil, liste de contact, géo-localisation, présence en ligne, …
- ID-WSF (v. 2.0) : fournit un framework pour créer des services interopérables liés aux identités (description & découverte), partage d’attributs et profil de sécurité. Ceux-ci sont généralement des services web.
2.2 Service-Oriented Architecture
L’architecture orientée service (Service-Oriented Architecture ou SOA) devient de plus en plus utilisée au sein des entreprises dans le but de réorganiser le système d'information autour de processus métier tout en conservant une partie du patrimoine applicatif.
Deux technologies relatives à SOA ont été étudiées dans le contexte du TD. Il s’agit des Web Services et de l’orchestration BPEL (Business Process Execution Language).
2.2.1 Web Services
Le World Wide Web Consortium (W3C) définit un Web Service comme étant un composant logiciel conçu pour être intéropérable avec d'autres Web Services indépendemment de la technologie (software & hardware) utilisée pour leurs mise en oeuvre. Généralement ces services utilisent le standard XML SOAP pour communiquer entre eux.
Dans le contexte de Web Services, il y a toujours un client (Service Requester ou Service Consumer) et un serveur (Service Provider) :
Figure 9
(source : http://wikipedia.org)
Un Web Service Provider offre une interface pour appeler ses méthodes dans un format standard : le Web Services Description Language (WSDL). Les Web Services Requester n’auront donc plus qu’a générer et interpréter un XML au format SOAP relatif à la WSDL fournie et pourront ainsi communiquer avec le Web Service Provider.
Toutefois, si cette approche a le grand avantage d’être totalement interopérable, il n’en demeure pas moins que les peformances sont amoindries notamment à cause de la taille des messages transmis.
2.2.2 Orchestration BPEL
BPEL (Business Process Execution Language) est un langage de programmation basé sur XML permettant de modéliser des processus métier de haut niveau. Un processus métier est un terme désignant une interaction entre deux entités voulant effectuer une transaction.
BPEL permet d’écrire des programmes qui utilisent des Web Services et/ou qui sont des Web Services. C’est ce que l’on appelle un orchestrateur car c’est lui qui fait office de coordinateur quant à l’appel des différents services.
Par exemple, quelqu’un demande un prêt via un site web. Le site va appeler un Web Service avec différents paramètres (âge et revenu salarial du demandeur, montant du prêt, etc). Le moteur BPEL qui va reçevoir l’appel du Web Service va créer une nouvelle instance du processus, qui va ensuite demander à un autre Web Service si cette personne peut bénéficier du prêt souhaité et renvoyer le résultat au site qui va l’afficher.
Business Process Modeling Notation (BPMN)
C’est un standard permettant de décrire visuellement un processus BPEL. Généralement un diagramme BPMN se présente sous la forme suivante (relatif à l’exemple ci-dessus) :
3 Spécifications des scénarii
3.1 Contexte des scénarii
Au terme du travail de diplôme, le but était d’avoir une agence virtuelle de voyage mise en oeuvre sous la forme d’une application composite3 utilisant des services web pour communiquer avec d’autres applications spécialisées dans les reservations (compagnie aérienne, location de voiture, hôtel, …).
Les scénarii sont progressifs : ils partent d'une situation où plusieurs sites web sur Internet fournissent divers services de réservation, ceux-ci n’ayant aucun lien entre eux.
Ils arrivent à une situation finale dans laquelle les sites sont liés par le biais d’une agence virtuelle de voyage avec une fédération d’identités.
Dans le premier scénario, les fondations sont posées, à savoir différents services de réservation sont créés. Dans un deuxième temps, ceux-ci sont liés pour établir une fédération. Puis enfin, l’agence de voyage virtuelle est posée au-dessus et communique avec les services de réservation via des services web.
Les fonctionnalités des différents services mis en œuvre sont volontairement basiques car l’accent est plus porté sur les concepts mis en œuvre !
3 Application composite: site web combinant le contenu de plusieurs sites web.
3.2 Scénario 1
3.2.1 Objectifs
Dans cette première étape, les services de réservation basiques vont être créés. Ceux-ci vont gérer de manière très simple des réservations et des utilisateurs.
D’autre part, l’idée était d’implémenter ce service de manière générique afin de pouvoir en simuler plusieurs pour les scénarii ultérieurs. Au final, trois de ces services ont été déployés :
- Compagnie aérienne.
- Hôtel.
- Compagnie de location de voiture.
3.2.2 Description
Nous avons créé ce que nous avons appelé un Travel Service Provider (TSP). Ci-dessous, les cas d’utilisation qui ont été développés :
Figure 11
L’acteur principal au sein d’un TSP est le Customer. Il représente le client qui va venir sur le site pour y effectuer diverses actions comme s’enregistrer, réserver un objet, etc.
Les fonctionnalités des TSP se séparent clairement en deux parties :
- Identity Management, qui concerne tout ce qui est la gestion des utilisateurs au sein du système.
- Reservation Management, qui gère tout ce qui a trait aux réservations d’objets quels qu’ils soient.
Identity Management
Cette partie décrit les différentes fonctionnalités relatives à l’IdM au sein des TSP.
a) Register User : enregistrement d’un nouvel utilisateur b) Log in / Log out : connexion & déconnexion d’un utilisateur c) Update user data : mise à jour d’un profil utilisateur
Reservation Management
Cette partie décrit les différentes fonctionnalités relatives à la gestion des réservations au sein des TSP.
a) Search possibilities : recherche de possibilités de réservation. Tous les utilisateurs, connectés ou non, peuvent entrer une date de début et une date de fin et voir quels sont les objets pouvant être réservés entre ces dates.
b) Book reservation : lorsque l’utilisateur a recherché les objets qui peuvent être réservés et que celui-ci est connecté, il peut choisir de réserver un de ces objets.
c) Validate reservation : dès la réservation effectuée, une confirmation est demandée au client. S’il valide sa réservation, alors l’ordre de paiement est transmis à la banque.
d) Pay reservation : paiement de la réservation auprès de la banque.
e) Browse (my) reservations : si l’utilisateur est connecté, il peut voir la liste des objets qu’il a réservé.
f) Cancel reservation : annulation d’une réservation.
3.2.3 Limitations
La notion de paiement (Pay reservation & Bank) n’a pas été implémentée en raison de manque de temps et que l’objectif ne s’y rapporte pas. Celui-ci aurait pu être simplement représenté comme un fournisseur de service traitant les transactions bancaires.
D’autres part, beaucoup de fonctionnalités logiques (tels que le prix) n’ont pas été mises en œuvre pour les mêmes raisons.
3.3 Scénario 2
3.3.1 Objectifs
Le but est de transformer les TSP précédemment créés afin qu’un utilisateur puisse choisir avec lequel il fédèrera ses identités.
3.3.2 Description
Chacun des TSP fournit donc toujours la possibilité aux internautes de s’enregister et de se connecter localement. Il fournissent maintenant la possibilité de se connecter par le biais d’un IdP au choix de l’utilisateur. Cela implique que les différents TSP se connaissent entre eux !
Figure 12
Provider. L’idée est donc que chaque TSP puisse agir en tant qu’Identity Provider envers les autres TSP selon le choix de l’utilisateur.
3.3.3 Limitations
Les TSP ne s’occupent pas de savoir si l’utilisateur a un compte ou pas chez les partenaires du cercle de confiance. C’est l’utilisateur qui est censé savoir quelle identité se trouve sur quel TSP afin de pouvoir la fédérer. Par ailleurs, c’est aussi l’utilisateur qui a le pouvoir de choisir lequel des TSP fera office d’Identity Provider.
3.4 Scénario 3
3.4.1 Objectifs
Le but est de créer l’agence de voyage virtuelle (Virtual Travel Agency ou VTA) qui va utiliser les services des TSP pour proposer de réservation à l’utilisateur.
3.4.2 Description
L’idée est donc de mettre en place une application composite reposant sur les TSP afin de pouvoir fournir les fonctionnalités (basiques) d’une agence de voyage. Les cas d’utilisation ont été développés ci-dessous :
Nous retrouvons à nouveau nos parties Identity Mangement et Reservation Management.
Cette dernière sera déléguée aux différents TSP, l’agence de voyage ne s’occupant que de les orchestrer. Celle-ci proposera différentes réservations suivant les données (date de début et date fin) que l’utilisateur aura saisies.
La VTA repose sur les différents services offerts par les TSP. Ces derniers s’occupent d’effectuer les réservations ou annulations selon les demandes de la VTA. Elle s’occupe de réserver et de proposer une liste de réservations à l’utilisateur suivant les données qu’il a entrées. L’utilisateur peut ensuite confirmer ces réservations ou les annuler.
Le but est aussi que les réservations se fassent de manière transactionnelle : si un problème survient durant une réservation auprès d’un TSP ou que l’utilisateur annule le traitement, toutes les réservations effectuées par la VTA doivent être annulées !
Les aspects concernant l’Identity Management sont les mêmes que pour les précédents scénarii. Ci-dessous, quelques détails supplémentaires sur les fonctionnalités spécifiques à l’implémentation de l’agence virtuelle de voyage :
a) List travel possibilities : récupération et sélection des possibilités de réservation.
b) Create travel : création d’un voyage (réservations effectuées).
c) Edit travel : édition d’un voyage réservé.
d) Cancel travel : annulation d’un voyage.
3.4.3 Limitations
Comme dans le premier scénario, aucune notion de prix n’est mise en place. L’agence de voyage prend en compte un aspect transactionnel basique. Toutefois celui-ci est géré manuellement. D’autre part, l’inscription et la fédération des utilisateurs se fait manuellement au sein des différents TSP.
Pour des raisons de temps, la fonctionnalité concernant l’édition d’un voyage (Edit Travel) n’a pas été implémentée.
4 Mise en œuvre
4.1 Scénario 1
Dans ce scénario, nous mettons en place les différents Travel Service Providers.
4.1.1 Fonctionnalités
Ce chapitre décrit en détail les fonctionnalités qui ont été développées au cours du travail de diplôme. L’aspect technique de celles-ci est décrit dans les chapitres suivants !
Recherche
Toute personne visitant le site a la possibilité d’effectuer une recherche. Cependant, seul un utilisateur authentifié pourra effectuer une réservation !
Figure 14
Enregistrement
Un nouvel utilisateur a la possibilité de s’enregistrer en ligne en fournissant les informations demandées, à savoir : nom, prénom, email, nom d’utilisateur et mot de passe. Cela lui permettra ensuite de se connecter pour effectuer des réservations.
Figure 15
Connexion / Déconnexion
Un utilisateur enregistré a la possibilité de se connecter en utilisant son nom d’utilisateur et son mot de passe. Cela lui permet d’effectuer des réservations (ou des les annuler).
Figure 16
Réservation
Suite à une recherche, si l’utilisateur est connecté, il a la possibilité de réserver une des possibilités qui lui sont présentées dans la liste.
Figure 17
Une fois que l’utilisateur clique sur le bouton Reserver, une confirmation de sa réservation lui est demandée.
Figure 18
Si l’utilisateur décide d’annuler, il revient sur la page d’accueil, sinon la réservation est ajoutée à sa liste de réservation.
Annulation
Parmi la liste des réservations effectuées, l’utilisateur peut en annuler. Dans le même esprit que la réservation, une confirmation lui est demandée.
Figure 20
Il se peut que l’annulation ne fonctionne pas. Ceci est du à la date ! Il faut un certain délai (paramétrable) pour pouvoir effectuer une annulation. Par exemple, si vous essayez d’annuler une réservation dont la date de début est déjà passé, cela ne fonctionnera pas.
4.1.2 Outils
NetBeans 5.5
Tout au long du développement des différents scénarii, l’outil principal a été NetBeans 5.5 avec l’Enterprise Pack 5.5. Il en dépend encore d’autres modules tels que l’UML Modeling entre autre pour la création des cas d’utilisation (Use Case).
Il est à noter que tout est pris en compte par rapport à l’installation par défaut. Les configurations spécifiques à chacun des scénarii sont décrites lors de chaque implémentation.
Application Server
Afin de comprendre les différentes fonctionnalités décrites au cours des prochains chapitres, il est important de s’arrêter sur la notion de serveur applicatif (Application Server). NetBeans 5.5 inclut par défaut le Sun Java System Application Server 9 qui sera utilisé tout au long des différents scénarii.
Un serveur applicatif gère beaucoup de choses. Ci-dessous sont évoquées les principales fonctionnalités qui ont été utilisées :
- Web Applications : ce sont des site Internet. Ceux-ci peuvent être dynamiques et utiliser la technologie Java (Servlet et JSP) pour gérer des pages web.
- Modules EJB : ces modules permettent de mettre à disposition différents Web Services et de mettre en oeuvre la logique métier d'une application.
- Ressources JDBC : cela représente des données de connexion à différentes sources (base de données, fichiers, …) qui peuvent être utilisées des applications fonctionnant au sein de l’Application Server.
L’Application Server contient les deux modules principaux que sont le conteneur web (Web Container) et le conteneur EJB (EJB Container). Le premier est destiné à l’interprétation des pages web, quant à l’autre s’occupe de tout ce qui touche aux EJB au sein de l’Application Server.
Core J2EE Patterns
Afin de développer efficacement et de se baser sur des modèles prédéfinis, quelques Design Patterns définis par les Core J2EE Patterns ont été utilisés. Les Core J2EE Patterns sont un regroupement des meilleures pratiques en matière de développement et de structuration des classes pour des applications Java Enterprise Edition.
4.1.3 Architecture
L’architecture a été créée selon le schéma suivant :
Figure 21
Elle se découpe clairement en trois parties (ou tiers) :
a) Resource (base de données) : stockage des données. Cela prend en compte tout ce qui concerne la gestion des utilisateurs, les objets réservables, les réservations effectuées et les sessions en cours.
b) Application (couche métier) : cela gère toute la partie logique d’un TSP.
Typiquement tout ce qui est réservation d’un objet, authentifcation d’un utilisateur etc.
c) Presentation (application web graphique) : gestion de tout ce qui est affichage à l’utilisateur. Cela comprend la gestion de la navigation et des sessions en cours.
4.1.4 Implémentation
Introduction
Afin de mettre en place l’architecture pré-citée, deux modules ont été développés, à savoir :
a) ServiceProviderLibrary : gestion de la partie Application & Database.
b) ServiceProviderPresentation : gestion de la partie Presentation.
Figure 22 ServiceProviderLibrary
C’est le moteur d’un Travel Service Provider. Ce module est destiné à produire une librairie contenant toute la logique et les objets métiers d’un fournisseur de service pour être utilisable dans un module qui se chargera du tiers de présentation.
ServiceProviderPresentation
Ce module s’occupe de toute la partie interface web. Il utilise notamment ServiceProviderLibrary pour récupérer les données persistentes et les afficher suivant les demandes de l’utilisateur.
ServiceProviderLibrary
Les chapitres ci-dessous décrivent en détails comment la partie ServiceProviderLibrary a été mise en œuvre au sein du scénario 1. Le but de ce module est de créer une librairie gérant les données d’un TSP afin de pouvoir être réutilisée dans différents contextes (Web Application, Web Service, …) qui s’occuperont de gérer le tiers de présentation.
Par ailleurs, cette librairie aura aussi pour but d’implémenter la logique métier des différents TSP.
Implémentation ServiceProviderLibrary
Toute la partie gestion de la logique métier et de la persistence des données est gérée par cette librairie. Voici comment se présente la base de données gérée par celle-ci :
Figure 23
- Customer : représente toutes les données d’un client
- ReservableObject : représente un objet réservable (vol, voiture, …) - Reservation : représente une réservation effectuée
- SessionOpen : représente une session en cours. Cette table est liée au projet ServiceProviderPresentation pour gérer la session en cours des utilisateurs.
Ci-dessous, une représentation UML des principales classes qui ont été développées :
Figure 24
Les différentes classes entités ci-dessus représentent les tables définies dans la base de données pré-citée. A noter qu’il n’existe pas de classe concernant la gestion des objets réservables car ceux-ci ne sont pas censés être modifiés dans le cadre des différents scénarii.
Entités Gestionnaire
d’accès aux données
Persistence des données (JPA)
Afin d’assurer la persistence des données, le projet ServiceProviderLibrary utilise JPA (Java Persistence API). C’est ce que l’on appelle un framework de persistence (on peut également citer Hibernate). JPA fait partie de l’implémentation standard des Enterprise Java Beans (EJB) 3.0. Voici son positionnement dans l’architecture :
Figure 25
Le tiers Application est séparé en deux nouveaux tiers : Business (processus métier) et Integration (accès aux resources). Par rapport au déploiement des classes précédentes, elles se situent ici :
Figure 26
JPA permet de se défaire complètement de la gestion des requêtes SQL natives et de la gestion de connexion aux diverses bases de données. C’est aussi cette API qui gère tout l’aspect transactionnel des différentes requêtes. Par ailleurs, tout ce qui concerne la configuration de la base de données est externalisé.
L’autre avantage de cette API est qu’elle s’utilise très facilement grâce aux annotations Java. Les annotations sont des espèces de tags paramétrés débutant avec un ‘@’ et qui permettent de spécifier certains attributs qui seront utilisés par d’autres classes.
Objectifs JPA
Le but est d’avoir une correspondance entre les classes Java et la base de données. Cela signifie que chaque classe persistente représentera une table de la base : ces classes seront désignées comme étant des entités (Entity Beans).
Par ailleurs, l’utilisation de cette API permet de se défaire de tout ce qui concerne la gestion de la montée en charge (Scalability), gestion des données de connexion ou encore du type de la base de données utilisée.
Configuration ServiceProviderLibrary
Pour que l’Application Server sache quelles sont les données à fournir à l’application, JPA utilise un fichier xml dénommé persistence.xml qui s’occupe de gérer tout cela.
Afin de pouvoir tester la connexion à la base de données avec JPA en mode standalone (notamment pour les tests unitaires), le fichier persistence.xml se présente sous la forme suivante :
Figure 27
Etant donné que pour les tests unitaires, l’exécution se fait en dehors de l’Application Server, il est nécessaire de fournir à JPA toutes les données concernant la connexion, le module de persistence, et autres paramètres y relatifs.
Afin de pouvoir modifier le comportement des différents Travel Service Providers, un fichier de configuration (SPConfiguration.xml) a été créé afin de pouvoir définir certains paramètres dynamiquement. Ce fichier est automatiquement chargé via le moteur. Il se présente sous la forme suivante :
Figure 28
- minDurationReservationInHours : durée minimale d’une réservation.
- maxDurationReservationInHours : durée maximale d’une réservation.
- minDelayBeforeReserveInHours : délai minimal avant la réservation.
- minDelayBeforeCancelInHours : délai minimal avant l’annulation.
Entity Beans
Afin de définir une classe comme entité, il suffit d’utiliser l’annotation @Entity. Il faut alors ensuite spécifier quel est le champs qui sera utilisé comme identifiant (@Id).
Evidemment pour pouvoir établir les correspondances, il existe d’autres annotations qui permettent de spécifier le nom de la table (@Table) ou le nom de la colonne (@Column).
Sur le schéma ci-dessous, voici ce que donnerai l’implémentation Java de la table Customer (client), représentée à gauche :
Figure 29
Toujours grâce à ces annotations, nous pourrions simplifier l’écriture de la classe en ajoutant certains paramètres :
Figure 30
Il existe encore différentes annotations afin que le schéma de classe puisse correspondre le plus fidèlement possible au schéma de la base de données, notamment en ce qui concerne les clés primaires multiples (@IdClass) et les relations (@ManyToOne,
@OneToMany, @OneToOne, @ManyToMany).
L’aspect le plus intéressant de JPA réside non seulement dans sa simplicité, mais aussi de par sa compatibilité avec les requêtes SQL. Grâce à cette API, il n’est plus nécessaire d’éparpiller les requêtes à travers les classes : désormais elles peuvent être codées directement dans la classe entité.
De plus, il est intéressant que cela ne soit pas du SQL classique dont les interprétations ne sont pas toujours les mêmes au sein des divers moteurs de base de données (typiquement entre Oracle et Micosoft SQL Server). Le language utilisé est le JPQL (Java Persistence Query Language). C’est un langage assez proche des requêtes SQL classiques qui sera interprété pour générer le code SQL compatible avec le moteur de base de données utilisé.
Afin d’implémenter ces requêtes au sein de notre classe, les annotations @NamedQueries et @NamedQuery sont à notre disposition :
Figure 31
Le gros avantage est que toutes les requêtes sont au même endroit et qu’elles seront automatiquement converties pour être comprises par le moteur de la base de données utilisé. Par ailleurs, la validité de toutes les requêtes est faite lors de l’exécution de la première requête, ce qui évite des fautes synthaxique de base.
Un des inconvénients majeurs est que si ces requêtes devaient être modifiées, cela implique la recompilation de la classe ! Cela est valide pour n’importe quelle modification concernant les annotations.
Configuration serveur
Tout ce qui concerne les données de connexion est stocké directement au sein de l’Application Server. Ces données seront ensuite récupérées automatiquement par JPA suivant un fichier de configuration persistence.xml.
Les figures suivantes montrent une partie de la configuration des données et la connexion y relative dans la console d'administration de l’Application Server :
Figure 32
Figure 33
Configuration JPA
Lorsque l’application utilisant JPA est exécutée au sein de l’Application Server et que le configurations précitées ont été faites, le fichier persistence.xml se présente de la manière suivante :
Figure 34
La notion d’unité de persistence (Persistence Unit) est introduite. C’est grâce à elle que nous allons pouvoir indiquer à l’intérieur de nos classes quelle sera la connexion à utiliser. Cette connexion est définie ici dans le nœud jta-data-source. JTA (Java Transaction APIs) concerne tout l’aspect transactionnel des données. D’autre part, une liste de classe est affichée : ce sont toutes les classes dénommées comme Entity Beans qui sont destinées à être gérées par la connexion définie.
Une fois ce fichier défini, il suffit d’indiquer à l’Application Server (plus précisément à l’EJB Container) où la référence sur cette unité de persistence doit être envoyée (il peut y en avoir plusieurs). Il y a pour cela deux annotations à disposition : @PersistenceContext et @Resource. Elles vont être définies comme suit :
Figure 35
Dans l’exemple ci-dessus, nous récupérons non seulement le gestionnaire d’entités qui nous servira à définir si une entité doit être persistente ou pas, mais aussi le gestionnaire transactionnel qui servira à valider les différentes actions.
Lorsque cette classe sera instanciée dans le cadre d’une application, l’EJB Container va automatiquement attribuer les références sur les bons objets qui pourront ainsi être utilisés par les autres classes.
Il est à noter que cette configuration est valide dans le contexte d’une Application exécutée dans un Application Server. L’expérience a démontré que suivant le contexte d’utilisation (application standalone, Web Service ou autre), la variable _userTransaction n’as pas toujours besoin d’être utilisée (contexte transactionnel inexistant).
ServiceProviderPresentation
Ce module consiste à créer une Web Application pour présenter les différentes fonctionnalités définies par un TSP. Il utilise la librairie ServiceProviderLibrary afin de n’avoir que la partie visuelle (Graphic User Interface ou GUI) à gérer.
Comme vous avez pu le constater, la partie visuelle est purement fonctionnelle. Toutefois elle a été pensée pour pouvoir être facilement adaptable à un graphisme.
Le principal objectif de cette partie a été de mettre en place la gestion de la navigation et l’affichage des pages. Pour atteindre cet objectif, le Design Pattern Front Controller a été mis en place.
Implémentation Design Pattern Front Controller
L’idée est de déléguer toute la gestion de la navigation à une classe qui s’occupera de rediriger les utilisateurs sur la page demandée. Dans cette optique, toutes les requêtes sont envoyées à la même servlet et se présentent toutes sous la même forme (cf plus bas).
Ainsi l’état de la session et les droits d’accès de l’utilisateur en cours peuvent être vérifiés et validés pour savoir s’il peut accéder ou non à la page demandée.
Dans le cas d’un TSP, les requêtes auront toutes la forme suivante : http://www.tsp.com:8080/tsp/sp?action=home
- http://www.tsp.com/tsp : URL du site du TSP.
- /sp : appel de la Servlet faisant office de Front Controller.
- action=home : demande de la page home.
Ci-dessous, le schéma UML de l’implémentation :
Toutes les requêtes sont envoyées ici
Figure 36
Ces classes se situent au niveau du tiers presentation :
Figure 37
Dans l’implémentation actuelle, toutes les différentes classes servant à gérer l’affichage d’une page héritent de la classe AbstractSPServlet qui effectue les vérifications principales et définit les paramètres généraux.
La classe RequestFrontController quant à elle utilise la classe NavigationController.
Cette dernière s’occupe de retourner l’url correspondante à un page. Elle se base sur un fichier de configuration externe de la forme suivante :
Figure 38
Typiquement, lorsque l’url suivante sera demandée : http://www.tsp.com:8080/tsp/sp?action=home l’utilisateur sera redirigé vers :
http://www.tsp.com:8080/tsp/home.jsp
Certaines pages telles que home ne nécessitent pas de traitement particulier, c’est pourquoi la page JSP est automatiquement affichée. Les autres correspondent toutes à des Servlet : une classe qui s’occupera d’effectuer différentes actions avant d’afficher un résultat.
Voici comment se déroule le processus d’appel d’une page :
Figure 39
1) L’utilisateur (Customer) demande une page (action=my_reservations).
2) La requête arrive chez le RequestFrontController qui va vérifier si l’utilisateur a le droit d’y accéder (état de la session).
3) Il demande au NavigationController ou il doit rediriger la requête.
4) La requête est redirigée sur l’url demandée (généralement une Servlet).
5) La Servlet effectue les différentes actions selon la requête.
6) L’affichage du résultat est renvoyé à l’utilisateur.
4.1.5 Déploiement
Ci-dessous le schéma de déploiement d’un Travel Service Provider sur un serveur représenté sur les différents tiers :
Figure 40
4.2 Scénario 2
Dans ce scénario, le but est d’ajouter la notion de fédération d’identités entre les différents Travel Service Provider en utilisant les protocoles de Liberty.
4.2.1 Introduction
Pour des raisons de performances, seuls deux Travel Service Providers ont pu être déployés. Leur tiers de présentation est une Web Application. Il s’agit d’un hotel et d’une compagnie aérienne.
A la base chaque TSP fait office uniquement de Service Provider. Comme dans le scénario 1, ils ne se connaissent pas et se méfient l’un de l’autre. Nous avons donc le schéma suivant :
Figure 41
Dans un deuxième temps, TSP Flight va agir également comme Identity Provider. TSP Hostel pourra ainsi lui faire confiance et permettra aux utilisateurs de fédérer leurs identités avec lui :
Figure 42
Dans un troisième temps, TSP Hostel agit lui aussi comme Identity Provider. TSP Flight va donc aussi pouvoir lui faire confiance.
Figure 43
L’idée est qu’un utilisateur inscrit sur TSP Hostel et sur TSP Flight pourra choisir de fédérer son identité auprès de l’un ou de l’autre. Cela signifie qu’il pourra choisir le profil avec lequel il se connectera.
Le schéma suivant démontre comment fonctionne un Identity Provider et deux Service Providers pour fédérer une identité :
Figure 44
Dans notre cas, il n’y a pas trois organismes, mais seulement deux qui agissent en tant qu’Identity Provider et Service Provider. L’utilisateur va donc choisir l’un d’eux pour fédérer son identité :
Figure 45
L’identité entourée en orange décrit celle qui sera utilisée par l’utilisateur pour se connecter sur les deux sites. Comme dit précédemment, l’identité herojb@idp a été fusionnée avec jackb@tdflight.
4.2.2 Fonctionnalités
Au cours des différentes étapes de ce chapitre, nous allons voir un utilisateur s’enregistrer, puis fédérer son identité. Nous verrons ensuite comment il peut faire du Single Sign On avec cette identité fédérée.
Création des identités
Ci-dessous, la création d’une identité auprès des deux Travel Service Providers http://www.tdhostel.com et http://www.tdflight.com selon les schémas pré-établis.
Figure 46
En revenant sur la page d’accueil, il y a quelques différences par rapport au premier scénario :
Figure 47
L’erreur signifie qu’actuellement l’utilisateur n’est pas connecté ou bien qu’il est connecté localement sur le TSP en ayant utilisé le module d’authentification du scénario 1.
La deuxième différence est ce lien IDP Login qui va permettre à l’utilisateur de se connecter sur l’Identity Provider. La différence par rapport au Local Login ci-dessus, est que le fait d’utiliser le IDP Login permet de récupérer un Single Sign On Token. Celui-ci sera affiché à la place de l’erreur affichée actuellement.
Fédération des identités
Nous allons fédérer l’identité jbauer@tdhostel avec l’identité jackb@tdflight ! Pour ce faire, il faut passer par le IDP Login. L’écran suivant s’affiche :
Figure 48
Etant donné que dans l’état actuel des choses aucune identité n’est fédérée, nous ne pouvons pas utiliser l’authentification de l’Identity Provider. Nous allons donc passer par le TSP Login.
Nous arrivons ensuite sur l’écran suivant :
Figure 49
Il suffit de fournir le nom d’utilisateur et mot de passe que nous avons défini dans le chapitre précédent, à savoir jbauer. Dans ce contexte, une authentification JDBC va être utilisée. Elle est configurée pour se connecter à la base de données du TSP pour vérifier les données de connexion entrées par l’utilisateur.
Après l’authentification, nous sommes redirigés sur la page d’accueil :
Figure 50
Nous avons maintenant différentes données qui sont affichées. Tout d’abord le Single Sign On Token qui a été créé lors de l’authentification. Le Principal est aussi affiché pour information.
Voici en détail ce qui s’est passé lors ce cette authentification :
Figure 51
1) L’utilisateur clique sur IDP Login.
2) La requête arrive sur le Front Controller qui la redirige sur la Servlet gérant l’authentification.
3) Celle-ci détecte que l’utilisateur veut s’authentifier à travers Access Manager. Elle redirige l’utilisateur.
4) Access Manager vérifie si un Single Sign On Token est déjà créé. Etant donné que non, il redirige l’utilisateur sur une page lui demander ou il veut s’authentifier (sur le TSP ou via un IdP).
5) L’utilisateur clique sur TSP Login et entre son identifiant et mot de passe.
6) Access Manager sélectionne le module d’authentification.
7) Le module d’authentification utilise JDBC pour récupérer les valeurs depuis la base de données.
8) Access Manager vérifie si le nom d’utilisateur et le mot de passe sont corrects puis redirige l’utilisateur sur la page principale du Reservation Manager.
9) La requête arrive au Request Front Controller qui affiche la page d’accueil à l’utilisateur.
Par ailleurs, différents liens sont à dispositions sur la gauche, dont celui qui nous intéresse : Federate. Celui-ci va nous permettre de relier notre identité en cours (jbauer) à celle de l’Identity Provider (jackb).
Voici ou ce lien nous amène :
Figure 52
Ici, le serveur demande de sélectionner l’Identity Provider avec lequel l’identité en cours (jbauer) doit être fédérée. Dans ce scénario, seul un Identity Provider peut êre sélectionné. Si un troisième TSP avait été déployé, l’utilisateur aurait le choix entre deux possibilités.
Après avoir cliqué sur le bouton Submit nous arrivons sur l’Identity Provider sélectionné :
Figure 53
Il est important de noter que nous sommes à présent sur la page d’authentification du site http://www.tdflight.com ! Nous indiquons donc que l’identité jbauer doit être fédérée avec l’identité jackb sur l’Identity Provider.
Si les données de connexion sont correctes, l’écran suivant s’affiche :
Figure 54
Nous nous retrouvons à nouveau sur le site http://www.tdhostel.com avec un message nous indiquant que la fédération d’identité s’est correctement passée ! Nous pouvons facilement nous en assurer, car si à présent nous recliquons sur Federate, nous arrivons sur l’écran suivant :
Figure 55
Dans notre cas, étant donné que nous n’avons qu’un seul Identity Provider et que l’identité en cours a déjà été fédérée avec une autre sur cet Identity Provider, le serveur nous indique qu’une nouvelle fédération n’est pas possible. Cela démontre qu’une identité ne peut être fédérée qu’avec une seule autre sur un Identity Provider.
Single Sign On
Maintenant que nous avons une identité fédérée, nous allons voir comment nous pouvons faire du Single Sign On entre l’Identity Provider et le Service Provider, respectivement entre les sites http://www.tdflight.com et http://www.tdhostel.com.
L’exemple fonctionne exactement comme le décrit le schéma suivant :
Figure 56
Afin de pouvoir démontrer le Single Sign On, il est nécessaire de redémarrer une nouvelle sessions en relançant Internet Explorer par exemple.
A présent, retournons sur le site http://www.tdhostel.com. Lorsque nous cliquons sur IDP Login, nous arrivons automatiquement sur l’écran de login de l’Identity Provider (http://www.tdflight.com) :
Figure 57
Cette redirection automatique est due à un cookie enregistré lorsque la fédération a été faite. Cela nous permet d’entrer les données de connexion de l’utilisateur jackb et de se connecter. Automatiquement nous allons nous retrouver sur la page d’accueil du site http://www.tdhostel.com connecté avec l’identité correspondante (jbauer).
Figure 58
Il est important de comprendre que nous avons actuellement 2 sessions ouvertes : - Sur http://www.sphostel.com en tant que jbauer
- Sur http://www.spflight.com en tant que jackb
Preuve en est que si maintenant nous accédons directement au site http://www.spflight.com, l’écran est suivant :
Figure 59
Il y a aussi un Single Sign On Token mais avec un identifiant différent, ainsi que le nom du Principal en cours.
Voici en résumé ce qui s’est passé pour effectuer le Single Sign On :
Figure 60
1) L’utilisateur clique sur IDP Login.
2) La requête arrive sur le Front Controller qui la redirige sur la Servlet gérant l’authentification.
3) Celle-ci détecte que l’utilisateur veut s’authentifier à travers Access Manager. Elle redirige l’utilisateur.
4) Access Manager vérifie si un Single Sign On Token est déjà créé. Etant donné que non, il détecte que l’utilisateur s’est déjà authentifié une fois auparavant sur l’Identity Provider. Il redirige l’utilisateur vers l’Identity Provider.
5) L’Identity Provider demande à l’utilisateur de s’authentifier.
6) L’utilisateur entre son identifiant et mot de passe.
7) L’Identity Provider sélectionne le module d’authentification.
8) Le module d’authentification utilise JDBC pour récupérer les valeurs depuis la base de données.
9) L’identity Provider vérifie si le nom d’utilisateur et le mot de passe sont corrects puis redirige l’utilisateur vers l’Access Manager du Service Provider.
10) Access Manager établit la liaison entre l’identité de l’Identity Provider et l’identité local, puis créer un Single Sign On Token. Il redirige ensuite l’utilisateur vers la page d’accueil du Reservation Manager.
11) La requête arriver au Request Front Controller qui affiche la page d’accueil à l’utilisateur.
Single Logout
Etant donné que plusieurs sessions sont ouvertes en même temps (sur l’Identity Provider et le Service Provider), il y a moyen de faire un déconnexion globale (Single Logout) :
Figure 61
Figure 62
Cet écran nous indique que la session a été invalidée auprès de l’Identity Provider et du Service Provider.
Toutefois, le Single Sign On Token n’a pas été détruit au sein du navigateur, ce qui signifie que la session est maintenue sur le site jusqu'à ce que le Token soit invalide (timeout).
Défédération des identités
Il se peut que pour une raison quelconque, l’utilisateur ne veut plus que son identité soit fédérée avec une autre sur un Identity Provider. Il a alors la possibilité de dé-fédérer son identité :
Figure 63
Figure 64
Comme lors de la fédération, le serveur demande avec quel Identity Provider la fédération doit être terminée.
Figure 65
Le serveur a automatiquement fait la correspondance entre les identités jbauer et jackb puis a rompu les liens qui unissaient ces deux identités. Il ne sera maintenant plus possible de faire du Single Sign On à travers l’Identity Provider spflight.
Autres fonctionnalités
Les diverses fonctionnalités concernant les réservations décrites dans le scénario 1 fonctionnent de la même manière !
4.2.3 Outils
Access Manager
C’est un logiciel développé par Sun Microsystems qui fournit plusieurs fonctionnalités dont celles qui étaient requises pour le scénario 2. Parmi celles-ci :
- Single Sign On - Fédération d’identités - Architecture J2EE - Intégré à NetBeans 5.5
Actuellement, ce programme est passé en open source et est désormais ouvert à la communauté sous le nom OpenSSO (https://opensso.dev.java.net/).
Dans ce scénario, Access Manager est utilisé principalement pour l’implémentation de Liberty ID-FF et donc tout ce qui touche à la fédération d’identités.
Reservation Manager
Cela correspond à l’implémentation du scénario 1.
4.2.4 Architecture
Afin de mettre en place la partie Fédération d’identité sans avoir à trop retoucher le code des TSP, l’outil Access Manager 7.1 de Sun Microsystems a été utilisé. Un TSP se compose à présent de deux parties bien distinctes :
- Access Manager => Identity Management.
- Reservation Manager => Reservation Management.
Figure 66
4.2.5 Implémentation
Comme dit dans le chapitre précédent, l’implémentation des TSP par rapport au scénario 1 change très peu. Seules 2 modifications ont été effectuées :
- Ajout d’un fichier de configuration (URL Access Manager) - Vérification du Single Sign On Token
Fichier de configuration
Le fichier identityUrl.properties sert principalement à définir les paramètres qui seront envoyés à Access Manager par le biais des différents liens. Il se présente comme suit :
Figure 67
Ces variables peuvent être récupérées via la classe NavigationController. Ce sont celle-ci qui seront utilisées par les pages de connexion, déconnexion, fédération et défédération pour rediriger l’utilisateur vers Access Manager.
Single Sign On Token
Enfin la deuxième configuration porte sur la classe AbstractSPServlet : elle consiste à vérifier l’existence et la validité du Single Signe On Token :
Figure 68
Le processus se déroule comme ceci :
- l’application essaie de détecter si un Single Sign On Token existe.
- s’il existe, est valide et que l’utilisateur n’est pas connecté, l’application le connecte automatiquement.
- s’il n’y a pas de Single Sign On Token, l’application essaie de voir si l’utilisateur s’est connecté localement (scénario 1).
- si oui, l’utilisateur est déjà connecté.
- si non, dans tous les cas, l’utilisateur est déconnecté car il se peut que la session ait expirée.
4.2.6 Configuration
La majeure partie du scénario 2 consiste en la compréhension et la configuration d’Access Manager au sein des différents TSP. Cela se passe en deux temps :
- configuration de l’authentification via JDBC.
- configuration de l’IDP et SP.
Authentification
Ce chapitre décrit la configuration suivante :
Figure 69
Access Manager offre la possibilité de définir différents référentiels d’identités (LDAP, JDBC, …). Lorsqu’un utilisateur s’enregistre au sein d’un TSP, celui-ci est ajouté dans une base de données (cf scénario 1). Nous indiquons donc à Access Manager qu’il doit utiliser cette base de données pour authentifier les utilisateurs.
Les étapes suivantes sont les mêmes pour les deux TSP ! Fonctionnement
Access Manager offre plusieurs modules d’authentification dont ceux que nous utiliseront : JDBC (base de données) et DataStore (fichiers plats). Dans un deuxième
Enfin il est possible de définir un chaînage d’authentification (Authentication Chaining).
Cela permet par exemple de demander à un utilisateur de se connecter à l’aide d’un nom d’utilisateur et un mot de passe, et ensuite un certificat. Par ailleurs, Access Manager permet de définir différent chaînage d’authentification suivant que l’on veut accéder à la console d’administration ou non.
Configuration
Cela se passe dans la console d’Access Manager > Realm > Authentication.
Figure 70
Nous avons la possibilité de définir plusieurs modules d’authentification au sein d’Access Manager. Typiquement le module DataStore est le module par défaut qui se base sur les profils utilisateurs enregistrés dans des fichiers plats.
Dans notre cas, nous avons ajouté un module JDBC dont la configuration est la suivante :
Figure 71
Toutes les données nécessaires à Access Manager pour effectuer l’authentification sont définies sur cet écran. Il est intéressant de noter le paramètre entouré ci-dessus : il définit une classe permettant de transformer le mot de passe entré par l’utilisateur afin de correspondre à celui dans la base de données, comme par exemple en encodage MD5 !
