Soutenance mémoire
L’architecture orientée service [LZV08, PH07, RVC07] propose un modèle d’architecture distribuée basé sur la notion de service. Un service est un ensemble de fonctions qui reçoivent des messages et qui restituent le résultat de leur traitement. L’architecture orientée service est bâtie autours de trois composants : un annuaire des services qui liste l’ensemble des services disponibles, les fournisseurs de services, et les consommateurs de services. Une implémentation de ce concept se retrouve dans les Web Services qui sont articulés autour du langage pivot XML. Les Web Services [Cer02] ont été au départ conçus, selon les principes du réseau Internet, comme un ensemble de services réutilisables, librement mis à la disposition de chacun. Le développement des Web-Services a permis la création de nouveaux services utilisant des services différents pour fournir un service complet. Nous pouvons prendre comme exemple un service complet de vente de livres en ligne qui utilisera plusieurs services différents, comme celui d’une librairie, d’une banque fournissant un service de paiement et d’un livreur permettant de délivrer le produit au client. Les accès à ces multiples services sont orchestrés dans un programme qui peut en particulier être écrit dans un langage dédié nommé BPEL (Business Process Execution Language).
Le langage BPEL [BPE07] est un langage relativement simple qui permet de décrire dans quel ordre les appels aux différents services nécessaires au bon fonctionnement du programme sont réalisés. Le programme BPEL peut recevoir des informations des utilisateurs, et utiliser ces données pour fournir des informations aux services qu’il invoque. Par conséquent, le programme BPEL réalise des flux d’information depuis les données de l’utilisateur vers les services qu’il utilise.
Architecture orientée service
Généralités
Dans une architecture orientée service (Service Oriented Architecture (SOA))[LZV08, PH07, RVC07] les ressources logicielles sont organisées sous la forme de services. Les services sont des modules indépendants les uns des autres vis à-vis de leur état ou de leur contexte d’exécution. Ils fournissent un ensemble de fonctions qui reçoivent des messages et restituent le résultat de leur traitement.
Une architecture orientée service est bâtie autour de trois composants principaux :
– un fournisseur de services, qui produit, maintient et propose un certain nombre de services ;
– un consommateur de services, soit un humain, soit un logiciel, qui utilise les services proposés par le fournisseur ;
– un annuaire de services qui permet de rechercher les services disponibles.
Ainsi le fournisseur de services publie ses services dans l’annuaire. Le consommateur de services peut ainsi rechercher les services disponibles dans l’annuaire puis se connecter au fournisseur de services afin d’utiliser le service recherché.
Dans le cadre des architectures orientées services dites statiques le consommateur recherche à la main dans l’annuaire les services qu’il va utiliser et les organise de manière statique afin de créer, par exemple, de nouveaux services. Dans ce cas l’annuaire n’est utilisé que dans la phase de développement. Il existe deux manières différentes de permettre les interactions entre les services. Dans le cadre d’une chorégraphie les services connaissent les services avec lesquels ils interagissent afin de réaliser une tâche définie.
Une implémentation des SOA : les Web Services
Les Web Services [CDK+02, Ma05, Lou06, YLBM08] sont une implémentation des architectures orientées services basée sur le langage XML. Ils sont basés sur trois piliers principaux :
– SOAP pour le transport des messages,
– WSDL pour la description des interfaces de service,
– UDDI pour la création des annuaires de services.
Une des forces des Web Services repose sur l’utilisation des standards de l’Internet. En effet si SOAP est un langage basé sur XML, le protocole de transport utilisé pour véhiculer les messages est le plus souvent HTTP. Ainsi les Web Services ne définissent pas un réseau parallèle aux réseaux existants, mais s’appuient directement sur les infrastructures existantes.
Echange de messages
SOAP [SOA07] est un protocole d’échange de messages basé sur XML. A l’origine SOAP a été créé afin de faire de l’appel de procédures distantes depuis HTTP. Cependant SOAP ne définit pas un nouveau protocole de transport, il s’appuie sur les protocoles de transport existants. SOAP est aujourd’hui disponible sur HTTP, SMTP, … La norme ne définit pas seulement la structure des messages mais aussi les différentes manières de l’employer.
Un message SOAP est composé de 2 parties principales : un en-tête et un corps contenus dans une enveloppe globale . L’en-tête optionnel permet de rajouter des informations complémentaires relatives notamment à la sécurité. Le corps du message contient quant à lui l’ensemble des données utiles au service. Le message SOAP est au format XML. La seule contrainte est que la syntaxe du message doit-être valide. Le contenu du message n’est pas limité à des données XML. En effet tout type de contenu (en particulier des données binaires) peut-être inséré au sein d’un message SOAP.
Description des interfaces
WSDL (Web Service Description Language) [WSD01] est une norme basée sur XML qui permet de décrire l’interface qui permet d’accéder aux Web Services. WSDL peut-être vu comme un contrat qui permet de spécifier comment accéder au service. Un Web Service est décrit dans un fichier WSDL comme une collection de ports de communication avec lesquels on peut échanger certains messages.
BPEL : l’orchestration des Web Services
BPEL (Business Process Execution Language) [BPE07] est un langage permettant de décrire une orchestration de Web Services. Il est issu des langages WSFL (Web Services Flow Language) d’IBM et XLang de Microsoft. Il permet de décrire des processus métiers en XML. Un processus BPEL est ensuite exécuté à travers un Web Service. Une présentation plus complète de l’utilisation de BPEL dans le développement d’applications web peut-être trouvé dans [Pas05]. Un processus BPEL est composé de partenaires qui interagissent avec le processus à travers des partner link. Le processus global résultant est décrit par un fichier WSDL à l’instar de n’importe quel Web Service.
|
Table des matières
Introduction
1 Sécurité des architectures orientées services
1.1 Architecture orientée service
1.1.1 Généralités
1.1.2 Une implémentation des SOA : les Web Services
1.1.3 BPEL : l’orchestration des Web Services
1.2 Sécurité des Web-Services
1.2.1 Briques standards pour la sécurité des Web-Services
1.2.2 Protection des Web Services et du contenu des messages
1.3 Bilan
2 Politique de sécurité pour les architectures orientées services
2.1 Modèles d’accès discrétionnaire et obligatoire
2.1.1 Le modèle d’accès discrétionnaire
2.1.2 Le modèle d’accès obligatoire
2.1.3 Utilisation de ces modèles dans les architectures orientées services
2.2 Modèle RBAC
2.3 Modèles de sécurité pour les architectures orientées services
2.4 Bilan
3 Contrôle de flux d’information
3.1 Suivi des flux d’information
3.1.1 Flux d’information
3.1.2 Flux d’information au sein des programmes
3.1.3 Flux d’information dans un système d’exploitation
3.1.4 Flux d’information dans les orchestrations de service
3.2 Politiques de flux d’information
3.2.1 Politiques en treillis
3.2.2 Le modèle décentralisé
3.2.3 Le modèle du système Blare
3.2.4 Le modèle de la non-interférence
3.3 Vérification statique des politiques de flux
3.3.1 Principe du contrôle statique de flux d’information
3.3.2 Contrôle de flux d’information par typage
3.3.3 Application du contrôle de flux par typage
3.3.4 Au niveau des orchestrations de service
3.4 Suivi dynamique des flux d’information
3.4.1 Au niveau des programmes
3.4.2 Au niveau des systèmes d’exploitation
3.5 Modification de la politique de sécurité
3.5.1 Comment sont effectuées les déclassifications
3.5.2 Qui peut déclassifier ?
3.5.3 Quelles informations peut-on déclassifier ?
3.5.4 Où peut-on déclassifier ?
3.5.5 Quand peut-on déclassifier ?
3.6 Bilan
4 Politique de flux d’information pour les orchestrations de service
Conclusion
