La passerelle SecureSpan Gateway (SSG) est une solution SOA intégrée permettant à la fois de protéger les services web utilisés depuis l’extérieur et d’implémenter les politiques de gouvernance appliquées en temps d’exécution. Dans le domaine de la protection d’applications et des services web, SSG permet de définir un certain nombre depolitiques de
sécurité permettant de garantir les services de confidentialité, intégrité, authentification et autorisation. En effet, cette passerelle fournit les moyens nécessaires pour définir les politiques de contrôle d’accès qui seront appliquées àEdecImportServicelorsque celui-ci sera sollicité par les différents transitaires. Parmi ces politiques de contrôle d’accès on trouve plusieurs variantes d’authentification et d’autorisation qui couvrent la plupart des stratégies existantes, comme les mécanismes d’authentification au niveau de la couche de transport (HTTP basic, digest and certificate) et au niveau de la couche de messages (WS-Security, SAML and XML Security).
Figure 42 : Les différentes catégories de politiques implémentées dans la passerelle SSG.
Comme on peut le constater dans la Figure 42, la passerelle SSG ne se limite pas aux aspects d’authentification. Elle permet aussi de définir d’autres types de politiques de gouvernance, telle que les contraintes de niveaux de service et de traitement de message. En effet, le contrat de service (SLA) existant entre EdecImportService et les transitaires est implémenté dans cette passerelle au même temps que les politiques de sécurité mentionnées ci-dessus. De cette façon on peut garantir aux différents clients (transitaires) que le service web EdecImportServicese comporte en conformité aux paramètres de niveaux de services. Dans le cas des messages, SSG supporte plusieurs mécanismes de traitement de messages XML tels que la validation, l’inspection de contenu, le traitement XSLT et le routage des requêtes et réponses.
Chacune des politiques mentionnées ci-dessus sont appliquées en temps d’exécution par la passerelle SSG. En effet, cette dernière fonctionne comme un « Policy Enforcement Point » (La phase de « Run-Time ») qui contrôle le trafic des messages (requêtes et réponses) pour garantir leur conformité vis-à-vis des politiques prédéfinies. SSG représente dans le rôle d’intermédiaire, le seul point d’accès au service EdecImportService par lequel transitent les requêtes et les réponses échangées avec les transitaires. Dans la Figure 43 on montre un exemple de configuration de politiques déployée à l’aide de SSG. Il s’agit d’un ensemble de contraintes imposant aux clients du service web protégé (EdecImportService) d’utiliser comme point d’entrée un canal SSL. Pour que l’utilisateur soit authentifié auprès de la passerelle il doit fournir son nom d’utilisateur et le mot de passe envoyé avec le mode HTTP Digest. Ensuite, la requête doit passer par une structure logique définie par trois opérateurs propres au standard WS-Policy (ALL, ExactlyOne, OneOrMore). Dans ce cas on peut constater que pour que la requête soit validée il faut qu’elle passe l’un des deux groupes d’assertions contenues dans l’opérateur OneOrMore (At least one assertion must evaluate to true). Si la requête passe l’un des ces groupes, elle est alors routée vers un point terminal spécifique.
Figure 43 : Policy Enforcement sur les requêtes envoyées àEdecImportService
La passerelle SSG fonctionne aussi comme un point d’intégration d’applications et des services déployés dans différents domaines de sécurité. Dans ce cas, il devient une extension des infrastructures de clés publiques (PKI) avec la capacité de signer et de délivrer des certificats. Elle assure aussi la fédération des identités et le service d’authentification unique (Single Sign-on) en prenant en charge la transmission des assertions d’authentification et autorisations de type SAML.
6.4.1 Le fonctionnement de SSG Manager
Le dernier composant utilisé dans la couche intermédiaire est le module de gestion de la passerelle SSG. Ce module existe en deux variantes, l’une sous forme d’application de bureau entièrement indépendante et l’autre sous la forme d’une applet accessible via un navigateur web qui est celle utilisée dans ce prototype. Du point de vue de la gouvernance SOA, le gestionnaire SSG permet d’accomplir plusieurs activités relatives à la gouvernanceRun-Time, à savoir la gestion interne ou fédérée des identités, l’implémentation et validation des politiques, le monitoring des services et l’audit des événements.
Pour que la passerelle SSG soit activée pour un service donné, il faut que l’administrateur du système puisse accomplir quelques tâches propres au flux de travail proposé par ce module.
En principe, ce processus est composé des étapes suivantes : 1. Se connecter au SSG.
2. Gérer les fournisseurs d’identités pour s’assurer que les clients seront identifiés.
3. Publier le service web
4. Analyser les performances de la passerelle pour identifier les violations éventuelles.
Les deux premières étapes concernent l’authentification des utilisateurs de la passerelle et des clients du service web. Grâce aux fournisseurs d’identités, la passerelle compte sur toutes les informations nécessaires à l’identification et authentification de ces deux types d’utilisateurs.
La troisième étape doit être terminée avant d’associer une politique à un service web. En effet, en publiant le WSDL, SSG intègre par défaut une politique de routage vers le point terminal déclaré dans l’interface de description. La publication peut se faire de deux manières différents selon si l’on possède ou non le fichier de description (WSDL). Dans le premier cas, il suffit de communiquer l’URL du fichier et dans le deuxième cas il faut fournir les paramètres nécessaires pour accéder au WSDL localisé dans un registre UDDI externe. En plus de cela, on peut publier sous différents URL uniques un même WSDL et d’y associer des politiques spécifiques aux clients qui accèdent par ces différents points. Enfin, la dernière étape correspond à superviser le comportement des services en regardant de plus près les outils de monitoring proposé dans ce module.
Figure 44 : L'interface duDashboardcontenu dans le gestionnaire de SSG.
La Figure 44 est en effet une capture d’écran du Dashboardou tableau de bord proposé dans le gestionnaire de SSG. Cet outil permet de suivre en temps réel le comportement des services grâce à un ensemble d’indicateurs clés de performances comme le temps de réponse et le nombre de requêtes par seconde. Sous l’onglet « Selection » on mesure aussi les nombre des requêtes qui ne se sont pas conformé aux politiques (Policy Violation) ainsi que le nombre de requêtes dont le routage n’a pas fonctionné.
En plus des capacités de monitoring en temps réel, SSG conserve un historique des événements survenus dans la passerelle qui s’avère être un outil efficace pour l’audit des requêtes et des réponses. Il permet de suivre à partir d’une date donnée les requêtes et les réponses qui ont transité par la passerelle ainsi que les messages de log associés.
6.4.2 Support et conformité aux standards
Afin d’implémenter les différents types de politiques mentionnées ci-dessus, SSG s’appui sur deux standards WS-Policy et XACML 2.0. Le premier standard (WS-Policy) est une spécification permettant de communiquer d’une manière découplée les contraintes et capacités d’un service web. Tant les clients comme les fournisseurs peuvent profiter de WS-Policy pour déclarer leurs exigences de sécurité, transactionnelles ou d’autre type, sans besoin d’ajouter du code à l’implémentation du service. WS-Policy est un Framework indépendant qui est souvent considéré comme étant le troisième composant d’un contrat de service global (WSDL, SLA, WS-Policy). Il est tout d’abord suffisamment générique pour couvrir la plupart des domaines (sécurité, fiabilité, transaction, etc.) des services web pour ensuite se décliner en plusieurs spécifications, à savoir WS-PolicyAttachment (liaison WS-Policy et les ressources),
WS-PolicyAssertions (des assertions génériques) et WS-SecurityPolicy (des assertions spécifiques à la sécurité). Dans le contexte de la gouvernance SOA, le support des standards industriels est un facteur très important car il contribue largement à garantir l’interopérabilité de l’architecture SOA.
6.4.3 Intégration avec des outils de la gouvernance Design-Time
La SSG, telle qu’elle est utilisée dans ce prototype, n’a pas la capacité pour implémenter les cas d’utilisation typiques à la gouvernance Design-Time. Pour ce faire, on a besoin des systèmes de registre et de référentiels de services qui fournissent les fonctionnalités propres à la gouvernanceDesign-Time. Dans la versionVirtual Appliance utilisée dans ce prototype on a la possibilité d’intégrer celle-ci avec la plateforme de gouvernance, HP SOA Systinet Softwarede HP. Dans ce cas, la SSG continue à assurer les tâches d’une solution de gouvernance Run-Timeen implémentant les politiques de contrôle d’accès, de sécurité XML, de routage WS, etc. Tandis que la plateforme Systinet offre les capacités nécessaires de Design-Time, telles que le stockage et la validation des politiques, l’implémentation des processus de validation de l’architecture, contrôle de la conformité des services, la gestion des contrats et le catalogue des services.
La SSG admet aussi le rôle d’agent de gestion de service web (WSM) pour le compte deHP SOA Manager. Ce dernier est une plateforme de gestion SOA offrant une large palette de fonctionnalités avancées telles que la gestion de la performance, de la sécurité et des exceptions. Il sert aussi comme un point de renforcement de politiques qui peut être combiné avec la SSG dans une configurationAgent-Gateway.
Cette combinaison ressemble fortement au système de gestion de politiques présenté dans la section La phase de « Run-Time ». La solution de HP joue le rôle de point de décision qui stocke les politiques de Run-Time pour que la SSG puisse les appliquer lorsque les messages SOAP passent par cette dernière. Chaque politique définie dans la SSG peut être envoyée vers Systinetpour passer par une étape de validation et de conformité et ensuite être stockée dans le système registre-référentiel.