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]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
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]](../images/ngzos.gif)
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]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
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.
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
- Cliquez surSécurité > Sécurité globale.
- Sous RMI/IIOP security, cliquez sur Communications
entrantes CSIv2.
- 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.
- Cliquez sur Appliquer.
- Modifiez éventuellement les ports d'écoute que vous avez configurés.
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é.
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.
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]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
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]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
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.
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]](../images/dist.gif)
Effectuez la procédure suivante pour l'agent du noeud ou le gestionnaire de déploiement.
- Cliquez sur Serveurs > Serveurs d'application > nom_serveur.
Dans la section Communications, cliquez sur Ports > Nouveau.
- Sélectionnez ORB_LISTENER_ADDRESS dans la zone Nom du port
de la fenêtre Configuration.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
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.
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.
- 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.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
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.
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 :
- Cliquez sur Sauvegarder dans la console d'administration pour sauvegarder les modifications apportées à la configuration.
Synchronisez la configuration avec tous les agents de noeud.
- Arrêtez, puis redémarrez tous les serveurs, une fois qu'ils sont synchronisés.