Ce serveur prend en charge trois niveaux d'authentification du client et deux types de contrôles d'accès fondés sur les informations contenues dans le certificat du client.
La directive SSLCLientAuth permet de définir le niveau d'authentification :
Si vous choisissez le niveau d'authentification required, le serveur sécurisé demande un certificat à tous les clients adressant une demande https. Le serveur valide les clients en recherchant la présence d'un certificat racine d'autorité d'accréditation digne de confiance dans leur base de données de clés locale. Il s'agit d'un certificat signé par une autorité d'accréditation déclarée comme autorité digne de confiance sur votre serveur.
Le serveur établit une connexion sécurisée si le client dispose d'un certificat valide. Il rejette la demande si le client dispose d'un certificat ayant expiré ou signé par une autorité d'accréditation non référencée comme autorité digne de confiance sur le serveur.
N'oubliez pas que l'authentification du client par protocole SSL accroît le trafic sur le réseau.
Si vous choisissez le niveau optional, le serveur demande un certificat de client. Si le client n'en fournit pas, une connexion sécurisée est tout de même établie. La demande est rejetée si le client fournit un certificat ayant expiré ou signé par une autorité d'accréditation non référencée comme autorité digne de confiance sur le serveur.
N'oubliez pas que l'authentification du client par protocole SSL accroît le trafic sur le réseau.
Si vous choisissez none, le serveur sécurisé ne demande pas de certificat aux clients.
Les directives SSLFakeBasicAuth ou SSLClientAuthRequire permettent de définir le type de contrôle d'accès.
Remarque : SSLClientAuthRequire est le type privilégié d'authentification du client.
Il n'est pas conseillé d'utiliser SSLFakeBasicAuth. Les fichiers de mots de passe ayant été générés en vue d'être utilisés avec le code SSL d'Apache (ou mod_ssl et Apache) ne fonctionnent pas avec IBM HTTP Server, car le format du nom distinctif (DN) est différent.
Le type SSLFakeBasicAuth est une méthode simpliste d'authentification du client. Si vous indiquez SSLFakeBasicAuth, le nom distinctif du certificat du client et le mot de passe (qui est "password") sont codés sur 64 bits (Base64) et placés dans l'en-tête d'autorisation. Le module mod_ibm_ssl doit apparaître en premier dans la liste des modules afin que les modules d'authentification suivants puissent disposer du mot de passe et de l'ID utilisateur d'authentification de base factices. Soyez conscient du fait que l'authentification de base au sein d'un hôte virtuel spécifié ne fonctionne pas, car l'ID utilisateur et le mot de passe fournis par un utilisateur sont remplacés par le nom distinctif du client et son mot de passe (qui est "password").
Pour afficher le nom distinctif d'un certificat de client, créez un programme CGI chargé d'extraire la variable d'environnement SSL_CLIENT_DN.
Le support plus étendu de la directive SSLClientAuthRequire permet à l'administrateur du site (webmestre) de définir des expressions logiques contenant les attributs x509. Ces expressions logiques sont comparées aux informations du certificat du client en vue de déterminer si l'accès à un objet doit lui être accordé ou refusé. Cependant, avant que l'ensemble de ce traitement puisse avoir lieu, GSK valide le certificat du client afin de s'assurer qu'il est signé par une autorité d'accréditation digne de confiance.
La directive SSLClientAuthRequire permet à un webmestre de créer une expression logique composée de contrôles d'attributs reliés par des opérateurs booléens AND, OR et NOT. Les parenthèses sont également autorisées. Par exemple :
SSLClientAuthRequire (CommonName = "Pierre Montel" OR CommonName = "Jean Lacroix") AND Org = IBMsignifie que l'objet est servi uniquement si le certificat du client contient le nom usuel Pierre Montel ou Jean Lacroix et que l'entreprise est IBM.
Pour les contrôles d'attributs, les seuls opérateurs de comparaison admis sont l'égalité (=) et la différence (!=). Les différents contrôles peuvent être liés entre eux par des opérateurs booléens AND, OR et NOT (qui peuvent aussi être spécifiés sous la forme &&, || et !). Lorsque plusieurs directives SSLClientAuthRequire sont spécifiées pour une ressource, l'effet est le même que si les valeurs étaient jointes par des opérateurs booléens AND.
Les parenthèses peuvent être utilisées pour regrouper des comparaisons. Si la valeur d'un attribut contient un caractère non alphanumérique, elle doit être délimitée par des guillemets.
Les attributs valides sont les suivants :
IssuerStateOrProvince IssuerCommonName IssuerOrgUnit IssuerCountry IssuerLocality IssuerOrg IssuerEmail StateOrProvince CommonName OrgUnit Country Locality Org Email
Les abréviations suivantes sont également valides :
IST, ICN, IOU, IC, IL, IO, IE, ST, CN, OU, C, L, O, E