Configuration des communications sortantes CSIv2

Les options suivantes sont disponibles lors de la configuration du panneau des communications sortantes CSIv2 (Secure Interoperability Version 2).

Avant de commencer

L'expression communications sortantes fait référence à la configuration qui détermine le type d'authentification effectué pour les demandes sortantes destinées aux serveurs en aval. Plusieurs couches ou méthodes d'authentification peuvent survenir. La configuration de l'authentification des communications entrantes sur le serveur en aval doit prendre en charge au moins l'un des types d'authentification choisi dans la configuration de l'authentification des communications sortantes de ce serveur. Si aucun type d'authentification n'est pris en charge, la demande peut être envoyée avec le statut non authentifiée. Cette situation ne pose pas de problème de sécurité, l'environnement d'exécution de l'autorisation étant chargé d'empêcher l'accès aux ressources protégées. Toutefois, pour empêcher l'envoi d'un justificatif non authentifié, il est conseillé de définir l'une des couches d'authentification comme requise plutôt que prise en charge. Si un serveur en aval ne prend pas en charge l'authentification, lorsque celle-ci est requise, la demande de méthode ne peut pas être envoyée.

Pourquoi et quand exécuter cette tâche

Les options suivantes sont disponibles dans le panneau des communications sortantes CSIv2 (Secure Interoperability Version 2). Vous n'êtes pas obligé d'effectuer ces étapes suivant l'ordre indiqué. Ces étapes sont fournies pour vous présenter les différentes options de configuration des communications sortantes.

Procédure

Exemple

En général, la configuration de l'authentification des communications sortantes permet à un serveur en amont de communiquer avec un serveur en aval. Par ailleurs, la plupart du temps, le serveur en amont est un serveur de servlets et le serveur en aval, un serveur d'EJB (Enterprise JavaBeans). Sur un serveur de servlet, différents types d'authentification de client peuvent être choisis pour accéder au servlet, y compris le certificat client et l'authentification de base. Lorsque des données d'authentification de base sont reçues via une connexion par invite ou par formulaire, ces données sont généralement authentifiées pour créer un justificatif adapté au type de mécanisme pris en charge par le serveur, par exemple LTPA (Lightweight Third Party Authentication). Si LTPA est utilisé, le justificatif contient un jeton acheminable. Choisissez une authentification par couche de messages (BasicAuth) pour propager les justificatifs du client. Si le justificatif est créé à l'aide d'une connexion par certificat et que vous voulez éviter d'envoyer le certificat en aval, optez pour un envoi avec vérification d'identité.


Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_csiv2outbound
Nom du fichier : tsec_csiv2outbound.html