L'outil module d'autorisation PAC-LDAP permet au Caching Proxy d'accéder à un serveur LDAP (Lightweight Directory Access Protocol) quand il exécute des routines d'autorisation ou d'authentification. Le module est constitué de deux jeux de composants : d'une part, deux bibliothèques partagées qui dotent l'API Caching Proxy des fonctionnalités LDAP, et, d'autre part, un démon PAC (Policy Authentication Control). Le fichier ibmproxy.conf contient la directive ServerInit qui donne l'instruction à la bibliothèque partagée d'initialiser un ou plusieurs démons PAC lors du démarrage de Caching Proxy. Les bibliothèques partagées lisent le fichier paccp.conf pour déterminer le nombre et les caractéristiques des démons PAC. Lors de l'initialisation, le démon recherche les directives de configuration dans le fichier pac.conf et les informations de stratégie de sécurité dans le fichier pacpolicy.conf. Ensuite, soit la directive Authentication du fichier ibmproxy.conf donne instruction au serveur proxy d'appeler la bibliothèque partagée lorsque une authentification est nécessaire, soit une directive Authorization prend le contrôle du flux des travaux de Caching Proxy lors du traitement des demandes HTTP standard.
Le processus d'authentification détermine si l'ensemble de justificatifs fourni – nom utilisateur et mot de passe – est valide. Ce processus vérifie entre autre qu'un utilisateur se trouve dans le registre et que le mot de passe indiqué correspond au mot de passe stocké dans le registre. Les opérations effectuées avec le module PAC-LDAP lors de l'étape d'authentification sont répertoriées ci-après.
Lorsque l'authentification est possible sur le module d'autorisation PAC-LDAP, ce dernier devient le référentiel d'où sont extraits par défaut les identificateurs utilisateurs, les mots de passe et les groupes. A chaque fois qu'une demande HTTP traverse le flux des travaux de Caching Proxy, chaque directive Protect compare l'URL demandée à son modèle de demandes. En cas de correspondance, la directive Protect invoque un schéma de protection, lequel inclut l'identificateur du serveur, le type d'authentification à utiliser, les règles de masquage à appliquer au client demandeur et l'emplacement des fichiers de mots de passe et de groupes. Si le fichier de mots de passe n'est pas défini, l'identificateur de l'utilisateur et le mot de passe sont extraits par l'intermédiaire du module d'autorisation PAC-LDAP. Des stratégies de type 0, 1, 2 et 3 définissent les méthodes d'authentification. Si l'authentification aboutit, la demande est servie ; dans le cas contraire, Caching Proxy retourne au client une erreur 401.
Le processus d'autorisation détermine si un utilisateur possède les droits d'accès requis à une ressource protégée. Lorsque le module PAC-LDAP est utilisé, des règles d'autorisation spécifiées dans le fichier pacpolicy.conf pour la demande HTTP sont appliquées.
Quand le module d'autorisation PAC-LDAP est configuré pour l'autorisation, les règles d'autorisation contenues dans le fichier pacpolicy.conf s'appliquent à la demande HTTP. A chaque fois que la demande HTTP traverse le flux des travaux de Caching Proxy, chaque directive Protect compare l'URL demandée à son modèle de demandes. En cas de correspondance, la directive Protect invoque un schéma de protection. En l'occurrence, le schéma de protection est la routine d'autorisation usurpée par le module d'autorisation PAC-LDAP. La directive Authorization compare l'URL demandée à son modèle de demandes, et, en cas de correspondance, il fait appel au module d'autorisation PAC-LDAP. Des stratégies de type 4 définies dans le fichier pacpolicy.conf affineront par la suite l'authentification nécessaire aux diverses demandes d'URL.
LDAP permet un accès interactif à des annuaires X.500 avec une consommation minimale des ressources système. L'IANA a attribué à LDAP un port TCP 389 et un port UDP 389. Pour plus d'informations, consultez la RFC 1777, qui définit LDAP.
Exemples de clients LDAP pris en charge : client LDAP IBM Tivoli et client LDAP IBM SecureWay.
Tous les composants du module d'autorisation PAC-LDAP sont automatiquement installés lors de l'installation du système de Caching Proxy de WebSphere Application Server, Version 8.0. Sur les systèmes Linux et UNIX, des répertoires pour la bibliothèque Caching Proxy (./lib/), pour la bibliothèque module d'autorisation PAC-LDAP (./lib/plugins/pac/), pour les fichiers binaires (./bin/) et pour les fichiers de configuration (./etc/) sont créés dans le répertoire /opt/ibm/edge/cp/. Des liens symboliques sont ensuite créés vers les répertoires spécifiques du produit à partir des répertoires /usr/lib/, /usr/sbin/ et /etc.
Structure des répertoires
Répertoire Linux et UNIX | Répertoire Windows | Contenu |
---|---|---|
/opt/ibm/edge/cp | C:\Program Files\IBM\edge\cachingproxy\cp | Répertoire principal Caching Proxy (cp_root) |
cp_root/sbin | C:\Program Files\IBM\edge\cachingproxy\cp\Bin\ | fichiers binaires et scripts Caching Proxy |
/usr/sbin/ | liens symboliques vers cp_root/sbin/ | |
cp_root/etc/ | C:\Program Files\IBM\edge\cachingproxy\cp\etc\ | fichiers de configuration Caching Proxy |
/etc/ | liens symboliques vers cp_root/etc/ | |
cp_root/lib/ | C:\Program Files\IBM\edge\cachingproxy\cp\lib\plugins\ | bibliothèques Caching Proxy |
cp_root/lib/ plugins/pac/ | C:\Program Files\IBM\edge\cachingproxy\cp\lib\plugins\pac\ | bibliothèques module d'autorisation PAC-LDAP |
/usr/lib/ | liens symboliques vers cp_root/lib/ et cp_root/lib/ plugins/pac/ | |
cp_root/server_root/pac/data/ | C:\Program Files\IBM\edge\cachingproxy\cp\server_root\pac\data\ | stockage des données module d'autorisation PAC-LDAP |
cp_root/server_root/ pac/creds/ | C:\Program Files\IBM\edge\cachingproxy\cp\server_root\pac\creds\ | données d'identification module d'autorisation PAC-LDAP |
Fichiers du plug-in LDAP
Nom de fichier Linux et UNIX | Nom du fichier Windows | Description |
---|---|---|
libpacwte.so | pacwte.dll | bibliothèque partagée |
libpacman.so | pacman.dll | bibliothèque partagée |
pacd_restart.sh | pacd_restart.bat | script de redémarrage du démon PAC |
paccp.conf, pac.conf, pacpolicy.conf | paccp.conf, pac.conf, pacpolicy.conf | fichiers de configuration et de stratégies |
Pour établir des connexions SSL (Secure Sockets Layer) entre le démon PACD et le serveur LDAP, vous devez installer le module GSKit requis par le module client LDAP. GSKit 7 est requis et installé par défaut sur le système Caching Proxy mais il est possible que cette version ne corresponde pas à celle demandée par le client LDAP sur le système. Il est possible d'utiliser différentes versions de GSKit sur le même système pour des processus différents.
Placez le fichier de clés de GSKit dans $pacd_creds_dir/pac_keyring.kdb et le mot de passe dans $pacd_creds_dir/pac_keyring.pwd.
Sous Linux, vous devez configurer la variable d'environnement LD_PRELOAD comme indiqué ci-après pour permettre les connexions SSL entre le démon PACD et le serveur LDAP. Associez la variable à la valeur suivante :
LD_PRELOAD=/usr/lib/libstdc++-libc6.1-1.so.2
Les paramètres requis pour GSKit indiqués plus haut sont également valables pour les systèmes Linux.
Sur les systèmes Red Hat Enterprise Linux 4.0, le processus PACD ne démarre pas lorsque Caching Proxy est configuré pour utiliser le plug-in LDAP ITDS 6.0 pour authentification. Le message d'erreur suivant apparaît :
"error while loading shared libraries: /usr/lib/libldapiconv.so: R_PPC_REL24 relocation at 0x0fb58ad0 for symbol 'strpbrk' out of range"
Une restriction actuelle empêche ITDS 6.0 de prendre en charge les systèmes RHEL 4.0.
Le processus PACD ne démarre pas sur les systèmes AIX à cause de liens non résolus lorsque vous utilisez le client LDAP ITDS. Au démarrage du processus PACD, l'erreur suivante risque de se produire :
exec(): 0509-036 Cannot load program /usr/sbin/pacd because of the following errors: 0509-022 Cannot load module /usr/lib/libpacman.a. 0509-150 Dependent module libldap.a could not be loaded. 0509-022 Cannot load module libldap.a.
Pour contourner cet incident pour la version 5 d'ITDS pour le client LDAP, créez le lien symbolique suivant :
ln -s /usr/lib/libibmldap.a /usr/lib/libldap.a
Pour contourner cet incident pour la version 6 d'ITDS pour le client LDAP, créez le lien symbolique suivant :
ln -s /opt/IBM/ldap/V6.0/lib/libibmldap.a /usr/lib/libldap.a
Pour pouvoir initialiser le module d'autorisation PAC-LDAP, il est nécessaire d'ajouter à la section API Directives du fichier ibmproxy.conf les directives suivantes : ServerInit, Authorization ou Authentication, et ServerTerm. Pour créer ces directives, vous pouvez modifier manuellement le fichier ibmproxy.conf, ou, si le serveur proxy est en cours d'exécution, vous connecter avec un navigateur Web aux formulaires de configuration et d'administration et ouvrir le formulaire de traitement des demandes API (cliquez sur Configuration du serveur –> Traitement des demandes–> Traitement des demandes API. Chacune de ces directives doit figurer dans le fichier de configuration sur une seule ligne, même si les exemples contiennent, pour plus de clarté, des sauts de ligne.
En effet, des directives données à titre de prototype ont été ajoutées (sous forme de commentaires) à la section API du fichier ibmproxy.conf. Ces directives API sont placées dans un ordre délibérément choisi. Lors de l'ajout de directives d'API pour permettre de nouvelles fonctionnalités et l'utilisation de plug-ins, respectez l'ordre dans lequel figurent les directives dans la section Prototypes du fichier de configuration. Vous pouvez également supprimer les marques de commentaires et modifier, si nécessaire, les directives API pour chacune des fonctionnalités ou chacun des plug-ins souhaités.
La directive ServerInit comporte trois arguments : (1) le chemin qualifié complet d'accès à la bibliothèque partagée, (2) l'appel à la fonction et (3) le chemin qualifié complet d'accès à paccp.conf. Le premier et le deuxième arguments doivent être délimités par deux points (:). Un espace doit séparer le deuxième et le troisième arguments. Le premier et le troisième arguments sont propres au système et dépendent de l'endroit où sont installés les composants du plug-in. Le deuxième argument est défini dans le code de la bibliothèque partagée et doit être tapé exactement comme il apparaît dans cette dernière. Lors de la création d'une directive ServerInit à l'aide du formulaire Traitement des demandes API, le deuxième et le troisième arguments doivent tous deux être entrés dans la zone Nom de la fonction. Le troisième argument s'affiche dans la colonne Modèle d'IP.
La directive Authorization comporte trois arguments : (1) un modèle de demande, (2) le chemin d'accès complet à la bibliothèque partagée et (3) le nom de la fonction. Les demandes HTTP sont comparées au modèle de demandes pour permettre de déterminer si la fonction de l'application est appelée. Le modèle de demande peut inclure le protocole, le domaine et l'hôte ; il peut être précédé d'une barre oblique (/) et utiliser un astérisque (*) en tant que caractère générique. Par exemple, /front_page.html, http://www.ics.raleigh.ibm.com, /pub*, /* et * sont tous valides. La fonction porte le nom qui est donné au nom de l'application au sein du programme. Ce nom est figé dans le code et doit être entré exactement tel qu'il apparaît. Un espace doit séparer les deux premiers arguments. Les deux derniers arguments doivent être délimités par deux points (:).
La directive Authentication comporte deux arguments : (1) le chemin qualifié complet d'accès à la bibliothèque partagée et (2) le nom de la fonction. Les deux derniers arguments doivent être délimités par deux points (:). Le premier argument est propre au système et dépend de l'endroit où est installée la bibliothèque partagée. Lorsque vous utilisez Caching Proxy comme proxy inversé, le modèle d'URL du premier argument doit commencer par la racine du document (/). Le deuxième argument est défini dans le code de la bibliothèque partagée et doit être tapé exactement comme il apparaît dans cette dernière.
La directive ServerTerm comporte deux arguments : (1) le chemin qualifié complet d'accès à la bibliothèque partagée et (2) le nom de la fonction. Les deux derniers arguments doivent être délimités par deux points (:). Le premier argument est propre au système et dépend de l'endroit où est installée la bibliothèque partagée. Le deuxième argument est défini dans le code de la bibliothèque partagée et doit être tapé exactement comme il apparaît dans cette dernière. Cette directive met fin à l'activité du démon PAC lors de l'arrêt du serveur proxy. Si le démon et le serveur proxy appartiennent à des propriétaires différents, le serveur proxy risque d'être incapable d'arrêter le démon, auquel cas seul un administrateur peut l'arrêter manuellement.
ServerInit chemin_accès_bibliothèque_partagée:pacwte_auth_init chemin_accès_fichier_stratégie
Exemple Linux et UNIX :
ServerInit /usr/lib/libpacwte.so:pacwte_auth_init /etc/pac.conf
Exemple Windows :
ServerInit C:\Program Files\IBM\edge\cachingproxy\cp\lib\plugins\ pac\pacwte.dll:pacwte_auth_init C:\Progra ~1\IBM\edge\cp
Modèle de demande d'autorisation path_of_shared_library:pacwte_auth_policy
Exemple Linux et UNIX :
Authorization http://* /usr/lib/libpacwte.so:pacwte_auth_policy
Exemple Windows :
Autorisation http://* C:\Program Files\IBM\edge\cachingproxy\cp\lib\plugins\ pac\pacwte.dll:pacwte_auth_policy
Authentification BASIC path_of_shared_library:pacwte_auth_policy
Exemple Linux et UNIX :
Authentification BASIC /usr/lib/plugins/pac/libpacwte.so:pacwte_auth_policy
Exemple Windows :
Authentification BASIC C:\Program Files\IBM\edge\cachingproxy\cp\lib\plugins\ pac\pacwte.dll:pacwte_auth_policy
ServerTerm chemin_librairie_partagée:pacwte_shutdown
Exemple Linux et UNIX :
ServerTerm /usr/lib/libpacwte.so:pacwte_shutdown
Exemple Windows :
ServerTerm BASIC C:\Program Files\IBM\edge\cachingproxy\cp\lib\plugins\ pac\bin\pacwte.dll:pacwte_shutdown
Vous devez modifier manuellement les fichiers de configuration et de stratégie du module d'autorisation PAC-LDAP en utilisant un éditeur de texte. Le nom d'une directive doit être séparé de son premier argument par le signe deux-points (:). Les arguments sont séparés les uns des autres par des virgules (,). Des commentaires sont inclus dans les fichiers de configuration et de stratégies comme une aide à la modification. Les principales directives de stratégie sont indiquées ci-dessous.
Le fichier paccp.conf est lu par les bibliothèques partagées lors de l'initialisation de Caching Proxy et contient les définitions (section [PAC_MAN_SERVER]) de chacun des démons PAC qui seront lancés. Chacun de ces démons doit avoir sa propre section [PAC_MAN_SERVER].
[PAC_MAN_SERVER] hostname: # nom du démon PAC port: # port ausculté par pacd [PACWTE_PLUGIN] hostname_check:[true|false] # active la recherche DNS. La recherche DNS # doit avoir été activée pour qu'ibmproxy puisse fonctionner.
Le fichier pac.conf définit le serveur LDAP auquel le démon PAC tente de se connecter.
[PAC_MAN_SERVER]
hostname: # nom du démon PAC
port: # port ausculté par pacd
conn_type:ssl # mettez en commentaire si vous n'utilisez pas SSL
authentication_sequence:[primary|secondary|none]
authorization_sequence:[primary|secondary|none]
[LDAP_SERVER]
hostname: # nom d'hôte du serveur LDAP
port:389 # port ausculté par LDAP
ssl_port:636 # port SSL utilisé par le serveur LDAP
admin_dn: # utilisateur disposant de droits d'accès au serveur LDAP
# indiquez admin_dn:NULL pour activer les connexions anonymes
search_base: # portion de l'arborescence LDAP dans laquelle rechercher les informations de stratégies
# Si non requis, indiquez search_base:NULL
search_key: # champ ID dans lequel effectuer la recherche
[CACHE]
cred_cache_enabled [TRUE|FALSE] # active la mémoire cache des données d'identification
cred_cache_min_size:100 # nombre minimal dans pacd de données d'identification à mettre en mémoire cache
cred_cache_max_size:64000 # nombre maximal dans pacd de données d'identification à mettre en mémoire cache
cred_cache_expiration:86400 # expiration des données d'identification
policy_cache_enabled:[TRUE|FALSE] # activation/désactivation de la mémoire cache des stratégies
policy_cache_min_size:100 # nombre minimal d'éléments liés aux stratégies à mettre en cache
policy_cache_max_size:64000 # max. nombre maximal d'éléments liés aux stratégies à mettre en cache
policy_cache_expiration:86400 # expiration des éléments liés aux stratégies
Toutes les stratégies LDAP utilisent le modèle suivant dans les fichiers de configuration et de stratégies. Chacune de ces stratégies doit commencer par le mot POLICY en majuscules entre crochets.
[POLICY] default_policy:[grant|deny] # indique la stratégie par défaut des utilisateurs # qui ne figurent pas dans la section POLICY pac_client_hotname: # les instances du Caching Proxy qui ont le droit # d'utiliser une liste de stratégies id: # l'ID de l'entrée LDAP ou ip/nom hôte # (caractères génériques acceptés, par exemple, *.ibm.com) grant:[true|false] # true autorise l'accès, false # interdit l'accès type:[0|1|2|3|4] # 0 entrée LDAP correspondant à un groupe, # 1 entrée LDAP ne correspondant pas à un groupe, # 2 adresse IP # 3 nom hôte # 4 URL propagate:[true|false] # true indique que les droits d'accès (grant # ou deny) se propageront à tous les # descendants ou membres stop_entry:[entry|NULL] # La propagation des droits d'accès s'arrête # à cette entrée. Si l'ID est un groupe, # stop_entry doit recevoir la valeur NULL. # stop_entry peut s'appliquer à une adresse IP # ou à un nom d'hôte. Chaque stop_entry # doit figurer sur une ligne différente exception_entry:[entry|NULL] # L'affectation des droits d'accès saute # ces entrées, mais se poursuit dans leurs # sous-arborescences. Il peut s'agir d'une liste d'entrées. # exception_entry peut s'appliquer à un groupe, # une adresse IP ou un nom d'hôte. Chaque # exception_entry doit figurer sur une ligne différente. Exception_type: Exception:
Le caractère générique (*) n'est possible dans les directives ID et stop_entry que pour la dernière position des adresses IP ou la première position d'un nom d'hôte. Les caractères génériques ne sont pas acceptés dans l'exception_entry. Ils ne sont pris en charge dans aucun champ des entrées LDAP.
Plusieurs stratégies sont prises en charge et la valeur false a toujours la priorité en cas de conflit entre des stratégies. En d'autres termes, un simple refus dans n'importe quelle stratégie bloque tout accès. L'ordre dans lequel sont énumérées les stratégies dans les fichiers de configuration et de stratégies n'a aucune importance et ne crée aucune priorité.
Vous trouverez un jeu d'exemples de stratégies dans le fichier pacpolicy.conf qui se trouve dans le répertoire des fichiers de configuration.
Créez un fichier texte appelé pac_ldap.cred dans /cp_root>/server_root/pac/creds. Ce fichier contient le mot de passe associé au nom d'utilisateur de la directive admin_dn, définie dans le fichier pac.conf.
Le démon PAC chiffrera le mot de passe lors de sa première lecture du fichier.
Pour créer le fichier pac_ldap.cred sous Linux et UNIX, entrez les commandes suivantes :
cd cp_root/server_root/pac/creds echo "password" > pac_ldap.cred chown nobody pac_ldap.cred chgrp nobody pac_ldap.cred (sur Linux SUSE, utilisez chgrp nogroup pac_ldap.cred.)
Pour créer le fichier sur une plateforme Windows, tapez le mot de passe dans un fichier texte et stockez ce fichier dans le répertoire server_root\pac\creds\.
Le démon d'autorisation LDAP s'exécute en même temps que pacd. Vous pouvez redémarrer le démon d'autorisation LDAP sans interrompre Caching Proxy grâce aux scripts fournis. Exécutez le script pacd comme indiqué ci-dessous.
/usr/sbin/pacd_restart.sh id_utilisateur_pacd
C:\Program Files\IBM\edge\cachingproxy\cp\Bin\pacd_restart.bat CP_install_root
kill -15 ID_processus_pacd
Sous HP-UX : Le plug-in PAC-LDAP et pacd peuvent ne pas charger toutes leurs bibliothèques partagées dépendantes lors de l'exécution. Avant de les utiliser, vérifiez que les variables du système sont définies de la façon suivante :
SHLIB_PATH=/usr/lib:/usr/IBMldap/lib PATH=/usr/IBMldap/bin:$PATH PATH=/usr/IBMldap/bin/usr/IBMldap/
est le chemin d'installation par défaut du client LDAP sous HP-UX. Modifiez les variables PATH et SHLIB_PATH si le client LDAP est installé dans un autre répertoire. Si vous ne définissez pas ces variables, les erreurs ci-dessous peuvent survenir.
"Serverinit Error: server did not load functions from DLL module /opt/ibm/edge/cp/lib/plugins/pac/libpacwte.sl"
"/usr/lib/dld.sl: Can't find path for shared library: libibmldap.sl /usr/lib/dld.sl: No such file or directory Abort"
Sous Linux : Pour SUSE Linux Enterprise Server 9, ldd pacd peut indiquer que libldap.so n'a pas été trouvé. Pour éviter que cette erreur se produise, créez le lien symbolique suivant :
ln -s /usr/lib/libldap.so.19 /usr/lib/libldap.so
Sous AIX : Lors du lancement de pacd avec IBM Tivoli Directory Server 5.2, il est possible que le chargement du module PAC-LDAP échoue et génère l'erreur suivante :
exec(): 0509-036 Cannot load program /usr/sbin/pacd because of the following errors: 0509-022 Cannot load module /usr/lib/libpacman.a. 0509-150 Dependent module libldap.a could not be loaded. 0509-022 Cannot load module libldap.a.
Pour éviter que cette erreur se produise, créez le lien symbolique suivant :
ln -s /usr/lib/libibmldap.a /usr/lib/libldap.a
Could not extract a value for: Uid, return code:3Cette erreur s'affiche même si l'authentification LDAP fonctionne correctement. N'en tenez pas compte.