6.6 Présentation des résultats
6.6.3 Evaluation de la passerelle virtuelle SecureSpan Gateway
Dans cette dernière étape on aimerait effectuer une petite analyse sur les avantages et les inconvénients de la passerelle SSG. Dès les phases d’installation et de configuration de la SSG jusqu’à l’implémentation des politiques de Run-Time on a pu se faire une idée de son potentiel et de ses inconvénients que l’on aimerait partager avec le lecteur.
L’utilisation de la passerelle SSG dans l’architecture orientée services offre des avantages non négligeables dans les domaines de la sécurité et de la gouvernance SOA. Dans cette expérience on a trouvé comme positif les points suivants:
Sécurité: La SSG offre une solution efficace au problème de sécurisation des services web et des applications XML. Cette solution est implémentée sous la forme d’unXML Firewall permettant d’inspecter le contenu des messages SOAP et XML en fonction des politiques de sécurité définies par l’administrateur. Les services de confidentialité, non-répudiation, authentification, autorisation et d’intégrité sont supportés à deux niveaux distincts, au niveau des protocoles Internet comme HTTPS et FTPS, et au niveau des messages XML au moyen des spécifications telles que XML Signature, XML Encryption, WS-Security, etc.
Politiques cross-domain et composition: La SSG ne se limite pas aux politiques de sécurité mais elle couvre un grand nombre de domaines comme celui des politiques de contrats et de qualité de services. On peut aussi définir des politiques pour les domaines de gestion d’identités, du routage des messages, la traduction des protocoles
de transport (HTTP, JMS, FTP). Le domaine du Compliance est couvert par les politiques d’audit et logging permettant de capturer les informations utilisées dans les rapports opérationnels. Grâce aux opérateurs logiques AND et OR, on peut combiner les assertions dans une séquence logique pour construire une politique dynamique. Les politiques peuvent être réutilisées basées dans l’importation et l’utilisation des templates.
Gestion avancée et centralisé: Pour gérer la SSG on peut utiliser soit une application standalone, soit une applet s’exécutant dans un navigateur web. Chacun de ces modules d’administration sont basés sur une interface utilisateur graphique très intuitive et un support déclaratif dans la gestion des politiques, à l’exception des expressions régulières, les schémas XML, et autres détailles. Elle permet la gestion en temps réel monitoring et e tableau de bord,
Interopérabilité et extensibilité: On compte sur un ample éventail de standards SOA pour assurer l’interopérabilité de la plateforme. Dans ce contexte on a toute la pile des standards des services web (HTTP, XML, SOAP, WSDL et UDDI). Les standards complémentaires Security, Policy, Trust, SecureConversation, WS-MetadataExchange, sont aussi supportés. Possibilité d’intégrer la SSG avec des systèmes externes et répandus dans le marché de SOA. Par exemple, on peut utiliser des fournisseurs d’identité Oracle Internet Directory, TivoliLDAP, Microsoft Active Directory et GenericLDAP. Il est aussi possible d’installer des politiques provenant d’autres éditeurs tels qu’Oracle COREid Protected Resource, Sun Java System Access manager Protected Resource, Symantec Virus Scanning, etc.
Réplication et répartition de charge: La SSG peut être configurée en mode cluster dans lequel on peut avoir plusieurs nœuds SSG partageant les politiques de services, les fournisseurs identités et les paramètres d’administration. Cette configuration se base sur le déploiement d’unLoad Balancer.
115
7
Conclusions
La partie théorique de ce travail est le fruit d’une étude approfondie et sérieuse sur les concepts élémentaires et plus au moins avancés de trois sujets importants de SOA, à savoir le développement orienté service, l’architecture SOA et la gouvernance SOA. Cette partie est sans doute celle qui a permit à l’auteur d’avancer d’une manière méthodique dans un sujet complexe et vaste comme celui de la gouvernance SOA. En effet, dans mon opinion personnelle il serait très difficile de comprendre l’art de la gouvernance si l’on ignore les caractéristiques de conception des services SOA. Ces propriétés de base, qui sont le faible couplage, le contrat de service, la composition, la réutilisation, l’autonomie, l’absence d’état, la localisation et l’abstraction, donnent une idée précise de la nature de ces composants software. Pour les managers, architectes, et autres participants de la gouvernance SOA, il s’agit de conserver ces propriétés tout au long du cycle de vie des services. Par exemple, chaque décision de gouvernance Design-Time doit tenir compte du fait que les services SOA sont réutilisables et, par conséquent, on ne devrait pas engager un projet de développement jusqu’à être sûr qu’il n’y a pas autre service équivalent.
Un autre aspect révélateur en matière de gouvernance est celui des modèles de services. Ces derniers jouent des rôles temporels en fonction de leur contexte d’utilisation. Mais ils répondent aussi à un modèle de service bien précis qui est souvent lié à la logique sous-jacente (métier, applicative, etc.) qu’ils implémentent. Connaître la différence existante entre ces différents types de services (Processus, Métier, Application) est un atout non négligeable qui permet de se faire une meilleure idée sur la nature de l’inventaire de service SOA d’une entreprise. Ils permettent aussi d’avoir une image logique de la disposition de l’architecture, notamment sa disposition en couches de services d’application, services métier et services de processus. Un service de processus a des caractéristiques particulières qui diffèrent de celles d’un service métier ou d’application, comme le fait de posséder un état, jouer le rôle de contrôleur et modéliser le comportement d’un processus métier. Donc, les paramètres de risque, de performance et d’alignement stratégique ne sont pas les mêmes que pour les autres modèles de services.
Quelque soit l’objet de gouvernance, il est évident que les cadres métier et TI doivent avoir une idée globale de l’environnement concerné. Toute la section traitant les sujets de l’architecture SOA a permis de faire un grand survol sur les aspects logiques et physiques de SOA. Indépendamment de toute technologie, SOA représente la dernière génération des systèmes d’information dont la raison d’être est celle de doter les entreprises d’une architecture TI flexible, agile et interopérable. Dans le contexte actuel de globalisation des marchés et de haut niveau concurrentiel, l’agilité de SOA permettrait de devancer ses concurrents dans les stratégies comme la pénétration de nouveaux marchés. La promesse de flexibilité décrit explicitement combien les technologies précédentes se sont montrées difficilement adaptables aux nouvelles exigences métier. L’exemple typique est celui des
opérations de fusion et d’achats d’entreprise qui posent beaucoup de difficultés lors de l’intégration des systèmes d’information (coûts élevés d’intégration et de maintenance, etc.).
Cela n’est pas sensé arriver avec les architectures SOA car cette dernière est caractérisée par un grand potentiel de réutilisation et de configuration. A tout ceci s’ajoute l’interopérabilité des systèmes dans les contextes commerciaux comme le B2B. Grâce à l’utilisation intensive des standards technologiques l’architecture SOA garanti un niveau élevé d’interopérabilité qui est essentielle pour l’échange d’information entre les entreprises partenaires.
La gouvernance SOA n’est donc pas déliée des notions élémentaires mentionnées ci-dessus, au contraire, elle est caractérisée par un cycle de vie qui est à l’image de celui des services. En effet, les concepts de SOA et de gouvernance ne sont que les deux faces d’une même monnaie. Pendant que la première permet de concevoir une solution hautement modulable et flexible, la deuxième fait que cette solution puisse exister à long terme tout en lui permettant d’atteindre les objectifs de flexibilité, réutilisation et interopérabilité. Les phases de gouvernance Design-Time, Run-Time et Change-Time définissent donc le modèle de gouvernance SOA standard, implémenté par toutes les entreprises de ce marché. Pendant la phase deDesign-Time, les décideurs TI et métier se concentreront sur les aspects stratégiques comme les stratégies de développement (Top-down, Bottom-up ou mixte) à adopter, le modèle de maturité SOA, l’architecture de référence et la structure de gouvernance clarifiant les rôles et les responsabilités assignés à chaque partie prenantes. Chacun de ces éléments sont ensuite publiés et communiqués afin de fournir vision et direction à l’échelle du projet SOA.
Dans chacune des phases de la gouvernance on doit définir des politiques qui seront stockées dans le référentiel de services. Les politiques deDesign-Timedevront être implémentées pour guider le comportement des utilisateurs par rapport à la réutilisation des services existants, au développement basés sur les standards SOA et à la gestion minutieuse des artefacts qu’ils produisent (SLA, modèles de données, etc.). Les politiques de la phase de Run-Time permettent de contrôler le comportement des services et de protéger le fournisseur contre les menaces de sécurité en temps d’exécution. Celles-ci sont appliquées dynamiquement par un outil spécialisé jouant le rôle de point de renforcement de politiques (PEP) dont le but est d’exécuter les assertions de contrôle d’accès, d’authentification et autorisation, d’accord de niveau de service, d’audit et de sécurité.
Enfin, grâce à prototypee-dec Governanceon a pu tester une solution de gouvernance proche de la réalité qui a permis d’analyser plus profondément les aspects théoriques et pratiques de la gouvernance SOA. D’une part, on a réalisé dans quelle mesure un outil de gouvernance Run-Time doit être capable de résoudre les problèmes soulevés par SOA, tels que le silo d’identités, la gestion des PKI, la conformité des services aux lois (SOX) et standards de l’industrie. D’autre part, il a été possible de montrer la manière dont la SSG gère les risques et la performance des services, au même temps, que sa capacité à intégrer d’autres outils pour offrir une solution complète et efficace.
117
A
Artefacts
Dans cette annexe on a ajouté quelques fragments importants du contrat de service, comme la SLA, une image globale du WSDL et une présentation du fichier des politiques en format XML. Le but est de faciliter aux lecteurs la recherche des informations mentionnées tout au long de ce travail.
Tableau 7 : SLA du service web EdecImportService
7.1 Accord de niveau de service
7.2 Disponibilité 7.3 Le système doit présenter une disponibilité de 99,5 % (24 heures x 7 jours).
7.4 Fait exception à ce principe une fenêtre de maintenance de 2 heures par semaine. Les fenêtres de maintenance sont annoncées à l'avance.
7.5 Durée
d'indisponibilité (non planifiée)
7.6 Après un redémarrage, le service doit être de nouveau disponible dans un délai de 5 minutes
7.7 Temps de réponse (temps de latence)
7.8 Charge normale: 95 % en dessous de 10 secondes, 99 % en dessous de 15 secondes
7.9 Charge extrême: 95 % en dessous de 20 secondes, 99 % en dessous de 60 secondes
7.10 Déclarations en douane d'importation: le temps de réponse correspond à l'intervalle entre le moment où la déclaration arrive dans le système et le moment où la réponse quitte le système.
Le temps de transmission par le réseau public n'est pas pris en considération.
7.11 Débit 7.12 Charge normale: jusqu'à 20 déclarations par minute.
7.13 Charge extrême: à partir de 170 déclarations environ par minute.
Figure 46: Vue globale de l'interface WSDL
Figure 47 : Vue globale du fichier EdecImportService Policy.xml
120
B
Installation et Configuration
Figure 48 : SSG_32bit_VirtualAppliance_v43
Configurer les paramètres de réseau de la SecureSpan Gateway V4.3 en suivant les instructions affichées au menu de la console. Pour plus de détailles veuillez lire le paragraphe de la configuration réseau ci-après.
Pour simplifier le déploiement on s’est limitée à déployer la SSG en mode standalone, contrairement au mode cluster. Donc, une fois avoir réglé les paramètres de réseau choisissez dans le menu l’option 5 pour appliquer les changements effectués. Ensuite, choisissez l’option 2 pour installer une instance de la SSG. Pour plus de détailles veuillez lire le paragraphe de configuration de la SSG ci-après.
A l’aide d’un navigateur web (Mozillla Firefox ou Internet Explorer) accédez au gestionnaire de la SSG au tapant comme URL les adresses suivantes:
o https://<ssghostname>:8443/ssg/soap -> Authentification mutuelle.
o https://<ssghostname>:9443/ssg/soap -> Authentification serveur seulement.
Configuration réseau
Pour configurer correctement cette étape la SSG offre deux options, à savoir un serveur DHCP et une configuration statique. Dans le cas de ce prototype, on a testé les deux configurations et on a préféré l’option statique car avec le serveur DHCP on a rencontré des difficultés dans la résolution de l’URL depuis le navigateur web. Après avoir choisi l’option statique et l’interface réseau (eth0) veuillez vérifier qu’il existe une entrée dans le fichier etc/hosts. Pour ce faire, suivez les indications suivantes:
Faire un login en tant qu’utilisateurrooten choisissant l’option 3.
Tapez la commande (nano /etc/hosts). Si l’on constate qu’il n y a pas d’entrée correspondant à la SSG que l’on vient de configurer, veuillez ajouter les lignes comme dans la figure ci-dessous. Les adresses IP et les noms d’hôte peuvent être différents de ceux présents dans cette configuration pour s’adapter aux propriétés locales du réseau en question.
Figure 49 : Fichier hosts du serveur linux
Jusqu’ici cela devrait être suffisant pour configurer le réseau de la SSG. Cependant, si vous rencontrez un problème de communication entre le navigateur web et la SSG, on recommande de vérifier le fichier hosts de Windows xp est d’y ajouter les mêmes lignes que dans le fichier/etc/hosts.
Configuration de la SSG
En général, si les étapes de la configuration réseau se sont terminées avec succès il n’y a pas des problèmes particuliers lors de la configuration de la SSG. On peut donc se limiter à consulter le manuel d’installation dont une copie a été ajoutée au CD-Rom.
Cependant, pour pouvoir utiliser le prototypee-dec Governancevotre système doit satisfaire les conditions suivantes :
Importer le certificat ADMIN-CA-T01 dans le Trust store de la SSG et cocher l’option Signing client certificatesdans l’assistant d’importation de certificats. Importer aussi le certificat client. Voir la sectionWorkflow using an X.509 Certificatedans la page 321 du documentSecureSpan Manger User Manual.
Créer un fournisseur d’identité fédéré avec les attributs suivants : o Provider Name: Transitaires.
o Credentials Source: X.509 Certificate.
Ajouter un utilisateur fédéré avec les attributs suivants : o Username: poveda
o X509 Subject Name: CN=Test Spediteur Poveda CP7BJT, OU=Anwendungen, OU=Weisse Seiten, O=admin, C=CH.
o Importer le certificat client depuis le trust store ou depuis un fichier PKCS#12.
Pour établir la confiance entre la SSG et le serveur e-dec et permettre que la politique de routage fonctionne correctement, importez le certificat du serveur. Pour ce faire, il faut suivre les étapes de la sectionAdd Certificate Wizarddans la page 328 du documentSecureSpan Manger User Manual.
Après avoir terminés les étapes décrites auparavant, il ne reste qu’à importer les politiques d’EdecImportService. Pour ce faire :
Publier le service en suivant les étapes du chapitre 4Publishing a SOAP Web Service du documentSecureSpan Manager User Manual.
Importer dans le gestionnaire SSG le fichier EdecImportService Policy.xml fourni dans le CD-Rom. Ensuite, il ne reste qu’à tester l’exécution des politiques d’EdecImportService.
On devrait voir s’afficher les politiques de la figure ci-après.
Figure 50 : Politiques d'EdecImportService.
Avant d’exécuter les requêtes vers la SSG vérifiez que la clé privée utilisée dans la politique de routage est celle appartenant au transitaire. Faire de même avec la clef utilisée sur le port 8443 de la SSG de sorte que celle-ci soit la clef privée de la SSG. Pour plus d’informations veuillez consulter les sectionsManaging Private Keysdans la page 338 etManaging Listen Portsdans la page 24 respectivement.
123
C
CD-Rom
Le CD-Rom ci-joint contient les outils et la documentation utilisés dans le développement du prototype e-dec Governance. La Figure 51 montre la structure du CD-Rom ainsi que les différents éléments livrés pour les utilisateurs.
Figure 51: Structure du CD-Rom
Les détails concernant chaque dossier sont présentés dans les tableaux ci-après.
Tableau 8: Contenu du dossier EdecImportService
ADMIN-CA-T01 ADMINCA-Class2 EdecImportService_v_1_0 TestSpediteurPovedaCP7BJT-SN15695
Autorité de certification du certificat client
Autorité de certification du certificat serveur
Interface de description du service
Certificat client
Tableau 9 : Contenu du dossier SoapUI
edecImportFull.xml edecWS-soapui_2-project.xml soapUI-2.0.2-installer
Déclaration d’importation pour le Spediteur Poveda
Projet soapUI contenant le requête utilisée pour tester les politiques.
Fichier d’installation de soapUI.
Tableau 10: Contenu du dossier Virtual SecureSpan Gateway 4.3
EdecImportService Policy.xml
University_Fribourg_6mth_v4 SSG_4.3_base_appliance_32bit SSM_User_Manua l_v4.4
Fichier des politiques Licence d’utilisation Image SSG compressée Mode d’emploi
124
[Abou khaled and Mugellini 2007]Web Services. Cours Web Engineering, Ecole d'ingénieurs de Fribourg, Suisse, 2007.
[AFD 2003]Faits et chiffres 2003. from
http://www.ezv.admin.ch/dokumentation/01854/01856/01870/index.html?lang=fr.
Retrieved 14.01.2008.
[AFD 2007]Faits et chiffres 2007. from
http://www.ezv.admin.ch/dokumentation/01854/01856/index.html?lang=fr. Retrieved 14.01.2008.
[Arch2Arch 2006a]SOA Practitioners Guide-Part 1: Why Services-Oriented Architecture.
fromhttp://dev2dev.bea.com/pub/a/2006/09/soa-practitioners-guide.html. Retrieved 19.08.2007.
[Arch2Arch 2006b]SOA Practitioners Guide-Part 2: SOA Reference Architecture. from http://dev2dev.bea.com/pub/a/2006/09/soa-practitioners-guide.html. Retrieved 19.08.2007.
[Arch2Arch 2006c]SOA Practitioners Guide-Part 3: Introduction to Services Lifecycle.
fromhttp://dev2dev.bea.com/pub/a/2006/09/soa-practitioners-guide.html. Retrieved 19.08.2007.
[Blanc 2007]La grande question de la gouvernancefrom
http://www.directioninformatique.com/DI/client/fr/DirectionInformatique/Nouvelles.a sp?id=43073. Retrieved 06.02.2008.
[Bloomberg 2004]SOA Governance: Reengineering IT Governance. zapthink
fromhttp://www.zapthink.com/report.html?id=ZAPFLASH-10272004. Retrieved 01.05.2008.
[Brown 2007]Succeeding with SOA: Realizing Business Value Through Total Architecture, Addison-Wesley Professional, 2007.
[Descloux 2004]Sécurité informatique. Cours de bachelor, Faculté de SES de l'Univesité de Fribourg, Suisse, 2004.
[Erl 2005]Service-Oriented Architecture: Concepts, Technology, and Design. Indiana, Prentice Hall PTR, 2005.
[Erl 2007]SOA Principles of Service Design (The Prentice Hall Service-Oriented Computing Series from Thomas Erl). Indiana, Prentice Hall PTR, 2007.
[Georgel 2005]IT Business Foundation (ITBF), Analyse du concept ITBF à l'origine de la gouvernance des systèmes d'information. 2005
[Gilardi 2006]Les analyses de gouvernement d'entreprise dans la pratique, CENTRE INFO SA, Fribourg, Suisse, 2006.
[High, Kinder, et al. 2005]IBM SOA Foundation: An architectural introduction and overview. ws-soa-whitepaper version 1.0. from
http://www.ibm.com/developerworks/webservices/library/ws-soa-whitepaper/#download. Retrieved 20.05.2008.
[Hoernes and Schwarb 2007]SOA Governance: Design-time, Change-time, Run-time, Bern, 2007.
[Hüsemann and Rischbeck 2007]Contrat de service d'EdectImportService. Office fédéral de l'informatique et de la télécommunication (OFIT), from
http://www.ezv.admin.ch/themen/00476/00494/01721/index.html?lang=fr. Retrieved 01.04.2007.
[Innotvation Process Technology 2008]SOA Case Study e-dec - electronic customs declaration, Bern, 2008.
[Isakov and Ledentu 2005]Gouvernance d'entreprise, Université de Fribourg, Suisse, 2005.
[IT Governance Institute 2003]Board Briefieng on IT Governance. 2 edition. from
http://www.itgi.org/AMTemplate.cfm?Section=Board_Briefing_on_IT_Governance&
Template=/ContentManagement/ContentDisplay.cfm&ContentID=39649. Retrieved 10.05.08.
[Josuttis 2007]SOA in Practice The Art of Distributed System Design, O'Reilly, 2007.
[Laudon, K. and J. Laudon 2001]Les systèmes d'information de gestion, Village Mondial / Pearson Education France, 2001.
[Layer 7 Technologies Inc 2006]Runtime SOA Governancefrom
http://www.layer7tech.com/library/page.html?id=39#wp. Retrieved 10.05.2008.
[Macfarlane and Rudd 2006]Gestion des Services liés aux technologies de l'information (ITSM) : Un guide à l'ITIL, itSMF Ltd, 2006.
[Maurer, Matlus, et al. 2000 ]A Guide to Successful SLA Development and Management.
2000
[Mitra 2005]A case of soa governance. IBM developers Works from
http://www.ibm.com/developerworks/webservices/library/ws-soa-govern/. Retrieved 01.05.2008.
[North 2007]Forrester Consulting. Companion Guide To Software AG’s
SOA Value Assessment. fromhttp://www.softwareag.com/Corporate/res/value/default.asp.
Retrieved 20.01.2008.
[numeraladvance 2008]L'ISO 12207- Le référentiel du cycle de vie d'un développemet logiciel. from
http://www.numeraladvance.com/Role_des_Normes/Normes_pour_SI/ISO_12207.ht m. Retrieved 10.03.2008.
[OFIT 2007]e-dec aktueller Stand und zukünftige Entwicklung, Bern, 2007.
[Organisation Internationale de normalisation 2008]Ingénierie des systèmes et du logiciel - Processus du cycle de vie du logiciel. from
http://www.iso.org/iso/fr/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=
43447. Retrieved 10.03.2008.
[Pulier and Taylor 2006]Understanding Enterprise SOA. Greenwich, Germany, Manning, 2006.
[Remenyi 2006]Proceedings of the 6th European Conference on e-Government. A. C.
International. Philipps-Universität Marburg, Germany.
[Ritu and Latha 2008]Policy-Driven Mobile Ad-Hoc Management, Wiley-InterScience,
[Ritu and Latha 2008]Policy-Driven Mobile Ad-Hoc Management, Wiley-InterScience,