1 IBM Tioli Access Manager Guide d administration WebSEAL Version 3.9 GC2 3 IBM Tioli Access Manager Guide d administration WebSEAL Version 3.9 GC4 Re...
Remarque Avant d’utiliser le présent document et le produit associé, prenez connaissance des informations figurant à l’Annexe C, «Remarques» à la page 261.
Chapitre 5. Authentification WebSEAL . . . . . . . . . . . . . . . . . . . . . . 111 Explication du processus d’authentification . . . . . . . . Types de données de session pris en charge . . . . . . . Méthodes d’authentification prises en charge . . . . . . . Gestion de l’état de session . . . . . . . . . . . . . . Généralités sur l’état de session . . . . . . . . . . . Généralités sur la mémoire cache de session GSKit et WebSEAL Configuration de la mémoire cache d’ID de session GSKit SSL . Configuration de la mémoire cache des droits d’accès WebSEAL Gestion de l’état avec des cookies de session . . . . . . . Détermination des types de données d’ID de session valides . Configuration de cookies de secours . . . . . . . . . . Généralités sur la configuration de l’authentification . . . . . Paramètres locaux d’authentification . . . . . . . . . Paramètres externes personnalisés d’authentification CDAS . . Configuration par défaut pour l’authentification WebSEAL . . Configuration de plusieurs méthodes d’authentification . . . Invite de connexion . . . . . . . . . . . . . . . Commandes de déconnexion et de modification de mot de passe Configuration de l’authentification de base . . . . . . . . Activation et désactivation de l’authentification de base . . . Définition du nom de domaine . . . . . . . . . . . Configuration de la méthode d’authentification de base . . .
Processus de la connexion unique à base de formulaires . . . . Conditions requises pour le support d’applications . . . . . . Création du fichier de configuration pour les connexions uniques à Activation de la connexion unique à base de formulaires . . . . Exemple de fichier de configuration pour IBM HelpNow . . . .
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Avant-propos Bienvenue dans IBMTivoliAccess Manager - Guide d’administration WebSEAL. IBM Tivoli Access Manager WebSEAL est le gestionnaire de sécurité de ressources pour les ressources basées sur le Web. WebSEAL est un serveur Web à hautes performances et à plusieurs unités d’exécution, appliquant des règles de sécurité renforcées à l’espace objet Web sous sa protection. Il peut fournir des solutions à connexion unique et intégrer des ressources du serveur d’applications Web d’arrière-plan dans ses règles de sécurité. Ce guide d’administration contient un ensemble complet de procédures et d’informations de référence qui peuvent vous aider à gérer les ressources de votre domaine Web sécurisé. Il vous apporte également des informations intéressantes en matière de contexte et de concepts, sur la grande gamme des fonctionnalités WebSEAL. Remarque : Certains graphiques de cette brochure ne sont pas disponibles en français à la date d’impression.
A qui s’adresse ce guide Ce guide s’adresse aux administrateurs système chargés de la configuration et de la maintenance d’un environnement Access Manager WebSEAL. Vous devez posséder des connaissances dans les domaines suivants : v Systèmes d’exploitation PC et UNIX v Architecture et concepts de bases de données v Gestion de la sécurité v Protocoles Internet (HTTP, TCP/IP, FTP (File Transfer Protocol) et Telnet) v Protocole LDAP (Lightweight Directory Access Protocol) et services de répertoires v Registres d’utilisateurs pris en charge v Authentification et autorisation Si vous activez les communications SSL (Secure Sockets Layer), vous devez également bien connaître le protocole SSL, l’échange de clés (publiques et privées), les signatures numériques, les algorithmes de cryptographie et les autorités d’accréditation.
Ce chapitre sert de référence technique pour les grandes tâches de configuration avancée de WebSEAL : configuration de plusieurs instances WebSEAL, configuration de la fonctionnalité de changement d’utilisateur, gestion de l’allocation des unités d’agent et configuration des mises à jour et des interrogations de la base de données d’autorisations. Chapitre 4 : Règles de sécurité WebSEAL Ce chapitre contient des procédures techniques détaillées pour la personnalisation des règles de sécurité sur WebSEAL : règles POP et LCA, qualité de la protection, renforcement des règles d’authentification, règles d’authentification basées sur le réseau, règles de tentatives limitées de connexion et règles de renforcement du mot de passe. Chapitre 5 : Authentification WebSEAL Ce chapitre contient des procédures techniques détaillées sur la configuration de WebSEAL pour gérer toute une série de méthodes d’authentification : nom d’utilisateur et mot de passe, certificats côté client, passcode de jeton SecurID, données d’en-tête HTTP spéciales et fonctionnalité de nouvelle authentification. Chapitre 6 : Solutions de connexion interdomaine Ce chapitre traite des solutions de connexion interdomaine pour le côté externe d’une configuration proxy WebSEAL (entre le client et le serveur WebSEAL). Chapitre 7 : Jonctions WebSEAL Ce chapitre sert de référence technique exhaustive à l’installation et à l’utilisation des jonctions WebSEAL.
v Chapitre 8 : Solutions de connexion unique Web Ce chapitre traite des solutions de connexion unique (SSO) pour le côté interne d’une configuration proxy WebSEAL (entre le serveur WebSEAL et le serveur d’applications d’arrière-plan relié par jonction). v Chapitre 9 : Intégration d’application Ce chapitre explore diverses capacités de WebSEAL permettant d’intégrer les fonctionnalités d’une application de tiers. v Annexe A : Référence du fichier webseald.conf v Annexe B : Référence des jonctions WebSEAL
Publications Cette section répertorie les publications incluses dans la bibliothèque d’Access Manager ainsi que d’autres documents connexes. Elle décrit également la méthode d’accès en ligne aux publications Tivoli, de commande de ces dernières ou d’envoi de commentaires.
IBM Tivoli Access Manager La bibliothèque d’Access Manager est organisée autour des catégories suivantes : v Informations sur les versions v Informations sur la base v Informations relatives à WebSEAL v Informations relatives à la sécurité sur le Web v Informations de référence pour développeurs v Informations techniques supplémentaires Vous trouverez les publications de la bibliothèque produits au format PDF (Portable Document Format) sur le CD du produit. Pour accéder à ces publications
x
IBM Tivoli Access Manager - Guide d’administration WebSEAL
à l’aide d’un navigateur Web, ouvrez le fichier infocenter.html, que vous trouverez dans le répertoire /doc sur le CD du produit. Pour obtenir d’autres sources d’informations sur Access Manager et sur des thèmes connexes, visitez les sites Web suivants : http://www.ibm.com/redbooks https://www.tivoli.com/secure/support/documents/fieldguides
Informations sur les versions v IBM Tivoli Access Manager for e-business Read Me First GI11-0918 (am39_readme.pdf ) Fournit des informations relatives à l’installation et aux premières utilisations d’Access Manager. v IBM Tivoli Access Manager for e-business Release Notes GI11-0919 (am39_relnotes.pdf ) Fournit les informations les plus récentes (telles que les limitations logicielles, les solutions et les mises à jour de documentation).
Informations relatives à la base v IBM Tivoli Access Manager Base Installation Guide GC32-0844 (am39_install.pdf ) Fournit les procédures d’installation, de configuration et de mise à niveau du logiciel Access Manager (y compris de l’interface Web Portal Manager). v IBM Tivoli Access Manager - Guide d’administration GC11-1909 (am39_admin.pdf ) Décrit les concepts et les procédures d’utilisation des services d’Access Manager. Fournit les instructions d’exécution des tâches à partir de l’interface Web Portal Manager ou de la commande pdadmin. v IBM Tivoli Access Manager Base for Linux on zSeries Installation Guide GC23-4796 (am39_zinstall.pdf ) Fournit les procédures d’installation et de configuration de la base Access Manager pour Linux sur plate-forme zSeries.
Informations relatives à WebSEAL v IBM Tivoli Access Manager WebSEAL Installation Guide GC32-0848 (amweb39_install.pdf) Fournit les instructions d’installation, de configuration et de désinstallation du serveur WebSEAL et du kit de développement d’applications WebSEAL. v IBM Tivoli Access Manager - Guide d’administration WebSEAL GC11-1908 (amweb39_admin.pdf ) Fournit les données de base, les procédures administratives et les informations techniques permettant d’utiliser WebSEAL afin de gérer les ressources de votre domaine Web sécurisé. v IBM Tivoli Access Manager WebSEAL Developer’s Reference GC23-4683 (amweb39_devref.pdf) Fournit des informations de programmation et d’administration applicables aux modules CDAS (Cross-domain Authentication Service), CDMF (Cross-domain Mapping Framework) et à la validation de mot de passe. v IBM Tivoli Access Manager WebSEAL for Linux on zSeries Installation Guide Avant-propos
xi
GC23-4797 (amweb39_zinstall.pdf) Fournit les instructions d’installation, de configuration et de désinstallation du serveur WebSEAL et du kit de développement d’applications WebSEAL pour Linux sur plate-forme zSeries.
Informations relatives à la sécurité sur le Web v IBM Tivoli Access Manager for WebSphere Application Server - Guide de l’utilisateur GC11-1907 (amwas39_user.pdf ) Fournit les instructions d’installation, de désinstallation et d’administration d’IBM Websphere Application Server. v IBM Tivoli Access Manager for WebLogic Server User’s Guide GC32-0851 (amwls39_user.pdf) Fournit les instructions d’installation, de désinstallation et d’administration d’Access Manager for BEA WebLogic Server. v IBM Tivoli Access Manager Plug-in for Edge Server User’s Guide GC23-4685 (amedge39_user.pdf) Fournit les instructions d’installation, de configuration et d’administration du plug-in adapté à IBM WebSphere Edge Server. v IBM Tivoli Access Manager Plug-in for Web Servers User’s Guide GC23-4686 (amws39_user.pdf) Fournit les instructions d’installation, les procédures d’administration et les informations techniques permettant de sécuriser votre domaine Web à l’aide du plug-in pour applications de serveurs Web.
Guides de référence pour développeurs v IBM Tivoli Access Manager Authorization C API Developer’s Reference GC32-0849 (am39_authC_devref.pdf) Fournit des informations de référence qui décrivent les méthodes d’utilisation de l’API C d’autorisations d’Access Manager et de l’interface Access Manager Service Plug-in pour ajouter la sécurité Access Manager aux applications. v IBM Tivoli Access Manager Authorization Java Classes Developer’s Reference GC23-4688 (am39_authJ_devref.pdf) Fournit des informations de référence pour l’utilisation du langage Java au sein de l’API d’autorisation afin de permettre à une application d’utiliser la sécurité Access Manager. v IBM Tivoli Access Manager Administration C API Developer’s Reference GC32-0843 (am39_adminC_devref.pdf) Fournit des informations de référence sur l’utilisation de l’API d’administration afin de permettre à une application d’exécuter des tâches d’administration Access Manager. Ce document décrit la mise en oeuvre C de l’API d’administration. v IBM Tivoli Access Manager Administration Java Classes Developer’s Reference SC32-0842 (am39_adminJ_devref.pdf) Fournit des informations de référence pour l’utilisation du langage Java au sein de l’API d’autorisation, afin de permettre à une application d’utiliser la sécurité Access Manager. v IBM Tivoli Access Manager WebSEAL Developer’s Reference GC23-4683 (amweb39_devref.pdf)
xii
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Fournit des informations de programmation et d’administration applicables aux modules CDAS (Cross-domain Authentication Service), CDMF (Cross-domain Mapping Framework) et à la validation de mot de passe.
Documents techniques supplémentaires v IBM Tivoli Access Manager Performance Tuning Guide GC32-0846 (am39_perftune.pdf) Fournit des informations d’optimisation des performances adaptées à un environnement composé d’Access Manager avec IBM SecureWay Directory défini comme registre utilisateur. v IBM Tivoli Access Manager Capacity Planning Guide GC32-0847 (am39_capplan.pdf) Aide les responsables du planning à déterminer le nombre de serveurs Web requis (serveurs WebSEAL, LDAP et d’arrière-plan) pour l’exécution d’une charge de travail en particulier. v IBM Tivoli Access Manager Error Message Reference SC32-0845 (am39_error_ref.pdf) Fournit des explications et indique des actions recommandées pour les messages émis par Access Manager. Le glossaire Tivoli contient la définition d’un grand nombre de termes techniques relatifs au logiciel Tivoli. Le glossaire Tivoli est disponible (en anglais uniquement) sur le site Web suivant : http://www.tivoli.com/support/documents/glossary/termsm03.htm
Documents connexes Cette section répertorie les documents relatifs à la bibliothèque Access Manager.
Base de données universelle IBM DB2 La base de données universelle IBM DB2 est requise lors de l’installation des serveurs IBM SecureWay Directory, LDAP SecureWay z/OS et OS/390. Vous trouverez des informations relatives à DB2 sur le site Web suivant : http://www.ibm.com/software/data/db2/
IBM Global Security Toolkit Access Manager permet d’effectuer un chiffrement de données via l’utilisation d’IBM Global Security Toolkit (GSKit). Vous trouverez GSKit sur le CD d’IBM Tivoli Access Manager Base pour votre plate-forme spécifique. GSKit installe l’utilitaire de gestion iKeyman (gsk5ikm). Ce dernier vous permet de créer des bases de données de clés, des paires de clés publiques-privées et des requêtes de certificats. Le document suivant est disponible dans le répertoire /doc/GSKit : v Secure Sockets Layer Introduction and iKeyman User’s Guide gskikm5c.pdf Ce document fournit des informations à l’attention des responsables de la sécurité du système ou des administrateurs réseau chargés d’activer les communications SSL dans leur domaine sécurisé Access Manager.
Avant-propos
xiii
IBM SecureWay Directory Vous trouverez IBM SecureWay Directory (version 3.2.2) sur le CD d’IBM Tivoli Access Manager Base pour votre plate-forme spécifique. Si vous souhaitez installer le serveur IBM SecureWay Directory en tant que registre d’utilisateurs, vous trouverez les documents suivants dans le répertoire /doc/Directory sur le CD IBM Tivoli Access Manager Base pour votre plate-forme spécifique : v IBM SecureWay Directory Installation and Configuration Guide (aparent.pdf, lparent.pdf, sparent.pdf, wparent.pdf) Fournit des informations d’installation, de configuration et de migration pour les composants IBM SecureWay Directory sous AIX, Linux, Solaris et Microsoft Windows. v IBM SecureWay Directory Release Notes (relnote.pdf) Complète la documentation produit d’IBM SecureWay Directory (version 3.2.2) et décrit les nouvelles fonctions de cette version. v IBM SecureWay Directory Readme Addendum (addendum322.pdf) Fournit des informations sur les modifications et les corrections apportées après la traduction de la documentation relative à IBM SecureWay Directory. Ce fichier existe en anglais uniquement. v IBM SecureWay Directory Server Readme (server.pdf) Fournit une description d’IBM SecureWay Directory Server (version 3.2.2). v IBM SecureWay Directory Client Readme (client.pdf) Fournit une description d’IBM SecureWay Directory Client SDK (version 3.2.2).Ce kit de développement logiciel (SDK) constitue un support de développement d’applications LDAP. v SSL Introduction and iKeyman User’s Guide (gskikm5c.pdf) Ce document fournit des informations à l’attention des responsables de la sécurité du système ou des administrateurs réseau chargés d’activer les communications SSL dans leur domaine sécurisé Access Manager. v IBM SecureWay Directory Configuration Schema (scparent.pdf) Décrit l’arborescence des renseignements répertoire (DIT) et les attributs utilisés pour configurer le fichier slapd32.conf. Dans IBM SecureWay Directory (version 3.2), les paramètres du répertoire sont stockés au format LDIF (LDAP Directory Interchange Format) dans le fichier slapd32.conf. v IBM SecureWay Directory Tuning Guide (tuning.pdf) Fournit des informations de réglage des performances pour IBM SecureWay Directory. Lorsqu’elles sont disponibles, des informations sont fournies sur le réglage des tailles de répertoires (de quelques milliers d’entrées à plusieurs millions d’entrées). Pour plus d’informations sur IBM SecureWay Directory, visitez le site Web suivant : http://www.software.ibm.com/network/directory/library/
xiv
IBM Tivoli Access Manager - Guide d’administration WebSEAL
IBM WebSphere Application Server IBM WebSphere Application Server, Advanced Single Server Edition (version 4.0.2) est installé en même temps que l’interface Web Portal Manager. Pour plus d’informations sur IBM WebSphere Application Server, visitez le site Web suivant : http://www.ibm.com/software/webservers/appserv/infocenter.html
Accès aux publications en ligne Vous trouverez les publications des bibliothèques produit sur le CD produit, au format PDF (Portable Document Format). Pour accéder à ces publications à l’aide d’un navigateur Web, ouvrez le fichier infocenter.html (que vous trouverez dans le répertoire /doc du CD produit. Lorsqu’IBM publie une nouvelle version de certaines publications (en ligne ou sous forme de documents), celle-ci figure dans le centre de documentation Tivoli. Le centre de documentation Tivoli contient la version la plus récente des publications de la bibliothèque produit, au format PDF ou HTML (ou encore aux deux). Des documents traduits sont également disponibles pour certains produits. Vous pouvez accéder au centre de documentation Tivoli et à d’autres sources d’informations techniques à partir du site Web suivant : http://www.tivoli.com/support/documents/ Les informations sont organisées par produit et comprennent des notes d’édition, des guides d’installation, des guides de l’utilisateur, des guides d’administration et des documents de référence pour développeurs. Remarque : Si vous imprimez des documents sur un autre papier que le papier lettre, cochez la case Fit to page dans la boîte de dialogue d’impression d’Adobe Acrobat (qui s’affiche lorsque vous cliquez sur File → Print) pour garantir que les dimensions totales d’une page au format lettre sont prises en compte pour l’impression sur le papier utilisé.
Commande de publications Vous pouvez commander de nombreuses publications Tivoli en ligne à partir du site Web suivant http://www.elink.ibmlink.ibm.com/public/applications/ publications/cgibin/pbi.cgi Vous pouvez également passer votre commande par téléphone, en appelant l’un des numéros suivants : v Aux Etats-Unis, composez le 800-879-2755. v Au Canada, composez le 800-426-4968 v Pour les autres pays, vous trouverez la liste des numéros de téléphone sur le site Web suivant : http://www.tivoli.com/inside/store/lit_order.html
Avant-propos
xv
Commentaires sur les publications Vos commentaires sur les produits et la documentation Tivoli nous sont très utiles, car ils permettent d’améliorer la qualité de nos produits. Vous pouvez nous faire parvenir vos commentaires et suggestions sur ce guide en procédant de l’une des manières suivantes : v Envoyez un courrier électronique à [email protected]. v Répondez à notre enquête de satisfaction clients sur le site Web suivant : http://www.tivoli.com/support/survey/
Accessibilité Les fonctions d’accessibilité permettent aux utilisateurs handicapés (à mobilité réduite ou ayant des problèmes de vue) d’utiliser des produits logiciels. Grâce à ce produit, vous pouvez utiliser des techniques qui vous aident à entendre et à naviguer dans l’interface. Vous pouvez également vous servir du clavier plutôt que de la souris pour utiliser toutes les fonctions de l’interface graphique utilisateur.
Comment contacter le service d’assistance En cas d’incident lors de l’utilisation de l’un des produits Tivoli, vous pouvez faire appel au service d’assistance Tivoli. Reportez-vous au document Tivoli Customer Support Handbook, disponible sur le site Web suivant : http://www.tivoli.com/support/handbook/ Ce document indique comment contacter le service clientèle de Tivoli en fonction de la gravité du problème rencontré et contient les informations suivantes v Enregistrement et éligibilité v Numéros de téléphone et adresses électroniques en fonction du pays v Informations à préparer avant de prendre contact avec le support
Conventions utilisées dans ce document Le présent guide applique plusieurs conventions de présentation pour les actions et les termes spéciaux, pour les commandes et chemins propres à chaque système d’exploitation et pour les graphiques.
Conventions utilisées dans ce guide Les conventions suivantes sont utilisées dans ce guide :
xvi
Gras
Les commandes, mots clés, noms de fichiers, rôles d’autorisation, adresses URL ou autres informations à utiliser littéralement apparaissent en caractères gras.
Italique
Les variables, les options et les valeurs que vous devez indiquer apparaissent en caractères italiques. Les titres des publications, ainsi que les termes et phrases que l’auteur a voulu mettre en évidence apparaissent également en caractères italiques.
Monospace
Les exemples de code, les lignes de commande, les sorties d’écran, les noms de fichier et de répertoire ainsi que les messages système apparaissent dans la police de caractères monospace.
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Avis aux lecteurs canadiens Le présent document a été traduit en France. Voici les principales différences et particularités dont vous devez tenir compte. Illustrations Les illustrations sont fournies à titre d’exemple. Certaines peuvent contenir des données propres à la France. Terminologie La terminologie des titres IBM peut différer d’un pays à l’autre. Reportez-vous au tableau ci-dessous, au besoin. IBM France
IBM Canada
ingénieur commercial
représentant
agence commerciale
succursale
ingénieur technico-commercial
informaticien
inspecteur
technicien du matériel
Claviers Les lettres sont disposées différemment : le clavier français est de type AZERTY, et le clavier français-canadien de type QWERTY. OS/2 et Windows - Paramètres canadiens Au Canada, on utilise : v les pages de codes 850 (multilingue) et 863 (français-canadien), v le code pays 002, v le code clavier CF.
Nomenclature Les touches présentées dans le tableau d’équivalence suivant sont libellées différemment selon qu’il s’agit du clavier de la France, du clavier du Canada ou du clavier des États-Unis. Reportez-vous à ce tableau pour faire correspondre les touches françaises figurant dans le présent document aux touches de votre clavier.
Brevets Il est possible qu’IBM détienne des brevets ou qu’elle ait déposé des demandes de brevets portant sur certains sujets abordés dans ce document. Le fait qu’IBM vous fournisse le présent document ne signifie pas qu’elle vous accorde un permis d’utilisation de ces brevets. Vous pouvez envoyer, par écrit, vos demandes de renseignements relatives aux permis d’utilisation au directeur général des relations commerciales d’IBM, 3600 Steeles Avenue East, Markham, Ontario, L3R 9Z7. Assistance téléphonique Si vous avez besoin d’assistance ou si vous voulez commander du matériel, des logiciels et des publications IBM, contactez IBM direct au 1 800 465-1234.
xviii
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL IBMTivoliAccess Manager for e-business (Access Manager) constitue une solution robuste et sécurisée de gestion centralisée des règles applicables au commerce électronique et aux applications distribuées. IBM Tivoli Access Manager WebSEAL est un serveur Web à hautes performances et à plusieurs unités d’exécution, appliquant des règles de sécurité renforcées à l’espace objet Web Access Manager sous sa protection. WebSEAL peut fournir des solutions à connexion unique et intégrer des ressources du serveur d’application Web d’arrière-plan dans ses règles de sécurité. Le présent chapitre vous présente les principales fonctionnalités du serveur WebSEAL. Index des rubriques : v «Introduction à IBM Tivoli Access Manager et à WebSEAL» à la page 1 v «Présentation du modèle de sécurité d’Access Manager» à la page 3 v v v v
«Protection de l’espace Web grâce à WebSEAL» à la page 7 «Planification et mise en oeuvre des règles de sécurité» à la page 8 «Explication de l’authentification WebSEAL» à la page 10 «Explication des jonctions WebSEAL» à la page 14
Introduction à IBM Tivoli Access Manager et à WebSEAL IBM Tivoli Access Manager : IBM Tivoli Access Manager constitue une solution complète de gestion des règles de sécurité réseau et d’autorisation, qui fournit une protection inégalée des ressources sur des intranets et des extranets géographiquement dispersés. Outre ses fonctions avancées de gestion des règles de sécurité, Access Manager contient des fonctions d’authentification, d’autorisation, de sécurité des données et de gestion centralisée des ressources. Vous pouvez utiliser Access Manager en association avec des applications Internet standard afin de créer des intranets présentant un très bon niveau de sécurité et de gestion. En tant qu’élément central, Access Manager offre les capacités suivantes : v Structure d’authentification Access Manager fournit une large gamme d’outils intégrés d’authentification et prend en charge des outils externes d’authentification. v Structure d’autorisation Le service d’autorisation d’Access Manager (auquel vous pouvez accéder via l’API d’autorisation d’Access Manager) vous permet de prendre des décisions d’autorisation ou de refus de requêtes relatives à des ressources protégées situées dans le domaine sécurisé.
Grâce à Access Manager, il devient possible de gérer en toute sécurité l’accès aux ressources de réseaux internes privés tout en bénéficiant des capacités de connectivité et de facilité d’utilisation d’Internet. Access Manager, en association avec un dispositif pare-feu, peut apporter une protection totale de l’intranet d’entreprise de toute intrusion ou accès non autorisé. IBM Tivoli Access Manager WebSEAL : IBM Tivoli Access Manager WebSEAL est le gestionnaire de sécurité et de protection de ressources pour les ressources et les informations basées sur le Web. WebSEAL est un serveur Web à hautes performances et à plusieurs unités d’exécution, appliquant des règles de sécurité renforcées à l’espace objet Web Access Manager sous sa protection. Il peut fournir des solutions à connexion unique et intégrer des ressources du serveur d’applications Web d’arrière-plan dans ses règles de sécurité. WebSEAL fonctionne normalement en tant que proxy Web inversé via la réception de requêtes HTTP/HTTPS en provenance d’un navigateur Web et la livraison du contenu de son propre serveur Web ou de serveurs d’applications Web reliés au réseau par jonction. Les requêtes acheminées par WebSEAL sont évaluées par le service d’autorisation d’Access Manager afin de déterminer si l’utilisateur est autorisé à accéder à la ressource demandée. WebSEAL comporte un certain nombre de fonctionnalités : v Prise en charge de plusieurs méthodes d’authentification
v v v
v
Les architectures, tant intégrées que complétées par des modules, autorisent une certaine souplesse, dans la mesure où elles acceptent toute une variété de méthodes d’authentification. Prise en charge des requêtes HTTP et HTTPS Intégration et protection des ressources du serveur d’arrière-plan grâce à la technologie de jonction WebSEAL Gestion d’un contrôle d’accès renforcé pour l’espace Web du serveur local et d’arrière-plan Sont notamment prises en charge les ressources suivantes : URL, expressions régulières basées sur une adresse URL, programmes CGI, fichiers HTML, servlets Java et fichiers de classe Java. Fonctionnement en tant que proxy Web inversé
WebSEAL apparaît comme un serveur Web pour les clients et comme un navigateur Web pour les serveurs reliés au réseau par une jonction qu’il protège. v Capacités de connexion unique
2
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Espace objet Web sécurisé
Authentification
/
Client
WebSEAL
jonction WebSEAL
Serveur d’applications Web
prend en charge plusieurs méthodes d’authentification intègre le service d’autorisation gère le contrôle renforcé des ressources Web gère des types de ressource variés intègre et protège les ressources du serveur d’arrière-plan assure un espace de ressources Web protégé unifié fournit des solutions à connexion unique
Figure 1. Protection de l’espace Web avec WebSEAL
Présentation du modèle de sécurité d’Access Manager La stratégie de sécurité d’un domaine sécurisé Access Manager s’articule autour de deux structures clés de sécurité : v Registre d’utilisateurs Le registre d’utilisateurs (tel que LDAP, Lotus Domino ou Microsoft Active Directory) contient tous les utilisateurs et tous les groupes autorisés à participer au domaine sécurisé Access Manager. v Base de données d’autorisation principale La base de données d’autorisation principale contient une représentation de toutes les ressources du domaine (l’espace objets protégé). L’administrateur de sécurité peut spécifier un niveau de sécurité grâce à l’application de règles appelées liste de contrôle d’accès (ACL) de règles simples et de règles d’objet protégées (POP) aux ressources qui nécessitent une protection. L’identité d’un utilisateur est vérifiée dans WebSEAL grâce au processus d’authentification. Un utilisateur peut participer au domaine sécurisé en tant qu’utilisateur authentifié ou non authentifié. Seuls les utilisateurs possédant une entrée dans le registre d’utilisateurs peuvent être authentifiés. A l’aide des ACL et des POP, l’administrateur de sécurité peut rendre certaines ressources publiques disponibles pour des utilisateurs non authentifiés. En revanche, d’autres ressources ne peuvent être disponibles que pour certains utilisateurs authentifiés. Lorsqu’un utilisateur est authentifié pour WebSEAL, des droits d’accès sont créés pour cet utilisateur. Ces droits d’accès se composent de l’identité de l’utilisateur, des membres du groupe et de tous les attributs de sécurité spécifiques (“étendus”). Le service d’autorisation d’Access Manager met en place les règles de sécurité en comparant les droits d’accès d’un utilisateur avec les autorisations affectées à la ressource demandée. La recommandation qui en résulte est transmise au gestionnaire des ressources (WebSEAL, par exemple), qui élabore la réponse à la requête d’origine. Les droits d’accès des utilisateurs sont essentiels pour leur participation complète au domaine sécurisé.
Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL
3
Espace objets protégé L’espace objets protégé est la représentation hiérarchique de ressources appartenant à un domaine sécurisé Access Manager. Les objets virtuels qui apparaissent dans l’espace objets hiérarchique représentent les ressources réseau physiques. v Ressource système – fichier ou application physique. v Objet protégé – représentation logique d’une ressource système réelle utilisée par le service d’autorisation, par le composant Web Portal Manager et par d’autres utilitaires de gestion Access Manager. Vous pouvez attacher des modèles de règles à des objets dans l’espace objets afin de protéger la ressource. Le service d’autorisation prend ses décisions d’autorisation sur la base de ces modèles. Les catégories d’espace objets suivantes sont utilisées par Access Manager : v Objets Web Ces objets représentent tous les éléments pouvant être adressés par une URL HTTP. Ils peuvent inclure des pages Web statiques et des adresses URL dynamiques converties en requêtes de base de données ou en tout autre type d’application. Le serveur WebSEAL assure la protection des objets Web. v Objets de gestion Access Manager Ces objets représentent les activités de gestion qui peuvent être exécutées via Web Portal Manager. Les objets représentent les tâches nécessaires à la définition des utilisateurs et des règles de sécurité. Access Manager prend en charge la délégation des activités de gestion et peut limiter la capacité d’un administrateur à définir des règles de sécurité pour un sous-ensemble de l’espace objets. v Objets définis par l’utilisateur Ces objets représentent des tâches définies par le client ou des ressources réseau protégées par des applications à l’aide du service d’autorisation, via l’API d’autorisation d’Access Manager.
Figure 2. Espace objets protégé Access Manager
4
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Définition et application de règles de LCA et POP Les responsables de la sécurité protègent les ressources système Access Manager grâce à la définition de règles (appelées règles de LCA et POP) et à l’application de ces règles aux représentations d’objets de ces ressources dans l’espace objets protégé. Le service d’autorisation d’Access Manager prend des décisions d’autorisation sur la base des règles appliquées à ces objets. Lorsqu’une opération demandée sur un objet protégé est autorisée, l’application responsable de la ressource met en place cette opération. Une règle peut indiquer les paramètres de protection d’un grand nombre d’objets. Toute modification apportée à la règle affecte tous les objets auxquels le modèle est associé.
Liste de contrôle d’accès (LCA) Une règle de liste de contrôle d’accès (ou règle de LCA) représente un ensemble de règles (autorisations) qui spécifie les conditions nécessaires à l’exécution de certaines opérations sur cette ressource. Les définitions de règles de LCA sont des composants importants de la stratégie de sécurité établie pour le domaine sécurisé. Les règles de LCA, comme toutes les règles, sont utilisées pour apposer les conditions requises d’une entreprise en matière de sécurité sur les ressources représentées au sein de l’espace objets protégé. Les règles de LCA contrôlent de façon spécifique les éléments suivants : 1. opérations pouvant être effectuées sur la ressource 2. personne pouvant effectuer cette opération Les règles de LCA sont composées d’une ou de plusieurs entrées qui incluent des désignations d’utilisateur et de groupe ainsi que leurs autorisations ou droits spécifiques. Une LCA peut également contenir des règles qui s’appliquent à des utilisateurs non authentifiés.
Figure 3. règle de LCA
Règles d’objet protégé (POP) Les règles de LCA fournissent au service d’autorisation des informations permettant d’apporter une réponse “oui” ou “non” à une requête afin d’accéder à un objet protégé et d’effectuer certaines opérations sur cet objet. Les règles POP contiennent des conditions supplémentaires relatives à la requête qui sont retransmises à Access Manager Base et au gestionnaire de ressources (WebSEAL, par exemple) avec la décision “oui” pour la règle de LCA provenant
Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL
5
du service d’autorisation. Il incombe à Access Manager et au gestionnaire de ressources de mettre en oeuvre les conditions POP. Les tableaux suivants dressent la liste des attributs disponibles pour une règle POP : Mise en oeuvre effectuée par Access Manager Base Attribut POP
Description
Nom
Nom de la règle. Il se transforme en dans les commandes pdadmin pop.
Description
Texte descriptif de la règle. Il apparaît dans la commande pop show.
Mode d’avertissement
Fournit aux administrateurs un moyen de tester les règles de LCA et POP.
Niveau d’audit
Spécifie le type d’audit : tout, aucun, accès abouti, accès refusé, erreurs.
Heures d’accès refusés
Jour et heure d’accès à l’objet protégé ayant abouti.
Mise en oeuvre effectuée par le gestionnaire de ressources (WebSEAL, par exemple) Attribut POP
Description
Qualité de protection
Spécifie le niveau de protection des données : aucun, intégrité, confidentialité.
Règle de méthode d’authentification d’extrémité IP
Spécifie les conditions d’authentification applicables à l’accès de membres appartenant à des réseaux externes.
Règle explicite et héritée Une règle peut être appliquée explicitement ou être héritée. L’espace objets protégé d’Access Manager prend en charge l’héritage des attributs de règles de LCA et POP. Il s’agit là d’un aspect important pour le responsable de la sécurité qui gère l’espace objets. En effet, il ne doit appliquer de règles explicites qu’à certains points de la hiérarchie où les règles doivent changer.
Figure 4. Règles explicites et héritées
6
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Gestion des règles : Web Portal Manager Web Portal Manager est une application graphique Web utilisée pour la gestion des règles de sécurité au sein d’un domaine sécurisé Access Manager. L’utilitaire de ligne de commande pdadmin contient les mêmes capacités d’administration que Web Portal Manager, plus certaines commandes non prises en charge par Web Portal Manager. A partir de Web Portal Manager (ou de pdadmin), vous pouvez gérer le registre d’utilisateurs, la base de données de règles d’autorisation principale et les serveurs Access Manager. Vous pouvez également ajouter et supprimer des utilisateurs/des groupes et appliquer des règles de LCA et POP aux objets réseau.
Protection de l’espace Web grâce à WebSEAL Lorsque WebSEAL met en place la sécurité au sein d’un domaine sécurisé, chaque client doit apporter la preuve de son identité. A leur tour, les règles de sécurité Access Manager déterminent si ce client est autorisé à effectuer une opération sur une ressource demandée. Puisque l’accès à chaque ressource Web d’un domaine sécurisé est contrôlé par WebSEAL, le fait que WebSEAL requiert une authentification et une autorisation peut fournir une sécurité du réseau très complète. En systèmes de sécurité, l’authentification est distincte de l’autorisation. L’autorisation (ou droit d’accès) détermine si un client authentifié a le droit d’exécuter une opération sur une ressource donnée au sein d’un domaine sécurisé. L’authentification peut valider l’identité d’un client, mais ne fournit aucune indication sur les droits du client à effectuer certaines opérations sur une ressource protégée. Dans le modèle d’autorisation d’Access Manager, les règles d’autorisation sont mises en oeuvre indépendamment de la méthode utilisée pour l’authentification des utilisateurs. Les utilisateurs peuvent authentifier leur identité à l’aide d’une clé publique/privée, d’une clé secrète ou de méthodes définies par le client. Une partie du processus d’authentification implique la création d’un droit d’accès qui décrit l’identité du client. Les décisions d’autorisation prises par un service d’autorisation prennent comme base les droits d’accès des utilisateurs. Les ressources d’un domaine sécurisé reçoivent un niveau de protection qui dépend de la stratégie de sécurité du domaine. La stratégie de sécurité définit les participants autorisés au sein du domaine sécurisé et le niveau de protection de chaque ressource. Le processus d’autorisation se compose des composants de base suivants : v Un gestionnaire de ressources effectue la mise en place de l’opération demandée lorsque l’autorisation correspondante est accordée. WebSEAL est un gestionnaire de ressources. L’un des composants du gestionnaire de ressources est l’outil de mise en oeuvre de règles qui envoie la requête au service d’autorisation à des fins de traitement. Remarque : Les applications classiques regroupent l’outil de mise en oeuvre de règles et le gestionnaire de ressources au sein d’un même processus. Des exemples de cette structure incluent WebSEAL et des applications de fabricants tiers.
Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL
7
v Un service d’autorisation est chargé de l’action de prise de décision à propos de la requête. Le diagramme suivant illustre le processus d’autorisation complet :
Figure 5. Processus d’autorisation Access Manager
1. Une requête de client authentifiée pour une ressource est acheminée vers le gestionnaire de ressources et interceptée par le processus de mise en oeuvre de règles. Le gestionnaire de ressources peut être WebSEAL (pour l’accès HTTP, HTTPS), ou encore une application de fabricant tiers. 2. Le processus de mise en oeuvre des règles utilise l’API d’autorisation d’Access Manager pour appeler le service d’autorisation afin de prendre une décision d’autorisation. 3. Le service d’autorisation effectue une vérification d’autorisation sur la ressource (représentée sous la forme d’objet dans l’espace objets protégé). Les règles POP de base sont vérifiées en premier lieu. Ensuite, la règle de LCA associée à l’objet est comparée aux droits d’accès du client. Puis, les règles POP mises en oeuvre par le gestionnaire de ressources sont vérifiées. 4. La décision d’accepter ou de refuser la requête est renvoyée au gestionnaire de ressources sous forme d’une recommandation (via l’outil de mise en oeuvre de règles). 5. Si la requête est approuvée, le gestionnaire de ressources transmet la requête à l’application responsable de la ressource. 6. Le client reçoit alors les résultats de l’opération demandée.
Planification et mise en oeuvre des règles de sécurité Des règles de sécurité d’entreprise identifient : 1. Les ressources Web exigeant une protection 2. Le niveau de protection
8
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Access Manager utilise une représentation virtuelle de ces ressources Web, appelée l’espace objet protégé. Ce dernier contient des objets qui représentent les ressources physiques réelles de votre réseau. Vous mettez en oeuvre les règles de sécurité en appliquant les mécanismes de sécurité appropriés aux objets nécessitant une protection. Les mécanismes de sécurité peuvent être les suivants : v Stratégies de liste de contrôle d’accès (LCA) Les stratégies de LCA identifient les types d’utilisateurs susceptibles de se voir accorder l’accès et indiquent les opérations autorisées au niveau de l’objet. v Stratégies d’objet protégé (POP) Une stratégie d’objet protégé (POP) spécifie des conditions supplémentaires d’accès à l’objet protégé, par exemple la confidentialité, l’intégrité, l’audit et l’accès en temps réel. v Attributs étendus Les attributs étendus sont des valeurs supplémentaires placées sur un objet, une LCA ou un POP, qui peuvent être lues et interprétées par des applications provenant de tiers (comme un service d’autorisation externe). Le composant central d’Access Manager est le service d’autorisation — qui accorde ou refuse l’accès aux objets protégés (ressources) sur la base des données d’autorisation de l’utilisateur et des contrôles d’accès définis sur les objets. Pour réussir la mise en oeuvre des règles de sécurité, vous devez organiser de façon logique les différents types de contenu (comme décrit à la section «Identification des types de contenu et des niveaux de protection» à la page 9) et appliquer les stratégies de LCA et de POP appropriées. La gestion du contrôle d’accès peut se révéler une tâche extrêmement complexe et est grandement facilitée par une catégorisation soignée des types de contenu.
Identification des types de contenu et des niveaux de protection En tant qu’administrateur de sécurité de votre espace Web, vous devez identifier de façon correcte les types de contenu disponibles pour les divers types d’utilisateurs. Si certains contenus doivent être hautement protégés et n’être placés qu’à la disposition de certains utilisateurs spécifiques, d’autres contenus sont destinés à l’ensemble du public. Chaque scénario de sécurité répond donc à diverses exigences sécuritaires et exige donc une configuration WebSEAL particulière. Il v v v
vous incombe de : Connaître votre contenu Web Identifier les types d’utilisateurs devant accéder à ce contenu Comprendre les points forts et les faiblesses des options de la configuration WebSEAL proposée pour protéger ce contenu
La protection d’un contenu Web peut correspondre à l’une des trois catégories suivantes : 1. Contenu public – l’accès ne requiert aucune protection v Accès des clients non authentifiés via HTTP
Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL
9
v Données d’autorisation non authentifiées utilisées pour le contrôle d’accès aux ressources v Configuration WebSEAL basique requise 2. Contenu public – l’accès requiert une certaine confidentialité (chiffrement) v Accès des clients non authentifiés via HTTPS v Chiffrement requis pour protéger les données confidentielles requises par le serveur d’applications (comme les numéros de carte de crédit et les informations de compte utilisateur) v Données d’autorisation non authentifiées utilisées pour le contrôle d’accès aux ressources v La configuration WebSEAL doit stipuler la confidentialité 3. Contenu privé – authentification obligatoire pour l’accès v Accès des clients authentifiés via HTTP ou HTTPS v L’administrateur détermine si le chiffrement est nécessaire ou non v Données d’autorisation authentifiées utilisées pour le contrôle d’accès aux ressources : le compte des clients doit être défini dans le registre d’utilisateurs v La configuration WebSEAL est complexe et toutes les options doivent être envisagées avec attention pour que l’impact des règles de sécurité puisse être déterminé
Explication de l’authentification WebSEAL L’authentification est la méthode qui permet d’identifier un processus ou une entité individuel essayant de se connecter à un domaine sécurisé. Lorsque le serveur et le client exigent tous les deux une authentification, l’échange porte le nom d’authentification réciproque.
Qui êtes-vous ?
Client
WebSEAL Qui êtes-vous ?
Figure 6. Authentification réciproque
WebSEAL peut apporter un niveau élevé de sécurité dans un domaine sécurisé en demandant à chaque client de prouver son identité. Les conditions suivantes s’appliquent à l’authentification WebSEAL : v WebSEAL prend en charge un ensemble standard de méthodes d’authentification. Vous pouvez le personnaliser pour lui faire accepter d’autres méthodes d’authentification. v Le processus serveur WebSEAL est indépendant de la méthode d’authentification. v WebSEAL ne requiert qu’une identité de client. A partir de cette identité, WebSEAL obtient des données d’autorisation authentifiées (ou non authentifiées)
10
IBM Tivoli Access Manager - Guide d’administration WebSEAL
pouvant être utilisées par le service d’autorisation d’Access Manager pour accorder ou refuser l’accès aux ressources. Cette approche souple de l’authentification permet de baser les règles de sécurité sur les besoins de l’entreprise et non sur la topologie physique du réseau.
Objectifs de l’authentification Bien que WebSEAL soit indépendant du processus d’authentification, il a besoin de ses résultats : l’identité du client. Le processus d’authentification se décompose comme suit 1. La méthode d’authentification aboutit à l’identité d’un client L’authentification client n’est réussie que si l’utilisateur dispose d’un compte défini dans le registre d’utilisateurs Access Manager ou s’il est traité avec succès par un CDAS. Sinon, l’utilisateur est désigné comme non authentifié. Les informations d’identité spécifiques d’une méthode, comme les mots de passe, les jetons et les certificats, représentent les propriétés d’identité physiques de l’utilisateur. Elles peuvent servir à établir une session sécurisée avec le serveur. 2. WebSEAL se sert de l’identité pour acquérir des données d’autorisation pour ce client. WebSEAL fait correspondre l’identité du client avec un utilisateur Access Manager enregistré. Il se procure ensuite les données d’autorisation appropriées à cet utilisateur (acquisition des données d’autorisation). Les données d’autorisation résultantes, qui représentent les droits d’accès d’un utilisateur sur le domaine sécurisé, décrivent l’utilisateur dans un contexte spécifique et ne sont valides que pour la durée de la session. Ces droits d’accès se composent de l’identité de l’utilisateur, des membres du groupe et de tous les attributs de sécurité spécifiques “étendus”. Si un utilisateur n’est pas membre du registre d’utilisateurs (“anonyme”), WebSEAL crée des droits d’accès non authentifiés pour cet utilisateur. Souvenez-vous qu’une LCA peut contenir certaines règles spécifiques qui régissent les utilisateurs non authentifiés. Ces données d’autorisation sont à la disposition du service d’autorisation, qui accorde ou refuse l’accès aux objets demandés dans l’espace objet protégé par WebSEAL. Les données d’autorisation peuvent être utilisées par tout service Access Manager demandant des informations sur le client. Elles permettent à Access Manager d’exécuter en toute sécurité une multitude de services, comme une autorisation, un audit et une délégation. Access Manager opère la distinction entre l’authentification de l’utilisateur et l’acquisition des données d’autorisation. L’identité d’un utilisateur reste constante, alors que les données d’autorisation, qui définissent les groupes ou rôles auxquels se rattache un utilisateur, varient. Les données d’autorisation, spécifiques d’un contexte, peuvent changer dans le temps. Par exemple, à la promotion d’une personne, les données d’autorisation doivent refléter le nouveau niveau de responsabilité. Pour plus d’informations sur la prise en charge de méthodes d’authentification spécifiques, reportez-vous au Chapitre 5, «Authentification WebSEAL» à la page 111.
Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL
11
Accès authentifié et non authentifié aux ressources Au sein de l’environnement de domaine sécurisé d’Access Manager, l’identité d’un utilisateur est vérifiée dans WebSEAL grâce au processus d’authentification. En règle générale, un utilisateur peut participer au domaine sécurisé en tant qu’utilisateur authentifié ou non authentifié. Dans les deux cas, le service d’autorisation d’Access Manager nécessite l’utilisation des droits d’accès des utilisateurs pour prendre des décisions d’autorisation pour les requêtes relatives à des ressources du domaine sécurisé.WebSEAL gère différemment les droits d’accès des utilisateurs selon qu’ils sont authentifiés ou non. Les droits d’accès d’un utilisateur non authentifié représentent uniquement un passeport générique qui permet à l’utilisateur de participer au domaine sécurisé et d’accéder aux ressources disponibles pour les utilisateurs non authentifiés. Les droits d’accès d’un utilisateur authentifié représentent un passeport personnalisé qui décrit un utilisateur spécifique appartenant au registre d’utilisateurs d’Access Manager (ou traité avec succès via un CDAS). Les droits d’accès d’un utilisateur authentifié se composent de l’identité de l’utilisateur, des membres du groupe et de tous les attributs de sécurité spécifiques (“étendus”). Le processus appliqué aux utilisateurs authentifiés est le suivant : v Un utilisateur dépose une demande relative à une ressource protégée par WebSEAL. La protection de cette ressource implique l’authentification de l’utilisateur. WebSEAL demande à l’utilisateur de se connecter. v L’authentification ne peut aboutir que si l’utilisateur est membre du registre d’utilisateurs d’Access Manager ou est géré par une opération CDAS. v Un ID de session WebSEAL est créé pour cet utilisateur. v Des droits d’accès sont créés pour cet utilisateur à partir des informations sur cet utilisateur contenues dans le registre (membres du groupe, par exemple). v L’ID de session et les droits d’accès (ainsi que d’autres données) sont stockés en cache tant qu’entrée de sessions/droits d’accès de WebSEAL. v Lorsque WebSEAL traite cette requête —ainsi que des requêtes se présentant ultérieurement pendant cette session —, il maintient disponibles les informations relatives aux droits d’accès. v Lors de chaque vérification d’autorisation, le service d’autorisation d’Access Manager utilise les informations relatives aux droits d’accès pendant le processus de prise de décision. v Lorsque l’utilisateur se déconnecte, l’entrée mise en cache pour cet utilisateur est supprimée et la session prend fin. Le processus appliqué aux utilisateurs non authentifiés est le suivant : v Un utilisateur dépose une demande relative à une ressource protégée par WebSEAL. La protection de cette ressource n’implique pas l’authentification de l’utilisateur. WebSEAL ne demande pas à l’utilisateur de se connecter. v WebSEAL crée des droits d’accès non authentifiés pour cet utilisateur. v Aucune entrée n’est créée dans le cache de sessions/droits d’accès de WebSEAL. v L’utilisateur peut accéder aux ressources qui contiennent les autorisations appropriées pour le type d’utilisateur non authentifié. v Si l’utilisateur nécessite l’accès à une ressource non disponible pour les utilisateurs non authentifiés, WebSEAL invite l’utilisateur à se connecter.
12
IBM Tivoli Access Manager - Guide d’administration WebSEAL
v Si la connexion aboutit, l’utilisateur devient un utilisateur authentifié. v Dans le cas contraire, le message 403 (“Accès refusé”) s’affiche. L’utilisateur peut continuer à accéder aux autres ressources disponibles pour les utilisateurs non authentifiés.
Structure de la mémoire cache des sessions/des droits d’accès WebSEAL La mémoire cache des sessions WebSEAL est également appelée mémoire cache des droits d’accès WebSEAL. La mémoire cache peut être représentée sous forme de table interne dans laquelle WebSEAL stocke les informations sur toutes les sessions établies par les utilisateurs authentifiés.
Figure 7. Mémoire cache des sessions/des droits d’accès WebSEAL
Chaque session utilisateur est représentée par une entrée dans la table de la mémoire cache. Chaque entrée de mémoire cache contient les types d’informations suivants : v ID de session L’ID de session représente un identificateur unique envoyé avec chaque requête de cet utilisateur. L’ID de session identifie l’entrée spécifique de mémoire cache associée à cet utilisateur. v Données en mémoire cache Les données les plus importantes stockées au sein d’une entrée de mémoire cache sont les données d’autorisation des utilisateurs. Ces données sont requises chaque fois que l’utilisateur effectue une demande relative aux ressources protégées. Le service d’autorisation utilise ces informations pour autoriser ou refuser l’accès à la ressource. WebSEAL peut signaler au moyen d’un “indicateur” une entrée de mémoire cache prenant en charge une fonction spécifique. Par exemple, lorsque la fonction de nouvelle authentification en cas d’inactivité de session est activée, une entrée de mémoire cache est signalée au moyen d’un “indicateur” lorsque la valeur affectée à la durée d’inactivité de la session est atteinte. v Horodateurs La création d’horodateurs pour l’entrée de mémoire cache constitue un point de référence associé à la valeur de durée de session. L’horodateur “Fin du délai d’inactivité” de l’entrée de mémoire cache devient le point de référence du délai d’inactivité. Les données d’autorisation des utilisateurs contiennent les éléments suivants : v Nom d’utilisateur Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL
13
v Membres du groupe v Attributs étendus Les attributs étendus permettent de stocker des données personnalisées dans les données d’autorisation des utilisateurs. Il s’agit par exemple de l’attribut étendu de données d’autorisation tagvalue_user_session_id. La valeur de cet attribut peut être insérée dans un en-tête HTTP afin de permettre le maintien de la session (établie avec un utilisateur) d’un serveur relié au réseau par une jonction.
Explication des jonctions WebSEAL Access Manager fournit des services d’authentification, d’autorisation et de gestion pour un réseau. Dans un réseau basé sur le Web, ces services sont fournis de façon optimale par un ou plusieurs serveurs WebSEAL frontaux qui intègrent et protègent les ressources et les applications Web se trouvant sur des serveurs d’arrière-plan. La liaison entre un serveur WebSEAL et un serveur d’applications Web d’arrière-plan est appelée jonction, ou jonction WebSEAL. Une jonction WebSEAL est une connexion TCP/IP entre un serveur WebSEAL frontal et un serveur d’arrière-plan. Le serveur d’arrière-plan est un autre serveur WebSEAL ou, plus souvent, un serveur d’applications Web tiers. L’espace Web du serveur d’arrière-plan est “connecté” au serveur WebSEAL au niveau d’un point de jonction (montage) désigné de façon explicite dans l’espace de nom WebSEAL. Domaine sécurisé
WebSEAL
/
TCP ou SSL
Client
Serveur d'applications Web
/mnt
Jonction
Figure 8. Connexion par jonctions de WebSEAL avec des serveurs d’arrière-plan
Une jonction permet à WebSEAL d’assurer des services de protection pour le compte du serveur d’arrière-plan. WebSEAL peut exécuter des contrôles d’authentification et d’autorisation sur toutes les requêtes avant de transmettre celles-ci au serveur d’arrière-plan. Si ce dernier exige un contrôle d’accès renforcé sur ses objets, vous devez exécuter d’autres étapes de configuration pour décrire l’espace Web tiers au service de sécurité Access Manager (voir la section «Utilisation de query_contents avec des serveurs tiers» à la page 191). Les jonctions fournissent un environnement évolutif et sécurisé, qui assure des capacités d’équilibrage de charge, de haute disponibilité et de gestion de l’état — fonctions qui sont toutes exécutées de façon transparente pour les clients. En tant qu’administrateur, vous pouvez tirer profit de cette gestion centralisée de l’espace Web.
14
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Les jonctions WebSEAL apportent la valeur ajoutée d’une combinaison logique de l’espace Web d’un serveur d’arrière-plan avec l’espace Web du serveur WebSEAL. Les jonctions entre des serveurs travaillant en collaboration aboutissent à un espace Web unique, unifié et distribué qui fonctionne en douceur et en transparence pour les utilisateurs. Le client n’a jamais besoin de connaître l’emplacement physique d’une ressource Web. WebSEAL convertit les adresses URL logiques dans les adresses physiques attendues par le serveur d’arrière-plan. Les objets Web peuvent être déplacés d’un serveur à l’autre sans que l’accès du client à ces objets en soit affecté. Pour l’administrateur système, un espace Web unifié simplifie la gestion de toutes les ressources. Les autres avantages administratifs incluent l’évolutivité, l’équilibrage de charge et la haute disponibilité.
/
Espace Web WebSEAL
point de jonction
/
Espace Web combiné : WebSEAL plus serveur relié par jonction
Figure 9. La jonction WebSEAL aboutit à un espace Web unifié
La plupart des serveurs Web du commerce ne sont pas à même de définir un espace objet Web logique. Leur contrôle d’accès est connecté à la structure de répertoires et de fichiers physiques. Les jonctions WebSEAL peuvent définir de façon transparente un espace objet qui reflète la structure organisationnelle plutôt que la machine physique et la structure des répertoires que l’on trouve généralement sur les serveurs Web standard. Les jonctions WebSEAL vous permettent également de créer des solutions à connexion unique. Une configuration à connexion unique permet à un utilisateur d’accéder à une ressource, quel que soit l’emplacement de cette dernière,
Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL
15
uniquement à partir de la connexion initiale. Toute autre exigence de connexion provenant des serveurs d’arrière-plan est traitée de façon transparente pour l’utilisateur. Les jonctions WebSEAL constituent un outil important d’évolutivité de votre site Web. Elles vous permettent de répondre à des demandes en augmentation sur un site Web, en rattachant des serveurs supplémentaires.
Jonctions WebSEAL et évolutivité de site Web Les jonctions WebSEAL servent à créer un site Web évolutif. Au fur et à mesure que les demandes augmentent au niveau du site Web, il est plus facile d’ajouter d’autres serveurs pour développer les capacités du site. Il est possible d’ajouter des serveurs supplémentaires pour les raisons suivantes : v Pour développer un site en y rajoutant du contenu v Pour dupliquer le contenu existant en vue d’un équilibrage de charge, d’une fonction de secours et d’une haute disponibilité
Serveurs WebSEAL frontaux répliqués La prise en charge de la jonction pour les serveurs d’arrière-plan commence avec au moins un serveur frontal WebSEAL. Les serveurs frontaux WebSEAL répliqués dotent le site d’un équilibrage de charge pendant les périodes de forte demande. Le mécanisme d’équilibrage de charge est géré par un mécanisme comme IBM Network Dispatcher ou Cisco Local Director. La réplication frontale dote également le site d’une fonction de secours (si le serveur tombe en panne pour une raison ou une autre, les autres serveurs de réplique continuent à fournir l’accès au site). Un bon équilibrage de charge combiné à une capacité de fonction de secours aboutissent à une haute disponibilité pour les utilisateurs du site.
Client SSL
Client SSL
Internet
Mécanisme d’équilibrage de charge
Réplique Serveur WebSEAL du serveur WebSEAL principal
Figure 10. Serveurs WebSEAL frontaux répliqués
Lorsque vous répliquez des serveurs frontaux WebSEAL, chaque serveur doit contenir une copie exacte de l’espace Web et de la base de données de jonction.
16
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Les informations de compte pour l’authentification se trouvent dans un registre d’utilisateurs indépendant des serveurs frontaux.
Prise en charge des applications serveur d’arrière-plan Le contenu d’un site Web peut être pris en charge par le serveur WebSEAL lui-même et/ou par des serveurs d’arrière-plan. Le support de la jonction WebSEAL par les serveurs d’arrière-plan vous permet de faire évoluer le site Web en y ajoutant du contenu et des ressources. Chaque serveur d’arrière-plan unique doit être relié au réseau au niveau d’un point de jonction séparé (montage). Au fur et à mesure que la demande d’un contenu supplémentaire devient plus forte, un plus grand nombre de serveurs peut être ajouté par des jonctions. Ce scénario apporte une solution pour les réseaux dont l’investissement existant dans des serveurs Web tiers est déjà lourd.
Client SSL
Client SSL
Internet Mécanisme d’équilibrage de charge
Réplique Serveur WebSEAL du serveur WebSEAL principal
Serveur tiers /engineering
Serveur tiers /sales
Figure 11. Connexion par jonctions de WebSEAL avec des serveurs d’arrière-plan
Le graphique suivant illustre la façon dont les jonctions fournissent un espace objet unifié et logique. Transparent pour l’utilisateur, cet espace Web permet une gestion centralisée.
Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL
17
Arborescence de l’objet Web
/ Jonction Engineering
Jonction Sales
Figure 12. Espace Web unifié
Les serveurs d’arrière-plan répliqués sont reliés au réseau par une jonction au même point de jonction, comme expliqué à la section suivante.
Serveurs d’arrière-plan répliqués Pour étendre les fonctions d’évolutivité à une configuration avec des serveurs d’arrière-plan, vous pouvez utiliser la réplication de serveurs d’arrière-plan. Comme dans le cas des serveurs frontaux répliqués, les serveurs d’arrière-plan répliqués doivent contenir des espaces Web qui constituent le reflet les uns des autres. WebSEAL effectue un équilibrage de charge entre les serveurs répliqués à l’aide d’un algorithme d’ordonnancement déterminant le serveur le “moins occupé”. Cet algorithme dirige chaque nouvelle requête vers le serveur comportant le nombre de connexions en cours le plus faible. WebSEAL déclenche également correctement la fonction de secours lorsqu’un serveur est en panne et commence à réutiliser le serveur lorsqu’il est redémarré. Si l’application d’arrière-plan exige que son état soit maintenu pendant plusieurs pages, des jonctions avec conservation de l’état peuvent être utilisées pour garantir que chaque session renvoie au même serveur d’arrière-plan.
18
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Internet Client SSL
Client SSL Mécanisme d’équilibrage de charge
Serveur WebSEAL principal
Réplique du serveur WebSEAL
Serveurs répliqués frontaux
Répliques du serveur Engineering
Répliques du serveur Sales
Figure 13. Serveurs d’arrrière-plan répliqués
Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL
19
20
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Chapitre 2. Configuration de base du serveur Ce chapitre contient des informations sur les tâches génériques d’administration et de configuration à exécuter pour personnaliser le serveur WebSEAL en fonction de votre réseau. Index des rubriques : v «Informations générales sur le serveur» à la page 21 v «Utilisation du fichier de configuration WebSEAL» à la page 23 v «Configuration des paramètres de communication» à la page 26 v «Gestion de l’espace Web» à la page 28 v v v v v v
«Gestion des pages personnalisées de messages d’erreur HTTP» à la page 34 «Gestion des pages personnalisées de gestion de comptes» à la page 37 «Gestion des certificats côté client et côté serveur» à la page 39 «Configuration de la journalisation HTTP par défaut» à la page 44 «Configuration de la journalisation HTTP par défaut» à la page 47 «Consignation des messages de mise en service WebSEAL» à la page 48
Informations générales sur le serveur Les sections ci-après contiennent des informations génériques sur le serveur WebSEAL : v v v v v
«Répertoire racine de l’installation WebSEAL» à la page 21 «Démarrage et arrêt de WebSEAL» à la page 22 «WebSEAL représenté dans l’espace objets protégé» à la page 22 «WebSEAL renvoie HTTP/1.1» à la page 22 «Fichier journal WebSEAL» à la page 23
Répertoire racine de l’installation WebSEAL Les fichiers programme de WebSEAL sont installés dans le répertoire racine suivant : UNIX : /opt/pdweb/
Démarrage et arrêt de WebSEAL Pour démarrer et arrêter le processus du serveur WebSEAL, vous pouvez utiliser la commande pdweb sous UNIX et le panneau de configuration des services sous Windows. UNIX : pdweb {start|stop|restart|status}
La commande pdweb est située dans le répertoire suivant : /usr/bin/
Par exemple, pour arrêter le serveur WebSEAL et le redémarrer, utilisez : # /usr/bin/pdweb restart
Windows : Identifiez le processus du serveur WebSEAL dans le panneau de configuration des services et utilisez les boutons de commande qui conviennent.
WebSEAL représenté dans l’espace objets protégé Le paramètre server-name dans le fichier de configuration webseald.conf spécifie le point au sein de l’espace objets protégé qui représente cette instance de serveur WebSEAL. Pour les installations WebSEAL à serveur unique, cette valeur est automatiquement définie à l’aide du nom de la machine sur laquelle ce serveur WebSEAL est installé. Par exemple, si le nom de la machine (l’hôte) est sales1, la valeur affectée à ce paramètre est la suivante : [server] server-name = sales1
La représentation de cette instance de serveur WebSEAL dans l’espace objets protégé Access Manager est alors la suivante : /WebSEAL/sales1
Voir aussi la section «Réplication de serveurs frontaux WebSEAL» à la page 57. Lorsque plusieurs instances de WebSEAL sont installées sur la même machine, cette valeur est définie à l’aide de l’option –i dans le script PDWeb_config (UNIX) ou ivweb_setup (Windows) utilisé pour créer les instances de serveurs multiples WebSEAL. Voir aussi la section «Configuration de plusieurs instances de serveur WebSEAL» à la page 58.
WebSEAL renvoie HTTP/1.1 Les requêtes HTTP/1.0 sont uniquement envoyées aux serveurs reliés au réseau par une jonction si ces serveurs renvoient l’état 400 (requête erronée), l’état 504 (version HTTP non prise en charge) ou si le navigateur du client spécifie HTTP/1.0 dans la requête.
22
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Dans les autres cas, si le serveur d’arrière-plan accepte HTTP/1.1, WebSEAL envoie des requêtes HTTP/1.1. Toutefois, même lorsque WebSEAL envoie une requête HTTP/1.0 à un serveur relié par jonction (et que ce serveur renvoie une réponse HTTP/1.0), WebSEAL renvoie toujours une réponse HTTP/1.1 au navigateur du client.
Fichier journal WebSEAL Le fichier journal WebSEAL enregistre les messages relatifs à la mise en service, tels que les messages d’avertissement et d’erreur destinés au serveur. Le nom et l’emplacement du fichier journal sont définis par le paramètre server-log qui se trouve dans la strophe [logging] du fichier de configuration webseald.conf : UNIX : [logging] server-log = /var/pdweb/log/webseald.log
Windows : [logging] server-log = C:/Program Files/Tivoli/PDWeb/log/webseald.log
Voir aussi la section «Consignation des messages de mise en service WebSEAL» à la page 48.
Utilisation du fichier de configuration WebSEAL Les sections suivantes contiennent des informations sur le fichier de configuration WebSEAL (webseald.conf) : v «Présentation du fichier de configuration webseald.conf» à la page 23 v «Répertoire racine du serveur WebSEAL» à la page 25
Présentation du fichier de configuration webseald.conf Vous pouvez personnaliser le fonctionnement de WebSEAL en configurant les paramètres qui se trouvent dans le fichier de configuration webseald.conf. Ce fichier se situe dans le répertoire suivant : UNIX : /opt/pdweb/etc/
Windows : C:\Program Files\Tivoli\PDWeb\etc\
Les fichiers de configuration Access Manager sont des fichiers texte ASCII et peuvent être modifiés à l’aide d’un éditeur de texte classique. Les fichiers de configuration contiennent des entrées de paramètres au format suivant : paramètre = valeur
L’installation initiale d’Access Manager permet de définir les valeurs par défaut de la plupart des paramètres. Certains paramètres sont statiques et ne changent jamais. D’autres en revanche peuvent être modifiés pour personnaliser les fonctionnalités et les performances d’un serveur.
Chapitre 2. Configuration de base du serveur
23
Chaque fichier contient des sections, également appelées strophes, qui incluent un ou plusieurs paramètres pour une catégorie de configuration spécifique. Les titres de strophes apparaissent entre crochets : [nom_strophe]
Par exemple, la strophe [junction] du fichier de configuration webseald.conf définit les paramètres de configuration qui affectent les jonctions WebSEAL. La strophe [authentication-mechanisms] définit les méthodes d’authentification prises en charge par WebSEAL, ainsi que les fichiers de bibliothèque partagée associés. Les fichiers de configuration contiennent des commentaires qui expliquent l’utilisation de chaque paramètre. Le caractère “#” est utilisé pour désigner une ligne de commentaires. Toutes les lignes de commentaires commencent par le caractère “#”. Par conséquent, le caractère “#” ne peut pas être utilisé comme valeur de paramètre. Remarque : Chaque fois que vous modifiez le fichier webseald.conf, vous devez redémarrer WebSEAL manuellement pour valider les modifications. Voir la section «Démarrage et arrêt de WebSEAL» à la page 22. Le tableau suivant récapitule les sections et les strophes du fichier de configuration webseald.conf : Sections
Voir l’Annexe A, «Références du fichier webseald.conf» à la page 239.
Répertoire racine du serveur WebSEAL Le paramètre server-root situé dans le fichier de configuration webseald.conf définit l’emplacement du serveur WebSEAL pour d’autres paramètres inclus dans ce fichier.Tous les chemins relatifs définis dans les fichiers de configuration webseald.conf sont relatifs à ce répertoire racine. UNIX : [server] server-root = /opt/pdweb/www
Windows : [server] server-root = C:\Program Files\Tivoli\PDWeb\www
Remarque : Normalement, vous ne devez pas modifier ce nom de chemin.
Chapitre 2. Configuration de base du serveur
25
Configuration des paramètres de communication Les sections ci-après contiennent des informations génériques sur le serveur WebSEAL : v «Configuration de WebSEAL pour les requêtes HTTP» à la page 26 v «Configuration de WebSEAL pour les requêtes HTTPS» à la page 26 v «Restriction des connexions à partir de versions SSL spécifiques» à la page 27 v «Paramètres de délai d’expiration pour les communications HTTP/HTTPS» à la page 27 v «Autres paramètres de délai d’expiration du serveur WebSEAL» à la page 28
Configuration de WebSEAL pour les requêtes HTTP WebSEAL gère généralement de nombreuses requêtes HTTP émanant d’utilisateurs non authentifiés. Par exemple, il est fréquent que des utilisateurs anonymes détiennent un accès en lecture seule à des documents sélectionnés dans la section publique de votre site Web. Les paramètres de gestion des requêtes HTTP via le protocole TCP se trouvent dans la strophe [server] du fichier de configuration webseald.conf.
Activation/Désactivation de l’accès HTTP Activez ou désactivez l’accès HTTP lors de la configuration de WebSEAL : http = {yes|no}
Définition de la valeur du port d’accès HTTP Le port d’accès HTTP par défaut est le port 80 : http-port = 80
Pour passer au port 8080, par exemple, définissez : http-port = 8080
Configuration de WebSEAL pour les requêtes HTTPS Les paramètres de gestion des requêtes HTTP via SSL (HTTPS) se trouvent dans la strophe [server] du fichier de configuration webseald.conf.
Activation/Désactivation de l’accès HTTPS Activez ou désactivez l’accès HTTP lors de la configuration de WebSEAL : https = {yes|no}
Définition de la valeur du port d’accès HTTPS Le port d’accès HTTPS par défaut est le port 443 : https-port = 443
Pour passer au port 4343, par exemple, définissez : https-port = 4343
26
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Restriction des connexions à partir de versions SSL spécifiques Vous pouvez activer et désactiver séparément les connexions pour SSL version 2, SSL version 3 et TLS version 1. Les paramètres qui contrôlent les connexions pour des versions SSL et TLS spécifiques sont situés dans la strophe [ssl] du fichier de configuration webseald.conf. Par défaut, toutes les versions SSL et TLS sont activées. [ssl] disable-ssl-v2 = no disable-ssl-v3 = no disable-tls-v1 = no
Paramètres de délai d’expiration pour les communications HTTP/HTTPS WebSEAL utilise la mise en oeuvre GSkit (Global Security Kit) IBM de SSL. Lorsque WebSEAL reçoit une requête d’un client HTTPS, GSKit SSL établit la liaison initiale et gère l’état de la session. WebSEAL prend en charge les paramètres de délai d’expiration suivants pour les communications HTTP et HTTPS. Ces paramètres se trouvent dans la strophe [server] du fichier de configuration webseald.conf. v client-connect-timeout Une fois la liaison initiale établie, ce paramètre indique le délai pendant lequel WebSEAL conserve la connexion pour la requête initiale HTTP ou HTTPS. La valeur par défaut est 120 secondes. [server] client-connect-timeout = 120
v persistent-con-timeout Après la première requête HTTP et la réponse du serveur, ce paramètre contrôle le nombre maximal de secondes pendant lequel WebSEAL conserve une connexion HTTP permanente avant son arrêt. La valeur par défaut est 5 secondes. [server] persistent-con-timeout = 5
Connexion
SSL Handshake
Requête http
Client
Réponse
Contrôlé par GSKit
client-connect-timeout
WebSEAL persistent-con-timeout
Requête http
(HTTP/1.1 uniquement)
Figure 14. Paramètres de délai d’expiration pour les communications HTTP et HTTPS
Chapitre 2. Configuration de base du serveur
27
Autres paramètres de délai d’expiration du serveur WebSEAL Les autres paramètres de délai d’expiration ci-après sont définis dans le fichier de configuration webseald.conf : Paramètre
Description
Valeur par défaut (secondes)
[junction] http-timeout
Valeur de dépassement du délai pour l’envoi vers/la lecture sur un serveur d’arrière-plan via une jonction TCP.
120
[junction] https-timeout
Valeur de dépassement du délai pour l’envoi vers/la lecture sur un serveur d’arrière-plan via une jonction SSL.
120
[cgi] cgi-timeout
Valeur de dépassement du délai pour l’envoi vers/la lecture sur un processus CFI local.
120
[junction] ping-time
WebSEAL effectue un ping périodique en arrière-plan sur chaque serveur relié par jonction pour déterminer s’il fonctionne. Ses tentatives ne se produisent pas à un rythme plus fréquent que toutes les 300 secondes (ou quelle que soit la valeur définie).
300
Gestion de l’espace Web Les sections ci-après décrivent les tâches requises pour gérer l’espace Web : v «Répertoire racine de l’arborescence des documents Web» à la page 28 v «Configuration de l’indexation de répertoires» à la page 29 v «Windows : conventions de dénomination de fichiers pour les programmes CGI» à la page 30 v «Configuration de la mémoire cache d’un document Web» à la page 31 v «Spécification de types de documents à filtrer» à la page 34
Répertoire racine de l’arborescence des documents Web L’emplacement de l’arborescence des documents Web est le chemin absolu à la racine de l’arborescence des document rendus disponibles par WebSEAL. Le nom de ce chemin est représenté par le paramètre doc-root de la strophe [content] du fichier de configuration webseald.conf. L’emplacement par défaut est défini initialement lors de l’installation de WebSEAL : UNIX : [content] doc-root = /opt/pdweb/www/docs
Windows : [content] doc-root = C:\Program Files\Tivoli\PDWeb\www\docs
28
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Cette valeur n’est utilisée qu’une fois : lors du premier démarrage de WebSEAL après l’installation. Elle est ensuite enregistrée dans la base de données des jonctions. Toute modification ultérieure de cette valeur dans webseald.conf reste sans effet. Méthode de modification de la racine du document après l’installation : Après l’installation, vous devez avoir recours à l’utilitaire pdadmin pour modifier la valeur de l’emplacement du répertoire racine des documents. L’exemple suivant (le nom de serveur est websealA) illustre cette procédure : 1. Connectez-vous à pdadmin : # pdadmin pdadmin> login Entrer ID utilisateur : sec_master Entrer mot de passe : pdadmin>
2. Servez-vous de la commande server task list pour afficher tous les points de jonction en cours : pdadmin> server task webseald-websealA list /
3. Servez-vous de la commande server task show pour afficher les détails de la jonction : pdadmin> server task webseald-websealA show / Junction point: / Type: Local Limite matérielle de la jonction : 0 - avec une valeur globale Limite logicielle de la jonction : 0 - avec une valeur globale Unités d’agent actives : 0 Répertoire racine : /opt/PolicyDirector/www/docs
4. Créez une nouvelle jonction locale pour remplacer le point de jonction en cours (l’option -f est nécessaire pour forcer une nouvelle jonction à en remplacer une autre) : pdadmin> server task webseald-websealA create -t local -f -d /tmp/docs / Created junction at /
5. Affichez le nouveau point de jonction : pdadmin> server task webseald-websealA list /
6. Affichez les détails de la jonction : pdadmin> server task webseald-websealA show / Junction point: / Type: Local Limite matérielle de la jonction : 0 - avec une valeur globale Limite logicielle de la jonction : 0 - avec une valeur globale Unités d’agent actives : 0 Répertoire racine : /tmp/docs
Configuration de l’indexation de répertoires Vous pouvez spécifier le nom du fichier par défaut renvoyé par WebSEAL lorsque l’expression URL d’une requête se termine par un nom de répertoire. Si ce fichier par défaut existe, WebSEAL le renvoie au client. S’il n’existe pas, WebSEAL génère de façon dynamique un index de répertoires et renvoie la liste au client. Le paramètre de configuration du fichier d’index des répertoires se trouve dans la strophe [content] du fichier de configuration webseald.conf.
Chapitre 2. Configuration de base du serveur
29
La valeur par défaut du fichier d’index est : [content] directory-index = index.html
Vous pouvez changer ce nom de fichier si votre site respecte une autre convention de dénomination. Par exemple : [content] directory-index = homepage.html
WebSEAL génère de façon dynamique un index des répertoires si le répertoire indiqué dans la requête ne contient pas le fichier d’index défini par le paramètre directory-index. L’index généré contient la liste du contenu du répertoire avec les liens vers chaque entrée du répertoire. L’index est généré uniquement si le client qui demande l’accès au répertoire dispose du droit d’accès (l) “list” dans la LCA de ce répertoire. Vous pouvez configurer les icônes graphiques spécifiques utilisées par WebSEAL pour chaque fichier répertorié dans un index généré. La strophe [content-index-icons] du fichier de configuration webseald.conf contient la liste des types MIME de document ainsi que les fichiers .gif associés qui s’affichent : [content-index-icons] image/*= /icons/image2.gif video/* = /icons/movie.gif audio/* = /icons/sound2.gif text/html = /icons/generic.gif text/* = /icons/text.gif application/x-tar = /icons/tar.gif application/* = /icons/binary.gif
Vous pouvez configurer cette liste de façon à définir d’autres icônes pour chaque type MIME. Les icônes peuvent également être à distance. Par exemple : application/* = http://www.acme.com/icons/binary.gif
Vous pouvez également configurer la valeur de ces icônes supplémentaires : v Icône utilisée pour représenter les sous-répertoires : [icons] diricon = /icons/folder2.gif
v Icône utilisée pour représenter le répertoire parent : [icons] backicon = /icons/back.gif
v Icône utilisée pour représenter les types de fichier inconnus : [icons] unknownicon = /icons/unknown.gif
Windows : conventions de dénomination de fichiers pour les programmes CGI Les paramètres contenus dans la strophe [cgi-types] du fichier de configuration webseald.conf vous permettent de spécifier les types d’extension de fichier Windows qui sont reconnus et exécutés comme des programmes CGI. Le système d’exploitation UNIX n’a aucune exigence en matière d’extension de nom de fichier. Il faut toutefois définir des types d’extension pour les systèmes d’exploitation Windows. La strophe [cgi-types] répertorie tous les types d’extension valides et fait correspondre chaque extension (le cas échéant) à un programme CGI approprié.
30
IBM Tivoli Access Manager - Guide d’administration WebSEAL
[cgi-types] =
Par défaut, seuls les fichiers dont l’extension correspond à l’une de celles répertoriées dans la strophe seront exécutés comme des programmes CGI. Si un programme CGI est doté d’une extension qui ne figure pas dans la liste, il n’est pas exécuté. Les fichiers comportant l’extension .exe sont exécutés comme des programmes Windows par défaut et n’exigent aucune mise en correspondance. Remarque : Cependant, chaque fois que vous voulez installer un fichier .exe sous Windows en vue d’un téléchargement, vous devez renommer l’extension ou installer le fichier comme faisant partie d’une archive (comme .zip). Vous devez fournir les programmes interpréteur appropriés pour les extensions représentant des fichiers script interprétés. Exemples de ces types d’extension : fichiers scripts shell (.sh et .ksh), scripts Perl (.pl) et scripts TCL (.tcl). L’exemple ci-après illustre une configuration de strophe [cgi-types] classique : [cgi-types] bat = cmd cmd = cmd pl = perl sh = sh tcl = tclsh76
Remarque : L’utilisation des fichiers .bat et .cmd est sujette à caution. Soyez très prudent dans leur utilisation car les questions de sécurité inhérentes sont importantes.
Configuration de la mémoire cache d’un document Web Il arrive souvent que les clients soient confrontés à des délais d’accès au réseau et de téléchargement des fichiers à cause de mauvaises performances d’extraction de documents Web. Ces faibles performances peuvent être dues au fait que les documents sont extraits de serveurs d’arrière-plan reliés au réseau ou que le stockage local est lent. La mise en mémoire cache d’un document Web permet la prise en charge de documents de façon locale à partir de WebSEAL plutôt qu’à partir d’un serveur d’arrière-plan via une jonction. La fonction de mise en mémoire cache des documents Web permet de stocker les types de documents Web auxquels vous accédez régulièrement dans la mémoire du serveur WebSEAL. Les clients connaissent alors des délais de réponse beaucoup plus rapides aux requêtes portant sur des documents mis en mémoire cache dans le serveur WebSEAL. Les documents placés dans la mémoire cache peuvent être aussi bien des documents de texte statique que des images graphiques. Les documents générés de façon dynamique, comme les résultats d’une interrogation de base de données, ne peuvent en revanche pas être placés dans la mémoire cache. La mise en mémoire cache s’exécute sur la base du type MIME. Lorsque vous configurez WebSEAL pour la mise en mémoire cache d’un document Web, vous identifiez les trois paramètres suivants : v Type de document MIME Chapitre 2. Configuration de base du serveur
31
v Type de support de stockage v Taille de support de stockage Vous définissez la mise en mémoire cache de documents Web dans la strophe [content-cache] du fichier de configuration webseald.conf. La syntaxe suivante s’applique : = : Paramètre
Description
type_mime
Représente tout type MIME valide fourni dans une en-tête de réponse “Type_contenu :” HTTP. Cette valeur peut contenir un caractère générique ( * ). La valeur */* représente une mémoire cache d’objet par défaut qui contiendra tout objet ne correspondant pas à une mémoire cache configurée de façon explicite.
type_cache
Spécifie le type de support de stockage à utiliser pour la mémoire cache. Cette édition d’Access Manager ne prend en charge que les “mémoires caches”.
taille_cache
Spécifie la taille maximale (en kilo-octets) de la mémoire cache, avant suppression des objets suivant l’algorithme d’ancienneté.
Conditions affectant la mise en mémoire cache de documents Web La méthode de mise en mémoire cache de documents Web respecte ces conditions : v La mise en mémoire cache ne se produit qu’à la définition d’une mémoire cache dans le fichier webseald.conf. v Par défaut, aucune mémoire cache n’est définie lors de l’installation. v Si vous ne spécifiez pas de mémoire cache par défaut, les documents ne correspondant à aucune mémoire cache explicite ne sont pas placés dans la mémoire cache. v Une autorisation est toujours exécutée sur toutes les requêtes portant sur des informations placées dans la mémoire cache. v La méthode de mise en mémoire cache ne contient pas les réponses aux requêtes contenant des chaînes de requête. v La méthode de mise en mémoire cache ne contient pas les réponses aux requêtes acheminées via des jonctions configurées à l’aide des options –c et –C.
Vidage de toutes les mémoires cache Vous pouvez vous servir de l’utilitaire pdadmin pour vider toutes les mémoires cache configurées. Cet utilitaire ne permet pas de vider des mémoires cache individuelles. Vous devez vous connecter au domaine sécurisé comme administrateur Access Manager sec_master avant d’utiliser pdadmin.
32
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Pour vider toutes les mémoires cache des documents Web, entrez la commande suivante : UNIX : # pdadmin server task webseald- cache flush all
Windows : MSDOS> pdadmin server task webseald- cache flush all
Contrôle de la mise en cache de documents spécifiques Vous pouvez contrôler la mise en mémoire cache de documents spécifiques en associant une règle POP (Protected Object Policy) aux objets correspondants. Cette règle POP doit contenir l’attribut étendu document-cache-control. L’attribut étendu document-cache-control reconnaît les deux valeurs suivantes : Valeur
Description
no-cache
La valeur no-cache indique à WebSEAL qu’il ne doit pas placer ce document en mémoire cache. Souvenez-vous que tous les enfants de l’objet associé à la règle POP héritent également des conditions de cette règle.
public
La valeur public autorise WebSEAL à mettre le document en mémoire cache en ignorant le fait que la jonction a été créée à l’aide de l’option –c ou –C. En outre, cette valeur permet la mise en mémoire cache de ce document lorsque la requête est envoyée avec un en-tête d’autorisation (comme pour l’authentification de base). Cette condition inclut également une requête via laquelle WebSEAL insère des informations BA au nom du client (avec GSO ou jonctions –b supply, par exemple). Normalement, les serveurs proxy ne mettent pas en mémoire cache les réponses aux requêtes qui incluent des en-têtes d’autorisation.
Utilisez les commandes pdadmin pop create, pdadmin pop modify et pdadmin pop attach. L’exemple suivant illustre la création d’une règle POP appelée “doc-cache” à l’aide de l’attribut étendu document-cache-control et de son association à un objet (budget.html ) : pdadmin> pop create doc-cache pdadmin> pop modify doc-cache set attribute document-cache-control no-cache pdadmin> pop attach /WebSEAL/hostA/junction/budget.html doc-cache
Le document budget.html n’est jamais placé en mémoire cache par WebSEAL. Chaque requête relative à ce document doit être envoyée directement au serveur d’arrière-plan sur lequel il réside. Vous trouverez des informations détaillées sur l’utilitaire de ligne de commande pdadmin dans le document IBM Tivoli Access Manager Base Administrator’s Guide.
Chapitre 2. Configuration de base du serveur
33
Spécification de types de documents à filtrer Vous pouvez spécifier les types de contenu de documents que WebSEAL filtre dans les réponses des serveurs reliés par jonction. Le paramètre type de la strophe [filter-content-types] du fichier de configuration webseald.conf accepte les valeurs de type MIME.WebSEAL est configuré par défaut pour filtrer les documents de deux types MIME : [filter-content-types] type = text/html type = text/vnd.wap.wml
Les spécifications de type MIME figurant dans cette strophe déterminent le filtrage supplémentaire effectué par WebSEAL pour les réponses en provenance de serveurs reliés par jonction. Les autres fonctionnalités de filtrage incluent : v Filtrage des adresses URL strophe [filter-schemes] dans le fichier webseald.conf v Filtrage des attributs d’adresses URL Voir la section «Règles de filtrage d’adresses URL standard pour WebSEAL» à la page 175. v Filtrage des scripts pour les adresses URL absolues Voir la section «Modification des adresses URL absolues avec filtrage de script» à la page 177.
Gestion des pages personnalisées de messages d’erreur HTTP Il arrive que le serveur WebSEAL tente de répondre à une requête et échoue. Différentes raisons peuvent expliquer cet échec. Par exemple : v Un fichier n’existe pas. v Les paramètres d’autorisation empêchent l’accès. v Des programmes CGI ne sont pas exécutables par suite de droits d’accès incorrects aux fichiers UNIX ou autre raison similaire. En cas d’échec à une requête, le serveur renvoie un message d’erreur au navigateur, comme “403 Interdit”, dans une page d’erreur HTML. Plusieurs messages d’erreur sont disponibles, dont chacun est stocké dans un fichier HTML séparé. Ces fichiers sont enregistrés dans le répertoire suivant : UNIX :/www/lib/errors/ Windows :\www\lib\errors\ Le répertoire errors contient un certain nombre de sous-répertoires d’environnement local contenant des versions localisées des fichiers de messages d’erreurs. Par exemple, le chemin du répertoire des messages US/English est : UNIX : /www/lib/errors/en_US Windows :\www\lib\errors\en_US
34
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Les messages de ce répertoire sont au format HTML de façon à pouvoir s’afficher correctement dans un navigateur. Vous pouvez éditer ces pages HTML pour personnaliser leur contenu. Le nom des fichiers correspond à la valeur hexadécimale des codes d’erreur internes renvoyés à l’échec des opérations. Ne modifiez pas ces noms de fichiers. Le tableau ci-après contient la liste des noms de fichiers et du contenu des messages d’erreurs les plus courants : Nom de fichier
132120c8.html
Titre
L’authentification a échoué
Description
Code d’erreur HTTP
Les données d’autorisation n’ont pas pu être extraites du certificat du client utilisé. Les raisons possibles sont les suivantes : v l’utilisateur a fourni un certificat incorrect v le certificat a été refusé v les données d’autorisation de l’utilisateur sont absentes de la base de données d’authentification
38ad52fa.html
Répertoire non vide
L’opération demandée exige le retrait d’un répertoire non vide. Il s’agit d’une opération non autorisée.
38cf013d.html
La mise en antémémoire de la requête a échoué
Les valeurs affectées à request-max-cache ou à request-body-max-read ont été dépassées.
38cf0259.html
Impossible d’établir la connexion utilisateur
La ressource demandée exige que le serveur WebSEAL connecte l’utilisateur à un autre serveur Web. Un incident s’est toutefois produit pendant la tentative d’extraction des informations par WebSEAL.
38cf025a.html
Aucune donnée de connexion pour cet utilisateur
WebSEAL n’a pas pu trouver l’utilisateur GSO correspondant à la ressource demandée.
38cf025b.html
Aucune destination de connexion pour cet utilisateur
WebSEAL n’a pas pu trouver le destinataire GSO correspondant à la ressource demandée.
38cf025c.html
Plusieurs destinations de connexion sont définies pour l’utilisateur
Plusieurs destinataires GSO sont définis pour la ressource demandée. Il s’agit d’une erreur de configuration.
38cf025d.html
Connexion obligatoire
La ressource demandée est protégée par un serveur Web d’arrière-plan relié au réseau, qui exige que WebSEAL se connecte à ce serveur Web. Pour ce faire, l’utilisateur doit d’abord se connecter à WebSEAL.
38cf025e.html
Impossible d’établir la connexion utilisateur
La ressource demandée exige que WebSEAL connecte l’utilisateur à un autre serveur Web. Cependant, les informations de connexion du compte utilisateur sont incorrectes.
38cf025f.html
Question d’authentification inattendue
WebSEAL a reçu une question d’authentification inattendue d’un serveur Web d’arrière-plan relié au réseau par une jonction.
38cf0421.html
Déplacé provisoirement
La ressource demandée a été déplacée provisoirement. Ceci se produit en cas de mauvaise gestion du réacheminement.
302
Chapitre 2. Configuration de base du serveur
35
Nom de fichier
Titre
Description
Code d’erreur HTTP
38cf0424.html
Requête incorrecte
WebSEAL a reçu une requête HTTP incorrecte.
400
38cf0425.html
Connexion obligatoire
La ressource demandée est protégée par WebSEAL, et pour y accéder, vous devez d’abord établir une connexion.
38cf0427.html
Interdit
L’utilisateur ne possède pas de droit d’accès à la ressource demandée.
403
38cf0428.html
Introuvable
La ressource demandée est introuvable.
404
38cf0432.html
Service non disponible
Un service nécessaire à WebSEAL pour traiter votre requête n’est pas disponible.
503
38cf0437.html
Serveur suspendu
Le serveur WebSEAL a été provisoirement suspendu par l’administrateur système. Aucune requête ne sera traitée tant que le serveur ne sera pas remis en service par l’administrateur.
38cf0439.html
Les données de la session ont été perdues
La transaction entre le navigateur et le serveur a occasionné une session avec un serveur relié au réseau par jonction. Ce serveur ne répond plus. WebSEAL a besoin d’un service installé sur ce serveur pour terminer le traitement de votre requête.
38cf0442.html
Service non disponible
Le service nécessaire à WebSEAL se trouve sur un serveur d’arrière-plan relié au réseau par une jonction et sur lequel l’authentification SSL réciproque a échoué.
38cf07aa.html
Le programme CGI a échoué
Un programme CGI n’a pas pu s’exécuter correctement.
default.html
Erreur du serveur
WebSEAL n’a pas pu traiter votre requête suite à une erreur inattendue.
500
deletesuccess.html Terminé
La suppression (DELETE) demandée par le client a 200 abouti.
putsuccess.html
Terminé
L’opération PUT demandée par le client a abouti.
200
relocated.html
Déplacé provisoirement
La ressource demandée a été déplacée provisoirement.
302
websealerror.html
400 Erreur du serveur WebSEAL
Erreur interne du serveur WebSEAL.
400
Prise en charge de macro pour les pages de messages d’erreur HTTP Les macros suivantes permettent de personnaliser les pages d’erreur HTML répertoriées dans la section précédente. Elles remplacent de façon dynamique les informations correspondantes disponibles. Macro
36
Description
%ERROR_CODE%
Valeur numérique du code d’erreur.
%ERROR_TEXT%
Texte associé à un code d’erreur du catalogue de messages.
%METHOD%
Méthode HTTP demandée par le client.
%URL%
Adresse URL demandée par le client.
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Macro
Description
%HOSTNAME%
Nom d’hôte complet.
%HTTP_BASE%
Adresse URL HTTP de base du serveur “http://:/”.
%HTTPS_BASE%
Adresse URL HTTPS de base du serveur “https://:/”.
%REFERER%
Valeur de l’en-tête du référenceur de la requête, ou “Inconnu”, s’il n’y en a pas.
%BACK_URL%
Valeur de l’en-tête du référenceur de la requête, ou “/”, s’il n’y en a pas.
%BACK_NAME%
Valeur “BACK” si un en-tête de référenceur est présent dans la requête, ou “HOME” dans le cas contraire.
Gestion des pages personnalisées de gestion de comptes Access Manager contient des exemples de pages HTML de gestion de comptes qui peuvent être personnalisés pour renfermer des messages spécifiques d’un site ou exécuter des actions spécifiques d’un site. La plupart des formulaires conviennent aux méthodes d’authentification BA, par formulaires et par jeton via HTTP ou HTTPS. Les emplacements des fichiers correspondant à ces formulaires sont définis par le paramètre mgt-pages-root contenu dans la strophe [acnt-mgt] du fichier de configuration webseald.conf. mgt-pages-root = lib/html/
Le répertoire utilisé dépend de la localisation. Ainsi le répertoire utilisé par défaut pour l’anglais US est : lib/html/C
Les fichiers de paramètres régionaux japonais se trouvent dans : lib/html/JP
Valeurs et paramètres de page personnalisée Les valeurs et les paramètres de page HTML spéciaux suivants se trouvent dans la strophe [acnt-mgt] du fichier de configuration webseald.conf. Certaines pages ne sont utilisées que par la méthode de connexion à l’aide de formulaires qui permet de fournir des informations d’identité. Paramètre
Page
Syntaxe
login =
login.html
Connexion à l’aide de formulaires
login-success =
login_success.html
Connexion à l’aide de formulaires
logout =
logout.html
Connexion à l’aide de formulaires
account-locked =
acct_locked.html
Toutes les méthodes
passwd-expired =
passwd_exp.html
Toutes les méthodes
passwd-change =
passwd.html
Toutes les méthodes
passwd-change-success =
passwd_rep.html
Toutes les méthodes
Chapitre 2. Configuration de base du serveur
37
Paramètre
Page
Syntaxe
passwd-change-failure =
passwd.html
Toutes les méthodes
help =
help.html
Toutes les méthodes
token-login =
tokenlogin.html
Connexion par jeton
next-token =
nexttoken.html
Connexion par jeton
stepup-login =
stepuplogin.html
Authentification renforcée
Descriptions de pages HTML personnalisées Masque
Description
login.html
Formulaire de demande standard de nom d’utilisateur et de mot de passe
login_success.html
Page affichée une fois la connexion établie.
logout.html
Page affichée une fois la déconnexion terminée.
acct_locked.html
Page affichée si l’authentification de l’utilisateur échoue à cause d’un compte verrouillé.
passwd_exp.html
Page affichée si l’authentification de l’utilisateur échoue en raison de l’expiration d’un mot de passe.
passwd.html
Formulaire de modification de mot de passe. S’affiche également si la requête de modification de mot de passe échoue.
passwd_rep.html
Page affichée si la requête de modification de mot de passe aboutit.
help.html
Page contenant les liens pour valider les pages d’administration.
tokenlogin.html
Formulaire de connexion par jeton.
nexttoken.html
Formulaire de jeton suivant.
stepuplogin.html
Formulaire de connexion par authentification renforcée.
Prise en charge de macro pour les pages de gestion des comptes Il existe également deux macros pour ces pages. Ces chaînes de macros peuvent être placées dans les fichiers modèles. La macro remplace de façon dynamique les valeurs appropriées. Macro
38
Description
%USERNAME%
Nom de l’utilisateur connecté.
%ERROR%
Message d’erreur défini dans le code renvoyé par Access Manager.
%METHOD%
Méthode HTTP demandée par le client.
%URL%
Adresse URL demandée par le client.
%HOSTNAME%
Nom d’hôte complet.
%HTTP_BASE%
Adresse URL HTTP de base du serveur “http://:/”.
%HTTPS_BASE%
Adresse URL HTTPS de base du serveur “https://:/”.
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Macro
Description
%REFERER%
Valeur de l’en-tête du référenceur de la requête, ou “Inconnu”, s’il n’y en a pas.
%BACK_URL%
Valeur de l’en-tête du référenceur de la requête, ou “/”, s’il n’y en a pas.
%BACK_NAME%
Valeur “BACK” si un en-tête de référenceur est présent dans la requête, ou “HOME” dans le cas contraire.
Gestion des certificats côté client et côté serveur Cette section décrit les tâches d’administration et de configuration requises pour configurer WebSEAL en vue d’une gestion des certificats numériques côté client et côté serveur, servant à l’authentification via SSL. WebSEAL a besoin de certificats dans les cas suivants : v WebSEAL s’identifie auprès des clients SSL avec son certificat côté serveur v WebSEAL s’identifie auprès d’un serveur d’arrière-plan relié au réseau par une jonction (configuré pour une authentification réciproque) avec un certificat côté client v WebSEAL se réfère à sa base de données de certificats racine de l’autorité de certification (CA) pour valider les clients dotés de certificats côté client v WebSEAL se réfère à sa base de données de certificats racine CA pour valider les serveurs d’arrière-plan reliés au réseau par jonction, configurés pour une authentification réciproque WebSEAL utilise l’implémentation de GSKit (Global Security Kit) IBM de SSL pour configurer et administrer les certificats numériques. GSKit contient l’utilitaire iKeyman qui permet de configurer et de gérer la base de données des clés de certificat contenant un ou plusieurs certificats serveur/client WebSEAL et les certificats racine de CA. WebSEAL inclut les composants suivants, lors de l’installation, pour prendre en charge l’authentification SSL via des certificats numériques : v Une base de données de clés par défaut (pdsrv.kdb) v Un fichier caché (pdsrv.sth) et un mot de passe (“pdsrv”) de la base de données de clés par défaut v Plusieurs certificats racine de CA usuels v Un certificat de test d’auto-signature dont WebSEAL peut se servir pour s’identifier auprès des clients SSL Il est conseillé de vous adresser à une autorité de certification reconnue pour remplacer le certificat de test par un certificat couramment accepté. La configuration de gestion du certificat WebSEAL comprend les étapes suivantes : v «Configuration de paramètres de base de données de clés» à la page 41 v «Utilisation de l’utilitaire de gestion de certificat iKeyman» à la page 42 v «Configuration du contrôle CRL» à la page 42
Chapitre 2. Configuration de base du serveur
39
Présentation des types de fichier de la base de données de clés L’outil IBM Key Management (iKeyman) utilise plusieurs types de fichier répertoriés dans le tableau suivant. Une base de données de clés CMS contient un fichier avec l’extension .kdb, voire plusieurs autres fichiers. Le fichier .kdb est créé en même temps qu’une nouvelle base de données de clés. Un enregistrement de clé contenu dans un fichier .kdb peut correspondre à un certificat ou à un certificat avec des informations chiffrées sur les clés privées. Les fichiers .rdb et .crl sont créés en même temps qu’une nouvelle demande de certificat. Le fichier .rdb est nécessaire tout au long du traitement de la demande de certificat de CA. Type de fichier
Description
.kdb
Fichier de la “base de données de clés”. Stocke les certificats personnels, les demandes de certificat personnel et les certificats de signataire. Par exemple, le fichier de la base de données de clés WebSEAL est pdsrv.kdb.
.sth
Fichier “caché”. Stocke une version chiffrée du mot de passe de la base de données de clés. Le nom dérivé de ce fichier est identique à celui du fichier .kdb associé.
.rdb
Fichier de la base de données de “demandes”. Créé automatiquement en même temps qu’un fichier de base de données de clés .kdb. Le nom dérivé de ce fichier est identique à celui du fichier .kdb associé. Ce fichier contient des demandes de certificat en attente qui n’ont pas été renvoyées par la CA. Lorsque la CA renvoie un certificat, la demande de certificat correspondante est recherchée dans le fichier .rdb (en fonction de la clé publique). Si une correspondance est trouvée, le certificat est renvoyé et la demande de certificat correspondante est supprimée du fichier .rdb. Si aucune correspondance n’est trouvée, la tentative de renvoi du certificat est rejetée. La demande de certificat inclut le nom de l’utilisateur, l’entreprise, l’adresse, d’autres informations définies en même temps que la requête ainsi que les clés publique et privée associées à cette demande.
.crl
Fichier de la “liste de révocation des certificats”. Normalement, ce fichier contient la liste des certificats ayant été refusés pour une raison quelconque. Toutefois, iKeyman ne fournit aucune prise en charge des listes de révocation des certificats ; c’est pourquoi ce fichier est vide.
.arm
Fichier binaire codé ASCII. Un fichier .arm contient une représentation ASCII codée en Base64 d’un certificat, y compris sa clé publique, mais pas sa clé privée. Les données de certificat binaire d’origine sont converties en représentation ASCII. Lorsqu’un utilisateur reçoit un certificat dans un fichier .arm, iKeyman décode la représentation ASCII et place la représentation binaire dans le fichier .kdb qui convient. De même, lorsqu’un utilisateur extrait un certificat d’un fichier .kdb, iKeyman convertit les données binaires en données ASCII et les place dans un fichier .arm. Les données ASCII du fichier .arm sont celles que vous envoyez à la CA lors du processus de demande de certificat. Remarque : Vous pouvez utiliser n’importe quel type de fichier (différent de .arm), à condition qu’il s’agisse d’un fichier codé en Base64.
.der
Fichier de “règles de codage distinctif”. Un fichier .der contient la représentation binaire d’un certificat, y compris sa clé publique mais pas sa clé privée. Il ressemble fortement à un fichier .arm sauf que la représentation est binaire et non pas ASCII.
.p12
Fichier “PKCS 12” où PKCS signifie “Public-Key Cryptography Standards” (normes de cryptographie de clé publique). Un fichier .p12 contient la représentation binaire d’un certificat, y compris sa clé publique et sa clé privée. Un fichier .p12 peut également contenir plusieurs certificats (par exemple, un certificat, le certificat de la CA ayant émis le certificat, l’émetteur du certificat de la CA, son émetteur, etc). Dans la mesure où un fichier .p12 contient une clé privée, il est protégé par un mot de passe.
40
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Configuration de paramètres de base de données de clés Fichier de clés de certificat WebSEAL : Lors de l’installation, WebSEAL fournit une base de données de clés de certificat par défaut. Le paramètre webseal-cert-keyfile, qui se trouve dans la strophe [ssl] du fichier de configuration webseald.conf, identifie le nom et l’emplacement de ce fichier : [ssl] webseal-cert-keyfile = /var/pdweb/www/certs/pdsrv.kdb
Vous pouvez vous servir de l’utilitaire iKeyman pour créer une nouvelle base de données de clés. Cependant, vous devez entrer le nom et l’emplacement de ce nouveau fichier de clés dans le paramètre webseal-cert-keyfile pour que WebSEAL puisse localiser et utiliser les certificats contenus dans cette base de données. Mot de passe du fichier de clés de certificat : A l’installation, WebSEAL fournit également un fichier caché par défaut qui contient le mot de passe du fichier de clés pdsrv.kdb. Le paramètre webseal-cert-keyfile-stash informe WebSEAL de l’emplacement du fichier caché : webseal-cert-keyfile-stash = /var/pdweb/www/certs/pdsrv.sth
Le mot de passe par défaut chiffré dans ce fichier caché est “pdsrv”. Vous pouvez également indiquer un mot de passe comme du texte simple dans le paramètre webseal-cert-keyfile-pwd. Par exemple : webseal-cert-keyfile-pwd = pdsrv
A l’installation, WebSEAL utilise le fichier caché pour obtenir le mot de passe du fichier de clés. Le paramètre webseal-cert-keyfile-pwd est placé en commentaire. L’utilisation du fichier caché vous dispense d’afficher le mot de passe sous forme de texte dans le fichier de configuration webseald.conf. Remarque : Annulez la mise en commentaire du paramètre du mot de passe spécifique que vous voulez utiliser. Si le mot de passe et le fichier caché sont tous les deux spécifiés, la valeur du mot de passe est utilisée. Certificat de test WebSEAL : A l’installation, WebSEAL fournit un certificat de test d’auto-signature non sécurisé. Le certificat de test, qui sert de certificat côté client, permet à WebSEAL de s’identifier auprès des clients SSL. Pour mieux contrôler l’utilisation de ce certificat de test, le certificat n’est pas installé comme certificat par défaut. Le paramètre webseal-cert-keyfile-label désigne le certificat comme certificat côté client actif et remplace tous les autres certificats “par défaut” dans la base de données du fichier de clés. webseal-cert-keyfile-label = WebSEAL
Bien que ce certificat de test permette à WebSEAL de répondre à une requête d’un navigateur activé SSL, il ne peut pas être vérifié par le navigateur (qui ne contient pas de certificat d’autorité de certification approprié). Comme la clé privée de ce certificat par défaut se trouve dans chaque distribution WebSEAL, ce certificat n’assure pas de véritables communications sécurisées.
Chapitre 2. Configuration de base du serveur
41
Vous devez avoir recours à l’utilitaire iKeyman pour générer une demande de certificat qui peut être envoyée à une autorité de certification (CA). Utilisez iKeyman pour installer le certificat de serveur renvoyé et lui affecter un libellé. Si vous utilisez différents certificats pour d’autres scénarios (par exemple, les jonctions –K), vous pouvez vous servir de l’utilitaire iKeyman pour les créer, les installer et leur affecter un libellé. Le libellé des fichiers de clés ne doit pas contenir d’espace. WebSEAL (qui s’exécute par défaut en tant que user ivmgr) doit détenir des droits d’accès en lecture (r) sur ces fichiers de base de données de clés. Communications SSL internes avec les serveurs Access Manager : La strophe [ssl] du fichier de configuration webseald.conf contient quatre autres paramètres destinés à configurer le fichier de clés utilisé par WebSEAL pour les communications SSL internes avec les autres serveurs Access Manager. Vous pouvez modifier ces paramètres uniquement à l’aide du script de configuration pdconfig. [ssl] ssl-keyfile = ssl-keyfile-pwd = ssl-keyfile-stash = ssl-keyfile-label =
Utilisation de l’utilitaire de gestion de certificat iKeyman L’utilitaire iKeyman est un outil livré avec GSKit qui permet de gérer les certificats numériques utilisés par WebSEAL. Servez-vous de iKeyman pour : v v v v v
créer une ou plusieurs bases de données de clés, modifier les mots de passe de connexion à la base de données de clés, créer de nouveaux certificats WebSEAL, définir un nouveau certificat WebSEAL par défaut, créer un certificat d’auto-signature pour test,
v demander et recevoir des certificats racine de CA, v ajouter des certificats dans la base de données, et en supprimer, v copier des certificats d’une base de données à une autre.
Configuration du contrôle CRL La liste LRC (Liste de révocation des certificats) constitue une méthode qui empêche la validation des certificats non souhaités. Elle contient les identités des certificats jugées non fiables. La mise en oeuvre GSKit de SSL utilisée par WebSEAL prend en charge le contrôle LRC. GSKit permet à WebSEAL d’exécuter le contrôle LRC sur les certificats côté client et sur les certificats émanant de jonctions SSL. WebSEAL doit connaître l’emplacement de cette liste pour exécuter le contrôle LRC. Vous pouvez trouver les paramètres liés à l’emplacement du serveur LDAP pouvant servir de référence pour le contrôle LRC pendant l’authentification par certificat dans la strophe [ssl] du fichier de configuration webseald.conf. [ssl] #ssl-ldap-server = #ssl-ldap-server-port = #ssl-ldap-user = #ssl-ldap-user-password =
42
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Par défaut, le contrôle LRC est désactivé (les paramètres sont placés en commentaire). Pour activer le contrôle LRC pendant l’authentification par certificat, annulez la mise en commentaire et entrez les valeurs appropriées. Une valeur nulle pour ssl-ldap-user indique que la méthode d’authentification SSL doit s’associer au serveur LDAP en tant qu’utilisateur anonyme.
Configuration du cache CRL GSKit permet à WebSEAL d’exécuter le contrôle LRC sur les certificats côté client et sur les certificats émanant de jonctions SSL. Pour améliorer les performances du contrôle CRL, vous pouvez mettre le CRL en mémoire cache à partir d’une autorité d’accréditation spécifique. Les contrôles CRL suivants sont effectués en comparaison avec cette version de la liste mise en mémoire cache. Les valeurs affectées aux deux paramètres du fichier de configuration webseald.conf décrits dans cette section sont directement transmis à l’utilitaire GSKit. Pour plus d’informations sur les fonctionnalités GSKit, reportez-vous à la documentation correspondante.
Définition du nombre maximal d’entrées Le paramètre gsk-crl-cache-size spécifie le nombre maximal d’entrées dans le cache CRL GSKit. Chaque entrée représente un CRL entier associé à une autorité d’accréditation spécifique. La valeur par défaut est “0”. Une valeur supérieure à “0” est requise pour l’activation du cache. Lorsque gsk-crl-cache-size et gsk-crl-cache-entry-lifetime portent la valeur “0” (valeur par défaut), la mise en mémoire cache de CRL est désactivée. [ssl] gsk-crl-cache-size = 0
Définition de la valeur du délai d’expiration de l’entrée de mémoire cache GSKit Le paramètre gsk-crl-cache-entry-lifetime spécifie la valeur de délai d’expiration applicable à toutes les entrées du cache CRL GSKit. La valeur est exprimée en secondes et peut être comprise dans la plage 0-86400 secondes. Lorsque gsk-crl-cache-size et gsk-crl-cache-entry-lifetime portent la valeur “0” (default), la mise en mémoire cache de CRL est désactivée. [ssl] gsk-crl-cache-size = 0
Chapitre 2. Configuration de base du serveur
43
Configuration de la journalisation HTTP par défaut WebSEAL gère trois fichiers journaux HTTP classiques qui enregistrent l’activité plutôt que les messages : v request.log v agent.log v referer.log Par défaut, ces fichiers journaux sont conservés dans le répertoire suivant : UNIX : /var/pdweb/www/log/
Windows : C:\Program Files\Tivoli\PDWeb\www\log\
Les paramètres de configuration de la journalisation HTTP standard se trouvent dans la strophe [logging] du fichier de configuration webseald.conf. Le tableau ci-après illustre les relations entre les fichiers journaux HTTP et les paramètres du fichier de configuration : Fichiers journaux
Paramètre d’emplacement
Paramètre d’activation/désactivation Activation/désactivation du paramètre ( = yes ou no)
request.log
requests-file
requests
referer.log
referers-file
referers
agent.log
agents-file
agents
Par exemple, l’entrée de l’emplacement par défaut du fichier request.log apparaît comme suit : UNIX : requests-file = /var/pdweb/www/log/request.log
Windows : requests-file = \Program Files\Tivoli\PDWeb\www\log\request.log
Activation et désactivation de la journalisation HTTP Par défaut, la journalisation HTTP est totalement activée : [logging] requests = yes referers = yes agents = yes
Chaque journal peut être activé ou désactivé indépendamment des autres. Si un paramètre est défini à “no”, la journalisation est désactivée pour ce fichier. Une fois l’activée, la consignation HTTP WebSEAL par défaut est en réalité gérée par la méthode de consignation d’événements d’Access Manager, conformément à la description de la section «Configuration de la journalisation HTTP par défaut» à la page 47.
44
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Spécification du type d’horodatage Vous pouvez choisir d’avoir les données d’horodatage enregistrées dans chaque journal en heure GMT (Greenwich Mean Time) plutôt que dans la zone horaire locale. Par défaut, la zone horaire locale est utilisée : [logging] gmt-time = no
Pour utiliser les données d’horodatage GMT, définissez : gmt-time = yes
Spécification du seuil de renouvellement des fichiers journaux Le paramètre max-size indique la taille maximale que peut atteindre un fichier journal HTTP et a la valeur par défaut suivante (en octets) : [logging] max-size = 2000000
Lorsqu’un fichier journal atteint la valeur spécifiée (ou seuil de renouvellement), le fichier existant est sauvegardé dans un fichier du même nom, auquel sont ajoutées la date et l’horodate en cours. Un nouveau fichier journal est alors démarré. Les différentes valeurs max-size possibles sont interprétées comme suit : v Si la valeur max-size est inférieure à zéro (< 0), un nouveau fichier journal est créé à chaque appel du processus de journalisation et toutes les 24 heures à partir de cette instance. v Si la valeur max-size est égale à zéro (= 0), aucun roulement n’est exécuté et le fichier journal augmente à l’infini. Si un fichier journal existe déjà, aucune nouvelle donnée n’y est ajoutée. v Si la valeur max-size est supérieure à zéro (> 0), un roulement s’effectue lorsqu’un fichier journal atteint la valeur de seuil configurée. Si un fichier journal existe déjà au démarrage, aucune nouvelle donnée n’y est ajoutée.
Spécification de la fréquence de vidage des mémoires tampon de fichier journal Les fichiers journaux sont enregistrés dans des flux de données mises en mémoire tampon. Si vous contrôlez les fichiers journaux en temps réel, vous voudrez peut-être modifier la fréquence à laquelle le serveur force un vidage des mémoires tampon des fichiers journaux. Par défaut, les fichiers journaux sont vidés toutes les 20 secondes : [logging] flush-time = 20
Si vous spécifiez une valeur négative, un vidage sera forcé après chaque enregistrement.
Format de journal HTTP courant (pour request.log) Chaque réponse (succès ou échec) renvoyée par le serveur Access Manager est enregistrée avec une entrée d’une ligne dans le fichier request.log à l’aide du format de journal HTTP courant suivant : host - authuser [date] request status bytes
Chapitre 2. Configuration de base du serveur
45
où : host
Indique l’adresse IP de la machine émettant la requête.
authuser
Ce champ prend la valeur de l’en-tête From: de la requête HTTP reçue. La valeur “unauth” est utilisée pour un utilisateur non authentifié.
date
Indique la date et l’heure de la requête.
request
Indique la première ligne de la requête telle qu’elle a été émise par le client.
status
Indique le code d’état HTTP renvoyé à la machine émettant la requête.
bytes
Indique le nombre d’octets renvoyés à la machine émettant la requête. Cette valeur (qu’il s’agisse de la taille du contenu non filtré ou d’une taille de zéro octet) est configurée avec le paramètre log-filtered-pages.
Affichage du fichier request.log Le journal request.log enregistre la journalisation standard des requêtes HTTP, comme les informations relatives aux adresses URL qui ont été demandées et les informations sur le client (par exemple, l’adresse IP) à l’origine de la requête. L’exemple suivant montre un exemple de fichier request.log : 130.15.1.90 130.15.1.90 130.15.1.90 130.15.1.90 130.15.1.90
Affichage du fichier agent.log Le fichier agent.log enregistre le contenu de l’en-tête User_Agent: dans la requête HTTP. Ce fichier journal révèle des informations sur le navigateur du client, comme l’architecture ou le numéro de version, pour chaque requête. L’exemple suivant montre un exemple de version de fichier agent.log : Mozilla/4.01 Mozilla/4.01 Mozilla/4.01 Mozilla/4.01
[en] [en] [en] [en]
(WinNT; (WinNT; (WinNT; (WinNT;
U) U) U) U)
Affichage du fichier referer.log Le journal referer.log enregistre l’en-tête Referer: de la requête HTTP. Pour chaque requête, le fichier journal enregistre le document qui contenait le lien au document demandé. Le journal utilise le format suivant : référenceur -> objet
Ces informations sont utiles pour effectuer le suivi des liens externes aux documents de votre espace Web. Le journal révèle que la source mentionnée par le référenceur contient un lien à un objet page. Il vous permet de pister les liens périmés et de découvrir les auteurs de liens à vos documents.
46
IBM Tivoli Access Manager - Guide d’administration WebSEAL
L’exemple suivant montre un exemple de fichier referer.log : http://manuel/maybam/index.html -> /pics/tivoli_logo.gif http://manuel/maybam/pddl/index.html ->/pics/tivoli_logo.gif http://manuel/maybam/ -> /pddl/index.html http://manuel/maybam/ -> /pddl/index.html http://manuel/maybam/pddl/index.html ->/pics/tivoli_logo.gif http://manuel/maybam/ -> /pddl/index.html
Configuration de la journalisation HTTP par défaut La journalisation HTTP WebSEAL peut être configurée dans la strophe [aznapi-configuration] du fichier de configuration webseald.conf via l’utilisation du paramètre de journalisation d’événements logcfg pour définir un ou plusieurs agents de journalisation (enregistreurs) chargés de rassembler une certaine catégorie d’informations à partir du pool d’événements et d’acheminer ces informations vers une destination donnée : [aznapi-configuration] logcfg = :{stdout|stderr|file|pipe|remote} [[[=]] [,[=]]...]
Pour plus d’informations sur la configuration de la journalisation d’événements, reportez-vous au chapitre consacré à la “journalisation d’événements” du document IBM Tivoli Access Manager Base Administrator’s Guide. Les valeurs de catégorie adaptées à la journalisation HTTP sont les suivantes : v http Toutes les informations de journalisation HTTP v http.clf Informations sur les requêtes HTTP au format de journalisation courant v http.ref Informations sur l’en-tête du référenceur HTTP v http.agent Informations sur l’en-tête HTTP User_Agent v http.cof Le format combiné NCSA enregistre les informations sur les requêtes HTTP (avec horodatage) et ajoute les chaînes de référenceur et d’agent au format standard. Les configurations suivantes d’agent de journalisation sont activées lorsque les paramètres de journalisation HTTP WebSEAL par défaut sont eux-mêmes activés (reportez-vous à la section «Configuration de la journalisation HTTP par défaut» à la page 44). Il est à noter que les configurations d’agents de consignation acceptent les valeurs des paramètres requests-file, referers-file, agents-file, flush-time et max-size du fichier de configuration webseald.conf (strophe [logging]) : request.log (format de journalisation courant) : logcfg = http.clf:file path=,flush=, \ rollover=,log=clf,buffer_size=8192,queue_size=48
Etant donné que la journalisation HTTP par défaut est configurée dans une strophe différente ([logging]) de celle de la configuration de la journalisation d’événements ([aznapi-configuration]), il est possible que des doublons d’entrées figurent pour chaque événement dans un fichier journal lorsque ces deux modes de journalisation sont activés. Le mode de journalisation d’événements offre davantage de souplesse lors du regroupement des informations de journalisation HTTP et de la personnalisation des résultats.
Consignation des messages de mise en service WebSEAL Les messages de mise en service d’Access Manager WebSEAL sont contrôlés par le fichier d’acheminement d’Access Manager WebSEAL. Le fichier d’acheminement se trouve dans le répertoire suivant : UNIX : /opt/pdweb/etc/
Windows : C:\Program Files\Tivoli\PDWeb\etc\
Le fichier d’acheminement est un fichier ASCII qui contient des documents supplémentaires sous la forme de lignes de commentaires. Les entrées de ce fichier de configuration déterminent les types de messages de mise en service consignés. Pour activer une entrée, supprimez le caractère de commentaire (#). Le fichier d’acheminement inclut les entrées par défaut suivantes : UNIX : FATAL:STDERR:ERROR:STDERR:WARNING:STDERR:#NOTICE:FILE.10.100:/opt/pdweb/log/notice.log #NOTICE_VERBOSE:FILE.10.100:/opt/pdweb/log/notice.log
Windows : FATAL:STDERR:ERROR:STDERR:WARNING:STDERR:#NOTICE:FILE.10.100:%PDWEBDIR%/log/notice.log #NOTICE_VERBOSE:FILE.10.100:%PDWEBDIR%/log/notice.log
Remarque : Sur un système Windows, la variable d’environnement spécifique PDWEBDIR est définie dans le répertoire d’installation de WebSEAL au moment de l’exécution. Par défaut, lorsque WebSEAL est exécuté en arrière-plan, tous les messages sont envoyés à l’écran (STDERR).
48
IBM Tivoli Access Manager - Guide d’administration WebSEAL
De la même façon, par défaut, lorsque WebSEAL est exécuté en arrière-plan, les messages sont réacheminés à partir de STDERR et sont envoyés au fichier journal du serveur WebSEAL, conformément aux indications de la strophe [logging] du fichier de configuration webseald.conf : Serveur
Fichier de configuration
Serveur WebSEAL webseald.conf (webseald)
Emplacement du fichier journal UNIX :[logging] server-log=/var/pdweb/log/webseald.log Windows : [logging] server-log= C:\Program Files\Tivoli\PDWeb\log\webseald.log
Pour activer verbose.log, ne faites aucun commentaire sur la ligne NOTICE_VERBOSE. Le syntaxe de FILE pour le message NOTICE contrôle le renouvellement des journaux et le recyclage des fichiers : FILE..
La valeur affectée à max-file spécifie le nombre de fichiers utilisé. La valeur affectée à max-records spécifie le nombre maximal d’entrées par fichier. Dans l’exemple par défaut ci-dessus, FILE.10.100 signifie qu’il y a 10 fichiers créés, chacun contenant un maximum de 100 entrées. Les fichiers portent les noms suivants : notice.log.1 notice.log.2 . . . notice.log.10
Les messages se présentent “en boucle”, du premier fichier au dernier fichier ayant atteint sa limite ou du démarrage à l’arrêt du serveur. En cas de réutilisation d’un fichier journal, les enregistrements existants sont écrasés (effacés).
Chapitre 2. Configuration de base du serveur
49
50
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Chapitre 3. Configuration avancée du serveur Ce chapitre contient des informations sur les tâches génériques d’administration et de configuration à exécuter pour personnaliser le serveur WebSEAL en fonction de votre réseau. Index des rubriques : v «Configuration d’un niveau de protection par défaut» à la page 51 v «Configuration des mises à jour et de l’interrogation de la base de données d’autorisation» à la page 53 v «Gestion des affectations des unités d’exécution d’agents» à la page 54 v «Réplication de serveurs frontaux WebSEAL» à la page 57 v «Configuration de plusieurs instances de serveur WebSEAL» à la page 58 v «Configuration du changement d’utilisateur pour les administrateurs» à la page 65 v «Configuration de la mise en mémoire cache des requêtes WebSEAL côté serveur» à la page 72 v «Gestion des caractères codés UTF-8» à la page 76 v «Prévention de la vulnérabilité causée par les scripts inter-sites» à la page 77 v «Suppression de l’identité de serveurs» à la page 79 v «Utilisation des statistiques WebSEAL» à la page 79 v «Utilisation de l’utilitaire de trace pour regrouper les actions de WebSEAL» à la page 89
Configuration d’un niveau de protection par défaut Vous pouvez contrôler le niveau de chiffrement par défaut requis pour accéder à WebSEAL via SSL (HTTPS) en configurant le niveau de protection (NDP). La gestion du niveau de protection par défaut est contrôlée par les paramètres de la section “SSL QUALITY OF PROTECTION MANAGEMENT” du fichier de configuration webseald.conf : v Activation et désactivation de la gestion du niveau de protection avec le paramètre ssl-qop-mgmt v Définition des niveaux de chiffrement autorisés dans la strophe [ssl-qop-mgmt-default] 1. Activez la gestion du niveau de protection : [ssl-qop] ssl-qop-mgmt = yes
2. Définissez le niveau de chiffrement par défaut pour l’accès HTTPS : [ssl-qop-mgmt-default] # default = ALL | NONE | # ALL (active toutes les méthodes de chiffrement) # NONE (désactive toutes les méthodes et utilise un total de contrôle MAC MD5) # DES-40 # DES-56 # DES-168 # RC2-40
Notez que vous pouvez également définir un groupe de méthodes de chiffrement : [ssl-qop-mgmt-default] default = RC4-128 default = RC2-128 default = DES-168
Configuration du niveau de protection pour les réseaux et les hôtes individuels Le paramètre ssl-qop-mgmt = yes active également tous les paramètres apparaissant dans les strophes [ssl-qop-mgmt-hosts] et [ssl-qop-mgmt-networks]. Ces strophes autorisent la gestion du niveau de protection par adresse IP d’hôte/de réseau/de masque de réseau. La strophe [ssl-qop-mgmt-default] répertorie les méthodes de chiffrement utilisées pour toutes les adresses IP sans correspondance dans les strophes [ssl-qop-mgmt-hosts] et [ssl-qop-mgmt-networks]. Exemple de syntaxe de configuration pour les hôtes : [ssl-qop-mgmt-hosts] # = ALL | NONE | # ALL (active toutes les méthodes de chiffrement) # NONE (désactive toutes les méthodes et utilise un total de contrôle MAC MD5) # DES-40 # DES-56 # DES-168 # RC2-40 # RC2-128 # RC4-40 # RC4-128 xxx.xxx.xxx.xxx = ALL yyy.yyy.yyy.yyy = RC2-128
Exemple de syntaxe de configuration pour les réseaux/masques de réseau : [ssl-qop-mgmt-networks] # = ALL | NONE | # ALL (active toutes les méthodes de chiffrement) # NONE (désactive toutes les méthodes et utilise un total de contrôle MAC MD5) # DES-40 # DES-56 # DES-168 # RC2-40 # RC2-128 # RC4-40 # RC4-128 xxx.xxx.xxx.xxx/255.255.255.0 = RC4-128 yyy.yyy.yyy.yyy/255.255.0.0 = DES-56
Les strophes [ssl-qop-mgmt-hosts] et [ssl-qop-mgmt-networks] sont fournies pour la compatibilité amont uniquement. Il est recommandé de ne pas les utiliser pour la configuration d’Access Manager.
52
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Configuration des mises à jour et de l’interrogation de la base de données d’autorisation Access Manager Policy Server (pdmgrd) gère la base de données de règles d’autorisation principale et conserve les informations sur les emplacements des autres serveurs Access Manager du domaine sécurisé. Un administrateur Access Manager peut à tout moment apporter des modifications aux règles de sécurité du domaine sécurisé. Policy Server modifie la base de données d’autorisation principale chaque fois que des modifications sont apportées aux règles de sécurité. Lorsque Policy Server modifie la base de données d’autorisation principale, il peut envoyer une notification de ce changement à toutes les répliques de la base de données dans le domaine sécurisé qui prennent en charge les différents applicateurs de règles (par exemple, WebSEAL). Les applicateurs de règles doivent ensuite demander une mise à jour de la base de données réelle à partir de la base de données d’autorisation principale. En tant que gestionnaire de ressources et applicateur de règles, WebSEAL peut obtenir des informations sur les modifications apportées à la base de données d’autorisation à l’aide de trois options : v Ecoute des notifications de mise à jour à partir de Policy Server (configurable et activée par défaut) ; v Contrôle (interrogation) de la base de données d’autorisation principale à intervalles réguliers (configurable et activé par défaut) ; v Activation de l’écoute et de l’interrogation. La strophe [aznapi-configuration] du fichier de configuration webseald.conf contient des paramètres destinés à configurer les interrogations de base de données et l’écoute des notifications de mise à jour. Le paramètre db-file définit le chemin de la base de données des règles d’autorisation des répliques locales de WebSEAL : [aznapi-configuration] db-file = /var/pdweb/db/webseald.db
Configuration de l’écoute des notifications de mise à jour Le paramètre listen-flags active et désactive l’écoute des notifications de mise à jour pour WebSEAL. L’écoute est activée par défaut. Pour la désactiver, entrez “disable”. [aznapi-configuration] listen-flags = enable
Le paramètre tcp-port configure le port TCP pour le programme d’écoute : [aznapi-configuration] tcp-port = 12056
Le paramètre udp-port configure le port UDP pour le programme d’écoute : [aznapi-configuration] udp-port = 0
Chapitre 3. Configuration avancée du serveur
53
Configuration de l’interrogation de la base de données d’autorisation Vous pouvez configurer WebSEAL de façon à interroger la base de données d’autorisation principale à intervalles réguliers pour rechercher des informations de mise à jour. Le paramètre cache-refresh-interval peut avoir la valeur “default”, “disable” ou indiquer un intervalle de temps spécifique exprimé en secondes. La valeur “default” est égale à 600 secondes. L’interrogation est désactivée par défaut. [aznapi-configuration] cache-refresh-interval = disable
Gestion des affectations des unités d’exécution d’agents v «Configuration des unités d’exécution d’agents WebSEAL» à la page 54 v «Affectation des unités d’exécution d’agents pour les jonctions (limite maximale)» à la page 55
Configuration des unités d’exécution d’agents WebSEAL Le nombre d’unités d’exécution d’agents configurées spécifie le nombre de requêtes entrantes concurrentes pouvant être prises en charge par un serveur. Les autres connexions arrivant lorsque toutes les unités d’exécution d’agents sont occupées sont mises en mémoire tampon jusqu’à ce qu’une unité d’exécution soit disponible. Vous pouvez définir le nombre d’unités d’exécution disponibles pour la prise en charge des connexions entrantes dans WebSEAL. Etant donné les risques encourus au niveau des performances, la configuration du nombre d’unités d’exécution d’agents doit s’effectuer avec précaution. Ce paramètre de configuration n’impose pas de limite supérieure au nombre de connexions simultanées. Il simplifie simplement le nombre d’unités d’exécution mises à disposition pour la gestion d’une file d’attente de travaux illimitée. Le choix du nombre optimal d’unités d’exécution d’agents dépend de la façon dont vous appréhendez la quantité et le type de trafic sur votre réseau. En augmentant le nombre d’unités d’exécution, vous réduisez généralement le temps moyen de traitement des requêtes. Mais vous jouez également sur d’autres facteurs qui peuvent avoir un effet négatif sur les performances du serveur. WebSEAL gère une liste d’agents générique et unique, ainsi qu’un pool d’unités d’exécution pour le traitement des requêtes émanant de clients utilisant des tunnels TCP ou SSL. Ce mécanisme renforcé permet à WebSEAL d’économiser les ressources système tout en gérant une charge nettement plus importante. Vous pouvez configurer la taille du pool des unités d’exécution des agents en définissant le paramètre worker-threads de la strophe [server] du fichier de configuration webseald.conf . [server] worker-threads = 50
Remarque : Il est vivement recommandé de ne modifier ce paramètre qu’en cas de dépannage d’un incident lié aux performances.
54
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Affectation des unités d’exécution d’agents pour les jonctions (limite maximale) Vous pouvez configurer l’affectation des unités d’exécution d’agents WebSEAL utilisées afin de traiter les requêtes au niveau de plusieurs jonctions ou sur une base globale ou jonction par jonction. La méthode de configuration permet de garantir une répartition “équitable” des unités d’exécution d’agents parmi les jonctions et empêche la limitation du pool des unités d’exécution à l’une des jonctions.
Principes de base Pour traiter plusieurs requêtes, WebSEAL effectue des extractions dans le pool des unités d’exécution d’agents. Le nombre d’unités d’exécution d’agents disponible pour WebSEAL est spécifié par le paramètre worker-threads du fichier de configuration webseald.conf. Vous pouvez adapter la valeur affectée à worker-threads afin de tenir compte de votre installation WebSEAL spécifique. Lorsqu’aucune unité d’exécution d’agents n’est disponible pour la gestion des requêtes entrantes, les utilisateurs peuvent constater que le serveur WebSEAL ne répond pas. Les unités d’exécution d’agents sont utilisées pour la gestion des requêtes entrantes relatives aux applications qui résident sur plusieurs serveurs reliés par jonction. Toutefois, le pool des unités d’exécution d’agents peut être rapidement vidé si une application d’arrière-plan est particulièrement lente lors du traitement d’un volume élevé de requêtes. La limitation du pool des unités d’exécution d’agents à cette application a pour effet de rendre WebSEAL incapable de répondre aux demandes de services sur les autres serveurs d’applications reliés par jonction. Vous pouvez configurer des limites globales ou jonction par jonction au niveau du nombre d’unités d’exécution d’agents utilisées pour les applications résidant sur plusieurs jonctions. Ces limites permettent de garantir une “équité” pour toutes les jonctions et interdisent à une application de réclamer davantage que sa part d’unités d’exécution.
Affectation globale d’unités d’exécution d’agents à des jonctions Deux paramètres de la strophe [junction] du fichier de configuration webseald.conf de contrôler, pour un serveur WebSEAL spécifique, l’affectation globale des unités d’exécution d’agents entre les différentes jonctions. Les valeurs affectées à ces paramètres sont exprimées en pourcentages (de 0 à 100). La valeur par défaut est 100 (%) et indique qu’il n’existe pas de limite. v worker-thread-soft-limit Ce paramètre constitue un avertissement avant que la limite “matérielle” ne soit atteinte. Lorsque la valeur affectée à worker-thread-soft-limit est dépassée, des messages d’avertissement sont insérés (toutes les 30 secondes) dans le fichier journal des erreurs de WebSEAL. Par exemple, lorsque worker-threads=50, une valeur 60 (%) entraîne l’affichage de messages lorsque la jonction consomme plus de 30 unités d’exécution d’agents. Toutes les requêtes contenant au maximum 30 unités d’exécution d’agents sont traitées, jusqu’à ce que la limite “supérieure” soit atteinte. v worker-thread-hard-limit Ce paramètre est utilisé comme point de coupure pour les requêtes de service acheminées via une jonction. Lorsque la valeur affectée à worker-thread-hard-
Chapitre 3. Configuration avancée du serveur
55
limit est dépassée, des messages d’erreur sont envoyés toutes les 30 secondes au fichier journal d’erreurs de WebSEAL. En outre, l’utilisateur reçoit le message 503 (“Service non disponible”). Par exemple, lorsque worker-threads=50, la valeur 80 (%) entraîne l’affichage de messages d’erreur lorsque la jonction tente de consommer plus de 40 unités d’exécution d’agents. Toutes les requêtes qui représentent plus de 40 unités d’exécution d’agents sur la jonction sont renvoyées avec le message d’erreur 503 “Service non disponible”. Ces paramétrages globaux s’appliquent à toutes les jonctions configurées. Lorsque vous configurez ces deux paramètres, il est logique d’affecter à la limite “logicielle” une valeur inférieure à celle de la limite “matérielle”.
Affectation d’unités d’exécution d’agents jonction par jonction Vous pouvez également limiter la consommation des unités d’exécution d’agents jonction par jonction. Les options suivantes de la commande pdadmin server task create permettent de spécifier les limites matérielles et logicielles applicables aux unités d’exécution d’agents pour une jonction spécifique : v –l Cette option permet de définir, pour une jonction, une valeur (pourcentage) qui constitue la limite logicielle de consommation d’unités d’exécution d’agents. Comme pour le paramétrage de limite logicielle globale, cette option entraîne l’affichage de messages d’avertissement lorsque la jonction consomme plus d’unités d’exécution que le nombre stipulé. v –L Cette option permet de définir, pour une jonction, une valeur (pourcentage) qui constitue la limite matérielle de consommation d’unités d’exécution d’agents. Comme pour le paramétrage de limite matérielle globale, cette option entraîne l’affichage de messages d’avertissement lorsque la jonction consomme plus d’unités d’exécution que le nombre stipulé.En outre, l’utilisateur reçoit le message 503 (“Service non disponible”). Par exemple : pdadmin> server task webseald- create -t tcp -h \ -l 60 -L 80
Le paramétrage par jonction écrase toujours le paramétrage global dans le fichier webseald.conf. Des valeurs inappropriées affectées à une jonction spécifique risquent d’affecter les règles établies par le paramétrage global.
Notes de résolution des incidents v Vous pouvez utiliser la commande pdadmin server task show pour afficher le nombre d’unités d’exécution d’agents actives sur une jonction spécifique : pdadmin> server task webseald- show /
Ces informations peuvent s’avérer utiles si vous souhaitez déterminer l’emplacement d’une jonction qui consomme plus que sa part d’unités d’exécution d’agents (ressources). v Si vous spécifiez une limite logicielle supérieure à la valeur de limite matérielle pour une jonction spécifique, celle-ci ne peut pas être créée. v Vous devez spécifier les valeurs de limite logicielle et matérielle (options –l et –L) pour une jonction spécifique.
56
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Réplication de serveurs frontaux WebSEAL Remarque : Les informations suivantes remplacent l’ancienne commande pdadmin server modify baseurl utilisée dans les versions précédentes d’Access Manager. Dans un environnement à forte charge, il est préférable de répliquer des serveurs frontaux WebSEAL afin d’optimiser l’équilibrage de charge et la fonction de secours. Lorsque vous répliquez des serveurs frontaux WebSEAL, chaque serveur doit contenir une copie exacte de l’espace Web, de la base de données des jonctions et de la base de données dynurl. Cette version d’Access Manager prend en charge une procédure de configuration manuelle pour répliquer des serveurs frontaux WebSEAL. La commande pdadmin n’est plus utilisée pour cette tâche. Dans l’exemple suivant, “WS1” est le nom d’hôte du serveur WebSEAL principal. “WS2” est le nom d’hôte de la réplique du serveur WebSEAL. 1. Installez et configurez WebSEAL à la fois sur les serveurs WS1 et WS2. 2. Arrêtez WebSEAL sur WS2. 3. Sur WS2, remplacez la valeur “WS2” du paramètre server-name du fichier de configuration webseald.conf par “WS1” : [server] server-name = WS1
4. Redémarrez WebSEAL sur WS2. A présent, le serveur WS2 utilise l’objet /WebSEAL/WS1 comme base des évaluations d’autorisation. Le serveur WS2 peut également répondre aux commandes object list et object show pour les objets situés sous /WebSEAL/WS1. L’utilitaire pdadmin répertorie toujours l’objet /WebSEAL/WS2 comme faisant partie de l’espace objet. Cet objet est à présent inutile et peut être supprimé : pdadmin> object delete /WebSEAL/WS2
Conditions : v Gestion de l’espace objet global : Bien que l’administrateur puisse voir une seule hiérarchie d’objets, tous les serveurs WebSEAL répliqués sont affectés par les commandes d’administration appliquées à cette hiérarchie et peuvent y répondre. v Evaluation de l’autorisation globale : Si le serveur WS2 est configuré en tant que réplique du serveur WS1, il utilise /WebSEAL/WS1 comme base pour évaluer les autorisations. v Configuration globale : Pour que la réplication du serveur frontal WebSEAL fonctionne correctement, les configurations de l’espace Web, de la base de données des jonctions et de la base de données dynurl doivent être identiques sur chaque serveur.
Chapitre 3. Configuration avancée du serveur
57
Configuration de plusieurs instances de serveur WebSEAL Access Manager offre la possibilité de configurer plusieurs instances de serveur WebSEAL sur une même machine.
Généralités sur la configuration A des fins de configuration, une instance de serveur WebSEAL est définie par une combinaison unique interface réseau (adresse IP)/numéro de port. Plusieurs instances WebSEAL peuvent être configurées à l’aide de l’une des méthodes suivantes, afin de créer une combinaison unique interface réseau/numéro de port. v Utilisez une interface réseau simple (adresse IP) et affectez des instances WebSEAL à des ports d’écoute HTTP/HTTPS v Affectez des instances WebSEAL à des interfaces réseau uniques (cartes physiques d’interface réseau ou alias de réseau logique) et utilisez des ports HTTP/HTTPS courants. Remarque : Dans les deux cas, la valeur de port interserveurs spécifiée par l’option –m doit être unique pour toutes les instances WebSEAL. Chaque instance WebSEAL configurée possède un nom unique, un numéro de port interne unique (pour les communications entre serveurs Access Manager), un emplacement de répertoire unique et un fichier de configuration unique. Plusieurs fichiers de configuration sont rendus uniques par le nom d’instance de serveur, précédé de webseald-. Par exemple : /opt/pdweb/etc/webseald-.conf
Les outils de configuration requis pour la configuration de plusieurs instances de serveur WebSEAL incluent : v Systèmes UNIX : Utilitaire de ligne de commande PDWeb_config Utilitaire de ligne de commande PDWeb_unconfig Remarque : L’utilitaire pdconfig peut être utilisé pour la création de l’instance WebSEAL initiale. La commande PDWeb_config doit être utilisée pour la création de toutes les instances supplémentaires. Cela suppose que vous ayez configuré un serveur WebSEAL initial. v Systèmes WINDOWS : Utilitaire de ligne de commande ivweb_setup Utilitaire de ligne de commande ivweb_uninst
Configuration de plusieurs instances WebSEAL sous UNIX L’utilitaire PDWeb_config est situé dans le répertoire suivant : /opt/pdweb/sbin/
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Argument
Description
nom_instance
Nom unique de cette instance. Vous devez utiliser ce nom pour déconfigurer l’instance. La longueur de ce nom est limitée à 20 caractères.
port_interne
Numéro de port unique utilisé pour les communications entre serveurs Access Manager. La valeur affectée doit être supérieure à 1023. (Les valeurs inférieures à 1023 sont réservées.)
interface_réseau
Argument facultatif permettant de spécifier l’adresse IP d’une interface réseau.
Remarque : La valeur de port de serveurs spécifiée par l’option –m doit être unique pour toutes les instances WebSEAL. Configuration de plusieurs instances sur des ports HTTP/HTTPS uniques : 1. Hypothèse : une machine est configurée pour un serveur WebSEAL initial (pdconfig) et une adresse IP/carte réseau simple (par exemple : 1.2.3.4). 2. Modifiez l’emplacement du répertoire : # cd /opt/pdweb/sbin
3. Exécutez la commande PDWeb_config afin de créer et de configurer une instance WebSEAL supplémentaire. Dans ce scénario, plusieurs instances de serveurs sont rendues uniques grâce aux désignations uniques de ports de serveurs et de ports d’écoute HTTP/HTTPS sur l’interface réseau par défaut. Par conséquent, n’utilisez pas l’option –n pour spécifier une interface réseau. Par exemple : # ./PDWeb_config –i webseal2 –m 3232
4. L’écran de configuration apparaît : Please check Web Server configuration: 1. Enable TCP HTTP? Yes 2. HTTP Port 80 3. Enable HTTPS? Yes 4. HTTPS Port 443 5. Web document root directory /opt/pdweb/www-webseal2/docs a. Accept configuration and continue with installation x. Exit installation Select item to change:
5. Par défaut, le serveur WebSEAL initial écoute les requêtes sur *:80 et *:443. Sélectionnez les options de port HTTP et HTTPS et indiquez des valeurs uniques de port non utilisées par un autre serveur (81 et 444, par exemple). Remarque : Un message d’avertissement s’affiche si vous sélectionnez une valeur de port déjà utilisée. Vous avez alors la possibilité de sélectionner une autre valeur. 6. Exécutez la commande PDWeb_config pour créer et configurer des instances de serveur WebSEAL supplémentaires (dotées de ports interserveurs uniques). Par exemple : # ./PDWeb_config –i webseal3 –m 3233
7. Utilisez l’écran de configuration pour configurer des valeurs uniques de ports HTTP et HTTPS. Remarque : Le nombre maximal d’instances WebSEAL autorisé dépend des limitations du système en matière de configuration (mémoire RAM Chapitre 3. Configuration avancée du serveur
59
et espace disque disponible, par exemple). Si l’une des ressources système est dépassée, des messages d’échec de configuration et d’échec de démarrage apparaissent. Configuration de plusieurs instances sur des interfaces réseau logiques uniques : 1. Hypothèse : une machine est configurée avec un serveur WebSEAL initial (pdconfig) et une adresse IP/carte réseau simple. 2. Par défaut, le serveur WebSEAL initial écoute les requêtes sur *:80 et *:443. Vous devez affecter une adresse IP spécifique à cette interface réseau initiale pour pouvoir configurer et exécuter d’autres serveurs WebSEAL. Remarque : Aucun autre serveur WebSEAL ne peut démarrer si le serveur initial utilise pour son écoute *:80 et *:443. 3. Modifiez le fichier de configuration webseald.conf et spécifiez l’adresse IP appropriée au serveur WebSEAL initial en ajoutant le paramètre network-interface à la strophe [server]. Par exemple : [server] network-interface = 1.2.3.4
4. Redémarrez le serveur WebSEAL : # /opt/pdweb/bin/pdweb restart
5. Pour chaque instance de serveur supplémentaire, configurez une interface réseau logique supplémentaire (alias). Par exemple (sous Solaris version 2.8) : # ifconfig hme0 addif 1.2.3.5 netmask w.x.y.z up # ifconfig hme0 addif 1.2.3.6 netmask w.x.y.z up
Remarque : Vous pouvez également affecter une carte réseau physique préconfigurée unique à chaque instance WebSEAL. 6. Modifiez l’emplacement du répertoire : # cd /opt/pdweb/sbin
7. Exécutez la commande PDWeb_config afin de créer et de configurer une instance WebSEAL supplémentaire. Dans ce scénario, plusieurs instances de serveurs sont rendues uniques grâce à une interface réseau unique sur des ports interserveurs et des ports d’écoute HTTP/HTTPS. Par conséquent, vous devez utiliser l’option –n. Par exemple : # ./PDWeb_config –i webseal2 –m 3232 –n 1.2.3.5
HP-UX utilise le nom d’interface réseau au lieu de l’adresse IP. L’utilitaire PDWeb_config vérifie que l’interface possède une adresse IP valide. 8. L’écran de configuration apparaît : Please check Web Server configuration: 1. Enable TCP HTTP? Yes 2. HTTP Port 80 3. Enable HTTPS? Yes 4. HTTPS Port 443 5. Web document root directory /opt/pdweb/www-webseal2/docs a. Accept configuration and continue with installation x. Exit installation Select item to change:
60
IBM Tivoli Access Manager - Guide d’administration WebSEAL
9. Acceptez les valeurs standard de port HTTP et HTTPS telles qu’elles apparaissent dans la liste. 10. Exécutez la commande PDWeb_config pour créer et configurer des instances de serveur WebSEAL supplémentaires. Par exemple : # ./PDWeb_config –i webseal3 –m 3233 -n 1.2.3.6
11. Utilisez l’écran de configuration pour accepter les valeurs standard de ports HTTP et HTTPS figurant dans la liste. Remarque : Le nombre maximal d’instances WebSEAL autorisé dépend des limitations du système en matière de configuration (mémoire RAM et espace disque disponible, par exemple). Si l’une des ressources système est dépassée, des messages d’échec de configuration et d’échec de démarrage apparaissent.
Configuration de plusieurs instances WebSEAL sous Win NT/2000 Hypothèses : v Une instance de serveur WebSEAL a été configurée v Les procédures décrites sont adaptées aux plates-formes Windows NT/2000 Syntaxe ivweb_setup : MSDOS> ivweb_setup -m -i \ -M -u {yes|no} -r -U {yes|no} \ -R [-n ] Option et argument
Description
–m
Mot de passe d’administration.
–i
Nom unique de cette instance. Vous devez utiliser ce nom pour déconfigurer l’instance. La longueur de ce nom est limitée à 20 caractères.
–M
Numéro de port unique utilisé pour les communications entre serveurs Access Manager. La valeur affectée doit être supérieure à 1023. (Les valeurs inférieures à 1023 sont réservées.)
–u {yes|no}
Active/désactive l’accès HTTP.
–r
Numéro de port à utiliser pour l’accès HTTP.
–U {yes|no}
Active/désactive l’accès HTTPS.
–R
Numéro de port à utiliser pour l’accès HTTPS.
–n
Argument facultatif permettant de spécifier l’adresse IP d’une interface réseau.
Remarque : La valeur de port interserveurs spécifiée par l’option –M doit être unique pour toutes les instances WebSEAL.
Chapitre 3. Configuration avancée du serveur
61
Configuration de plusieurs instances sur des ports HTTP/HTTPS uniques : 1. Hypothèse : Windows est configuré pour un serveur WebSEAL initial (pdconfig) et une adresse IP/carte réseau physique (pour cet exemple : 1.2.3.4). 2. Modifiez l’emplacement du répertoire : MSDOS> cd C:\Program Files\Tivoli\Policy Director\PDWeb\bin
3. Exécutez la commande ivweb_setup afin de créer et de configurer une instance WebSEAL supplémentaire. Dans ce scénario, plusieurs instances de serveurs sont rendues uniques grâce aux désignations uniques de ports de serveurs et de ports d’écoute HTTP/HTTPS sur une interface réseau. Par conséquent, n’utilisez pas l’option –n pour spécifier une interface réseau. Par exemple : MSDOS> ivweb_setup -m xxxxx –i webseal2 –M 3232 -u yes -r 81 -U yes -R 444
Remarque : Un message d’avertissement s’affiche si vous sélectionnez une valeur de port déjà utilisée. Vous avez alors la possibilité de sélectionner une autre valeur. 4. Exécutez la commande ivweb_setup pour créer et configurer des instances de serveur WebSEAL supplémentaires. Par exemple : MSDOS> ivweb_setup -m xxxxx –i webseal3 –M 3233 -u yes -r 82 -U yes -R 445
Configuration de plusieurs instances sur des interfaces réseau logiques uniques : 1. Hypothèse : Windows est configuré pour un serveur WebSEAL initial et une adresse IP/carte réseau simple. 2. Par défaut, le serveur WebSEAL initial écoute les requêtes sur *:80 et *:443. Vous devez affecter une adresse IP spécifique à cette interface réseau initiale pour pouvoir configurer et exécuter d’autres serveurs WebSEAL. Remarque : Aucun autre serveur WebSEAL ne peut démarrer si le serveur initial utilise pour son écoute *:80 et *:443. 3. Modifiez le fichier de configuration webseald.conf et spécifiez l’adresse IP appropriée au serveur WebSEAL initial en ajoutant le paramètre network-interface à la strophe [server]. Par exemple : [server] network-interface = 1.2.3.4
4. Redémarrez le serveur WebSEAL à partir du panneau de configuration des services : 5. Pour chaque instance de serveur WebSEAL supplémentaire, configurez une interface réseau logique supplémentaire (alias) à l’aide du panneau de configuration (Connexions réseau). Par exemple (sous Windows 2000) : a. Panneau de configuration > Connexions réseau b. Cliquez avec le bouton droit de la souris sur Connexions locales et sélectionnez Propriétés. c. Sélectionnez Internet Protocol (TCP/IP) d. e. f. g. h.
62
Cliquez sur Propriétés et sélectionnez Avancées Dans l’onglet Paramètres IP, cliquez sur Ajouter Entrez une adresse IP à associer à la nouvelle interface réseau Entrez un masque de sous-réseau Cliquez sur Ajouter
IBM Tivoli Access Manager - Guide d’administration WebSEAL
i. Ouvrez une fenêtre d’invite de commande et entrez les éléments suivants : MSDOS> ipconfig -all
Toutes les interfaces réseau doivent figurer comme étant en mode écoute. j. Répétez cette procédure pour les autres interfaces réseau 6. Modifiez l’emplacement du répertoire : MSDOS> cd C:\Program Files\Tivoli\PDWeb\bin
7. Exécutez la commande ivweb_setup afin de créer et de configurer une instance WebSEAL supplémentaire. Dans ce scénario, plusieurs instances de serveurs sont rendues uniques grâce à une interface réseau unique sur des ports interserveurs et des ports d’écoute HTTP/HTTPS. Par conséquent, vous devez utiliser l’option –n. Par exemple : MSDOS> ivweb_setup -m xxxxx –i webseal2 –M 3232 -u yes -r 80 -U yes \ -R 443 -n 1.2.3.5
8. Exécutez la commande ivweb_setup pour créer et configurer des instances de serveur WebSEAL supplémentaires. Par exemple : MSDOS> ivweb_setup -m xxxxx –i webseal3 –M 3233 -u yes -r 80 -U yes \ -R 443 -n 1.2.3.6
Déconfiguration de plusieurs instances WebSEAL Vous ne pouvez pas déconfigurer le serveur WebSEAL initial si toutes les instances de serveur n’ont pas été au préalable déconfigurées. UNIX : PDWeb_unconfig -i
1. Modifiez l’emplacement du répertoire : # cd /opt/pdweb/sbin
2. Exécutez la commande PDWeb_unconfig pour chaque instance. Par exemple : # ./PDWeb_unconfig -i webseal2 # ./PDWeb_unconfig -i webseal3
Windows : ivweb_uninst -deconfig -m -i
1. Modifiez l’emplacement du répertoire : MSDOS> cd C:\Program Files\Tivoli\PDWeb\bin
2. Exécutez la commande ivweb_uninst pour chaque instance. Par exemple : MSDOS> ivweb_uninst -deconfig -m xxxxxx -i webseal2 MSDOS> ivweb_uninst -deconfig -m xxxxxx -i webseal3
Commandes de serveur start, stop, restart et status UNIX : L’utilitaire pdweb contient des fonctions de démarrage, d’arrêt, de redémarrage et d’état pour le serveur initial WebSEAL et pour les instances de serveur multiples. Vous pouvez également appliquer une commande à une instance de serveur spécifique. pdweb {start|stop|restart|status} []
Chapitre 3. Configuration avancée du serveur
63
Exemples : Démarrage du serveur WebSEAL initial et de toutes les instances de serveur configurées : # /usr/bin/pdweb start
Démarrage d’une instance de serveur spécifique uniquement : # /usr/bin/pdweb start webseal3
Redémarrage du serveur WebSEAL initial et de toutes les instances de serveur configurées : # /usr/bin/pdweb restart
Arrêt du serveur WebSEAL initial et de toutes les instances de serveur configurées : # /usr/bin/pdweb stop
Arrêt d’une instance de serveur spécifique uniquement : # /usr/bin/pdweb stop webseal3
Affichage de l’état de tous les serveurs configurés : # /opt/PolicyDirector/bin/pd_start status Serveurs Access Manager Serveur Activé En fonctionnement -----------------------------------------pdmgrd oui oui pdacld oui oui webseald oui oui webseald-webseal2 oui oui webseald-webseal3 oui oui
Windows : Le panneau de configuration Windows (Services) contient des informations relatives au démarrage, à l’arrêt et à l’état du serveur. La commande net contient également des fonctions de démarrage et d’arrêt pour le serveur initial WebSEAL et pour les instances de serveur multiples. net {start|stop}
Exemples : Démarrage du serveur WebSEAL initial et de toutes les instances de serveur configurées (vous devez exécuter la commande pour chaque instance) : MSDOS> net start webseald MSDOS> net start webseal2 MSDOS> net start webseal3
Arrêt du serveur WebSEAL initial et de toutes les instances de serveur configurées (vous devez exécuter la commande pour chaque instance) : MSDOS> net stop webseald MSDOS> net stop webseal2 MSDOS> net stop webseal3
Affichage de l’état de tous les serveurs configurés : Démarrer > Paramètres > Panneau de configuration > Services
64
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Configuration du changement d’utilisateur pour les administrateurs La fonctionnalité WebSEAL de changement d’utilisateur permet à certains administrateurs de déterminer l’identité d’un utilisateur membre du domaine sécurisé d’Access Manager. La mise en oeuvre de cette fonctionnalité est identique à l’exécution de la commande su en environnement UNIX. En environnement WebSEAL, l’administrateur obtient les données d’autorisation de l’utilisateur et assure l’interaction avec les ressources et les applications d’arrière-plan dotées des mêmes capacités que l’utilisateur réel. Le changement d’utilisateur peut être utilisé en environnement Help Desk à des fins de résolution d’incidents et de diagnostic. Il peut également servir à tester l’accès d’un utilisateur aux ressources et l’intégration d’applications. Les principales caractéristiques du changement d’utilisateur figurent ci-après : v Le changement d’utilisateur ne nécessite pas de mot de passe utilisateur. v L’administrateur utilise des données d’autorisation qui représentent l’utilisateur réel. v Le changement d’utilisateur est limité aux membres d’un groupe d’administrateurs spécifique. Un administrateur ne peut pas changer d’utilisateur au profit d’un autre membre de ce groupe. v Les processus Access Manager, sec_master ainsi que d’autres utilisateurs sélectionnés peuvent être exclus de la fonctionnalité de changement d’utilisateur s’ils appartiennent à un groupe d’exclusion v Un formulaire HTML spécifique est utilisé pour transmettre les informations relatives au changement d’utilisateur et pour activer une méthode d’authentification spécifique qui renvoie les données d’autorisation de l’utilisateur spécifié sans qu’il soit nécessaire de saisir un mot de passe. v L’administrateur se sert de l’utilitaire pkmslogout pour mettre fin à une session de changement d’utilisateur.
Explication du processus de changement d’utilisateur La séquence ci-après décrit le flux du processus de changement d’utilisateur : 1. Hypothèses : L’administrateur (membre du groupe su-admins) s’est authentifié à WebSEAL, une session a été établie et une entrée a été créée pour l’administrateur dans la mémoire cache des sessions/données d’autorisation WebSEAL. 2. L’administrateur se connecte à un formulaire HTML préconfiguré de changement d’utilisateur. Ce formulaire est accessible uniquement aux membres du groupe su-admins. 3. Le formulaire de changement d’utilisateur est rempli et renvoyé avec les informations suivantes : nom d’utilisateur (l’administrateur est “attribué à” cet utilisateur), une adresse URL de destination, une méthode d’authentification. Cette action aboutit à l’envoi d’une requête POST à /pkmssu.form. 4. Une authentification spécifique pour changement d’utilisateur est effectuée par la bibliothèque partagée de changement d’utilisateur ou par une bibliothèque CDAS de changement d’utilisateur personnalisée. La bibliothèque de changement d’utilisateur (personnalisée ou intégrée) renvoie des données d’autorisation valides sur l’utilisateur sans qu’il soit nécessaire de saisir un mot de passe.
Chapitre 3. Configuration avancée du serveur
65
5. Pendant l’authentification pour changement d’utilisateur, WebSEAL vérifie les éléments suivants : Les groupes Access Manager su-admins, securitygroup et su-excluded, afin de vérifier que le nom d’utilisateur fourni dans le formulaire de changement d’utilisateur ne correspond pas à un membre de l’un de ces groupes. 6. Lors de l’authentification de l’utilisateur spécifié, une nouvelle structure de données de mémoire cache est créée et contient les données d’autorisation de l’utilisateur. 7. Les données de mémoire cache de l’administrateur sont supprimées de l’entrée de cache de session WebSEAL pour cet administrateur et enregistrées à un autre emplacement. Les données de cache de l’utilisateur prennent alors cette place. Désormais, l’entrée de cache contient l’ID de session d’origine de l’administrateur et les données de cache de l’utilisateur (avec les données d’autorisation). Les données d’autorisation contiennent également un nouvel ID de session utilisateur qui peut être utilisé pour toutes les situations de gestion des sessions utilisateur. L’entrée de cache de sessions est indexée à l’aide du même ID de session que celui utilisé par l’administrateur avant l’opération de changement d’utilisateur.
Figure 15. Permutation des données de cache administrateur et utilisateur pendant un changement d’utilisateur
8. WebSEAL envoie un réacheminement au navigateur pour l’adresse URL de destination fournie dans le formulaire de changement d’utilisateur. 9. La requête est traitée normalement à l’aide des données d’autorisation de l’utilisateur et l’adresse URL est utilisée. L’administrateur peut effectuer d’autres requêtes. Toutes les décisions d’autorisation relatives à ces requêtes sont prises sur la base des données d’autorisation de l’utilisateur. 10. L’administrateur met fin à la session de changement d’utilisateur à l’aide de l’utilitaire Access Manager standard /pkmslogout. 11. Une fois la déconnexion effectuée, les données du cache de l’utilisateur sont supprimées et les données de cache d’origine de l’administrateur (ainsi que ses données d’autorisation) sont restaurées. L’administrateur revient à la page d’origine dans laquelle le formulaire de changement d’utilisateur a été demandé. Le service d’autorisation utilise les données d’autorisation d’origine de l’administrateur pour toutes les requêtes ultérieures.
66
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Activation du changement d’utilisateur : récapitulatif Pour activer le changement d’utilisateur : 1. Supprimez les méthodes d’authentification appropriées du fichier webseald.conf et ajoutez le chemin d’accès à la bibliothèque partagée qui gère l’opération de changement d’utilisateur. 2. Servez-vous de l’utilitaire pdadmin pour ajouter des administrateurs au compte du groupe su-admins. 3. Servez-vous de l’utilitaire pdadmin pour ajouter des utilisateurs au compte du groupe su-excluded. 4. Vous pouvez également modifier le formulaire switchuser.html pour spécifier des données préconfigurées (telles que la méthode d’authentification et l’URL de destination). 5. Vous avez également la possibilité de créer d’autres formulaires afin de valider ou de traiter des données à soumettre à /pkmssu.form.
Configuration du formulaire HTML de changement d’utilisateur Le formulaire de changement d’utilisateur est défini dans la strophe [acnt-mgt] du fichier de configuration webseald.conf . v Le paramètre switch-user spécifie le nom du fichier. Par défaut, le nom du fichier est switchuser.html : [acnt-mgt] switch-user = switchuser.html
v Le paramètre mgt-pages-root spécifie le sous-répertoire du répertoire qui contient le fichier suivant : [acnt-mgt} mgt-pages-root = lib/html/
Sur les systèmes utilisant l’anglais US, le répertoire LANG est appelé “C”. v Le segment de chemin lib/html est relatif au paramètre server-root valeur : UNIX : [server] server-root = /opt/pdweb/www
Windows : [server] server-root = C:/Program Files/Tivoli/PDWeb/www
Le formulaire de changement d’utilisateur peut être modifié afin de répondre à vos besoins en matière de présentation et de fonctionnalités. Il contient des requêtes relatives aux éléments suivants : v Nom d’utilisateur (l’administrateur “effectue le changement” en faveur de cet utilisateur) Cet utilisateur ne peut pas être un membre des groupes su-excluded, su-admins ou securitygroup. v Adresse URL de destination Cette page apparaît après une opération réussie de changement d’utilisateur. Vous pouvez effectuer cette configuration sous forme d’entrée masquée contenant une page d’accueil appropriée ou une page de confirmation de changement d’utilisateur.
Chapitre 3. Configuration avancée du serveur
67
v Méthode d’authentification La méthode d’authentification détermine le type d’informations utilisé pour créer les données d’autorisation de l’utilisateur. Vous pouvez configurer cette zone en zone de saisie masquée. Pour obtenir la liste des paramètres de méthodes d’authentification valides, reportez-vous aux notes ci-dessous. Le formulaire de changement d’utilisateur se présente comme suit :
Figure 16. Formulaire de changement d’utilisateur
Notes relatives au formulaire de changement d’utilisateur : v Ce formulaire est accessible uniquement aux membres du groupe su-admins.Aucune LCA n’est requise pour ce fichier. WebSEAL effectue un contrôle codé en interne d’appartenance à un groupe. WebSEAL renvoie le message d’erreur 404 (“Introuvable”) en cas d’échec du contrôle d’appartenance à un groupe. v Le nom d’utilisateur, l’URL de destination et la méthode d’authentification sont des données obligatoires. v Les données obligatoires peuvent être générées dans le formulaire en tant que zones masquées. v WebSEAL vérifie que toutes les données obligatoires sont présentes dans le formulaire soumis. Si certaines données sont manquantes, le formulaire (accompagné d’un message descriptif) est renvoyé à l’administrateur. v Les valeurs valides de méthodes d’authentification sont les suivantes : su-ba su-forms su-certificate su-token-card su-http-request su-cdsso
Ces paramètres de méthodes d’authentification spécifient la méthode d’authentification WebSEAL à utiliser. v Les méthodes su-ba et su-forms sont mises en correspondance avec la méthode d’authentification su-password spécifiée dans le fichier de configuration webseald.conf. v Les données du formulaire de changement d’utilisateur sont soumises à l’URL d’action /pkmssu.form.
68
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Activation et exclusion d’utilisateurs pour le changement d’utilisateur Seuls les administrateurs membres du groupe su-admins peuvent utiliser la fonction de changement d’utilisateur et recevoir le formulaire HTML correspondant. La fonction de changement d’utilisateur est activée pour tout utilisateur membre du groupe su-admins. Les administrateurs peuvent changer d’utilisateur pour tout compte Access Manager, à l’exception des comptes qui appartiennent à certains groupes. Vous pouvez exlcure d’autres utilisateurs Access Manager du changement d’utilisateur via leur leur appartenance au groupe su-excluded. Par ailleurs, les membres du groupe Access Manager securitygroup sont exclus de la fonctionnalité de changement d’utilisateur. En règle générale, sec_master et les processus Access Manager sont membres de securitygroup. Pendant le changement d’utilisateur, WebSEAL effectue des contrôles sur les trois groupes. Vous ne pouvez pas “changer pour” une personne membre des groupes su-admins, su-excluded ou securitygroup.
Configuration de la méthode d’authentification par changement d’utilisateur Le principal objectif de l’authentification par changement d’utilisateur (bibliothèque partagée intégrée) est de créer des données d’autorisation représentant le “nouvel” utilisateur, sur la base du nom d’utilisateur et de la méthode d’authentification spécifiés, sans qu’il soit nécessaire de saisir un mot de passe. La méthode d’authentification CDAS personnalisée doit remplir la même condition. Les méthodes d’authentification par changement d’utilisateur doivent être spécifiées dans la strophe [authentication-mechanisms] stanza du fichier de configuration webseald.conf. Les méthodes d’authentification suivantes sont prises en charge : [authentication-mechanisms] #su-password = #su-token-card = #su-certificate = #su-http-request = #su-cdsso =
Access Manager contient une bibliothèque unique de changement d’utilisateur qui peut être utilisée pour activer l’une des méthodes d’authentification au sein d’un environnement par défaut non personnalisé. La bibliothèque de changement d’utilisateur diffère des bibliothèques d’authentification standard. La bibliothèque spécifie une méthode d’authentification qui extrait du formulaire de changement d’utilisateur l’identité de l’utilisateur et renvoie des données d’autorisation valides pour cet utilisateur sans qu’il soit nécessaire de saisir un mot de passe. La bibliothèque partagée de changement d’utilisateur fournie avec Access Manager s’appelle : Solaris
libsuauthn.so
AIX
libsuauthn.a
HP-UX
libsuauthn.sl
Windows
suauthn.dll Chapitre 3. Configuration avancée du serveur
69
La fonction de changement d’utilisateur prend également en charge les méthodes d’authentification CDAS personnalisées. Cette prise en charge est importante car un CDAS personnalisé offre souvent des informations complémentaires aux données d’autorisation de l’utilisateur. Il vous incombe d’écrire un CDAS de changement d’utilisateur personnalisé qui assure l’émulation du comportement de votre CDAS existant tout en prenant en charge l’obligation de renvoyer des données d’autorisation sans saisie de mot de passe. Reportez-vous au document IBM Tivoli Access Manager WebSEAL Developer’s Reference. Chaque bibliothèque d’authentification par changement d’utilisateur doit porter un nom unique, même lorsque la bibliothèque par défaut (libsuauthn) est utilisée pour plusieurs méthodes d’authentification.
Exemple Dans l’exemple suivant (pour plate-forme Solaris), un environnement existant possède trois méthodes d’authentification activées : 1. L’authentification par formulaire, qui utilise la bibliothèque intégrée libldapauthn 2. L’authentification par certificat, qui utilise la bibliothèque intégrée libsslauthn 3. L’authentification par jeton, qui utilise une méthode CDAS personnalisée L’environnement peut désormais prendre en charge la fonctionnalité de changement d’utilisateur pour ces trois méthodes d’authentification. Trois paramètres d’authentification supplémentaires doivent être activés dans le fichier de configuration webseald.conf pour le changement d’utilisateur. En outre, une nouvelle bibliothèque CDAS personnalisée doit être créée afin d’émuler le CDAS actuel à jeton et de prendre en charge les besoins de l’authentification par changement d’utilisateur : [authentication-mechanisms] passwd-ldap = /opt/PolicyDirector/lib/libldapauthn.so cert-ssl = /opt/PolicyDirector/lib/libsslauthn.so token-cdas = /opt/PolicyDirector/lib/libcustom.so su-password = /opt/PolicyDirector/lib/libsuformauthn.so su-certificate = /opt/PolicyDirector/lib/libsucert.so su-token-card = /opt/PolicyDirector/lib/libsucustom.so
Souvenez-vous que la méhode d’authentification su-forms figurant dans le formulaire de changement d’utilisateur est mappée au paramètre de méthode d’authentification su-password du fichier de configuration webseald.conf . De plus, la bibliothèque libsuauthn a été renommée pour les méthodes d’authentification par formulaire et par certificat.
Configuration d’une méthode de changement d’utilisateur CDAS Une méthode d’authentification existante renvoie souvent des informations complémentaires sur l’utilisateur incorporé aux données d’autorisation de l’utilisateur. Si vous utilisez la fonctionnalité de changement d’utilisateur dans un environnement identique, il vous incombe d’écrire un CDAS de changement d’utilisateur personnalisé qui assure l’émulation du comportement de votre CDAS existant tout en prenant en charge l’obligation de renvoyer des données d’autorisation sans saisie de mot de passe.
70
IBM Tivoli Access Manager - Guide d’administration WebSEAL
L’API CDAS d’Access Manager fournit un ensemble de composants d’identité qui peuvent être utilisés pour la transmission des informations sur l’authentification des clients à la bibliothèque partagée CDAS de changement d’utilisateur. Ces informations sont transmises au format nom/liste de valeurs (le nom correspond à un identificateur qui spécifie le type de valeur). Les informations sont stockées dans le type xnlist_t data. Les valeurs sont accessibles via l’utilisation de la fonction xnvlist_get(). Les composants d’identité appropriés aux CDAS de changement d’utilisateur incluent notamment : xauthn_su_method xauthn_admin_name xauthn_admin_cred xauthn_existing_cred xauthn_username xauthn_qop xauthn_ipaddr xauthn_browser_info
Les composants d’identité xauthn_browser_info, xauthn_qop et xauthn_ipaddr représentent ceux de l’administrateur, et non ceux de l’utilisateur. Ces données sont fournies pour tout CDAS devant effectuer des validations supplémentaires du compte de l’administrateur. Pour plus d’informations sur la génération d’un module CDAS personnalisé, reportez-vous au document IBM Tivoli Access Manager WebSEAL Developer’s Reference.
Impact sur les autres fonctionnalités WebSEAL Impact sur la configuration du délai d’expiration du cache de session La fonctionnalité de délai d’expiration du cache de session WebSEAL configuré n’est pas affectée par l’opération de changement d’utilisateur. Les délais d’inactivité et de durée de vie sont associés à l’entrée du cache de session de l’administrateur et non aux données de mémoire cache qui sont modifiées au cours de toute opération de changement d’utilisateur. Le délai d’inactivité est encore réinitialisé pendant que l’administrateur effectue des requêtes pour le “changement” d’utilisateur. Lorsque ce dernier termine la session de changement d’utilisateur, l’inactivité est encore valide pour la session administrateur qui est de nouveau établie. La valeur de durée de vie n’est pas étendue par les opérations de changement d’utilisateur. Il est possible qu’un délai d’expiration d’entrée de cache de session expire pendant une opération de changement d’utilisateur. Dans ce cas, le cache de session est supprimé et l’administrateur est déconnecté. L’administrateur doit alors s’authentifier de nouveau et recommencer l’opération de changement d’utilisateur.
Insertion de niveaux d’authentification avancée La spécification de bibliothèque partagée peut accepter des arguments supplémentaires sous la forme suivante : & ....
Chapitre 3. Configuration avancée du serveur
71
Vous pouvez spécifier des niveaux d’authentification avancée à l’aide de l’option –l suivie du numéro de niveau. Par exemple : su-password = /opt/PolicyDirector/lib/libsuformauthn.so& -l 1 su-certificate = /opt/PolicyDirector/lib/libsucert.so& -l 0 su-token-card = /opt/PolicyDirector/lib/libsucustom.so& -l 2
Remarque : Pour cette version d’Access Manager, l’administrateur doit connaître le mot de passe de l’utilisateur pour que l’authentification avancée puisse aboutir.
Support de nouvelle authentification La fonctionnalité WebSEAL de nouvelle authentification est reconnue par l’opération de changement d’utilisateur. Si une nouvelle authentification est requise pendant une opération de changement d’utilisateur, l’administrateur doit s’authentifier en tant que “nouvel” utilisateur. Remarque : Pour cette version d’Access Manager, l’administrateur doit connaître le mot de passe du “nouvel” utilisateur afin de s’authentifier de nouveau avec succès.
Support pour la gestion des sessions utilisateurs L’opération de changement d’utilisateur prend en charge la gestion des sessions utilisateurs. L’administrateur possède un ID unique de session utilisateur. En outre, pendant une session de changement d’utilisateur, un ID unique de session utilisateur existe pour le “nouvel” utilisateur. Les tâches de fin de session utilisateur et de fin de toutes les sessions utilisateurs s’effectuent comme prévu.
Support de tag-value L’option tag-value, souvent utilisée par un module CDAS, est reconnue et prise en charge par la fonctionnalité de changement d’utilisateur.
Audit de l’administrateur pendant le changement d’utilisateur Il est possible d’effectuer un audit relatif à l’administrateur pendant une opération de changement d’utilisateur. La fonctionnalité de changement d’utilisateur permet d’ajouter un attribut étendu aux données d’autorisation du “nouvel” utilisateur, qui identifie l’administrateur. L’attribut étendu s’appelle su-admin : su-admin =
Cet attribut étendu peut être utilisé pour toutes les méthodes d’audit.
Configuration de la mise en mémoire cache des requêtes WebSEAL côté serveur Principes de base Dans les versions antérieures de WebSEAL qui utilisaient l’authentification par formulaires, WebSEAL créait une entrée de cache pour l’adresse URL associée à une requête utilisateur chaque fois qu’une authentification était requise. Une fois l’authentification effectuée avec succès, WebSEAL envoyait un réacheminement HTTP au navigateur qui contenait cette adresse URL. Le navigateur faisait alors suivre ce réacheminement vers l’emplacement d’origine de la ressource. La limitation de cette mise en oeuvre est apparue lorsque, par exemple, une requête POST était interrompue par le délai d’expiration d’une session, ce qui exigeait une nouvelle authentification. Etant donné que WebSEAL ne mettait en mémoire cache que l’adresse URL de la requête d’origine, les données POST
72
IBM Tivoli Access Manager - Guide d’administration WebSEAL
(incluant la METHODE et le corps du message) étaient perdues au cours du réacheminement HTTP. L’utilisateur devait alors générer de nouveau la requête POST. Désormais, WebSEAL met en mémoire cache un ensemble plus complet de données de requêtes et utilise ces données pour générer de nouveau la requête au cours du réacheminement HTTP si la nécessité d’une nouvelle authentification interrompt le traitement de la requête. Cette solution est particulièrement avantageuse pour les requêtes POST et PUT, car ces types de requêtes peuvent inclure un grand nombre de zones d’information.
Flux du processus de mise en mémoire cache côté serveur Lorsque la nécessité d’effectuer une authentification interrompt une requête, WebSEAL met en mémoire cache toutes les informations nécessaires pour générer de nouveau la requête au cours du réacheminement HTTP effectué à la suite d’un processus de nouvelle authentification. Les données de requêtes mises en mémoire cache incluent l’adresse URL, la METHODE, le corps du message, les chaînes d’interrogation, ainsi que tous les en-têtes HTTP (y compris les cookies). Ces données sont stockées temporairement dans la mémoire cache WebSEAL de sessions/données d’autorisation. Une fois l’authentification (ou la nouvelle authentification) effectuée avec succès, WebSEAL envoie un réacheminement HTTP au navigateur. Le navigateur transmet ce réacheminement vers l’adresse URL d’origine contenue dans ce dernier. WebSEAL intercepte le réacheminement et reconstitue la requête à l’aide des données de la mémoire cache. La requête reconstituée est transmise à l’adresse URL de destination. Le schéma suivant illustre un flux de processus de mise en mémoire cache de requête côté serveur : 1. L’utilisateur se connecte avec succès (authentification par formulaires) et soumet une requête HTTP relative à une ressource impliquant l’utilisation d’un formulaire généré par CGI. WebSEAL crée et met en mémoire cache un ID de session pour cet utilisateur. 2. Le serveur d’applications d’arrière-plan renvoie le formulaire à l’utilisateur. 3. Pendant que l’utilisateur remplit le formulaire, le délai d’expiration de session configuré est atteint. WebSEAL supprime alors l’entrée de mémoire cache et l’ID de session des données d’autorisation de l’utilisateur. 4. L’utilisateur soumet, s’il le souhaite, le formulaire rempli (POST). WebSEAL ne trouve aucune entrée de mémoire cache pour l’utilisateur, crée une nouvelle mémoire cache et place temporairement dans cette mémoire les informations complètes contenues dans la requête POST. 5. Etant donné que WebSEAL ne trouve aucune donnée d’autorisation pour cet utilisateur, celui-ci est obligé de s’authentifier. WebSEAL envoie un formulaire de connexion à l’utilisateur. 6. L’utilisateur renvoie le formulaire de connexion rempli à WebSEAL (POST). L’authentification s’effectue avec succès. La mémoire cache contient désormais les données d’autorisation de l’utilisateur, ainsi que la requête mise en mémoire cache. 7. WebSEAL renvoie un réacheminement HTTP au navigateur qui contient l’adresse URL de la ressource objet de la requête d’origine.
Chapitre 3. Configuration avancée du serveur
73
8. Le navigateur suit le réacheminement (GET). WebSEAL intercepte le réacheminement et reconstitue la requête d’origine (formulaire) à l’aide des données POST placées en mémoire cache. La requête restaurée (formulaire) est transmise à l’URL.
Figure 17. Exemple de flux de processus de mise en mémoire cache côté serveur
Configuration des paramètres de mise en mémoire cache côté serveur Bien que la mise en mémoire cache des requêtes ait lieu automatiquement pour l’authentification WebSEAL par formulaires, vous pouvez spécifier des limites de taille pour les requêtes que WebSEAL place en mémoire cache. Les paramètres request-max-cache et request-body-max-read se trouvent dans la strophe [server] du fichier de configuration webseald.conf . request-max-cache Le paramètre request-max-cache spécifie la quantité maximale de données (exprimée en octets) que WebSEAL place en mémoire cache pour chaque requête. Par exemple : [server] request-max-cache = 8192
Comme décrit ci-avant, vous devez tenir compte de la valeur affectée au paramètre request-body-max-read lorsque vous spécifiez la valeur du paramètre request-max-cache.
74
IBM Tivoli Access Manager - Guide d’administration WebSEAL
request-body-max-read Le paramètre request-body-max-read spécifie la taille maximale du corps du message (exprimée en octets) que WebSEAL place en mémoire cache pour chaque requête. Ce paramètre a un impact sur les types de requêtes qui contiennent des données de corps de message (comme par exemple les requêtes POST et PUT). Par exemple : [server] request-body-max-read = 4096
Ce paramètre ne limite pas la taille maximale de requête POST (qui est illimitée) pour les requêtes qui ne nécessitent pas d’authentification. Il est à noter que la valeur affectée au paramètre request-max-cache doit contenir une valeur correcte pour le paramètre request-body-max-read et pour la taille de tous les autres composants de la requête. Par exemple, si vous spécifiez 2048 octets comme limite de mémoire cache pour les corps de messages de requêtes et que vous spécifiez une taille maximale égale à 4096 octets pour tous les autres composants de requête (tels que les en-têtes et les cookies), définissez les éléments suivants : 1. Définissez request-body-max-read = 2048 2. Définissez request-max-cache = 2048 + 4096 = 6144 Si la valeur de request-body-max-read ou de request-max-cache est dépassée pendant une requête, WebSEAL abandonne le processus de mise en mémoire cache de la requête, puis renvoie un message d’erreur au navigateur (La mise en antémémoire de la requête a échoué) et consigne ce message d’erreur dans le fichier journal. Vous pouvez personnaliser ce message d’erreur. Voir la section «Gestion des pages personnalisées de messages d’erreur HTTP» à la page 34.
Notes et limites v La valeur affectée à request-body-max-read a également un impact sur les requêtes d’adresses URL dynamiques car la part d’interrogation de la requête POST est contenue dans le corps du message de requête. v La valeur de request-body-max-read affecte également l’authentification par formulaires grâce à la limite fixée pour la taille des données POST traitées au cours de l’authentification. v Les paramètres request-body-max-read et request-max-cache protègent WebSEAL des types d’attaque de refus d’accès aux services qui obligent WebSEAL à placer davantage de données en mémoire cache qu’il ne peut en gérer. v La mise en mémoire cache de requêtes côté serveur ne fonctionne correctement que si la valeur du délai d’expiration de la session utilisateur est atteinte pendant le processus de connexion. Dans ce cas, l’entrée de cache est perdue. v La mise en mémoire cache des requêtes côté serveur peut entraîner une limitation des capacités du navigateur à manipuler la ressource. Le navigateur n’a pas d’informations sur la reconstitution du réacheminement HTTP par WebSEAL. Par conséquent, la fonction de rechargement/réactualisation du navigateur et sa capacité de mise en mémoire cache peuvent s’en trouver affectées.
Chapitre 3. Configuration avancée du serveur
75
Gestion des caractères codés UTF-8 Conformément aux spécifications HTTP, les navigateurs sont limités au jeu de caractères qui peut être utilisé au sein d’une adresse URL. Cette plage comprend les caractères imprimables du jeu de caractères ASCII (entre le code hexadécimal 0x20 et 0x7e). Pour les langues autres que l’anglais, et pour d’autres objectifs, les caractères qui ne font pas partie du jeu de caractères imprimables ASCII sont souvent requises dans les adresses URL. Ces caractères peuvent être codés à l’aide des caractères imprimables, à des fins de transmission et d’interprétation. Il existe plusieurs méthodes différentes de codage utilisées pour la transmission des caractères situés hors de la plage autorisée. En dépit des spécifications HTTP, il existe également de nombreux serveurs Web sur le marché qui tolèrent simplement et acceptent les caractères situés hors de la plage légale. WebSEAL, en tant que proxy Web, doit être capable de gérer toutes ces situations. La méthode de codage de caractères la plus largement acceptée (et donc “standard”) est la méthode UTF-8. De nombreux serveurs Web présents sur le marché peuvent être configurés de façon à accepter le codage UTF-8. Le paramètre utf8-url-support-enabled inclus dans la strophe [server] du fichier de configuration webseald.conf contrôle la façon dont WebSEAL interprète les adresses URL envoyées par les navigateurs. Ce paramètre reconnaît les trois valeurs suivantes : v yes WebSEAL reconnaît uniquement le codage UTF-8 contenu dans les chaînes d’adresses URL et décode les informations présentes dans les jeux de caractères natifs (page de codes locale). Les autres techniques (telles que les jeux de caractères à double octets (DBCS) et Unicode), ne sont pas acceptées. v no WebSEAL ne reconnaît pas le codage UTF-8 dans les chaînes d’adresses URL. Toutes les informations codées UTF-8 ne sont pas interprétées correctement. Les autres techniques de codage sont acceptées. v auto WebSEAL tente de faire la distinction entre UTF-8 et les autres formes de codage de caractères (DBCS et Unicode). WebSEAL traite correctement tous les codages UTF-8 construits correctement. Si le codage n’est pas de type UTF-8, il est alors traité en Unicode ou DBCS. Lorsque utf8-url-support-enabled porte la valeur “yes” (valeur par défaut), WebSEAL suppose que les adresses URL peuvent inclure des caractères codés UTF-8. Ces caractères UTF-8 sont ensuite validés puis pris en compte lors de la détermination des droits d’accès pour l’adresse URL. L’adresse URL est normalisée (c’est-à-dire que les caractères codés sont convertis en équivalents dans leur page de codes locale) et le contrôle de LCA est appliqué à l’adresse URL normalisée. Le paramétrage par défaut n’autorise pas les adresses URL contenant des caractères Unicode ou DBCS se présentant sous la forme %uXXXX. Il s’agit là de la configuration recommandée pour WebSEAL. Certaines applications et certains serveurs Web existants ne fonctionnent pas correctement avec WebSEAL si le support UTF-8 est activé, car ces applications utilisent DBCS (comme par exemple Shift-JIS) dans l’adresse URL, ou encore d’autres méthodes de codage.
76
IBM Tivoli Access Manager - Guide d’administration WebSEAL
Si c’est le cas pour vous, vous devez exécuter les deux tâches suivantes : 1. Modifiez le fichier webseald.conf et définissez le nouveau paramètre comme suit : utf8-url-support-enabled = no
2. Assurez-vous que tous les serveurs reliés par jonction n’acceptent PAS les adresses URL codées en UTF-8. Pour des raisons de sécurité, il est important que WebSEAL interprète les adresses URL de la même façon que les serveurs reliés par jonction. La stratégie de déploiement recommandée est la suivante : 1. Sauf avis contraire pour des raisons de contenu, effectuez pour les déploiements de production un contrôle immédiat et définissez la LCA de default-webseal de façon à ne PAS autoriser les accès “r” non authentifiés. Pour des raisons de sécurité, cela permet de limiter l’accès aux utilisateurs qui possèdent un compte valide au sein du domaine Access Manager. 2. Assurez-vous que le paramètre utf8-url-support-enabled porte la valeur par défaut “yes”. 3. Testez vos applications. Si elles fonctionnent correctement, utilisez ce paramétrage. 4. Si l’une des applications échoue et entraîne l’affichage de messages d’erreur de type “Requête incorrecte”, affectez au paramètre utf8-url-support-enabled la valeur “no”, puis effectuez une nouvelle tentative. Si tout fonctionne bien, vous pouvez utiliser ce paramétrage pour votre déploiement. Toutefois, vous devez également vous assurer qu’aucun serveur Web relié par jonction n’est configuré pour accepter les adresses URL codées en UTF-8.
Prévention de la vulnérabilité causée par les scripts inter-sites Les scripts inter-sites font référence à une technique utilisée pour rendre les serveurs Web vulnérables via l’insertion de code malveillant dans les adresses URL de requêtes Web. WebSEAL contient une protection intégrée contre ce type de vulnérabilité et permet d’affiner cette protection grâce à la configuration du filtrage des chaînes d’adresses URL. Remarque : L’expression “scripts inter-sites”, bien qu’acceptée par les industriels, ne décrit pas complètement les nombreuses implications de cette insertion de code malveillant.
Principes de base Les scripts inter-sites représentent un type spécifique de vulnérabilité des serveurs Web qui naît de l’insertion d’un code malveillant dans une requête URL de client. Par exemple (Javascript) : <script>malicious_code
D’autres code de scripts peuvent entraîner une vulnérabilité :
