Configuration des protocoles de transport des communications entrantes

Avec cette configuration, vous pouvez définir un transport différent pour la sécurité des communications entrantes et des communications sortantes.

Avant de commencer

[AIX Solaris HP-UX Linux Windows][IBM i]Les transports entrants font référence aux types de port d'écoute et à leurs attributs qui sont ouverts pour la réception des demandes destinées à ce serveur. Les protocoles CSIv2 (Common Secure Interoperability Specification, Version 2) et Secure Authentication Service (SAS) peuvent tous deux configurer le transport.
Important : SAS est pris en charge uniquement sur les serveurs version 6.0.x et antérieure qui ont été fédérés dans une cellule version 6.1.
[z/OS]Les transports entrants font référence aux types de port d'écoute et à leurs attributs qui sont ouverts pour la réception des demandes destinées à ce serveur. Les protocoles CSIv2 (Common Secure Interoperability Specification, version 2) et z/OS Secure Authentication Service (z/SAS) peuvent tous deux configurer le transport.
Important : z/SAS est pris en charge uniquement sur les serveurs version 6.0.x et versions antérieures qui ont été fédérés dans une cellule version 6.1.
[AIX Solaris HP-UX Linux Windows][IBM i]Toutefois, ces deux protocoles se différencient de plusieurs manières :
  • CSIv2 est beaucoup plus souple que SAS, qui requiert SSL ; CSIv2 ne requiert pas SSL.
  • SAS, contrairement à CSIv2, ne prend pas en charge l'authentification par certificat client SSL.
  • CSIv2 peut nécessiter des connexions SSL, alors que SAS se contente de les prendre en charge.
  • SAS a toujours deux ports d'écoute ouverts : TCP/IP et SSL.
  • CSIv2 peut avoir un port d'écoute au minimum et trois ports d'écoute au maximum. Vous pouvez en ouvrir un pour TCP/IP seul ou pour quand SSL est requis. Vous pouvez ouvrir deux ports lorsque SSL est pris en charge et ouvrir trois ports lorsque SSL et l'authentification par certificat du client SSL est prise en charge.

[z/OS]CSIv2 est z/SAS prennent en charge presque toutes les mêmes fonctions. Le protocole CSIv2 a l'avantage de pouvoir interagir avec d'autres produits WebSphere Application Server et avec n'importe quelle autre plateforme qui le prend en charge.

Pourquoi et quand exécuter cette tâche

Suivez la procédure ci-après pour configurer les panneaux des transports entrants dans la console d'administration :

Procédure

  1. Cliquez surSécurité > Sécurité globale.
  2. Sous RMI/IIOP security, cliquez sur Communications entrantes CSIv2.
  3. Sous Transport, sélectionnez SSL requis. Vous pouvez choisir d'utiliser le protocole SSL (Secure Sockets Layer), TCP/IP ou les deux protocoles comme transport de communication entrante pris en charge par un serveur. Si vous indiquez TCP/IP,le serveur prend uniquement en charge TCP/IP et ne peut pas accepter les connexions SSL. Si vous indiquez que SSL est pris en charge, ce serveur peut prendre en charge les connexions TCP/IP ou SSL. Si vous indiquez que SSL est requis, tout serveur communiquant avec ce serveur doit utiliser SSL.
  4. Cliquez sur Appliquer.
  5. Modifiez éventuellement les ports d'écoute que vous avez configurés.
    Vous effectuez cette action dans un autre panneau, mais vous devez y réfléchir dès maintenant. La plupart des noeuds finaux sont gérés au même emplacement et n'apparaissent donc pas dans les sous-fenêtres des protocoles de transports entrants. La gestion des noeuds finaux sur un même emplacement permet de réduire les conflits dans votre configuration lorsque vous les affectez. Les noeuds finaux SSL se trouvent sur chaque serveur. Les noms de port suivants sont définis dans le panneau Noeuds finals et sont utilisés pour la sécurité des ORB (Object Request Broker) :
    • [AIX Solaris HP-UX Linux Windows][IBM i]CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS - Port SSL d'authentification des clients CSIv2
    • [AIX Solaris HP-UX Linux Windows][IBM i]CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS - Port SSL CSIv2
    • [AIX Solaris HP-UX Linux Windows][IBM i]SAS_SSL_SERVERAUTH_LISTENER_ADDRESS - Port SSL SAS
    • [z/OS]ORB_SSL_LISTENER_ADDRESS - Port SSL
    • [AIX Solaris HP-UX Linux Windows][IBM i]ORB_LISTENER_PORT - Port TCP/IP
    • [z/OS] ORB_LISTENER_ADDRESS - Port IIOP

    Pour un serveur d'applications, cliquez sur Serveurs > Serveurs d'applications > nom_serveur. Dans la section Communications, cliquez sur Ports. Le panneau Ports s'affiche pour le serveur indiqué.

    [AIX Solaris HP-UX Linux Windows]Pour un agent de noeud, accédez à Administration du système > Agents de noeud > nom_noeud. Dans le menu Propriétés supplémentaires, cliquez sur Ports. Le panneau Ports de l'agent de noeud et du gestionnaire de déploiement est déjà corrigé mais vous pouvez éventuellement réaffecter les ports. Pour le gestionnaire de déploiement, cliquez sur Administration du système > Gestionnaire de déploiement. Dans le menu Propriétés supplémentaires, cliquez sur Ports.

    L'ORB (Object Request Broker) de WebSphere Application Server emploie un port d'écoute pour les communications RMI/IIOP (Remote Method Invocation over the Internet Inter-ORB Protocol) et est indiqué de façon statique à l'aide de boîtes de dialogue de configuration ou pendant la migration. [z/OS]ORB_LISTENER_ADDRESS et BOOTSTRAP_ADDRESS doivent indiquer le même port. Si vous travaillez avec un pare-feu, vous devez associer un port statique au programme d'écoute ORB, port par lequel transiteront les communications. La valeur ORB_LISTENER_ADDRESS est associée à la propriété endPoint de définition du port d'écoute ORB.

    [AIX Solaris HP-UX Linux Windows][IBM i]Dans l'environnement WebSphere Application Server, Network Deployment, le noeud final ORB_LISTENER_ADDRESS est indiqué sur l'agent de noeud. Le démon du service de localisation et les piggybacks résident sur l'agent du noeud et sur le port d'écoute respectivement, ce qui oblige à définir un port préalablement. Vous devez aussi définir ORB_LISTENER_ADDRESS comme port d'écoute ORB des autres serveurs d'applications. Chaque ORB possède un port d'écoute distinct. Dans WebSphere Application Server, Network Deployment, il est nécessaire d'indiquer un port d'écoute différent. Voici, par exemple, les ports pouvant être spécifiés :
    • Agent de noeud : ORB_LISTENER_ADDRESS=9000
    • Serveur1 : ORB_LISTENER_ADDRESS=9811
    • Serveur2 : ORB_LISTENER_ADDRESS=9812
    [AIX Solaris HP-UX Linux Windows][IBM i]Les serveurs fédérés peuvent être exécutés sans que l'agent de noeud soit actif. Lorsque ORB_LISTENER_ADDRESS a une valeur supérieure ou égale à 0, le serveur ne dépend pas du démon du service de localisation pour rediriger les connexions vers le serveur. Lorsque vous définissez ORB_LISTENER_ADDRESS, toutes les références d'objet dans le même espace de noms indiquent la connexion au serveur et non le démon de localisation. Lorsque le serveur est exécuté sans l'agent de noeud, l'accès à toutes les applications doit s'effectuer par le biais du serveur de noms exécuté sur le serveur d'applications. Le client doit modifier la référence JNDI (Java™ Naming Directory Interface) afin que l'hôte et le port du serveur d'applications soient utilisés.
    Tableau 1. ORB_LISTENER_ADDRESS. Ce tableau décrit ORB_LISTENER_ADDRESS.
    ORB_LISTENER_ADDRESS  
    value = 0 Le serveur démarre sur n'importe quel port disponible et n'utilise pas le démon du service de localisation.
    value > 0 Le serveur démarre sur le port indiqué par la valeur entrée. Le démon du service de localisation n'est pas utilisé.
    Remarque : La gestion de la charge de travail peut ne pas fonctionner si l'agent de noeud n'est pas actif.

    [z/OS]Effectuez les opérations ci-dessous dans la console d'administration afin de spécifier le ou les ports ORB_LISTENER_ADDRESS.

    [AIX Solaris HP-UX Linux Windows][IBM i]Effectuez la procédure suivante pour l'agent du noeud ou le gestionnaire de déploiement.

    1. Cliquez sur Serveurs > Serveurs d'application > nom_serveur. Dans la section Communications, cliquez sur Ports > Nouveau.
    2. Sélectionnez ORB_LISTENER_ADDRESS dans la zone Nom du port de la fenêtre Configuration.
    3. [AIX Solaris HP-UX Linux Windows][IBM i]Dans la zone Hôte, entrez l'adresse IP, le nom complet de l'hôte DNS (Domain Name System) ou le nom de l'hôte DNS. Par exemple, si le nom d'hôte est monhôte, le nom DNS complet peut être monhôte.myco.com et l'adresse IP peut être 155.123.88.201.
    4. [z/OS]Entrez l'adresse IP ou "*" dans la zone Hôte. Par exemple, entrez 155.123.88.201.
      Important : Les noms d'hôte DNS ne sont pas pris en charge comme valeur ORB_LISTENER_ADDRESS.
    5. Entrez le numéro de port dans la zone Port. Indique le port pour lequel le service est configuré pour accepter les demandes du client. La valeur du port est utilisée avec le nom d'hôte. Dans l'exemple précédent, le numéro de port pourrait être 9000.
  6. [AIX Solaris HP-UX Linux Windows][IBM i]Cliquez surSécurité > Sécurité globale. Sous RMI/IIOP security, cliquez sur Communications entrantes CSIv2. Sélectionnez les paramètres SSL utilisés pour les demandes entrantes des clients CSIv2, puis cliquez sur Valider. Le protocole CSIv2 est utilisé pour la compatibilité avec les versions précédentes. Lors de la configuration des fichiers de clés et de clés certifiées dans la configuration SSL, ceux-ci doivent contenir les informations appropriées pour être compatibles avec les versions antérieures de WebSphere Application Server.
  7. [z/OS]Cliquez surSécurité > Sécurité globale. Sous Sécurité RMI/IIOP, cliquez sur Authentification z/SAS pour sélectionner les paramètres SSL utilisés pour les demandes entrantes des clients z/SAS.

Résultats

La configuration du transport des communications entrantes est terminée. Avec cette configuration, vous pouvez définir un transport différent pour la sécurité des communications entrantes et des communications sortantes. Par exemple, si le serveur d'applications est le premier serveur utilisé par les utilisateurs, la configuration de la sécurité peut être renforcée. Lorsque les demandes sont destinées aux serveurs de bean enterprise dorsaux, vous pouvez diminuer le niveau de sécurité des communications sortantes, pour améliorer les performances. Cette souplesse permet de concevoir des infrastructures de transport adaptées à vos besoins.

Que faire ensuite

Une fois la sécurité configurée, suivez la procédure ci-après pour sauvegarder, synchroniser et redémarrer les serveurs :
  1. Cliquez sur Sauvegarder dans la console d'administration pour sauvegarder les modifications apportées à la configuration.
  2. [AIX Solaris HP-UX Linux Windows]Synchronisez la configuration avec tous les agents de noeud.
  3. Arrêtez, puis redémarrez tous les serveurs, une fois qu'ils sont synchronisés.

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_inboundtransport
Nom du fichier : tsec_inboundtransport.html