De nombreuses fonctions d'IBM® HTTP Server V5.3 for z/OS sont disponibles dans IBM HTTP Server, mais implémentées différemment. Vous allez apprendre quelles sont les différences clés de la configuration de base entre les deux serveurs Web.
Les parties et chapitres correspondent aux parties et chapitres de la publication numéro SC34-4826-09 du manuel z/OS HTTP Server Planning, Install, and Using d'IBM HTTP Server V5.3 for z/OS.
IBM HTTP Server peut utiliser des fichiers statiques ou exécuter des fichiers script CGI. Ces fichiers peuvent se trouver dans des répertoires par défaut ou dans des répertoires que vous spécifiez. Vous pouvez utiliser divers directives pour ces fichiers. Utilisez la section Directory pour regrouper les directives et indiquer qu'elles s'appliquent à un répertoire particulier.
Les fichiers statiques se trouvent dans le répertoire install_root/htdocs par défaut. Vous pouvez indiquer un répertoire de remplacement dans la directive Alias afin de le mapper à un préfixe d'adresse Web. Vous pouvez ensuite créer ou copier une section Directory et la faire pointer vers le répertoire de remplacement. Par exemple, vous pouvez copier la directive Directory indiquant le répertoire par défaut install_root/htdocs et passer du répertoire par défaut au répertoire install_root/static.
Les scripts CGI s'exécutent à partir du répertoire install_root/cgi-bin/ par défaut. Vous pouvez indiquer un répertoire de remplacement sur la directive ScriptAlias pour mapper le répertoire de remplacement vers un préfixe d'adresse Web. Vous pouvez ensuite créer ou copier une section Directory et la faire pointer vers le répertoire de remplacement. Par exemple, vous pouvez copier la directive Directory indiquant le répertoire par défaut install_root/cgi-bin/ et passer du répertoire par défaut au répertoire install_root/cgi2.
Pour plus d'informations sur les directives, consultez la documentation sur Apache HTTP Server.
La directive DirectoryIndex étant définie sur index.html dans le fichier httpd.conf par défaut, IBM HTTP Server utilise le fichier d'index de répertoire index.html pour les demandes de répertoire. Vous pouvez définir la directive DirectoryIndex dans d'autres fichiers pour utiliser IBM HTTP Server. Vous pouvez également ajouter la directive Options avec l'argument Indexes à la section Directory existante ou à une nouvelle section Directory afin que le serveur Web renvoie des informations pour ce répertoire. Si vous incluez un signe + devant l'argument Indexes, la section Directory hérite d'arguments qui sont définis sur d'autres directives Options. Si aucune des directives DirectoryIndex et Options n'est définie, le serveur Web renvoie une erreur 403.
Pour plus d'informations sur les directives, consultez la documentation sur Apache HTTP Server.
Vous ne pouvez administrer IBM HTTP Server qu'en mettant à jour les fichiers de configuration EBCDIC.
Le fichier de configuration IBM HTTP Server par défaut est install_root/conf/httpd.conf. Si vous souhaitez revoir ou récupérer les valeurs par défaut définies, vous pouvez les consulter dans le fichier install_root/conf/httpd.conf.default.
Le gouvernement américain, ainsi que d'autres gouvernements, régulent les produits utilisés pour le chiffrement et interdisent leur exportation tant que la taille des clés n'est pas strictement limitée. Lorsque le gouvernement américain met à jour les lois sur l'exportation et que les autres gouvernements mettent à jour leurs lois sur l'importation, les longueurs de clé et les spécifications de chiffrement prises en charge peuvent changer.
IBM HTTP Server prend en charge les chiffrements SSL répertoriés dans la rubrique Spécifications de chiffrement SSL.
Vous pouvez utiliser le chiffrement du matériel pour améliorer la performance des sessions SSL entre le client et le serveur. Le plus important gain de performance pour le serveur est du à l'établissement de liaison SSL. L'établissement de liaison utilise des clés et des fonctions asymétriques. Le serveur Web utilise la technologie RSA pour implémenter la capacité d'asymétrie. Lorsque vous implémentez SSL sans chiffrement du matériel, les fonctions asymétriques sont beaucoup plus lentes que les fonctions symétriques. Par conséquent, lorsque vous implémentez le chiffrement du matériel avec le serveur Web, vérifiez que vos clés principales asymétriques sont correctement configurées. Utilisez le logiciel ICSF (Integrated Cryptographic Services Facility) pour pouvoir tirer avantage de l'augmentation des performances. Les clés principales asymétriques ne sont pas identiques aux clés RSA du serveur Web.
Les spécifications de chiffrement DES (Data Encryption Standard) et DES triple utilisent des clés asymétriques pour gérer la transmission de données. La transmission de données peut être plus rapide dans le matériel, ou pas. La meilleure rapidité de la transmission de données dans le matériel ou les logiciels dépend de la taille du flux de données. SSL doit envoyer des flux de données relativement petits, le plus souvent de 4 Ko ou moins. Les flux de données moins volumineux sont généralement plus rapides dans les logiciels. Les flux de taille moyenne peuvent être plus rapides dans le matériel ou les logiciels. Les flux très volumineux sont plus rapides dans le matériel.
Pour plus d'informations sur l'implémentation du chiffrement du matériel, consultez les manuels appropriés. Par exemple, consultez le manuel z/OS Processor Resource/Systems Management Planning Guide sur le portail de support IBM.. Vous pouvez également consulter les manuels z/OS Cryptographic Services ICSF Administrator's Guide et z/OS Cryptographic Services ICSF System Programmer's Guide, qui sont disponibles dans la bibliothèque Internet z/OS.
Pour activer TLS (Transport Layer Security), utilisez l'exemple d'hôte virtuel SSL dans le fichier conf/httpd.conf.default. L'exemple contient des éléments requis pour l'activation de TLS, notamment une directive Listen, la directive SSLEnable et un module mod_ibm_ssl.
Vous pouvez utiliser la directive SSLCipherSpec pour contrôler l'ordre des niveaux de chiffrement. IBM HTTP Server impose toujours l'ordre de préférence. Consultez la directive SSLCipherSpec dans la rubrique sur les directives SSL.
Aucune action de votre part n'est nécessaire pour cette étape car IBM HTTP Server charge par défaut les modules communs limitant l'accès aux ressources.
Utilisez des sections de configuration pour inclure des directives de configuration relatives au verrouillage. Consultez les sections sur la configuration dans la documentation Apache HTTP Server.
Pour les ressources du système hiérarchique de fichiers (HFS), utilisez les directives <Directory> et <DirectoryMatch> pour inclure des directives de protection. Pour les autres ressources ne se trouvant pas dans HFS, telles que celles utilisées par les plug-ins, utilisez les directives <Location> et <LocationMatch>.
Vous pouvez vérifier les mots de passe IBM HTTP Server par rapport aux fichiers de mots de passe utilisateur et groupe. Cependant, si vous souhaitez vérifier les mots de passe IBM HTTP Server par rapport au système local, spécifiez la directive AuthBasicProvider SAF. Si vous le souhaitez, vous pouvez modifier l'ID utilisateur SAF sous lequel une demande est utilisée en spécifiant la directive SAFRunAs.
Si vous souhaitez demander l'authentification de client SSL sur un hôte virtuel, spécifiez la directive SSLCLientAuth required. Utilisez la directive SSLClientAuthRequire pour spécifier des valeurs d'attribut, ou des groupes de valeurs d'attribut, qui doivent être validées par rapport à un certificat client pour que le serveur autorise l'accès à la ressource protégée.
Utilisez les exemples suivants pour vous aider à créer vos configurations de verrouillage :
Alias /my-app /opt/my-app/htdocs
<Directory /opt/my-app/htdocs>
# Allow requests that match the allow directives. Then, deny requests that match the deny directives.
# Then, deny requests that do not match the allow or deny directives.
Order allow,deny
# Allow access only to those users from the local host.
Allow from 127.0.0.1
</Directory>
<Directory /opt/my-app/htdocs/members-only>
Order allow,deny
Allow from 127.0.0.1
# Add HTTP basic authentication.
AuthType Basic
AuthBasicProvider file
AuthName "Login with your example.com user ID."
# Use the htpasswd utility in the <install_root>/bin/htpasswd file to maintain the passwords.
# Store the userid and password file in a directory other than the one that it is protecting.
AuthUserFile /opt/my-app/users.passwd
Require valid-user
</Directory>
<Directory /opt/my-app/htdocs/admin>
...
Require user administrator
</Directory>
<Directory /opt/my-app/htdocs/admin>
...
# text file with multiple group-name: member1 member2... lines
# Store the group file in a directory other than the one that it is protecting.
AuthzGroupFile /auth/groups
Require group admins
</Directory>
<Directory /opt/my-app/htdocs/admin>
...
Require group admins
Satisfy any
Order allow,deny
Allow from 127.0.0.1
</Directory>
Vous pouvez limiter les fichiers auxquels un utilisateur peut accéder en intégrant la directive <Files> ou la directive <FilesMatch> à la directive <Directory> ou à la directive <DirectoryMatch>.
Vous ne pouvez pas autoriser l'accès en fonction de la combinaison d'un nom d'utilisateur et d'une adresse, par exemple bob@192.168.1.1 et steve@192.168.2.2, sans inscrire votre propre module Apache pour l'autorisation.
Un fichier de groupe dans IBM HTTP Server n'est que le mappage d'un nom de groupe vers une liste d'utilisateurs. Il ne peut pas contenir de définitions imbriquées ou inclure des spécifications d'adresse.
IBM HTTP Server ne dispose pas de fichiers de liste de contrôle d'accès. Vous pouvez utiliser des fichiers .htaccess pour limiter l'accès aux ressources. Cependant, évitez d'utiliser ces fichiers si vous pouvez mettre à jour le fichier httpd.conf ; l'utilisation de fichiers .htaccess ralentissant votre serveur. Comme alternative, vous pouvez inclure des directives à une directive <Directory> et placer toutes les directives dans le fichier httpd.conf.