3.1.1 Vue d’ensemble
Pour avoir une vue d’ensemble de notre futur système, nous allons modéliser un diagramme de flux de données (DFD) qui est une représentation graphique du flux de données à travers un système d’information. Il nous permet de visualiser les flux de données échangés entre les différents services. Nous avons pour les différents services énumérés dans le chapitre II pu ressortir le diagramme de flux de données suivant :
Fig. 3.1 Diagramme de flux de données
A première vue, Il en ressort de notre diagramme quatre groupes de transactions de données étiquetés par des notations numériques suivantes :
(1) Authentification
Tous les utilisateurs pour accéder à l’ensemble des services de la plateforme doivent pouvoir s’authentifier à travers un identifiant et un mot de passe.
(2) Vérification du profil
Une fois l’utilisateur authentifié par le système, son profil est alors automatiquement récupéré et en fonction des droits dont il dispose, il accède aux services de la plateforme.
(3) Accès aux services
L’accès aux services est conditionné par les droits que dispose chaque utilisateur authenticité.
(4) Composition de services
Pour fournir un service quelconque, un service peut avoir impérativement ou partiellement besoin d’un autre service. Il s’agit alors de la composition de services.
De manière globale, l’on constate que la livraison d’un service est le résultat d’un ensemble de plusieurs interactions entre les protagonistes mis en œuvre. Cependant aussi, il se dégage que l’on peut regrouper les services offerts en plusieurs catégories.
3.1.2 Catégories de services
La vue d’ensemble du système ainsi modélisé nous a permis de comprendre que certains services ont besoins d’autres et certains pas. Nous avons donc pu identifier plusieurs catégories de services :
– Les services indépendants des autres : ils peuvent être classés à la base d’une pyramide pour dire qu’il s’agit ici du socle de notre plateforme. Ce type de services peut fonctionner sans besoin d’autres services et constituent des services indispensables au fonctionnement des services situés au sommet de la pyramide. Exemple : le service d’Authentification ;
– Les services non visibles par les utilisateurs : ils peuvent être considérés comme des middlewares (services intermédiaires) permettant la réalisation d’autres services sans pour autant que l’utilisateur ne soit au courant de son existence. Exemple : le service Gestion de profils ;
– Les services applicatifs : ils sont constitués des services offerts aux utilisateurs finaux de la plateforme. Ils nécessitent impérativement l’intervention des services indépendants ou des services non visibles pour fonctionner. Ils peuvent aussi nécessiter la collaboration des services situés au même niveau qu’eux dans la pyramide pour pouvoir offrir un service de qualité. Exemple : le service Agenda, Forum, Gestion de stockage et Gestion de documents, Contacts, Mail, Classe et Groupe de travail etc.
L’on peut représenter les différentes catégories de services ainsi énumérées par la figure 3.2 ci-dessous :
Fig. 3.2 Catégorisation des services
La représentation schématique des catégories de services met en exergue le fait que les services intermédiaires (services non visibles) et les services positionnés au sommet de la pyramide (services applicatifs) nécessitent la collaboration des services du socle (services indépendants) pour pouvoir offrir une garantie de service. Cependant, nous avons proposé aussi un modèle de communication permettant une collaboration horizontale et verticale (les services de niveau plus haut nécessitant la collaboration des services de niveau inférieur) entre les différents services de la plateforme regroupés en catégories.
3.1.3 Modèle de communication
Comme nous l’avons rappelé dans le deuxième chapitre, les services web permettent aux applications d’interopérer en se fondant sur des standards tels que XML, UDDI, WSDL, SOAP, etc. Quoique ces protocoles permettent aujourd’hui de bâtir des applications et de les mettre en production, de nombreuses évolutions restent à apporter pour offrir la prise en compte de critère de qualité de services tels que la sécurité, la garantie de livraison et les transactions.
La sécurisation d’une infrastructure fondée sur une architecture SOA s’avère beaucoup plus complexe que celle des environnements traditionnels. L’agrégation de services de provenances diverses implique la nécessité de pouvoir proposer un modèle de sécurité outre que celui proposé par la pile de protocoles. Les applications, qu’elles soient ou non constituées des services web, font face à un certain nombre de menaces sous répertoriées sous l’acronyme STRIDE [26] :
– Spoofing identity : un utilisateur non accrédité usurpe l’identité d’un utilisateur valide de l’application ;
– Tampering with data : un utilisateur détruit ou modifie les informations sans autorisation ;
– Repudiability : la possibilité qu’un utilisateur nie avoir effectué telle ou telle opération ;
– Information disclosure : des données confidentielles sont rendues visibles à des utilisateurs non accrédités ;
– Denial of service : l’application est rendu indisponible ;
– Elevation of privilege : un utilisateur dispose d’un niveau d’accès à l’application supérieur à celui qui devrait lui être accessible.
Pour se prémunir de ces menaces, nous avons envisagé différentes techniques liées à la mise en œuvre de la sécurité :
– Exploitation des mécanismes standards liés aux protocoles de transport tels que SSL, TLS et IPSec (IP Security Protocol) permettant d’assurer la confidentialité des échanges entre un client et un serveur web ;
– Le mécanisme d’authentification qui permet de se prémunir contre l’usurpation d’identité. Dans notre système, chaque utilisateur s’authentifie au préalable pour avoir accès à l’ensemble des services proposés (Single Sign On) ;
– Les autorisations qui permettent de définir des droits d’accès d’un client authentifié vis-à-vis de l’ensemble des services ;
– Modélisation d’un mécanisme de communication contraignant les services à communiquer uniquement soit avec les services de strate inférieure ou avec les services de niveau égal.
Cette dernière technique est une organisation des services par catégories que nous avons préconisées pour garantir une accessibilité able des différents services. Les communications se font dans deux sens et pour chaque service, un ensemble d’informations est nécessaire pour permettre ainsi d’établir l’échange. Pour qu’une collaboration de services soit établie, le service agrégeant doit fournir les informations suivantes au service agrégé :
– Catégorie : cette variable permet de savoir dans quelle catégorie le service appartient. Il faudrait que le service agrégeant soit de la même catégorie ou d’une catégorie inférieure que le service agrégé pour qu’il y a collaboration ;
– Profils : permet de récupérer le pro l de l’utilisateur. A chaque profil correspond un ensemble de priorités et de restrictions (droits d’accès) vis-à-vis de l’ensemble de la plateforme ;
– Critique : cette dernière variable permet de savoir si les données échangées doivent être sécurisées ou non ; c’est dire si elles doivent être transmises en claire ou non. En somme, le service nécessitant une collaboration devrait fournir une étiquette suivante pour être accessible :
Fig. 3.3 Modèle de communication entre les services
Cependant, ce modèle de communication mis en œuvre participe non seulement à la sécurité mais aussi à une livraison de service able. A ce modèle syntaxiquement structuré (basé sur le langage XML), l’ajout d’une structure sémantique viendrait définitivement résoudre les problèmes liés à la composition dynamique des services.
Les services web étant aussi indépendants les uns des autres, nous allons dans la suite de notre travail, réaliser des modélisations individuelles de chaque service.
Page suivante : 3.2 Modélisation des différents services de la plateforme