La passerelle SSG est un outil de gestion et de gouvernance Run-Timepour les architectures orientée services. On va donc montrer comment on peut implémenter et renforcer les politiques de gouvernance Run-Time (PEP) dans le prototypee-dec Governance. Notons que pour faire de la gouvernance Design-Time il faut pouvoir intégrer la SSG avec des solutions complémentaires comme les systèmes de registres et référentiels de service fournis par des sociétés partenaires tels que les produits HP SOA Systinet Software,CentraSite de Software AG, etc.
6.5.1 Publication d’EdecImportService
La première décision à prendre en matière de gouvernance Run-Time est évidemment la publication du service. Pour utiliserEdecImportServicedepuis une application externe, il faut que le modèle de gouvernance SOA prévoie la manière dont le service sera exposé aux transitaires et clients de la douane. Dans ce contexte, SSG offre le choix entre générer une nouvelle interface WSDL et utiliser une interface existante publiée dans un registre UDDI ou dans un fichier local. Dans le cas d’EdecImportService on a opté pour la dernière option consistant à localiser le WSDL dans un fichier local.
Pour ce prototype, le choix d’un WSDL local n’a pas de répercutions importantes à différence d’un environnement réel de production. L’utilisation d’un WSDL local limite la flexibilité de SOA dans la mesure où elle empêche la réplication en temps réel des éventuels changements effectués sur l’interface du service. Du point de vue de la gouvernance SOA, une telle décision est importante car elle peut réduire le potentiel de l’architecture global, notamment sa flexibilité et agilité vis-à-vis des nouveaux changements.
Une remarque importante qui revient dans chaque cas d’utilisation est celle liée à la structure de gouvernance et aux différents rôles que celle-ci peut définir. Il fau dire que la SSG vient configurée avec un seul rôle qui est celui d’administrateur auquel on assigne tous les droits sur l’ensemble d’objets gérés. Donc, pour publier un service il faut que l’utilisateur soit dans un rôle adéquat tel que celui duService Managerou tout autre rôle équivalent.
Figure 45 : Les services web publiées dans la passerelle SSG.
Dans la Figure 45 on peut observer les services qui ont été publiés dans la passerelle SSG. Il s’agit d’EdecImportService et d’un service web non protégé proposé par le site web
www.amazon.fr. Le binding d’EdecImportService définit la liaison SOAP/HTTP pour la seule opération qui contient le service, à savoir submitEdecImport. Tandis que la partie
Services expose les points terminaux où se trouve EdecImportService. Une fois cette opération de publication terminée, les transitaires doivent configurer le point terminal du service pour qu’il pointe vers le point terminal où se trouve le service intermédiaire, en l’occurrence a passerelle SSG.
6.5.2 Les politiques d’accès pour EdecImportService
Pour qu’un client puisse accéder à EdecImportService il doit présenter un certificat client délivré par l’autorité d’identification de la plateforme « e-dec ». Ce certificat est présenté par soapUI lors de la phase d’authentification mutuelle avec le serveur SSL. En ajoutant un service intermédiaire tel que celui de la passerelle SSG, il devient plus difficile de satisfaire cette exigence car il faut garantir une sécuritéend-to-endet non paspoint-to-point.
Pour satisfaire cette exigence d’authentification il faut tout d’abord pouvoir authentifier et autoriser les transitaires auprès du service intermédiaire, en l’occurrence la passerelle SSG.
Pour ce faire, on a le choix entre utiliser un seul certificat client qui est celui délivré par l’autorité de certification AdminCA-CD-T01 et utiliser deux certificats clients, l’un pour l’authentification auprès de la SSG et l’autre pour la politique de routage HTTPS vers EdecImportService.
La première alternative a l’avantage d’être plus simple à mener car elle n’utilise qu’un seul certificat pour les deux canaux SSL ouvert entre le client soapUI et la SSG, ainsi qu’entre la SSG et la plateforme « e-dec ». Le désavantage de cette solution est qu’elle augmente les possibilités d’attaques man in the middleconsistant à intercepter la clef publique de l’une ou des deux parties. La deuxième alternative est plus sûre tout en répondant aux exigences de sécurité SSL mais beaucoup plus difficile à implémenter car elle demande une connaissance approfondies dans la gestion fédérées des identités.
Pour implémenter la politique d’accès àEdecImportServiceon doit procéder comme suit : 1. Le transitaire doit disposer d’un compte utilisateur dans un annuaire LDAP existant ou
dans la base de données MySQL gérée par la SSG. C’est cette dernière option que l’on a choisi pour le prototype.
2. Il faut aussi établir la relation de confiance avec les certificats qui seront utilisés. Dans ce cas, il faut que les transitaires acceptent le certificat de la SSG qui est signé par la passerelle elle-même jouant le rôle d’autorité de certification. Cette dernière doit à son tour faire de même avec les certificats des transitaires.
3. Enfin, il ne reste qu’à choisir l’assertion de contrôle d’accèsSSL with client certificate authentication.
Pour que cette politique soit validée sans problème il faut combiner l’assertion SSL avec une seconde assertionGrant Access to Users/Group» ouAthentication. Donc, dans sa forme finale la politique de contrôle d’accès est celle-ci :
SSL with Client Certificate Authentication Transitaire in Federated Internal Provider
Il est évidemment possible de définir plusieurs alternatives de contrôle d’accès en fonction du client avec qui on communique. Bien qu’EdecImportService ne l’exige pas on pourrait proposer une politique d’authentification différente pour des clients pour qui le SSL en mode mutuel ne serait pas nécessaire. Voici en quoi peut consister cette politique :
6.5.3 Les politiques de sécurité
Souvent, les environnements de production des services web vont au-delà de la sécurité au niveau du protocole de transport pour assurer une sécurité de messages SOAP. La justification d’une telle démarche, qui est aussi valable pour « e-dec », se réfère au fait que malgré l’utilisation d’un canal sécurisé SSL, rien n’empêche qu’il y ait une attaque interne, déclenché par un Backdoor lisant le contenu des déclarations d’importation après que celle-ci aient atteint leurs destination.
Dans tous les cas, les idées pour exploiter les vulnérabilités et les limites de SSL ne font pas défaut. Par exemple, malgré le service d’authentification de SSL rien n’empêche qu’un client mécontent essaie une attaque DoS en envoyant des déclarations trop lourdes avec plusieurs mégaoctets en attachements. Pour éviter ces types de surprises, la passerelle SSG offre la possibilité de définir des politiques de Firewall XML comme le fait de contrôler la validité des requêtes par rapport au schéma XML, contrôler les attachements SOAP en faisant appel aux modules Norton Antivirus que l’on peut intégrer au SSG, imposer l’utilisation de XML Signature et XML Encryption, etc.
Le service EdecImportService n’exige aucune sécurité au niveau des messages mais il serait quand même pertinent d’ajouter une assertion de typeValidate XML Schemapour être sûr que les requêtes des transitaires respectent bien le schéma référencé dans le WSDL. Cela permet de protéger EdecImportService contre les attaques de type XML Parameter Tampering et XDoS car le contrôle des valeurs de la déclaration d’importation permet de s’assurer que les paramètres XML n’ont pas été remplacés par des scripts malicieux ou que la structure même du message n’a pas été modifiée. Donc, la politique de sécurité XML pour « e-dec » serait la suivante:
SSL or TLS Transport
HTTP Basic or Digest or WSS UsernameToken Basic Transitaire in Identity Internal Provider
Validate XML Schema
6.5.4 L’implémentation du SLA
L’accord sur les niveaux de services de la plateforme « e-dec » n’a pas des restrictions particulières sauf la maintenance de 2 heures par semaine qui exige l’arrêt du service. Comme le service est sensé être disponible la plupart du temps il n’y a pas besoin de définir une assertion de disponibilité. Du point de vue technique, l’absence de ce type de disponibilité ne change rien à la manière dont la passerelle SSG se comporte car il n y a pas de restriction dans le temps et les requêtes vers « e-dec » ne seront jamais filtrées. Cependant, dans l’intérêt d’éviter toute confusion et de veiller au respect de l’accord SLA, on estime que le prototype e-dec Governancedoit implémenter explicitement la disponibilité du service.
Dans la description du SLA on peut lire que la charge normale se situe à l’hauteur de 20 déclarations par minute et qu’à partir de 170 déclarations par minute on considère que la charge est extrême. La passerelle SSG permet de limiter le nombre de requêtes par seconde pour un client, un groupe de clients, etc. Il est aussi possible de définir un maximum de requêtes concurrentes et de configurer SSG pour qu’il adapte sa réponse au cas où les restrictions de SLA seraient violées.
L’accord de niveaux de service pour « e-dec » est implémenté avec les assertions suivantes:
6.5.5 La logique de WS-Policy et les assertions
Chacune des politiques qui ont été développées dans ce prototype traduisent les contraintes d’interaction entre les transitaires et le service EdecImportService. Cependant, pour mieux contrôler le traitement de ces assertions, le standard WS-Policy met à disposition une série d’opérateurs logiques qui n’ont pas été utilisés jusqu’ici. Il s’agit des opérateurs ALL,
ExactlyOne et OneOrMore. Lorsque le premier opérateur est appliqué aux assertions qu’il contient, chacune de ces assertions doivent retourner la valeur « True » pour que la politique soit satisfaite. Le deuxième opérateur permet d’implémenter le cas opposé à l’opérateur ALL, c'est-à-dire, qu’une seule assertion doit être évaluée comme « True ». Dans le cas du troisième opérateur, au moins une assertion doit retourner vrai pour que la politique soit satisfaite.
Le prototype e-dec Governance fait aussi usage de ces opérateurs pour combiner les différentes assertions. Ce qui suit résume l’ensemble des assertions que conforment la politique de gouvernance pour le serviceEdecImportService:
Availability Time – 00:00:00 to 23:59:59 Availability Day of Week: Monday to Sunday Rate limit: average 1 msg/second per Authenticated
user (concurrency 170)
Dans la politique de gouvernance Run-Time d’EdecImportService on a utilisé les opérateurs logiquesAll etOneOrMore. L’opérateur de premier niveauAll assertions must be evaluate to True, englobe toutes les assertions utilisées dans cette politique. Tout d’abord on a placé l’exigence de transport SSL pour dire que l’accès au service web doit se faire par un canal SSL, quelque soit le client. Ensuite, l’opérateur At least one assertion must evaluate to true contient les assertions d’identification et authentification des clients. Grâce à ce deuxième niveau d’assertions, combinées avec l’opérateur OneOrMore, on peut couvrir l’ensemble d’alternatives d’authentification et d’identification de ce prototype. Au moins un transitaire doit être identifié et authentifié par la passerelle SSG pour que la politique soit satisfaite. Dans ce cas, on a déclaré deux clients, l’un qui représente un transitaire agrée de la plateforme «
e-<All assertions must evaluate to true/>
SSL or TLS Transport
< At least one assertion must evaluate to true/>
<All assertions must evaluate to true/>
SSL with Client Certificate Authentication
Poveda_Transitairein Federated Internal Provider />
< All assertions must evaluate to true
HTTP BasicorDigestorWSS UsernameToken Basic DLH_Transitaire in Identity Internal Provider
/>
/>
Validate XML Schema
Availability Time – 00:00:00 to 23:59:59 Availability Day of Week : Monday to Sunday
Rate limit: average 1 msg/second per Authenticated user (concurrency 170) Route to Https://e-dec-a.ssl.admin.ch/services/EdecImportService/V1
/>
dec » et l’autre un transitaire fictif qui n’a pas de certificat client mais possède un compte utilisateur qui lui permet d’envoyer des requêtes à titre d’essaie.
Après que la passerelle SSG est identifié l’un des deux clients, elle peut continuer à évaluer le reste des assertions. Les assertionsValidate XML Schema, Availability, Rate limit et Route to https, sont placées à la fin de l’assertion de premier niveau All assertions must evaluate to true pour dire qu’elles s’appliquent à tous les clients du service web. Dans le cas où l’une de ces assertions ne soit pas satisfaite c’est alors toute la politique qui échoue.
Bien que le service EdecImportService n’exige pas explicitement la conformité des formats des données aux standards industriels, on sait que SOA compte beaucoup sur l’utilisation des standards pour garantir l’interopérabilité. Dans le cadre de ce prototype on peut encore insérer une assertion globale pour dire que chaque requête doit respecter tel ou tel standard. Par exemple, on peut demander que les clients qui n’ont pas des certificats pour l’authentification et veulent tester leurs applications auprès d’EdecImportService, d’envoyer des requêtes conforme au standard WS-Security.