WebSphere Enterprise Service Bus, Version 6.2.0 Systèmes d'exploitation: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Mise en place de la sécurité de bout en bout

Il existe de nombreux modèles de sécurité de bout en bout. Chacun d'entre eux peut comporter des étapes de configuration très différentes. Plusieurs scénarios type, avec les options de sécurité nécessaires, sont présentés.

Avant de commencer

Ces scénarios supposent tous que la sécurité administrative est activée.
Procédure
  1. Déterminez lequel des exemples présentés dans cette section correspond le mieux à vos besoins en sécurité. Dans certains cas, vos besoins impliquent le recours à une combinaison d'informations issues de plusieurs de ces scénarios.
  2. Prenez connaissance des informations relatives à la sécurité de chaque scénario et appliquez-les à votre situation.

Exemple

Demande entrante de service Web

Dans ce scénario, un client de services Web appelle un composant WebSphere Process Server. La demande transite par plusieurs composants de l'environnement WebSphere Process Server avant d'être transmise à un EIS via un adaptateur.

Le schéma représente une demande de service Web à WebSphere Enterprise Service Bus.

Vous pouvez authentifier le client de services Web comme étant un client SSL, en utilisant une authentification HTTP de base ou une authentification WS-Security. Lorsque le client est authentifié, le contrôle d'accès est appliqué en définissant le qualifiant SecurityPermission. Entre le client et l'instance WebSphere Process Server, vous pouvez sécuriser l'intégrité et la confidentialité des données à l'aide de SSL ou WS-Security. SSL sécurise le circuit complet, alors que WS-Security vous permet de ne chiffrer ou signer numériquement que certaines parties du message SOAP. Pour les services Web, WS-Security est à privilégier.

Demande entrante de service Web

Dans ce scénario, la demande entrante peut provenir d'un adaptateur, d'un client de services Web ou d'un client HTTP. Un composant de WebSphere ESB (par exemple un composant de flux de médiation) appelle un service Web externe.

Le schéma représente une demande de service Web émise par WebSphere Enterprise Service Bus.

Comme dans le cas de la demande entrante de service Web, vous pouvez vous authentifier au service Web externe comme client SSL, en utilisant une authentification HTTP de base ou une authentification WS-Security. Utilisez LTPACallBackHandler comme mécanisme de rappel pour extraire le usernameToken du sujet RunAs en cours. Pour sécuriser la confidentialité et l'intégrité des données entre WebSphere Process Server et le service Web cible, vous pouvez utiliser WS-Security.

Demande entrante Application Web - HTTP vers WebSphere Process Server

WebSphere Process Server prend en charge trois types d'authentification pour HTTP :
  • authentification HTTP de base
  • authentification HTTP par formulaires
  • authentification du client basée sur SSL (HTTPS).
En outre, pour protéger votre intranet de toute intrusion, vous pouvez placer le serveur Web dans la zone démilitarisée (DMZ) et WebSphere Process Server à l'intérieur du pare-feu interne. Dans cet exemple, WebSEAL est le proxy inverse qui procède à l'authentification. Il est dans une relation de confiance avec WebSphere Process Server derrière le pare-feu et peut réacheminer les demandes authentifiées.
Le schéma représente une application Web qui envoie une demande HTTP (entrante) à WebSphere Enterprise Service Bus.

task Rubrique relative à une tâche

Conditions d'utilisation | Commentaires en retour


Icône d'horodatage Dernière mise à jour: 07 juillet 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/tsec_endtoend.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
Ce centre d'information est mis en service par la technologie Eclipse (http://www.eclipse.org).