294
IBM Tivoli Access Manager Guide d’administration WebSEAL Version 3.9 GC11-1908-00

IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

  • Upload
    others

  • View
    5

  • Download
    0

Embed Size (px)

Citation preview

Page 1: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

IBM Tivoli Access Manager

Guide d’administration WebSEALVersion 3.9

GC11-1908-00

Page 2: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00
Page 3: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

IBM Tivoli Access Manager

Guide d’administration WebSEALVersion 3.9

GC11-1908-00

Page 4: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

RemarqueAvant d’utiliser le présent document et le produit associé, prenez connaissance des informations figurant à l’Annexe C,«Remarques» à la page 261.

Première édition – juillet 2002

LE PRESENT DOCUMENT EST LIVRE ″EN L’ETAT″. IBM DECLINE TOUTE RESPONSABILITE, EXPRESSE OUIMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y COMPRIS EN CE QUI CONCERNELES GARANTIES DE QUALITE MARCHANDE OU D’ADAPTATION A VOS BESOINS. Certaines juridictionsn’autorisent pas l’exclusion des garanties implicites, auquel cas l’exclusion ci-dessus ne vous sera pas applicable.

Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. Les informations qui ysont fournies sont susceptibles d’être modifiées avant que les produits décrits ne deviennent eux-mêmesdisponibles. En outre, il peut contenir des informations ou des références concernant certains produits, logiciels ouservices non annoncés dans ce pays. Cela ne signifie cependant pas qu’ils y seront annoncés.

Pour plus de détails, pour toute demande d’ordre technique, ou pour obtenir des exemplaires de documents IBM,référez-vous aux documents d’annonce disponibles dans votre pays, ou adressez-vous à votre partenairecommercial.

Vous pouvez également consulter les serveurs Internet suivants :v http://www.fr.ibm.com (serveur IBM en France)

v http://www.can.ibm.com (serveur IBM au Canada)

v http://www.ibm.com (serveur IBM aux Etats-Unis)

Compagnie IBM FranceDirection QualitéTour Descartes92066 Paris-La Défense Cedex 50

© Copyright IBM France 2002. Tous droits réservés.

© Copyright International Business Machines Corporation 1999, 2002. All rights reserved.

Page 5: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Table des matières

Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixA qui s’adresse ce guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixContenu de ce guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixPublications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xDocuments connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiAccès aux publications en ligne . . . . . . . . . . . . . . . . . . . . . . . . . . . xvCommande de publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvCommentaires sur les publications . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Accessibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviComment contacter le service d’assistance . . . . . . . . . . . . . . . . . . . . . . . . . xviConventions utilisées dans ce document . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Conventions utilisées dans ce guide . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Avis aux lecteurs canadiens . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL . . . . . . . . . . . 1Introduction à IBM Tivoli Access Manager et à WebSEAL . . . . . . . . . . . . . . . . . . . . 1Présentation du modèle de sécurité d’Access Manager . . . . . . . . . . . . . . . . . . . . . 3

Espace objets protégé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Définition et application de règles de LCA et POP . . . . . . . . . . . . . . . . . . . . . . 5Gestion des règles : Web Portal Manager . . . . . . . . . . . . . . . . . . . . . . . . . 7

Protection de l’espace Web grâce à WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . 7Planification et mise en oeuvre des règles de sécurité . . . . . . . . . . . . . . . . . . . . . . 8

Identification des types de contenu et des niveaux de protection . . . . . . . . . . . . . . . . . 9Explication de l’authentification WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . 10

Objectifs de l’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Accès authentifié et non authentifié aux ressources . . . . . . . . . . . . . . . . . . . . . 12Structure de la mémoire cache des sessions/des droits d’accès WebSEAL . . . . . . . . . . . . . . 13

Explication des jonctions WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Jonctions WebSEAL et évolutivité de site Web . . . . . . . . . . . . . . . . . . . . . . . 16

Chapitre 2. Configuration de base du serveur . . . . . . . . . . . . . . . . . . . 21Informations générales sur le serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Répertoire racine de l’installation WebSEAL . . . . . . . . . . . . . . . . . . . . . . . 21Démarrage et arrêt de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 22WebSEAL représenté dans l’espace objets protégé. . . . . . . . . . . . . . . . . . . . . . 22WebSEAL renvoie HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Fichier journal WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Utilisation du fichier de configuration WebSEAL . . . . . . . . . . . . . . . . . . . . . . . 23Présentation du fichier de configuration webseald.conf . . . . . . . . . . . . . . . . . . . . 23Répertoire racine du serveur WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . 25

Configuration des paramètres de communication . . . . . . . . . . . . . . . . . . . . . . . 26Configuration de WebSEAL pour les requêtes HTTP. . . . . . . . . . . . . . . . . . . . . 26Configuration de WebSEAL pour les requêtes HTTPS . . . . . . . . . . . . . . . . . . . . 26Restriction des connexions à partir de versions SSL spécifiques . . . . . . . . . . . . . . . . . 27Paramètres de délai d’expiration pour les communications HTTP/HTTPS . . . . . . . . . . . . . 27Autres paramètres de délai d’expiration du serveur WebSEAL . . . . . . . . . . . . . . . . . 28

Gestion de l’espace Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Répertoire racine de l’arborescence des documents Web . . . . . . . . . . . . . . . . . . . 28Configuration de l’indexation de répertoires . . . . . . . . . . . . . . . . . . . . . . . 29Windows : conventions de dénomination de fichiers pour les programmes CGI . . . . . . . . . . . 30Configuration de la mémoire cache d’un document Web . . . . . . . . . . . . . . . . . . . 31Spécification de types de documents à filtrer . . . . . . . . . . . . . . . . . . . . . . . 34

Gestion des pages personnalisées de messages d’erreur HTTP . . . . . . . . . . . . . . . . . . 34

© Copyright IBM Corp. 1999, 2002 iii

Page 6: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Prise en charge de macro pour les pages de messages d’erreur HTTP . . . . . . . . . . . . . . . 36Gestion des pages personnalisées de gestion de comptes . . . . . . . . . . . . . . . . . . . . 37

Valeurs et paramètres de page personnalisée . . . . . . . . . . . . . . . . . . . . . . . 37Descriptions de pages HTML personnalisées . . . . . . . . . . . . . . . . . . . . . . . 38

Gestion des certificats côté client et côté serveur . . . . . . . . . . . . . . . . . . . . . . . 39Présentation des types de fichier de la base de données de clés . . . . . . . . . . . . . . . . . 40Configuration de paramètres de base de données de clés . . . . . . . . . . . . . . . . . . . 41Utilisation de l’utilitaire de gestion de certificat iKeyman . . . . . . . . . . . . . . . . . . . 42Configuration du contrôle CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Configuration du cache CRL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Configuration de la journalisation HTTP par défaut . . . . . . . . . . . . . . . . . . . . . . 44Activation et désactivation de la journalisation HTTP . . . . . . . . . . . . . . . . . . . . 44Spécification du type d’horodatage . . . . . . . . . . . . . . . . . . . . . . . . . . 45Spécification du seuil de renouvellement des fichiers journaux . . . . . . . . . . . . . . . . . 45Spécification de la fréquence de vidage des mémoires tampon de fichier journal . . . . . . . . . . . 45Format de journal HTTP courant (pour request.log) . . . . . . . . . . . . . . . . . . . . . 45Affichage du fichier request.log. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Affichage du fichier agent.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Affichage du fichier referer.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Configuration de la journalisation HTTP par défaut . . . . . . . . . . . . . . . . . . . . . . 47Consignation des messages de mise en service WebSEAL . . . . . . . . . . . . . . . . . . . . 48

Chapitre 3. Configuration avancée du serveur . . . . . . . . . . . . . . . . . . . 51Configuration d’un niveau de protection par défaut . . . . . . . . . . . . . . . . . . . . . . 51

Configuration du niveau de protection pour les réseaux et les hôtes individuels . . . . . . . . . . . 52Configuration des mises à jour et de l’interrogation de la base de données d’autorisation . . . . . . . . . 53

Configuration de l’écoute des notifications de mise à jour . . . . . . . . . . . . . . . . . . . 53Configuration de l’interrogation de la base de données d’autorisation . . . . . . . . . . . . . . . 54

Gestion des affectations des unités d’exécution d’agents . . . . . . . . . . . . . . . . . . . . 54Configuration des unités d’exécution d’agents WebSEAL . . . . . . . . . . . . . . . . . . . 54Affectation des unités d’exécution d’agents pour les jonctions (limite maximale) . . . . . . . . . . . 55

Réplication de serveurs frontaux WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . 57Configuration de plusieurs instances de serveur WebSEAL . . . . . . . . . . . . . . . . . . . 58

Généralités sur la configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Configuration de plusieurs instances WebSEAL sous UNIX . . . . . . . . . . . . . . . . . . 58Configuration de plusieurs instances WebSEAL sous Win NT/2000 . . . . . . . . . . . . . . . 61Déconfiguration de plusieurs instances WebSEAL . . . . . . . . . . . . . . . . . . . . . 63Commandes de serveur start, stop, restart et status . . . . . . . . . . . . . . . . . . . . . 63

Configuration du changement d’utilisateur pour les administrateurs . . . . . . . . . . . . . . . . 65Explication du processus de changement d’utilisateur . . . . . . . . . . . . . . . . . . . . 65Activation du changement d’utilisateur : récapitulatif . . . . . . . . . . . . . . . . . . . . 67Configuration du formulaire HTML de changement d’utilisateur . . . . . . . . . . . . . . . . 67Activation et exclusion d’utilisateurs pour le changement d’utilisateur. . . . . . . . . . . . . . . 69Configuration de la méthode d’authentification par changement d’utilisateur . . . . . . . . . . . . 69Configuration d’une méthode de changement d’utilisateur CDAS . . . . . . . . . . . . . . . . 70Impact sur les autres fonctionnalités WebSEAL . . . . . . . . . . . . . . . . . . . . . . 71

Configuration de la mise en mémoire cache des requêtes WebSEAL côté serveur . . . . . . . . . . . . 72Principes de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Flux du processus de mise en mémoire cache côté serveur. . . . . . . . . . . . . . . . . . . 73Configuration des paramètres de mise en mémoire cache côté serveur. . . . . . . . . . . . . . . 74Notes et limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Gestion des caractères codés UTF-8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Prévention de la vulnérabilité causée par les scripts inter-sites . . . . . . . . . . . . . . . . . . 77

Principes de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Configuration du filtrage des chaînes d’adresses URL . . . . . . . . . . . . . . . . . . . . 78

Suppression de l’identité de serveurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Utilisation des statistiques WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Syntaxe de la commande pdadmin stats . . . . . . . . . . . . . . . . . . . . . . . . . 79Composants statistiques et types d’activités. . . . . . . . . . . . . . . . . . . . . . . . 82Activation statique des statistiques à l’aide de la journalisation d’événements . . . . . . . . . . . . 88

Utilisation de l’utilitaire de trace pour regrouper les actions de WebSEAL . . . . . . . . . . . . . . 89

iv IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 7: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Syntaxe applicable aux commandes de base de l’utilitaire de trace . . . . . . . . . . . . . . . . 89Composants de trace de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Chapitre 4. Règles de sécurité WebSEAL . . . . . . . . . . . . . . . . . . . . . 93Règles de LCA spécifiques de WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . 93

/WebSEAL/<hôte>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93/WebSEAL/<hôte>/<fichier> . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Droits d’accès LCA WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Règles de LCA WebSEAL par défaut . . . . . . . . . . . . . . . . . . . . . . . . . . 94Caractères valides pour les noms de LCA . . . . . . . . . . . . . . . . . . . . . . . . 94

Limitation des tentatives de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . 95Syntaxe de commande. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Règle de renforcement de mot de passe . . . . . . . . . . . . . . . . . . . . . . . . . . 96Règle de renforcement de mot de passe définie par l’utilitaire pdadmin . . . . . . . . . . . . . . 96Syntaxe de commande. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Exemples de mots de passe valides et invalides . . . . . . . . . . . . . . . . . . . . . . 98Valeurs globales et spécifiques d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . 98

Règles POP de renforcement d’authentification (authentification avancée) . . . . . . . . . . . . . . 99Configuration des niveaux pour une augmentation du niveau d’authentification . . . . . . . . . . . 99Activation de l’authentification avancée . . . . . . . . . . . . . . . . . . . . . . . . 100Formulaire de connexion d’authentification avancée . . . . . . . . . . . . . . . . . . . . 102Algorithme d’autentification avancée . . . . . . . . . . . . . . . . . . . . . . . . . 103Notes et limites de l’authentification avancée . . . . . . . . . . . . . . . . . . . . . . . 103Différence entre authentification avancée et authentification à facteurs multiples . . . . . . . . . . . 104

Règles POP d’authentification basée sur réseau . . . . . . . . . . . . . . . . . . . . . . . 105Configuration des niveaux d’authentification . . . . . . . . . . . . . . . . . . . . . . . 105Spécification des adresses IP et des plages . . . . . . . . . . . . . . . . . . . . . . . . 105Désactivation du renforcement d’authentification par adresse IP . . . . . . . . . . . . . . . . 107Algorithme d’authentification basée sur réseau . . . . . . . . . . . . . . . . . . . . . . 107Notes et limites de l’authentification avancée . . . . . . . . . . . . . . . . . . . . . . . 107

Niveau de protection des règles POP . . . . . . . . . . . . . . . . . . . . . . . . . . 107Gestion des utilisateurs non authentifiés (HTTP/HTTPS) . . . . . . . . . . . . . . . . . . . . 108

Traitement d’une requête émanant d’un client anonyme . . . . . . . . . . . . . . . . . . . 108Forçage de la connexion utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . 108Applications de l’accès HTTPS non authentifié . . . . . . . . . . . . . . . . . . . . . . 109Contrôle d’utilisateurs non authentifiés avec des règles de LCA/POP . . . . . . . . . . . . . . 109

Chapitre 5. Authentification WebSEAL . . . . . . . . . . . . . . . . . . . . . . 111Explication du processus d’authentification . . . . . . . . . . . . . . . . . . . . . . . . 111

Types de données de session pris en charge . . . . . . . . . . . . . . . . . . . . . . . 112Méthodes d’authentification prises en charge . . . . . . . . . . . . . . . . . . . . . . . 112

Gestion de l’état de session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Généralités sur l’état de session . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Généralités sur la mémoire cache de session GSKit et WebSEAL . . . . . . . . . . . . . . . . 113Configuration de la mémoire cache d’ID de session GSKit SSL . . . . . . . . . . . . . . . . . 114Configuration de la mémoire cache des droits d’accès WebSEAL . . . . . . . . . . . . . . . . 115Gestion de l’état avec des cookies de session . . . . . . . . . . . . . . . . . . . . . . . 116Détermination des types de données d’ID de session valides . . . . . . . . . . . . . . . . . 118Configuration de cookies de secours. . . . . . . . . . . . . . . . . . . . . . . . . . 119

Généralités sur la configuration de l’authentification . . . . . . . . . . . . . . . . . . . . . 122Paramètres locaux d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . 123Paramètres externes personnalisés d’authentification CDAS . . . . . . . . . . . . . . . . . . 123Configuration par défaut pour l’authentification WebSEAL . . . . . . . . . . . . . . . . . . 123Configuration de plusieurs méthodes d’authentification . . . . . . . . . . . . . . . . . . . 124Invite de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Commandes de déconnexion et de modification de mot de passe . . . . . . . . . . . . . . . . 125

Configuration de l’authentification de base . . . . . . . . . . . . . . . . . . . . . . . . 126Activation et désactivation de l’authentification de base . . . . . . . . . . . . . . . . . . . 126Définition du nom de domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Configuration de la méthode d’authentification de base . . . . . . . . . . . . . . . . . . . 127

Table des matières v

Page 8: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Conditions de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Configuration de l’authentification à base de formulaires . . . . . . . . . . . . . . . . . . . . 127

Activation et désactivation de l’authentification par formulaires . . . . . . . . . . . . . . . . 127Configuration de la méthode d’authentification par formulaires . . . . . . . . . . . . . . . . 128Conditions de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Personnalisation des formulaires de réponse HTML . . . . . . . . . . . . . . . . . . . . 128

Configuration de l’authentification par certificat côté client . . . . . . . . . . . . . . . . . . . 129Contexte : Authentification réciproque via des certificats . . . . . . . . . . . . . . . . . . . 129Certificat de test WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Activation et désactivation de l’authentification par certificat . . . . . . . . . . . . . . . . . 131Configuration de la méthode d’authentification par certificat . . . . . . . . . . . . . . . . . 131Conditions de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Configuration de l’authentification par en-tête HTTP . . . . . . . . . . . . . . . . . . . . . 132Activation et désactivation de l’authentification par en-tête HTTP . . . . . . . . . . . . . . . . 132Spécification de types d’en-têtes . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Configuration de la méthode d’authentification par en-tête HTTP . . . . . . . . . . . . . . . . 133Conditions de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Configuration de l’authentification par adresse IP . . . . . . . . . . . . . . . . . . . . . . 134Activation et désactivation de l’authentification par adresse IP . . . . . . . . . . . . . . . . . 134Configuration de la méthode d’authentification par adresse IP . . . . . . . . . . . . . . . . . 134

Configuration de l’authentification par jeton . . . . . . . . . . . . . . . . . . . . . . . . 134Activation et désactivation de l’authentification par jeton. . . . . . . . . . . . . . . . . . . 134Configuration de la méthode d’authentification par jeton . . . . . . . . . . . . . . . . . . . 134

Prise en charge du multiplexage d’agents proxy . . . . . . . . . . . . . . . . . . . . . . . 135Types de données de session valides et méthodes d’authentification . . . . . . . . . . . . . . . 136Flux de processus d’authentification pour les agents MPA et des clients multiples . . . . . . . . . . 137Activation et désactivation de l’authentification MPA . . . . . . . . . . . . . . . . . . . . 138Création d’un compte utilisateur pour l’agent MPA . . . . . . . . . . . . . . . . . . . . 138Ajout du compte MPA au groupe webseal-mpa-servers . . . . . . . . . . . . . . . . . . . 138Limites de l’authentification MPA . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Configuration de la nouvelle authentification sur la base de la stratégie de sécurité . . . . . . . . . . . 138Conditions affectant la nouvelle authentification POP . . . . . . . . . . . . . . . . . . . . 138Création et application de règles POP de nouvelle authentification . . . . . . . . . . . . . . . 139Configuration de la réinitialisation et de l’allongement de la durée de vie du cache de session . . . . . . 140

Configuration de la nouvelle authentification sur la base de la règle d’inactivité de session . . . . . . . . 141Conditions affectant la nouvelle authentification pour inactivité . . . . . . . . . . . . . . . . 141Activation de la nouvelle authentification pour inactivité . . . . . . . . . . . . . . . . . . . 143Configuration de la réinitialisation et de l’allongement de la durée de vie du cache de session . . . . . . 143

Chapitre 6. Solutions de connexion unique interdomaine (CDSSO) . . . . . . . . . 145Configuration de l’authentification CDSSO . . . . . . . . . . . . . . . . . . . . . . . . 145

Intégration d’une bibliothèque partagée CDMF . . . . . . . . . . . . . . . . . . . . . . 145Flux du processus d’authentification pour CDSSO avec CDMF . . . . . . . . . . . . . . . . . 146Activation et désactivation de l’authentification CDSSO . . . . . . . . . . . . . . . . . . . 147Configuration de la méthode d’authentification CDSSO . . . . . . . . . . . . . . . . . . . 147Chiffrement des données d’authentification du jeton . . . . . . . . . . . . . . . . . . . . 148Configuration de l’horodate du jeton . . . . . . . . . . . . . . . . . . . . . . . . . 148Expression des liens HTML CDSSO . . . . . . . . . . . . . . . . . . . . . . . . . . 149Protection du jeton d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . 149

Configuration de la connexion unique de communauté électronique . . . . . . . . . . . . . . . . 149Fonctions de la communauté électronique et conditions requises . . . . . . . . . . . . . . . . 151Flux du processus de communauté électronique . . . . . . . . . . . . . . . . . . . . . . 152Explication du cookie de communauté électronique . . . . . . . . . . . . . . . . . . . . 156Explication de la requête et de la réponse “d’attestation” . . . . . . . . . . . . . . . . . . . 156Explication du jeton “d’attestation” . . . . . . . . . . . . . . . . . . . . . . . . . . 157Chiffrement du jeton “d’attestation” . . . . . . . . . . . . . . . . . . . . . . . . . . 157Configuration de la communauté électronique . . . . . . . . . . . . . . . . . . . . . . 158

Chapitre 7. Jonctions WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . 163Présentation des jonctions WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . 163

vi IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 9: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Emplacement et format de la base de données des jonctions . . . . . . . . . . . . . . . . . . 163Application du contrôle d’accès allégé : récapitulatif . . . . . . . . . . . . . . . . . . . . 164Application du contrôle d’accès allégé : récapitulatif . . . . . . . . . . . . . . . . . . . . 164Directives en matière de création de jonctions WebSEAL junctions. . . . . . . . . . . . . . . . 164Références supplémentaires pour les jonctions WebSEAL . . . . . . . . . . . . . . . . . . . 165

Utilisation de pdadmin pour créer des jonctions . . . . . . . . . . . . . . . . . . . . . . . 165Configuration d’une jonction WebSEAL de base . . . . . . . . . . . . . . . . . . . . . . . 166

Création de jonctions de type TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 167Création de jonctions de type SSL . . . . . . . . . . . . . . . . . . . . . . . . . . 167Ajout de serveurs d’arrière-plan à une jonction . . . . . . . . . . . . . . . . . . . . . . 168

Jonctions SSL authentifiées de façon réciproque . . . . . . . . . . . . . . . . . . . . . . . 169WebSEAL valide le certificat du serveur d’arrière-plan . . . . . . . . . . . . . . . . . . . 169Mise en correspondance des noms distinctifs (DN) . . . . . . . . . . . . . . . . . . . . . 170WebSEAL s’authentifie avec le certificat client . . . . . . . . . . . . . . . . . . . . . . 170WebSEAL s’authentifie avec l’en-tête BA . . . . . . . . . . . . . . . . . . . . . . . . 171Gestion des informations d’identité du client sur les différentes jonctions . . . . . . . . . . . . . 171

Création de jonctions proxy TCP et SSL . . . . . . . . . . . . . . . . . . . . . . . . . 172Jonctions WebSEAL/WebSEAL via SSL . . . . . . . . . . . . . . . . . . . . . . . . . . 173Modification des adresses URL des ressources d’arrière-plan . . . . . . . . . . . . . . . . . . 173

Présentation des types de chemins d’accès utilisés dans les adresses URL . . . . . . . . . . . . . 175Filtrage des adresses URL dans les réponses . . . . . . . . . . . . . . . . . . . . . . . 175Traitement des adresses URL dans les requêtes . . . . . . . . . . . . . . . . . . . . . . 178

Autres options de jonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Nouvelle fonction forcée (–f) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Spécification de l’identité du client dans les en-têtes HTTP (–c) . . . . . . . . . . . . . . . . . 182Spécification des adresses IP client dans les en-têtes HTTP (–r) . . . . . . . . . . . . . . . . . 183Limitation de la taille des en-têtes HTTP générés par WebSEAL . . . . . . . . . . . . . . . . 184Transmission de cookies de session à des serveurs de portail reliés par jonction (–k). . . . . . . . . . 184Prise en charge d’adresses URL sans distinction de casse (–i) . . . . . . . . . . . . . . . . . 185Prise en charge d’une jonction avec état (–s, –u) . . . . . . . . . . . . . . . . . . . . . . 185Spécification d’UUID de serveur d’arrière-plan pour des jonctions avec état (–u) . . . . . . . . . . . 186Etablissement de jonctions avec des systèmes de fichiers Windows (–w) . . . . . . . . . . . . . . 188

Remarques techniques sur l’utilisation des jonctions WebSEAL . . . . . . . . . . . . . . . . . . 190Montage de plusieurs serveurs sur la même jonction . . . . . . . . . . . . . . . . . . . . 190Exceptions à la mise en oeuvre des droits d’accès sur les jonctions . . . . . . . . . . . . . . . 190Authentification par certificat sur les jonctions . . . . . . . . . . . . . . . . . . . . . . 190

Utilisation de query_contents avec des serveurs tiers . . . . . . . . . . . . . . . . . . . . . 191Installation des composants query_contents . . . . . . . . . . . . . . . . . . . . . . . 191Installation de query_contents sur des serveurs UNIX tiers . . . . . . . . . . . . . . . . . . 192Installation de query_contents sur des serveurs Win32 tiers . . . . . . . . . . . . . . . . . . 192Personnalisation de query_contents . . . . . . . . . . . . . . . . . . . . . . . . . . 194Sécurisation de query_contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Chapitre 8. Solutions de connexion unique Web . . . . . . . . . . . . . . . . . 197Configuration d’en-têtes BA pour des solutions SSO . . . . . . . . . . . . . . . . . . . . . 197

Concepts de connexion unique (Single sign-on - SSO) . . . . . . . . . . . . . . . . . . . . 197Spécification de l’identité client dans les en-têtes BA . . . . . . . . . . . . . . . . . . . . 198Spécification de l’identité client et du mot de passe générique . . . . . . . . . . . . . . . . . 198Transmission des informations d’en-tête BA du client . . . . . . . . . . . . . . . . . . . . 200Suppression des informations d’en-tête BA client . . . . . . . . . . . . . . . . . . . . . 200Spécification de noms d’utilisateur et de mots de passe à partir de GSO. . . . . . . . . . . . . . 201

Utilisation d’une connexion globale (GSO). . . . . . . . . . . . . . . . . . . . . . . . . 201Mappage des informations d’authentification . . . . . . . . . . . . . . . . . . . . . . . 203Configuration d’une jonction WebSEAL activée GSO . . . . . . . . . . . . . . . . . . . . 203Configuration du cache GSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Configuration d’une connexion unique à IBM WebSphere (LTPA) . . . . . . . . . . . . . . . . . 205Configuration d’une jonction LTPA . . . . . . . . . . . . . . . . . . . . . . . . . . 205Configuration du cache LTPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Remarques techniques sur les connexions uniques . . . . . . . . . . . . . . . . . . . . . 207

Configuration d’une authentification à base de formulaires (connexion unique) . . . . . . . . . . . . 207Présentation et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Table des matières vii

Page 10: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Processus de la connexion unique à base de formulaires . . . . . . . . . . . . . . . . . . . 208Conditions requises pour le support d’applications . . . . . . . . . . . . . . . . . . . . . 209Création du fichier de configuration pour les connexions uniques à base de formulaires . . . . . . . . 210Activation de la connexion unique à base de formulaires . . . . . . . . . . . . . . . . . . . 214Exemple de fichier de configuration pour IBM HelpNow. . . . . . . . . . . . . . . . . . . 214

Chapitre 9. Intégration d’application . . . . . . . . . . . . . . . . . . . . . . 217Prise en charge de la programmation CGI . . . . . . . . . . . . . . . . . . . . . . . . . 217

Windows : prise en charge des variables d’environnement WIN32 . . . . . . . . . . . . . . . 218Prise en charge des applications serveur d’arrière-plan . . . . . . . . . . . . . . . . . . . . 219Meilleures pratiques de jonction applicables à l’intégration d’applications . . . . . . . . . . . . . . 220

Fourniture d’informations d’en-tête HOST complètes avec -v . . . . . . . . . . . . . . . . . 220Prise en charge du filtrage des adresses URL absolues standard . . . . . . . . . . . . . . . . 220

Création d’un service d’individualisation personnalisé. . . . . . . . . . . . . . . . . . . . . 221Configuration de WebSEAL pour un service d’individualisation . . . . . . . . . . . . . . . . 222Exemple de service d’individualisation . . . . . . . . . . . . . . . . . . . . . . . . . 222

Activation dynamique des droits d’accès (code/valeur) . . . . . . . . . . . . . . . . . . . . 223Création de droits d’accès à partir de données LDAP . . . . . . . . . . . . . . . . . . . . 223

Mise à jour des données sur l’état de la session entre le client et les applications d’arrière-plan . . . . . . . 226Contexte de la gestion des sessions utilisateurs . . . . . . . . . . . . . . . . . . . . . . 226Activation de la gestion des ID de sessions utilisateurs . . . . . . . . . . . . . . . . . . . 227Insertion des données d’autorisation dans l’en-tête HTTP. . . . . . . . . . . . . . . . . . . 227Fin des sessions utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Ajout d’un contrôle d’accès à des adresses URL dynamiques . . . . . . . . . . . . . . . . . . 230Composants d’adresses URL dynamiques . . . . . . . . . . . . . . . . . . . . . . . . 230Mappage d’objets de LCA et POP à des adresses URL dynamiques . . . . . . . . . . . . . . . 231Mise à jour de WebSEAL pour les adresses URL dynamiques . . . . . . . . . . . . . . . . . 233Conversion des adresses URL dynamiques dans l’espace objet . . . . . . . . . . . . . . . . . 233Configuration de limites sur les requêtes POST . . . . . . . . . . . . . . . . . . . . . . 234Résumé et remarques techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Exemple d’adresse URL dynamique : Travel Kingdom . . . . . . . . . . . . . . . . . . . . 236Présentation de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Présentation de l’interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Présentation des règles de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . 237Protection des clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Annexe A. Références du fichier webseald.conf . . . . . . . . . . . . . . . . . 239

Annexe B. Référence des jonctions WebSEAL . . . . . . . . . . . . . . . . . . 253Utilisation de pdadmin pour créer des jonctions . . . . . . . . . . . . . . . . . . . . . . . 253Commandes de jonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Création d’une nouvelle jonction pour un serveur existant . . . . . . . . . . . . . . . . . . . 256Ajout d’un serveur supplémentaire à une jonction existante . . . . . . . . . . . . . . . . . . . 258

Annexe C. Remarques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261Marques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

viii IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 11: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Avant-propos

Bienvenue dans IBMTivoliAccess Manager - Guide d’administration WebSEAL.

IBM Tivoli Access Manager WebSEAL est le gestionnaire de sécurité de ressourcespour les ressources basées sur le Web. WebSEAL est un serveur Web à hautesperformances 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 Webd’arrière-plan dans ses règles de sécurité.

Ce guide d’administration contient un ensemble complet de procédures etd’informations de référence qui peuvent vous aider à gérer les ressources de votredomaine Web sécurisé. Il vous apporte également des informations intéressantes enmatière de contexte et de concepts, sur la grande gamme des fonctionnalitésWebSEAL.

Remarque : Certains graphiques de cette brochure ne sont pas disponibles enfrançais à la date d’impression.

A qui s’adresse ce guideCe guide s’adresse aux administrateurs système chargés de la configuration et dela maintenance d’un environnement Access Manager WebSEAL.

Vous devez posséder des connaissances dans les domaines suivants :v Systèmes d’exploitation PC et UNIXv Architecture et concepts de bases de donnéesv 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épertoiresv Registres d’utilisateurs pris en chargev 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ésd’accréditation.

Contenu de ce guidev Chapitre 1 : Généralités sur IBM Tivoli Access Manager WebSEAL

Ce chapitre présente les concepts et fonctionnalités importants de WebSEAL :organisation et protection de votre espace objet, authentification, acquisition desdonnées d’identification et jonctions WebSEAL.

v Chapitre 2 : Configuration de base du serveur

Ce chapitre sert de référence technique pour les grandes tâches de configurationde WebSEAL : utilisation du fichier de configuration WebSEAL, gestion del’espace Web, gestion des certificats et configuration des connexions.

v Chapitre 3 : Configuration avancée du serveur

© Copyright IBM Corp. 1999, 2002 ix

Page 12: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Ce chapitre sert de référence technique pour les grandes tâches de configurationavancée de WebSEAL : configuration de plusieurs instances WebSEAL,configuration de la fonctionnalité de changement d’utilisateur, gestion del’allocation des unités d’agent et configuration des mises à jour et desinterrogations de la base de données d’autorisations.

v Chapitre 4 : Règles de sécurité WebSEAL

Ce chapitre contient des procédures techniques détaillées pour lapersonnalisation des règles de sécurité sur WebSEAL : règles POP et LCA,qualité de la protection, renforcement des règles d’authentification, règlesd’authentification basées sur le réseau, règles de tentatives limitées de connexionet règles de renforcement du mot de passe.

v Chapitre 5 : Authentification WebSEAL

Ce chapitre contient des procédures techniques détaillées sur la configuration deWebSEAL pour gérer toute une série de méthodes d’authentification : nomd’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.

v Chapitre 6 : Solutions de connexion interdomaine

Ce chapitre traite des solutions de connexion interdomaine pour le côté externed’une configuration proxy WebSEAL (entre le client et le serveur WebSEAL).

v Chapitre 7 : Jonctions WebSEAL

Ce chapitre sert de référence technique exhaustive à l’installation et à l’utilisationdes jonctions WebSEAL.

v Chapitre 8 : Solutions de connexion unique Web

Ce chapitre traite des solutions de connexion unique (SSO) pour le côté interned’une configuration proxy WebSEAL (entre le serveur WebSEAL et le serveurd’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 lesfonctionnalité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

PublicationsCette section répertorie les publications incluses dans la bibliothèque d’AccessManager ainsi que d’autres documents connexes. Elle décrit également la méthoded’accès en ligne aux publications Tivoli, de commande de ces dernières ou d’envoide commentaires.

IBM Tivoli Access ManagerLa bibliothèque d’Access Manager est organisée autour des catégories suivantes :v Informations sur les versionsv Informations sur la basev Informations relatives à WebSEALv Informations relatives à la sécurité sur le Webv Informations de référence pour développeursv 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

Page 13: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

à l’aide d’un navigateur Web, ouvrez le fichier infocenter.html, que voustrouverez dans le répertoire /doc sur le CD du produit.

Pour obtenir d’autres sources d’informations sur Access Manager et sur des thèmesconnexes, visitez les sites Web suivants :

http://www.ibm.com/redbookshttps://www.tivoli.com/secure/support/documents/fieldguides

Informations sur les versionsv 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 utilisationsd’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, lessolutions et les mises à jour de documentation).

Informations relatives à la basev IBM Tivoli Access Manager Base Installation Guide

GC32-0844 (am39_install.pdf )Fournit les procédures d’installation, de configuration et de mise à niveau dulogiciel 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 PortalManager 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 AccessManager pour Linux sur plate-forme zSeries.

Informations relatives à WebSEALv IBM Tivoli Access Manager WebSEAL Installation Guide

GC32-0848 (amweb39_install.pdf)Fournit les instructions d’installation, de configuration et de désinstallation duserveur 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 informationstechniques permettant d’utiliser WebSEAL afin de gérer les ressources de votredomaine 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 auxmodules CDAS (Cross-domain Authentication Service), CDMF (Cross-domainMapping Framework) et à la validation de mot de passe.

v IBM Tivoli Access Manager WebSEAL for Linux on zSeries Installation Guide

Avant-propos xi

Page 14: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

GC23-4797 (amweb39_zinstall.pdf)Fournit les instructions d’installation, de configuration et de désinstallation duserveur WebSEAL et du kit de développement d’applications WebSEAL pourLinux sur plate-forme zSeries.

Informations relatives à la sécurité sur le Webv 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’administrationd’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’administrationd’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 duplug-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 lesinformations techniques permettant de sécuriser votre domaine Web à l’aide duplug-in pour applications de serveurs Web.

Guides de référence pour développeursv 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 del’API C d’autorisations d’Access Manager et de l’interface Access ManagerService 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 seinde 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’administrationafin de permettre à une application d’exécuter des tâches d’administrationAccess Manager. Ce document décrit la mise en oeuvre C de l’APId’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 seinde 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

Page 15: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Fournit des informations de programmation et d’administration applicables auxmodules CDAS (Cross-domain Authentication Service), CDMF (Cross-domainMapping Framework) et à la validation de mot de passe.

Documents techniques supplémentairesv IBM Tivoli Access Manager Performance Tuning Guide

GC32-0846 (am39_perftune.pdf)Fournit des informations d’optimisation des performances adaptées à unenvironnement composé d’Access Manager avec IBM SecureWay Directory définicomme 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 Webrequis (serveurs WebSEAL, LDAP et d’arrière-plan) pour l’exécution d’unecharge 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 techniquesrelatifs 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 connexesCette section répertorie les documents relatifs à la bibliothèque Access Manager.

Base de données universelle IBM DB2La base de données universelle IBM DB2 est requise lors de l’installation desserveurs IBM SecureWay Directory, LDAP SecureWay z/OS et OS/390. Voustrouverez des informations relatives à DB2 sur le site Web suivant :

http://www.ibm.com/software/data/db2/

IBM Global Security ToolkitAccess Manager permet d’effectuer un chiffrement de données via l’utilisationd’IBM Global Security Toolkit (GSKit). Vous trouverez GSKit sur le CD d’IBMTivoli Access Manager Base pour votre plate-forme spécifique.

GSKit installe l’utilitaire de gestion iKeyman (gsk5ikm). Ce dernier vous permet decréer des bases de données de clés, des paires de clés publiques-privées et desrequê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 lasécurité du système ou des administrateurs réseau chargés d’activer lescommunications SSL dans leur domaine sécurisé Access Manager.

Avant-propos xiii

Page 16: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

IBM SecureWay DirectoryVous trouverez IBM SecureWay Directory (version 3.2.2) sur le CD d’IBM TivoliAccess Manager Base pour votre plate-forme spécifique. Si vous souhaitez installerle serveur IBM SecureWay Directory en tant que registre d’utilisateurs, voustrouverez les documents suivants dans le répertoire /doc/Directory sur le CD IBMTivoli 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 lescomposants IBM SecureWay Directory sous AIX, Linux, Solaris et MicrosoftWindows.

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èsla traduction de la documentation relative à IBM SecureWay Directory. Ce fichierexiste 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 (version3.2.2).Ce kit de développement logiciel (SDK) constitue un support dedéveloppement d’applications LDAP.

v SSL Introduction and iKeyman User’s Guide

(gskikm5c.pdf)Ce document fournit des informations à l’attention des responsables de lasécurité du système ou des administrateurs réseau chargés d’activer lescommunications 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éspour configurer le fichier slapd32.conf. Dans IBM SecureWay Directory (version3.2), les paramètres du répertoire sont stockés au format LDIF (LDAP DirectoryInterchange Format) dans le fichier slapd32.conf.

v IBM SecureWay Directory Tuning Guide

(tuning.pdf)Fournit des informations de réglage des performances pour IBM SecureWayDirectory. Lorsqu’elles sont disponibles, des informations sont fournies sur leréglage des tailles de répertoires (de quelques milliers d’entrées à plusieursmillions d’entrées).

Pour plus d’informations sur IBM SecureWay Directory, visitez le site Websuivant :

http://www.software.ibm.com/network/directory/library/

xiv IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 17: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

IBM WebSphere Application ServerIBM WebSphere Application Server, Advanced Single Server Edition (version 4.0.2)est installé en même temps que l’interface Web Portal Manager. Pour plusd’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 ligneVous trouverez les publications des bibliothèques produit sur le CD produit, auformat PDF (Portable Document Format). Pour accéder à ces publications à l’aided’un navigateur Web, ouvrez le fichier infocenter.html (que vous trouverez dansle répertoire /doc du CD produit.

Lorsqu’IBM publie une nouvelle version de certaines publications (en ligne ou sousforme de documents), celle-ci figure dans le centre de documentation Tivoli. Lecentre de documentation Tivoli contient la version la plus récente des publicationsde la bibliothèque produit, au format PDF ou HTML (ou encore aux deux). Desdocuments traduits sont également disponibles pour certains produits.

Vous pouvez accéder au centre de documentation Tivoli et à d’autres sourcesd’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 etdes documents de référence pour développeurs.

Remarque : Si vous imprimez des documents sur un autre papier que le papierlettre, cochez la case Fit to page dans la boîte de dialogued’impression d’Adobe Acrobat (qui s’affiche lorsque vous cliquez surFile → Print) pour garantir que les dimensions totales d’une page auformat lettre sont prises en compte pour l’impression sur le papierutilisé.

Commande de publicationsVous pouvez commander de nombreuses publications Tivoli en ligne à partir dusite 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’undes numéros suivants :v Aux Etats-Unis, composez le 800-879-2755.v Au Canada, composez le 800-426-4968v 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

Page 18: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Commentaires sur les publicationsVos 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 faireparvenir vos commentaires et suggestions sur ce guide en procédant de l’une desmanières suivantes :v Envoyez un courrier électronique à [email protected] 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 à ceproduit, vous pouvez utiliser des techniques qui vous aident à entendre et ànaviguer dans l’interface. Vous pouvez également vous servir du clavier plutôt quede la souris pour utiliser toutes les fonctions de l’interface graphique utilisateur.

Comment contacter le service d’assistanceEn cas d’incident lors de l’utilisation de l’un des produits Tivoli, vous pouvez faireappel au service d’assistance Tivoli. Reportez-vous au document Tivoli CustomerSupport 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 fonctionde la gravité du problème rencontré et contient les informations suivantesv Enregistrement et éligibilitév Numéros de téléphone et adresses électroniques en fonction du paysv Informations à préparer avant de prendre contact avec le support

Conventions utilisées dans ce documentLe présent guide applique plusieurs conventions de présentation pour les actionset les termes spéciaux, pour les commandes et chemins propres à chaque systèmed’exploitation et pour les graphiques.

Conventions utilisées dans ce guideLes conventions suivantes sont utilisées dans ce guide :

Gras Les commandes, mots clés, noms de fichiers, rôles d’autorisation,adresses URL ou autres informations à utiliser littéralementapparaissent en caractères gras.

Italique Les variables, les options et les valeurs que vous devez indiquerapparaissent 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èmeapparaissent dans la police de caractères monospace.

xvi IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 19: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Avis aux lecteurs canadiens

Le présent document a été traduit en France. Voici les principales différences etparticularités dont vous devez tenir compte.

Illustrations

Les illustrations sont fournies à titre d’exemple. Certaines peuvent contenir desdonnées propres à la France.

Terminologie

La terminologie des titres IBM peut différer d’un pays à l’autre. Reportez-vous autableau 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, etle 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.

© Copyright IBM Corp. 1999, 2002 xvii

Page 20: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Nomenclature

Les touches présentées dans le tableau d’équivalence suivant sont libelléesdifféremment selon qu’il s’agit du clavier de la France, du clavier du Canada oudu clavier des États-Unis. Reportez-vous à ce tableau pour faire correspondre lestouches 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 debrevets portant sur certains sujets abordés dans ce document. Le fait qu’IBM vousfournisse le présent document ne signifie pas qu’elle vous accorde un permisd’utilisation de ces brevets. Vous pouvez envoyer, par écrit, vos demandes derenseignements relatives aux permis d’utilisation au directeur général des relationscommerciales 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, deslogiciels et des publications IBM, contactez IBM direct au 1 800 465-1234.

xviii IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 21: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Chapitre 1. Généralités sur IBM Tivoli Access ManagerWebSEAL

IBMTivoliAccess Manager for e-business (Access Manager) constitue une solutionrobuste et sécurisée de gestion centralisée des règles applicables au commerceélectronique et aux applications distribuées. IBM Tivoli Access Manager WebSEALest 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 Managersous sa protection. WebSEAL peut fournir des solutions à connexion unique etintégrer des ressources du serveur d’application Web d’arrière-plan dans ses règlesde sécurité.

Le présent chapitre vous présente les principales fonctionnalités du serveurWebSEAL.

Index des rubriques :v «Introduction à IBM Tivoli Access Manager et à WebSEAL» à la page 1v «Présentation du modèle de sécurité d’Access Manager» à la page 3v «Protection de l’espace Web grâce à WebSEAL» à la page 7v «Planification et mise en oeuvre des règles de sécurité» à la page 8v «Explication de l’authentification WebSEAL» à la page 10v «Explication des jonctions WebSEAL» à la page 14

Introduction à IBM Tivoli Access Manager et à WebSEALIBM Tivoli Access Manager :

IBM Tivoli Access Manager constitue une solution complète de gestion des règlesde sécurité réseau et d’autorisation, qui fournit une protection inégalée desressources sur des intranets et des extranets géographiquement dispersés.

Outre ses fonctions avancées de gestion des règles de sécurité, Access Managercontient des fonctions d’authentification, d’autorisation, de sécurité des données etde gestion centralisée des ressources. Vous pouvez utiliser Access Manager enassociation avec des applications Internet standard afin de créer des intranetspré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 etprend en charge des outils externes d’authentification.

v Structure d’autorisationLe service d’autorisation d’Access Manager (auquel vous pouvez accéder vial’API d’autorisation d’Access Manager) vous permet de prendre des décisionsd’autorisation ou de refus de requêtes relatives à des ressources protégéessituées dans le domaine sécurisé.

© Copyright IBM Corp. 1999, 2002 1

Page 22: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Grâce à Access Manager, il devient possible de gérer en toute sécurité l’accès auxressources de réseaux internes privés tout en bénéficiant des capacités deconnectivité et de facilité d’utilisation d’Internet. Access Manager, en associationavec un dispositif pare-feu, peut apporter une protection totale de l’intranetd’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 deprotection de ressources pour les ressources et les informations basées sur le Web.

WebSEAL est un serveur Web à hautes performances et à plusieurs unitésd’exécution, appliquant des règles de sécurité renforcées à l’espace objet WebAccess Manager sous sa protection. Il peut fournir des solutions à connexionunique et intégrer des ressources du serveur d’applications Web d’arrière-plandans ses règles de sécurité.

WebSEAL fonctionne normalement en tant que proxy Web inversé via la réceptionde requêtes HTTP/HTTPS en provenance d’un navigateur Web et la livraison ducontenu de son propre serveur Web ou de serveurs d’applications Web reliés auréseau par jonction. Les requêtes acheminées par WebSEAL sont évaluées par leservice d’autorisation d’Access Manager afin de déterminer si l’utilisateur estautorisé à accéder à la ressource demandée.

WebSEAL comporte un certain nombre de fonctionnalités :v Prise en charge de plusieurs méthodes d’authentification

Les architectures, tant intégrées que complétées par des modules, autorisent unecertaine souplesse, dans la mesure où elles acceptent toute une variété deméthodes d’authentification.

v Prise en charge des requêtes HTTP et HTTPSv Intégration et protection des ressources du serveur d’arrière-plan grâce à la

technologie de jonction WebSEALv Gestion d’un contrôle d’accès renforcé pour l’espace Web du serveur local et

d’arrière-planSont notamment prises en charge les ressources suivantes : URL, expressionsrégulières basées sur une adresse URL, programmes CGI, fichiers HTML,servlets Java et fichiers de classe Java.

v Fonctionnement en tant que proxy Web inverséWebSEAL apparaît comme un serveur Web pour les clients et comme unnavigateur 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

Page 23: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Présentation du modèle de sécurité d’Access ManagerLa stratégie de sécurité d’un domaine sécurisé Access Manager s’articule autour dedeux structures clés de sécurité :v Registre d’utilisateurs

Le registre d’utilisateurs (tel que LDAP, Lotus Domino ou Microsoft ActiveDirectory) contient tous les utilisateurs et tous les groupes autorisés à participerau 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 detoutes les ressources du domaine (l’espace objets protégé). L’administrateur desécurité peut spécifier un niveau de sécurité grâce à l’application de règlesappelées liste de contrôle d’accès (ACL) de règles simples et de règles d’objetprotégées (POP) aux ressources qui nécessitent une protection.

L’identité d’un utilisateur est vérifiée dans WebSEAL grâce au processusd’authentification. Un utilisateur peut participer au domaine sécurisé en tantqu’utilisateur authentifié ou non authentifié. Seuls les utilisateurs possédant uneentrée dans le registre d’utilisateurs peuvent être authentifiés. A l’aide des ACL etdes POP, l’administrateur de sécurité peut rendre certaines ressources publiquesdisponibles pour des utilisateurs non authentifiés. En revanche, d’autres ressourcesne peuvent être disponibles que pour certains utilisateurs authentifiés.

Lorsqu’un utilisateur est authentifié pour WebSEAL, des droits d’accès sont crééspour 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é encomparant les droits d’accès d’un utilisateur avec les autorisations affectées à laressource demandée. La recommandation qui en résulte est transmise augestionnaire des ressources (WebSEAL, par exemple), qui élabore la réponse à larequête d’origine. Les droits d’accès des utilisateurs sont essentiels pour leurparticipation complète au domaine sécurisé.

Client WebSEAL

� 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

Authentification

Serveurd’applications

Web

/

Espace objetWeb sécurisé

jonction WebSEAL

Figure 1. Protection de l’espace Web avec WebSEAL

Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL 3

Page 24: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

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 dansl’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 pard’autres utilitaires de gestion Access Manager.

Vous pouvez attacher des modèles de règles à des objets dans l’espace objets afinde protéger la ressource. Le service d’autorisation prend ses décisionsd’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 URLHTTP. Ils peuvent inclure des pages Web statiques et des adresses URLdynamiques converties en requêtes de base de données ou en tout autre typed’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 viaWeb Portal Manager. Les objets représentent les tâches nécessaires à la définitiondes utilisateurs et des règles de sécurité. Access Manager prend en charge ladé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éseauprotégées par des applications à l’aide du service d’autorisation, via l’APId’autorisation d’Access Manager.

Figure 2. Espace objets protégé Access Manager

4 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 25: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Définition et application de règles de LCA et POPLes responsables de la sécurité protègent les ressources système Access Managergrâce à la définition de règles (appelées règles de LCA et POP) et à l’application deces règles aux représentations d’objets de ces ressources dans l’espace objetsprotégé.

Le service d’autorisation d’Access Manager prend des décisions d’autorisation surla base des règles appliquées à ces objets. Lorsqu’une opération demandée sur unobjet protégé est autorisée, l’application responsable de la ressource met en placecette 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 estassocié.

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 derègles (autorisations) qui spécifie les conditions nécessaires à l’exécution decertaines opérations sur cette ressource. Les définitions de règles de LCA sont descomposants 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 lesconditions requises d’une entreprise en matière de sécurité sur les ressourcesrepré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 ressource2. personne pouvant effectuer cette opération

Les règles de LCA sont composées d’une ou de plusieurs entrées qui incluent desdésignations d’utilisateur et de groupe ainsi que leurs autorisations ou droitsspécifiques. Une LCA peut également contenir des règles qui s’appliquent à desutilisateurs non authentifiés.

Règles d’objet protégé (POP)Les règles de LCA fournissent au service d’autorisation des informationspermettant 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êtequi 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

Figure 3. règle de LCA

Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL 5

Page 26: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

du service d’autorisation. Il incombe à Access Manager et au gestionnaire deressources de mettre en oeuvre les conditions POP.

Les tableaux suivants dressent la liste des attributs disponibles pour une règlePOP :

Mise en oeuvre effectuée par Access Manager Base

Attribut POP Description

Nom Nom de la règle. Il se transforme en <nom_pop> dans lescommandes pdadmin pop.

Description Texte descriptif de la règle. Il apparaît dans la commandepop show.

Mode d’avertissement Fournit aux administrateurs un moyen de tester lesrègles de LCA et POP.

Niveau d’audit Spécifie le type d’audit : tout, aucun, accès abouti, accèsrefusé, 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éthoded’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éeUne 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 etPOP. Il s’agit là d’un aspect important pour le responsable de la sécurité qui gèrel’espace objets. En effet, il ne doit appliquer de règles explicites qu’à certains pointsde 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

Page 27: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Gestion des règles : Web Portal ManagerWeb Portal Manager est une application graphique Web utilisée pour la gestion desrègles de sécurité au sein d’un domaine sécurisé Access Manager. L’utilitaire deligne de commande pdadmin contient les mêmes capacités d’administration queWeb Portal Manager, plus certaines commandes non prises en charge par WebPortal Manager.

A partir de Web Portal Manager (ou de pdadmin), vous pouvez gérer le registred’utilisateurs, la base de données de règles d’autorisation principale et les serveursAccess Manager. Vous pouvez également ajouter et supprimer des utilisateurs/desgroupes et appliquer des règles de LCA et POP aux objets réseau.

Protection de l’espace Web grâce à WebSEALLorsque WebSEAL met en place la sécurité au sein d’un domaine sécurisé, chaqueclient 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 surune ressource demandée. Puisque l’accès à chaque ressource Web d’un domainesécurisé est contrôlé par WebSEAL, le fait que WebSEAL requiert uneauthentification et une autorisation peut fournir une sécurité du réseau trèscomplè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 droitd’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 aucuneindication sur les droits du client à effectuer certaines opérations sur une ressourceprotégée.

Dans le modèle d’autorisation d’Access Manager, les règles d’autorisation sontmises en oeuvre indépendamment de la méthode utilisée pour l’authentificationdes 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èsqui décrit l’identité du client. Les décisions d’autorisation prises par un serviced’autorisation prennent comme base les droits d’accès des utilisateurs.

Les ressources d’un domaine sécurisé reçoivent un niveau de protection quidépend de la stratégie de sécurité du domaine. La stratégie de sécurité définit lesparticipants autorisés au sein du domaine sécurisé et le niveau de protection dechaque 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 ungestionnaire de ressources.L’un des composants du gestionnaire de ressources est l’outil de mise en oeuvrede 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 derègles et le gestionnaire de ressources au sein d’un même processus.Des exemples de cette structure incluent WebSEAL et desapplications de fabricants tiers.

Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL 7

Page 28: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

v Un service d’autorisation est chargé de l’action de prise de décision à propos dela requête.

Le diagramme suivant illustre le processus d’autorisation complet :

1. Une requête de client authentifiée pour une ressource est acheminée vers legestionnaire de ressources et interceptée par le processus de mise en oeuvre derè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’AccessManager pour appeler le service d’autorisation afin de prendre une décisiond’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 POPde 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 enoeuvre 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 deressources sous forme d’une recommandation (via l’outil de mise en oeuvre derè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 protection2. Le niveau de protection

Figure 5. Processus d’autorisation Access Manager

8 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 29: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Access Manager utilise une représentation virtuelle de ces ressources Web, appeléel’espace objet protégé. Ce dernier contient des objets qui représentent les ressourcesphysiques réelles de votre réseau.

Vous mettez en oeuvre les règles de sécurité en appliquant les mécanismes desé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 voiraccorder 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émentairesd’accès à l’objet protégé, par exemple la confidentialité, l’intégrité, l’audit etl’accès en temps réel.

v Attributs étendusLes attributs étendus sont des valeurs supplémentaires placées sur un objet, uneLCA ou un POP, qui peuvent être lues et interprétées par des applicationsprovenant de tiers (comme un service d’autorisation externe).

Le composant central d’Access Manager est le service d’autorisation — qui accordeou refuse l’accès aux objets protégés (ressources) sur la base des donnéesd’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 defaç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) etappliquer les stratégies de LCA et de POP appropriées. La gestion du contrôled’accès peut se révéler une tâche extrêmement complexe et est grandement facilitéepar une catégorisation soignée des types de contenu.

Identification des types de contenu et des niveaux deprotection

En tant qu’administrateur de sécurité de votre espace Web, vous devez identifierde façon correcte les types de contenu disponibles pour les divers typesd’utilisateurs. Si certains contenus doivent être hautement protégés et n’être placésqu’à la disposition de certains utilisateurs spécifiques, d’autres contenus sontdestinés à l’ensemble du public. Chaque scénario de sécurité répond donc àdiverses exigences sécuritaires et exige donc une configuration WebSEALparticulière.

Il vous incombe de :v Connaître votre contenu Webv Identifier les types d’utilisateurs devant accéder à ce contenuv 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égoriessuivantes :1. Contenu public – l’accès ne requiert aucune protectionv Accès des clients non authentifiés via HTTP

Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL 9

Page 30: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

v Données d’autorisation non authentifiées utilisées pour le contrôle d’accèsaux ressources

v Configuration WebSEAL basique requise2. Contenu public – l’accès requiert une certaine confidentialité (chiffrement)v Accès des clients non authentifiés via HTTPSv 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 lesinformations de compte utilisateur)

v Données d’autorisation non authentifiées utilisées pour le contrôle d’accèsaux ressources

v La configuration WebSEAL doit stipuler la confidentialité3. Contenu privé – authentification obligatoire pour l’accèsv Accès des clients authentifiés via HTTP ou HTTPSv L’administrateur détermine si le chiffrement est nécessaire ou nonv 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 registred’utilisateurs

v La configuration WebSEAL est complexe et toutes les options doivent êtreenvisagées avec attention pour que l’impact des règles de sécurité puisse êtredéterminé

Explication de l’authentification WebSEALL’authentification est la méthode qui permet d’identifier un processus ou uneentité individuel essayant de se connecter à un domaine sécurisé. Lorsque leserveur et le client exigent tous les deux une authentification, l’échange porte lenom d’authentification réciproque.

WebSEAL peut apporter un niveau élevé de sécurité dans un domaine sécurisé endemandant à 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éthodesd’authentification.

v Le processus serveur WebSEAL est indépendant de la méthoded’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)

Client WebSEAL

Qui êtes-vous ?

Qui êtes-vous ?

Figure 6. Authentification réciproque

10 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 31: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

pouvant être utilisées par le service d’autorisation d’Access Manager pouraccorder 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’authentificationBien que WebSEAL soit indépendant du processus d’authentification, il a besoin deses résultats : l’identité du client. Le processus d’authentification se décomposecomme suit1. 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 comptedéfini dans le registre d’utilisateurs Access Manager ou s’il est traité avecsuccè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 depasse, 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éeavec le serveur.

2. WebSEAL se sert de l’identité pour acquérir des données d’autorisation pource client.WebSEAL fait correspondre l’identité du client avec un utilisateur AccessManager 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’unutilisateur sur le domaine sécurisé, décrivent l’utilisateur dans un contextespécifique et ne sont valides que pour la durée de la session. Ces droits d’accèsse composent de l’identité de l’utilisateur, des membres du groupe et de tousles 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 quirégissent les utilisateurs non authentifiés.Ces données d’autorisation sont à la disposition du service d’autorisation, quiaccorde ou refuse l’accès aux objets demandés dans l’espace objet protégé parWebSEAL.

Les données d’autorisation peuvent être utilisées par tout service Access Managerdemandant des informations sur le client. Elles permettent à Access Managerd’exécuter en toute sécurité une multitude de services, comme une autorisation, unaudit et une délégation.

Access Manager opère la distinction entre l’authentification de l’utilisateur etl’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 auxquelsse rattache un utilisateur, varient. Les données d’autorisation, spécifiques d’uncontexte, peuvent changer dans le temps. Par exemple, à la promotion d’unepersonne, les données d’autorisation doivent refléter le nouveau niveau deresponsabilité.

Pour plus d’informations sur la prise en charge de méthodes d’authentificationspécifiques, reportez-vous au Chapitre 5, «Authentification WebSEAL» à lapage 111.

Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL 11

Page 32: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Accès authentifié et non authentifié aux ressourcesAu sein de l’environnement de domaine sécurisé d’Access Manager, l’identité d’unutilisateur est vérifiée dans WebSEAL grâce au processus d’authentification. Enrègle générale, un utilisateur peut participer au domaine sécurisé en tantqu’utilisateur authentifié ou non authentifié.

Dans les deux cas, le service d’autorisation d’Access Manager nécessite l’utilisationdes droits d’accès des utilisateurs pour prendre des décisions d’autorisation pourles requêtes relatives à des ressources du domaine sécurisé.WebSEAL gèredifféremment les droits d’accès des utilisateurs selon qu’ils sont authentifiés ounon.

Les droits d’accès d’un utilisateur non authentifié représentent uniquement unpasseport générique qui permet à l’utilisateur de participer au domaine sécurisé etd’accéder aux ressources disponibles pour les utilisateurs non authentifiés.

Les droits d’accès d’un utilisateur authentifié représentent un passeportpersonnalisé qui décrit un utilisateur spécifique appartenant au registred’utilisateurs d’Access Manager (ou traité avec succès via un CDAS). Les droitsd’accès d’un utilisateur authentifié se composent de l’identité de l’utilisateur, desmembres 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 del’utilisateur. WebSEAL demande à l’utilisateur de se connecter.

v L’authentification ne peut aboutir que si l’utilisateur est membre du registred’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 informationsrelatives aux droits d’accès.

v Lors de chaque vérification d’autorisation, le service d’autorisation d’AccessManager utilise les informations relatives aux droits d’accès pendant leprocessus de prise de décision.

v Lorsque l’utilisateur se déconnecte, l’entrée mise en cache pour cet utilisateur estsupprimé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 del’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

Page 33: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

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 nonauthentifiés.

Structure de la mémoire cache des sessions/des droitsd’accès WebSEAL

La mémoire cache des sessions WebSEAL est également appelée mémoire cachedes droits d’accès WebSEAL. La mémoire cache peut être représentée sous formede table interne dans laquelle WebSEAL stocke les informations sur toutes lessessions établies par les utilisateurs authentifiés.

Chaque session utilisateur est représentée par une entrée dans la table de lamé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êtede cet utilisateur. L’ID de session identifie l’entrée spécifique de mémoire cacheassocié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émoirecache sont les données d’autorisation des utilisateurs. Ces données sontrequises chaque fois que l’utilisateur effectue une demande relative auxressources protégées. Le service d’autorisation utilise ces informations pourautoriser ou refuser l’accès à la ressource.WebSEAL peut signaler au moyen d’un “indicateur” une entrée de mémoirecache prenant en charge une fonction spécifique. Par exemple, lorsque lafonction 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 lavaleur 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 deréférence associé à la valeur de durée de session. L’horodateur “Fin du délaid’inactivité” de l’entrée de mémoire cache devient le point de référence du délaid’inactivité.

Les données d’autorisation des utilisateurs contiennent les éléments suivants :v Nom d’utilisateur

Figure 7. Mémoire cache des sessions/des droits d’accès WebSEAL

Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL 13

Page 34: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

v Membres du groupev Attributs étendus

Les attributs étendus permettent de stocker des données personnalisées dans lesdonnées d’autorisation des utilisateurs. Il s’agit par exemple de l’attribut étendude données d’autorisation tagvalue_user_session_id. La valeur de cet attributpeut être insérée dans un en-tête HTTP afin de permettre le maintien de lasession (établie avec un utilisateur) d’un serveur relié au réseau par unejonction.

Explication des jonctions WebSEALAccess Manager fournit des services d’authentification, d’autorisation et de gestionpour un réseau. Dans un réseau basé sur le Web, ces services sont fournis de façonoptimale par un ou plusieurs serveurs WebSEAL frontaux qui intègrent etprotègent les ressources et les applications Web se trouvant sur des serveursd’arrière-plan.

La liaison entre un serveur WebSEAL et un serveur d’applications Webd’arrière-plan est appelée jonction, ou jonction WebSEAL. Une jonction WebSEALest une connexion TCP/IP entre un serveur WebSEAL frontal et un serveurd’arrière-plan.

Le serveur d’arrière-plan est un autre serveur WebSEAL ou, plus souvent, unserveur 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.

Une jonction permet à WebSEAL d’assurer des services de protection pour lecompte du serveur d’arrière-plan. WebSEAL peut exécuter des contrôlesd’authentification et d’autorisation sur toutes les requêtes avant de transmettrecelles-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écrirel’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 descapacité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 tantqu’administrateur, vous pouvez tirer profit de cette gestion centralisée de l’espaceWeb.

ClientServeur

d'applicationsWeb

Jonction

TCP ou SSL

WebSEAL/

/mnt

Domaine sécurisé

Figure 8. Connexion par jonctions de WebSEAL avec des serveurs d’arrière-plan

14 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 35: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Les jonctions WebSEAL apportent la valeur ajoutée d’une combinaison logique del’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 espaceWeb unique, unifié et distribué qui fonctionne en douceur et en transparence pourles utilisateurs.

Le client n’a jamais besoin de connaître l’emplacement physique d’une ressourceWeb. WebSEAL convertit les adresses URL logiques dans les adresses physiquesattendues par le serveur d’arrière-plan. Les objets Web peuvent être déplacés d’unserveur à 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 toutesles ressources. Les autres avantages administratifs incluent l’évolutivité,l’équilibrage de charge et la haute disponibilité.

La plupart des serveurs Web du commerce ne sont pas à même de définir unespace objet Web logique. Leur contrôle d’accès est connecté à la structure derépertoires et de fichiers physiques. Les jonctions WebSEAL peuvent définir defaçon transparente un espace objet qui reflète la structure organisationnelle plutôtque la machine physique et la structure des répertoires que l’on trouvegé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 utilisateurd’accéder à une ressource, quel que soit l’emplacement de cette dernière,

/

Espace Web WebSEAL

Espace Web combiné :WebSEAL plus serveur relié par jonction

/point de jonction

Figure 9. La jonction WebSEAL aboutit à un espace Web unifié

Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL 15

Page 36: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

uniquement à partir de la connexion initiale. Toute autre exigence de connexionprovenant des serveurs d’arrière-plan est traitée de façon transparente pourl’utilisateur.

Les jonctions WebSEAL constituent un outil important d’évolutivité de votre siteWeb. Elles vous permettent de répondre à des demandes en augmentation sur unsite Web, en rattachant des serveurs supplémentaires.

Jonctions WebSEAL et évolutivité de site WebLes jonctions WebSEAL servent à créer un site Web évolutif. Au fur et à mesureque les demandes augmentent au niveau du site Web, il est plus facile d’ajouterd’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 contenuv 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ésLa prise en charge de la jonction pour les serveurs d’arrière-plan commence avecau moins un serveur frontal WebSEAL. Les serveurs frontaux WebSEAL répliquésdotent 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 IBMNetwork Dispatcher ou Cisco Local Director.

La réplication frontale dote également le site d’une fonction de secours (si leserveur tombe en panne pour une raison ou une autre, les autres serveurs deréplique continuent à fournir l’accès au site). Un bon équilibrage de chargecombiné à une capacité de fonction de secours aboutissent à une hautedisponibilité pour les utilisateurs du site.

Lorsque vous répliquez des serveurs frontaux WebSEAL, chaque serveur doitcontenir une copie exacte de l’espace Web et de la base de données de jonction.

Client SSL Client SSL

Serveur WebSEALprincipal

Internet

Répliquedu serveur WebSEAL

Mécanismed’équilibrage de charge

Figure 10. Serveurs WebSEAL frontaux répliqués

16 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 37: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Les informations de compte pour l’authentification se trouvent dans un registred’utilisateurs indépendant des serveurs frontaux.

Prise en charge des applications serveur d’arrière-planLe contenu d’un site Web peut être pris en charge par le serveur WebSEALlui-même et/ou par des serveurs d’arrière-plan. Le support de la jonctionWebSEAL par les serveurs d’arrière-plan vous permet de faire évoluer le site Weben y ajoutant du contenu et des ressources.

Chaque serveur d’arrière-plan unique doit être relié au réseau au niveau d’unpoint de jonction séparé (montage). Au fur et à mesure que la demande d’uncontenu 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éseauxdont l’investissement existant dans des serveurs Web tiers est déjà lourd.

Le graphique suivant illustre la façon dont les jonctions fournissent un espace objetunifié et logique. Transparent pour l’utilisateur, cet espace Web permet une gestioncentralisée.

Client SSL

Serveur WebSEALprincipal

Internet

Répliquedu serveur WebSEAL

Serveur tiers/engineering

Client SSL

Serveur tiers/sales

Mécanisme d’équilibragede charge

Figure 11. Connexion par jonctions de WebSEAL avec des serveurs d’arrière-plan

Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL 17

Page 38: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Les serveurs d’arrière-plan répliqués sont reliés au réseau par une jonction aumême point de jonction, comme expliqué à la section suivante.

Serveurs d’arrière-plan répliquésPour étendre les fonctions d’évolutivité à une configuration avec des serveursd’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-planrépliqués doivent contenir des espaces Web qui constituent le reflet les uns desautres.

WebSEAL effectue un équilibrage de charge entre les serveurs répliqués à l’aided’un algorithme d’ordonnancement déterminant le serveur le “moins occupé”. Cetalgorithme dirige chaque nouvelle requête vers le serveur comportant le nombrede connexions en cours le plus faible.

WebSEAL déclenche également correctement la fonction de secours lorsqu’unserveur 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 plusieurspages, des jonctions avec conservation de l’état peuvent être utilisées pour garantirque chaque session renvoie au même serveur d’arrière-plan.

Arborescence de l’objet Web

/Jonction Engineering Jonction Sales

Figure 12. Espace Web unifié

18 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 39: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Client SSL

Serveur WebSEALprincipal

Internet

Répliquedu serveur WebSEAL

Client SSL

Répliquesdu serveur Engineering

Répliquesdu serveur Sales

Serveursrépliquésfrontaux

Mécanisme d’équilibragede charge

Figure 13. Serveurs d’arrrière-plan répliqués

Chapitre 1. Généralités sur IBM Tivoli Access Manager WebSEAL 19

Page 40: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

20 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 41: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Chapitre 2. Configuration de base du serveur

Ce chapitre contient des informations sur les tâches génériques d’administration etde configuration à exécuter pour personnaliser le serveur WebSEAL en fonction devotre réseau.

Index des rubriques :v «Informations générales sur le serveur» à la page 21v «Utilisation du fichier de configuration WebSEAL» à la page 23v «Configuration des paramètres de communication» à la page 26v «Gestion de l’espace Web» à la page 28v «Gestion des pages personnalisées de messages d’erreur HTTP» à la page 34v «Gestion des pages personnalisées de gestion de comptes» à la page 37v «Gestion des certificats côté client et côté serveur» à la page 39v «Configuration de la journalisation HTTP par défaut» à la page 44v «Configuration de la journalisation HTTP par défaut» à la page 47v «Consignation des messages de mise en service WebSEAL» à la page 48

Informations générales sur le serveurLes sections ci-après contiennent des informations génériques sur le serveurWebSEAL :v «Répertoire racine de l’installation WebSEAL» à la page 21v «Démarrage et arrêt de WebSEAL» à la page 22v «WebSEAL représenté dans l’espace objets protégé» à la page 22v «WebSEAL renvoie HTTP/1.1» à la page 22v «Fichier journal WebSEAL» à la page 23

Répertoire racine de l’installation WebSEALLes fichiers programme de WebSEAL sont installés dans le répertoire racinesuivant :

UNIX :/opt/pdweb/

Windows :C:\Program Files\Tivoli\PDWeb\

Vous pouvez configurer ce chemin dans une installation Access Manager pourWindows. En revanche, vous ne pouvez pas le configurer dans les installationsAccess Manager sous UNIX.

Dans le présent document, la variable <chemin_installation> représente ce répertoireracine.

Sur les installations UNIX, le répertoire suivant contient des fichiers extensibles telsque des fichiers journaux et des fichiers d’audit :/var/pdweb/

© Copyright IBM Corp. 1999, 2002 21

Page 42: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Démarrage et arrêt de WebSEALPour démarrer et arrêter le processus du serveur WebSEAL, vous pouvez utiliser lacommande pdweb sous UNIX et le panneau de configuration des services sousWindows.

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 desservices 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écifiele point au sein de l’espace objets protégé qui représente cette instance de serveurWebSEAL.

Pour les installations WebSEAL à serveur unique, cette valeur est automatiquementdéfinie à l’aide du nom de la machine sur laquelle ce serveur WebSEAL estinstallé.

Par exemple, si le nom de la machine (l’hôte) est sales1, la valeur affectée à ceparamètre est la suivante :[server]server-name = sales1

La représentation de cette instance de serveur WebSEAL dans l’espace objetsproté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 multiplesWebSEAL.

Voir aussi la section «Configuration de plusieurs instances de serveur WebSEAL» àla page 58.

WebSEAL renvoie HTTP/1.1Les requêtes HTTP/1.0 sont uniquement envoyées aux serveurs reliés au réseaupar 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.0dans la requête.

22 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 43: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Dans les autres cas, si le serveur d’arrière-plan accepte HTTP/1.1, WebSEALenvoie 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 renvoietoujours une réponse HTTP/1.1 au navigateur du client.

Fichier journal WebSEALLe 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 etl’emplacement du fichier journal sont définis par le paramètre server-log qui setrouve 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 WebSEALLes sections suivantes contiennent des informations sur le fichier de configurationWebSEAL (webseald.conf) :v «Présentation du fichier de configuration webseald.conf» à la page 23v «Répertoire racine du serveur WebSEAL» à la page 25

Présentation du fichier de configuration webseald.confVous pouvez personnaliser le fonctionnement de WebSEAL en configurant lesparamètres qui se trouvent dans le fichier de configuration webseald.conf. Cefichier 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 etpeuvent être modifiés à l’aide d’un éditeur de texte classique. Les fichiers deconfiguration 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 dela plupart des paramètres. Certains paramètres sont statiques et ne changentjamais. D’autres en revanche peuvent être modifiés pour personnaliser lesfonctionnalités et les performances d’un serveur.

Chapitre 2. Configuration de base du serveur 23

Page 44: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Chaque fichier contient des sections, également appelées strophes, qui incluent unou plusieurs paramètres pour une catégorie de configuration spécifique. Les titresde strophes apparaissent entre crochets :[nom_strophe]

Par exemple, la strophe [junction] du fichier de configuration webseald.confdéfinit les paramètres de configuration qui affectent les jonctions WebSEAL. Lastrophe [authentication-mechanisms] définit les méthodes d’authentification prisesen charge par WebSEAL, ainsi que les fichiers de bibliothèque partagée associés.

Les fichiers de configuration contiennent des commentaires qui expliquentl’utilisation de chaque paramètre. Le caractère “#” est utilisé pour désigner uneligne de commentaires. Toutes les lignes de commentaires commencent par lecaractère “#”. Par conséquent, le caractère “#” ne peut pas être utilisé commevaleur de paramètre.

Remarque : Chaque fois que vous modifiez le fichier webseald.conf, vous devezredé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 configurationwebseald.conf :

Sections Strophes

WEBSEAL GENERAL [server]

LDAP [ldap]

ACTIVE DIRECTORY [uraf-ad]

DOMINO [uraf-domino]

SSL [ssl]

JONCTION [junction][filter-url][filter-schemes][filter-content-types][script-filtering][gso-cache][ltpa-cache]

24 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 45: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Sections Strophes

AUTHENTIFICATION [ba][forms][token][certificate][http-headers][auth-headers][ipaddr][authentication-levels][mpa][cdsso][cdsso-peers][failover][e-community-sso][inter-domain-keys][reauthentication][authentication-mechanisms][ssl-qop][ssl-qop-mgmt-hosts][ssl-qop-mgmt-networks][ssl-qop-mgmt-default]

SESSION [session]

CONTENU [content][acnt-mgt][cgi][cgi-types][cgi-environment-variable][content-index-icons][icons][content-cache][content-mime-types][content-encodings]

CONNEXION [logging]

API D’AUTORISATION [aznapi-configuration][aznapi-entitlement-services]

POLICY DIRECTOR [policy-director]

Voir l’Annexe A, «Références du fichier webseald.conf» à la page 239.

Répertoire racine du serveur WebSEALLe paramètre server-root situé dans le fichier de configuration webseald.confdéfinit l’emplacement du serveur WebSEAL pour d’autres paramètres inclus dansce fichier.Tous les chemins relatifs définis dans les fichiers de configurationwebseald.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

Page 46: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Configuration des paramètres de communicationLes sections ci-après contiennent des informations génériques sur le serveurWebSEAL :v «Configuration de WebSEAL pour les requêtes HTTP» à la page 26v «Configuration de WebSEAL pour les requêtes HTTPS» à la page 26v «Restriction des connexions à partir de versions SSL spécifiques» à la page 27v «Paramètres de délai d’expiration pour les communications HTTP/HTTPS» à la

page 27v «Autres paramètres de délai d’expiration du serveur WebSEAL» à la page 28

Configuration de WebSEAL pour les requêtes HTTPWebSEAL gère généralement de nombreuses requêtes HTTP émanant d’utilisateursnon authentifiés. Par exemple, il est fréquent que des utilisateurs anonymesdétiennent un accès en lecture seule à des documents sélectionnés dans la sectionpublique de votre site Web.

Les paramètres de gestion des requêtes HTTP via le protocole TCP se trouventdans la strophe [server] du fichier de configuration webseald.conf.

Activation/Désactivation de l’accès HTTPActivez 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 HTTPLe 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 HTTPSLes paramètres de gestion des requêtes HTTP via SSL (HTTPS) se trouvent dans lastrophe [server] du fichier de configuration webseald.conf.

Activation/Désactivation de l’accès HTTPSActivez 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 HTTPSLe 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

Page 47: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Restriction des connexions à partir de versions SSLspé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 pourdes versions SSL et TLS spécifiques sont situés dans la strophe [ssl] du fichier deconfiguration webseald.conf. Par défaut, toutes les versions SSL et TLS sontactivées.[ssl]disable-ssl-v2 = nodisable-ssl-v3 = nodisable-tls-v1 = no

Paramètres de délai d’expiration pour les communicationsHTTP/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 laliaison initiale et gère l’état de la session.

WebSEAL prend en charge les paramètres de délai d’expiration suivants pour lescommunications 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 lequelWebSEAL conserve la connexion pour la requête initiale HTTP ou HTTPS. Lavaleur 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ôlele nombre maximal de secondes pendant lequel WebSEAL conserve uneconnexion HTTP permanente avant son arrêt. La valeur par défaut est5 secondes.[server]persistent-con-timeout = 5

Connexion

Client WebSEAL

SSL Handshake

Requête http

Réponse

Requête http

Contrôlé par GSKit

(HTTP/1.1 uniquement)

client-connect-timeout

persistent-con-timeout

Figure 14. Paramètres de délai d’expiration pour les communications HTTP et HTTPS

Chapitre 2. Configuration de base du serveur 27

Page 48: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Autres paramètres de délai d’expiration du serveur WebSEALLes autres paramètres de délai d’expiration ci-après sont définis dans le fichier deconfiguration webseald.conf :

Paramètre Description Valeurpar défaut(secondes)

[junction]http-timeout

Valeur de dépassement du délaipour l’envoi vers/la lecture sur unserveur d’arrière-plan via unejonction TCP.

120

[junction]https-timeout

Valeur de dépassement du délaipour l’envoi vers/la lecture sur unserveur d’arrière-plan via unejonction SSL.

120

[cgi]cgi-timeout

Valeur de dépassement du délaipour l’envoi vers/la lecture sur unprocessus CFI local.

120

[junction]ping-time

WebSEAL effectue un pingpériodique en arrière-plan surchaque serveur relié par jonctionpour déterminer s’il fonctionne. Sestentatives ne se produisent pas à unrythme plus fréquent que toutes les300 secondes (ou quelle que soit lavaleur définie).

300

Gestion de l’espace WebLes 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 28v «Configuration de l’indexation de répertoires» à la page 29v «Windows : conventions de dénomination de fichiers pour les programmes

CGI» à la page 30v «Configuration de la mémoire cache d’un document Web» à la page 31v «Spécification de types de documents à filtrer» à la page 34

Répertoire racine de l’arborescence des documents WebL’emplacement de l’arborescence des documents Web est le chemin absolu à laracine de l’arborescence des document rendus disponibles par WebSEAL. Le nomde ce chemin est représenté par le paramètre doc-root de la strophe [content] dufichier de configuration webseald.conf. L’emplacement par défaut est définiinitialement 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

Page 49: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Cette valeur n’est utilisée qu’une fois : lors du premier démarrage de WebSEALaprès l’installation. Elle est ensuite enregistrée dans la base de données desjonctions. Toute modification ultérieure de cette valeur dans webseald.conf restesans 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 modifierla 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 :

# pdadminpdadmin> loginEntrer ID utilisateur : sec_masterEntrer mot de passe :pdadmin>

2. Servez-vous de la commande server task list pour afficher tous les points dejonction en cours :pdadmin> server task webseald-websealA list/

3. Servez-vous de la commande server task show pour afficher les détails de lajonction :pdadmin> server task webseald-websealA show /Junction point: /Type: LocalLimite matérielle de la jonction : 0 - avec une valeur globaleLimite logicielle de la jonction : 0 - avec une valeur globaleUnités d’agent actives : 0Ré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 uneautre) :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: LocalLimite matérielle de la jonction : 0 - avec une valeur globaleLimite logicielle de la jonction : 0 - avec une valeur globaleUnités d’agent actives : 0Répertoire racine : /tmp/docs

Configuration de l’indexation de répertoiresVous pouvez spécifier le nom du fichier par défaut renvoyé par WebSEAL lorsquel’expression URL d’une requête se termine par un nom de répertoire. Si ce fichierpar défaut existe, WebSEAL le renvoie au client. S’il n’existe pas, WebSEAL génèrede 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 lastrophe [content] du fichier de configuration webseald.conf.

Chapitre 2. Configuration de base du serveur 29

Page 50: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

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 conventionde 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épertoireindiqué dans la requête ne contient pas le fichier d’index défini par le paramètredirectory-index. L’index généré contient la liste du contenu du répertoire avec lesliens vers chaque entrée du répertoire. L’index est généré uniquement si le clientqui demande l’accès au répertoire dispose du droit d’accès (l) “list” dans la LCAde ce répertoire.

Vous pouvez configurer les icônes graphiques spécifiques utilisées par WebSEALpour chaque fichier répertorié dans un index généré. La strophe[content-index-icons] du fichier de configuration webseald.conf contient la listedes types MIME de document ainsi que les fichiers .gif associés qui s’affichent :[content-index-icons]image/*= /icons/image2.gifvideo/* = /icons/movie.gifaudio/* = /icons/sound2.giftext/html = /icons/generic.giftext/* = /icons/text.gifapplication/x-tar = /icons/tar.gifapplication/* = /icons/binary.gif

Vous pouvez configurer cette liste de façon à définir d’autres icônes pour chaquetype 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 lesprogrammes CGI

Les paramètres contenus dans la strophe [cgi-types] du fichier de configurationwebseald.conf vous permettent de spécifier les types d’extension de fichierWindows 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 denom de fichier. Il faut toutefois définir des types d’extension pour les systèmesd’exploitation Windows. La strophe [cgi-types] répertorie tous les typesd’extension valides et fait correspondre chaque extension (le cas échéant) à unprogramme CGI approprié.

30 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 51: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

[cgi-types]<extension> = <programme_cgi>

Par défaut, seuls les fichiers dont l’extension correspond à l’une de cellesrépertoriées dans la strophe seront exécutés comme des programmes CGI. Si unprogramme CGI est doté d’une extension qui ne figure pas dans la liste, il n’estpas exécuté.

Les fichiers comportant l’extension .exe sont exécutés comme des programmesWindows par défaut et n’exigent aucune mise en correspondance.

Remarque : Cependant, chaque fois que vous voulez installer un fichier .exe sousWindows en vue d’un téléchargement, vous devez renommerl’extension ou installer le fichier comme faisant partie d’une archive(comme .zip).

Vous devez fournir les programmes interpréteur appropriés pour les extensionsrepré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 = cmdcmd = cmdpl = perlsh = shtcl = tclsh76

Remarque : L’utilisation des fichiers .bat et .cmd est sujette à caution. Soyez trèsprudent dans leur utilisation car les questions de sécurité inhérentessont importantes.

Configuration de la mémoire cache d’un document WebIl arrive souvent que les clients soient confrontés à des délais d’accès au réseau etde téléchargement des fichiers à cause de mauvaises performances d’extraction dedocuments Web. Ces faibles performances peuvent être dues au fait que lesdocuments sont extraits de serveurs d’arrière-plan reliés au réseau ou que lestockage local est lent.

La mise en mémoire cache d’un document Web permet la prise en charge dedocuments de façon locale à partir de WebSEAL plutôt qu’à partir d’un serveurd’arrière-plan via une jonction. La fonction de mise en mémoire cache desdocuments Web permet de stocker les types de documents Web auxquels vousaccédez régulièrement dans la mémoire du serveur WebSEAL. Les clientsconnaissent alors des délais de réponse beaucoup plus rapides aux requêtesportant 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 desdocuments de texte statique que des images graphiques. Les documents générés defaçon dynamique, comme les résultats d’une interrogation de base de données, nepeuvent 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 vousconfigurez WebSEAL pour la mise en mémoire cache d’un document Web, vousidentifiez les trois paramètres suivants :v Type de document MIME

Chapitre 2. Configuration de base du serveur 31

Page 52: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

v Type de support de stockagev 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 suivantes’applique :<type_mime> =<type_cache>:<taille_cache>

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èregénérique ( * ). La valeur */* représente une mémoire cache d’objetpar défaut qui contiendra tout objet ne correspondant pas à unemémoire cache configurée de façon explicite.

type_cache Spécifie le type de support de stockage à utiliser pour la mémoirecache. 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, avantsuppression des objets suivant l’algorithme d’ancienneté.

Exemple :text/html = memory:2000image/* = memory:5000*/* = memory:1000

Conditions affectant la mise en mémoire cache de documentsWebLa méthode de mise en mémoire cache de documents Web respecte cesconditions :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 lamémoire cache.

v Une autorisation est toujours exécutée sur toutes les requêtes portant sur desinformations 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êtescontenant des chaînes de requête.

v La méthode de mise en mémoire cache ne contient pas les réponses aux requêtesacheminées via des jonctions configurées à l’aide des options –c et –C.

Vidage de toutes les mémoires cacheVous pouvez vous servir de l’utilitaire pdadmin pour vider toutes les mémoirescache configurées. Cet utilitaire ne permet pas de vider des mémoires cacheindividuelles.

Vous devez vous connecter au domaine sécurisé comme administrateur AccessManager sec_master avant d’utiliser pdadmin.

32 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 53: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Pour vider toutes les mémoires cache des documents Web, entrez la commandesuivante :

UNIX :# pdadmin server taskwebseald-<nom_machine> cacheflush all

Windows :MSDOS> pdadmin server taskwebseald-<nom_machine> cacheflush all

Contrôle de la mise en cache de documents spécifiquesVous pouvez contrôler la mise en mémoire cache de documents spécifiques enassociant une règle POP (Protected Object Policy) aux objets correspondants. Cetterè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 cedocument en mémoire cache. Souvenez-vous que tous les enfants del’objet associé à la règle POP héritent également des conditions decette règle.

public La valeur public autorise WebSEAL à mettre le document en mémoirecache 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 dece document lorsque la requête est envoyée avec un en-têted’autorisation (comme pour l’authentification de base). Cette conditioninclut également une requête via laquelle WebSEAL insère desinformations BA au nom du client (avec GSO ou jonctions –b supply,par exemple). Normalement, les serveurs proxy ne mettent pas enmémoire cache les réponses aux requêtes qui incluent des en-têtesd’autorisation.

Utilisez les commandes pdadmin pop create, pdadmin pop modify et pdadminpop 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 sonassociation à un objet (budget.html ) :pdadmin> pop create doc-cachepdadmin> pop modify doc-cache set attribute document-cache-control no-cachepdadmin> 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 serveurd’arrière-plan sur lequel il réside.

Vous trouverez des informations détaillées sur l’utilitaire de ligne de commandepdadmin dans le document IBM Tivoli Access Manager Base Administrator’s Guide.

Chapitre 2. Configuration de base du serveur 33

Page 54: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Spécification de types de documents à filtrerVous pouvez spécifier les types de contenu de documents que WebSEAL filtre dansles 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 lesvaleurs de type MIME.WebSEAL est configuré par défaut pour filtrer lesdocuments de deux types MIME :[filter-content-types]type = text/htmltype = text/vnd.wap.wml

Les spécifications de type MIME figurant dans cette strophe déterminent le filtragesupplémentaire effectué par WebSEAL pour les réponses en provenance deserveurs 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 URLVoir la section «Règles de filtrage d’adresses URL standard pour WebSEAL» à lapage 175.

v Filtrage des scripts pour les adresses URL absoluesVoir la section «Modification des adresses URL absolues avec filtrage de script»à la page 177.

Gestion des pages personnalisées de messages d’erreur HTTPIl 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 aunavigateur, comme “403 Interdit”, dans une page d’erreur HTML. Plusieursmessages d’erreur sont disponibles, dont chacun est stocké dans un fichier HTMLséparé.

Ces fichiers sont enregistrés dans le répertoire suivant :

UNIX :<chemin_installation>/www/lib/errors/<répertoire_env_local>

Windows :<chemin_installation>\www\lib\errors\<rép_locale>

Le répertoire errors contient un certain nombre de sous-répertoiresd’environnement local contenant des versions localisées des fichiers de messagesd’erreurs.

Par exemple, le chemin du répertoire des messages US/English est :

UNIX : <chemin_installation>/www/lib/errors/en_US

Windows :<chemin_installation>\www\lib\errors\en_US

34 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 55: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Les messages de ce répertoire sont au format HTML de façon à pouvoir s’affichercorrectement dans un navigateur. Vous pouvez éditer ces pages HTML pourpersonnaliser leur contenu. Le nom des fichiers correspond à la valeurhexadécimale des codes d’erreur internes renvoyés à l’échec des opérations. Nemodifiez pas ces noms de fichiers.

Le tableau ci-après contient la liste des noms de fichiers et du contenu desmessages d’erreurs les plus courants :

Nom de fichier Titre Description Coded’erreurHTTP

132120c8.html L’authentification a échoué Les données d’autorisation n’ont pas pu êtreextraites du certificat du client utilisé. Les raisonspossibles 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 sontabsentes de la base de donnéesd’authentification

38ad52fa.html Répertoire non vide L’opération demandée exige le retrait d’unrépertoire non vide. Il s’agit d’une opération nonautorisée.

38cf013d.html La mise en antémémoire dela 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 laconnexion utilisateur

La ressource demandée exige que le serveurWebSEAL connecte l’utilisateur à un autre serveurWeb. Un incident s’est toutefois produit pendant latentative d’extraction des informations parWebSEAL.

38cf025a.html Aucune donnée deconnexion pour cetutilisateur

WebSEAL n’a pas pu trouver l’utilisateur GSOcorrespondant à la ressource demandée.

38cf025b.html Aucune destination deconnexion pour cetutilisateur

WebSEAL n’a pas pu trouver le destinataire GSOcorrespondant à la ressource demandée.

38cf025c.html Plusieurs destinations deconnexion sont définiespour l’utilisateur

Plusieurs destinataires GSO sont définis pour laressource demandée. Il s’agit d’une erreur deconfiguration.

38cf025d.html Connexion obligatoire La ressource demandée est protégée par unserveur Web d’arrière-plan relié au réseau, quiexige que WebSEAL se connecte à ce serveur Web.Pour ce faire, l’utilisateur doit d’abord seconnecter à WebSEAL.

38cf025e.html Impossible d’établir laconnexion utilisateur

La ressource demandée exige que WebSEALconnecte l’utilisateur à un autre serveur Web.Cependant, les informations de connexion ducompte utilisateur sont incorrectes.

38cf025f.html Question d’authentificationinattendue

WebSEAL a reçu une question d’authentificationinattendue 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éeprovisoirement. Ceci se produit en cas demauvaise gestion du réacheminement.

302

Chapitre 2. Configuration de base du serveur 35

Page 56: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Nom de fichier Titre Description Coded’erreurHTTP

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 parWebSEAL, 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 à laressource demandée.

403

38cf0428.html Introuvable La ressource demandée est introuvable. 404

38cf0432.html Service non disponible Un service nécessaire à WebSEAL pour traitervotre requête n’est pas disponible.

503

38cf0437.html Serveur suspendu Le serveur WebSEAL a été provisoirementsuspendu par l’administrateur système. Aucunerequête ne sera traitée tant que le serveur ne serapas remis en service par l’administrateur.

38cf0439.html Les données de la sessionont été perdues

La transaction entre le navigateur et le serveur aoccasionné une session avec un serveur relié auréseau par jonction. Ce serveur ne répond plus.WebSEAL a besoin d’un service installé sur ceserveur pour terminer le traitement de votrerequête.

38cf0442.html Service non disponible Le service nécessaire à WebSEAL se trouve sur unserveur d’arrière-plan relié au réseau par unejonction et sur lequel l’authentification SSLréciproque a échoué.

38cf07aa.html Le programme CGI aéchoué

Un programme CGI n’a pas pu s’exécutercorrectement.

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 aabouti.

200

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éeprovisoirement.

302

websealerror.html 400 Erreur du serveurWebSEAL

Erreur interne du serveur WebSEAL. 400

Prise en charge de macro pour les pages de messagesd’erreur HTTP

Les macros suivantes permettent de personnaliser les pages d’erreur HTMLrépertoriées dans la section précédente. Elles remplacent de façon dynamique lesinformations correspondantes disponibles.

Macro 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.

36 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 57: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Macro Description

%HOSTNAME% Nom d’hôte complet.

%HTTP_BASE% Adresse URL HTTP de base du serveur“http://<hôte>:<tcpport>/”.

%HTTPS_BASE% Adresse URL HTTPS de base du serveur“https://<hôte>:<sslport>/”.

%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’yen a pas.

%BACK_NAME% Valeur “BACK” si un en-tête de référenceur est présent dans larequête, ou “HOME” dans le cas contraire.

Gestion des pages personnalisées de gestion de comptesAccess Manager contient des exemples de pages HTML de gestion de comptes quipeuvent être personnalisés pour renfermer des messages spécifiques d’un site ouexécuter des actions spécifiques d’un site. La plupart des formulaires conviennentaux méthodes d’authentification BA, par formulaires et par jeton via HTTP ouHTTPS.

Les emplacements des fichiers correspondant à ces formulaires sont définis par leparamètre mgt-pages-root contenu dans la strophe [acnt-mgt] du fichier deconfiguration webseald.conf.mgt-pages-root = lib/html/<répertoire_lang>

Le répertoire utilisé dépend de la localisation. Ainsi le répertoire utilisé par défautpour 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éeLes valeurs et les paramètres de page HTML spéciaux suivants se trouvent dans lastrophe [acnt-mgt] du fichier de configuration webseald.conf. Certaines pages nesont utilisées que par la méthode de connexion à l’aide de formulaires qui permetde fournir des informations d’identité.

Paramètre Page Syntaxe

login = login.html Connexion à l’aide deformulaires

login-success = login_success.html Connexion à l’aide deformulaires

logout = logout.html Connexion à l’aide deformulaires

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

Page 58: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

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 etde 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 enraison 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 passeaboutit.

help.html Page contenant les liens pour valider les pagesd’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 descomptesIl 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 lesvaleurs appropriées.

Macro Description

%USERNAME% Nom de l’utilisateur connecté.

%ERROR% Message d’erreur défini dans le code renvoyé par AccessManager.

%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://<hôte>:<tcpport>/”.

%HTTPS_BASE% Adresse URL HTTPS de base du serveur“https://<hôte>:<sslport>/”.

38 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 59: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

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’iln’y en a pas.

%BACK_NAME% Valeur “BACK” si un en-tête de référenceur est présent dansla requête, ou “HOME” dans le cas contraire.

Gestion des certificats côté client et côté serveurCette section décrit les tâches d’administration et de configuration requises pourconfigurer WebSEAL en vue d’une gestion des certificats numériques côté client etcô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é serveurv 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é decertification (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 lesserveurs d’arrière-plan reliés au réseau par jonction, configurés pour uneauthentification réciproque

WebSEAL utilise l’implémentation de GSKit (Global Security Kit) IBM de SSL pourconfigurer et administrer les certificats numériques. GSKit contient l’utilitaireiKeyman qui permet de configurer et de gérer la base de données des clés decertificat contenant un ou plusieurs certificats serveur/client WebSEAL et lescertificats racine de CA.

WebSEAL inclut les composants suivants, lors de l’installation, pour prendre encharge 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éfautv Plusieurs certificats racine de CA usuelsv Un certificat de test d’auto-signature dont WebSEAL peut se servir pour

s’identifier auprès des clients SSLIl est conseillé de vous adresser à une autorité de certification reconnue pourremplacer 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 41v «Utilisation de l’utilitaire de gestion de certificat iKeyman» à la page 42v «Configuration du contrôle CRL» à la page 42

Chapitre 2. Configuration de base du serveur 39

Page 60: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Présentation des types de fichier de la base de données declés

L’outil IBM Key Management (iKeyman) utilise plusieurs types de fichierrépertoriés dans le tableau suivant.

Une base de données de clés CMS contient un fichier avec l’extension .kdb, voireplusieurs autres fichiers. Le fichier .kdb est créé en même temps qu’une nouvellebase de données de clés. Un enregistrement de clé contenu dans un fichier .kdbpeut correspondre à un certificat ou à un certificat avec des informations chiffréessur les clés privées.

Les fichiers .rdb et .crl sont créés en même temps qu’une nouvelle demande decertificat. Le fichier .rdb est nécessaire tout au long du traitement de la demandede certificat de CA.

Type defichier

Description

.kdb Fichier de la “base de données de clés”. Stocke les certificats personnels, les demandes de certificatpersonnel et les certificats de signataire. Par exemple, le fichier de la base de données de clésWebSEAL 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 nomdé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 fichierde base de données de clés .kdb. Le nom dérivé de ce fichier est identique à celui du fichier .kdbassocié. Ce fichier contient des demandes de certificat en attente qui n’ont pas été renvoyées par laCA. Lorsque la CA renvoie un certificat, la demande de certificat correspondante est recherchéedans le fichier .rdb (en fonction de la clé publique). Si une correspondance est trouvée, le certificatest renvoyé et la demande de certificat correspondante est supprimée du fichier .rdb. Si aucunecorrespondance n’est trouvée, la tentative de renvoi du certificat est rejetée. La demande decertificat inclut le nom de l’utilisateur, l’entreprise, l’adresse, d’autres informations définies enmê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 descertificats ayant été refusés pour une raison quelconque. Toutefois, iKeyman ne fournit aucune priseen 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’uncertificat, y compris sa clé publique, mais pas sa clé privée. Les données de certificat binaired’origine sont converties en représentation ASCII. Lorsqu’un utilisateur reçoit un certificat dans unfichier .arm, iKeyman décode la représentation ASCII et place la représentation binaire dans lefichier .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. Lesdonnées ASCII du fichier .arm sont celles que vous envoyez à la CA lors du processus de demandede 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’uncertificat, y compris sa clé publique mais pas sa clé privée. Il ressemble fortement à un fichier .armsauf que la représentation est binaire et non pas ASCII.

.p12 Fichier “PKCS 12” où PKCS signifie “Public-Key Cryptography Standards” (normes decryptographie de clé publique). Un fichier .p12 contient la représentation binaire d’un certificat, ycompris 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 dela 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

Page 61: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Configuration de paramètres de base de données de clésFichier de clés de certificat WebSEAL :

Lors de l’installation, WebSEAL fournit une base de données de clés de certificatpar 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 cefichier :[ssl]webseal-cert-keyfile = /var/pdweb/www/certs/pdsrv.kdb

Vous pouvez vous servir de l’utilitaire iKeyman pour créer une nouvelle base dedonnées de clés. Cependant, vous devez entrer le nom et l’emplacement de cenouveau fichier de clés dans le paramètre webseal-cert-keyfile pour que WebSEALpuisse 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 quicontient le mot de passe du fichier de clés pdsrv.kdb. Le paramètrewebseal-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ètrewebseal-cert-keyfile-pwd. Par exemple :webseal-cert-keyfile-pwd = pdsrv

A l’installation, WebSEAL utilise le fichier caché pour obtenir le mot de passe dufichier 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 formede texte dans le fichier de configuration webseald.conf.

Remarque : Annulez la mise en commentaire du paramètre du mot de passespécifique que vous voulez utiliser. Si le mot de passe et le fichiercaché sont tous les deux spécifiés, la valeur du mot de passe estutilisée.

Certificat de test WebSEAL :

A l’installation, WebSEAL fournit un certificat de test d’auto-signature nonsécurisé. Le certificat de test, qui sert de certificat côté client, permet à WebSEALde s’identifier auprès des clients SSL.

Pour mieux contrôler l’utilisation de ce certificat de test, le certificat n’est pasinstallé comme certificat par défaut. Le paramètre webseal-cert-keyfile-labeldésigne le certificat comme certificat côté client actif et remplace tous les autrescertificats “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’unnavigateur activé SSL, il ne peut pas être vérifié par le navigateur (qui ne contientpas de certificat d’autorité de certification approprié). Comme la clé privée de cecertificat par défaut se trouve dans chaque distribution WebSEAL, ce certificatn’assure pas de véritables communications sécurisées.

Chapitre 2. Configuration de base du serveur 41

Page 62: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Vous devez avoir recours à l’utilitaire iKeyman pour générer une demande decertificat qui peut être envoyée à une autorité de certification (CA). UtiliseziKeyman 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, lesjonctions –K), vous pouvez vous servir de l’utilitaire iKeyman pour les créer, lesinstaller et leur affecter un libellé. Le libellé des fichiers de clés ne doit pas contenird’espace.

WebSEAL (qui s’exécute par défaut en tant que user ivmgr) doit détenir des droitsd’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 autresparamètres destinés à configurer le fichier de clés utilisé par WebSEAL pour lescommunications SSL internes avec les autres serveurs Access Manager. Vouspouvez modifier ces paramètres uniquement à l’aide du script de configurationpdconfig.[ssl]ssl-keyfile =ssl-keyfile-pwd =ssl-keyfile-stash =ssl-keyfile-label =

Utilisation de l’utilitaire de gestion de certificat iKeymanL’utilitaire iKeyman est un outil livré avec GSKit qui permet de gérer les certificatsnumériques utilisés par WebSEAL. Servez-vous de iKeyman pour :v créer une ou plusieurs bases de données de clés,v modifier les mots de passe de connexion à la base de données de clés,v créer de nouveaux certificats WebSEAL,v définir un nouveau certificat WebSEAL par défaut,v 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 CRLLa liste LRC (Liste de révocation des certificats) constitue une méthode quiempêche la validation des certificats non souhaités. Elle contient les identités descertificats jugées non fiables. La mise en oeuvre GSKit de SSL utilisée parWebSEAL prend en charge le contrôle LRC. GSKit permet à WebSEAL d’exécuter lecontrôle LRC sur les certificats côté client et sur les certificats émanant de jonctionsSSL.

WebSEAL doit connaître l’emplacement de cette liste pour exécuter le contrôleLRC. Vous pouvez trouver les paramètres liés à l’emplacement du serveur LDAPpouvant servir de référence pour le contrôle LRC pendant l’authentification parcertificat dans la strophe [ssl] du fichier de configuration webseald.conf.[ssl]#ssl-ldap-server = <nom_serveur>#ssl-ldap-server-port = <ID_port>#ssl-ldap-user = <nom_administrateur_webseal>#ssl-ldap-user-password = <mot_de_passe_administrateur>

42 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 63: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Par défaut, le contrôle LRC est désactivé (les paramètres sont placés encommentaire). 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 SSLdoit s’associer au serveur LDAP en tant qu’utilisateur anonyme.

Configuration du cache CRLGSKit permet à WebSEAL d’exécuter le contrôle LRC sur les certificats côté clientet sur les certificats émanant de jonctions SSL. Pour améliorer les performances ducontrô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 encomparaison avec cette version de la liste mise en mémoire cache.

Les valeurs affectées aux deux paramètres du fichier de configurationwebseald.conf décrits dans cette section sont directement transmis à l’utilitaireGSKit. Pour plus d’informations sur les fonctionnalités GSKit, reportez-vous à ladocumentation correspondante.

Définition du nombre maximal d’entréesLe paramètre gsk-crl-cache-size spécifie le nombre maximal d’entrées dans le cacheCRL 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 etgsk-crl-cache-entry-lifetime portent la valeur “0” (valeur par défaut), la mise enmé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 demémoire cache GSKitLe paramètre gsk-crl-cache-entry-lifetime spécifie la valeur de délai d’expirationapplicable à toutes les entrées du cache CRL GSKit. La valeur est exprimée ensecondes et peut être comprise dans la plage 0-86400 secondes. Lorsquegsk-crl-cache-size et gsk-crl-cache-entry-lifetime portent la valeur “0” (default), lamise en mémoire cache de CRL est désactivée.[ssl]gsk-crl-cache-size = 0

Chapitre 2. Configuration de base du serveur 43

Page 64: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Configuration de la journalisation HTTP par défautWebSEAL 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 trouventdans la strophe [logging] du fichier de configuration webseald.conf.

Le tableau ci-après illustre les relations entre les fichiers journaux HTTP et lesparamètres du fichier de configuration :

Fichiers journaux Paramètre d’emplacement Paramètred’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îtcomme 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 HTTPPar défaut, la journalisation HTTP est totalement activée :[logging]requests = yesreferers = yesagents = yes

Chaque journal peut être activé ou désactivé indépendamment des autres. Si unparamè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éepar 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

Page 65: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Spécification du type d’horodatageVous pouvez choisir d’avoir les données d’horodatage enregistrées dans chaquejournal en heure GMT (Greenwich Mean Time) plutôt que dans la zone horairelocale. 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 journauxLe paramètre max-size indique la taille maximale que peut atteindre un fichierjournal 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), lefichier existant est sauvegardé dans un fichier du même nom, auquel sont ajoutéesla 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 lefichier journal augmente à l’infini. Si un fichier journal existe déjà, aucunenouvelle donnée n’y est ajoutée.

v Si la valeur max-size est supérieure à zéro (> 0), un roulement s’effectuelorsqu’un fichier journal atteint la valeur de seuil configurée. Si un fichierjournal 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 tamponde fichier journal

Les fichiers journaux sont enregistrés dans des flux de données mises en mémoiretampon. Si vous contrôlez les fichiers journaux en temps réel, vous voudrezpeut-être modifier la fréquence à laquelle le serveur force un vidage des mémoirestampon 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 chaqueenregistrement.

Format de journal HTTP courant (pour request.log)Chaque réponse (succès ou échec) renvoyée par le serveur Access Manager estenregistrée avec une entrée d’une ligne dans le fichier request.log à l’aide duformat de journal HTTP courant suivant :host - authuser [date] request status bytes

Chapitre 2. Configuration de base du serveur 45

Page 66: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

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 HTTPreçue. La valeur “unauth” est utilisée pour un utilisateur nonauthentifié.

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 parle client.

status Indique le code d’état HTTP renvoyé à la machine émettant larequête.

bytes Indique le nombre d’octets renvoyés à la machine émettant larequête. Cette valeur (qu’il s’agisse de la taille du contenu nonfiltré ou d’une taille de zéro octet) est configurée avec le paramètrelog-filtered-pages.

Affichage du fichier request.logLe journal request.log enregistre la journalisation standard des requêtes HTTP,comme les informations relatives aux adresses URL qui ont été demandées et lesinformations 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 - - [26/Jan/2002:17:23:33 -0800] "GET /~am/a_html/ HTTP/1.0" 403 77130.15.1.90 - - [26/Jan/2002:17:23:47 -0800] ”GET /icons HTTP/1.0" 302 93130.15.1.90 - - [26/Jan/2002:17:23:59 -0800] "GET /icons/ HTTP/1.0" 403 77130.15.1.90 - - [26/Jan/2002:17:24:04 -0800] "GET /~am/a_html/ HTTP/1.0" 403 77130.15.1.90 - - [26/Jan/2002:17:24:11 -0800] "GET /~am/ HTTP/1.0" 403 77

Affichage du fichier agent.logLe fichier agent.log enregistre le contenu de l’en-tête User_Agent: dans la requêteHTTP. 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 [en] (WinNT; U)Mozilla/4.01 [en] (WinNT; U)Mozilla/4.01 [en] (WinNT; U)Mozilla/4.01 [en] (WinNT; U)

Affichage du fichier referer.logLe journal referer.log enregistre l’en-tête Referer: de la requête HTTP. Pourchaque requête, le fichier journal enregistre le document qui contenait le lien audocument demandé.

Le journal utilise le format suivant :référenceur -> objet

Ces informations sont utiles pour effectuer le suivi des liens externes auxdocuments de votre espace Web. Le journal révèle que la source mentionnée par leréférenceur contient un lien à un objet page. Il vous permet de pister les lienspérimés et de découvrir les auteurs de liens à vos documents.

46 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 67: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

L’exemple suivant montre un exemple de fichier referer.log :http://manuel/maybam/index.html -> /pics/tivoli_logo.gifhttp://manuel/maybam/pddl/index.html ->/pics/tivoli_logo.gifhttp://manuel/maybam/ -> /pddl/index.htmlhttp://manuel/maybam/ -> /pddl/index.htmlhttp://manuel/maybam/pddl/index.html ->/pics/tivoli_logo.gifhttp://manuel/maybam/ -> /pddl/index.html

Configuration de la journalisation HTTP par défautLa journalisation HTTP WebSEAL peut être configurée dans la strophe[aznapi-configuration] du fichier de configuration webseald.conf via l’utilisationdu paramètre de journalisation d’événements logcfg pour définir un ou plusieursagents de journalisation (enregistreurs) chargés de rassembler une certainecatégorie d’informations à partir du pool d’événements et d’acheminer cesinformations vers une destination donnée :[aznapi-configuration]logcfg =<catégorie>:{stdout|stderr|file|pipe|remote}[[<param>[=<valeur>]][,<param>[=<valeur>]]...]

Pour plus d’informations sur la configuration de la journalisation d’événements,reportez-vous au chapitre consacré à la “journalisation d’événements” dudocument 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 HTTPv http.clf

Informations sur les requêtes HTTP au format de journalisation courantv http.ref

Informations sur l’en-tête du référenceur HTTPv http.agent

Informations sur l’en-tête HTTP User_Agentv 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 formatstandard.

Les configurations suivantes d’agent de journalisation sont activées lorsque lesparamè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 acceptentles valeurs des paramètres requests-file, referers-file, agents-file, flush-time etmax-size du fichier de configuration webseald.conf (strophe [logging]) :

request.log (format de journalisation courant) :logcfg = http.clf:file path=<requests-file>,flush=<flush-time>, \rollover=<max-size>,log=clf,buffer_size=8192,queue_size=48

referer.log:logcfg = http.ref:file path=<referers-file>,flush=<flush-time>, \rollover=<max-size>,log=ref,buffer_size=8192,queue_size=48

Chapitre 2. Configuration de base du serveur 47

Page 68: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

agent.log (format de journalisation courant) :logcfg = http.agent:file path=<agents-file>,flush=<flush-time>, \rollover=<max-size>,log=agent,buffer_size=8192,queue_size=48

Etant donné que la journalisation HTTP par défaut est configurée dans une strophediffé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 pourchaque événement dans un fichier journal lorsque ces deux modes dejournalisation sont activés.

Le mode de journalisation d’événements offre davantage de souplesse lors duregroupement des informations de journalisation HTTP et de la personnalisationdes résultats.

Consignation des messages de mise en service WebSEALLes messages de mise en service d’Access Manager WebSEAL sont contrôlés par lefichier d’acheminement d’Access Manager WebSEAL. Le fichier d’acheminement setrouve 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 documentssupplémentaires sous la forme de lignes de commentaires. Les entrées de ce fichierde 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 fichierd’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écifiquePDWEBDIR est définie dans le répertoire d’installation de WebSEALau moment de l’exécution.

Par défaut, lorsque WebSEAL est exécuté en arrière-plan, tous les messages sontenvoyés à l’écran (STDERR).

48 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 69: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

De la même façon, par défaut, lorsque WebSEAL est exécuté en arrière-plan, lesmessages sont réacheminés à partir de STDERR et sont envoyés au fichier journaldu serveur WebSEAL, conformément aux indications de la strophe [logging] dufichier de configuration webseald.conf :

Serveur Fichier deconfiguration

Emplacement du fichier journal

Serveur WebSEAL(webseald)

webseald.conf UNIX :[logging]server-log=/var/pdweb/log/webseald.logWindows :[logging]server-log=C:\Program Files\Tivoli\PDWeb\log\webseald.log

Pour activer verbose.log, ne faites aucun commentaire sur la ligneNOTICE_VERBOSE.

Le syntaxe de FILE pour le message NOTICE contrôle le renouvellement desjournaux et le recyclage des fichiers :FILE.<max-files>.<max-records>

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 nomssuivants :notice.log.1notice.log.2...notice.log.10

Les messages se présentent “en boucle”, du premier fichier au dernier fichier ayantatteint sa limite ou du démarrage à l’arrêt du serveur. En cas de réutilisation d’unfichier journal, les enregistrements existants sont écrasés (effacés).

Chapitre 2. Configuration de base du serveur 49

Page 70: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

50 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 71: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Chapitre 3. Configuration avancée du serveur

Ce chapitre contient des informations sur les tâches génériques d’administration etde configuration à exécuter pour personnaliser le serveur WebSEAL en fonction devotre réseau.

Index des rubriques :v «Configuration d’un niveau de protection par défaut» à la page 51v «Configuration des mises à jour et de l’interrogation de la base de données

d’autorisation» à la page 53v «Gestion des affectations des unités d’exécution d’agents» à la page 54v «Réplication de serveurs frontaux WebSEAL» à la page 57v «Configuration de plusieurs instances de serveur WebSEAL» à la page 58v «Configuration du changement d’utilisateur pour les administrateurs» à la page

65v «Configuration de la mise en mémoire cache des requêtes WebSEAL côté

serveur» à la page 72v «Gestion des caractères codés UTF-8» à la page 76v «Prévention de la vulnérabilité causée par les scripts inter-sites» à la page 77v «Suppression de l’identité de serveurs» à la page 79v «Utilisation des statistiques WebSEAL» à la page 79v «Utilisation de l’utilitaire de trace pour regrouper les actions de WebSEAL» à la

page 89

Configuration d’un niveau de protection par défautVous 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). Lagestion du niveau de protection par défaut est contrôlée par les paramètres de lasection “SSL QUALITY OF PROTECTION MANAGEMENT” du fichier deconfiguration 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 | <niveau_chiffrement># 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

© Copyright IBM Corp. 1999, 2002 51

Page 72: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

# RC2-128# RC4-40# RC4-128default = ALL

Notez que vous pouvez également définir un groupe de méthodes dechiffrement :[ssl-qop-mgmt-default]default = RC4-128default = RC2-128default = DES-168

Configuration du niveau de protection pour les réseaux et leshôtes individuels

Le paramètre ssl-qop-mgmt = yes active également tous les paramètresapparaissant dans les strophes [ssl-qop-mgmt-hosts] et [ssl-qop-mgmt-networks].Ces strophes autorisent la gestion du niveau de protection par adresse IPd’hôte/de réseau/de masque de réseau.

La strophe [ssl-qop-mgmt-default] répertorie les méthodes de chiffrement utiliséespour 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]# <IP_hôte> = ALL | NONE | <niveau_chiffrement># 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-128xxx.xxx.xxx.xxx = ALLyyy.yyy.yyy.yyy = RC2-128

Exemple de syntaxe de configuration pour les réseaux/masques de réseau :[ssl-qop-mgmt-networks]# <réseau/masque_réseau> = ALL | NONE |<niveau_chiffrement># 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-128xxx.xxx.xxx.xxx/255.255.255.0 = RC4-128yyy.yyy.yyy.yyy/255.255.0.0 = DES-56

Les strophes [ssl-qop-mgmt-hosts] et [ssl-qop-mgmt-networks] sont fournies pourla compatibilité amont uniquement. Il est recommandé de ne pas les utiliser pourla configuration d’Access Manager.

52 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 73: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Configuration des mises à jour et de l’interrogation de la base dedonnées d’autorisation

Access Manager Policy Server (pdmgrd) gère la base de données de règlesd’autorisation principale et conserve les informations sur les emplacements desautres serveurs Access Manager du domaine sécurisé. Un administrateur AccessManager peut à tout moment apporter des modifications aux règles de sécurité dudomaine sécurisé. Policy Server modifie la base de données d’autorisationprincipale 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 peutenvoyer une notification de ce changement à toutes les répliques de la base dedonnées dans le domaine sécurisé qui prennent en charge les différentsapplicateurs de règles (par exemple, WebSEAL). Les applicateurs de règles doiventensuite demander une mise à jour de la base de données réelle à partir de la basede données d’autorisation principale.

En tant que gestionnaire de ressources et applicateur de règles, WebSEAL peutobtenir des informations sur les modifications apportées à la base de donnéesd’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.confcontient des paramètres destinés à configurer les interrogations de base de donnéeset l’écoute des notifications de mise à jour.

Le paramètre db-file définit le chemin de la base de données des règlesd’autorisation des répliques locales de WebSEAL :[aznapi-configuration]db-file = /var/pdweb/db/webseald.db

Configuration de l’écoute des notifications de mise à jourLe 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

Page 74: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Configuration de l’interrogation de la base de donnéesd’autorisation

Vous pouvez configurer WebSEAL de façon à interroger la base de donnéesd’autorisation principale à intervalles réguliers pour rechercher des informationsde 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. Lavaleur “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’agentsv «Configuration des unités d’exécution d’agents WebSEAL» à la page 54v «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 WebSEALLe nombre d’unités d’exécution d’agents configurées spécifie le nombre derequêtes entrantes concurrentes pouvant être prises en charge par un serveur. Lesautres connexions arrivant lorsque toutes les unités d’exécution d’agents sontoccupées sont mises en mémoire tampon jusqu’à ce qu’une unité d’exécution soitdisponible.

Vous pouvez définir le nombre d’unités d’exécution disponibles pour la prise encharge des connexions entrantes dans WebSEAL. Etant donné les risques encourusau niveau des performances, la configuration du nombre d’unités d’exécutiond’agents doit s’effectuer avec précaution.

Ce paramètre de configuration n’impose pas de limite supérieure au nombre deconnexions simultanées. Il simplifie simplement le nombre d’unités d’exécutionmises à 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 dontvous 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 letemps moyen de traitement des requêtes. Mais vous jouez également sur d’autresfacteurs 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ésd’exécution pour le traitement des requêtes émanant de clients utilisant des tunnelsTCP ou SSL. Ce mécanisme renforcé permet à WebSEAL d’économiser lesressources 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 endéfinissant le paramètre worker-threads de la strophe [server] du fichier deconfiguration webseald.conf .[server]worker-threads = 50

Remarque : Il est vivement recommandé de ne modifier ce paramètre qu’en cas dedépannage d’un incident lié aux performances.

54 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 75: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

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 WebSEALutilisées afin de traiter les requêtes au niveau de plusieurs jonctions ou sur unebase globale ou jonction par jonction. La méthode de configuration permet degarantir une répartition “équitable” des unités d’exécution d’agents parmi lesjonctions et empêche la limitation du pool des unités d’exécution à l’une desjonctions.

Principes de basePour traiter plusieurs requêtes, WebSEAL effectue des extractions dans le pool desunités d’exécution d’agents. Le nombre d’unités d’exécution d’agents disponiblepour WebSEAL est spécifié par le paramètre worker-threads du fichier deconfiguration webseald.conf.

Vous pouvez adapter la valeur affectée à worker-threads afin de tenir compte devotre installation WebSEAL spécifique. Lorsqu’aucune unité d’exécution d’agentsn’est disponible pour la gestion des requêtes entrantes, les utilisateurs peuventconstater 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 entrantesrelatives 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 uneapplication 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 à cetteapplication a pour effet de rendre WebSEAL incapable de répondre aux demandesde services sur les autres serveurs d’applications reliés par jonction.

Vous pouvez configurer des limites globales ou jonction par jonction au niveau dunombre d’unités d’exécution d’agents utilisées pour les applications résidant surplusieurs jonctions. Ces limites permettent de garantir une “équité” pour toutes lesjonctions et interdisent à une application de réclamer davantage que sa partd’unités d’exécution.

Affectation globale d’unités d’exécution d’agents à des jonctionsDeux paramètres de la strophe [junction] du fichier de configurationwebseald.conf de contrôler, pour un serveur WebSEAL spécifique, l’affectationglobale des unités d’exécution d’agents entre les différentes jonctions. Les valeursaffectées à ces paramètres sont exprimées en pourcentages (de 0 à 100). La valeurpar 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 soitatteinte. Lorsque la valeur affectée à worker-thread-soft-limit est dépassée, desmessages d’avertissement sont insérés (toutes les 30 secondes) dans le fichierjournal des erreurs de WebSEAL.Par exemple, lorsque worker-threads=50, une valeur 60 (%) entraîne l’affichagede messages lorsque la jonction consomme plus de 30 unités d’exécutiond’agents. Toutes les requêtes contenant au maximum 30 unités d’exécutiond’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 serviceacheminées via une jonction. Lorsque la valeur affectée à worker-thread-hard-

Chapitre 3. Configuration avancée du serveur 55

Page 76: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

limit est dépassée, des messages d’erreur sont envoyés toutes les 30 secondes aufichier journal d’erreurs de WebSEAL. En outre, l’utilisateur reçoit le message503 (“Service non disponible”).Par exemple, lorsque worker-threads=50, la valeur 80 (%) entraîne l’affichage demessages d’erreur lorsque la jonction tente de consommer plus de 40 unitésd’exécution d’agents. Toutes les requêtes qui représentent plus de 40 unitésd’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. Lorsquevous 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 jonctionVous pouvez également limiter la consommation des unités d’exécution d’agentsjonction par jonction. Les options suivantes de la commande pdadmin server taskcreate permettent de spécifier les limites matérielles et logicielles applicables auxunités d’exécution d’agents pour une jonction spécifique :v –l <percent-value>

Cette option permet de définir, pour une jonction, une valeur (pourcentage) quiconstitue 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înel’affichage de messages d’avertissement lorsque la jonction consomme plusd’unités d’exécution que le nombre stipulé.

v –L <percent-value>Cette option permet de définir, pour une jonction, une valeur (pourcentage) quiconstitue 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înel’affichage de messages d’avertissement lorsque la jonction consomme plusd’unités d’exécution que le nombre stipulé.En outre, l’utilisateur reçoit lemessage 503 (“Service non disponible”).

Par exemple :pdadmin> server taskwebseald-<nom_serveur> create -t tcp -h <nom_hôte> \-l 60 -L 80 <point_jct>

Le paramétrage par jonction écrase toujours le paramétrage global dans le fichierwebseald.conf. Des valeurs inappropriées affectées à une jonction spécifiquerisquent d’affecter les règles établies par le paramétrage global.

Notes de résolution des incidentsv 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 taskwebseald-<nom_serveur> show/<point_jct>

Ces informations peuvent s’avérer utiles si vous souhaitez déterminerl’emplacement d’une jonction qui consomme plus que sa part d’unitésd’exécution d’agents (ressources).

v Si vous spécifiez une limite logicielle supérieure à la valeur de limite matériellepour 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

Page 77: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Réplication de serveurs frontaux WebSEAL

Remarque : Les informations suivantes remplacent l’ancienne commande pdadminserver modify baseurl utilisée dans les versions précédentes d’AccessManager.

Dans un environnement à forte charge, il est préférable de répliquer des serveursfrontaux WebSEAL afin d’optimiser l’équilibrage de charge et la fonction desecours. Lorsque vous répliquez des serveurs frontaux WebSEAL, chaque serveurdoit contenir une copie exacte de l’espace Web, de la base de données des jonctionset de la base de données dynurl.

Cette version d’Access Manager prend en charge une procédure de configurationmanuelle pour répliquer des serveurs frontaux WebSEAL. La commande pdadminn’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 évaluationsd’autorisation. Le serveur WS2 peut également répondre aux commandes objectlist et object show pour les objets situés sous /WebSEAL/WS1.

L’utilitaire pdadmin répertorie toujours l’objet /WebSEAL/WS2 comme faisant partiede 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 lescommandes d’administration appliquées à cette hiérarchie et peuvent yrépondre.

v Evaluation de l’autorisation globale : Si le serveur WS2 est configuré en tant queréplique du serveur WS1, il utilise /WebSEAL/WS1 comme base pour évaluer lesautorisations.

v Configuration globale : Pour que la réplication du serveur frontal WebSEALfonctionne correctement, les configurations de l’espace Web, de la base dedonnées des jonctions et de la base de données dynurl doivent être identiquessur chaque serveur.

Chapitre 3. Configuration avancée du serveur 57

Page 78: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Configuration de plusieurs instances de serveur WebSEALAccess Manager offre la possibilité de configurer plusieurs instances de serveurWebSEAL sur une même machine.

Généralités sur la configurationA des fins de configuration, une instance de serveur WebSEAL est définie par unecombinaison unique interface réseau (adresse IP)/numéro de port.

Plusieurs instances WebSEAL peuvent être configurées à l’aide de l’une desméthodes suivantes, afin de créer une combinaison unique interfaceréseau/numéro de port.v Utilisez une interface réseau simple (adresse IP) et affectez des instances

WebSEAL à des ports d’écoute HTTP/HTTPSv Affectez des instances WebSEAL à des interfaces réseau uniques (cartes

physiques d’interface réseau ou alias de réseau logique) et utilisez des portsHTTP/HTTPS courants.

Remarque : Dans les deux cas, la valeur de port interserveurs spécifiée parl’option –m doit être unique pour toutes les instances WebSEAL.

Chaque instance WebSEAL configurée possède un nom unique, un numéro de portinterne unique (pour les communications entre serveurs Access Manager), unemplacement de répertoire unique et un fichier de configuration unique. Plusieursfichiers de configuration sont rendus uniques par le nom d’instance de serveur,précédé de webseald-. Par exemple :/opt/pdweb/etc/webseald-<nom_instance>.conf

Les outils de configuration requis pour la configuration de plusieurs instances deserveur 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’instanceWebSEAL initiale. La commande PDWeb_config doit être utiliséepour la création de toutes les instances supplémentaires. Celasuppose 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 UNIXL’utilitaire PDWeb_config est situé dans le répertoire suivant :/opt/pdweb/sbin/

Syntaxe PDWeb_config :# ./PDWeb_config –i<nom_instance> –m<port_interne> [–n<interface_réseau>]

58 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 79: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Argument Description

nom_instance Nom unique de cette instance. Vous devez utiliser cenom pour déconfigurer l’instance. La longueur de cenom est limitée à 20 caractères.

port_interne Numéro de port unique utilisé pour les communicationsentre serveurs Access Manager. La valeur affectée doitêtre supérieure à 1023. (Les valeurs inférieures à 1023sont réservées.)

interface_réseau Argument facultatif permettant de spécifier l’adresse IPd’une interface réseau.

Remarque : La valeur de port de serveurs spécifiée par l’option –m doit êtreunique 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 uneinstance WebSEAL supplémentaire.Dans ce scénario, plusieurs instances de serveurs sont rendues uniques grâceaux désignations uniques de ports de serveurs et de ports d’écouteHTTP/HTTPS sur l’interface réseau par défaut. Par conséquent, n’utilisez pasl’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 checkWeb Server configuration:1. Enable TCP HTTP? Yes2. HTTP Port 803. Enable HTTPS? Yes4. HTTPS Port 4435. Web document root directory /opt/pdweb/www-webseal2/docsa. Accept configuration and continue with installationx. Exit installationSelect 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 valeursuniques 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 unevaleur de port déjà utilisée. Vous avez alors la possibilité desélectionner une autre valeur.

6. Exécutez la commande PDWeb_config pour créer et configurer des instancesde 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 portsHTTP et HTTPS.

Remarque : Le nombre maximal d’instances WebSEAL autorisé dépend deslimitations du système en matière de configuration (mémoire RAM

Chapitre 3. Configuration avancée du serveur 59

Page 80: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

et espace disque disponible, par exemple). Si l’une des ressourcessystème est dépassée, des messages d’échec de configuration etd’échec de démarrage apparaissent.

Configuration de plusieurs instances sur des interfaces réseau logiquesuniques :

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 initialepour pouvoir configurer et exécuter d’autres serveurs WebSEAL.

Remarque : Aucun autre serveur WebSEAL ne peut démarrer si le serveurinitial utilise pour son écoute *:80 et *:443.

3. Modifiez le fichier de configuration webseald.conf et spécifiez l’adresse IPappropriée au serveur WebSEAL initial en ajoutant le paramètrenetwork-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 interfaceré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 physiquepré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 uneinstance 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’écouteHTTP/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 (network interface name = lan0:1):# ./PDWeb_config –i webseal2 –m 3232 –n lan0:1

HP-UX utilise le nom d’interface réseau au lieu de l’adresse IP. L’utilitairePDWeb_config vérifie que l’interface possède une adresse IP valide.

8. L’écran de configuration apparaît :Please check WebServer configuration:1. Enable TCP HTTP? Yes2. HTTP Port 803. Enable HTTPS? Yes4. HTTPS Port 4435. Web document root directory /opt/pdweb/www-webseal2/docsa. Accept configuration and continue with installationx. Exit installationSelect item to change:

60 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 81: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

9. Acceptez les valeurs standard de port HTTP et HTTPS telles qu’ellesapparaissent dans la liste.

10. Exécutez la commande PDWeb_config pour créer et configurer des instancesde serveur WebSEAL supplémentaires. Par exemple :# ./PDWeb_config –i webseal3 –m 3233 -n 1.2.3.6

HP-UX (network interface name = lan0:2):# ./PDWeb_config –i webseal3 –m 3232 –n lan0:2

11. Utilisez l’écran de configuration pour accepter les valeurs standard de portsHTTP et HTTPS figurant dans la liste.

Remarque : Le nombre maximal d’instances WebSEAL autorisé dépend deslimitations du système en matière de configuration (mémoire RAM etespace disque disponible, par exemple). Si l’une des ressourcessystème est dépassée, des messages d’échec de configuration etd’échec de démarrage apparaissent.

Configuration de plusieurs instances WebSEAL sousWin NT/2000

Hypothèses :v Une instance de serveur WebSEAL a été configuréev Les procédures décrites sont adaptées aux plates-formes Windows NT/2000

Syntaxe ivweb_setup :MSDOS> ivweb_setup -m <mot_de_passe_pdadmin> -i<nom_instance> \-M <port_interne> -u {yes|no} -r<port_http> -U {yes|no} \-R <port_https> [-n<interface_réseau>]

Option et argument Description

–m <mot_de_passe_pdadmin> Mot de passe d’administration.

–i <nom_instance> Nom unique de cette instance. Vous devez utiliser cenom pour déconfigurer l’instance. La longueur de cenom est limitée à 20 caractères.

–M <port_interne> Numéro de port unique utilisé pour les communicationsentre serveurs Access Manager. La valeur affectée doitêtre supérieure à 1023. (Les valeurs inférieures à 1023sont réservées.)

–u {yes|no} Active/désactive l’accès HTTP.

–r <port_http> Numéro de port à utiliser pour l’accès HTTP.

–U {yes|no} Active/désactive l’accès HTTPS.

–R <port_https> Numéro de port à utiliser pour l’accès HTTPS.

–n <interface_réseau> Argument facultatif permettant de spécifier l’adresse IPd’une interface réseau.

Remarque : La valeur de port interserveurs spécifiée par l’option –M doit êtreunique pour toutes les instances WebSEAL.

Chapitre 3. Configuration avancée du serveur 61

Page 82: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

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 instanceWebSEAL supplémentaire.Dans ce scénario, plusieurs instances de serveurs sont rendues uniques grâceaux désignations uniques de ports de serveurs et de ports d’écouteHTTP/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 unevaleur de port déjà utilisée. Vous avez alors la possibilité desélectionner une autre valeur.

4. Exécutez la commande ivweb_setup pour créer et configurer des instances deserveur 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 logiquesuniques :

1. Hypothèse : Windows est configuré pour un serveur WebSEAL initial et uneadresse 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 initialepour pouvoir configurer et exécuter d’autres serveurs WebSEAL.

Remarque : Aucun autre serveur WebSEAL ne peut démarrer si le serveurinitial utilise pour son écoute *:80 et *:443.

3. Modifiez le fichier de configuration webseald.conf et spécifiez l’adresse IPappropriée au serveur WebSEAL initial en ajoutant le paramètrenetwork-interface à la strophe [server]. Par exemple :[server]network-interface = 1.2.3.4

4. Redémarrez le serveur WebSEAL à partir du panneau de configuration desservices :

5. Pour chaque instance de serveur WebSEAL supplémentaire, configurez uneinterface réseau logique supplémentaire (alias) à l’aide du panneau deconfiguration (Connexions réseau). Par exemple (sous Windows 2000) :a. Panneau de configuration > Connexions réseaub. 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. Cliquez sur Propriétés et sélectionnez Avancéese. Dans l’onglet Paramètres IP, cliquez sur Ajouterf. Entrez une adresse IP à associer à la nouvelle interface réseaug. Entrez un masque de sous-réseauh. Cliquez sur Ajouter

62 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 83: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

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 instanceWebSEAL 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’écouteHTTP/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 deserveur 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 WebSEALVous ne pouvez pas déconfigurer le serveur WebSEAL initial si toutes les instancesde serveur n’ont pas été au préalable déconfigurées.

UNIX :PDWeb_unconfig -i <nom_instance>

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 <pdadmin-passwd> -i <instance-name>

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 webseal2MSDOS> ivweb_uninst -deconfig -m xxxxxx -i webseal3

Commandes de serveur start, stop, restart et statusUNIX :

L’utilitaire pdweb contient des fonctions de démarrage, d’arrêt, de redémarrage etd’état pour le serveur initial WebSEAL et pour les instances de serveur multiples.Vous pouvez également appliquer une commande à une instance de serveurspécifique.pdweb {start|stop|restart|status} [<nom_instance>]

Chapitre 3. Configuration avancée du serveur 63

Page 84: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Exemples :

Démarrage du serveur WebSEAL initial et de toutes les instances de serveurconfiguré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 serveurconfigurées :# /usr/bin/pdweb restart

Arrêt du serveur WebSEAL initial et de toutes les instances de serveurconfiguré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 statusServeurs Access ManagerServeur Activé En fonctionnement------------------------------------------pdmgrd oui ouipdacld oui ouiwebseald oui ouiwebseald-webseal2 oui ouiwebseald-webseal3 oui oui

Windows :

Le panneau de configuration Windows (Services) contient des informationsrelatives 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 pourle serveur initial WebSEAL et pour les instances de serveur multiples.net {start|stop} <nom_instance>

Exemples :

Démarrage du serveur WebSEAL initial et de toutes les instances de serveurconfigurées (vous devez exécuter la commande pour chaque instance) :MSDOS> net start websealdMSDOS> net start webseal2MSDOS> 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 websealdMSDOS> net stop webseal2MSDOS> 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

Page 85: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Configuration du changement d’utilisateur pour les administrateursLa fonctionnalité WebSEAL de changement d’utilisateur permet à certainsadministrateurs de déterminer l’identité d’un utilisateur membre du domainesécurisé d’Access Manager. La mise en oeuvre de cette fonctionnalité est identiqueà l’exécution de la commande su en environnement UNIX. En environnementWebSEAL, l’administrateur obtient les données d’autorisation de l’utilisateur etassure l’interaction avec les ressources et les applications d’arrière-plan dotées desmêmes capacités que l’utilisateur réel.

Le changement d’utilisateur peut être utilisé en environnement Help Desk à desfins de résolution d’incidents et de diagnostic. Il peut également servir à testerl’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 changerd’utilisateur au profit d’un autre membre de ce groupe.

v Les processus Access Manager, sec_master ainsi que d’autres utilisateurssélectionnés peuvent être exclus de la fonctionnalité de changement d’utilisateurs’ils appartiennent à un groupe d’exclusion

v Un formulaire HTML spécifique est utilisé pour transmettre les informationsrelatives au changement d’utilisateur et pour activer une méthoded’authentification spécifique qui renvoie les données d’autorisation del’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 sessionde changement d’utilisateur.

Explication du processus de changement d’utilisateurLa 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’estauthentifié à WebSEAL, une session a été établie et une entrée a été créée pourl’administrateur dans la mémoire cache des sessions/données d’autorisationWebSEAL.

2. L’administrateur se connecte à un formulaire HTML préconfiguré dechangement d’utilisateur. Ce formulaire est accessible uniquement auxmembres du groupe su-admins.

3. Le formulaire de changement d’utilisateur est rempli et renvoyé avec lesinformations suivantes : nom d’utilisateur (l’administrateur est “attribué à”cet utilisateur), une adresse URL de destination, une méthoded’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 parla bibliothèque partagée de changement d’utilisateur ou par une bibliothèqueCDAS de changement d’utilisateur personnalisée. La bibliothèque dechangement d’utilisateur (personnalisée ou intégrée) renvoie des donnéesd’autorisation valides sur l’utilisateur sans qu’il soit nécessaire de saisir unmot de passe.

Chapitre 3. Configuration avancée du serveur 65

Page 86: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

5. Pendant l’authentification pour changement d’utilisateur, WebSEAL vérifie leséléments suivants : Les groupes Access Manager su-admins, securitygroup etsu-excluded, afin de vérifier que le nom d’utilisateur fourni dans le formulairede changement d’utilisateur ne correspond pas à un membre de l’un de cesgroupes.

6. Lors de l’authentification de l’utilisateur spécifié, une nouvelle structure dedonnées de mémoire cache est créée et contient les données d’autorisation del’utilisateur.

7. Les données de mémoire cache de l’administrateur sont supprimées del’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 alorscette place. Désormais, l’entrée de cache contient l’ID de session d’origine del’administrateur et les données de cache de l’utilisateur (avec les donnéesd’autorisation). Les données d’autorisation contiennent également un nouvelID de session utilisateur qui peut être utilisé pour toutes les situations degestion 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 avantl’opération de changement d’utilisateur.

8. WebSEAL envoie un réacheminement au navigateur pour l’adresse URL dedestination fournie dans le formulaire de changement d’utilisateur.

9. La requête est traitée normalement à l’aide des données d’autorisation del’utilisateur et l’adresse URL est utilisée. L’administrateur peut effectuerd’autres requêtes. Toutes les décisions d’autorisation relatives à ces requêtessont 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 del’utilitaire Access Manager standard /pkmslogout.

11. Une fois la déconnexion effectuée, les données du cache de l’utilisateur sontsupprimées et les données de cache d’origine de l’administrateur (ainsi queses données d’autorisation) sont restaurées. L’administrateur revient à la paged’origine dans laquelle le formulaire de changement d’utilisateur a étédemandé. Le service d’autorisation utilise les données d’autorisation d’originede l’administrateur pour toutes les requêtes ultérieures.

Figure 15. Permutation des données de cache administrateur et utilisateur pendant unchangement d’utilisateur

66 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 87: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Activation du changement d’utilisateur : récapitulatifPour 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èrel’opération de changement d’utilisateur.

2. Servez-vous de l’utilitaire pdadmin pour ajouter des administrateurs au comptedu groupe su-admins.

3. Servez-vous de l’utilitaire pdadmin pour ajouter des utilisateurs au compte dugroupe su-excluded.

4. Vous pouvez également modifier le formulaire switchuser.html pour spécifierdes données préconfigurées (telles que la méthode d’authentification et l’URLde destination).

5. Vous avez également la possibilité de créer d’autres formulaires afin de validerou de traiter des données à soumettre à /pkmssu.form.

Configuration du formulaire HTML de changement d’utilisateurLe formulaire de changement d’utilisateur est défini dans la strophe [acnt-mgt] dufichier 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 quicontient le fichier suivant :[acnt-mgt}mgt-pages-root = lib/html/<LANG>

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 à vosbesoins en matière de présentation et de fonctionnalités. Il contient des requêtesrelatives 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-adminsou 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éecontenant une page d’accueil appropriée ou une page de confirmation dechangement d’utilisateur.

Chapitre 3. Configuration avancée du serveur 67

Page 88: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

v Méthode d’authentification

La méthode d’authentification détermine le type d’informations utilisé pourcréer les données d’autorisation de l’utilisateur. Vous pouvez configurer cettezone en zone de saisie masquée. Pour obtenir la liste des paramètres deméthodes d’authentification valides, reportez-vous aux notes ci-dessous.

Le formulaire de changement d’utilisateur se présente comme suit :

Notes relatives au formulaire de changement d’utilisateur :

v Ce formulaire est accessible uniquement aux membres du groupesu-admins.Aucune LCA n’est requise pour ce fichier. WebSEAL effectue uncontrôle codé en interne d’appartenance à un groupe. WebSEAL renvoie lemessage 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 sontdes données obligatoires.

v Les données obligatoires peuvent être générées dans le formulaire en tant quezones masquées.

v WebSEAL vérifie que toutes les données obligatoires sont présentes dans leformulaire 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-basu-formssu-certificatesu-token-cardsu-http-requestsu-cdsso

Ces paramètres de méthodes d’authentification spécifient la méthoded’authentification WebSEAL à utiliser.

v Les méthodes su-ba et su-forms sont mises en correspondance avec la méthoded’authentification su-password spécifiée dans le fichier de configurationwebseald.conf.

v Les données du formulaire de changement d’utilisateur sont soumises à l’URLd’action /pkmssu.form.

Figure 16. Formulaire de changement d’utilisateur

68 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 89: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Activation et exclusion d’utilisateurs pour le changementd’utilisateur

Seuls les administrateurs membres du groupe su-admins peuvent utiliser lafonction de changement d’utilisateur et recevoir le formulaire HTMLcorrespondant. La fonction de changement d’utilisateur est activée pour toututilisateur membre du groupe su-admins.

Les administrateurs peuvent changer d’utilisateur pour tout compte AccessManager, à l’exception des comptes qui appartiennent à certains groupes. Vouspouvez exlcure d’autres utilisateurs Access Manager du changement d’utilisateurvia leur leur appartenance au groupe su-excluded. Par ailleurs, les membres dugroupe Access Manager securitygroup sont exclus de la fonctionnalité dechangement d’utilisateur. En règle générale, sec_master et les processus AccessManager sont membres de securitygroup.

Pendant le changement d’utilisateur, WebSEAL effectue des contrôles sur les troisgroupes. Vous ne pouvez pas “changer pour” une personne membre des groupessu-admins, su-excluded ou securitygroup.

Configuration de la méthode d’authentification parchangement 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’autorisationreprésentant le “nouvel” utilisateur, sur la base du nom d’utilisateur et de laméthode d’authentification spécifiés, sans qu’il soit nécessaire de saisir un mot depasse. La méthode d’authentification CDAS personnalisée doit remplir la mêmecondition.

Les méthodes d’authentification par changement d’utilisateur doivent êtrespécifiées dans la strophe [authentication-mechanisms] stanza du fichier deconfiguration webseald.conf. Les méthodes d’authentification suivantes sont prisesen charge :[authentication-mechanisms]#su-password = <su-password-library>#su-token-card = <su-token-card-library>#su-certificate = <su-certificate-library>#su-http-request = <su-http-request-library>#su-cdsso = <su-cdsso-library>

Access Manager contient une bibliothèque unique de changement d’utilisateur quipeut être utilisée pour activer l’une des méthodes d’authentification au sein d’unenvironnement par défaut non personnalisé. La bibliothèque de changementd’utilisateur diffère des bibliothèques d’authentification standard. La bibliothèquespécifie une méthode d’authentification qui extrait du formulaire de changementd’utilisateur l’identité de l’utilisateur et renvoie des données d’autorisation validespour 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 Managers’appelle :

Solaris libsuauthn.so

AIX libsuauthn.a

HP-UX libsuauthn.sl

Windows suauthn.dll

Chapitre 3. Configuration avancée du serveur 69

Page 90: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

La fonction de changement d’utilisateur prend également en charge les méthodesd’authentification CDAS personnalisées. Cette prise en charge est importante carun CDAS personnalisé offre souvent des informations complémentaires auxdonnées d’autorisation de l’utilisateur.

Il vous incombe d’écrire un CDAS de changement d’utilisateur personnalisé quiassure l’émulation du comportement de votre CDAS existant tout en prenant encharge l’obligation de renvoyer des données d’autorisation sans saisie de mot depasse. Reportez-vous au document IBM Tivoli Access Manager WebSEAL Developer’sReference.

Chaque bibliothèque d’authentification par changement d’utilisateur doit porter unnom unique, même lorsque la bibliothèque par défaut (libsuauthn) est utiliséepour plusieurs méthodes d’authentification.

ExempleDans l’exemple suivant (pour plate-forme Solaris), un environnement existantpossè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é dechangement d’utilisateur pour ces trois méthodes d’authentification. Troisparamètres d’authentification supplémentaires doivent être activés dans le fichierde configuration webseald.conf pour le changement d’utilisateur. En outre, unenouvelle bibliothèque CDAS personnalisée doit être créée afin d’émuler le CDASactuel à jeton et de prendre en charge les besoins de l’authentification parchangement d’utilisateur :[authentication-mechanisms]passwd-ldap = /opt/PolicyDirector/lib/libldapauthn.socert-ssl = /opt/PolicyDirector/lib/libsslauthn.sotoken-cdas = /opt/PolicyDirector/lib/libcustom.sosu-password = /opt/PolicyDirector/lib/libsuformauthn.sosu-certificate = /opt/PolicyDirector/lib/libsucert.sosu-token-card = /opt/PolicyDirector/lib/libsucustom.so

Souvenez-vous que la méhode d’authentification su-forms figurant dans leformulaire de changement d’utilisateur est mappée au paramètre de méthoded’authentification su-password du fichier de configuration webseald.conf . Deplus, la bibliothèque libsuauthn a été renommée pour les méthodesd’authentification par formulaire et par certificat.

Configuration d’une méthode de changement d’utilisateurCDAS

Une méthode d’authentification existante renvoie souvent des informationscomplémentaires sur l’utilisateur incorporé aux données d’autorisation del’utilisateur. Si vous utilisez la fonctionnalité de changement d’utilisateur dans unenvironnement identique, il vous incombe d’écrire un CDAS de changementd’utilisateur personnalisé qui assure l’émulation du comportement de votre CDASexistant tout en prenant en charge l’obligation de renvoyer des donnéesd’autorisation sans saisie de mot de passe.

70 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 91: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

L’API CDAS d’Access Manager fournit un ensemble de composants d’identité quipeuvent être utilisés pour la transmission des informations sur l’authentificationdes clients à la bibliothèque partagée CDAS de changement d’utilisateur. Cesinformations 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 sontaccessibles via l’utilisation de la fonction xnvlist_get().

Les composants d’identité appropriés aux CDAS de changement d’utilisateurincluent notamment :xauthn_su_methodxauthn_admin_namexauthn_admin_credxauthn_existing_credxauthn_usernamexauthn_qopxauthn_ipaddrxauthn_browser_info

Les composants d’identité xauthn_browser_info, xauthn_qop et xauthn_ipaddrreprésentent ceux de l’administrateur, et non ceux de l’utilisateur. Ces données sontfournies pour tout CDAS devant effectuer des validations supplémentaires ducompte 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’sReference.

Impact sur les autres fonctionnalités WebSEAL

Impact sur la configuration du délai d’expiration du cache desessionLa 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élaisd’inactivité et de durée de vie sont associés à l’entrée du cache de session del’administrateur et non aux données de mémoire cache qui sont modifiées au coursde toute opération de changement d’utilisateur.

Le délai d’inactivité est encore réinitialisé pendant que l’administrateur effectuedes requêtes pour le “changement” d’utilisateur. Lorsque ce dernier termine lasession de changement d’utilisateur, l’inactivité est encore valide pour la sessionadministrateur qui est de nouveau établie.

La valeur de durée de vie n’est pas étendue par les opérations de changementd’utilisateur. Il est possible qu’un délai d’expiration d’entrée de cache de sessionexpire pendant une opération de changement d’utilisateur. Dans ce cas, le cache desession est supprimé et l’administrateur est déconnecté. L’administrateur doit alorss’authentifier de nouveau et recommencer l’opération de changement d’utilisateur.

Insertion de niveaux d’authentification avancéeLa spécification de bibliothèque partagée peut accepter des argumentssupplémentaires sous la forme suivante :<bibliothèque>&<arg1><arg2> .... <argx>

Chapitre 3. Configuration avancée du serveur 71

Page 92: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Vous pouvez spécifier des niveaux d’authentification avancée à l’aide de l’option –lsuivie du numéro de niveau. Par exemple :su-password = /opt/PolicyDirector/lib/libsuformauthn.so& -l 1su-certificate = /opt/PolicyDirector/lib/libsucert.so& -l 0su-token-card = /opt/PolicyDirector/lib/libsucustom.so& -l 2

Remarque : Pour cette version d’Access Manager, l’administrateur doit connaître lemot de passe de l’utilisateur pour que l’authentification avancéepuisse aboutir.

Support de nouvelle authentificationLa fonctionnalité WebSEAL de nouvelle authentification est reconnue parl’opération de changement d’utilisateur. Si une nouvelle authentification est requisependant une opération de changement d’utilisateur, l’administrateur doits’authentifier en tant que “nouvel” utilisateur.

Remarque : Pour cette version d’Access Manager, l’administrateur doit connaître lemot de passe du “nouvel” utilisateur afin de s’authentifier de nouveauavec succès.

Support pour la gestion des sessions utilisateursL’opération de changement d’utilisateur prend en charge la gestion des sessionsutilisateurs. L’administrateur possède un ID unique de session utilisateur. En outre,pendant une session de changement d’utilisateur, un ID unique de sessionutilisateur existe pour le “nouvel” utilisateur. Les tâches de fin de sessionutilisateur et de fin de toutes les sessions utilisateurs s’effectuent comme prévu.

Support de tag-valueL’option tag-value, souvent utilisée par un module CDAS, est reconnue et prise encharge par la fonctionnalité de changement d’utilisateur.

Audit de l’administrateur pendant le changement d’utilisateurIl est possible d’effectuer un audit relatif à l’administrateur pendant une opérationde changement d’utilisateur. La fonctionnalité de changement d’utilisateur permetd’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 = <nom_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 WebSEALcôté serveur

Principes de baseDans les versions antérieures de WebSEAL qui utilisaient l’authentification parformulaires, 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 foisl’authentification effectuée avec succès, WebSEAL envoyait un réacheminementHTTP au navigateur qui contenait cette adresse URL. Le navigateur faisait alorssuivre ce réacheminement vers l’emplacement d’origine de la ressource.

La limitation de cette mise en oeuvre est apparue lorsque, par exemple, unerequête POST était interrompue par le délai d’expiration d’une session, ce quiexigeait une nouvelle authentification. Etant donné que WebSEAL ne mettait enmé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

Page 93: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

(incluant la METHODE et le corps du message) étaient perdues au cours duréacheminement HTTP. L’utilisateur devait alors générer de nouveau la requêtePOST.

Désormais, WebSEAL met en mémoire cache un ensemble plus complet dedonnées de requêtes et utilise ces données pour générer de nouveau la requête aucours du réacheminement HTTP si la nécessité d’une nouvelle authentificationinterrompt le traitement de la requête. Cette solution est particulièrementavantageuse pour les requêtes POST et PUT, car ces types de requêtes peuventinclure un grand nombre de zones d’information.

Flux du processus de mise en mémoire cache côté serveurLorsque 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érerde nouveau la requête au cours du réacheminement HTTP effectué à la suite d’unprocessus de nouvelle authentification. Les données de requêtes mises en mémoirecache incluent l’adresse URL, la METHODE, le corps du message, les chaînesd’interrogation, ainsi que tous les en-têtes HTTP (y compris les cookies). Cesdonnées sont stockées temporairement dans la mémoire cache WebSEAL desessions/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 transmetce réacheminement vers l’adresse URL d’origine contenue dans ce dernier.WebSEAL intercepte le réacheminement et reconstitue la requête à l’aide desdonnées de la mémoire cache. La requête reconstituée est transmise à l’adresseURL de destination.

Le schéma suivant illustre un flux de processus de mise en mémoire cache derequê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’unformulaire généré par CGI. WebSEAL crée et met en mémoire cache un ID desession 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 etl’ID de session des données d’autorisation de l’utilisateur.

4. L’utilisateur soumet, s’il le souhaite, le formulaire rempli (POST). WebSEAL netrouve aucune entrée de mémoire cache pour l’utilisateur, crée une nouvellemémoire cache et place temporairement dans cette mémoire les informationscomplètes contenues dans la requête POST.

5. Etant donné que WebSEAL ne trouve aucune donnée d’autorisation pour cetutilisateur, celui-ci est obligé de s’authentifier. WebSEAL envoie un formulairede 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ésormaisles données d’autorisation de l’utilisateur, ainsi que la requête mise en mémoirecache.

7. WebSEAL renvoie un réacheminement HTTP au navigateur qui contientl’adresse URL de la ressource objet de la requête d’origine.

Chapitre 3. Configuration avancée du serveur 73

Page 94: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

8. Le navigateur suit le réacheminement (GET). WebSEAL intercepte leréacheminement et reconstitue la requête d’origine (formulaire) à l’aide desdonnées POST placées en mémoire cache. La requête restaurée (formulaire) esttransmise à l’URL.

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 pourl’authentification WebSEAL par formulaires, vous pouvez spécifier des limites detaille pour les requêtes que WebSEAL place en mémoire cache. Les paramètresrequest-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ètrerequest-body-max-read lorsque vous spécifiez la valeur du paramètrerequest-max-cache.

Figure 17. Exemple de flux de processus de mise en mémoire cache côté serveur

74 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 95: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

request-body-max-read

Le paramètre request-body-max-read spécifie la taille maximale du corps dumessage (exprimée en octets) que WebSEAL place en mémoire cache pour chaquerequête. Ce paramètre a un impact sur les types de requêtes qui contiennent desdonnées de corps de message (comme par exemple les requêtes POST et PUT). Parexemple :[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 contenirune valeur correcte pour le paramètre request-body-max-read et pour la taille detous les autres composants de la requête. Par exemple, si vous spécifiez 2048 octetscomme limite de mémoire cache pour les corps de messages de requêtes et quevous spécifiez une taille maximale égale à 4096 octets pour tous les autrescomposants de requête (tels que les en-têtes et les cookies), définissez les élémentssuivants :1. Définissez request-body-max-read = 20482. Définissez request-max-cache = 2048 + 4096 = 6144

Si la valeur de request-body-max-read ou de request-max-cache est dépasséependant une requête, WebSEAL abandonne le processus de mise en mémoire cachede la requête, puis renvoie un message d’erreur au navigateur (La mise enantémémoire de la requête a échoué) et consigne ce message d’erreur dans lefichier 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 limitesv 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êtePOST est contenue dans le corps du message de requête.

v La valeur de request-body-max-read affecte également l’authentification parformulaires grâce à la limite fixée pour la taille des données POST traitées aucours de l’authentification.

v Les paramètres request-body-max-read et request-max-cache protègentWebSEAL des types d’attaque de refus d’accès aux services qui obligentWebSEAL à placer davantage de données en mémoire cache qu’il ne peut engérer.

v La mise en mémoire cache de requêtes côté serveur ne fonctionne correctementque si la valeur du délai d’expiration de la session utilisateur est atteintependant 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 unelimitation des capacités du navigateur à manipuler la ressource. Le navigateurn’a pas d’informations sur la reconstitution du réacheminement HTTP parWebSEAL. Par conséquent, la fonction de rechargement/réactualisation dunavigateur et sa capacité de mise en mémoire cache peuvent s’en trouveraffectées.

Chapitre 3. Configuration avancée du serveur 75

Page 96: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Gestion des caractères codés UTF-8Conformément aux spécifications HTTP, les navigateurs sont limités au jeu decaractères qui peut être utilisé au sein d’une adresse URL. Cette plage comprendles caractères imprimables du jeu de caractères ASCII (entre le code hexadécimal0x20 et 0x7e). Pour les langues autres que l’anglais, et pour d’autres objectifs, lescaractères qui ne font pas partie du jeu de caractères imprimables ASCII sontsouvent requises dans les adresses URL. Ces caractères peuvent être codés à l’aidedes caractères imprimables, à des fins de transmission et d’interprétation.

Il existe plusieurs méthodes différentes de codage utilisées pour la transmissiondes caractères situés hors de la plage autorisée. En dépit des spécifications HTTP, ilexiste également de nombreux serveurs Web sur le marché qui tolèrent simplementet acceptent les caractères situés hors de la plage légale. WebSEAL, en tant queproxy 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 lemarché 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 deconfiguration webseald.conf contrôle la façon dont WebSEAL interprète lesadresses URL envoyées par les navigateurs. Ce paramètre reconnaît les troisvaleurs suivantes :v yes

WebSEAL reconnaît uniquement le codage UTF-8 contenu dans les chaînesd’adresses URL et décode les informations présentes dans les jeux de caractèresnatifs (page de codes locale). Les autres techniques (telles que les jeux decaractè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. Lesautres techniques de codage sont acceptées.

v auto

WebSEAL tente de faire la distinction entre UTF-8 et les autres formes de codagede caractères (DBCS et Unicode). WebSEAL traite correctement tous les codagesUTF-8 construits correctement. Si le codage n’est pas de type UTF-8, il est alorstraité 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ésUTF-8. Ces caractères UTF-8 sont ensuite validés puis pris en compte lors de ladé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 pagede codes locale) et le contrôle de LCA est appliqué à l’adresse URL normalisée. Leparamétrage par défaut n’autorise pas les adresses URL contenant des caractèresUnicode ou DBCS se présentant sous la forme %uXXXX. Il s’agit là de laconfiguration recommandée pour WebSEAL.

Certaines applications et certains serveurs Web existants ne fonctionnent pascorrectement avec WebSEAL si le support UTF-8 est activé, car ces applicationsutilisent DBCS (comme par exemple Shift-JIS) dans l’adresse URL, ou encored’autres méthodes de codage.

76 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 97: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

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 lesadresses URL codées en UTF-8. Pour des raisons de sécurité, il est importantque WebSEAL interprète les adresses URL de la même façon que les serveursrelié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 dedefault-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 quipossèdent un compte valide au sein du domaine Access Manager.

2. Assurez-vous que le paramètre utf8-url-support-enabled porte la valeur pardéfaut “yes”.

3. Testez vos applications. Si elles fonctionnent correctement, utilisez ceparamétrage.

4. Si l’une des applications échoue et entraîne l’affichage de messages d’erreur detype “Requête incorrecte”, affectez au paramètre utf8-url-support-enabled lavaleur “no”, puis effectuez une nouvelle tentative. Si tout fonctionne bien, vouspouvez 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-sitesLes scripts inter-sites font référence à une technique utilisée pour rendre lesserveurs Web vulnérables via l’insertion de code malveillant dans les adresses URLde requêtes Web. WebSEAL contient une protection intégrée contre ce type devulnérabilité et permet d’affiner cette protection grâce à la configuration du filtragedes 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 cetteinsertion de code malveillant.

Principes de baseLes scripts inter-sites représentent un type spécifique de vulnérabilité des serveursWeb qui naît de l’insertion d’un code malveillant dans une requête URL de client.Par exemple (Javascript) :<script>malicious_code</script>

D’autres code de scripts peuvent entraîner une vulnérabilité :<OBJECT>,<APPLET> et <EMBED>. Lorsqu’un utilisateur clique sur un lien contenant le codemalveillant (ou entre directement l’adresse URL correspondante), le script estexécuté lorsque le code HTML est lu par le navigateur de l’utilisateur.

Par exemple, une agression peut survenir lorsqu’un utilisateur clique sur un lienqui contient l’adresse URL suivante :https://<hôte_webseal>/<script>code_malveillant</script>

Chapitre 3. Configuration avancée du serveur 77

Page 98: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Dans cet exemple, l’objet n’est pas trouvé et WebSEAL répond en affichant lemessage d’erreur HTML 404 “Page introuvable”. Ce message d’erreur peut inclurel’adresse URL qui contient le code Javascript malveillant. Le navigateur interprètel’adresse URL et exécute le script.

Pour plus d’informations sur les méthodes de scripts inter-sites et sur les mesurespréventives générales, reportez-vous à l’avis du CERT ci-après :

http://www.cert.org/advisories/CA-2000-02.html

Configuration du filtrage des chaînes d’adresses URLLe problème des scripts inter-sites — et du code malveillant en général — est traitéde deux façons :

WebSEAL place désormais les adresses URL réacheminées entre crochets (<, >). Lecodage peut permettre d’empêcher une interprétation normale des scripts par lenavigateur.

En outre, vous pouvez désormais ajouter une nouvelle strophe au fichier deconfiguration webseald.conf. Cette strophe ([illegal-url-substrings]) peut contenirdes paramètres qui spécifient un ou plusieurs fragments de chaînes. Par exemple :[illegal-url-substrings]substring = <scriptsubstring = <appletsubstring = <embed

Si WebSEAL détecte un fragment de chaîne configurée dans l’adresse URLdemandée, l’URL n’est pas acceptée car elle est jugée illégale. WebSEAL renvoiealors le message d’erreur 400 (“Requête incorrecte”).

Cette méthode, d’une grande souplesse, permet de gérer les modèles d’attaquesfutures grâce à l’ajout de valeurs de sous-chaînes supplémentaires.

Par défaut, WebSEAL filtre les chaînes contenant <script. Il est inutile d’ajoutermanuellement la strophe [illegal-url-substrings] pour filtrer cette chaîne enparticulier. Toutefois, lorsque vous devez effectuer un filtrage supplémentaire, vousdevez créer la strophe et répertorier individuellement toutes les sous-chaînes,comme dans l’exemple ci-dessus.

Vous pouvez désactiver totalement la fonction de filtrage de chaînes URL (ycompris les valeurs par défaut) en insérant une strophe [illegal-url-substrings]vide dans le fichier de configuration webseald.conf.

Remarques fonctionnelles :v Les recherches de sous-chaînes s’effectuent sans distinction des minuscules et

des majuscules.v Le filtrage des sous-chaînes inclut des caractères à plusieurs octetsv Cette méthode protège les serveurs reliés par jonction

78 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 99: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Suppression de l’identité de serveursLes réponses des serveurs HTTP contiennent normalement l’identité et la versiondu serveur :content-type: text/htmldate: Tue, 05 Mar 2002 02:34:18 GMTcontent-length: 515server: WebSEAL/3.9.0last-modified: Thu, 21 Feb 2002 08:03:46 GMTconnection: close

Pour des raisons de sécurité, WebSEAL peut supprimer ces informations dans sesréponses aux clients. Pour supprimer l’identité des serveurs dans les réponses deserveurs HTTP, définissez le paramètre suppress-server-identity de la strophe[server] du fichier de configuration webseald.conf en lui attribuant la valeur “yes”:[server]suppress-server-identity = yes

La valeur par défaut est “no”.

Utilisation des statistiques WebSEALWebSEAL contient une série de modules logiciels qui, lorsqu’ils sont activés,peuvent surveiller l’activité d’un serveur spécifique et collecter les informationsrelatives à ces activités. Vous pouvez à tout moment afficher les statistiquesrassemblées depuis que ce module a été activé. De plus, vous pouvez acheminerces informations statistiques vers des fichiers journaux.

Lorsque vous affichez des informations statistiques, vous pouvez obtenir un“cliché” de celles-ci depuis que le module a été activé. Les informationsrassemblées par WebSEAL fournissent une vue relative de l’activité enregistrée. Siles statistiques sont rassemblées à des intervalles réguliers sur une période donnée,vous pouvez générer une vue graphique des relations relatives des activités duserveur.

Syntaxe de la commande pdadmin statsUtilisez la commande pdadmin stats pour gérer les composants de statistiques.Cette section décrit les opérations valides pour la commande pdadmin stats :

Commande pdadmin stats de basepdadmin> server taskwebseald-<instance commande > stats<>

Vous pouvez effectuer les tâches suivantes grâce à la commande pdadmin stats :

stats on Active dynamiquement les statistiques, par composant

stats off Désactive les statistiques par composant ou encore tous les composants àla fois

stats show Répertorie les composants activés

stats get Affiche les valeurs de statistiques actuelles par composant ou pour tousles composants à la fois

stats reset Réinitialise les valeurs de statistiques par composant ou pour tous lescomposants à la fois

stats list Répertorie tous les composants de statistiques disponibles

Chapitre 3. Configuration avancée du serveur 79

Page 100: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Activation dynamique des statistiquesVous pouvez activer dynamiquement les statistiques grâce à l’utilisation de lacommande pdadmin stats on ou (de façon statique) en configurant certainsparamètres du fichier de configuration webseald.conf.

Utilisez la commande pdadmin stats on pour activer la collecte de statistiques etpour en définir la fréquence, le comptage et la destination pour un composant.stats on <composant>[<interval> [<count>]] [<logagent>]

Argument Description

component Nom du composant de statistiques. Obligatoire. Les statistiques sontrassemblées dans la mémoire WebSEAL associée à ce composant. Lesstatistiques relatives à ce composant peuvent également êtreenregistrées dans un fichier journal via la spécification des argumentsfacultatifs de cette commande.

interval Intervalle de temps entre les rapports statistiques. Cet argument estfacultatif et entraîne la consignation des statistiques dans un fichierjournal. Lorsque cette option est spécifiée, les statistiques sont envoyéespar défaut au fichier journal du serveur WebSEAL. Vous pouvezspécifier un autre emplacement à l’aide de l’argument logagent. Sil’argument interval n’est pas spécifié, les statistiques ne sont pasenvoyées à un fichier journal. Toutefois, le composant de statistiques esttoujours activé. Vous pouvez à tout moment obtenir des rapports defaçon dynamique grâce à l’utilisation de la commande pdadmin statsget.

count Nombre de rapports ayant été envoyés dans un fichier journal. Cetargument est facultatif et nécessite que l’argument interval soit spécifié.Si l’argument interval est spécifié sans que l’argument count le soit, ladurée du rapport est infinie. Une fois que la valeur affectée à cetargument est atteinte, la consignation dans un fichier journal s’arrête.Toutefois, le composant de statistiques est toujours activé. Vous pouvezà tout moment obtenir des rapports de façon dynamique grâce àl’utilisation de la commande pdadmin stats get.

logagent (Facultatif) Permet de spécifier une destination pour les informationsstatistiques rassemblées pour le composant spécifié. Pour plusd’informations sur cette configuration, reportez-vous au chapitreconsacré à la “ journalisation d’événements” du document IBM TivoliAccess Manager - Guide d’administration.

Remarque : Par défaut, les composants pdweb.threads, pdweb.doccache etpdweb.jmt sont toujours activés et ne peuvent pas être désactivés.

Voir aussi la section «Activation statique des statistiques à l’aide de lajournalisation d’événements» à la page 88.

Exemple 1 :

Cet exemple illustre l’activation du composant pdweb.http. Etant donné quel’option interval n’est pas spécifiée, vous ne pouvez obtenir d’informationsstatistiques pour ce composant que de façon dynamique, grâce à l’utilisation de lacommande pdadmin stats get.pdadmin> server task webseald-<instance> stats on pdweb.http

80 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 101: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Exemple 2 :

Cet exemple illustre l’activation du composant pdweb.http. Etant donné quel’argument interval est spécifié, les informations sont envoyées (par défaut) aufichier journal standard de WebSEAL. Les arguments interval et count entraînentl’accumulation, dans le fichier journal, de 100 entrées représentant les rapportsstatistiques séparés de 20 secondes.pdadmin> server task webseald-<instance> stats on pdweb.http 20 100

Exemple 3 :

Cet exemple illustre l’activation du composant pdweb.http. L’argument logagentutilise la configuration de la journalisation d’événements pour spécifier un fichierde destination pour les informations statistiques. L’argument interval (sans valeuraffectée à l’argument count) envoie toutes les 20 secondes des informationsstatistiques pour ce composant au fichier journal, et cela indéfiniment.L’augmentation de taille du fichier journal est contrôlée par le paramètrerollover_size . Pour plus d’informations sur la configuration de la journalisationd’événements, reportez-vous au chapitre consacré à la “ journalisationd’événements” du document IBM Tivoli Access Manager - Guide d’administration.pdadmin> server task webseald-<instance> stats on pdweb.http 20 filepath=/tmp/jmt-stats.log,rollover_size=-1,flush_interval=20

Exemple 4 :

Cet exemple illustre une limitation dynamique de la gestion des statistiques. Lapremière commande active le composant pdweb.http et achemine les informationsstatistiques vers le fichier A.log. La deuxième commande tente d’activer undeuxième fichier journal (B.log). Toutefois, cette action entraîne en réalité ladésactivation de A.log en même temps que l’activation de B.log.pdadmin> server task webseald-<instance> stats on pdweb.http 20 file path=/tmp/A.logpdadmin> server task webseald-<instance> stats on pdweb.http 20 file path=/tmp/B.log

Désactivation des statistiquesDésactive la collecte des statistiques par composant ou encore pour tous lescomposants à la foisstats off [<composant>]

Exemple :pdadmin> server task webseald-<instance> stats off pdweb.sescache

Remarque : Par défaut, les composants pdweb.threads, pdweb.doccache etpdweb.jmt sont toujours activés et ne peuvent pas être désactivés.

Affichage des composants statistiques activésRépertorie tous les composants statistiques activés ou un composant spécifiqueactivé. Si l’un des composants spécifiés n’est pas activé, aucun résultat n’est affiché.stats show [<composant>]

Exemple 1 :pdadmin> server task webseald-<instance> stats showpdweb.authnpdweb.doccachepdweb.jmtpdweb.sescachepdweb.threads

Chapitre 3. Configuration avancée du serveur 81

Page 102: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Exemple 2 :pdadmin> server task webseald-<instance> stats show pdweb.authnpdweb.authn

Obtention de valeurs statistiques de façon dynamiqueAffiche les valeurs actuelles des statistiques rassemblées par un composant ou partous les composants activés.stats get [<composant>]

Exemple :pdadmin> server task webseald-<instance> stats get pdweb.threadsactive:4total:50

Réinitialisation des valeurs statistiquesRéinitialise les valeurs rassemblées par un composant activé ou par tous lescomposants activés à la fois.stats reset [<composant>]

Exemple :pdadmin> server task webseald-<instance> stats reset pdweb.threads

Liste de tous les composants statistiques disponiblesDresse la liste de tous les composants disponibles afin de collecter des statistiqueset de constituer des rapports.stats list

Exemple :pdadmin> server task webseald-<instance> stats listpd.ras.stats.monitorpd.log.EventPool.queuepd.log.file.clfpd.log.file.refpd.log.file.agentpdweb.authnpdweb.authzpdweb.httppdweb.httpspdweb.threadspdweb.jmtpdweb.sescachepdweb.doccachepdweb.jct.1

Composants statistiques et types d’activitésCette section décrit les composants statistiques disponibles pour IBM Tivoli AccessManager WebSEAL.

Composant pdweb.authnLe composant de statistiques pdweb.authn collecte les informations relatives àl’authentification WebSEAL. Le tableau suivant décrit les types d’informationsdisponibles :

Type Description

pass (succès) Nombre total d’authentifications effectuées avec succès

fail (échecs) Nombre total d’échecs d’authentification

82 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 103: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Type Description

pwd exp (motde passe àexpiration)

Nombre total de tentatives d’authentification effectuées avec un mot depasse arrivé à expiration

max(maximum)

Durée maximale d’un processus d’authentification simple

avg (moyenne) Durée moyenne d’un processus d’authentification simple

total (duréetotale)

Durée totale du traitement d’authentification

Exemple :pdadmin> server task webseald-<instance> stats get pdweb.authnpass : 2fail : 1pwd exp : 0max : 0.178avg : 0.029total : 0.382

Composant pdweb.authzLe composant de statistiques pdweb.authz collecte des informations relatives àl’autorisation WebSEAL. Le tableau suivant décrit les types d’informationsdisponibles :

Type Description

pass (succès) Nombre total de requêtes d’autorisation effectuées avec succès (nombrede ressources auxquelles il a été possible d’accéder)

fail (échecs) Nombre total d’échecs de requêtes d’autorisation

Exemple :pdadmin> server task webseald-<instance> stats get pdweb.authzpass : 2fail : 1

Composant pdweb.httpLe composant de statistiques pdweb.http collecte les informations relatives auxcommunications HTTP de WebSEAL. Le tableau suivant décrit les typesd’informations disponibles :

Type Description

reqs (requêtes) Nombre total de requêtes HTTP reçues

max-worker(maximumpour une unitéd’exécution)

Durée maximale consommée par une unité d’exécution d’agents simplepour traiter une requête HTTP

total-worker(total desunitésd’exéution)

Durée totale consommée par toutes les unités d’exécution d’agents quitraitent ces requêtes HTTP

max-webseal(maximumwebseal)

Durée maximale consommée pour traiter une requête HTTP simple(mesurée au sein de l’unité d’exécution d’agents, une fois que les en-têtesde requêtes ont été lus et après élimination du temps système deconfiguration des connexions)

Chapitre 3. Configuration avancée du serveur 83

Page 104: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Type Description

total-webseal(durée totalewebseal)

Durée maximale consommée pour traiter toutes les requêtes HTTP(mesurées au sein des unités d’exécution d’agents, une fois que lesen-têtes de requêtes ont été lus et après élimination du temps système deconfiguration des connexions)

Exemple :pdadmin> server task webseald-<instance> stats get pdweb.httpreqs : 0max-worker : 0.000total-worker : 0.000max-webseal : 0.000total-webseal : 0.000

Composant pdweb.httpsLe composant de statistiques pdweb.https collecte les informations relatives auxcommunications HTTP de WebSEAL. Le tableau suivant décrit les typesd’informations disponibles :

Type Description

reqs (requêtes) Nombre total de requêtes HTTPS reçues

max-worker(maximumunitésd’exécution)

Durée maximale consommée par une unité d’exécution d’agents simplepour traiter une requête HTTPS

total-worker(total unitésd’exécution)

Durée totale consommée par toutes les unités d’exécution d’agents quitraitent ces requêtes HTTPS

max-webseal(maximumwebseal)

Durée maximale consommée pour traiter une requête HTTPS simple(mesurée au sein de l’unité d’exécution d’agents, une fois que les en-têtesde requêtes ont été lus et après élimination du temps système deconfiguration des connexions)

total-webseal(durée totalewebseal)

Durée maximale consommée pour traiter toutes les requêtes HTTPS(mesurées au sein des unités d’exécution d’agents, une fois que lesen-têtes de requêtes ont été lus et après élimination du temps système deconfiguration des connexions)

Exemple :pdadmin> server task webseald-<instance> stats get pdweb.httpsreqs : 0max-worker : 0.000total-worker : 0.000max-webseal : 0.000total-webseal : 0.000

84 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 105: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Composant pdweb.threadsLe composant de statistiques pdweb.threads collecte les informations relatives àl’activité des unités d’exécution d’agents WebSEAL. Ce composant est toujoursactivé par défaut et ne peut pas être désactivé. Le tableau suivant décrit les typesd’informations disponibles :

Type Description

active (unitésactives)

Nombre total d’unités d’exécution d’agents actives chargées de gérer lesrequêtes

total (totald’unités)

Nombre total d’unités d’exécution d’agents configurées

Exemple :pdadmin> server task webseald-<instance> stats get pdweb.threadsactive : 0total : 50

Composant pdweb.jmtLe composant de statistiques pdweb.jmt collecte les informations relatives à latable de mappage des jonctions WebSEAL. Ce composant est toujours activé pardéfaut et ne peut pas être désactivé. Le tableau suivant décrit les typesd’informations disponibles :

Type Description

hits (succès) Nombre total de requêtes ayant requis un mappage d’adresses URL via latable de mappage des jonctions

Exemple :pdadmin> server task webseald-<instance> stats get pdweb.jmthits : 5

Composant pdweb.sescacheLe composant de statistiques pdweb.sescache collecte les informations relatives àl’activité de la mémoire cache de sessions/données d’autorisation de WebSEAL. Letableau suivant décrit les types d’informations disponibles :

Type Description

hit (succès) Nombre de requêtes ayant abouti à l’obtention d’un cache de session(c’est-à-dire que l’utilisateur possède une entrée de mémoire cache etqu’elle a été référencée avec succès)

miss (échecs) Nombre de requêtes n’ayant pas obtenu de cache de session

add (ajout) Nombre d’entrées ajoutées au cache de session

del(suppression)

Nombre d’entrées supprimées du cache de session

inactive(inactivité)

Nombre d’entrées supprimées du cache en raison de l’expiration du délaid’inactivité

lifetime (duréede vie)

Nombre d’entrées supprimées du cache en raison de l’expiration de ladurée de vie

LRU expired(expirationLRU)

Nombre de fois que l’entrée de cache “Least Recently Used” (utilisationla moins récente) a expiré ou a été supprimée afin de libérer de l’espacepour une nouvelle entrée.

Chapitre 3. Configuration avancée du serveur 85

Page 106: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Exemple :pdadmin> server task webseald-<instance> stats get pdweb.sescachehit : 0miss : 0add : 0del : 0inactive : 0lifetime : 0LRU expired : 0

Composant pdweb.doccacheLe composant de statistiques pdweb.doccache collecte les informations relatives àl’activité de mise en mémoire cache de documents WebSEAL. Ce composanttransmet un rapport statistique pour tous les types MIME activés dans la strophe[content-cache] du fichier de configuration webseald.conf. Ce composant esttoujours activé par défaut et ne peut pas être désactivé.

Le tableau suivant décrit les types d’informations globales disponibles pour tousles types MIME :

Type Description

General Errors (erreursgénérales)

Nombre d’erreurs indiqué par le composant pdweb.doccache encas d’échec d’allocation de mémoire, d’initialisation ou de valeursd’en-tête de type MIME incorrectes.

Uncachable (mise encache impossible)

Nombre d’instances en cas d’absence de cache défini pour le typeMIME du document à mettre en mémoire cache

Pending Deletes(suppressions en cours)

Nombre d’entrées à supprimer mais qui sont toujours utilisées

Pending Size (tailleactuelle)

Nombre d’octets utilisés par les entrées, qui doivent êtresupprimés mais qui sont toujours en cours d’utilisation

Misses (échecs) Nombre de recherches d’une adresse URL dans le cache dedocuments n’ayant pas abouti. Lorsqu’un document placé enmémoire cache est trouvé, cela élimine le besoin d’accéder denouveau au document réel.

type MIME de cache Type MIME des documents contenus dans ce cache.

Statistiques relatives au type MIME de la mémoire cache :

Type Description

Max size (taillemaximale)

Taille maximale en octets de tous les documents contenus dans lamémoire cache.

Max entry size (taillemaximale d’entrée)

Taille maximale en octets d’un document placé en mémoire cache.Si la taille de ce document dépasse la valeur calculée en interne, ledocument n’est pas placé en mémoire cache.

Taille Taille totale, exprimée en octets, de tous les documents résidantactuellement dans la mémoire cache

Count (comptage) Nombre actuel d’entrées dans la mémoire cache.

Hits (succès) Nombre de recherches effectuées avec succès (documents trouvésdans la mémoire cache)

Stale hits (succèsavec purge)

Nombre de recherches effectuées avec succès, ayant permis detrouver une entrée trop ancienne qui a été purgée

86 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 107: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Type Description

Create waits (misesen attente)

Nombre de blocages successifs des requêtes relatives à undocument dont le contenu se trouvait à l’origine dans la mémoirecache

Cache no room(espace cacheinsuffisant)

Nombre de fois où un document valide pour la mise en mémoirecache ne peut pas être inséré dans celle-ci parce qu’un trop grandnombre d’entrées est créé en même temps

Additions (ajouts) Nombre de nouvelles entrées ayant pu être créées dans la mémoirecache

Aborts (abandons) Nombre de fois où la création d’une nouvelle entrée de mémoirecache est abandonnée en raison d’un problème ou d’un en-têtespécifiant que l’entrée ne doit pas être mise en mémoire cache

Deletes(suppressions)

Nombre d’entrées de mémoire cache supprimées car l’entrée aexpiré ou la création a été abandonnée

Updates (mises àjour)

Nombre d’entrées dont le délai d’expiration a été mis à jour

Too big errors(documents tropvolumineux)

Nombre de tentatives de mise en cache de documents dont la tailledépasse la taille maximale (par conséquent, ces documents nepeuvent pas être mis en mémoire cache)

MT errors (erreursMT)

Nombre de tentatives de création de la même entrée dans lamémoire cache par plusieurs threads (MT=Multi-Threading)

Exemple :pdadmin> server task webseald-<instance> stats get pdweb.doccacheGeneral Errors : 0Uncachable : 0Pending Deletes: 0Pending Size : 0Misses : 0Cache MIME type : text/htmlMax size : 2048000Max entry size : 128000Size : 0Count : 0Hits : 0Stale hits : 0Create waits : 0Cache no room : 0Additions : 0Aborts : 0Deletes : 0Updates : 0Too big errors : 0MT errors : 0

Composant pdweb.jct.#Le composant de statistiques pdweb.jct.# collecte des informations relatives auxjonctions WebSEAL. Le tableau suivant décrit les types d’informationsdisponibles :

Type Description

[/] Nom de jonction réel (figurant dans la commande sous forme denuméro)

reqs (requêtes) Nombre total de requêtes acheminées via cette jonction

max (duréemaximale)

Durée maximale consommée par une requête sur cette jonction

Chapitre 3. Configuration avancée du serveur 87

Page 108: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Type Description

total (duréetotale)

Durée totale consommée par les requêtes sur cette jonction

Exemple :pdadmin> server task webseald-<instance> stats get pdweb.jct.1[/]reqs : 0max : 0.000total : 0.000

Activation statique des statistiques à l’aide de lajournalisation d’événements

Les statistiques peuvent être configurées de façon dynamique dans la strophe[aznapi-configuration] du fichier de configuration webseald.conf grâce àl’utilisation du paramètre stats afin d’activer l’interface de statistiques et d’utiliserle paramètre de journalisation d’événements logcfg pour acheminer lesinformations statistiques vers une destination :[aznapi-configuration]stats = <composant>[interval [count]]logcfg =stats.<composant>:<destination>

Reportez-vous à la section «Activation dynamique des statistiques» à la page 80pour plus d’informations sur les arguments interval et count.

Pour plus d’informations sur la configuration de la journalisation d’événements,reportez-vous au chapitre consacré à la “ journalisation d’événements” dudocument IBM Tivoli Access Manager - Guide d’administration.

Exemple 1 :

Dans cet exemple, le paramètre stats active le composant et l’argument interval oucount. Le paramètre logcfg spécifie la destination de ces informations. Pour plusd’informations sur cette configuration, reportez-vous au chapitre consacré à la “journalisation d’événements” du document IBM Tivoli Access Manager - Guided’administration.[aznapi-configuration]stats = pdweb.jmt 20logcfg = stats.pdweb.jmt:file path=/tmp/jmt.log,rollover_size=-1,flush=20

Exemple 2 :

Dans cet exemple, plusieurs paramètres stats permettent d’activer plusieurscomposants. Plusieurs paramètres logcfg permettent de spécifier plusieursdestinations. Il est à noter que, contrairement au fonctionnement de la commandedynamique stats on, vous pouvez spécifier plusieurs fichiers de destination pour lemême composant. Pour plus d’informations sur la configuration de lajournalisation d’événements, reportez-vous au chapitre consacré à la “journalisation d’événements” du document IBM Tivoli Access Manager - Guided’administration.[aznapi-configuration]stats = pdweb.jmt 20stats = pdweb.authn 40

88 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 109: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

stats = pdweb.jct.1 50logcfg = stats.pdweb.jmt:file path=/tmp/jmtA.log,rollover_size=-1,flush=20logcfg = stats.pdweb.jmt:file path=/tmp/jmtB.log,rollover_size=-1,flush=20logcfg = stats.pdweb.authn:file path=/tmp/an.log,rollover_size=-1,flush=20logcfg = stats.pdweb.jct.1:file path=/tmp/jct.log,rollover_size=-1,flush=20

Utilisation de l’utilitaire de trace pour regrouper les actions deWebSEAL

L’utilitaire de trace permet de regrouper des informations relatives à des incidentset à des flux d’Access Manager Base et d’Access Manager WebSEAL. Cesinformations sont stockées dans un fichier et utilisées à des fins de débogage.L’utilitaire trace a pour but principal d’aider les membres du support technique àeffectuer le diagnostic de problèmes de fonctionnement du logiciel AccessManager.

En tant qu’utilisateur, certains composants de trace de WebSEAL peuvent vous êtreutiles. Toutefois, ils ne sont, pour la plupart, d’aucun secours sauf si vous devezdiagnostiquer des problèmes complexes avec l’aide du personnel de supporttechnique.

Remarque : Servez-vous avec prudence de l’utilitaire de trace. Il a été conçucomme un outil à utiliser sous la responsabilité du personnel dusupport technique. Les messages émis par l’utilitaire de trace sontparfois codés, non traduits, et risquent d’endommager sérieusementles performances système.

Syntaxe applicable aux commandes de base de l’utilitaire detrace

pdadmin> server taskwebseald-<instance> trace <commande>

Vous pouvez exécuter les tâches suivantes à l’aide de la commande pdadmintrace :

trace set Active le niveau de trace et la destination des messages de trace pour uncomposant et ses composants secondaires.

trace show Affiche le nom et le niveau de tous les composants de trace activés ou ducomposant spécifié

trace list Répertorie tous les composants de trace disponibles

Activation de l’utilitaire de traceUtilisez la commande pdadmin trace set pour activer la collecte d’informations detrace pour le composant et le niveau spécifiés.trace set <composant><niveau>[<log-agent>]

Argument Description

component Nom du composant de trace. Obligatoire. Les composants spécifiquesWebSEAL portent le préfixe “pdweb”.

Chapitre 3. Configuration avancée du serveur 89

Page 110: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Argument Description

level Niveau de rapport. Obligatoire. Le niveau d’argument spécifie leniveau de détail collecté par l’utilitaire de trace. La plage est compriseentre 1 et 9. Le niveau 1 représente le niveau le plus détaillé et leniveau 9 représente le niveau le moins détaillé.

logagent (Facultatif) Spécifie une destination pour les informations de tracecollectées pour le composant spécifié. Pour plus d’informations surcette configuration, reportez-vous au chapitre consacré à la “journalisation d’événements” du document IBM Tivoli Access Manager -Guide d’administration.

Affichage des composants de trace activésRépertorie tous les composants de trace activés ou un composant spécifique activé.Si l’un des composants spécifiés n’est pas activé, aucun résultat n’est affiché.trace show [<composant>]

Exemple :pdadmin> server task webseald-<instance> trace set pdweb.debug 2pdadmin> server task webseald-<instance> trace showpdweb.debug 2

Liste de tous les composants de trace disponiblesRépertorie le composant spécifié ou tous les composants disponibles pour collecterles informations de trace et en créer un rapport.trace list [<composant>]

Composants de trace de WebSEAL

pdweb.debugRemarque : le composant pdweb.debug peut uniquement être utilisé au niveau 2.

La commande ci-dessous permet d’appeler l’utilitaire de trace pour le composantpdweb.debug au niveau 2, puis d’acheminer le résultat vers un fichier à l’aide dela méthode de journalisation d’événements permettant de spécifier un agent dejournalisation.pdadmin> server task webseald-<instance> trace set pdweb.debug 2 \file path=/opt/pdweb/log/debug.log

Le résultat de cette commande, tel qu’il apparaît dans le fichier debug.log, peutpar exemple être le suivant :/src/wand/wand/log.c:277: -------------- Browser ===> PD --------------Thread_ID:17GET /test/index.html HTTP/1.1Host: bevanUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)Gecko/20011128 Netscape6/6.2.1Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css,*/*;q=0.1Accept-Language: en-usAccept-Encoding: gzip, deflate, compress;q=0.9Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66Keep-Alive: 300Connection: keep-alive---------------------------------------------------

/src/wand/wand/log.c:277: -------------- PD ===> BackEnd --------------

90 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 111: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Thread_ID:17GET /index.html HTTP/1.1via: HTTP/1.1 bevan:443host: mokum.santacruz.na.tivoli.comuser-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)Gecko/20011128 Netscape6/6.2.1accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css,*/*;q=0.1accept-language: en-usaccept-charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66accept-encoding: gzip, deflate, compress;q=0.9keep-alive: 300connection: close---------------------------------------------------

/src/wand/wand/log.c:277: -------------- PD <=== BackEnd --------------Thread_ID:17content-type: text/htmldate: Mon, 25 Mar 2002 19:48:32 GMTcontent-length: 7017etag: "0-1b69-3b688e48"last-modified: Thu, 02 Aug 2001 00:18:32 GMTserver: IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Win32)connection: closeaccept-ranges: bytes---------------------------------------------------

/src/wand/wand/log.c:277: -------------- Browser <=== PD --------------Thread_ID:17HTTP/1.1 200 Document followscontent-type: text/htmldate: Mon, 25 Mar 2002 19:48:32 GMTcontent-length: 7017etag: "0-1b69-3b688e48"last-modified: Thu, 02 Aug 2001 00:18:32 GMTserver: IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Win32)connection: closeaccept-ranges: bytes---------------------------------------------------

Chapitre 3. Configuration avancée du serveur 91

Page 112: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

92 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 113: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Chapitre 4. Règles de sécurité WebSEAL

Ce chapitre contient des informations expliquant comment configurer etpersonnaliser les règles de sécurité WebSEAL.

Index des rubriques :v «Règles de LCA spécifiques de WebSEAL»v «Limitation des tentatives de connexion» à la page 95v «Règle de renforcement de mot de passe» à la page 96v «Règles POP de renforcement d’authentification (authentification avancée)» à la

page 99v «Règles POP d’authentification basée sur réseau» à la page 105v «Niveau de protection des règles POP» à la page 107v «Gestion des utilisateurs non authentifiés (HTTP/HTTPS)» à la page 108

Règles de LCA spécifiques de WebSEALLes considérations de sécurité suivantes s’appliquent au conteneur /WebSEAL dansl’espace objet progégé :v L’objet WebSEAL commence la chaîne de l’héritage de la LCA pour la région

WebSEAL de l’espace objetv Si vous n’appliquez pas d’autre LCA explicite, cet objet définit (par

l’intermédiaire de l’héritage) les règles de sécurité de l’ensemble de l’espace Webv Le droit d’accès traverse est nécessaire pour l’accès à tout objet se trouvant en

aval de ce point

Pour plus d’informations sur les règles de LCA d’Access Manager, reportez-vousau document IBM Tivoli Access Manager Base Administrator’s Guide.

/WebSEAL/< hôte >L’entrée de sous-répertoire représente le début de l’espace Web pour une instancede serveur WebSEAL spécifique. Les considérations de sécurité suivantess’appliquent à cet objet :v Le droit d’accès traverse est nécessaire pour l’accès à tout objet se trouvant en

aval de ce pointv Si vous n’appliquez pas d’autre LCA explicite, cet objet définit (par

l’intermédiaire de l’héritage) les règles de sécurité de l’ensemble de l’espace objetsur cette machine

/WebSEAL/< hôte >/<fichier >Cette entrée de sous-répertoire représente l’objet ressource contrôlé au niveau del’accès HTTP. Les droits d’accès vérifiés dépendent de l’opération demandée.

© Copyright IBM Corp. 1999, 2002 93

Page 114: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Droits d’accès LCA WebSEALLe tableau ci-après décrit les droits d’accès LCA applicables à la région WebSEALde l’espace objet :

Opération Description

r read Affichage de l’objet Web

x execute Exécution du programme CGI.

d delete Suppression de l’objet Web de l’espace Web.

m modify Opération PUT sur un objet HTTP. (Place - publie - un objetHTTP dans l’espace objet WebSEAL.)

l list Requis par policy server pour générer une liste de répertoiresautomatisée de l’espace Web.

Ce droit d’accès gère aussi l’affichage ou non par un client dela liste du contenu du répertoire en l’absence de la page“index.html” par défaut.

g delegation Permet de sécuriser un serveur WebSEAL pour agir au nomd’un client et de transmettre cette requête à un serveurWebSEAL relié par jonction.

Règles de LCA WebSEAL par défautLes entrées centrales de la LCA WebSEAL default-webseal sont les suivantes :Group iv-admin TcmdbsvarxlGroup webseal-servers TgmdbsrxlUser sec_master TcmdbsvarxlAny-other TrxUnauthenticated T

A l’installation, cette LCA par défaut est associée au conteneur /WebSEAL dansl’espace objet.

Le groupe webseal-servers contient une entrée pour chaque serveur WebSEALdans le domaine sécurisé. Les droits d’accès par défaut permettent aux serveurs derépondre aux requêtes du navigateur.

Le droit d’accès traverse permet d’étendre l’espace Web représenté dans Web portalmanager. Le droit d’accès permet à Web portal manager d’afficher le contenu del’espace Web.

Caractères valides pour les noms de LCALes caractères suivants sont valides pour la création de noms de LCA :v A-Zv a-zv trait de soulignement (_)v trait d’union (-)v barre oblique inversée (\)v Tout caractère issu d’un jeu de caractères à double octets

Pour plus d’informations sur la création de noms de LCA, reportez-vous audocument IBM Tivoli Base Administrator’s Guide.

94 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 115: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Limitation des tentatives de connexionLe fait de limiter à trois les tentatives de connexion, option possible pour lesinstallations Access Manager basées LDAP, permet de spécifier un nombremaximal d’échecs de connexion (n) ainsi qu’un délai de verrouillage de pénalité(x), de sorte qu’après un nombre “n” d’échecs de connexion, un utilisateur n’a plusle droit d’essayer de se connecter pendant “x” secondes (ou le compte estdésactivé).

Cette règle de limitation des tentatives de connexion permet de protégerl’ordinateur contre des attaques par mot de passe. Elle crée une conditioncontraignant l’utilisateur à attendre un certain temps avant de renouveler d’autrestentatives de connexion, en cas d’échec. Par exemple, une règle peut définir que 3échecs de connexion sont suivis par une pénalité de 180 secondes. Ce type de règlepeut éviter les tentatives de connexion aléatoires générées par ordinateur plusieursfois par seconde.

Cette règle de connexion nécessite l’association de deux paramètres de lacommande pdadmin policy :v Nombre maximal de tentatives de connexion sans succès

policy set max-login-failures

v Pénalité pour dépassement du paramètre de tentatives de connexion sans succèspolicy set disable-time-interval

Le paramètre de pénalité peut inclure un intervalle de temps de verrouillage decompte ou une désactivation totale du compte.

Si une règle est définie (pour exemple) selon laquelle trois échecs de connexionsont suivis d’une pénalité de temps de verrouillage spécifique, une quatrièmetentative (correcte ou incorrecte) génère une page d’erreur indiquant que le compteest provisoirement non disponible par suite de la règle en matière de mot de passe.

L’intervalle de temps est spécifié en secondes (l’intervalle minimal recommandé estde 60 secondes).

Si la règle disable-time-interval est définie à “disable”, l’utilisateur n’a plus accès àson compte et l’attribut LDAP account valid correspondant à cet utilisateur estdéfini à “no”. Un administrateur active à nouveau le compte via le composant Webportal manager.

Remarque : La définition de disable-time-interval à “disable” entraîne unsupplément de temps système d’administration. Vous pouvezrencontrer des délais de réplication des informations de validité decompte (account valid) sur le serveur WebSEAL. Cette situationdépend de votre environnement LDAP. En outre, certaines mises enoeuvre LDAP risquent d’être confrontées à des baisses deperformances, suite à l’opération de mise à niveau de account valid.Ces raisons expliquent pourquoi il est conseillé d’utiliser un intervallede dépassement de délai.

Chapitre 4. Règles de sécurité WebSEAL 95

Page 116: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Syntaxe de commandeLes commandes pdadmin suivantes ne conviennent qu’à un registre LDAP.

Commande Description

policy set max-login-failures {<nombre>|unset} [-user <nom_utilisateur>]

policy get max-login-failures [-user <nom_utilisateur>]

Gère la règle contrôlant le nombre maximal de tentatives deconnexion ratées autorisées avant le déclenchement d’une pénalité.Cette commande dépend d’une pénalité définie dans la commandepolicy set disable-time-interval.

En tant qu’administrateur, vous pouvez appliquer cette règle à unutilisateur donné ou l’appliquer globalement à tous les utilisateursfigurant dans le registre LDAP.

La valeur par défaut est 10 tentatives.

policy set disable-time-interval {<nombre>|unset|disable} [-user <nom_utilisateur>]

policy get disable-time-interval [-user <nom_utilisateur>]

Gère la règle de pénalité contrôlant la durée pendant laquelle uncompte doit être désactivé si le nombre maximal d’échecs detentatives de connexion a été atteint.

En tant qu’administrateur, vous pouvez appliquer cette règle à unutilisateur donné ou l’appliquer globalement à tous les utilisateursfigurant dans le registre LDAP.

La valeur par défaut est 180 secondes.

Règle de renforcement de mot de passeLa règle de renforcement de mot de passe, disponible pour les installations AccessManager basées LDAP, fait référence aux stipulations établies à la constructiond’un mot de passe par les règles de stratégie de mot de passe. Access Managerfournit deux méthodes de contrôle des règles de renforcement de mot de passe :v Cinq commandes de règles de mot de passe pdadmin

v Un module d’authentification enfichable (Plugable Authentication Module, ouPAM) qui vous permet de personnaliser les règles de mot de passeReportez-vous au document IBM Tivoli Access Manager WebSEAL Developer’sReference.

Règle de renforcement de mot de passe définie par l’utilitairepdadmin

Les cinq attributs de renforcement de mot de passe mis en oeuvre par l’utilitairepdadmin sont les suivants :v Longueur minimale de mot de passev Nombre minimal de caractères alphabétiquesv Nombre minimal de caractères non alphabétiquesv Nombre maximal de caractères répétésv Espaces autorisés

96 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 117: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Ces règles sont mises en oeuvre lorsque vous créez un utilisateur avec pdadmin oule composant Web portal manager, et lorsqu’un mot de passe est modifié avecpdadmin, Web portal manager ou l’utilitaire pkmspasswd.

Syntaxe de commandeLes commandes pdadmin suivantes ne conviennent qu’à un registre LDAP.L’option unset désactive cet attribut de règle (autrement dit, la règle n’est pas miseen oeuvre).

Commande Description

policy set min-password-length {<nombre>|unset} [-user <nom_utilisateur>]

policy get min-password-length [-user <nom_utilisateur>]

Gère les règles contrôlant la longueur minimale de mot de passe.

En tant qu’administrateur, vous pouvez appliquer cette règle à unutilisateur donné ou l’appliquer globalement à tous les utilisateursfigurant dans le registre default.

La valeur par défaut est 8.

policy set min-password-alphas {<nombre>|unset} [-user <nom_utilisateur>]

policy get min-password-alphas [-user <nom_utilisateur>]

Gère les règles contrôlant le nombre minimal de caractèresalphabétiques autorisés dans un mot de passe.

En tant qu’administrateur, vous pouvez appliquer cette règle à unutilisateur donné ou l’appliquer globalement à tous les utilisateursfigurant dans le registre default.

La valeur par défaut est 4.

policy set min-password-non-alphas {<nombre>|unset} [-user <nom_utilisateur>]

policy get min-password-non-alphas [-user <nom_utilisateur>]

Gère les règles contrôlant le nombre minimal de caractères nonalphabétiques (numériques) autorisés dans un mot de passe.

En tant qu’administrateur, vous pouvez appliquer cette règle à unutilisateur donné ou l’appliquer globalement à tous les utilisateursfigurant dans le registre default.

La valeur par défaut est 1.

policy set max-password-repeated-chars {<nombre>|unset} [-user <nom_utilisateur>]

policy get max-password-repeated-chars [-user <nom_utilisateur>]

Gère les règles contrôlant le nombre maximal de caractères répétésautorisés dans un mot de passe.

En tant qu’administrateur, vous pouvez appliquer cette règle à unutilisateur donné ou l’appliquer globalement à tous les utilisateursfigurant dans le registre default.

La valeur par défaut est 2.

policy set password-spaces {yes|no|unset} [-user <nom_utilisateur>]

policy get password-spaces [-user <nom_utilisateur>]

Chapitre 4. Règles de sécurité WebSEAL 97

Page 118: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Commande Description

Gère les règles contrôlant le fait qu’un mot de passe peut contenirou non des espaces.

En tant qu’administrateur, vous pouvez appliquer cette règle à unutilisateur donné ou l’appliquer globalement à tous les utilisateursfigurant dans le registre default.

La valeur par défaut est unset.

Valeurs des paramètres de règles par défautLe tableau ci-après répertorie les paramètres de la règle et leurs valeurs pardéfaut :

Paramètre Valeur par défaut

min-password-length 8

min-password-alphas 4

min-password-non-alphas 1

max-password-repeated-chars 2

password-spaces non défini

Pour créer le comportement des règles de sécurité de mot de passe qui existaitdans les éditions précédentes d’Access Manager, appliquez l’option unset à chacundes cinq paramètres de mot de passe répertoriés ci-dessus.

Exemples de mots de passe valides et invalidesLe tableau ci-après illustre plusieurs exemples de mots de passe et les résultats desrègles sur la base des valeurs par défaut des cinq paramètres pdadmin :

Exemple Résultat

password Non valide : doit contenir au moins un caractère non alphabétique.

pass Non valide : doit contenir au moins 8 caractères.

passs1234 Non valide : contient plus de deux caractères répétés.

12345678 Non valide : doit contenir au moins quatre caractèresalphabétiques.

password3 Valide.

Valeurs globales et spécifiques d’un utilisateurLes commandes pdadmin policy peuvent être définies pour un utilisateurspécifique (avec l’option - user) ou globalement (en ne spécifiant pas l’option -user). Tout paramètre spécifique d’un utilisateur prévaut sur un paramètre globalde règle. Vous pouvez également désactiver (unset) un paramètre de règle, ce quisignifie que le paramètre ne contient aucune valeur. Toute règle dotée de l’optionunset n’est ni contrôlée ni mise en oeuvre.

Par exemple :pdadmin> policy set min-password-length 8

pdadmin> policy set min-password-length 4 -user matt

pdadmin> policy get min-password-length

98 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 119: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Longueur minimale d’un mot de passe : 8

pdadmin> policy get min-password-length -user matt

Longueur minimale d’un mot de passe : 4

(L’utilisateur matt est doté d’une règle de longueur minimale pour un mot depasse de 4 caractères ; tous les autres utilisateurs sont dotés d’une règle delongueur minimale pour un mot de passe de 8.)pdadmin> policy set min-password-length unset -user matt

(L’utilisateur matt est désormais soumis à la règle de longueur minimale globalepour un mot de passe de 8 caractères.)pdadmin> policy set min-password-length unset

(Tous les utilisateurs, y compris l’utilisateur matt, sont désormais soumis à unerègle de longueur minimale pour un mot de passe.)

Règles POP de renforcement d’authentification (authentificationavancée)

Vous pouvez utiliser des règles POP (Protected Object Policies) pour mettre enoeuvre certaines conditions d’accès ou certaines ressources spécifiques. Les règlesPOP de renforcement d’authentification permettent de contrôler l’accès aux objets,sur la base de la méthode d’authentification utilisée.

Vous pouvez vous servir de cette fonctionnalité, quelquefois appelée augmentationdu niveau d’authentification ou authentification avancée, pour vous assurer que lesutilisateurs ayant accès à des ressources plus confidentielles utilisent une méthoded’authentification renforcée. Cette condition peut être souhaitable si vous souhaitezvous protéger contre un accès incorrect à certaines ressources.

Par exemple, vous pouvez fournir un plus haut niveau de sécurité à une région(reliée au réseau par jonction) de l’espace Web en appliquant des règles POPd’authentification qui exigent un niveau d’authentification plus élevé que celuiutilisé par le client lors de son entrée initiale dans le domaine WebSEAL.

Les règles de renforcement d’authentification sont définies dans l’attribut deméthode d’authentification des extrémités IP des règles POP (IP EndpointAuthentication Method).

Configuration des niveaux pour une augmentation du niveaud’authentification

La première étape de la configuration d’un accès d’authentification spécifiqueconsiste à configurer les méthodes d’authentification prises en charge et àdéterminer l’ordre dans lequel ces méthodes doivent pouvoir paraître renforcées.

Tout client accédant à un serveur WebSEAL dispose d’un niveau d’authentification,comme “unauthenticated” ou “password”, qui indique par quelle méthode le clients’est authentifié pour la dernière fois auprès de WebSEAL.

Dans certaines situations, il peut se révéler nécessaire de mettre en oeuvre desniveaux d’authentification “de sécurité” minimaux, pour accéder à certainesresources. Par exemple, dans un environnement donné, l’authentification par

Chapitre 4. Règles de sécurité WebSEAL 99

Page 120: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

passcode de jeton peut être considérée comme plus sécurisée que l’authentificationpar nom d’utilisateur et mot de passe. Un autre environnement peut avoir desnormes différentes.

Au lieu de forcer les clients à redémarrer leurs sessions avec WebSEAL lorsqu’ilsne répondent pas au niveau voulu d’authentification, la méthode d’authentificationavancée donne aux clients une deuxième chance de s’authentifier à nouveau àl’aide de la méthode requise (niveau).

L’authentification avancée indique qu’un utilisateur ne reçoit pas immédiatementun message “de refus” lorsqu’il essaie d’accéder à une ressource nécessitant unniveau d’authentification “supérieur” à celui avec lequel ils se sont connectés. Ilreçoit à la place une invite d’authentification qui demande des informations pourla prise en charge du niveau d’authentification plus élevé. S’il est capable defournir ce niveau d’authentification, la requête originale est autorisée.

WebSEAL reconnaît trois méthodes (niveaux) d’authentification utilisables dans laméthode d’authentification renforcée :v unauthenticatedv passwordv token-card

Vous pouvez configurer les niveaux d’authentification dans la strophe[authentication-levels] du fichier de configuration webseald.conf. Initialement,seulement deux niveaux sont configurés :[authentication-levels]level = unauthenticatedlevel = password

Chaque méthode est dotée d’un index de niveau allant de 0 à 2 basé sur l’ordred’apparition des méthodes de la liste.v La méthode “unauthenticated” doit toujours être la première de la liste et

recevoir l’index de niveau 0.v Les méthodes suivantes peuvent être placées dans un ordre quelconque.

Voir la section «Notes et limites de l’authentification avancée» à la page 103.v Par défaut, la méthode “password” apparaît comme le niveau suivant (index de

niveau 1).v Il doit y avoir au moins deux entrées pour activer l’authentification renforcée.

Remarque : Pour des informations détaillées sur la configuration des méthodesd’authentification requises, reportez-vous au Chapitre 5,«Authentification WebSEAL» à la page 111.

Activation de l’authentification avancéeL’authentification avancée est mise en oeuvre au moyen de règles POP placées surles objets exigeant des droits d’accès basés sur une authentification. Vous utilisezl’attribut de méthode d’authentification des extrémités IP des règles POP.

La commande pdadmin pop modify set ipauth spécifie les réseaux autorisés et leniveau d’authentification requis dans l’attribut de méthode d’authentification desextrémités IP.

Les niveaux d’authentification configurés peuvent être liés à des plages d’adressesIP. Cette méthode est conçue pour assurer une souplesse dans la gestion. Si le

100 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 121: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

filtrage des utilisateurs par adresse IP n’est pas important, vous pouvez définir uneseule entrée pour anyothernw (any other network, ou tout autre réseau). Ceparamètre affectera tous les utilisateurs tentant un accès, quelle que soit l’adresseIP, et les oblige à s’authentifier au niveau spécifié. Il s’agit de la méthode de miseen oeuvre de l’authentification renforcée la plus répandue.

Syntaxe :pdadmin> pop modify<nom_pop> set ipauth anyothernw<index_niveau>

L’entrée anyothernw sert de plage de réseaux qui correspondront à tout réseaunon spécifié dans les objets protégés (POP). Cette méthode est utilisée pour créerune entrée par défaut qui peut soit refuser toutes les adresses IP ne correspondantpas ou permettre l’accès à toute personne pouvant répondre aux exigences duniveau d’authentification.

Par défaut, anyothernw figure dans un objet protégé avec un index de niveaud’authentification 0. L’entrée apparaît comme “Any Other Network” dans lacommande pop show :pdadmin> pop show test

Protected object policy: testDescription: Test POPWarning: noAudit level: noneQuality of protection: noneTime of day access: sun, mon, tue, wed, thu, fri, sat:

anytime:localIP Endpoint Authentication Method Policy

Any Other Network 0

Exemple1. Configurez des niveaux d’authentification dans webseald.conf :

[authentication-levels]level = unauthenticatedlevel = token-card

2. Configurez l’attribut IP Endpoint Authentication Method POP :pdadmin> pop modify test set ipauth anyothernw 1

pdadmin> pop show testProtected object policy: testDescription: Test POPWarning: noAudit level: noneQuality of protection: noneTime of day access: mon, wed, fri:anytime:localIP Endpoint Authentication Method Policy

Any Other Network 1

Ces règles exigent une augmentation du niveau d’authentification grâce aupassage vers la méthode d’authentification par code de jeton (niveau 1) pourtous les utilisateurs ayant initialement un accès “unauthenticated” (niveau 0).Tous les utilisateurs non authentifiés tentant d’accéder à des objets protégés parces règles POP reçoivent une invite pour un nom d’utilisateur et un passcodede jeton.

Voir aussi la section «Règles POP d’authentification basée sur réseau» à lapage 105.

Chapitre 4. Règles de sécurité WebSEAL 101

Page 122: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Formulaire de connexion d’authentification avancéeWebSEAL présente un formulaire spécial lorsque les règles POP renforcées sur laressource demandée forcent le client à demander une nouvelle authentification.L’emplacement de ce formulaire, ou page HTML, est spécifié par le paramètrestepup-login de la strophe [acnt-mgt] du fichier de configuration webseald.conf.[acnt-mgt]stepup-login = stepuplogin.html

Vous pouvez configurer cette page HTML pour qu’elle réponde à vos besoins,comme vous pouvez configurer des formulaires login.html ou tokenlogin.html.

Ce fichier contient des macros, qui se présentent comme des séquences %TEXT%,remplacées par les valeurs appropriées. Cette substitution se produit au sein desfonctions de traitement de fichier modèle WebSEAL et permet d’utiliser ceformulaire pour les méthodes d’authentification par mot de passe et par jeton avecune mise en forme correcte. De même, d’autres informations, du type messaged’erreur et nom de méthode (renforcée) peuvent être renseignées pour l’utilisateurdans le formulaire.

Figure 18. Formulaire de connexion personnalisée pour nom d’utilisateur et mot de passe

Figure 19. Formulaire de connexion personnalisée pour SecurID et mot de passe

102 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 123: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Algorithme d’autentification avancéeWebSEAL utilise l’algorithme suivant pour traiter les conditions d’un objetprotégé :1. Vérification des règles de la méthode d’authentification par noeud final IP sur

l’objet protégé.2. Vérification des droits d’accès de LCA.3. Vérification des règles d’heure d’accès pour l’objet protégé.4. Vérification des règles de niveau d’audit pour l’objet protégé.

Notes et limites de l’authentification avancée1. L’authentification avancée est prise en charge à la fois via HTTP et HTTPS.2. Vous ne pouvez pas passer du protocole HTTP au protocole HTTPS.3. Le niveau non authentifié doit toujours constituer la première méthode de la

liste, et ne peut pas se trouver à un autre niveau de la liste.4. Les méthodes ne peuvent être spécifiées qu’une fois dans la liste de niveaux.5. L’authentification par certificat est une méthode prise en charge pour

l’authentification renforcée.

Remarque : L’authentification renforcée traite les certificats côté client commeun cas à part. Si un client accède à WebSEAL avec un certificatcôté client et que WebSEAL est configuré de façon à accepter descertificats, le client est traité comme étant non authentifié avec unindex de niveau 0.

A partir de la méthode : Peut évoluer à :

unauthenticated password token-card

password token-card

token-card password

6. Les niveaux d’authentification étant représentés par des méthodesd’authentification, il est impossible de spécifier un mécanismed’authentification précis pour l’authentification à ce niveau.Les méthodes d’authentification peuvent être prises en charge par plusieursmécanismes d’authentification, par exemple des authentificateurs locaux et desauthentificateurs externes personnalisés.WebSEAL suit des règles spécifiques pour déterminer l’authentificateur àsélectionner en cas de configuration de plusieurs instances d’une mêmeméthode d’authentification.

7. Si trois niveaux ont été configurés, les valeurs d’index autorisées sont : 0,1,2. Siune autre valeur d’index est configurée, une page d’erreur s’affiche dès qu’unobjet doté de ce POP est demandé.

8. Si les niveaux d’authentification avancée ne sont pas configurés correctementdans le fichier de configuration webseald.conf, la fonctionnalité derenforcement est désactivée dans WebSEAL. Cette situation peut engendrer uncomportement d’authentification inattendu, par exemple la page de connexionpar mot de passe sera émise pour des objets protégés par une règle POPdemandant la méthode d’authentification par passcode de jeton.Après avoir configuré les niveaux d’authentification renforcée, recherchez leserreurs de configuration consignées dans le fichier webseald.log.

Chapitre 4. Règles de sécurité WebSEAL 103

Page 124: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Différence entre authentification avancée et authentification àfacteurs multiples

L’authentification avancée et l’authentification à facteurs multiples Access Managerreprésentent deux méthodes différentes de contrôle d’accès aux ressources. AccessManager contient uniquement l’authentification avancée, comme le décrit cechapitre.

L’authentification à facteurs multiples force un utilisateur à s’authentifier à l’aidede deux niveaux d’authentification ou plus. Par exemple, le contrôle d’accès à uneressource protégée peut nécessiter que l’utilisateur s’authentifie à l’aide du nomd’utilisateur/mot de passe et du nom d’utilisateur/code jeton.

L’authentification avancée d’Access Manager repose sur une hiérarchiepréconfigurée de niveaux d’authentification et met en oeuvre un niveau spécifiqued’authentification en fonction de la règle définie pour une ressource. Elle ne forcepas l’utilisateur à s’authentifier à l’aide de plusieurs niveaux d’authentificationpour accéder à une ressource donnée. L’utilisateur doit s’authentifier à un niveauau moins aussi élevé que le niveau requis par la règle qui protège la ressource.

Exemple d’authentification avancée :

Niveaux d’authentification configurée :v niveau d’authentification 1 = nom d’utilisateur/mot de passev niveau d’authentification 2 = nom d’utilisateur/code jeton

L’objet suivant est protégé par une règle POP nécessitant le niveaud’authentification 1 :/WebSEAL/hostA/junction

L’objet suivant est protégé par une règle POP nécessitant le niveaud’authentification 2 :/WebSEAL/hostA/junction/applicationA

Avec l’auhentification avancée, le niveau d’authentification 1 (nomd’utilisateur/mot de passe) est requis pour l’accès à /WebSEAL/hostA/junction.

En revanche, le niveau d’authentification 2 (nom d’utilisateur/code jeton) estrequis pour l’accès à /WebSEAL/hostA/junction/applicationA. Si l’utilisateur s’estconnecté à l’aide d’un nom d’utilisateur et d’un mot de passe, une invite luidemande d’entrer son nom d’utilisateur et son code jeton (authentificationavancée). Mais si l’utilisateur s’est initialement connecté à WebSEAL à l’aide dunom d’utilisateur et du code jeton, l’accès à applicationA est immédiat (sousréserve d’un contrôle de LCA positif).

L’authentification à facteurs multiples nécessiterait dans ce cas à la fois le niveau 1et le niveau 2 d’authentification pour l’accès à applicationA.

104 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 125: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Règles POP d’authentification basée sur réseauLes règles POP d’authentification basée sur réseau permettent de contrôler l’accèsaux objets, sur la base de l’adresse IP de l’utilisateur. Vous pouvez avoir recours àcette fonctionnalité pour éviter que certaines adresses IP (ou plages d’adresses IP)puissent accéder à des ressources de votre domaine protégé.

Vous pouvez également appliquer une configuration de renforcementd’authentification à ces règles et demander une méthode d’authentificationspécifique pour chaque plage d’adresses IP spécifiée.

Les règles de renforcement d’authentification sont définies dans l’attribut deméthode d’authentification des extrémités IP (IP Endpoint Authentication Method)des règles POP. Vous devez spécifier deux éléments dans cet attribut :v Niveaux d’authentificationv Réseaux autorisés

Configuration des niveaux d’authentificationWebSEAL reconnaît trois méthodes d’authentification avancée :v unauthenticatedv passwordv token-card

Sur la base de l’ordre des méthodes de la liste, chaque méthode est dotée d’unindex de niveau, de 0 à 2.

Vous pouvez configurer les niveaux d’authentification dans la strophe[authentication-levels] du fichier de configuration webseald.conf. Initialement,seulement deux niveaux sont configurés :[authentication-levels]level = unauthenticatedlevel = password

Vous pouvez vous servir de ces paramètres par défaut lorsque vous configurez uneauthentification basée sur réseau. Dans ce cas, “unauthenticated” correspond auniveau 0 et “password”, au niveau 1.

Voir aussi la section «Configuration des niveaux pour une augmentation du niveaud’authentification» à la page 99.

Spécification des adresses IP et des plagesVous devez indiquer les adresses IP et les plages d’adresses IP autorisées par cesrègles POP.

La commande pdadmin pop modify set ipauth add spécifie le réseau (oul’ensemble de réseaux) et le niveau d’authentification requis dans l’attribut deméthode d’authentification des extrémités IP.

Syntaxe :pdadmin> pop modify <nom_pop> set ipauth add<réseau> <masque_réseau><index_niveau>

Chapitre 4. Règles de sécurité WebSEAL 105

Page 126: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Les niveaux d’authentification configurés sont liés aux plages d’adresses IP. Cetteméthode est conçue pour assurer une certaine souplesse. Si le filtrage desutilisateurs par adresse IP n’est pas important, vous pouvez définir une seuleentrée pour anyothernw (any other network, ou tout autre réseau). Ce paramètreaffecte tous les utilisateurs tentant un accès, quelle que soit l’adresse IP, et lesoblige à s’authentifier au niveau spécifié.

Syntaxe :pdadmin> pop modify<nom_pop> set ipauth anyothernw<index_niveau>

De même, si vous souhaitez ignorer le niveau d’authentification et ne vousreporter qu’à l’adresse IP pour autoriser ou refuser l’accès, vous pouvez utiliser leniveau 0 pour les plages à autoriser et le niveau “forbidden” pour les plages àrefuser.

L’entrée anyothernw définit une plage de réseaux. Elle correspond à tout réseaunon spécifié dans les objets protégés (POP). Cette méthode est utilisée pour créerune entrée par défaut qui peut soit refuser toutes les adresses IP ne correspondantpas ou permettre l’accès à toute personne pouvant répondre aux exigences duniveau d’authentification.

Par défaut, anyothernw figure dans un objet protégé avec un index de niveaud’authentification de 0. L’entrée apparaît comme “Any Other Network” dans lacommande pop show :pdadmin> pop show test

Protected object policy: testDescription: Test POPWarning: noAudit level: noneQuality of protection: noneTime of day access: sun, mon, tue, wed, thu, fri, sat:

anytime:localIP Endpoint Authentication Method Policy

Any Other Network 0

Pour plus de détails sur la définition des niveaux d’authentification, reportez-vousà la section«Configuration des niveaux pour une augmentation du niveaud’authentification» à la page 99.

ExemplesSeuls les utilisateurs à partir de la plage d’adresses IP 9.0.0.0 et du masque deréseau 255.0.0.0 utilisent le niveau d’authentification 1 (“password” par défaut) :pdadmin> pop modify test set ipauth add 9.0.0.0 255.0.0.0 1

Un utilisateur spécifique utilise le niveau d’authentification 0 :pdadmin> pop modify test set ipauth add 9.1.2.3 255.255.255.255 0

Aucun utilisateur (autre que ceux spécifiés dans les exemples ci-dessus) ne peutaccéder à l’objet :pdadmin> pop modify test set ipauth anyothernw forbidden

106 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 127: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Désactivation du renforcement d’authentification par adresseIP

Syntaxe :pdadmin> pop modify <nom_pop> set ipauth remove <réseau> <masque_réseau>

Par exemple :pdadmin> pop modify test set ipauth remove 9.0.0.0 255.0.0.0

Algorithme d’authentification basée sur réseauWebSEAL utilise l’algorithme suivant pour traiter les conditions d’un objetprotégé :1. Vérification des règles de la méthode d’authentification par noeud final IP sur

l’objet protégé.2. Vérification des droits d’accès de LCA.3. Vérification des règles d’heure d’accès pour l’objet protégé.4. Vérification des règles de niveau d’audit pour l’objet protégé.

Notes et limites de l’authentification avancéeL’adresse IP utilisée par WebSEAL pour mettre en oeuvre les règlesd’authentification basée sur réseau doit être celle de l’émetteur de la connexionTCP. Si la topologie de réseau utilise des proxy HTTP, l’adresse qui s’affiche peutêtre celle du serveur proxy.

Dans ce cas, WebSEAL ne peut pas identifier de façon définitive l’adresse IP réelledu client. Lorsque vous définissez des règles d’authentification basée sur réseau,vous devez vous assurer que les clients du réseau peuvent se connecterdirectement au serveur WebSEAL.

Niveau de protection des règles POPL’attribut POP de niveau de protection vous permet de spécifier le niveau deprotection de données requis pour exécuter une opération sur un objet.

Actuellement, cet attribut n’est adéquat que dans un environnement WebSEAL.

L’attribut POP de niveau de protection remplace les bits de droits d’accès de LCA“P” et “I” qui activaient les exigences en matière de confidentialité et d’intégritédans les versions précédentes d’Access Manager. Cette ancienne mise en oeuvre duniveau de protection était inefficace et avait des conséquences sur les performancessystème.

L’attribut POP de niveau de protection permet une transaction unique quand laréponse “yes” à la décision de la LCA inclut également le niveau de protectionrequis. Si le gestionnaire de ressources (comme WebSEAL) ne peut pas garantir leniveau de protection requis, la requête est refusée.pdadmin> pop modify <nom_pop> set qop {none|integrity|privacy}

Niveau deprotection

Description

Privacy(confidentialité)

Le chiffrement de données est obligatoire (SSL).

Chapitre 4. Règles de sécurité WebSEAL 107

Page 128: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Niveau deprotection

Description

Integrity(intégrité)

Utilise certains mécanismes pour assurer que les données n’ont pas étémodifiées.

Par exemple :pdadmin> pop modify test set qop privacy

Gestion des utilisateurs non authentifiés (HTTP/HTTPS)WebSEAL accepte les requêtes émanant à la fois d’utilisateurs authentifiés ou nonauthentifiés via HTTP et HTTPS. WebSEAL se base alors sur le serviced’autorisation pour mettre en oeuvre les règles de sécurité en autorisant ourefusant l’accès aux ressources protégées.

Pour les utilisateurs non authentifiés qui ont un accès via SSL, les conditionsci-après s’appliquent :v L’échange d’informations entre l’utilisateur non authentifié et WebSEAL est

chiffré (comme avec un utilisateur authentifié).v Une connexion SSL entre un utilisateur authentifié et WebSEAL exige

uniquement une authentification côté serveur.

Traitement d’une requête émanant d’un client anonyme1. Un client anonyme effectue une requête auprès de WebSEAL (via HTTP ou

HTTPS).2. WebSEAL crée une autorisation d’accès non authentifiée pour ce client.3. La requête se poursuit, avec cette autorisation d’accès, vers l’objet Web protégé.4. Le service d’autorisation vérifie les droits d’accès au niveau de l’entrée non

authentifiée de la LCA pour cet objet, puis accepte ou refuse l’opérationdemandée.

5. Un accès réussi à cet objet dépend de l’entrée LCA non authentifiée contenantau moins un accès en lecture (r) ou de type traverse (T).

6. Si la requête ne passe pas le cap de l’autorisation, le client reçoit un formulairede connexion (BA ou à par formulaire).

Forçage de la connexion utilisateurVous pouvez forcer un utilisateur non authentifié à se connecter en définissantcorrectement les droits d’accès appropriés à l’entrée non authentifiée dans lesrègles de la LCA qui protège l’objet demandé.

Les droits d’accès de type lecture (r) et traverse (T) permettent l’accès nonauthentifié à un objet.

Pour forcer un utilisateur non authentifié à se connecter, supprimez le droit d’accèsen lecture (r) de l’entrée non authentifiée dans les règles de la LCA qui protègel’objet demandé. L’utilisateur reçoit une invite de connexion (BA ou par à l’aide deformulaires).

108 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 129: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Applications de l’accès HTTPS non authentifiéIl existe plusieurs raisons pratiques justifiant la prise en charge d’un accès nonauthentifié à WebSEAL via HTTPS :v Certaines applications n’exigent pas de connexion personnelle, mais demandent

des informations confidentielles, du type adresses et numéros de cartes de crédit.C’est le cas par exemple pour l’achat en ligne de tickets d’avion ou autresmarchandises.

v Certaines applications nécessitent que vous définissiez un compte commercialavant de poursuivre la transaction. Là encore, des informations confidentiellesvont transiter sur le réseau.

Contrôle d’utilisateurs non authentifiés avec des règles deLCA/POP

Remarque : Le type d’entrée “any-authenticated” (authentifié) équivaut au typed’entrée “any-other”.

1. Pour permettre l’accès d’un utilisateur non authentifié à des objets publics,protégez le contenu public par une LCA contenant au moins les droits d’accèsde type lecture (r) et traverse (T) pour les entrées non authentifiées etauthentifiées :unauthenticated Trany-authenticated Tr

Remarque : L’entrée unauthenticated est un masque (une opération “and” bitpar bit) appliqué à l’entrée any-authenticated quand les droitsd’accès sont déterminés. Un droit d’accès pour unauthenticatedn’est accordé que s’il apparaît également dans l’entréeany-authenticated. Comme unauthenticated dépend deany-authenticated, il n’est pas logique qu’une LCA contienneany-authenticated sans unauthenticated. Si cette situation seproduit toutefois, la réponse par défaut consiste à n’accorderaucun droit d’accès à unauthenticated.

2. Pour demander le chiffrement (SSL), protégez le contenu par des règles d’objetprotégé (POP) qui spécifient la confidentialité comme une condition.Voir la section «Niveau de protection des règles POP» à la page 107.

Chapitre 4. Règles de sécurité WebSEAL 109

Page 130: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

110 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 131: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Chapitre 5. Authentification WebSEAL

Ce chapitre explique comment WebSEAL gère l’état des sessions et le processusd’authentification. Une authentification réussie génère une identité Access Managerqui représente l’utilisateur. WebSEAL se sert de cette identité pour acquérir desautorisations pour cet utilisateur. Ces données sont utilisées par le serviced’autorisation pour accorder ou refuser l’accès aux ressources protégées.

Index des rubriques :v «Explication du processus d’authentification» à la page 111v «Gestion de l’état de session» à la page 113v «Généralités sur la configuration de l’authentification» à la page 122v «Configuration de l’authentification de base» à la page 126v «Configuration de l’authentification à base de formulaires» à la page 127v «Configuration de l’authentification par certificat côté client» à la page 129v «Configuration de l’authentification par en-tête HTTP» à la page 132v «Configuration de l’authentification par adresse IP» à la page 134v «Configuration de l’authentification par jeton» à la page 134v «Prise en charge du multiplexage d’agents proxy» à la page 135v «Configuration de la nouvelle authentification sur la base de la stratégie de

sécurité» à la page 138v «Configuration de la nouvelle authentification sur la base de la règle d’inactivité

de session» à la page 141

Explication du processus d’authentificationL’authentification est la méthode qui permet d’identifier un processus ou uneentité individuel essayant de se connecter à un domaine sécurisé.v WebSEAL prend en charge plusieurs méthodes d’authentification par défaut et

peut être personnalisé pour utiliser d’autres méthodes.v Le résultat d’une authentification réussie auprès de WebSEAL est une identité de

registre d’utilisateurs Access Manager.v WebSEAL utilise cette identité pour obtenir un droit d’accès pour l’utilisateur.v Le service d’autorisation utilise ce droit d’accès pour autoriser ou refuser l’accès

à des objets protégés après évaluation des droits d’accès de la LCA et desconditions POP gérant les règles relatives à chaque objet.

Remarque : LCA = liste de contrôle d’accès règles POP = règles d’objet protégé

Lors de l’authentification, WebSEAL examine une requête client et en particulier lesinformations suivantes :v Données de session

Les données de session sont des informations identifiant une connexionspécifique entre le client et le serveur WebSEAL. Les données de session sontstockées avec le client et accompagnent les requêtes ultérieures de ce client. Ellespermettent d’identifier une deuxième fois la session client auprès du serveurWebSEAL et évitent de devoir établir une nouvelle session pour chaque requête.

© Copyright IBM Corp. 1999, 2002 111

Page 132: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

v Données d’authentification

Les données authentification sont des informations issues du client quiidentifient ce dernier auprès du serveur WebSEAL. Les donnéesd’authentification comprennent les certificats côté client, les mots de passe et lescodes de jeton.

Lorsque WebSEAL reçoit une requête client, il recherche toujours les données desession en premier, puis les données d’authentification. La requête client initiale necontient jamais les données de session.

Types de données de session pris en chargeWebSEAL prend en charge les données de session suivantes :1. ID SSL (défini par le protocole SSL) ;2. Cookie de session du serveur ;3. Données d’en-tête de l’authentification de base (BA) ;4. Données d’en-tête HTTP ;5. Adresse IP

Lorsque WebSEAL examine une requête client, il recherche les données de sessiondans l’ordre de cette liste.

Méthodes d’authentification prises en chargeBien que WebSEAL fonctionne de façon indépendante du processusd’authentification, WebSEAL utilise les droits d’accès pour contrôler tous lesutilisateurs participant au domaine sécurisé. Pour obtenir les informationsd’identité nécessaires à l’acquisition des droits d’accès, WebSEAL se base sur lesinformations obtenues à partir du processus d’authentification.

WebSEAL prend en charge les méthodes d’authentification suivantes pour obtenirdes droits d’accès :

Méthode d’authentification Type de connexion accepté

1. Cookie de secours HTTP et HTTPS

2. Jeton d’ID CDSSO HTTP et HTTPS

3. Certificat côté client HTTPS

4. Codes de jeton HTTP et HTTPS

5. Authentification par formulaires (nom d’utilisateur et motde passe)

HTTP et HTTPS

6. Authentification de base (nom d’utilisateur et mot depasse)

HTTP et HTTPS

7. En-têtes HTTP HTTP et HTTPS

8. Adresse IP HTTP et HTTPS

Lorsque WebSEAL examine une requête client, il recherche les donnéesd’authentification dans l’ordre de ce tableau.

Les méthodes d’authentification peuvent être activées et désactivées séparément àla fois pour les transports HTTP et HTTPS. Si aucune méthode d’authentificationn’est activée pour un transport en particulier, le processus d’authentification estinactif pour les clients utilisant ce type de transport.

112 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 133: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Gestion de l’état de sessionUne connexion sécurisée, ou session, entre un client et un serveur exige que cedernier ait la possibilité de mémoriser (entre de nombreuses requêtes) sesinterlocuteurs. Le serveur doit donc pouvoir recevoir des informations sur l’état dela session, identifiant le client associé à chaque requête.

Cette section contient :v «Généralités sur l’état de session» à la page 113v «Généralités sur la mémoire cache de session GSKit et WebSEAL» à la page 113v «Configuration de la mémoire cache d’ID de session GSKit SSL» à la page 114v «Configuration de la mémoire cache des droits d’accès WebSEAL» à la page 115v «Gestion de l’état avec des cookies de session» à la page 116v «Détermination des types de données d’ID de session valides» à la page 118v «Configuration de cookies de secours» à la page 119

Généralités sur l’état de sessionSi l’état de la session entre le client et le serveur est inconnu, les communicationsentre les deux doivent être renégociées pour chaque nouvelle requête. Lesinformations sur l’état de la session optimisent les performances en évitant lesfermetures et les réouvertures répétées des connexions client/serveur. Le clientpeut se connecter une seule fois et exécuter de nombreuses requêtes sans avoir à seconnecter séparément pour chacune.

WebSEAL gère à la fois les communications HTTP et HTTPS. HTTP est unprotocole “sans état” qui ne fournit aucun moyen permettant de distinguer unerequête d’une autre. En revanche, le protocole de transport SSL est toutspécialement conçu pour fournir un ID de session de façon à conserver lesinformations d’état de session. Les communications HTTP peuvent êtreencapsulées via SSL pour devenir des communications HTTPS.

Cependant, WebSEAL doit souvent traiter des communications HTTP à partir declients non authentifiés. Parfois, l’ID de session SSL n’est pas une solutionappropriée. C’est pourquoi WebSEAL est conçu pour utiliser tous les typesd’informations suivants pour gérer l’état de la session d’un client :1. ID SSL2. Cookie de session du serveur ;3. Données d’en-tête de l’authentification de base (BA) ;4. Données d’en-tête HTTP ;5. Adresse IP

Généralités sur la mémoire cache de session GSKit etWebSEAL

Une mémoire cache de session permet à un serveur de stocker les informationsd’ID de session de différents clients. Deux mémoires cache de session sont utiliséespar WebSEAL pour contenir les informations d’état de session HTTPS et HTTP.v Mémoire cache des sessions/des droits d’accès WebSEAL

La mémoire cache des droits d’accès stocke tous les types d’informations d’ID desession (voir la liste ci-dessus) ainsi que les informations de droits d’accèsobtenues pour chaque client.

Chapitre 5. Authentification WebSEAL 113

Page 134: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Les informations de droits d’accès sont mises en mémoire cache de manière àsupprimer les interrogations répétitives de la base de données du registred’utilisateurs lors des contrôles d’autorisation.

v Cache d’ID de session SSL GSKitLa mémoire cache de session GSKit traite les communications HTTPS (SSL)lorsque les informations d’ID de session SSL sont utilisées pour gérer l’état dessessions.La mémoire cache GSKit conserve également les informations d’état de sessionpour la connexion SSL entre WebSEAL et le registre d’utilisateurs LDAP.

Différents paramètres de configuration permettent d’ajuster les performances dechaque mémoire cache. Ces paramètres sont résumés dans la figure ci-après :

Configuration de la mémoire cache d’ID de session GSKit SSLLes tâches de configuration suivantes sont disponibles pour la mémoire cache d’IDde session SSL GSKit :v Définition de la valeur du délai d’expiration de l’entrée de mémoire cachev Définition de la valeur du nombre maximal d’entrées concurrentes

Définition de la valeur du délai d’expiration de l’entrée demémoire cacheLes paramètres permettant de définir le délai d’expiration maximum d’une entréedans la mémoire cache d’ID de session SSL GSKit sont situés dans la strophe [ssl]du fichier de configuration webseald.conf. Il existe deux paramètres : le premierpour les connexions SSL V2 (ssl-v2-timeout) et le second pour les connexions SSLV3 (ssl-v3-timeout).

Par défaut, le délai d’expiration de session SSL V2 (en secondes) est 100 (lesvaleurs admises vont de 1 à 100) :[ssl]ssl-v2-timeout = 100

Par défaut, le délai d’expiration de session SSL V3 (en secondes) est 7200 (lesvaleurs admises vont de 1 à 86400) :[ssl]ssl-v3-timeout = 7200

WebSEAL

Client

Paramètres de configurationde cache GSK- ssl-v2-timeout- ssl-v3-timeout- ssl-cache-max-sessions

Conserve :- ID de session

SSL

Conserve :- Infos sur l’ID

de session- Infos sur le

justificatif

Paramètres de configurationde cache WebSEAL- timeout- inactive-timeout- max-entries

Cache de sessionGSK SSL

Cache des justificatifsWebSEAL

Figure 20. Paramètres de configuration de la mémoire cache de session

114 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 135: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Définition de la valeur du nombre maximal d’entréesconcurrentesLe paramètre ssl-max-entries, situé dans la strophe [ssl] du fichier de configurationwebseald.conf, définit le nombre maximum d’entrées concurrentes dans lamémoire cache d’ID de session SSL GSKit.

Cette valeur correspond au nombre de sessions de connexion concurrentes.Lorsque la taille de la mémoire cache atteint cette valeur, des entrées y sontsupprimées suivant l’algorithme d’ancienneté pour permettre de nouvellesconnexions entrantes.

Le nombre par défaut de sessions de connexion concurrentes est 4096 :[ssl]ssl-max-entries = 4096

Configuration de la mémoire cache des droits d’accèsWebSEAL

Les tâches de configuration suivantes sont disponibles pour la mémoire cache desession/droits d’accès WebSEAL :v Définition de la valeur du nombre maximal d’entrées concurrentesv Définition de la valeur du délai d’expiration de l’entrée de mémoire cachev Définition de la valeur du délai d’inactivité de l’entrée de mémoire cache

Définition de la valeur du nombre maximal d’entréesconcurrentesLe paramètre max-entries, situé dans la strophe [session] du fichier deconfiguration webseald.conf, définit le nombre maximum d’entrées concurrentesdans la mémoire cache de session/droits d’accès WebSEAL.

Cette valeur correspond au nombre de sessions de connexion concurrentes.Lorsque la taille de la mémoire cache atteint cette valeur, des entrées y sontsupprimées suivant l’algorithme d’ancienneté pour permettre de nouvellesconnexions entrantes.

Le nombre par défaut de sessions de connexion concurrentes est 4096 :[session]max-entries = 4096

Définition de la valeur du délai d’expiration de l’entrée demémoire cacheLe paramètre timeout, situé dans la strophe [session] du fichier de configurationwebseald.conf, définit le délai d’expiration maximum de toutes les sessionsutilisateur stockées dans la mémoire cache de session/droits d’accès WebSEAL.

WebSEAL met en mémoire cache interne les informations concernant les droitsd’accès. Le paramètre de dépassement du délai de la mémoire cache de la sessiondéfinit le délai pendant lequel les droits d’accès restent en mémoire sur WebSEAL.

Le paramètre n’est pas un délai d’inactivité. La valeur établit une correspondanceavec une “durée de vie de droits d’accès” plutôt qu’avec un “délai d’expiration desdroits d’accès”. L’objectif est de renforcer la sécurité en forçant l’utilisateur às’authentifier à nouveau lorsque la limite de dépassement du délai est atteinte.

Chapitre 5. Authentification WebSEAL 115

Page 136: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Par défaut, le délai d’expiration de l’entrée en mémoire cache de la session (ensecondes) est 3600 :[session]timeout = 3600

Définition de la valeur du délai d’inactivité de l’entrée demémoire cacheLe paramètre inactive-timeout, situé dans la strophe [session] du fichier deconfiguration webseald.conf, définit la valeur du délai d’inactivité de la sessionutilisateur.

Par défaut, le délai d’inactivité de la session de connexion (en secondes) est 600 :[session]inactive-timeout = 600

Pour désactiver cette fonction de délai d’expiration, affectez au paramètre la valeur“0”.

Gestion de l’état avec des cookies de sessionL’état d’une session entre un client et un serveur peut aussi être conservé par lebiais d’un cookie contenant ces informations. Le serveur groupe les informationsd’état correspondant à un client donné dans un cookie qu’il envoie au navigateurdu client. A chaque nouvelle requête, le navigateur renvoie le cookie (avec lesinformations sur la session) au serveur pour identifier à nouveau le client.

L’emploi des cookies de session constitue une solution possible lorsque le clientutilise un navigateur qui renégocie sa session SSL après de très courtes périodes.Par exemple, certaines versions du navigateur Microsoft Internet Explorerrenégocient les sessions SSL toutes les deux ou trois minutes.

Un cookie de session n’assure une nouvelle authentification d’un client que pour leserveur auprès duquel il s’était récemment authentifié préalablement (environ dixminutes). Ce mécanisme repose sur un “cookie de serveur” qui ne peut êtretransmis à aucune autre machine que celle qui l’a généré.

En outre, le cookie de la session ne contient qu’un identificateur numériquealéatoire utilisé comme index dans la mémoire cache des sessions du serveur. Lecookie de la session ne contient aucune autre information. Ce dernier ne peut pascompromettre les règles de sécurité.

Explication des cookies de sessionWebSEAL utilise un cookie de session sécurisé spécifique du serveur. Lesconditions suivantes s’appliquent à ce mécanisme de cookie :v Un cookie ne contient que des informations de session ; il ne contient pas

d’informations d’identitév Un cookie ne réside que dans la mémoire du navigateur (il n’est pas enregistré

dans la réserve de cookies du disque)v Un cookie a une durée de vie limitéev Un cookie possède des paramètres de domaine et de chemin empêchant à

d’autres serveurs de l’utiliser

116 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 137: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Activation et désactivation des cookies d’ID de sessionLe paramètre ssl-id-sessions, situé dans la strophe [session] du fichier deconfiguration webseald.conf, active et désactive les cookies de session. Il déterminesi l’ID de session SSL est utilisé pour gérer la session de connexion pour les clientsqui se connectent via HTTPS. S’il a la valeur “no”, les cookies de session sontutilisés dans la plupart des méthodes d’authentification.[session]ssl-id-sessions = no

Si ce paramètre de configuration a la valeur “no”, les conditions suivantess’appliquent aux clients utilisant HTTPS :1. L’ID de session SSL n’est jamais utilisé comme données d’ID de session.2. Les cookies permettront de gérer des sessions avec les clients authentifiés à

l’aide de cookies de secours, de jetons d’ID CDSSO, de formulaires (nomd’utilisateur et mot de passe), de codes de jeton et de certificats côté client.

3. Les cookies sont utilisés pour les clients utilisant l’authentification de baseuniquement lorsque use-same-session = yes (voir section suivante). Sinon,l’en-tête BA est utilisé pour les données d’ID de session.

4. L’en-tête HTTP est utilisé comme données d’ID de session pour les clients quis’authentifient avec ce type d’en-tête.

5. L’adresse IP est utilisée comme données d’ID de session pour les clients quis’authentifient avec ce type d’adresse.

Lorsque vous utilisez un cookie pour gérer l’état de la session, il n’est envoyéqu’une seule fois au navigateur, lorsque la connexion est établie. Toutefois, certainsnavigateurs limitent le nombre de cookies en mémoire qu’ils peuvent stockersimultanément. Dans certains environnements, les applications peuvent placer ungrand nombre de cookies en mémoire par domaine sur des systèmes client. Dansce cas, tous les cookies de secours ou de session WebSEAL configurés peuvent êtrefacilement remplacés par un autre.

Lorsque vous configurez WebSEAL de façon à utiliser des cookies de session (voiredes cookies de secours), vous pouvez définir le paramètre resend-webseal-cookies,situé dans la strophe [session] du fichier de configuration webseald.conf afin queWebSEAL les envoie au navigateur avec chaque réponse. Cette action permet des’assurer que les cookies de secours et de session restent dans la mémoire dunavigateur.

La valeur par défaut du paramètre resend-webseal-cookies est “no” :[session]resend-webseal-cookies = no

Pour envoyer les cookies de secours et de session WebSEAL avec chaque réponse,remplacez la valeur par défaut par “yes”.

Activation et désactivation des mêmes sessionsVous pouvez configurer WebSEAL de façon à utiliser les mêmes données d’ID desession lorsqu’un client se connecte via un type de transport (HTTP, par exemple),et se déconnecte puis se reconnecte via un autre type de transport (HTTPS, parexemple).

Chapitre 5. Authentification WebSEAL 117

Page 138: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Le paramètre use-same-session, situé dans la strophe [session] du fichier deconfiguration webseald.conf, active et désactive la reconnaissance des donnéesd’ID de session identiques. Par défaut, ce paramètre a la valeur “no” :[session]use-same-session = no

Si ce paramètre de configuration a la valeur “yes”, les conditions suivantess’appliquent :1. Les cookies de session permettent d’identifier les types de client suivants pour

les connexions suivantes via un autre type de transport :a. Cookies de secours ;b. Certificats côté client ;c. Jeton d’ID CDSSO ;d. Code de jeton ;e. Formulaires (nom d’utilisateur et mot de passe) ;f. Authentification de base.

2. L’en-tête HTTP est utilisé pour les clients qui se connectent avec ce typed’en-tête.

3. L’adresse IP est utilisée pour les clients qui se connectent avec ce typed’adresse.

4. Le paramètre de configuration ssl-id-sessions est ignoré ; le comportementobtenu est le même que lorsque qu’il a la valeur “no”.Cette logique est importante dans la mesure où les clients HTTP n’ont pas d’IDde session SSL utilisable comme données de session.

5. Dans la mesure où les cookies sont utilisables à la fois par les clients HTTP etHTTPS, ils ne sont pas marqués comme cookies sécurisés.

Détermination des types de données d’ID de session validesLe type de données de session pour un client qui se connecte avec une méthoded’authentification particulière est déterminé par des combinaisons spécifiques desparamètres de configuration suivants :v Activation ou désactivation des cookies de session (ssl-id-sessions) ;v Activation ou désactivation de la fonction permettant d’utiliser les mêmes

données de session lorsqu’un client passe du transport HTTP au transportHTTPS ou inversement (use-same-session).

Les tableaux suivants récapitulent les données d’ID de session valides pour toutesles configurations combinant les paramètres ssl-id-sessions et use-same-session :

Clients HTTPS

Méthode d’authentification ssl-id-sessions = yes ssl-id-sessions = nouse-same-session = no

use-same-session = yesssl-id-sessions ignored

Cookie de secours ID SSL Cookie Cookie

Certificat ID SSL Cookie Cookie

CDSSO ID SSL Cookie Cookie

Jeton ID SSL Cookie Cookie

Formulaires ID SSL Cookie Cookie

BA ID SSL En-tête BA Cookie

En-tête HTTP ID SSL En-tête HTTP En-tête HTTP

118 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 139: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Clients HTTPS

Méthode d’authentification ssl-id-sessions = yes ssl-id-sessions = nouse-same-session = no

use-same-session = yesssl-id-sessions ignored

Adresse IP ID SSL Adresse IP Adresse IP

Clients HTTP

Méthode d’authentification use-same-session = no use-same-session = yes

Cookie de secours Cookie Cookie

CDSSO Cookie Cookie

Jeton Cookie Cookie

Formulaires Cookie Cookie

BA En-tête BA Cookie

En-tête HTTP En-tête HTTP En-tête HTTP

Adresse IP Adresse IP Adresse IP

Configuration de cookies de secoursLa fonction de cookie de secours suivante (pour HTTP et HTTPS) convient à unclient qui se connecte à un groupe de serveurs WebSEAL frontaux répliqués via unmécanisme d’équilibrage de charge. L’objectif d’un cookie de secours consiste àempêcher une nouvelle authentification obligatoire lorsque le serveur ayant établila première session avec le client devient subitement indisponible.

Un groupe de serveurs WebSEAL frontaux peut être mis en oeuvre pour fournirune accessibilité avancée des ressources à de nombreux clients. Le mécanismed’équilibrage de charge intercepte les requêtes entrantes et les répartit entre lesserveurs frontaux disponibles.

Reportez-vous au graphique suivant :

Le client ignore la configuration des serveurs frontaux répliqués. Le mécanismed’équilibrage de charge est le seul point de contact pour l’adresse URL demandée.Le mécanisme d’équilibrage de charge connecte un client avec un serveur

Client

Mécanisme d’équilibragede charge

WS1

WS2

WS3

Serveurs WebSEALprincipaux répliqués

Ressourcessecondaires

Figure 21. Scénario de cookie de secours

Chapitre 5. Authentification WebSEAL 119

Page 140: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

disponible (par exemple, WS1). Un état de session est établi avec le serveur WS1 ettoutes les requêtes suivantes de ce client sont envoyées à WS1.

Lorsque le serveur WS1 devient indisponible pour une raison ou une autre (parexemple, panne du système ou déconnexion par un administrateur), les cookies desecours peuvent apporter une solution. Si le serveur WS1 devient indisponible, lemécanisme d’équilibrage de charge réachemine la requête vers l’un des autresserveurs répliqués (WS2 ou WS3). A présent, le mappage session-droits d’accèsd’origine est perdu. Ce serveur de remplacement ne connaît pas le client qui doitnormalement s’authentifier une deuxième fois.

Vous pouvez configurer les serveurs WebSEAL répliqués pour chiffrer les donnéesd’identification d’un client dans un cookie spécifique du serveur. Le cookie estplacé sur le navigateur lorsque le client se connecte pour la première fois. Si leserveur WebSEAL existant devient provisoirement indisponible, le cookie (avec lesinformations d’identification chiffrées) est envoyé au serveur de remplacement.

Le cookie de secours contient le nom d’utilisateur, l’horodate et la méthoded’authentification d’origine. Les serveurs WebSEAL répliqués partagent une clécommune qui permet de déchiffrer les informations relatives au cookie. Lorsque leserveur WebSEAL de substitution reçoit ce cookie, il peut utiliser le nomd’utilisateur et la méthode d’authentification pour générer de nouveau les donnéesd’autorisation du client (y compris les attributs étendus). A présent, le client peutétablir une nouvelle session avec une réplique de ce serveur WebSEAL sans êtreobligé de subir une nouvelle authentification.

Le point de référence du cookie est le serveur DNS du mécanisme d’équilibrage decharge. Cet unique point de référence est important dans la mesure où le cookie estpropre à un serveur et non pas à un domaine. Seul un serveur ayant le même nomDNS que le serveur ayant créé le cookie peut accepter ce dernier. Le client effectuetoujours ses requêtes à l’aide du mécanisme d’équilibrage de charge. C’estpourquoi le cookie est toujours accepté, puis transmis au serveur disponiblesuivant lors d’une opération de secours.

Activation des cookies de secoursLe paramètre failover-auth, situé dans la strophe [failover] du fichier deconfiguration webseald.conf, active ou désactive des cookies de secours propres auserveur.v Pour activer les cookies de secours, entrez “http”, “https” ou “both”.v Pour désactiver les cookies de secours, entrez “none” (valeur par défaut).

Par exemple :[failover]failover-auth = https

Vous devez définir ce paramètre sur chaque serveur WebSEAL frontal.

Pour chaque méthode d’authentification prise en charge dans l’environnement declusters WebSEAL, vous devez également activer un paramètre équivalent deméthode de secours dans la strophe [authentication-mechanisms] du fichier deconfiguration webseald.conf. Chaque paramètre de méthode de secours désigneune bibliothèque partagée spécifique d’authentification identique à celle d’origineet récupère les attributs étendus qui ont été placés dans les données d’autorisationde l’utilisateur.

120 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 141: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Les paramètres de méthode d’authentification de secours suivants sontdisponibles :[authentication-mechanisms]#failover-password = <failover-password-library>#failover-token-card = <failover-tokeb-card-library>#failover-certificate = <failover-certificate-library>#failover-http-request = <failover-http-request-library>#failover-cdsso = <failover-cdsso-library>

WebSEAL contient une bibliothèque partagée standard de secours qui fonctionnepour toutes les méthodes d’authentification décrites ci-dessus. Cette bibliothèqueest la suivante :

Solaris libfailoverauthn.so

AIX libfailoverauthn.a

HP-UX libfailoverauthn.sl

Windows failoverauthn.dll

Vous pouvez également indiquer une bibliothèque CDAS personnalisée offrant lescapacités d’authentification requises par votre environnement.

Par exemple :1. L’utilisateur effectue l’authentification vis-à-vis de WS1 via le nom d’utilisateur

et le mot de passe. La bibliothèque standard libldapauthn ajoute aux donnéesd’autorisation de l’utilisateur (via un attribut étendu HTTP-Tag-Value sur lajonction) certains attributs étendus à partir de LDAP.Un module CDAS peut également ajouter d’autres attributs étendus auxdonnées d’autorisation de l’utilisateur via sa bibliothèque cred-ext-attrs.

2. Le serveur WS1 échoue et l’utilisateur est orienté vers le serveur WS2.3. WS2 reçoit le cookie de secours en provenance du navigateur de l’utilisateur et

décode le cookie. Puisque l’utilisateur a effectué l’authentification d’origine àl’aide de la méthode de nom d’utilisateur et de mot de passe, la bibliothèquelibfailoverauthn se connecte au serveur LDAP et extrait les donnéesd’autorisation standard requises par cette méthode, ainsi que les attributsétendus spécifiés par l’association balise/valeur.Ensuite, l’identité de l’utilisateur est transmise à la bibliothèque personnaliséecred-ext-attrs qui fournit ses attributs étendus supplémentaires.Désormais, WS2 a généré les mêmes données d’autorisation complètes relativesà l’utilisateur que celles utilisées par WS1.

Si l’environnement applicable à cet exemple inclut également un support pourl’authentification de certificats, la strophe [authentication-mechanisms] se présentecomme suit :[authentication-mechanisms]passwd-ldap = /opt/pdweb/lib/libldapauthn.socert-ssl = /opt/pdweb/lib/libsslauthn.sofailover-password = /opt/pdweb/lib/libfailoverauthn.sofailover-certificate = /opt/pdweb/lib/libfailoverauthn.socred-ext-attrs = /usr/lib/custom-ext-attrs-CDAS.so

Chapitre 5. Authentification WebSEAL 121

Page 142: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Chiffrement et déchiffrage des données de cookiePour protéger les données du cookie, servez-vous de l’utilitaire cdsso_key_genfourni par WebSEAL. Ce dernier génère une clé symétrique qui chiffre et déchiffreles données dans le cookie. Indiquez l’emplacement (chemin d’accès absolu) dufichier de clés lorsque vous exécutez l’utilitaire :

UNIX :# cdsso_key_gen <chemin>

Windows :MSDOS> cdsso_key_gen <chemin>

Exécutez l’utilitaire sur l’un des serveurs répliqués et copiez manuellement lefichier de clés sur tous les autres. Entrez l’emplacement de ce fichier de clés dansla strophe [failover] du fichier de configuration webseald.conf de chaque serveur.Si vous n’indiquez pas de fichier de clés, la fonctionnalité de cookie de secours estdésactivée pour ce serveur :[failover]failover-cookies-keyfile = <chemin_absolu>

Vous pouvez affecter au fichier de clés un nom approprié, par exemple ws.key.

Configuration de la durée de vie des cookiesLa valeur de durée de vie des cookies de secours (exprimée en minutes) est définieà l’aide du paramètre failover-cookie-lifetime :[failover]failover-cookie-lifetime = 60

Activation des cookies de secours dans les domainesVous pouvez autoriser l’envoi des cookies de secours à tout serveur du mêmedomaine utilisé comme serveur WebSEAL grâce à l’affectation de la valeur “yes”au paramètre enable-failover-cookie-for-domain. Par défaut, la fonction de cookiede secours dans les domaines est désactivée :[failover]enable-failover-cookie-for-domain = no

Généralités sur la configuration de l’authentificationVous pouvez activer et désactiver l’authentification pour les clients HTTP etHTTPS méthode par méthode.

Les mécanismes pour toutes les méthodes d’authentification prises en charge parWebSEAL sont configurés dans la strophe [authentication-mechanisms] du fichierde configuration webseald.conf. Les paramètres de méthode d’authentificationacceptés sont les suivants :v Authentificateurs locaux (intégrés)

Les paramètres des authentificateurs locaux spécifient les fichiers debibliothèques partagées intégrés (UNIX) ou DLL (Windows).

v Authentificateurs externes personnalisésWebSEAL fournit un code serveur modèle qui vous permet de définir et despécifier un serveur CDAS (Cross Domain Authentication Service) externepersonnalisé.Un authentificateur CDAS externe spécifie la bibliothèque partagée personnaliséequi convient.

122 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 143: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Paramètres locaux d’authentificationLes paramètres suivants spécifient les authentificateurs intégrés locaux :

Paramètre Description

Authentification de base et par formulaires

passwd-ldap Accès client avec nom d’utilisateur et mot de passe LDAP.

Authentification par jeton

token-cdas Accès client avec nom d’utilisateur LDAP et passcode de jetonSecurID.

Authentification par certificat côté client

cert-ssl Accès client avec certificat côté client via SSL.

Authentification par en-tête HTTP et/ou adresse IP

http-request Accès client via en-tête HTTP spécial et/ou adresse IP

Authentification par jeton d’ID CDSSO

cdsso Authentification par connexion unique interdomaine.

Vous pouvez utiliser la strophe [authentication-mechanisms] pour configurer laméthode d’authentification et la mise en oeuvre dans le format suivant :<paramètre_de_méthode_d’authentification> =<bibliothèque_partagée>

Paramètres externes personnalisés d’authentification CDASLes paramètres suivants sont disponibles pour définir les bibliothèques partagéespersonnalisées pour les serveurs CDAS externes :

Paramètre Description

passwd-cdas Accès client avec nom d’utilisateur et mot de passe pour unregistre tiers.

token-cdas Accès client avec nom d’utilisateur et passcode de jeton.

cert-cdas Accès client avec certificat côté client via SSL.

http-request Accès client via en-tête HTTP spécial et/ou adresse IP

cred-ext-attrs Utilisé par CDAS pour fournir des données d’attributs étendus auxdonnées d’autorisation des utilisateurs.

Pour plus d’informations sur la création et la configuration d’une bibliothèquepartagée personnalisée qui met en oeuvre un serveur CDAS, reportez-vous audocument IBM Tivoli Access Manager WebSEAL Developer’s Reference.

Configuration par défaut pour l’authentification WebSEALPar défaut, WebSEAL est défini pour authentifier des clients via SSL en utilisant lesnoms d’utilisateur et les mots de passe de l’authentification de base (BA) (registreLDAP).

WebSEAL est normalement activé pour les accès TCP et SSL. Une configurationclassique de la strophe [authentication-mechanisms inclut donc la prise en chargedu nom d’utilisateur et du mot de passe (registre LDAP), ainsi que celle descertificats côté client via SSL.

Chapitre 5. Authentification WebSEAL 123

Page 144: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

L’exemple suivant représente la configuration classique de la strophe[authentication-mechanisms] pour Solaris :[authentication-mechanisms]passwd-ldap = libldapauthn.socert-ssl = libsslauthn.so

Pour configurer d’autres méthodes d’authentification, ajoutez le paramètreapproprié avec sa bibliothèque partagée (ou le module CDAS).

Configuration de plusieurs méthodes d’authentificationPour définir la bibliothèque partagée à utiliser pour une méthoded’authentification prise en charge, modifiez la strophe [authentication-mechanism]du fichier de configuration webseald.conf. Les conditions suivantes s’appliquentlorsque vous configurez plusieurs méthodes d’authentification :1. Toutes les méthodes d’authentification peuvent fonctionner de façon

indépendante. Vous pouvez configurer une bibliothèque partagée pour chaqueméthode prise en charge.

2. La méthode cert-cdas prévaut sur la méthode cert-ssl lorsqu’elles sont toutesles deux configurées. Vous devez activer l’une ou l’autre de ces méthodes pourprendre en charge les certificats côté client.

3. Seul un authentificateur par mot de passe est réellement utilisé lorsqueplusieurs authentificateurs de ce type sont configurés. WebSEAL utilise l’ordrede priorité suivant en cas de configuration de plusieurs authentificateurs parmot de passe :a. passwd-cdas

b. passwd-ldap

4. Il est possible de configurer la même bibliothèque personnalisée pour deuxméthodes d’authentification différentes. Par exemple, vous pouvez écrire unebibliothèque partagée personnalisée pour traiter à la fois l’authentification parnom d’utilisateur/mot de passe et l’authentification par en-tête HTTP. Dans cetexemple, les paramètres passwd-cdas et http-request doivent être configurésavec la même bibliothèque partagée. Le développeur doit gérer l’état de sessionet éviter les conflits entre les deux méthodes.

Invite de connexionWebSEAL invite un client à se connecter :1. lorsque le contrôle d’autorisation d’un client non authentifié échoue ;2. lorsque le contrôle d’autorisation d’un client utilisant l’authentification de base

ou par formulaire échoue.

Les types de client suivants reçoivent un message d’erreur de type “403 Echec” :1. Lorsqu’un contrôle d’autorisation échoue :

a. Certificat côté clientb. Cookie de secoursc. CDSSOd. Adresse IPe. En-tête HTTP

2. Lorsqu’un client s’authentifie avec une méthode désactivée par WebSEAL

124 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 145: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Commandes de déconnexion et de modification de mot depasse

Access Manager fournit les commandes suivantes pour prendre en charge lesclients qui s’authentifient via HTTP ou SSL.

pkmslogoutLes clients peuvent exécuter la commande pkmslogout pour se déconnecter de lasession courante lorsqu’ils utilisent une méthode d’authentification qui ne fournitpas de données d’authentification avec chaque requête. Par exemple, pkmslogoutne fonctionne pas pour les clients utilisant l’authentification de base oul’authentification par adresse IP. Dans ce cas, vous devez fermer le navigateur pourvous déconnecter.

La commande pkmslogout est appropriée pour l’authentification par certificat côtéclient, les codes de jeton, l’authentification par formulaires et certaines mises enoeuvres de l’authentification par en-tête HTTP.

Exécutez la commande comme suit :https://www.tivoli.com/pkmslogout

Le navigateur affiche un formulaire de déconnexion défini dans le fichier deconfiguration webseald.conf :[acnt-mgt]logout = logout.html

Vous pouvez modifier le fichier logout.html selon vos besoins.

L’utilitaire pkmslogout accepte également plusieurs pages de réponse dedéconnexion lorsque l’architecture de réseau exige différents écrans de sortie pourles utilisateurs se déconnectant de systèmes d’arrière-plan distincts.

L’expression suivante identifie un fichier réponse spécifique :https://www.tivoli.com/pkmslogout?filename=<fichier_déconnexion_personnalisé>

où fichier_déconnexion_personnalisé est le nom du fichier de réponse dedéconnexion. Ce fichier doit se trouver dans le répertoire lib/html/C, qui contientle fichier logout.html par défaut et d’autres modèles de formulaires de réponseHTML.

pkmspasswdVous pouvez utiliser cette commande pour modifier votre mot de passe deconnexion lorsque vous utilisez l’authentification de base (BA) ou l’authentificationpar formulaires. Elle est adaptée au protocole HTTP ou HTTPS.

Par exemple :https://www.tivoli.com/pkmspasswd

Pour optimiser la sécurité lorsque l’authentification BA est utilisée avec WebSEAL,cette commande présente le comportement suivant pour un client BA :1. Le mot de passe est modifié.2. L’utilisateur du poste client est déconnecté de la session courante.3. Lorsque le client effectue une autre requête, le navigateur lui envoie une invite

BA.4. Le client doit se reconnecter pour continuer à effectuer des requêtes.

Chapitre 5. Authentification WebSEAL 125

Page 146: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Ce scénario s’applique uniquement à un client utilisant l’authentification de base.

Configuration de l’authentification de baseL’authentification de base (BA) est une méthode standard qui permet de fournir unnom d’utilisateur et un mot de passe au système d’authentification. Définie par leprotocole HTTP, elle peut être mise en oeuvre via HTTP et via HTTPS.

Par défaut, WebSEAL est configuré pour une authentification via HTTPS au moyend’une authentification de base (BA) par nom d’utilisateur et mot de passe.

Activation et désactivation de l’authentification de baseLe paramètre ba-auth, situé dans la strophe [ba] du fichier de configurationwebseald.conf, active et désactive la méthode d’authentification de base.v Pour activer la méthode d’authentification de base, entrez “http”, “https” ou

“both”.v Pour désactiver la méthode d’authentification de base, entrez “none”.

Par exemple :[ba]ba-auth = https

Définition du nom de domaineLe nom de cellule est le texte contenu dans la boîte de dialogue qui s’affichelorsque le navigateur invite l’utilisateur à entrer les données de connexion.

Le paramètre de configuration qui définit le nom de domaine est situé dans lastrophe [ba] du fichier de configuration webseald.conf.

Par exemple :[ba]basic-auth-realm = Access Manager

Figure 22. Invite de connexion BA

126 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 147: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Configuration de la méthode d’authentification de baseLe paramètre passwd-ldap définit la bibliothèque partagée utilisée pour gérerl’authentification par nom d’utilisateur et mot de passe.v Sous UNIX, le fichier fournissant la fonction de mappage intégrée est la

bibliothèque partagée libldapauthn.v Sous Windows, le fichier fournissant la fonction de mappage intégrée est la DLL

ldapauthn.

Méthoded’authentification

Bibliothèque partagée

Solaris AIX Windows HP-UX

passwd-ldap libldapauthn.so libldapauthn.a ldapauthn.dll libldapauthn.sl

Pour configurer la méthode d’authentification par nom d’utilisateur et mot depasse, entrez le paramètre passwd-ldap avec le nom du fichier de bibliothèquepartagée correspondant à la plate-forme utilisée, dans la strophe[authentication-mechanism] du fichier de configuration webseald.conf. Parexemple :

Solaris :[authentication-mechanisms]passwd-ldap = libldapauthn.so

Windows :[authentication-mechanisms]passwd-ldap = ldapauthn.dll

Conditions de configurationSi l’authentification par formulaires est activée pour un transport spécifique, lesparamètres de l’authentification de base correspondants seront ignorés.

Configuration de l’authentification à base de formulairesAccess Manager propose l’authentification par formulaires comme solutionalternative à la méthode classique d’authentification de base. Avec cette méthode,un masque (ou formulaire) de connexion HTML personnalisé est fourni par AccessManager au lieu de l’invite de connexion classique résultant d’une demanded’authentification de base.

Lorsque vous utilisez une connexion par formulaires, le navigateur ne place pas lesinformations de nom d’utilisateur et de mot de passe dans la mémoire cache,comme avec une authentification de base.

Activation et désactivation de l’authentification parformulaires

Le paramètre forms-auth, situé dans la strophe [forms] du fichier de configurationwebseald.conf, active et désactive la méthode d’authentification par formulaires.v Pour activer la méthode d’authentification par formulaires, entrez “http”, “https”

ou “both”.v Pour désactiver la méthode d’authentification par formulaires, entrez “none”.

Chapitre 5. Authentification WebSEAL 127

Page 148: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Par exemple :[forms]forms-auth = https

Configuration de la méthode d’authentification par formulairesLe paramètre passwd-ldap définit la bibliothèque partagée utilisée pour gérerl’authentification par nom d’utilisateur et mot de passe.v Sous UNIX, le fichier fournissant la fonction de mappage intégrée est la

bibliothèque partagée libldapauthn.v Sous Windows, le fichier fournissant la fonction de mappage intégrée est la DLL

ldapauthn.

Méthoded’authentification

Bibliothèque partagée

Solaris AIX Windows HP-UX

passwd-ldap libldapauthn.so libldapauthn.a ldapauthn.dll libldapauthn.sl

Pour configurer la méthode d’authentification par nom d’utilisateur et mot depasse, entrez le paramètre passwd-ldap avec le nom du fichier de bibliothèquepartagée correspondant à la plate-forme utilisée, dans la strophe[authentication-mechanism] du fichier de configuration webseald.conf. Parexemple :

Solaris :[authentication-mechanisms]passwd-ldap = libldapauthn.so

Windows :[authentication-mechanisms]passwd-ldap = ldapauthn.dll

Conditions de configurationSi l’authentification par formulaires est activée pour un transport spécifique, lesparamètres de l’authentification de base correspondants seront ignorés.

Personnalisation des formulaires de réponse HTMLL’authentification par formulaires exige que vous utilisiez un formulaire deconnexion personnalisé. Par défaut, le formulaire modèle login.html est situé dansle répertoire suivant :<répertoire_installation>/lib/html

128 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 149: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Vous pouvez personnaliser le contenu et l’aspect de ce formulaire. Par exemple :

Pour plus d’informations sur les formulaires HTML disponibles à personnaliser,reportez-vous à la section «Gestion des pages personnalisées de gestion decomptes» à la page 37.

Configuration de l’authentification par certificat côté clientWebSEAL prend en charge les communications sécurisées avec les clients grâce àdes certificats numériques côté client via SSL. Avec cette méthoded’authentification, les informations de certificat (comme le nom distinctif ou DN)sont mises en correspondance avec une identité Access Manager.

Contexte : Authentification réciproque via des certificatsL’échange de certificats côté serveur et côté client via SSL permet d’obtenir unerelation sécurisée entre le client et le serveur sur la base des certificats. Une voie detransmission sécurisée est également établie.

L’établissement de liaison entre les certificats numériques SSL, qui aboutit à uneauthentification réciproque, a lieu en deux phases :v WebSEAL s’identifie auprès des clients SSL avec son certificat côté serveur.v WebSEAL se réfère à la base de données de certificats racine de l’autorité de

certification (CA) pour valider les clients dotés de certificats côté client1. Un client SSL demande une connexion à un serveur WebSEAL via SSL.2. En réponse, WebSEAL envoie sa clé publique via un certificat signé côté

serveur. Ce certificat a été préalablement signé par une autorité de certification(CA) tierce digne de confiance.

3. Le client vérifie si l’émetteur du certificat est fiable. Le navigateur du clientcontient habituellement une liste de certificats racine provenant de CA dignesde confiance. Si la signature du certificat WebSEAL correspond à l’une de cescertificats racine, le serveur peut être jugé fiable.

Figure 23. Exemple de formulaire de connexion WebSEAL

Chapitre 5. Authentification WebSEAL 129

Page 150: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

4. Si la signature ne correspond à rien, le navigateur informe son utilisateur quece certificat a été émis par une autorité de certification inconnue. Il incombealors à l’utilisateur d’accepter ou de refuser le certificat.

5. Si la signature correspond à une entrée de la base de données des certificatsracine du navigateur, les clés de la session sont négociées de façon sécuriséeentre le client et le serveur WebSEAL.Le résultat final de ce processus est une voie de transmission sécurisée.

6. Le client envoie alors son certificat de clé publique au serveur WebSEAL.7. WebSEAL essaie de faire correspondre la signature du certificat client à une

CA connue. Comme le navigateur d’un client, le serveur WebSEAL conserveune liste de certificats racine provenant de CA dignes de confiance dans sabase de données de clés.

8. En l’absence de toute correspondance avec la signature, WebSEAL génère uncode d’erreur SSL qu’il envoie au client.

9. Si une correspondance existe avec la signature, le certificat est fiable.10. Access Manager authentifie le client grâce à l’utilisation de la bibliothèque

partagée intégrée, afin d’obtenir une correspondance exacte entre le nom (DN)de la zone Sujet du certificat côté client et une entrée DN existante dans leregistre LDAP, ou encore via l’utilisation d’un CDAS personnalisé poureffectuer une autre mise en correspondance d’identités.Le résultat d’une authentification effectuée avec succès est une identité AccessManager qui est ensuite utilisée pour la création des données d’autorisationde cet utilisateur. Ces données d’autorisation sont nécessaires pour que leclient puisse participer au domaine sécurisé Access Manager.

Certificat de test WebSEALA l’installation, WebSEAL contient un certificat de serveur de test d’auto-signature.Bien que ce dernier lui permette de répondre à une requête d’un navigateur SSL, ilne peut pas être vérifié par le navigateur (qui ne contient pas de certificatd’autorité de certification racine approprié). Comme la clé privée de ce certificatpar défaut se trouve dans chaque distribution WebSEAL, ce certificat n’assure pasde véritables communications sécurisées.

Pour garantir des communications sécurisées via SSL, il est très important des’inscrire à un certificat de serveur de site unique, et de l’obtenir auprès d’uneautorité de certification digne de confiance. Vous pouvez utiliser l’utilitaire GSKitiKeyman pour générer une demande de certificat qui est envoyée à la CA. Vouspouvez également vous servir de iKeyman pour installer le nouveau certificat de

Requête

Client

Réponse

Serveur WebSEAL

« Je peux me fier à votre identité. »

verisign

www.tivoli.com

ID numériquedu serveur

belsigncertisignentrustverisign

...

Certificats racinede CA du navigateur

Figure 24. Le client valide le certificat WebSEAL

130 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 151: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

site et lui affecter un libellé. Utilisez le paramètre webseal-cert-keyfile-labelcontenu dans la strophe [ssl] du fichier de configuration webseald.conf pourdésigner le certificat comme certificat côté serveur WebSEAL actif (ce paramètreremplace tous les certificats désignés comme certificats “par défaut” dans la basede données du fichier de clés).

Si vous avez besoin de différents certificats pour d’autres scénarios (par exemple,pour les jonctions authentifiées de façon réciproque), vous pouvez utiliserl’utilitaire iKeyman pour créer ces certificats supplémentaires, les installer et leuraffecter un libellé.

Voir la section «Configuration de paramètres de base de données de clés» à la page41.

Activation et désactivation de l’authentification par certificatVous pouvez spécifier la façon dont WebSEAL doit gérer l’authentification aumoyen de certificats côté client via SSL en définissant le paramètreaccept-client-certs, situé dans la strophe [certificate] du fichier de configurationwebseald.conf.

Par défaut, WebSEAL n’accepte pas les certificats côté client :[certificate]accept-client-certs = never

Les autres valeurs de ce paramètre sont optional et required.

Le tableau ci-après répertorie les valeurs autorisées du paramètreaccept-client-certs :

Valeur Description

never N’accepte pas les certificats X.509 des clients.

optional Demande aux clients un certificat X.509 et utilise uneauthentification basée sur certificat, si un certificat est fourni.

required Demande aux clients un certificat X.509 et utilise uneauthentification basée sur certificat. Si le client ne présente pas decertificat, ne permet pas de connexion.

Configuration de la méthode d’authentification par certificatLe paramètre cert-ssl spécifie la bibliothèque partagée servant au mappage desinformations sur l’authentification par certificat.v Sous UNIX, le fichier fournissant la fonction de mappage intégrée est la

bibliothèque partagée libsslauthn.v Sous Windows, le fichier fournissant la fonction de mappage intégrée est la DLL

sslauthn.

Méthoded’authentification

Bibliothèque partagée

Solaris AIX Windows HP-UX

cert-ssl libsslauthn.so libsslauthn.a sslauthn.dll libsslauthn.sl

Chapitre 5. Authentification WebSEAL 131

Page 152: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Pour configurer la méthode d’authentification par certificat, entrez le paramètrecert-ssl avec le nom du fichier de bibliothèque partagée correspondant à laplate-forme utilisée dans la strophe [authentication-mechanism] du fichier deconfiguration webseald.conf.

Solaris :[authentication-mechanisms]cert-ssl= libsslauthn.so

Windows :[authentication-mechanisms]cert-ssl = sslauthn.dll

Au cours de l’authentification par certificat, la bibliothèque partagée identifiel’utilisateur Access Manager en faisant correspondre le nom (DN) de la zone Sujetdu certificat côté client et une entrée DN existante dans le registre LDAP.

Conditions de configurationSi le paramètre accept-client-certs (acceptation des certificats côté client) a la valeur“required”, tous les autres paramètres d’authentification sont ignorés pour lesclients HTTPS.

Configuration de l’authentification par en-tête HTTPAccess Manager prend en charge l’authentification au moyen d’informationsd’en-tête HTTP personnalisées fournies par le client ou par un agent proxy.

Cette méthode exige une fonction de mappage (une bibliothèque partagée) qui faitcorrespondre les données d’en-tête sécurisées (avant authentification) avec uneidentité Access Manager. A partir de cette identité, WebSEAL peut créer des droitsd’accès pour l’utilisateur.

Les données d’en-tête HTTP personnalisées sont supposées avoir été préalablementauthentifiées. C’est la raison pour laquelle il est recommandé de mettre en oeuvrecette méthode de façon exclusive (sans qu’aucune autre méthode d’authentificationne soit activée). Il est possible d’usurper les données d’en-tête HTTPpersonnalisées.

Par défaut, cette bibliothèque partagée est constituée pour faire correspondre desdonnées provenant d’en-têtes Entrust Proxy.

Activation et désactivation de l’authentification par en-têteHTTP

Le paramètre http-headers-auth, situé dans la strophe [http-headers] du fichier deconfiguration webseald.conf, active et désactive la méthode d’authentification paren-tête HTTP.v Pour activer la méthode d’authentification par en-tête HTTP, entrez “http”,

“https” ou “both”.v Pour désactiver la méthode d’authentification par en-tête HTTP, entrez “none”.

Par exemple :[http-headers]http-headers-auth = https

132 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 153: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Spécification de types d’en-têtesVous devez spécifier tous les types d’en-tête HTTP pris en charge dans la strophe[auth-headers] du fichier de configuration webseald.conf.[auth-headers]header = <type_en_tête>

Par défaut, cette bibliothèque intégrée est définie (dans le code) pour prendre encharge les données d’en-tête Entrust Proxy.[auth-headers]header = entrust-client

Vous devez personnaliser ce fichier pour authentifier d’autres types de donnéesd’en-tête spéciales et, éventuellement, faire correspondre ces données à l’identitéAccess Manager. Pour plus d’informations sur les ressources API, reportez-vous audocument IBM Tivoli Access Manager WebSEAL Developer’s Reference.

Configuration de la méthode d’authentification par en-têteHTTP

Le paramètre http-request spécifie la bibliothèque partagée servant au mappagedes informations sur l’authentification par en-tête HTTP.v Sous UNIX, le fichier fournissant la fonction de mappage intégrée est la

bibliothèque partagée libhttpauthn.v Sous Windows, le fichier fournissant la fonction de mappage intégrée est la DLL

httpauthn.

Méthoded’authentification

Bibliothèque partagée

Solaris AIX Windows HP-UX

http-request libhttpauthn.so libhttpauthn.a httpauthn.dll libhttpauthn.sl

Par défaut, cette bibliothèque partagée intégrée est définie dans le code pourmapper les données d’en-tête Entrust Proxy à une identité Access Manager valide.Vous devez personnaliser ce fichier pour authentifier d’autres types de donnéesd’en-tête spéciales et, éventuellement, faire correspondre ces données à l’identitéAccess Manager. Pour plus d’informations sur les ressources API, reportez-vous audocument IBM Tivoli Access Manager WebSEAL Developer’s Reference.

Pour configurer la méthode d’authentification par en-tête HTTP, entrez leparamètre http-request avec le nom du fichier de bibliothèque partagéecorrespondant à la plate-forme utilisée dans la strophe [authentication-mechanism]du fichier de configuration webseald.conf.

Par exemple :

Solaris :[authentication-mechanisms]http-request = libhttpauthn.so

Windows :[authentication-mechanisms]http-request = httpauthn.dll

Chapitre 5. Authentification WebSEAL 133

Page 154: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Conditions de configuration1. Les cookies d’ID de session ne sont pas utilisés pour gérer l’état si

ssl-id-sessions = no. La valeur unique de l’en-tête sert à gérer l’état.2. Si le client rencontre un problème d’autorisation, il reçoit une page de type

“Accès interdit” (HTTP 403).3. Les en-têtes de cookies ne peuvent pas être transmis à la méthode

d’authentification par en-tête HTTP.

Configuration de l’authentification par adresse IPAccess Manager prend en charge l’authentification via une adresse IP fournie parle client.

Activation et désactivation de l’authentification par adresse IPLe paramètre ipaddr-auth, situé dans la strophe [ipaddr] du fichier deconfiguration webseald.conf, active et désactive la méthode d’authentification paradresse IP.v Pour activer la méthode d’authentification par adresse IP, entrez “http”, “https”

ou “both”.v Pour désactiver la méthode d’authentification par adresse IP, entrez “none”.

Par exemple :[ipaddr]ipaddr-auth = https

Configuration de la méthode d’authentification par adresse IPL’authentification via une adresse IP nécessite une bibliothèque partagéepersonnalisée. Utilisez le paramètre http-request pour cette bibliothèque partagée.

Configuration de l’authentification par jetonAccess Manager prend en charge l’authentification via un passcode de jeton fournipar le client.

Activation et désactivation de l’authentification par jetonLe paramètre token-auth, situé dans la strophe [token] du fichier de configurationwebseald.conf, active et désactive la méthode d’authentification par jeton.v Pour activer la méthode d’authentification par jeton, entrez “http”, “https” ou

“both”.v Pour désactiver la méthode d’authentification par jeton, entrez “none”.

Par exemple :[token]token-auth = https

Configuration de la méthode d’authentification par jetonLe paramètre token-cdas spécifie la bibliothèque partagée servant au mappage desinformations sur l’authentification par passcode de jeton.v Sous UNIX, le fichier fournissant la fonction de mappage intégrée est la

bibliothèque partagée libxtokenauthn.

134 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 155: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

v Sous Windows, le fichier fournissant la fonction de mappage intégrée est la DLLxtokenauthn.

Méthoded’authentification

Bibliothèque partagée

Solaris AIX Windows HP-UX

token-cdas libxtokenauthn.so libxtokenauthn.a xtokenauthn.dll libxtokenauthn.sl

Par défaut, cette bibliothèque partagée intégrée est définie dans le code pourmapper les données de passcode de jeton SecurID. Vous pouvez personnaliser cefichier pour authentifier d’autres types de données d’en-tête spéciales et,éventuellement, faire correspondre ces données à une identité Access Manager.Pour plus d’informations sur les ressources API, reportez-vous au document IBMTivoli Access Manager WebSEAL Developer’s Reference.

Pour configurer la méthode d’authentification par jeton, entrez le paramètretoken-cdas avec le nom du fichier de bibliothèque partagée correspondant à laplate-forme utilisée dans la strophe [authentication-mechanism] du fichier deconfiguration webseald.conf. La bibliothèque partagée doit inclure l’option etl’argument –r <registre>. Le type de registre doit être spécifié en tant que LDAP.

Par exemple :

Solaris :[authentication-mechanisms]token-cdas = libxtokenauthn.so& -r LDAP

Windows :[authentication-mechanisms]token-cdas = xtokenauthn.dll& -r LDAP

Prise en charge du multiplexage d’agents proxyAccess Manager fournit des solutions de protection des réseaux à l’aide d’un agentMPA (Multiplexing Proxy Agent).

Les agents SPA (Standard Proxy Agents) sont des passerelles prenant en charge dessessions client par client entre des clients et le serveur d’origine, via protocole SSLou HTTP. WebSEAL peut appliquer une authentification SSL ou HTTP normale àces sessions.

Les agents MPA (Multiplexing Proxy Agents) sont des passerelles qui permettentl’accès de plusieurs clients. Elles sont quelquefois appelées passerelles WAPlorsque les clients ont un accès via un protocole WAP (Wireless Access Protocol).Les passerelles établissent un unique canal authentifié vers le serveur d’origine parlequel ils “font transiter” toutes les requêtes et réponses du client.

Pour WebSEAL, les informations transitant par cette voie apparaissent initialementcomme plusieurs requêtes émanant d’un seul client. WebSEAL doit effectuer unedistinction entre l’authentification du serveur MPA et l’authentificationsupplémentaire de chaque client.

Chapitre 5. Authentification WebSEAL 135

Page 156: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Dans la mesure où WebSEAL gère une session authentifiée pour l’agent MPA, ildoit gérer simultanément des sessions séparées pour chaque client. Les données desession et la méthode d’authentification utilisée pour l’agent MPA doivent doncêtre différentes de celles du client.

Types de données de session valides et méthodesd’authentification

Le type de données de session utilisé par l’agent MPA auprès de WebSEAL doitêtre distinct (différent) de celui du client. Le tableau ci-après répertorie les types desession valides pour l’agent MPA et le client :

Types de session valides

Agent MPA / WebSEAL Client / WebSEAL

ID de session SSL

En-tête HTTP En-tête HTTP

En-tête BA En-tête BA

Adresse IP

Cookie Cookie

v Le client ne peut utiliser l’ID de session SSL comme type de données de session.v Par exemple, si l’agent MPA utilise un en-tête BA comme type de données de

session, le client a le choix entre l’en-tête HTTP et le cookie uniquement.v Si l’agent MPA utilise un en-tête HTTP comme données de session, le client peut

utiliser un type d’en-tête HTTP différent.v Le cookie du serveur ne contient que des informations de session ; il ne contient

pas d’informations d’identité.v Si la prise en charge de l’agent MPA est activée, la fonction de ssl-id-sessions est

modifiée. Normalement, si ssl-id-sessions=yes, seul l’ID de session SSL estutilisé pour gérer les sessions des clients HTTPS. Pour permettre à l’agent MPAde gérer une session avec un ID de session SSL et aux clients d’en gérer avecune autre méthode, cette restriction est supprimée. Voir aussi la section«Détermination des types de données d’ID de session valides» à la page 118.

ClientB

PasserelleMPA

� plusieurs sessions sur un seul canal SSL� MPA s’authentifie auprès de WebSEAL� MPA est membre du groupe webseal-mpa-servers

ServeurWebSEAL

ClientA

ClientC

A B C

� les clients s’authentifient auprès de WebSEAL

Figure 25. Communications via une passerelle MPA

136 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 157: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

La méthode d’authentification utilisée par l’agent MPA auprès de WebSEAL doitêtre distincte (différente) de celle du client. Le tableau ci-après répertorie lesméthodes d’authentification valides pour l’agent MPA et le client :

Types d’authentification valides

Agent MPA / WebSEAL Client / WebSEAL

Authentification de base Authentification de base

Formulaires Formulaires

Jeton Jeton

En-tête HTTP En-tête HTTP

Certificat

Adresse IP

v Par exemple, si l’agent MPA utilise l’authentification de base, le client a le choixentre l’authentification par formulaires, par jeton et par en-tête HTTP.

v Les méthodes d’authentification par certificats et par adresse IP ne sont pasutilisables par le client.

v Normalement, si l’authentification par formulaires (ou par jeton) est activée pourun transport spécifique, l’authentification de base est automatiquementdésactivée pour ce transport (voir la section «Configuration de la méthoded’authentification de base» à la page 127). Si la prise en charge de l’agent MPAest activée, cette restriction est supprimée. Cela permet, d’une part, à l’agentMPA de se connecter, par exemple avec des formulaires (ou des jetons) et,d’autre part, aux clients de se connecter à l’aide de l’authentification de base viale même transport.

Flux de processus d’authentification pour les agents MPA etdes clients multiples

1. L’administrateur WebSEAL effectue la configuration préliminaire suivante :v Activation de la prise en charge des agents MPAv Création d’un compte Access Manager pour la passerelle MPA spécifiquev Ajout de ce compte MPA au groupe webseal-mpa-servers

2. Les clients se connectent à la passerelle MPA.3. La passerelle convertit la requête en requête HTTP.4. La passerelle authentifie le client.5. La passerelle établit une connexion à WebSEAL, avec la requête du client.6. WebSEAL authentifie l’agent MPA (avec une méthode différente de celle du

client) et déduit son identité (lequel MPA détient déjà un compte WebSEAL).7. WebSEAL vérifie l’appartenance de l’agent MPA au groupe

webseal-mpa-servers.8. Un droit d’accès est établi pour le MPA et marqué comme type de MPA

spécial dans la mémoire cache.Bien que ce droit d’accès MPA accompagne chaque nouvelle requête du client,il n’est pas utilisé pour les contrôles d’autorisation menés sur ces requêtes.

9. WebSEAL doit maintenant identifier plus précisément le propriétaire de larequête.L’agent MPA est capable de faire la distinction entre les différents clients pouracheminer correctement les invites de connexion.

Chapitre 5. Authentification WebSEAL 137

Page 158: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

10. Le client se connecte et s’authentifie à l’aide d’une méthode différente du typed’authentification utilisé par l’agent MPA.

11. WebSEAL crée un droit d’accès à partir des informations d’authentification duclient.

12. Le type de données de session utilisé par chaque client doit être différent decelui de l’agent MPA.

13. Le service d’autorisation accorde ou refuse l’accès aux objets protégés, en sefondant sur les droits d’accès de l’utilisateur et sur les droits d’accès de LCAdes objets.

Activation et désactivation de l’authentification MPALe paramètre mpa, situé dans la strophe [mpa] du fichier de configurationwebseald.conf, active et désactive l’authentification MPA :v Pour activer la méthode d’authentification MPA, entrez “yes”.v Pour désactiver la méthode d’authentification MPA, entrez “no”.

Par exemple :[mpa]mpa = yes

Création d’un compte utilisateur pour l’agent MPAPour plus d’informations sur la création de comptes utilisateur, reportez-vous audocument IBM Tivoli Access Manager Base Administrator’s Guide.

Ajout du compte MPA au groupe webseal-mpa-serversPour plus d’informations sur la gestion de groupes, reportez-vous au documentIBM Tivoli Access Manager Base Administration Guide.

Limites de l’authentification MPACette édition de Access Manager n’accepte qu’un agent MPA par serveurWebSEAL.

Configuration de la nouvelle authentification sur la base de la stratégiede sécurité

Access Manager WebSEAL peut forcer un utilisateur à effectuer une nouvelleconnexion (nouvelle authentification) afin de s’assurer que l’utilisateur qui accède àune ressource protégée est bien la même personne que celle qui s’est authentifiéeau début de la session. La nouvelle authentification peut être activée via des règlesPOP (Protected Object Policy) sur l’objet protégé ou à l’expiration de la duréed’inactivité du cache de session WebSEAL.

Cette section décrit la nouvelle authentification effectuée sur la base des règles desécurité spécifiées par l’un des attributs étendus POP.

Conditions affectant la nouvelle authentification POPLa nouvelle authentification forcée offre une protection supplémentaire pour lesressources sensibles du domaine sécurisé. La nouvelle authentification prenantcomme base des règles de sécurité est activée par un attribut étendu spécifique ausein d’une règle POP qui protège l’objet ressource demandé. Cette règle POP peutêtre associée directement à l’objet, ou encore l’objet peut hériter des conditionscorrespondantes en provenance d’un objet parent.

138 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 159: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

La nouvelle authentification est prise en charge par les méthodes suivantesd’authentification WebSEAL :v Authentification par formulaires (nom d’utilisateur et mot de passe)v Authentification par jeton

En outre, il est possible d’écrire un CDAS personnalisé de nom d’utilisateur/motde passe en tant que support de la nouvelle authentification.

La nouvelle authentification suppose que l’utilisateur se soit initialement connectéau domaine sécurisé et que des données d’autorisation valides existent pour cetutilisateur. Pendant la nouvelle authentification, l’utilisateur doit se connecter enutilisant la même identité que celle générée par les droits d’accès existants. AccessManager conserve les informations relatives à la première session de l’utilisateur (ycompris les droits d’accès) pendant la nouvelle authentification. Les droits d’accèsne sont pas remplacés pendant la nouvelle authentification.

Au cours de la nouvelle authentification, WebSEAL place également en mémoirecache la requête à l’origine de cette nouvelle authentification. Si celle-ci aboutit, lesdonnées placées en mémoire cache sont utilisées pour la reconstitution de larequête. Voir la section «Configuration de la mise en mémoire cache des requêtesWebSEAL côté serveur» à la page 72.

En cas d’échec, WebSEAL envoie de nouveau l’invite de connexion. Si la nouvelleauthentification aboutit mais que le contrôle de LCA échoue pour cette ressource,le message 403 (“Accès refusé”) est renvoyé et l’accès à la ressource demandée estrefusé par l’utilisateur. Dans les deux cas, l’utilisateur n’est jamais déconnecté. Ilpeut, en utilisant des droits d’accès toujours valides, abandonner le processus denouvelle authentification (via la demande d’une nouvelle adresse URL) etparticiper malgré tout au domaine sécurisé en accédant à d’autres ressources quine nécessitent pas de nouvelle authentification.

Une configuration permet de réinitialiser la durée de vie du cache de sessionWebSEAL. Par ailleurs, une période de grâce peut être configurée afin d’accorderau processus de nouvelle authentification le temps nécessaire à son traitementavant l’expiration de la durée de vie du cache de session.

Création et application de règles POP de nouvelleauthentification

La nouvelle authentification effectuée sur la base de règles de sécurité estconfigurée via la création d’une règle POP (Protected Object Policy) incluant unattribut étendu spécifique appelé “reauth”. Vous pouvez associer cette règle POP àtout objet nécessitant la protection supplémentaire que représente une nouvelleauthentification forcée.

Souvenez-vous que tous les enfants de l’objet associé à la règle POP héritentégalement des conditions de cette règle. Chaque objet enfant demandé nécessiteune nouvelle authentification séparée.

Utilisez les commandes pdadmin pop create, pdadmin pop modify et pdadminpop attach. L’exemple suivant illustre la création d’une règle POP appelée “secure”à l’aide de l’attribut étendu reauth et de son association à un objet (budget.html) :pdadmin> pop create securepdadmin> pop modify secure set attribute reauth truepdadmin> pop attach /WebSEAL/hostA/junction/budget.html secure

Chapitre 5. Authentification WebSEAL 139

Page 160: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Toute personne tentant d’accéder au fichier budget.html doit effectuer une nouvelleauthentification à l’aide de la même identité et de la même méthoded’authentification que celles générées par les données d’autorisation existantes.

Si l’utilisateur émettant la demande de ressource n’est pas authentifié, la règle POPforce l’utilisateur à s’authentifier. Aucune nouvelle authentification n’est requisepour cette ressource une fois qu’une connexion initiale a été établie avec succès.

Vous trouverez des informations détaillées sur l’utilitaire de ligne de commandepdadmin dans le document IBM Tivoli Access Manager Base Administrator’s Guide.

Configuration de la réinitialisation et de l’allongement de ladurée de vie du cache de session

Réinitialisation du délai d’expiration du cache de sessionLe cache de session de l’utilisateur a un délai d’expiration limité, spécifié par leparamètre timeout de la strophe [session] du fichier de configurationwebseald.conf configuration file. La valeur par défaut, en minutes, est 3600 (1heure) :[session]timeout = 3600

Que la session soit active ou inactive, le cache de session est supprimé une fois quela valeur de délai d’expiration est atteinte. L’utilisateur est alors déconnecté.

Toutefois, vous pouvez configurer une réinitialisation du délai d’expiration ducache de session lors de chaque nouvelle authentification. Grâce à cetteconfiguration, la session utilisateur ne contient plus une seule valeur de délaid’expiration maximal. Chaque fois qu’une nouvelle authentification a lieu, lavaleur de délai d’expiration du cache de session est réinitialisée.

Vous pouvez configurer la réinitialisation du délai d’expiration du cache de sessionà l’aide du paramètre reauth-reset-lifetime de la strophe [reauthentication] dufichier de configuration webseald.conf :[reauthentication]reauth-reset-lifetime = yes

La valeur par défaut est “no”.

Ce paramètre est également adapté à la nouvelle authentification due à l’expirationdu délai d’inactivité du cache de session. Voir la section «Configuration de lanouvelle authentification sur la base de la règle d’inactivité de session» à la page141.

Allongement du délai d’expiration du cache de sessionIl est possible qu’une valeur de délai d’expiration de cache de session soit atteintealors que l’utilisateur effectue une nouvelle authentification. Cette situation seproduit dans les cas suivants :v L’utilisateur demande une ressource protégée par une règle POP de nouvelle

authentificationv La valeur de délai d’expiration du cache de session est très proche du délai

d’expiration

Le cache de session peut arriver à expiration après l’envoi à l’utilisateur duformulaire de connexion pour la nouvelle authentification et avant que ce

140 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 161: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

formulaire rempli ne soit renvoyé. Lorsque le cache de session arrive à expiration,l’entrée correspondante est supprimée. Lorsque le formulaire de connexion estrenvoyé à WebSEAL, la session n’est plus établie pour cet utilisateur. En outre,toutes les données de requête utilisateur placées en mémoire cache sont perdues.

Vous pouvez configurer un allongement (ou “période de grâce”) du délaid’expiration du cache de session pour le cas où ce délai arriverait à son termependant la nouvelle authentification. Le paramètre reauth-extend-lifetime de lastrophe [reauthentication] du fichier de configuration webseald.conf contient cetallongement (exprimé en secondes). Par exemple :[reauthentication]reauth-extend-lifetime = 20

La valeur par défaut (“0”) ne prévoit aucun allongement de la valeur de délaid’expiration du cache de session.

Le paramètre reauth-extend-lifetime s’applique aux utilisateurs possédant desentrées existantes de cache de session et devant effectuer une nouvelleauthentification. Par exemple :v Utilisateurs effectuant une nouvelle authentification à la suite de l’application de

règles de sécurité POPv Utilisateurs effectuant une nouvelle authentification à la suite de l’inactivité du

cache de sessionv Utilisateurs effectuant une nouvelle authentification pas à pas

L’option reauth-extend-lifetime doit être utilisée en association avec l’optionreauth-reset-lifetime=yes.

Ce paramètre est également adapté à la nouvelle authentification due à l’expirationdu délai d’inactivité du cache de session. Voir la section «Configuration de lanouvelle authentification sur la base de la règle d’inactivité de session» à la page141.

Configuration de la nouvelle authentification sur la base de la règled’inactivité de session

Access Manager WebSEAL peut forcer un utilisateur à effectuer une nouvelleconnexion (nouvelle authentification) afin de s’assurer que l’utilisateur qui accède àune ressource protégée est bien la même personne que celle qui s’est authentifiéeau début de la session. La nouvelle authentification peut être activée via des règlesPOP (Protected Object Policy) sur l’objet protégé ou à l’expiration de la duréed’inactivité du cache de session WebSEAL.

Cette section décrit la nouvelle authentification effectuée sur la base de l’expirationdu délai d’inactivité du cache de session.

Conditions affectant la nouvelle authentification pourinactivité

La nouvelle authentification forcée offre une protection supplémentaire pour lesressources sensibles du domaine sécurisé. La nouvelle authentification effectuée enraison de l’inactivité d’une session est activée grâce à un paramètre deconfiguration et est déclenchée par l’expiration de la valeur de délai d’inactivité ducache de session.

Chapitre 5. Authentification WebSEAL 141

Page 162: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

La nouvelle authentification est prise en charge par les méthodes suivantesd’authentification WebSEAL :v Authentification par formulaires (nom d’utilisateur et mot de passe)v Authentification par jeton

En outre, il est possible d’écrire un CDAS personnalisé de nom d’utilisateur/motde passe en tant que support de la nouvelle authentification.

La nouvelle authentification suppose que l’utilisateur se soit initialement connectéau domaine sécurisé et que des données d’autorisation valides existent pour cetutilisateur. Pendant la nouvelle authentification, l’utilisateur doit se connecter enutilisant la même identité que celle générée par les droits d’accès existants.WebSEAL conserve les informations relatives à la première session de l’utilisateur(y compris les droits d’accès) pendant la nouvelle authentification. Les droitsd’accès ne sont pas remplacés pendant la nouvelle authentification.

Au cours de la nouvelle authentification, WebSEAL place également en mémoirecache la requête à l’origine de cette nouvelle authentification. Si celle-ci aboutit, lesdonnées placées en mémoire cache sont utilisées pour la reconstitution de larequête. Voir la section «Configuration de la mise en mémoire cache des requêtesWebSEAL côté serveur» à la page 72.

La session d’un utilisateur est normalement régulée par une valeur d’inactivité desession et par une valeur de délai d’expiration de session. Lorsque WebSEAL estconfiguré pour la nouvelle authentification sur la base de l’inactivité de session, lecache de session de l’utilisateur porte un “indicateur” chaque fois que le délaid’inactivité de la session arrive à expiration. Le cache de session (contenant lesdonnées d’autorisation de l’utilisateur) n’est pas supprimé. L’utilisateur peut alorsaccéder aux ressources non protégées. Toutefois, si l’utilisateur demande l’accès àune ressource protégée, WebSEAL envoie une invite de connexion.

Si la nouvelle authentification aboutit, l’“indicateur” de session inactive estsupprimé et le délai d’inactivité est réinitialisé. Toutefois, la valeur de délaid’expiration du cache de session détermine principalement la longueur maximalede session. Lorsque cette valeur arrive à expiration, la session prend fin quelle quesoit l’activité.

En cas d’échec de la nouvelle authentification, WebSEAL envoie de nouveaul’invite de connexion. Le cache de session porte encore l’“indicateur” et l’utilisateurpeut poursuivre en tant qu’utilisateur non authentifié jusqu’à expiration du délaid’expiration du cache de session.

Si la nouvelle authentification aboutit mais que le contrôle de LCA échoue pourcette ressource, le message 403 (“Accès refusé”) est renvoyé et l’accès à la ressourcedemandée est refusé par l’utilisateur.

Deux autres situations peuvent mettre fin à une session utilisateur : l’utilisateur sedéconnecte volontairement ou l’administrateur met fin à une session utilisateur.Voir la section «Fin des sessions utilisateurs» à la page 229.

Une configuration permet de réinitialiser le délai d’expiration du cache de sessionWebSEAL. Par ailleurs, une période de grâce peut être configurée afin d’accorderau processus de nouvelle authentification le temps nécessaire à son traitementavant l’expiration du délai d’expiration du cache de session.

142 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 163: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Activation de la nouvelle authentification pour inactivitéPour configurer WebSEAL en “signalant” les sessions inactives plutôt qu’en lessupprimant du cache de session, affectez au paramètre reauth-for-inactive lavaleur “yes” dans la strophe [reauthentication] du fichier de configurationwebseald.conf :[reauthentication]reauth-for-inactive = yes

La valeur par défaut de ce paramètre est “no”.

Configuration de la réinitialisation et de l’allongement de ladurée de vie du cache de session

Réinitialisation du délai d’expiration du cache de sessionLe cache de session de l’utilisateur a un délai d’expiration limité, spécifié par leparamètre timeout de la strophe [session] du fichier de configurationwebseald.conf configuration file. La valeur par défaut, en minutes, est 3600 (1heure) :[session]timeout = 3600

Que la session soit active ou inactive, le cache de session est supprimé une fois quela valeur de délai d’expiration est atteinte. L’utilisateur est alors déconnecté.

Toutefois, vous pouvez configurer une réinitialisation du délai d’expiration ducache de session lors de chaque nouvelle authentification. Grâce à cetteconfiguration, la session utilisateur ne contient plus une seule valeur de délaid’expiration maximal. Chaque fois qu’une nouvelle authentification a lieu, lavaleur de délai d’expiration du cache de session est réinitialisée.

Vous pouvez configurer la réinitialisation du délai d’expiration du cache de sessionà l’aide du paramètre reauth-reset-lifetime de la strophe [reauthentication] dufichier de configuration webseald.conf :[reauthentication]reauth-reset-lifetime = yes

La valeur par défaut est “no”.

Ce paramètre est également adapté à la nouvelle authentification due àl’application d’une règle de sécurité POP. Voir la section «Configuration de lanouvelle authentification sur la base de la stratégie de sécurité» à la page 138.

Allongement du délai d’expiration du cache de sessionIl est possible qu’une valeur de délai d’expiration de cache de session soit atteintealors que l’utilisateur effectue une nouvelle authentification. Cette situation seproduit dans les cas suivants :v L’utilisateur demande une ressource protégée par une règle POP de nouvelle

authentificationv La valeur de délai d’expiration du cache de session est très proche du délai

d’expiration

Le cache de session peut arriver à expiration après l’envoi à l’utilisateur duformulaire de connexion pour la nouvelle authentification et avant que ceformulaire rempli ne soit renvoyé. Lorsque le cache de session arrive à expiration,l’entrée correspondante est supprimée. Lorsque le formulaire de connexion est

Chapitre 5. Authentification WebSEAL 143

Page 164: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

renvoyé à WebSEAL, la session n’est plus établie pour cet utilisateur. En outre,toutes les données de requête utilisateur placées en mémoire cache sont perdues.

Vous pouvez configurer un allongement (ou “période de grâce”) du délaid’expiration du cache de session pour le cas où ce délai arriverait à son termependant la nouvelle authentification. Le paramètre reauth-extend-lifetime de lastrophe [reauthentication] du fichier de configuration webseald.conf contient cetallongement (exprimé en secondes). Par exemple :[reauthentication]reauth-extend-lifetime = 20

La valeur par défaut (“0”) ne prévoit aucun allongement de la valeur de délaid’expiration du cache de session.

Le paramètre reauth-extend-lifetime s’applique aux utilisateurs possédant desentrées existantes de cache de session et devant effectuer une nouvelleauthentification. Par exemple :v Utilisateurs effectuant une nouvelle authentification à la suite de l’application de

règles de sécurité POPv Utilisateurs effectuant une nouvelle authentification à la suite de l’inactivité du

cache de sessionv Utilisateurs effectuant une nouvelle authentification pas à pas

L’option reauth-extend-lifetime doit être utilisée en association avec l’optionreauth-reset-lifetime=yes.

Ce paramètre est également adapté à la nouvelle authentification due àl’application d’une règle de sécurité POP. Voir la section «Configuration de lanouvelle authentification sur la base de la stratégie de sécurité» à la page 138.

144 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 165: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Chapitre 6. Solutions de connexion unique interdomaine(CDSSO)

Lorsque WebSEAL est mis en oeuvre en tant que serveur proxy pour protéger undomaine sécurisé, il est souvent nécessaire de fournir des solutions de connexionunique (SSO) aux ressources. Ce chapitre traite de deux solutions de connexionunique interdomaine (CDSSO).

Index des rubriques :v «Configuration de l’authentification CDSSO» à la page 145v «Configuration de la connexion unique de communauté électronique» à la page

149

Configuration de l’authentification CDSSOLe mécanisme CDSSO (Cross-Domain Domain Single Sign-on ou connexion uniqueinterdomaine) d’Access Manager permet de transférer les données d’autorisationd’un utilisateur entre plusieurs domaines sécurisés. CDSSO permet aux utilisateursWeb d’effectuer une connexion unique et de passer en douceur d’un domainesécurisé à un autre. La méthode d’authentification CDSSO ne repose pas sur unserveur d’authentification principal (voir la section Configuration de la connexionunique de la communauté électronique).

CDSSO répond aux objectifs d’une architecture de réseau évolutive en permettantl’intégration de plusieurs domaines sécurisés. Par exemple, il est possible de mettresur pied un grand extranet d’entreprise à partir d’au moins deux domainesuniques, chacun possédant ses propres utilisateurs et espace objet. CDSSO permetaux utilisateurs de passer d’un domaine à l’autre avec une connexion unique.

Lorsqu’un utilisateur demande une ressource située dans un autre domaine, lemécanisme CDSSO transfère un jeton d’identité d’utilisateur d’un domaine àl’autre. Le deuxième domaine dispose alors de l’identité de l’utilisateur (tel qu’ilest authentifié dans le premier domaine), et l’utilisateur n’est pas obligé d’effectuerune autre connexion.

Intégration d’une bibliothèque partagée CDMFDans plusieurs scénarios CDSSO, il se peut que le mappage un à un par défautentre les utilisateurs de différents domaines ne répondent pas à tous les besoins enmatière de déploiement.

L’interface de programmation CDMF (Cross-domain Domain MappingFrameWork) permet de créer une bibliothèque partagée personnalisée pouvantgérer des attributs utilisateur étendus et fournir des services de mappage pourl’identité des utilisateurs.

L’interface de programmation CDMF permet de personnaliser le mappage desidentités d’utilisateur et de traiter les attributs utilisateur avec une certainesouplesse.

© Copyright IBM Corp. 1999, 2002 145

Page 166: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Flux du processus d’authentification pour CDSSO avec CDMFfigure 26 illustre la description du flux de processus suivant.1. Tout utilisateur souhaitant participer à plusieurs domaines doit posséder un

compte utilisateur valide dans le domaine principal et une identité pouvant êtremappée dans un compte valide dans chacun des domaines distantsparticipants.Un utilisateur peut appeler la fonctionnalité CDSSO sans s’authentifierpréalablement auprès d’un domaine sécurisé initial (A) contenant le compte del’utilisateur.

2. L’utilisateur effectue une requête d’accès à une ressource se trouvant dans ledomaine B via un lien personnalisé sur une page Web.Le lien contient une expression CDSSO spéciale :/pkmscdsso?<URL_de_destination>

Par exemple :/pkmscdsso?https://www.domainB.com/index.html

3. La requête est tout d’abord traitée par le serveur WebSEAL dans le domaine A.WebSEAL établit un jeton d’authentification contenant l’identité AccessManager de l’utilisateur (nom abrégé), le domaine courant (“A”), desinformations supplémentaires sur l’utilisateur ainsi qu’une horodate.Les autres informations sur l’utilisateur sont obtenues en appelant labibliothèque partagée CDMF personnalisée (cdmf_get_usr_attributes). Celle-cifournit des attributs utilisateur que peut utiliser le domaine B lors du processusde mappage des utilisateurs.La norme Triple DES de WebSEAL chiffre ces données de jeton avec la clésymétrique générée par l’utilitaire cdsso_key_gen. Ce fichier de clés est partagéet stocké dans la strophe [cdsso-peers] du fichier de configurationwebseald.conf des serveurs WebSEAL du domaine A et du domaine B.Le jeton contient une horodate configurable (authtoken-lifetime) qui définit sadurée de vie. La valeur d’horodatage, si elle est correctement configurée, peutconstituer une protection contre des tentatives malveillantes de réexécution.

4. Le serveur WebSEAL du domaine A réachemine la requête plus le jeton chiffrévers le navigateur, puis vers le serveur WebSEAL du domaine B(réacheminement HTTP).

5. Le serveur WebSEAL du domaine B utilise sa version du même fichier de cléspour déchiffrer et valider le jeton, comme provenant du domaine de référence.

6. Le serveur WebSEAL du domaine B fait appel à une bibliothèque de méthodesd’authentification CDSSO. A son tour, cette bibliothèque CDSSO fait appel à labibliothèque CDMF personnalisée qui effectue le mappage de l’utilisateurproprement dit (cdmf_map_usr).La bibliothèque CDMF retransmet à la bibliothèque CDSSO l’identité del’utilisateur et, éventuellement, d’autres informations sur ses attributs. Labibliothèque CDSSO utilise ces informations pour créer une autorisation.

7. Le service d’autorisation du domaine B accorde ou refuse l’accès aux objetsprotégés, en se fondant sur les autorisations de l’utilisateur et les droits d’accèsde LCA associés aux objets demandés.

146 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 167: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Activation et désactivation de l’authentification CDSSOLe paramètre cdsso-auth, situé dans la strophe [cdsso] du fichier de configurationwebseald.conf, active et désactive la méthode d’authentification CDSSO.v Pour activer la méthode d’authentification CDSSO, entrez “http”, “https” ou

“both”.v Pour désactiver la méthode d’authentification CDSSO, entrez “none”.

Par exemple :[cdsso]cdsso-auth = https

Configuration de la méthode d’authentification CDSSOLe paramètre de configuration cdsso spécifie la bibliothèque partagée définie dansle code servant au mappage des informations d’authentification.v Sous UNIX, le fichier fournissant la fonction de mappage intégré est la

bibliothèque partagée libcdssoauthn.v Sous Windows, le fichier fournissant la fonction de mappage intégré est le DLL

cdssoauthn.

Méthoded’authentification

Bibliothèque partagée

Solaris AIX Windows HP-UX

cdsso libcdssoauthn.so libcdssoauthn.a cdssoauthn.dll libcdssoauthn.sl

Pour configurer la méthode d’authentification CDSSO, indiquez le paramètre cdssoavec le nom du fichier de bibliothèque partagée correspondant à la plate-formeutilisée, dans la strophe [authentication-mechanism] du fichier de configurationwebseald.conf.

WebSEALA

connexion uniqueClient

Domaine A

/

WebSEALB

Domaine B

/� Le client clique sur le lien vers le domaine B� WebSEAL A CDSSO utilise la bibliothèque CDMF

pour obtenir des informations supplémentairessur l’utilisateur. Puis, il génère et envoie un jetonID chiffré avec requête.

� WebSEAL B déchiffre et valide le jeton� WebSEAL B CDSSO appelle la bibliothèque

partagée CDMF pour le mappage de l’identitéde l’utilisateur.

� Le justificatif est créé et le client participeau domaine B

SSL

BibliothèquepartagéeCDMF

BibliothèquepartagéeCDMF

BibliothèqueCDSSO

/pkmscdsso

Figure 26. Processus de connexion unique interdomaine avec CDMF

Chapitre 6. Solutions de connexion unique interdomaine (CDSSO) 147

Page 168: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Par exemple :

Solaris :[authentication-mechanisms]cdsso = libcdssoauthn.so

Windows :[authentication-mechanisms]cdsso = cdssoauthn.dll

Chiffrement des données d’authentification du jetonWebSEAL doit chiffrer les données d’authentification placées sur le jeton à l’aided’une clé générée par l’utilitaire cdsso_key_gen. Vous devez “synchroniser” cetteclé en partageant le fichier de clés avec chaque serveur WebSEAL de chaquedomaine participant. Chacun des serveurs WebSEAL participant à chaque domainedoit utiliser la même clé.

Remarque : La création et la distribution de fichiers de clés ne fait pas partie duprocessus CDSSO d’Access Manager.

L’utilitaire cdsso_key_gen exige que vous spécifiez l’emplacement (chemin absolu)du fichier de clés lorsque vous l’exécutez :

UNIX : # cdsso_key_gen <chemin_absolu>

Windows : MSDOS> cdsso_key_gen <chemin_absolu>

Entrez l’emplacement de ce fichier de clés dans la strophe [cdsso-peers] du fichierde configuration webseald.conf du serveur WebSEAL de chaque domaine. Leformat inclut le nom de la machine WebSEAL et l’emplacement du fichier de clés :[cdsso-peers]<nom_machine_webseal> =<emplacement_fichier_de_clés>

Exemple de configuration du domaine A :[cdsso-peers]www.domainB.com = <chemin>/A-B.key

Exemple de configuration du domaine B :[cdsso-peers]www.domainA.com = <chemin>/A-B.key

Dans l’exemple ci-dessus, le fichier A-B.key serait généré sur une machine(WebSEAL A, par exemple), puis copié manuellement (et de façon sécurisée) surl’autre machine (WebSEAL B, par exemple).

Configuration de l’horodate du jetonLe jeton contient une horodate configurable qui définit la durée de vie du jetond’identité. Une fois l’horodate expirée, le jeton est considéré comme non valide etn’est plus utilisé. Cette horodate permet d’éviter les tentatives malveillantes deréexécution en définissant une valeur suffisamment courte pour éviter le vol dujeton et sa réexécution pendant sa durée de vie.

148 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 169: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Le paramètre authtoken-lifetime, situé dans la strophe [cdsso] du fichier deconfiguration webseald.conf définit la valeur de la durée de vie du jeton. Lavaleur est exprimée en secondes. La valeur par défaut est 180 :[cdsso]authtoken-lifetime = 180

Vous devez prendre en compte tout décalage horaire entre les domainesparticipants.

Expression des liens HTML CDSSOLes liens HTML à des ressources d’un domaine sécurisé secondaire doiventcontenir une expression CDSSO spéciale :/pkmscdsso?<URL_de_destination>

Par exemple :/pkmscdsso?https://www.domainB.com/index.html

Protection du jeton d’authentificationLe jeton d’authentification ne contient pas d’informations d’authentification(comme un nom d’utilisateur et un mot de passe), mais une identité d’utilisateurqui est sécurisée dans le domaine récepteur. Il convient donc de protéger le jetonlui-même contre le vol et la réexécution.

Pour la protection contre le vol, le protocole SSL est utilisé pour protéger lescommunications entre les serveurs WebSEAL et les utilisateurs. Un vol est possibleau niveau de l’historique du navigateur de l’utilisateur. Veillez à ce que l’horodateait une valeur suffisamment courte pour éviter que le jeton, éventuellement volé,puisse être réutilisé pendant sa durée de vie.

Toutefois, un jeton, même dont la durée de vie aurait expiré, reste vulnérable à desagressions cryptographiques. Si la clé utilisée pour le chiffrer est découverte oucompromise d’une manière ou d’une autre, un utilisateur malveillant pourraitconstituer ses propres jetons.

Ces jetons pourraient alors être introduits dans un “flux pseudo-CDSSO”. Ilsseraient alors impossibles à distinguer des véritables jetons d’authentification pourles serveurs WebSEAL faisant partie du domaine CDSSO. C’est la raison pourlaquelle les clés utilisées pour protéger les jetons doivent être également géréesavec précaution, et modifiées périodiquement.

Configuration de la connexion unique de communauté électroniqueLa connexion unique de la communauté électronique est une autre implémentationde l’authentification interdomaine dans un environnement Access Manager.L’objectif de l’authentification interdomaine consiste à autoriser les utilisateurs àaccéder aux ressources via plusieurs serveurs de différents domaines sans nouvelleauthentification.

Une “communauté électronique” est un groupe de domaines distincts (AccessManager ou DNS) liés par une relation de nature économique. Ces domainesparticipants peuvent être configurés comme appartenant à une seule et mêmeentreprise (et éventuellement sous différents noms DNS pour des raisonsgéographiques) ou à plusieurs entreprises distinctes ayant en commun, parexemple, des locaux, une compagnie d’assurance vie ou une société de gestionfinancière.

Chapitre 6. Solutions de connexion unique interdomaine (CDSSO) 149

Page 170: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Dans chaque scénario, un des domaines est appelé le domaine “d’accueil” ou“propriétaire”. Dans le cas d’entreprises participantes, le domaine d’accueil détientles accords qui régissent la communauté électronique.

Dans les deux scénarios, les informations d’authentification sur les utilisateursappartenant à la communauté électronique (y compris les noms d’utilisateur et lesmots de passe utilisés pour l’authentification) sont conservées dans le domained’accueil. Cette organisation permet de cantonner à un unique point de référenceles questions administratives. Par exemple, toutes les demandes d’assistanceémanant de la communauté électronique sont dirigées vers le domaine d’accueil.

De même, vous pouvez utiliser Access Manager Web Portal Manager pourdéléguer la gestion de ces informations afin que les domaines participantsprennent en charge l’administration de leurs propres utilisateurs.

Le diagramme ci-après illustre un exemple de communauté électroniquecomprenant deux domaines participants : le domaine A (dA.com) et le domaine B(dB.com). Dans cet exemple, le domaine A représente le domaine d’accueil oupropriétaire tandis que le domaine B est un domaine participant ou “distant”.

Le domaine d’accueil “détient” les utilisateurs (c’est-à-dire qu’il contrôle leursinformations d’authentification). Quel que soit l’emplacement d’où l’utilisateureffectue une requête sur les ressources, le domaine d’accueil se situe toujours sur leserveur auprès duquel il doit s’authentifier.

L’authentification s’effectue auprès d’un serveur d’authentification principal MAS(Master Authentication Server), à savoir un serveur (ou un ensemble de répliquesde serveur) situé dans le domaine d’accueil et configuré de façon à authentifiertous les utilisateurs. Dans le diagramme, mas.dA.com représente le serveur MAS.Vous devez limiter les fonctions du serveur MAS aux services d’authentification.Ce serveur ne doit pas contenir de ressources utilisables par les utilisateurs.

Client

Domaine A Domaine B

mas.dA.com

WebSEAL 1

WebSEAL 2

WebSEAL MAS WebSEAL 3

WebSEAL 4

ws2.dA.com

ws1.dA.com

ws3.dB.com

ws4.dB.com

Figure 27. Modèle de communauté électronique

150 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 171: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Après avoir authentifié un utilisateur, le serveur MAS génère un jeton“d’attestation”. Celui-ci est retransmis au serveur lorsque l’utilisateur effectue larequête. Le serveur traite ce jeton “d’attestation” comme étant la preuve quel’utilisateur s’est authentifié auprès du serveur MAS et qu’il peut faire partie de lacommunauté électronique.

Le transfert d’informations entre les domaines de la communauté électronique estdétaillé dans la section «Flux du processus de communauté électronique» à la page152.

Fonctions de la communauté électronique et conditionsrequises

v Le modèle prend en charge l’accès aux ressources via des adresses URL (signets).Cette fonction contraste avec le modèle CDSSO reposant sur un lien pkmscdssoconfiguré d’une manière particulière (voir la section «Configuration del’authentification CDSSO» à la page 145).

v L’implémentation de la communauté électronique nécessite une configurationcohérente entre tous les serveurs WebSEAL de tous les domaines de cettecommunauté.

v Tous les utilisateurs appartenant à la communauté électronique s’authentifientauprès d’un serveur MAS situé dans le domaine d’accueil.

v L’implémentation de la communauté électronique permet l’authentification“locale” dans les domaines distants si l’utilisateur n’a pas de compte valide avecle serveur MAS (par exemple, les utilisateurs appartenant au domaine B maispas à la communauté électronique domaine A-domaine B).Un utilisateur dont l’authentification auprès du serveur MAS a échoué lors de larequête d’une ressource dans un domaine autre que celui de MAS (maisparticipant) peut s’authentifier auprès du serveur local sur lequel la requête esteffectuée.

v Le serveur MAS (et éventuellement les autres serveurs sélectionnés dans lesdomaines distants) “atteste” l’identité authentifiée de l’utilisateur.

v Les cookies spécifiques aux domaines servent à identifier le serveur permettantde fournir des services “d’attestation”. Les serveurs d’un domaine distantpeuvent ainsi demander des informations “d’attestation” localement. Le contenuchiffré des cookies de communauté électronique n’inclut aucune information surla sécurité ou l’identité de l’utilisateur.

v Des jetons spéciaux sont utilisés pour transmettre l’identité utilisateur “attestée”chiffrée. Le jeton “d’attestation” ne contient pas les informationsd’authentification de l’utilisateur proprement dites. La clé secrète partagée(Triple DES) assure l’intégrité des données. Le jeton contient un délaid’expiration (durée de vie) pour limiter la durée de validité du jeton.

v L’implémentation de la communauté électronique est prise en charge à la foisvia HTTP et HTTPS.

v Chaque domaine de la communauté électronique gère l’identité de ses propresutilisateurs ainsi que les privilèges associés. Vous pouvez utiliser l’API CDMF(Cross-domain Mapping Function) pour mapper un utilisateur issu d’undomaine distant à un utilisateur valide du domaine local.Si la communauté électronique partage des identités utilisateur globales, cettefonction de mappage n’est pas obligatoire.

v La configuration de la communauté électronique est définie dans le fichierwebseald.conf de chaque serveur WebSEAL participant.

Chapitre 6. Solutions de connexion unique interdomaine (CDSSO) 151

Page 172: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Flux du processus de communauté électroniqueUne communauté électronique comprend un serveur MAS WebSEAL ainsi qued’autres serveurs WebSEAL situés dans le domaine d’accueil ou les domainesdistants. Le serveur MAS peut être une instance unique d’un serveur WebSEAL ouun groupe de répliques de serveur WebSEAL situées derrière un mécanismed’équilibrage de charge (ce dernier étant identifié comme le serveur MAS).

Tous les serveurs WebSEAL locaux et distants participants doivent être configurésde façon à utiliser le serveur MAS du domaine d’accueil pour l’authentificationinitiale des clients. Il s’agit d’une condition matérielle pour les serveurs dudomaine d’accueil et d’une condition logicielle pour ceux des domaines distants.Par exemple, certains serveurs de domaines distants peuvent être configurés defaçon à gérer leur propre authentification. Ces serveurs et les ressources qu’ilsprotègent peuvent fonctionner indépendamment de la communauté électroniques’ils sont situés dans un domaine de la communauté.

L’implémentation de la communauté électronique repose sur un système“d’attestation”. Normalement, lorsqu’un utilisateur demande une ressource à partird’un serveur WebSEAL avec lequel il n’a pas établi de session valide, WebSEAL luidemande des informations d’authentification. Dans une configuration decommunauté électronique, le serveur WebSEAL identifie un serveur “d’attestation”et lui demande de vérifier si l’utilisateur s’est authentifié.

Le serveur “d’attestation” dispose d’informations d’autorisation pour cetutilisateur. Pour la première requête de l’utilisateur, le serveur “d’attestation” esttoujours le serveur MAS. Ce dernier sert toujours de serveur “d’attestation” pourles ressources situées dans le domaine d’accueil. A mesure que l’utilisateurcontinue à effectuer des requêtes portant sur des ressources via la communautéélectronique, chaque serveur du domaine distant peut créer sa propre autorisationpour l’utilisateur (en fonction des informations sur son identité issues du serveurMAS) et servir de serveur “d’attestation” pour les ressources de son domaine.

La vérification requise du serveur “d’attestation” prend la forme d’un jeton“d’attestation”. Le serveur “d’attestation” crée le jeton et le renvoie au serveurWebSEAL émettant la requête. Les informations sur l’identité de l’utilisateurcontenues dans le jeton sont chiffrées. La durée de vie du jeton est limitée.

Lors de la réception du jeton “d’attestation”, le serveur à l’origine de la requêtecrée des autorisations ainsi qu’une session locale pour cet utilisateur. Celui-ci peutensuite accéder à la ressource demandée en fonction des contrôles d’autorisationnormaux. L’utilisateur n’a pas besoin de s’authentifier une nouvelle fois (un desobjectifs du modèle de communauté électronique).

Reportez-vous au diagramme ci-après tout au long du flux du processus de lacommunauté électronique jusqu’à la fin de cette section. Le flux du processusdécrit deux scénarios de PREMIER accès possibles (1 et 2). Ceux-ci sontimmédiatement suivis de deux autres scénarios d’accès SUIVANT possibles (3 et 4).Le scénario 5 peut intervenir à tout moment après le premier accès.

152 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 173: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Serveurs “d’attestation”

v Le serveur MAS est toujours utilisé pour authentifier un utilisateur qui souhaiteaccéder à une partie de la communauté électronique pour la première fois.Il doit fonctionner comme un serveur d’authentification uniquement et non pascomme un fournisseur de ressources. Le serveur MAS ne doit pas être configurépour servir de serveur d’authentification principal et protéger les ressources enmême temps. Cette recommandation n’est pas une condition de sécuritéobligatoire mais elle affecte les performances.

v Le serveur MAS est toujours le serveur “d’attestation” pour le domaine d’accueil(domaine A dans cet exemple).

v Un cookie de communauté électronique spécifique à un domaine est utilisé pouridentifier le serveur “d’attestation” pour tous les autres serveurs dans undomaine donné. Le serveur “d’attestation” est le premier serveur d’un domainequi demande un jeton “d’attestation” à partir du serveur MAS. Le serveur“d’attestation” fournit des informations “d’attestation” à l’utilisateur membre dudomaine. Ce serveur peut émettre localement d’autres requêtes portant sur desservices “d’attestation” dans un domaine distant défini, au lieu d’accéder auserveur MAS en dehors du domaine. Dans le domaine d’accueil, le cookie decommunauté électronique identifie le serveur MAS comme étant le serveur“d’attestation”.

(1) PREMIER accès à la communauté électronique : WebSEAL 1 (domaine A)

v L’utilisateur demande une ressource protégée par WebSEAL 1 (dans le mêmedomaine que celui du serveur MAS). Le navigateur ne contient pas de cookie decommunauté électronique pour ce domaine. WebSEAL 1 ne dispose d’aucuneautorisation mise en mémoire cache pour l’utilisateur.

v WebSEAL 1 est configuré de façon à activer l’authentification de la communautéélectronique et à spécifier l’emplacement du serveur MAS. Il réachemine lenavigateur vers une adresse URL “d’attestation” spéciale sur le serveur MAS.

v Le serveur MAS reçoit la requête “d’attestation” et demande à l’utilisateur de seconnecter car aucune autorisation correspondante n’a été trouvée.

v Une fois la connexion terminée, le serveur MAS crée une autorisation pourl’utilisateur, la stocke dans la mémoire cache et réachemine le navigateur versl’adresse URL demandée à l’origine sur WebSEAL 1 avec un jeton “d’attestation”

Client

Domaine A Domaine B

mas.dA.com

ws1.dA.com

ws2.dA.com

WebSEAL 1

WebSEAL 2

WebSEAL MAS

ws3.dB.com

ws4.dB.com

WebSEAL 3

WebSEAL 4

Figure 28. Flux du processus de communauté électronique

Chapitre 6. Solutions de connexion unique interdomaine (CDSSO) 153

Page 174: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

chiffré. En outre, un cookie de communauté électronique spécifique au domaineA est placé sur le navigateur de façon à identifier le serveur “d’attestation” pource domaine (dans ce cas, le serveur MAS).Si la tentative de connexion échoue, le serveur MAS renvoie un jeton“d’attestation” indiquant un état d’échec. Ce jeton est créé de façon à êtreindifférenciable d’un jeton “d’attestation” indiquant un état de succès. Leserveur émettant la demande réagit à un jeton indiquant un état d’échec commesi l’authentification locale de l’utilisateur avait échoué.

v WebSEAL 1 déchiffre le jeton et crée sa propre autorisation pour l’utilisateur.

Remarque : Le mappage des identités ne doit pas être obligatoire dans le mêmedomaine. Si c’est le cas, WebSEAL 1 doit utiliser la fonction CDMF.

v Le service d’autorisation accepte ou refuse la requête.

(2) PREMIER accès à la communauté électronique : WebSEAL 3 (domaine B)

v L’utilisateur demande une ressource protégée par WebSEAL 3 (domaine Bdistant). Le navigateur ne contient pas de cookie de communauté électroniquepour ce domaine. WebSEAL 3 ne dispose d’aucune autorisation mise enmémoire cache pour l’utilisateur.

v WebSEAL 3 est configuré de façon à activer l’authentification de la communautéélectronique et à spécifier l’emplacement du serveur MAS. Il réachemine lenavigateur vers une adresse URL “d’attestation” spéciale sur le serveur MAS.

v Le serveur MAS reçoit la requête “d’attestation” et demande à l’utilisateur de seconnecter car aucune autorisation correspondante n’a été trouvée.

v Une fois la connexion terminée, le serveur MAS crée une autorisation pourl’utilisateur, la stocke dans la mémoire cache et réachemine le navigateur versl’adresse URL demandée à l’origine sur WebSEAL 3 avec un jeton “d’attestation”chiffré. En outre, un cookie de communauté électronique spécifique au domaineA est placé sur le navigateur de façon à identifier le serveur “d’attestation” pource domaine (dans ce cas, le serveur MAS).Si la tentative de connexion échoue, le serveur MAS renvoie un jeton“d’attestation” indiquant un état d’échec. Ce jeton est créé de façon à êtreindifférenciable d’un jeton “d’attestation” indiquant un état de succès. Leserveur émettant la demande réagit à un jeton indiquant un état d’échec commesi l’authentification locale de l’utilisateur avait échoué.

v WebSEAL 3 déchiffre le jeton et crée sa propre autorisation pour l’utilisateur.v WebSEAL 3 crée et définit un second cookie de communauté électronique (valide

pour le domaine B) sur le navigateur, en identifiant WebSEAL 3 comme étant leserveur “d’attestation” pour le domaine B.

v Le service d’autorisation accepte ou refuse la requête.

(3) Accès SUIVANT à la communauté électronique : WebSEAL 2 (domaine A)

v L’utilisateur demande une ressource protégée par WebSEAL 2 (dans le mêmedomaine que celui du serveur MAS). Le navigateur contient un cookie decommunauté électronique du domaine A qui identifie le serveur MAS commeétant le serveur “d’attestation”. WebSEAL 2 reçoit ce cookie. WebSEAL 2 nedispose d’aucune autorisation mise en mémoire cache pour l’utilisateur.

v WebSEAL 2 est configuré de façon à activer l’authentification de la communautéélectronique et à spécifier l’emplacement du serveur MAS. La présence ducookie de communauté électronique du domaine A prévaut sur la configurationde WebSEAL 2 pour l’emplacement du serveur MAS. Le cookie fournit l’identité

154 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 175: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

du serveur “d’attestation” à WebSEAL 2 (si le scénario 2 se produit en premier,un cookie du domaine B sera également maintenu sur le navigateur et ne seraenvoyé à aucun serveur du domaine A).

v WebSEAL 2 réachemine le navigateur vers une adresse URL “d’attestation”spéciale sur le serveur “d’attestation” du domaine A identifié dans le cookie(dans ce cas, le serveur MAS car WebSEAL 2 est situé dans le domaine A).

v Le serveur MAS reçoit la requête “d’attestation” et trouve les autorisations pourcet utilisateur dans la mémoire cache (scénarios 1 et 2).

v Le serveur MAS réachemine le navigateur vers l’adresse URL demandéeinitialement sur WebSEAL 2 avec un jeton “d’attestation” chiffré.

v WebSEAL 2 déchiffre le jeton et crée sa propre autorisation pour l’utilisateur.v Le service d’autorisation accepte ou refuse la requête.

(4) Accès SUIVANT à la communauté électronique : WebSEAL 4 (domaine B)

v L’utilisateur demande une ressource protégée par WebSEAL 4 (domaine Bdistant). Si le scénario 2 se produit en premier, le navigateur contient un cookiede communauté électronique du domaine B qui identifie WebSEAL 3 commeétant le serveur “d’attestation”. WebSEAL 4 ne dispose d’aucune autorisationmise en mémoire cache pour l’utilisateur.

v WebSEAL 4 est configuré de façon à activer l’authentification de la communautéélectronique et à spécifier l’emplacement du serveur MAS. La présence d’uncookie de communauté électronique du domaine B prévaut sur la configurationde WebSEAL 4 pour l’emplacement du serveur MAS. Le cookie fournit l’identitédu serveur “d’attestation” à WebSEAL 4 (si le scénario 1 se produit en premier,seul un cookie du domaine A sera maintenu sur le navigateur et ne sera envoyéà aucun serveur du domaine B). L’emplacement du serveur MAS configuré serautilisé à la place. WebSEAL 4 deviendra ensuite le serveur “d’attestation” pour ledomaine B).

v Si le scénario 2 se produit en premier, WebSEAL 4 réachemine le navigateur versune adresse URL “d’attestation” spéciale sur le serveur “d’attestation” dudomaine B identifié dans le cookie du domaine B (dans ce cas, WebSEAL 3).

v WebSEAL 3 reçoit la requête “d’attestation” et trouve les autorisations pour cetutilisateur dans la mémoire cache (scénario 2).

v WebSEAL 3 réachemine le navigateur vers l’adresse URL demandée initialementsur WebSEAL 4 avec un jeton “d’attestation” chiffré.

v WebSEAL 4 déchiffre le jeton et crée sa propre autorisation pour l’utilisateur.v Le service d’autorisation accepte ou refuse la requête.

(5) AUTRE accès à la communauté électronique : WebSEAL 2 (domaine A)

v L’utilisateur se connecte à WebSEAL 2 (domaine A) avec une requête. Si lescénario 3 se produit, WebSEAL 2 dispose d’autorisations mises en mémoirecache pour l’utilisateur.

v Le service d’autorisation accepte ou refuse la requête.

Déconnexion de la communauté électronique

v Si l’utilisateur se déconnecte en fermant le navigateur, les sessions SSL et lescookies de communauté électronique sont tous supprimés.

v S’il se déconnecte via la page /pkmslogout, la session SSL et le cookie decommunauté électronique pour ce domaine sont supprimés.

Chapitre 6. Solutions de connexion unique interdomaine (CDSSO) 155

Page 176: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Explication du cookie de communauté électroniquev Le cookie de communauté électronique est un cookie spécifique au domaine

défini par un serveur WebSEAL, stocké dans la mémoire du navigateur del’utilisateur et transmis aux autres serveurs WebSEAL (du même domaine) lorsdes requêtes suivantes.

v Le cookie spécifique au domaine contient le nom du serveur “d’attestation”,l’identité de la communauté électronique, l’emplacement (adresse URL) duserveur et de la fonctionnalité “d’attestation” ainsi que la valeur de sa durée devie. Le cookie ne contient pas d’informations sur les utilisateurs ou sur lasécurité.

v Le cookie de communauté électronique permet aux serveurs des domainesparticipants de demander des informations “d’attestation” localement. Le cookiede communauté électronique attaché au domaine sur lequel réside le serveurMAS joue un rôle moins important.

v La valeur de la durée de vie (délai d’expiration) du cookie est définie dans lefichier de configuration webseald.conf. Elle définit la durée pendant laquelle unserveur distant peut fournir des informations “d’attestation” à l’utilisateur.Lorsque la durée de vie du cookie arrive à expiration, l’utilisateur doit êtreréacheminé vers le serveur MAS pour être authentifié.

v Lorsque le navigateur est fermé, le cookie est supprimé de la mémoire. Sil’utilisateur se déconnecte d’un domaine spécifique, le cookie de communautéélectronique est ignoré comme s’il était vide. En réalité, cette action le supprimedu navigateur.

Explication de la requête et de la réponse “d’attestation”L’opération “d’attestation” de la communauté électronique nécessite unefonctionnalité dédiée accessible par deux adresses URL créées tout spécialement :la requête “d’attestation” et la réponse “d’attestation”. Ces adresses URL sontdéfinies lors des réacheminements HTTP “d’attestation” de la communautéélectronique en fonction des informations de configuration contenues dans lefichier webseald.conf.

Requête “d’attestation”

La requête “d’attestation” est déclenchée lorsqu’un utilisateur demande uneressource à partir d’un serveur de destination (configuré pour la communautéélectronique) qui ne contient pas de données d’autorisation pour cet utilisateur. Leserveur envoie un réacheminement HTTP vers le serveur “d’attestation” (le serveurMAS ou un autre identifié dans un cookie de communauté électronique).

La requête “d’attestation” contient les informations suivantes :https://<serveur_d’attestation>/pkmsvouchfor?<nom_communauté_électronique>&<URL_de_destination>

Le serveur récepteur vérifie la variable nom_communauté_électronique pour validerl’identité de la communauté électronique. Le serveur récepteur utilise la variableURL_de_destination dans la réponse “d’attestation” pour réacheminer le navigateurvers la page demandée initialement.

L’adresse URL “d’attestation” de pkmsvouchfor est configurable.

Par exemple :https://mas.dA.com/pkmsvouchfor?companyABC&https://ws5.dB.com/index.html

156 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 177: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Réponse “d’attestation”

La réponse “d’attestation” est la réponse du serveur “d’attestation” au serveur dedestination.

La réponse “d’attestation” contient les informations suivantes :https://<URL_de_destination>?PD-VFHOST=<serveur_d’attestation>&PD-VF=<jeton_chiffré>

Le paramètre PD-VFHOST identifie le serveur ayant exécuté l’opération“d’attestation”. Le serveur récepteur (de destination) utilise ces informations afinde sélectionner la clé requise pour déchiffrer le jeton “d’attestation” (PD-VF). Leparamètre PD-VF représente le jeton “d’attestation” chiffré.

Par exemple :https://w5.dB.com/index.html?PD-VFHOST=mas.dA.com&PD-VF=3qhe9fjkp...ge56wgb

Explication du jeton “d’attestation”Pour qu’une connexion unique interdomaine aboutisse, certaines informations surl’identité de l’utilisateur doivent être transmises entre les serveurs. Cesinformations confidentielles sont gérées à l’aide d’un réacheminement qui inclut lesinformations d’identité chiffrées dans l’adresse URL. Ces données chiffrées sontappelées jeton “d’attestation”.v Le jeton contient l’état d’échec ou de succès de “l’attestation”, l’identité de

l’utilisateur (si la connexion réussit), le nom complet du serveur ayant créé lejeton, l’identité de la communauté électronique ainsi que la date de création.

v Le détenteur d’un jeton “d’attestation” valide peut l’utiliser pour établir unesession (et un ensemble d’autorisations) sur un serveur sans avoir às’authentifier auprès de lui de manière explicite.

v Le jeton est chiffré à l’aide d’une clé secrète Triple DES partagée de façon àvérifier son authenticité.

v Les informations de jeton chiffrées ne sont pas stockées sur le navigateur.v Le jeton n’est transmis qu’une seule fois. Le serveur récepteur utilise ces

informations pour créer les autorisations utilisateur dans sa propre mémoirecache. Le serveur les utilise lors des requêtes suivantes de cet utilisateur aucours de la même session.

v La valeur de la durée de vie (délai d’expiration) du jeton est définie dans lefichier de configuration webseald.conf. Cette durée peut être très courte(quelques secondes) de façon à réduire le risque d’une tentative de réexécutionmalveillante.

Chiffrement du jeton “d’attestation”WebSEAL doit chiffrer les données d’authentification placées sur le jeton à l’aided’une clé générée par l’utilitaire cdsso_key_gen. Vous devez “synchroniser” cetteclé en partageant le fichier de clés avec chaque serveur WebSEAL de chaquedomaine participant. Chacun des serveurs WebSEAL participant à chaque domainedoit utiliser la même clé.

Remarque : La création et la distribution de fichiers de clés ne fait pas partie duprocessus de communauté électronique d’Access Manager.Vous devezcopier manuellement les clés sur chaque serveur participant en toutesécurité.

Chapitre 6. Solutions de connexion unique interdomaine (CDSSO) 157

Page 178: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

L’utilitaire cdsso_key_gen exige que vous spécifiez l’emplacement (chemin absolu)du fichier de clés lorsque vous l’exécutez :

UNIX :# cdsso_key_gen <chemin_absolu>

Windows :MSDOS> cdsso_key_gen <chemin_absolu>

L’emplacement de la clé utilisée pour sécuriser les jetons envoyés entre les serveursdans le même domaine (accueil et distant) est la valeur du paramètreintra-domain-key dans la strophe [e-community-sso] du fichier de configurationwebseald.conf.[e-community-sso]intra-domain-key = <chemin_absolu>

L’emplacement des fichiers de clés utilisés pour sécuriser les jetons envoyés entrele serveur MAS et les serveurs des domaines distants est défini dans la strophe[inter-domain-keys]. La strophe inter-domain-keys n’est pas requise pour lesautres serveurs appartenant au même domaine que celui du serveur MAS. Leserveur MAS est le seul qui doit communiquer avec les serveurs dans les domainesdistants.[inter-domain-keys]<nom_domaine> = <chemin_absolu><nom_domaine> = <chemin_absolu

Configuration de la communauté électroniqueCette section décrit tous les paramètres de configuration requis pourl’implémentation d’une communauté électronique. Ces paramètres se trouvent dansle fichier webseald.conf. Vous devez configurer ce fichier avec précaution pourchaque serveur membre de la communauté électronique.

e-community-sso-auth

Ce paramètre active et désactive l’authentification de la communauté électronique.Les valeurs sont “http”, “https”, “both” ou “none”. Par exemple :[e-community-sso]e-community-sso-auth = both

Les valeurs “http”, “https” et “both” indiquent le type de communication utiliséepar les membres de la communauté électronique. En revanche, la valeur “none”désactive la communauté électronique pour ce serveur. La valeur par défaut de ceparamètre est “none”.

master-http-port

Si le paramètre e-community-sso-auth active l’authentification de la communautéélectronique HTTP et que le serveur d’authentification principal écoute les requêtesHTTP sur un port différent du port HTTP standard (port 80), le paramètremaster-http-port identifie le port non standard. Ce paramètre est ignoré si ceserveur est le serveur d’authentification principal. Il est désactivé par défaut.[e-community-sso]master-http-port = <numéro_port>

158 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 179: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

master-https-port

Si le paramètre e-community-sso-auth active l’authentification de la communautéélectronique HTTPS et que le serveur d’authentification principal écoute lesrequêtes HTTPS sur un port différent du port HTTPS standard (port 443), leparamètre master-http-port identifie le port non standard. Ce paramètre est ignorési ce serveur est le serveur d’authentification principal. Il est désactivé par défaut.[e-community-sso]master-https-port = <numéro_port>

e-community-name

Ce paramètre identifie le nom global de la communauté électronique pour tous lesserveurs des domaines participants. Par exemple :[e-community-sso]e-community-name = companyABC

La valeur du paramètre e-community-name doit être identique pour tous lesserveurs WebSEAL dans l’ensemble des domaines de la communauté électronique.

intra-domain-key

Ce paramètre identifie l’emplacement du fichier de clés utilisé pour chiffrer etdéchiffrer les jetons qui sont échangés dans le domaine de ce serveur. Parexemple :[e-community-sso]intra-domain-key = /abc/xyz/key.file

Vous devez générer ce fichier de clés à un endroit et le copier manuellement (et entoute sécurité) à l’emplacement défini sur tous les autres serveurs WebSEAL dudomaine.

is-master-authn-server

Ce paramètre indique si ce serveur est le serveur MAS. Les valeurs sont “yes” ou“no”. Par exemple :[e-community-sso]is-master-authn-server = yes

Plusieurs serveurs WebSEAL peuvent être configurés pour servir de serveursd’authentification principaux et placés derrière un mécanisme d’équilibrage decharge. Dans ce scénario, tous les autres serveurs WebSEAL de la communautéélectronique “reconnaissent” le mécanisme d’équilibrage de charge comme étant leserveur MAS.

master-authn-server

Si le paramètre is-master-authn-server a la valeur “no”, sa mise en commentairedoit être annulée et il doit être défini. Le paramètre identifie le nom de domainecomplet du serveur MAS. Par exemple :[e-community-sso]master-authn-server = mas.dA.com

Chapitre 6. Solutions de connexion unique interdomaine (CDSSO) 159

Page 180: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

vf-token-lifetime

Ce paramètre définit la durée de vie (en secondes) du jeton “d’attestation”. Cettevaleur est comparée avec l’heure de création du cookie. La valeur par défaut est180 secondes. Vous devez prendre en compte le décalage horaire entre les serveursparticipants. Par exemple :[e-community-sso]vf-token-lifetime = 180

vf-url

Ce paramètre définit l’adresse URL “d’attestation”. La valeur doit commencer parune barre oblique (/). La valeur par défaut est /pkmsvouchfor. Par exemple :[e-community-sso]vf-url = /pkmsvouchfor

Vous pouvez également définir une adresse URL étendue :vf-url = /ecommA/pkmsvouchfor

ec-cookie-lifetime

Ce paramètre indique la durée de vie maximale (en minutes) du cookie dedomaine de communauté électronique. La valeur par défaut est 300 minutes. Parexemple :[e-community-sso]ec-cookie-lifetime = 300

Clés interdomaines

L’emplacement des fichiers de clés requis pour chiffrer et déchiffrer les jetons entrele serveur MAS et les serveurs membres des domaines distants est défini dans lastrophe [inter-domain-keys]. Vous devez indiquer les noms de domaine completspour les serveurs ainsi que les noms de chemin absolu pour les emplacements desfichiers de clés.

L’exemple suivant fournit au serveur MAS (domaine A) les fichiers de clés pourcommuniquer avec les deux domaines distants :[inter-domain-keys]dB.com = /abc/xyz/key.fileBdC.com = /abc/xyz/key.fileC

Dans cet exemple, key.fileB identifie le fichier de clés utilisé entre le domaine A etle domaine B tandis que key.fileC définit celui utilisé entre le domaine A et ledomaine C.

Chaque serveur distant nécessite une copie du fichier de clés approprié utilisé parle serveur MAS. Pour échanger des jetons avec le serveur MAS (domaine A), tousles serveurs du domaine B requièrent des copies de key.fileB.[inter-domain-keys]dA.com = /efg/hij/key.fileB

Pour échanger des jetons avec le serveur MAS (domaine A), tous les serveurs dudomaine C requièrent des copies de key.fileC.[inter-domain-keys]dA.com = /efg/hij/key.fileC

160 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 181: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Configuration de la méthode d’authentification CDSSOLa configuration de la communauté électronique exige que la méthoded’authentification cdsso soit activée. Ce mécanisme est nécessaire lorsque leserveur récepteur crée des autorisations utilisateur à partir des informationsd’identité contenues dans le jeton “d’attestation”. Le paramètre de configurationcdsso spécifie la bibliothèque partagée définie dans le code servant au mappagedes informations d’authentification.v Sous UNIX, le fichier fournissant la fonction de mappage intégré est la

bibliothèque partagée libcdssoauthn.v Sous Windows, le fichier fournissant la fonction de mappage intégré est le DLL

cdssoauthn.

Méthoded’authentification

Bibliothèque partagée

Solaris AIX Windows HP-UX

cdsso libcdssoauthn.so libcdssoauthn.a cdssoauthn.dll libcdssoauthn.sl

Pour configurer la méthode d’authentification CDSSO, indiquez le paramètre cdssoavec le nom du fichier de bibliothèque partagée correspondant à la plate-formeutilisée, dans la strophe [authentication-mechanism] du fichier de configurationwebseald.conf.

Par exemple :

Solaris :[authentication-mechanisms]cdsso = libcdssoauthn.so

Windows :[authentication-mechanisms]cdsso = cdssoauthn.dll

Chapitre 6. Solutions de connexion unique interdomaine (CDSSO) 161

Page 182: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

162 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 183: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Chapitre 7. Jonctions WebSEAL

La connexion entre un serveur WebSEAL et un serveur d’applications Webd’arrière-plan est appelée jonction ou jonction WebSEAL. Une jonction WebSEALest une connexion TCP/IP entre un serveur WebSEAL frontal et un serveurd’applications Web. Les jonctions permettent à WebSEAL de protéger les ressourcesWeb situées sur des serveurs d’arrière-plan.

Vous pouvez créer des jonctions WebSEAL avec l’utilitaire de ligne de commandepdadmin ou avec Web portal manager. Ce chapitre aborde en détails lesnombreuses options permettant de configurer les jonctions WebSEAL.

Index des rubriques :v «Présentation des jonctions WebSEAL» à la page 163v «Utilisation de pdadmin pour créer des jonctions» à la page 165v «Configuration d’une jonction WebSEAL de base» à la page 166v «Jonctions SSL authentifiées de façon réciproque» à la page 169v «Création de jonctions proxy TCP et SSL» à la page 172v «Jonctions WebSEAL/WebSEAL via SSL» à la page 173v «Modification des adresses URL des ressources d’arrière-plan» à la page 173v «Autres options de jonction» à la page 180v «Remarques techniques sur l’utilisation des jonctions WebSEAL» à la page 190v «Utilisation de query_contents avec des serveurs tiers» à la page 191

Présentation des jonctions WebSEALVous pouvez créer les types de jonction suivants :v WebSEAL / serveur d’arrière-plan via connexion TCPv WebSEAL / serveur d’arrière-plan via connexion SSLv WebSEAL / serveur d’arrière-plan via connexion TCP à l’aide d’un serveur

proxy HTTPv WebSEAL / serveur d’arrière-plan via connexion SSL à l’aide d’un serveur proxy

HTTPSv WebSEAL / WebSEAL via connexion SSL

Lorsque vous créez une jonction, vous devez réfléchir aux deux points suivants :1. Décidez de l’emplacement où établir la jonction du(des) serveur(s)

d’applications Web dans l’espace objet WebSEAL.2. Choisissez le type de jonction.

Emplacement et format de la base de données des jonctionsA présent, les informations de jonction WebSEAL sont stockées dans des fichiers debase de données au format XML. L’emplacement du répertoire de la base dedonnées des jonctions est défini dans la strophe [junction] du fichier deconfiguration webseald.conf. Ce répertoire est relatif à la racine du serveurWebSEAL (paramètre server-root situé dans la strophe [server]) :[junction]junction-db = jct

© Copyright IBM Corp. 1999, 2002 163

Page 184: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

v Chaque jonction est définie dans un fichier séparé avec une extension .xml.v Servez-vous de l’utilitaire pdadmin pour créer et gérer des jonctions et des

options.v Le format XML permet de créer, d’éditer, de dupliquer et de sauvegarder

manuellement des fichiers de jonction.

Application du contrôle d’accès allégé : récapitulatif1. Servez-vous de l’utilitaire pdadmin ou de Web portal manager pour créer une

jonction entre WebSEAL et le serveur d’arrière-plan.2. Définissez des règles de LCA appropriées sur le point de jonction pour fournir

un contrôle d’accès allégé au serveur d’arrière-plan.

Application du contrôle d’accès allégé : récapitulatif1. Servez-vous de l’utilitaire pdadmin ou de Web portal manager pour créer une

jonction entre WebSEAL et le serveur d’arrière-plan.WebSEAL ne peut pas “voir” ni comprendre automatiquement un système defichiers d’un tiers. Vous devez l’informer de l’espace objet tiers avec uneapplication spéciale, appelée query_contents, qui effectue l’inventaire del’espace Web tiers et en indique la structure et le contenu à WebSEAL.

2. Copiez le programme query_contents sur le serveur tiers.3. Appliquez les règles de LCA aux objets appropriés de l’espace objet unifié.

Directives en matière de création de jonctions WebSEALjunctions

Les directives suivantes récapitulent les “règles” en matière de jonctions :v Vous pouvez ajouter une jonction en un point quelconque de l’espace objet

WebSEAL principalv Vous pouvez relier plusieurs répliques de serveur sur le même point de montage

Les répliques de serveur montées sur le même point de jonction doivent être dumême type : TCP ou SSL

v Les règles de sécurité de LCA sont transmises par les jonctions jusqu’auxserveurs tiers

v Le nom du point de jonction ne doit pas correspondre à un répertoire del’espace Web du serveur WebSEAL local. Par exemple, si WebSEAL possède desressources du type /chemin/..., ne créez pas de point de jonction du nom/chemin.

v Le point de jonction ne doit pas correspondre à un répertoire de l’espace Webdu serveur d’arrière-plan si des pages HTML de ce serveur contiennent desprogrammes (Javascript ou applets, par exemple) ayant des adresses URLrelatives au serveur pour ce répertoire. Par exemple, si des pages du serveurd’arrière-plan contiennent des programmes dotés d’une adresse URL du type/chemin/..., ne créez pas de point de jonction nommé /chemin.

v Ne créez pas plusieurs jonctions WebSEAL qui désignent le même serveur/portd’applications d’arrière-plan. En effet, ce type de configuration peut entraîner uncontrôle d’accès aux ressources imprévisible et ne constitue donc pas unestratégie de configuration recommandée ou prise en charge par Access Manager.Chaque jonction WebSEAL peut être sécurisée grâce à un ensemble unique decontrôles d’accès (LCA). Toutefois, les règles de LCA de chaque nouvellejonction recouvrent celles des jonctions créées précédemment et associées aumême serveur/port d’arrière-plan. Les jonctions suivantes sécurisées à l’aide des

164 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 185: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

règles de LCA les plus ouvertes risquent d’affecter les jonctions précédentessécurisées à l’aide des règles de LCA les moins ouvertes. WebSEAL et le modèled’autorisation Access Manager ne peuvent pas garantir un contrôle d’accèssécurisé avec ce type de mise en oeuvre de jonctions.

v WebSEAL prend en charge HTTP 1.1 sur les jonctions.

Références supplémentaires pour les jonctions WebSEALPour une présentation conceptuelle des jonctions WebSEAL, reportez-vous à lasection «Explication des jonctions WebSEAL» à la page 14.

Pour plus d’informations sur les options de commande de jonction, reportez-vousà l’Annexe B, «Référence des jonctions WebSEAL» à la page 253.

Utilisation de pdadmin pour créer des jonctionsAvant d’utiliser pdadmin, vous devez vous connecter à un domaine sécurisé entant qu’utilisateur administratif sec_master.

Par exemple :

UNIX :# pdadminpdadmin> loginEntrer ID utilisateur : sec_masterEntrer mot de passe :pdadmin>

Windows :MSDOS> pdadminpdadmin> loginEntrer ID utilisateur : sec_masterEntrer mot de passe :pdadmin>

Pour créer des jonctions WebSEAL, utilisez la commande pdadmin server taskcreate :pdadmin> server task<ID_serveur> create<options>

Le composant ID-serveur de cette commande est une combinaison du serveurAccess Manager utilisé par cette commande et du nom d’hôte du serveur AccessManager.<serveur_Access_Manager>-<nom_hôte>

Syntaxe applicable à un serveur unique WebSEAL :

Pour Access Manager WebSEAL, le composant serveur_Access_Manager estwebseald et le composant the nom_hôte est le nom du serveur WebSEAL :pdadmin> server taskwebseald-<nom_hôte> create<options>

Chapitre 7. Jonctions WebSEAL 165

Page 186: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Le nom du serveur WebSEAL initial installé sur une machine contient toujours lenom de la machine. Par exemple, si le nom de la machine est cruz, l’ID serveurd’une installation WebSEAL à serveur unique est le suivant :webseald-cruz

Syntaxe applicable à plusieurs instances WebSEAL :

Si vous installez plusieurs instances de serveurs WebSEAL sur la même machine, lecomposant serveur_Access_Manager correspond au nom configuré de l’instance duserveur WebSEAL, suivi de webseald et du nom d’hôte :<nom_instance>-webseald-<nom_hôte>

Par exemple, si les noms configurés de deux instances WebSEAL supplémentairessont webseal2 et webseal3, les ID des serveurs sont les suivants :webseal2-webseald-cruzwebseal3-webseald-cruz

Utilisez la commande server list pour vérifier l’ID des serveurs :pdadmin> server listwebseald-cruzwebseal2-webseald-cruzwebseal3-webseald-cruz

Configuration d’une jonction WebSEAL de baseWebSEAL prend en charge à la fois les jonctions TCP (HTTP) standard et SSL(HTTPS) sécurisées entre WebSEAL et les serveurs d’applications Webd’arrière-plan.

La jonction entre WebSEAL et le serveur d’arrière-plan est indépendante du typede connexion (et de son niveau de sécurité) entre le client et le serveur WebSEAL.

Les options de commande obligatoires pour créer une jonction WebSEAL de base àl’aide de pdadmin sont les suivantes :v Nom d’hôte du serveur d’applications d’arrière-plan (option –h)v Type de jonction : tcp, ssl, tcpproxy, sslproxy, local (option –t)v Point de jonction (point de montage)pdadmin> server taskwebseald-<nom_instance> create –t <type> –h \<nom_hôte> <point_de_jonction>

Par exemple :pdadmin> server task webseald-cruz create -t tcp -h doc.tivoli.com /pubs

Remarque : La recommandation en termes de “meilleures pratiques” consiste àtoujours utiliser le nom de domaine complet du serveur d’arrière-plandans l’option –h lors de la création ou de l’ajout d’une jonction.

166 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 187: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Création de jonctions de type TCPUne jonction WebSEAL sur une connexion TCP fournit les propriétés de base d’unejonction, mais ne fournit pas des communications sécurisées au niveau de lajonction.

Pour créer une jonction TCP sécurisée et ajouter un serveur initial, servez-vous dela commande create avec l’option –t tcp :pdadmin> server taskwebseald-<nom_instance> create–t tcp –h <nom_hôte> \[–p <port>]<point_de_jonction>

La valeur du port par défaut d’une jonction TCP (en l’absence de spécification) est80.

Création de jonctions de type SSLLes jonctions SSL fonctionnent exactement comme des jonctions TCP, mais l’atoutsupplémentaire réside dans le fait que toutes les communications entre WebSEALet le serveur d’arrière-plan sont chiffrées.

Les jonctions SSL permettent des transactions sécurisées de bout en bout entre lenavigateur et l’application. Vous pouvez utiliser le protocole SSL pour sécuriser lescommunications entre le client et WebSEAL, ainsi qu’entre WebSEAL et le serveurd’arrière-plan. Ce dernier doit être activé en mode HTTPS lorsque vous utilisezune jonction SSL.

JonctionWebSEAL

Client

Domaine sécurisé

Serveurd’applications

Web

HTTP

/

/mnt

TCP

Figure 29. Jonction TCP (HTTP) non sécurisée

JonctionWebSEAL

Client

Domaine sécurisé

HTTPS

/

/mntSSLTCP

Serveurd’applications

Web

Figure 30. Jonction SSL (HTTPS) sécurisée

Chapitre 7. Jonctions WebSEAL 167

Page 188: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Pour créer une jonction SSL sécurisée et ajouter un serveur initial, servez-vous dela commande create avec l’option –t ssl :pdadmin> server taskwebseald-<nom_instance> create–t ssl –h <nom_hôte> \[–p <port>]<point_de_jonction>

La valeur du port par défaut d’une jonction SSL (en l’absence de spécification) est443.

Vérification du certificat du serveur d’arrière-planLorsqu’un client demande une ressource du serveur d’arrière-plan, WebSEAL, entant que serveur de sécurité, effectue la requête pour le compte du client. Leprotocole SSL spécifie que, si une requête est effectuée auprès du serveurd’arrière-plan, ce dernier doit apporter la preuve de son identité via un certificatc″té serveur.

Lorsque WebSEAL reçoit ce certificat du serveur d’arrière-plan, il doit vérifier sonauthenticité en le comparant à une liste de certificats d’autorité de certificationracine enregistrés dans sa base de certificats.

Access Manager utilise la mise en oeuvre GSkit (Global Security Kit) IBM de SSL.Vous devez vous servir de l’utilitaire GSKit iKeyman pour ajouter le certificatracine de la CA qui a signé le certificat du serveur d’arrière-plan au fichier de clésdu certificat WebSEAL (pdsvr.kdb).

Exemples de jonctions SSLLiaison de l’hôte sales.tivoli.com au point de jonction /sales via SSL :pdadmin> server taskwebseald-<nom_instance> create–t ssl –h \sales.tivoli.com /sales

Remarque : Dans l’exemple précédent, l’option –t ssl indique le port par défaut443.

Liaison de l’hôte travel_svr sur le port 4443 au point de jonction /travel via SSL :pdadmin> server taskwebseald-<nom_instance> create –t ssl –p 4443 \–h travel_svr /travel

Ajout de serveurs d’arrière-plan à une jonctionPour augmenter la grande disponibilité des ressources protégées par AccessManager, vous pouvez effectuer une jonction entre plusieurs serveurs répliqued’arrière-plan sur le même point de jonction.v Lorsque plusieurs serveurs d’arrière-plan sont reliés par jonction au même point,

ils doivent posséder des versions de WebSEAL et des espaces de documents Webidentiques.

v Par ailleurs, plusieurs serveurs d’arrière-plan reliés par jonction au même pointdoivent utiliser le même type de connexion (TCP ou SSL).

v WebSEAL utilise au minimum un algorithme pour déterminer quel serveurréplique d’arrière-plan possède le nombre le moins élevé de connexions derequêtes et pour acheminer les nouvelles requêtes vers ce serveur.

168 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 189: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Créez la jonction initiale. Par exemple :pdadmin> server task webseald-cruz create -t tcp -h server1 /sales

Ajoutez une réplique de serveur d’arrière-plan supplémentaire. Par exemple :pdadmin> server task webseald-cruz add -h server2 /sales

Jonctions SSL authentifiées de façon réciproqueWebSEAL prend en charge l’authentification réciproque entre un serveur WebSEALet un serveur d’arrière-plan via une jonction SSL (–t ssl ou –t sslproxy). Ladescription ci-après résume les fonctionnalités prises en charge en matièred’authentification réciproque via SSL (les options de commande sont répertoriées sinécessaire) :1. WebSEAL authentifie le serveur d’arrière-plan (processus SSL normal)v WebSEAL valide le certificat de serveur à partir du serveur d’arrière-plan.

Voir la section «WebSEAL valide le certificat du serveur d’arrière-plan».v WebSEAL vérifie le nom distinctif (DN) contenu dans le certificat (–D)

(opération facultative, mais fortement recommandée). Voir la section «Miseen correspondance des noms distinctifs (DN)» à la page 170.

2. Le serveur d’arrière-plan authentifie WebSEAL (deux méthodes)v Le serveur d’arrière-plan valide le certificat client à partir de WebSEAL (–K).

Voir la section «WebSEAL s’authentifie avec le certificat client» à la page 170.v Le serveur d’arrière-plan valide les informations d’identité de WebSEAL dans

l’en-tête de l’authentification de base (BA) (–B, –U, –W). Voir la section«WebSEAL s’authentifie avec l’en-tête BA» à la page 171.

Les options de commande qui contrôlent l’authentification réciproque via SSLfournissent les fonctions suivantes :v Vous pouvez spécifier une méthode d’authentification BA ou par certificat client.v Vous pouvez appliquer une méthode d’authentification jonction par jonction.

Les différents points à prendre en considération pour la combinaison des options–b (pour la gestion des informations BA) avec l’authentification réciproque via SSLsont décrits dans la section «Gestion des informations d’identité du client sur lesdifférentes jonctions» à la page 171

WebSEAL valide le certificat du serveur d’arrière-planWebSEAL vérifie un certificat de serveur d’arrière-plan en fonction du protocoleSSL standard. Le serveur d’arrière-plan envoie son certificat de serveur àWebSEAL. WebSEAL valide le certificat de serveur en le comparant à une listeprédéfinie de certificats racine de CA.

Les certificats de CA qui composent la chaîne de confiance pour le certificat duserveur d’applications (depuis la CA signataire jusqu’au certificat racine) doiventfigurer dans la base de données de clés utilisée par WebSEAL.

Vous avez recours à l’utilitaire iKeyman pour créer et gérer la base de données descertificats racine de CA.

Chapitre 7. Jonctions WebSEAL 169

Page 190: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Mise en correspondance des noms distinctifs (DN)Vous pouvez renforcer la vérification du certificat c″té serveur au moyen de la miseen correspondance des noms distinctifs DN (distinguished name - DN). Pouractiver cette fonction, vous devez spécifier le DN du serveur d’arrière-plan lorsquevous créez la jonction SSL à ce serveur. Bien que la mise en correspondance denoms distinctifs soit une configuration facultative, sa mise en oeuvre avecl’authentification réciproque est vivement recommandée sur les jonctions SSL.

Pendant la vérification du certificat c″té serveur, le DN contenu dans le certificatest comparé à celui qui est défini par la jonction. La connexion au serveurd’arrière-plan échoue si les deux noms ne correspondent pas.

Pour activer cette fonction de mise en correspondance, spécifiez le DN du serveurd’arrière-plan lorsque vous créez la jonction SSL avec l’option –D“<DN>”. Pourmaintenir les espaces éventuels de la chaîne, encadrez la chaîne du DN par desguillemets. Par exemple :–D “/C=US/O=Tivoli/OU=SecureWay/CN=Access Manager”

L’option –D doit obligatoirement être accompagnée de l’option –K ou –B.

WebSEAL s’authentifie avec le certificat clientServez-vous de l’option –K pour activer l’authentification WebSEAL auprès duserveur d’arrière-plan relié par jonction via le certificat client.–K “<libellé_clé>”

Les conditions relatives à ce scénario sont les suivantes :v Le serveur d’arrière-plan est configuré pour demander une vérification de

l’identité de WebSEAL au moyen d’un certificat client.v WebSEAL est configuré (webseald.conf) de façon à utiliser un certificat client

spécifique pour s’identifier auprès du serveur d’arrière-plan (ssl_keyfile_label).v Vous êtes également invités à configurer la jonction pour une mise en

correspondance des noms distinctifs –D).

L’option –K utilise un argument qui spécifie le libellé de clé du certificat requis, telqu’il est enregistré dans la base de données de clés GSKit. Servez-vous del’utilitaire iKeyman pour ajouter de nouveaux certificats à la base de données declés. Utilisez le paramètre ssl-keyfile-label du fichier de configurationwebseald.conf pour configurer le libellé de clé.

Vous devez encadrer l’argument de libellé de clé de guillemets. Par exemple :–K “cert1_Tiv”

Voir la section «Configuration de paramètres de base de données de clés» à la page41.

170 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 191: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

WebSEAL s’authentifie avec l’en-tête BAServez-vous de l’option –B –U “<nom_utilisateur>” –W “<mot_de_passe>” pouractiver l’authentification WebSEAL via l’authentification de base.–B –U “<nom_utilisateur>” –W“<mot_de_passe>”

Les conditions relatives à ce scénario sont les suivantes :v Le serveur d’arrière-plan est configuré pour demander une vérification de

l’identité de WebSEAL au moyen d’un en-tête BA.v Ne configurez pas la jonction avec une option –b. (En interne, l’option –B utilise

toutefois le filtre –b.)v WebSEAL est configuré pour transmettre ses informations d’identité dans un

en-tête BA pour s’authentifier auprès du serveur d’arrière-plan.v Vous êtes également vivement invités à configurer la jonction pour une mise en

correspondance des noms distinctifs (–D).

Vous devez encadrer les arguments de nom d’utilisateur et de mot de passe deguillemets. Par exemple :–U “WS1” –W “abCde”

Gestion des informations d’identité du client sur lesdifférentes jonctions

Il est possible qu’une jonction soit définie pour spécifier des informations d’identitédu client dans des en-têtes BA. L’option –b autorise quatre arguments : filter,supply, ignore, gso. Vous trouverez des détails sur ces arguments à la section«Configuration d’en-têtes BA pour des solutions SSO» à la page 197.

L’option –b joue sur les paramètres de jonction en matière d’authentificationréciproque et vous devez envisager la combinaison appropriée d’options.

Utilisation de –b supplyv L’authentification WebSEAL via l’en-tête BA n’est pas autorisée avec cette

option. Cette option utilise l’en-tête BA pour le nom d’utilisateur du clientoriginal et un mot de passe “fictif”.

v L’authentification WebSEAL via le certificat client est autorisée avec cette option.

Utilisation de –b ignorev L’authentification WebSEAL via l’en-tête BA n’est pas autorisée avec cette

option. Cette option utilise l’en-tête BA pour le nom d’utilisateur et le mot depasse du client original.

v L’authentification WebSEAL via le certificat client est autorisée avec cette option.

Utilisation de –b gsov L’authentification WebSEAL via l’en-tête BA n’est pas autorisée avec cette

option. Cette option utilise l’en-tête BA pour les informations de nomd’utilisateur et de mot de passe fournies par le serveur GSO.

v L’authentification WebSEAL via le certificat client est autorisée avec cette option.

Chapitre 7. Jonctions WebSEAL 171

Page 192: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Utilisation de –b filterv En interne, l’option –b filter est utilisée lorsque l’authentification WebSEAL est

définie pour utiliser les informations de l’en-tête BA.Cet en-tête est utilisé pour toutes les transactions HTTP qui suivent. Pour leserveur d’arrière-plan, WebSEAL semble connecté tout le temps.

v L’authentification WebSEAL via le certificat client est autorisée avec cette option.v Si le serveur d’arrière-plan exige l’identité réelle du client (à partir du

navigateur), il est possible d’utiliser les variables CGI suivantes :HTTP_IV_USER, HTTP_IV_GROUP et HTTP_IV_CREDS. Pour les scripts et lesservlets, utilisez les en-têtes HTTP spécifiques d’Access Managercorrespondantes : iv-user, iv-groups, iv-creds.

Création de jonctions proxy TCP et SSLVous pouvez créer des jonctions WebSEAL qui permettent aux communications detransiter par des topologies de réseau utilisant des serveurs proxy HTTP ouHTTPS. Vous pouvez configurer la jonction pour qu’elle gère les requêtes commedes communications TCP standard ou des communications TCP protégées.

Pour que la commande create définisse une jonction TCP ou SSL parl’intermédiaire d’un serveur proxy, l’un des arguments ci-après doit être définipour l’option type :v –t tcpproxy

v –t sslproxy

Pour identifier le serveur proxy et le serveur Web destinataire, les deuxcommandes create et add doivent être dotées des options et des argumentsci-après :

–H <nom_hôte> Nom d’hôte DNS ou adresse IP du serveur proxy.

–P <port> Port TCP du serveur proxy.

–h <nom_hôte> Nom d’hôte DNS ou adresse IP du serveur Webdestinataire.

–p <port> Port TCP du serveur Web destinataire. La valeur par défautest 80 pour les jonctions TCP ; 443 pour les jonctions SSL.

Exemple de jonction de proxy TCP (entrée sur une ligne) :pdadmin> server taskwebseald-<nom_instance> create –t tcpproxy \–H clipper –P 8081 –h www.ibm.com –p 80 /ibm

Exemple de jonction de proxy SSL (entrée sur une ligne) :pdadmin> server taskwebseald-<nom_instance> create–t sslproxy \–H clipper –P 8081 –h www.ibm.com –p 443 /ibm

172 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 193: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Jonctions WebSEAL/WebSEAL via SSLAccess Manager accepte les jonctions SSL entre un serveur WebSEAL frontal et unserveur WebSEAL d’arrière-plan. Pour relier par jonction deux serveurs WebSEALvia SSL et assurer une authentification réciproque, spécifiez l’option –C avec lacommande create.

Exemple :pdadmin> server taskwebseald-<nom_instance> create –t ssl –C –h serverA /jctA

L’authentification réciproque s’effectue en deux étapes :v Le protocole SSL autorise le serveur WebSEAL d’arrière-plan à s’authentifier

auprès du serveur WebSEAL frontal au moyen de son certificat de serveur.v L’option –C permet au serveur frontal de transmettre ses informations d’identité

au serveur d’arrière-plan dans un en-tête BA.

En outre, l’option –C active la fonctionnalité de l’option –c, laquelle vous permetde placer des informations sur l’appartenance à un groupe et sur l’identité duclient, spécifiques d’Access Manager, dans l’en-tête HTTP de la requête destinée auserveur WebSEAL d’arrière-plan. Les paramètres d’en-tête sont iv-user, iv-groups etiv-creds. Voir la section «Spécification de l’identité du client dans les en-têtes HTTP(–c)» à la page 182.

Les conditions suivantes s’appliquent aux jonctions WebSEAL / WebSEAL :v La jonction ne convient qu’au type –t ssl ou –t sslproxy.v Les deux serveurs WebSEAL doivent partager un registre LDAP ou DCE

commun. Le serveur d’arrière-plan peut ainsi authentifier les informationsd’identité du serveur frontal.

Modification des adresses URL des ressources d’arrière-planLes pages renvoyées au client par les applications d’arrière-plan contiennent leplus souvent des adresses URL correspondant à des ressources situées sur lesserveurs d’applications. Il est important que ces adresses puissent acheminer lesrequêtes vers les emplacements corrects de ces ressources.

Par exemple, en environnement non WebSEAL, l’adresse URL entrée par un clientpour une ressource située sur un serveur d’applications peut apparaître commesuit :http://www.abc.com/file.html

Client WebSEALServeur

Web

www.ibm.com

Domaine sécurisé

Serveurproxy

Clipper Internet

-H et -P -h et -pjonction à /ibm

Figure 31. Exemple de jonction proxy

Chapitre 7. Jonctions WebSEAL 173

Page 194: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

WebSEAL, en tant que proxy frontal inversé, offre des services de sécurité auxserveurs d’applications d’arrière-plan via les jonctions WebSEAL. Cettefonctionnalité de jonctions permet d’accéder aux ressources à l’aide d’adresses URLdifférentes.

Par exemple, en environnement WebSEAL, l’adresse URL entrée par un client pourla même ressource située sur un serveur d’arrière-plan relié par jonction doitapparaître comme suit :http://webseal.abc.com/jct/file.html

La fonctionnalité de jonctions de WebSEAL modifie les informations sur le serveuret sur le chemin qui doivent être utilisées pour l’accès aux ressources situées surdes systèmes d’arrière-plan reliés par jonction. Un lien d’accès à une ressourcesituée sur un serveur d’arrière-plan relié par jonction n’aboutit que si l’adresseURL correspondante contient l’identité de la jonction.

Pour le support de cette fonctionnalité de jonctions et pour le maintien del’intégrité des adresses URL, WebSEAL doit, dans la mesure du possible :1. Modifier les adresses URL (liens) contenues dans les réponses envoyées aux

clients.2. Modifier les requêtes résultant des adresses URL (liens) que WebSEAL n’a pas

pu modifier

Il est à noter que les règles et méthodes WebSEAL de filtrage et de traitement desadresses URL ne s’appliquent pas aux liens qui désignent des ressources externes àl’environnement de jonctions d’Access Manager.

Le schéma suivant résume les solutions permettant à WebSEAL de modifier lesadresses URL d’accès aux ressources d’arrière-plan reliées par jonction :

Cette section contient :v «Présentation des types de chemins d’accès utilisés dans les adresses URL» à la

page 175v «Filtrage des adresses URL dans les réponses» à la page 175v «Traitement des adresses URL dans les requêtes» à la page 178

Figure 32. Récapitulatif : modification des adresses URL des ressources d’arrière-plan

174 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 195: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Présentation des types de chemins d’accès utilisés dans lesadresses URL

Toute page HTML est susceptible de contenir des liens (URL) à d’autres ressourcesde ce serveur d’arrière-plan ou d’un emplacement quelconque. Les expressionsd’URL peuvent se présenter dans les formats suivants :v relatifv relatif au serveurv absolu

Les adresses URL exprimées en format relatif n’exigent aucune manipulation de lapart de WebSEAL. Par défaut, le navigateur gère les adresses URL relatives enajoutant au début de l’adresse URL relative les informations correctes sur laméthode, le serveur et le répertoire (y compris la jonction). Ces informationsproviennent de la page dans laquelle se trouve le lien.

Exemple d’expressions URL relatives :abc.html ../abc.html./abc.html sales/abc.html

Toutefois, les formats relatif au serveur et absolu entraînent des difficultés. Lesliens aux ressources d’arrière-plan exprimés aux formats absolu ou relatif auserveur n’aboutissent que si WebSEAL a été capable de modifier l’expression URLet d’inclure les informations de jonction.

Exemple d’expression URL relative au serveur :/abc.html /accounts/abc.html

Exemple d’expression URL absolue :http://www.tivoli.com/abc.html

Remarque : Tous les programmeurs de scripts Web sont invités à utiliser des liensrelatifs (et non absolus ou relatifs au serveur) pour les URL généréesdynamiquement.

Filtrage des adresses URL dans les réponsesCette section décrit le filtrage, par WebSEAL, des réponses en provenance desserveurs d’applications reliés par jonction.v «Règles de filtrage d’adresses URL standard pour WebSEAL» à la page 175v «Modification des adresses URL absolues avec filtrage de script» à la page 177v «Filtrage des modifications de l’en-tête Content-Length» à la page 177

Règles de filtrage d’adresses URL standard pour WebSEALWebSEAL utilise un ensemble de règles standard utilisé pour le filtrage desadresses URL contenues dans les pages de réponse aux requêtes des clients. Pourappliquer le filtrage standard des adresses URL, WebSEAL doit pouvoir “afficher”les adresses URL dans une page provenant du serveur d’arrière-plan. WebSEAL nepeut pas utiliser les règles de filtrage standard pour les adresses URL contenuesdans des scripts.

Par défaut, WebSEAL filtre uniquement les documents de type MIME “text/html”et “text/vnd.wap.wml” qui proviennent des serveurs reliés par jonction. Vouspouvez configurer d’autres types MIME à l’aide de la strophe [filter-content-types]du fichier de configuration webseald.conf.

Chapitre 7. Jonctions WebSEAL 175

Page 196: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Les adresses URL relatives sont toujours gérées de façon appropriée par lenavigateur. Toutefois, WebSEAL doit ajouter le nom de la jonction au chemind’accès des adresses URL absolues et relatives au serveur qui font référence auxressources situées sur des serveurs reliés par jonction.v Les adresses URL relatives au serveur indiquent la position d’une URL par

rapport à la racine du document du serveur relié par jonction, par exemple :/dir/file.html

Ces URL sont modifiées de façon à refléter le point de jonction du serveur reliépar jonction, par exemple :/jct/dir/file.html

v Les adresses URL absolues indiquent une position de l’URL par rapport à unnom d’hôte ou à une adresse IP, et un port de réseau, par exemple :http://<nom_hôte>[:<port>]/file.html,ouhttps://<nom_hôte>[:<port>]/file.html

Ces URL sont modifiées selon les ensembles de règles suivants :1. Si l’adresse URL est HTTP et que l’ensemble hôte/port correspond à un serveur

TCP relié par jonction, l’URL est modifiée pour être de type relatif au serveurWebSEAL et pour refléter le point de jonction. Par exemple :http://<nom_hôte>[:<port>]/file.html

devient :/tcpjct/file.html

2. Si l’adresse URL est HTTPS et que l’ensemble hôte/port correspond à unserveur SSL relié par jonction, l’URL est modifiée pour être de type relatif auserveur WebSEAL et pour refléter le point de jonction. Par exemple :https://<nom_hôte>[:<port>]/file.html

devient :/ssljct/file.html

3. Seules les adresses URL dont le type de contenu est défini dans la strophe[filter-content-types] du fichier de configuration webseald.conf sont filtrées.

4. Les codes META sont toujours filtrés pour les requêtes d’actualisation, parexemple :<META HTTP-EQUIV=”Refresh” CONTENT=”5;URL=http://server/url”>

5. Si un code BASE contient un attribut HREF, il est supprimé de la réponse auclient.

Les paramètres de filtrage des adresses URL dans les serveurs reliés par jonction setrouvent dans la strophe [filter-url] du fichier de configuration webseald.conf. Lastrophe [filter-url] contient la liste des codes HTML que le serveur WebSEAL filtreou modifie pour convertir les adresses URL absolues obtenues par l’intermédiaired’un serveur relié par jonction.

Tous les codes HTML courants sont configurés par défaut. L’administrateur doitpeut-être rajouter des codes HTML contenant des adresses URL.

176 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 197: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Modification des adresses URL absolues avec filtrage de scriptUne configuration supplémentaire de WebSEAL est nécessaire pour lui permettrede gérer des adresses URL absolues contenues dans des scripts. Les langages derédaction des scripts Web sont Javascript, VBscript, ASP, JSP et ActiveX, entreautres. Le fichier de configuration webseald.conf contient un paramètre qui activeou désactive le filtrage des adresses URL absolues :[script-filtering]script-filter = no

Le filtrage de script est désactivé par défaut. Pour activer le filtrage de script,définissez :script-filter = yes

Remarque : Vous devez également spécifier l’option –j pour créer la jonction auserveur d’arrière-plan.

Le mécanisme script-filter attend des URL absolues respectant le format standard :schéma, serveur, ressource.http://serveur/ressource

Le mécanisme script-filter remplace les portions schéma et serveur du lien par lesinformations de jonction qui conviennent./nom_jonction/ressource

Cette solution analyse le script incorporé au code HTML et requiert par conséquentun temps système supplémentaire qui risque d’entraîner une diminution desperformances. Limitez votre utilisation du paramètre script-filter aux jonctionspour lesquelles le filtrage d’URL absolue doit être pris en charge.

Le diagramme suivant illustre cette solution de filtrage d’adresses URL :

Filtrage des modifications de l’en-tête Content-LengthNormalement, l’en-tête Content-Length contenu dans une réponse de serveurd’arrière-plan indique la taille du contenu renvoyé. Lorsque WebSEAL filtre lesadresses URL et ajoute des informations de jonction au chemin d’accès des URLcontenues dans la page, la taille réelle de la page est plus élevée que celle indiquéedans l’en-tête Content-Header.

Client

WebSEAL Serveur d’applications(prend en charge Javascript)

Script contenantune URL absolue :

http://server/abc.html

Le client reçoit :/jctA/abc.html

Requête Requête

Le client effectue unerequête à l’aide du lien :

/jctA/abc.htmlabc.html

localisé avec succès

script-filtering=yesWebSEAL reformate le lien en :

/jctA/abc.html

1

2

3

/jctAavec option -j

Figure 33. Filtrage des adresses URL absolues

Chapitre 7. Jonctions WebSEAL 177

Page 198: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

WebSEAL ne peut pas connaître la longueur du nouveau contenu avant d’avoirréellement envoyé le flux au client. A ce stade, il est trop tard pour insérer unnouvel en-tête Content-Length. WebSEAL répond à cette situation de la façonsuivante :1. WebSEAL place la valeur de l’en-tête Content-Length d’origine dans un nouvel

en-tête appelé X-Old-Content-Length.Tous les applets et toutes les applications écrits pour la recherche de cet en-têtepeuvent accéder à la valeur initiale (préfiltrée) de l’en-tête Content-Length.

2. WebSEAL consigne la valeur modifiée (post-filtrée) de l’en-tête Content-Lengthdans le fichier request.log.

3. L’en-tête Content-Length ne s’affiche plus.

Traitement des adresses URL dans les requêtesUne difficulté se présente lorsque les adresses URL sont générées dynamiquementpar des applications c″té client (applets) ou sont incorporées à des scripts au seinde code HTML. Les langages de rédaction des scripts Web sont Javascript,VBscript, ASP, JSP et ActiveX, entre autres. Ces applets et ces scripts s’exécutentune fois que la page est parvenue au navigateur du client. WebSEAL ne peutjamais appliquer ses règles de filtrage standard à ces adresses URL généréesdynamiquement.

Cette section décrit la méthode de traitement, par WebSEAL, des liens c″té clientrelatifs au serveur générés dynamiquement et inclus dans les requêtes concernantdes ressources situées sur des serveurs reliés au réseau par jonction.v «Gestion des adresses URL relatives au serveur avec des cookies de jonction (-j)»

à la page 178v «Gestion d’adresses URL relatives au serveur avec mappage des jonctions» à la

page 179

Remarque : Il n’existe aucune solution permettant de gérer les adresses URLabsolues générées c″té client.

Gestion des adresses URL relatives au serveur avec des cookiesde jonction (-j)Les adresses URL relatives au serveur générées c″té client par des applets et desscripts n’ont généralement pas d’informations sur le point de jonction. WebSEALne peut pas filtrer une adresse URL située c″té client. Lorsqu’une demande clientrelative à une ressource utilise cette URL, WebSEAL peut tenter de traiter denouveau l’URL relative au serveur via l’utilisation de cookies de jonction.

Dans le scénario suivant, un script situé dans la page demandée génèredynamiquement une expression d’URL relative au serveur au moment de l’arrivéedans le navigateur. Si le client demande la ressource spécifiée par ce lien,WebSEAL reçoit une requête de page locale. Lorsqu’il détecte que la page estintrouvable, il renvoie une erreur “Introuvable” au client.

L’option –j fournit une solution basée sur cookie pour la gestion des URL relativesau serveur qui sont générées dynamiquement par un script exécuté sur la machinecliente.

Syntaxe générale :pdadmin> server task <non_serveur> create ... –j...

178 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 199: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Pour chaque page demandée, un cookie ”identificateur de jonction” est envoyé auclient. Le cookie contient la variable et la valeur suivantes :IV_JCT_<nom_serveur_arrière-plan> =</nom_jonction>

Lorsque le client envoie une requête à partir de cette page à l’aide d’une URLrelative au serveur et générée dynamiquement, WebSEAL reçoit, commeauparavant, une demande relative à une ressource locale. En cas d’échec à localiserla ressource, WebSEAL relance immédiatement la requête à l’aide des informationsde jonction fournies par le cookie. A l’aide des informations de jonction correctesde l’expression d’URL, la ressource est localisée.

Le diagramme suivant illustre cette solution de filtrage d’adresses URL relatives auserveur

WebSEAL fournit une autre solution (qui n’est pas basée sur un cookie) de gestiondes adresses URL relatives à un serveur. Voir la section «Gestion d’adresses URLrelatives au serveur avec mappage des jonctions» à la page 179.

Gestion d’adresses URL relatives au serveur avec mappage desjonctionsLes adresses URL relatives au serveur générées c″té client par des applets et desscripts n’ont généralement pas d’informations sur le point de jonction. WebSEALne peut pas filtrer une adresse URL située c″té client. Lorsqu’une demande clientrelative à une ressource utilise cette URL, WebSEAL peut tenter de traiter denouveau l’URL relative au serveur via le mappage de jonctions.

Access Manager propose une solution alternative à la solution basée sur cookiepour le filtrage des URL relatives au serveur générées dynamiquement. Vouspouvez créer et activer une table de mappage des jonctions qui fait correspondredes ressources destinataires spécifiques à des noms de jonction.

WebSEAL vérifie les informations d’emplacement dans l’URL relative au serveurpar rapport aux données contenues dans la table de mappage des jonctions. Si lesinformations de chemin contenues dans l’URL correspondent à une entrée de latable, WebSEAL adresse la requête à la jonction associée à cet emplacement.

La table est un fichier texte ASCII appelé jmt.conf. Son emplacement est spécifiédans la strophe [junction] du fichier de configuration webseald.conf.jmt-map = lib/jmt.conf

Client

WebSEAL Application Server(serves Javascript)

Script containingserver-relative URL:

/abc.html

/jctAwith -j option

Script runs and displayslink:/abc.html

Request Request

Client makes requestusing link:/abc.html

abc.htmlsuccessfully locatedCookie sent

with requrest

WebSEAL reformatslink to:

/jctA/abc.html

1

2

3

/jctA

WebSEAL sends cookieto identify junction

/jctA

Figure 34. Traitement d’adresses URL relatives au serveur

Chapitre 7. Jonctions WebSEAL 179

Page 200: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Le format d’entrée des données dans la table est composé d’un nom de jonction,d’un espace et du modèle d’emplacement de ressource. Vous pouvez égalementexprimer le modèle d’emplacement de ressource à l’aide de caractères génériques.

Dans l’exemple suivant de fichier de configuration de mappage de jonctions, deuxserveurs d’arrière-plan sont reliés par une jonction à WebSEAL aux points /jctA et/jctB :#jmt.conf#<nom_jonction><modèle_emplacement_ressource>/jctA /documents/release-notes.html/jctA /travel/index.html/jctB /accounts/*/jctB /images/weather/*.jpg

La table de mappage jmt.conf originale est un fichier vide. Après avoir ajouté desdonnées au fichier, servez-vous de la commande jmt load pour “charger” lesdonnées afin que WebSEAL soit informé des nouveautés.pdadmin> server task <nom_serveur> jmt loadChargement de la table JMT terminé.

Les conditions suivantes s’appliquent à la solution de table de mappage desjonctions :v Cette solution n’exige pas l’option –j ou un cookie de jonctionv La table de mappage doit être configurée et activée par un administrateur de

sécuritév Cette solution ne gère pas les liens créés avec des adresses URL absoluesv La mise en correspondance du modèle d’emplacement de ressource doit être

unique dans l’espace Web local et dans les serveurs d’applications Web reliés parjonction

v En cas d’entrée de modèle en double dans le fichier, la table de mappage ne secharge pas. WebSEAL continue cependant à s’exécuter.

v En cas d’erreur de chargement de la table de mappage, celle-ci n’est pasdisponible. WebSEAL continue cependant à s’exécuter.

v Si la table de mappage est vide ou qu’elle comporte une erreur dans ses entrées,elle ne se charge pas. WebSEAL continue cependant à s’exécuter.

v Toute erreur se produisant pendant le chargement de la table de mappagegénère des entrées de mise en service dans le fichier journal du serveurWebSEAL (webseald.log).

Autres options de jonctionVous pouvez ajouter les fonctionnalités de jonction WebSEAL suivantes avecd’autres options :v «Nouvelle fonction forcée (–f)» à la page 181v «Spécification de l’identité du client dans les en-têtes HTTP (–c)» à la page 182v «Spécification des adresses IP client dans les en-têtes HTTP (–r)» à la page 183v «Limitation de la taille des en-têtes HTTP générés par WebSEAL» à la page 184v «Transmission de cookies de session à des serveurs de portail reliés par jonction

(–k)» à la page 184v «Prise en charge d’adresses URL sans distinction de casse (–i)» à la page 185v «Prise en charge d’une jonction avec état (–s, –u)» à la page 185

180 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 201: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

v «Spécification d’UUID de serveur d’arrière-plan pour des jonctions avec état(–u)» à la page 186

v «Etablissement de jonctions avec des systèmes de fichiers Windows (–w)» à lapage 188

Nouvelle fonction forcée (–f)Lorsque vous souhaitez forcer une nouvelle jonction pour en remplacer une autre,vous devez utiliser l’option –f.

L’exemple suivant (le nom d’instance de serveur est cruz) illustre cette procédure :1. Connectez-vous à pdadmin :

# pdadminpdadmin> loginEntrer ID utilisateur : sec_masterEntrer mot de passe :pdadmin>

2. Servez-vous de la commande server task list pour afficher tous les points dejonction en cours :pdadmin> server task webseald-cruz list/

3. Servez-vous de la commande server task show pour afficher les détails de lajonction :pdadmin> server task webseald-cruz show /Junction point: /Type: LocalLimite matérielle de la jonction : 0 - avec une valeur globaleLimite logicielle de la jonction : 0 - avec une valeur globaleUnités d’agent actives : 0Ré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 uneautre) :pdadmin> server task webseald-cruz create -t local -f -d /tmp/docs /Created junction at /

5. Affichez le nouveau point de jonction :pdadmin> server task webseald-cruz list/

6. Affichez les détails de la jonction :pdadmin> server task webseald-cruz show /Junction point: /Type: LocalLimite matérielle de la jonction : 0 - avec une valeur globaleLimite logicielle de la jonction : 0 - avec une valeur globaleUnités d’agent actives : 0Répertoire racine : /tmp/docs

Chapitre 7. Jonctions WebSEAL 181

Page 202: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Spécification de l’identité du client dans les en-têtes HTTP(–c)

L’option –c vous permet d’insérer des informations propres à Access Manager surl’appartenance à un groupe et sur l’identité du client dans les en-têtes HTTP desrequêtes destinées à des serveurs tiers reliés par une jonction. Les informations deces en-têtes permettent aux applications des serveurs tiers reliés par une jonctiond’exécuter des actions spécifiques de l’utilisateur en fonction de l’identité AccessManager du client.

Les informations d’en-tête HTTP doivent être converties par le serveurd’arrière-plan au format de la variable d’environnement correspondant à un servicedu serveur d’arrière-plan. Leur conversion au format d’une variabled’environnement CGI s’effectue en remplaçant tous les tirets (-) par des traits desoulignement (_) et par le déplacement de “HTTP” en début de chaîne. La valeurde l’en-tête HTTP devient celle de la nouvelle variable d’environnement.

Champs d’en-têteHTTP spécifiques de PD

Variables d’environnementCGI équivalentes

Description

iv-user = HTTP_IV_USER = Nom du client sous forme abrégée oudétaillée. “Unauthenticated” par défaut,si le client n’est pas authentifié (inconnu).

iv-groups = HTTP_IV_GROUPS = Liste des groupes auxquels appartient leclient. Se compose d’entrées entreapostrophes séparées par une virgule.

iv-creds = HTTP_IV_CREDS = Structure de données opaque codéereprésentant des données d’autorisationAccess Manager. Fournit des autorisationsaux serveurs éloignés pour que lesapplications de niveau intermédiairepuissent utiliser l’API d’autorisation pourappeler le service d’autorisation.Reportez-vous au document intitulé IBMTivoli Access Manager Authorization C APIDeveloper’s Reference.

Les entrées d’en-tête HTTP spécifiques d’Access Manager sont utilisées par lesprogrammes CGI en tant que variables d’environnement HTTP_IV_USER,HTTP_IV_GROUPS et HTTP_IV_CREDS. Pour les autres produits de structured’application, reportez-vous à la documentation propre à chaque produit poursavoir comment extraire des en-têtes à partir de requêtes HTTP.

Syntaxe –cL’option –c spécifie quelles données d’en-tête HTTP spécifiques d’Access Managersont envoyées au serveur d’applications d’arrière-plan.–c <types_en-tête>

Les arguments types_en-tête sont les suivants : all, iv_user, iv_user_l, iv_groups etiv_creds.

Argument Description

iv_user Contient le nom d’utilisateur (sous forme abrégée) comme champiv-user de l’en-tête HTTP de la requête.

iv_user_l Contient le nom distinctif de l’utilisateur (sous forme détaillée)comme champ iv-user de l’en-tête HTTP de la requête.

182 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 203: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Argument Description

iv_groups Contient la liste des groupes de l’utilisateur comme champiv-groups de l’en-tête HTTP de la requête.

iv_creds Contient les données d’autorisation de l’utilisateur comme champiv-creds de l’en-tête HTTP de la requête.

Remarque : Spécifiez iv_user ou iv_user_l, mais pas les deux ensemble.

L’option –c all insère les trois types d’informations d’identité dans l’en-tête HTTP(le nom en format abrégé iv_user est alors utilisé).

Remarque : Pour séparer plusieurs arguments, n’utilisez que des virgules. N’entrezpas d’espaces.

Exemples :–c all

–c iv_creds

–c iv_user,iv_groups

–c iv_user_l,iv_groups,iv_creds

Spécification des adresses IP client dans les en-têtes HTTP(–r)

L’option –r vous permet d’insérer des informations sur les adresses IP client dansles en-têtes HTTP des requêtes destinées à des serveurs d’applications reliés parune jonction. Les informations de ces en-têtes permettent aux applications desserveurs tiers reliés par une jonction d’exécuter des actions en fonction de cesinformations sur les adresses IP.

Les informations d’en-tête HTTP doivent être converties par le serveurd’arrière-plan au format de la variable d’environnement correspondant à un servicedu serveur d’arrière-plan. Leur conversion au format d’une variabled’environnement CGI s’effectue en remplaçant tous les tirets (-) par des traits desoulignement (_) et par le déplacement de “HTTP” en début de chaîne. La valeurde l’en-tête HTTP devient celle de la nouvelle variable d’environnement.

Remarque : La valeur de l’adresse IP ne représente pas toujours l’adresse de lamachine client d’origine. Elle peut représenter celle d’un serveurproxy ou d’un convertisseur NAT (Network Address Translator).

Champ d’en-têteHTTP spécifiques de PD

Variable d’environnementCGI équivalente

Description

iv-remote-address HTTP_IV_REMOTE_ADDRESS Adresse IP du client. Cette valeur peutreprésenter l’adresse IP d’un serveur proxy oud’un convertisseur NAT.

L’option –r indique que l’adresse IP de la requête entrante doit être envoyée auserveur d’applications d’arrière-plan. L’option est exprimée sans aucun argument.

Chapitre 7. Jonctions WebSEAL 183

Page 204: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Limitation de la taille des en-têtes HTTP générés parWebSEAL

Vous pouvez limiter la taille des en-têtes HTTP générés par WebSEAL insérés dansles requêtes destinées aux serveurs reliés au réseau par jonction. Le paramètremax-webseal-header-size de la strophe [junction] du fichier de configurationwebseald.conf spécifie la taille maximale (exprimée en octets) des en-têtes HTTPgénérés par WebSEAL. La valeur “0” désactive cette fonction :[junction]max-webseal-header-size = 0

Ce paramètre peut être utile lorsqu’un serveur d’applications d’arrière-plan rejettedes en-têtes HTTP générés par WebSEAL en raison de leur taille trop volumineuse.Par exemple, un en-tête iv-creds d’utilisateur appartenant à de nombreux groupesrisque d’être trop volumineux.

Ce paramètre, lorsqu’il est configuré, permet de diviser les en-têtes WebSEALdépassant la valeur maximale. L’exemple ci-après provenant d’une application CGIillustre l’effet de la division d’en-têtes :HTTP_IV_CREDS_1=Version=1, BAKs3DCCBnMMADCCBm0wggZpAgIDkDCCAYUwKzAHTTP_IV_CREDS_2=+0+8eAgI8iAICEdYCAgCkAgFUBAaSVNCJqncMOWNuPXNlY21==HTTP_IV_CREDS_SEGMENTS=2

Si vous activez cette fonction, vous devez modifier l’application d’arrière-plan afinqu’elle reconnaisse les en-têtes divisés au lieu des en-têtes HTTP WebSEALstandard.

Transmission de cookies de session à des serveurs de portailreliés par jonction (–k)

Un portail Web est un serveur qui propose une grande gamme de services et deressources individualisés. L’option –k vous permet d’envoyer le cookie de sessionAccess Manager (session établie initialement entre le client et WebSEAL) à unserveur de portail d’arrière-plan. Cette option sert à prendre en charge directementl’intégration de WebSEAL avec la solution Plumtree Corporate Portal.

Lorsqu’un client demande la liste de ses ressources personnelles au serveur deportail, celui-ci la dresse en accédant aux ressources situées sur d’autres serveursd’applications également protégés par WebSEAL. Le cookie de session permet auserveur de portail d’effectuer une connexion unique transparente à ces serveursd’applications, pour le compte du client.

Lorsque vous créez la jonction entre WebSEAL et le serveur de portaild’arrière-plan, vous devez inclure l’option –k sans aucun argument.

Conditions à prendre en compte pour configurer un serveur de portail :v Pour un accès avec nom d’utilisateur et mot de passe, l’authentification par

formulaires est requise. N’utilisez pas l’authentification de base.v Le paramètre ssl-id-sessions situé dans la strophe [session] dans les fichiers de

configuration webseald.conf doit avoir la valeur “no”. Pour les communicationsHTTPS, ce paramètre force l’utilisation d’un cookie de session, à la place d’un IDde session SSL, afin de gérer l’état de la session.

v Si le serveur de portail a un groupe de serveurs WebSEAL comme serveursfrontaux, activez le cookie de secours. Celui-ci contient des donnéesd’autorisation chiffrées permettant à l’authentification d’aboutir avec n’importequel serveur WebSEAL répliqué traitant la requête.

184 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 205: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Prise en charge d’adresses URL sans distinction de casse (–i)Par défaut, Access Manager traite les adresses URL comme faisant la distinction decasse lors des vérifications effectuées sur les contrôles d’accès. L’option –i permetde spécifier que WebSEAL traite les URL sans distinction de casse lors de lagestion d’une requête adressée à un serveur d’arrière-plan relié par jonction.

Lorsque vous définissez cette option pour la jonction, WebSEAL ne fait pas ladistinction entre les caractères majuscules et minuscules lorsqu’il analyse lesadresses URL. Par défaut, les serveurs Web sont censés être sensibles à la casse.

Bien que la plupart des serveurs HTTP acceptent la spécification HTTP définissantles URL comme étant sensibles à la casse, certains serveurs HTTP traitent les URLsans distinction de casse.

Par exemple, sur des serveurs ne faisant pas la distinction entre les majuscules etles minuscules, les deux adresses URL suivantes :http://server/sales/index.htm

http://server/SALES/index.HTM

sont considérées comme identiques. Ce comportement exige d’un administrateurqu’il définisse les mêmes contrôles d’accès (LCA) sur les deux URL.

En reliant par jonction un serveur tiers avec l’option –i, WebSEAL traite lesadresses URL envoyées à ce serveur sans respecter la casse.

Prise en charge d’une jonction avec état (–s, –u)La plupart des applications activées pour le Web conservent un “état”correspondant à une série de requêtes HTTP émanant d’un client. Cet état sert, parexemple, à :v Suivre la progression d’un utilisateur dans les champs d’un masque de saisie

généré par un programme CGIv Maintenir le contexte d’un utilisateur pendant l’exécution d’une série

d’interrogations sur la base de donnéesv Maintenir une liste de produits dans une application d’achats en ligne où un

utilisateur se déplace aléatoirement et sélectionne des produits à acheter

Il est possible de répliquer les serveurs exécutant des applications activées pour leWeb pour améliorer les performances en répartissant la charge. Lorsque le serveurWebSEAL procure une jonction avec ces répliques de serveurs d’arrière-plan, il doitvérifier que toutes les requêtes contenues au sein d’une session client sonttransmises au serveur correct et non réparties entre les répliques en fonction desrègles d’équilibrage de charge.

Par défaut, Access Manager équilibre la charge du serveur d’arrière-plan enrépartissant les requêtes entre toutes les répliques de serveurs disponibles. Il utiliseun algorithme de calcul du “moins occupé”. Cet algorithme dirige chaque nouvellerequête vers le serveur ayant le nombre de connexions en cours le plus faible.

La commande create avec l’option –s ignore cette règle d’équilibrage de charge etcrée une jonction “avec état” qui garantit l’acheminement des requêtes vers lemême serveur pendant toute une session. A la première requête du client,WebSEAL place dans le système client un cookie contenant l’UUID du serveur

Chapitre 7. Jonctions WebSEAL 185

Page 206: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

d’arrière-plan désigné. Lors des requêtes ultérieures du client à la même ressource,les informations d’UUID du cookie garantissent que les requêtes sont acheminéesau même serveur d’arrière-plan.

L’option –s convient à un serveur WebSEAL frontal avec plusieurs serveursd’arrière-plan reliés par une jonction au même point de jonction. Vous remarquezqu’une fois la première jonction créée comme jonction avec état, la commande addest spécifiée sans l’option –s pour relier les autres répliques des serveursd’arrière-plan au même point de jonction.

Si le scénario implique plusieurs serveurs WebSEAL frontaux, tous reliés parjonction aux mêmes serveurs d’arrière-plan, utilisez l’option –u pour spécifiercorrectement chaque UUID de serveur d’arrière-plan pour chaque serveurWebSEAL frontal. Voir la section «Spécification d’UUID de serveur d’arrière-planpour des jonctions avec état (–u)».

Spécification d’UUID de serveur d’arrière-plan pour desjonctions avec état (–u)

A la création d’une jonction avec un serveur d’applications Web d’arrière-plan,WebSEAL génère normalement un UUID (Unique Universal Identifier) qui identifiece serveur d’arrière-plan. Utilisé en interne, cet UUID permet également de gérerles jonctions avec état (create –s).

A la première requête du client, WebSEAL place dans le système client un cookiecontenant l’UUID du serveur d’arrière-plan désigné. Lors des requêtes ultérieuresdu client à la même ressource, les informations d’UUID du cookie garantissent queles requêtes sont acheminées au même serveur d’arrière-plan.

La gestion des jonctions avec état devient plus complexe lorsque plusieurs serveursWeb frontaux sont reliés par jonction à plusieurs serveurs d’arrière-plan.Normalement, chaque jonction entre un serveur WebSEAL frontal et un serveurd’arrière-plan génère un UUID unique pour le serveur d’arrière-plan. Autrementdit, un seul serveur d’arrière-plan sera doté d’un UUID différent sur chaqueserveur WebSEAL frontal.

La présence de plusieurs serveurs frontaux nécessite un mécanisme d’équilibragede charge pour répartir la charge entre les deux serveurs. Par exemple, il estpossible qu’un “état” initial ait été établi vers un serveur d’arrière-plan parl’intermédiaire du serveur WebSEAL 1 avec un UUID spécifique.

WebSEAL

Serveurd’applications 1(UUID1)

Serveurd’applications 2(UUID2)

ClientJonctionsavec étatCookie

avecUUID2

Figure 35. Les jonctions avec état utilisent les UUID de serveurs d’arrière-plan

186 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 207: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Toutefois, si une future requête du même client est acheminée par l’intermédiairedu serveur WebSEAL 2 au moyen du mécanisme d’équilibrage de charge, l’“état”n’existe plus, à moins que le serveur WebSEAL 2 utilise le même UUID pouridentifier le même serveur d’arrière-plan. Ce n’est généralement pas le cas.

L’option –u vous permet de fournir le même UUID pour un serveur d’arrière-plandonné à chaque serveur WebSEAL frontal.

A titre d’exemple, imaginez deux répliques d’un serveur WebSEAL frontal,possédant chacun une jonction avec deux serveurs d’arrière-plan. Lorsque vouscréez la jonction avec état entre le serveur WebSEAL 1 et le serveur d’arrière-plan2, un UUID unique (UUID A) est généré pour identifier le serveur d’arrière-plan 2.Toutefois, lorsqu’une jonction avec état est créée entre le serveur WebSEAL 2 et leserveur d’arrière-plan 2, un autre UUID (UUID B) est généré pour identifier leserveur d’arrière-plan 2.

Un “état” établi entre un client et un serveur d’arrière-plan 2, via le serveurWebSEAL 1, échoue si une requête ultérieure du client est acheminée parl’intermédiaire du serveur WebSEAL 2.

Procédez comme suit pour spécifier un UUID pendant la création d’une jonction :1. Créez une jonction entre le serveur WebSEAL 1 et chaque serveur

d’arrière-plan.Spécifiez create –s et add.

2. Répertoriez les UUID générés pour chaque serveur d’arrière-plan pendantl’étape 1.Spécifiez show.

3. Créez une jonction entre le serveur WebSEAL 2 et chaque serveurd’arrière-plan, puis indiquez les UUID spécifiés à l’étape 2.Spécifiez create –s –u et add –u.

Dans la figure suivante, le serveur d’arrière-plan 1 est identifié par WebSEAL-1 etWebSEAL-2 comme UUID 1. Le serveur d’arrière-plan 2 est identifié parWebSEAL-1 et WebSEAL-2 comme UUID 2.

WebSEAL-1

Jonctionsavec état

WebSEAL-2

UUID B

Serveurd’applications 1UUID A

Serveurd’applications 2

Figure 36. UUID différents

Chapitre 7. Jonctions WebSEAL 187

Page 208: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Exemple :Dans l’exemple suivant,v WebSEAL-1 est appelé WS1v WebSEAL-2 est appelé WS2v Le serveur d’arrière-plan 1 est appelé APP1v Le serveur d’arrière-plan 2 est appelé APP2pdadmin> server task webseald-WS1 create –t tcp –h APP1 –s /mntpdadmin> server task webseald-WS1 add –h APP2 /mntpdadmin> server task webseald-WS1 show /mnt

(UUID1 et UUID2 sont ainsi indiqués)pdadmin> server task webseald-WS2 create –t tcp –h APP1 –u<UUID1> –s /mntpdadmin> server task webseald-WS2 add –h APP2 –u<UUID2> /mnt

Lorsqu’un client définit une connexion avec état avec le serveur d’arrière-plan 2, ilreçoit un cookie contenant l’UUID2. L’exemple précédent assure que le client seconnecte systématiquement au serveur d’arrière-plan 2, que les requêtes futuressoient acheminées par WebSEAL-1 ou WebSEAL-2.

Etablissement de jonctions avec des systèmes de fichiersWindows (–w)

WebSEAL effectue des contrôles de sécurité sur les requêtes client portant sur desserveurs d’arrière-plan reliés par jonction, d’après les chemins de fichiers spécifiésdans l’adresse URL. Ce contrôle de sécurité peut être compromis car les systèmesde fichiers Win32 fournissent deux méthodes d’accès aux noms de fichiers longs.

La première méthode reconnaît tout le nom de fichier ( abcdefghijkl.txt). Parexemple :abcdefghijkl.txt

La deuxième méthode reconnaît le format de noms de fichiers 8.3 (compatibilitéamont). Par exemple :abcdef~1.txt

WebSEAL-1

Serveurd’applications 2

(UUID 2)

Jonctionsavec état

Mécanismed’équilibrage

de charge

WebSEAL-2

Client

Cookieavec

UUID 2

Serveurd’applications 1

(UUID 1)

Figure 37. Spécification d’UUID de serveur d’arrière-plan pour des jonctions avec état

188 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 209: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Lorsque vous créez des jonctions dans un environnement Windows, il estimportant de restreindre le contrôle d’accès à une représentation d’objetuniquement et de ne pas laisser de failles permettant de contourner le mécanismede sécurité.

L’option –w offre les mesures de protection suivantes :1. Evite l’utilisation du format de noms de fichiers 8.3

Lorsque la jonction est configurée à l’aide de l’option –w, un utilisateur ne peutpas éviter une LCA explicite sur un nom de fichier long en utilisant la formecourte (8.3) du nom de fichier. Le serveur renvoie une erreur “403 Interdit”pour toute entrée d’un nom de fichier court.

2. Interdit l’utilisation de points à la fin des noms de répertoires et de fichiersSi un fichier ou un répertoire contient des points en fin de nom, le messaged’erreur 403 “Interdit” s’affiche.

3. Ne distingue pas les minuscules des majuscules grâce à la définition de l’option–i

L’option –w appelle automatiquement l’option –i. Cette option permet despécifier que WebSEAL doit traiter les URL sans distinction de casse lors de lagestion d’une requête adressée à un serveur relié au réseau par jonction. Aprèsun contrôle de LCA effectué avec succès, la casse de l’adresse URL est restauréelorsque la requête est envoyée au serveur d’arrière-plan.

Remarque : Si vous avez besoin du contrôle de la casse pour les noms defichiers uniquement, utilisez simplement l’option –i sur la jonctionet non l’option –w.

Exemple :Dans un environnement Windows, le fichier :\Program Files\Company Inc\Release.Notes

est également accessible par les chemins d’accès suivants :1. \progra~1\compan~2\releas~3.not

2. \Program Files\Company Inc.\Release.Notes

3. \program files\company inc\release.notes

L’exemple 1 illustre la façon dont Windows peut créer un alias (pour compatibilitéDOS) ne contenant pas d’espace dans les noms de fichier et conforme au format8.3.L’option –w permet à WebSEAL de rejeter ce format pour les contrôles de LCA.

L’exemple 2 illustre la façon dont Windows peut inclure un point de fin.L’option–w permet à WebSEAL de rejeter ce format pour les contrôles de LCA.

L’exemple illustre la façon dont Windows autorise la non distinction entreminuscules et majuscules pour les noms de fichiers. L’option –w appelle l’option –iafin de garantir un contrôle de LCA sans distinction entre les minuscules et lesmajuscules.

Chapitre 7. Jonctions WebSEAL 189

Page 210: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Remarques techniques sur l’utilisation des jonctions WebSEALv «Montage de plusieurs serveurs sur la même jonction» à la page 190v «Exceptions à la mise en oeuvre des droits d’accès sur les jonctions» à la page

190v «Authentification par certificat sur les jonctions» à la page 190

Montage de plusieurs serveurs sur la même jonctionVous pouvez monter plusieurs répliques de serveur au même point de jonction, ennombre illimité.

Tous les serveurs montés au même point de jonction doivent être des répliques(espaces Web en miroir) et utiliser le même protocole : HTTP ou HTTPS. Nemontez pas des serveurs dissemblables au même point de jonction.

A partir de l’espace Web du serveur Access Manager principal, vous accédez auxpages appartenant au(x) serveur(s) relié(s) par jonction. En principe, vous ne devezpas avoir de problème d’accès à ces pages (dans la limite de vos droits d’accès,bien évidemment) et les pages doivent sembler cohérentes. S’il arrive qu’une pagesoit introuvable ou modifiée, elle n’a pas été répliquée correctement.

Vérifiez que le document existe et est identique à l’arborescence de documents desdeux serveurs répliqués.

Exceptions à la mise en oeuvre des droits d’accès sur lesjonctions

Certains droits d’accès Access Manager ne peuvent pas être mis en oeuvre au-delàd’une jonction. Ainsi, vous ne pouvez pas contrôler l’exécution d’un script CGIavec le droit d’accès x ou une liste de répertoires avec le droit d’accès l. WebSEALne peut pas déterminer de façon précise si un objet demandé sur un serveurd’arrière-plan est, par exemple, un fichier programme CGI, une liste de répertoiresdynamique ou un objet HTTP classique.

L’accès aux objets à travers des jonctions, y compris aux programmes CGI et auxlistes de répertoires, est contr″lé uniquement par le droit d’accès r.

Authentification par certificat sur les jonctionsA l’installation, WebSEAL est configuré avec un certificat de test autre que celuipar défaut. Le paramètre webseal-cert-keyfile-label, situé dans la strophe [ssl] dufichier de configuration webseald.conf, désigne le certificat de test comme certificatc″té client actif.

Si un serveur d’applications d’arrière-plan relié par jonction exige que WebSEALs’identifie avec un certificat c″té client, vous devez commencer par créer cecertificat, l’installer et lui affecter un libellé à l’aide de l’utilitaire iKeyman. Vouspouvez ensuite configurer la jonction avec l’option –K <libellé_clé>. Voir la section«Jonctions SSL authentifiées de façon réciproque» à la page 169

Si la jonction n’est pas configurée avec –K, GSKit traite une demanded’authentification réciproque en envoyant automatiquement le certificat “pardéfaut” contenu dans la base de données du fichier de clés. S’il ne s’agit pas de laréponse requise, vous devez vous assurer que la base de données du fichier de clés(pdsrv.kdb) ne contient aucun certificat marqué “par défaut” (astérisque).

190 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 211: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Pour résumer :v Identifiez tous les certificats requis par leur nom de libellé.v Ne marquez aucun certificat comme étant “par défaut” dans la base de données

du fichier de clés.v contrôlez la réponse de certificat c″té client WebSEAL avec le paramètre

webseal-cert-keyfile-label.v contrôlez la réponse de certificat c″té client WebSEAL avec l’option de jonction

–K.

Utilisation de query_contents avec des serveurs tiersSi vous voulez protéger les ressources de l’espace Web d’une application tierce àl’aide du service de sécurité Access Manager, vous devez fournir à WebSEAL desinformations sur le contenu de cet espace Web.

Ces informations peuvent être fournies par un programme CGI appeléquery_contents. Le programme query_contents examine le contenu de l’espaceWeb tiers et fournit les informations d’inventaire à Web portal manager surWebSEAL. Fourni avec le programme d’installation de WebSEAL, il doit êtreinstallé manuellement sur le serveur tiers. Différents types de fichiers programmesont disponibles, suivant que le serveur tiers est basé UNIX ou Windows.

Le gestionnaire d’espace objet de Web portal manager exécute automatiquementquery_contents chaque fois qu’une partie de l’espace objet protégé représentant lajonction est développée dans l’écran de gestion de l’espace objet. Une fois que Webportal manager est informé du contenu de l’espace de l’application tiers, vouspouvez afficher ces informations et appliquer des modèles de règles aux objetsappropriés.

Installation des composants query_contentsL’installation de query_contents est en général très facile. Il suffit de copier un oudeux fichiers du serveur Access Manager vers le serveur tiers et de modifier unfichier de configuration.

Le répertoire Access Manager ci-après contient un modèle du programme :

UNIX : <chemin_installation>/www/lib/query_contents

Windows : <chemin_installation>\www\lib\query_contents

Le contenu du répertoire comprend :

Fichier Description

query_contents.exe Principal programme exécutable pour les systèmes Win32.Doit être installé dans le répertoire cgi-bin du serveurWeb tiers.

query_contents.sh Principal programme exécutable pour les systèmes UNIX.Doit être installé dans le répertoire cgi-bin du serveurWeb tiers.

query_contents.c Code source. La source est fournie au cas où vous deviezmodifier le comportement de query_contents. La plupartdes cas, ceci n’est pas nécessaire.

query_contents.html Fichier d’aide au format HTML.

Chapitre 7. Jonctions WebSEAL 191

Page 212: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Fichier Description

query_contents.cfg Exemple de fichier de configuration qui identifie la racinedu document pour le serveur Web.

Installation de query_contents sur des serveurs UNIX tiersLocalisez le script shell query_contents.sh dans le répertoire suivant :<chemin_installation>/www/lib/query_contents

1. Copiez query_contents.sh dans un répertoire actif /cgi-bin du serveur Webtiers.

2. Supprimez l’extension .sh.3. Définissez le bit d’exécution UNIX pour le bit d’exécution du serveur Web.

Installation de query_contents sur des serveurs Win32 tiersOption de jonction spécifique pour Windows :

Lorsque vous installez le programme query_contents sur un serveur d’applicationsWeb Windows relié au réseau par jonction, vous devez utiliser l’option –q aumoment de la création de la jonction pour ce serveur.

En effet, WebSEAL recherche par défaut le programme query_contents dans lerépertoire cgi-bin :/cgi-bin/query_contents

Si vous modifiez le nom du programme query_contents ou encore son répertoire,vous devez utiliser l’option d’emplacement –q <location> lorsque vous créez lajonction. L’argument d’emplacement spécifie le nouvel emplacement et le nouveaunom du programme.

Le nom du programme query_contents utilisé sur la plate-forme Windows estquery_contents.exe. La présence de l’extension .exe change le nom duprogramme. Par conséquent, WebSEAL ne peut pas trouver le nom du programmepar défaut. Vous devez utiliser l’option et l’argument d’emplacement –q<location> pour indiquer à WebSEAL l’emplacement du fichier. Par exemple :create -t tcp -h <nom_hôte>... -q /cgi-bin/query_contents.exe/<nom_jonction>

L’option –q n’est pas obligatoire pour les serveurs UNIX car le nom etl’emplacement du programme query_contents correspondent aux valeurs pardéfaut.

Procédure :

Localisez le programme exécutable query_contents.exe et le fichier deconfiguration query_contents.cfg dans le répertoire suivant :

Windows : <chemin_installation>\www\lib\query_contents

1. Assurez-vous que le serveur Web tiers comporte un répertoire CGIcorrectement configuré.

2. A des fins de test, vérifiez qu’un document valide existe dans le répertoireprincipal des documents du serveur Web tiers.

3. Copiez query_contents.exe dans le répertoire CGI du serveur Web tiers.

192 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 213: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

4. Copiez query_contents.cfg dans le répertoire Windows.Vous trouverez dans le tableau ci-après les valeurs par défautcorrespondantes :

Système d’exploitation Répertoire Windows

Windows 95 et 98 c:\windows

Windows NT 4.x et 2000 c:\winnt

5. Editez le fichier query_contents.cfg pour y spécifier de façon correcte lerépertoire principal des documents du serveur Web tiers.Le fichier contient en général des exemples d’entrées pour le serveur MicrosoftInternet Information Server et les serveurs Netscape FastTrack. Les lignescommençant par un point-virgule sont des commentaires et sont ignorées par leprogramme query_contents.

6. Créez une jonction vers le serveur d’arrière-plan Windows et utilisez l’option–q pour spécifier query_contents.exe comme fichier correct. Par exemple :pdadmin> server taskwebseald-<nom_instance> create -t tcp-h <nom_hôte> ... \-q /cgi-bin/query_contents.exe/<nom_jonction>

Test de la configuration1. A partir d’une invite MS-DOS sur la machine Win32, exécutez le programme

query_contents depuis le répertoire CGI comme suit :MSDOS> query_contents dirlist=/

Une sortie semblable à la suivante doit s’afficher :100index.htmlcgi-bin//pics//

Le nombre 100 est un code d’état qui indique le succès. Il est très important devoir au moins le nombre 100 comme première (et quelquefois seule) valeur.

Si un code d’erreur s’affiche à la place, le fichier de configuration n’est pas bienplacé ou ne contient pas une entrée de répertoire principal des documentsvalide. Vérifiez la configuration du fichier query_contents.cfg et assurez-vousde l’existence du répertoire principal des documents.

2. A partir du navigateur, entrez l’URL suivantehttp://<nom_machine_win32>/cgi-bin/query_contents.exe?dirlist=/

Vous devez obtenir le même résultat que lors de l’étape précédente. Si lerésultat diffère, la configuration CGI de votre serveur Web est incorrecte. Pourremédier à cet incident, reportez-vous à la documentation relative à votreserveur.

Chapitre 7. Jonctions WebSEAL 193

Page 214: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Personnalisation de query_contentsLe but de query_contents est de renvoyer le contenu des répertoires inclus dansune requête URL.

Par exemple, pour obtenir le contenu du répertoire racine d’un espace Web duserveur, le navigateur exécute query_contents au niveau d’une adresse URL dutype :http://serveur_tiers/cgi-bin/query_contents?dirlist=/

Le script query_contents exécute les actions suivantes :1. Il lit $SERVER_SOFTWARE, variable d’environnement CGI standard, pour

déterminer le type de serveur.Basée sur le type de serveur Web, la variable $DOCROOTDIR est définie surun emplacement racine de document classique.

2. Il lit la variable d’environnement $QUERY_STRING à partir de l’adresse URLdemandée pour obtenir l’opération demandée et obtenir le chemin d’objet.La valeur de l’opération est enregistrée dans la variable $OPERATION, et lechemin d’objet dans $OBJPATH. Dans l’exemple précédent, la variable$OPERATION a la valeur dirlist, et $OBJPATH a la valeur “/”.

3. Affiche la liste des répertoires (ls) du chemin d’objet et place le résultat dans lasortie standard, à destination du serveur Access Manager. Les entrées quiindiquent des sous-répertoires comportent une double barre oblique(//).Une sortie ressemble généralement à ceci :100index.htmlcgi-bin//pics//

Le nombre 100 est un code d’état qui indique le succès.

Personnalisation du répertoire principal de documentsUNIX :

Pour personnaliser query_contents.sh pour votre serveur UNIX, vous devezmodifier le paramètre de répertoire principal des documents.

Si query_contents renvoie un état d’erreur (un nombre différent de 100) etn’affiche aucun fichier, examinez le script et modifiez la variable $DOCROOTDIR,si nécessaire, pour la faire correspondre à la configuration de votre serveur.

Si le répertoire principal des documents est spécifié correctement et que le scriptéchoue encore, il est possible que la spécification de l’emplacement cgi-bin soitincorrecte. Examinez la variable $FULLOBJPATH et modifiez la valeur qui lui estaffectée pour qu’elle reflète l’emplacement cgi-bin qui convient.

Windows :

Pour personnaliser query_contents.exe pour votre serveur Windows, modifiez lefichier query_contents.cfg.

194 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 215: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Fonctionnalités supplémentairesLe code source du programme query_contents (query_contents.c) est distribuégratuitement avec Access Manager.

Il est possible d’ajouter des fonctionnalités supplémentaires à ce programme pourassurer la prise en charge de fonctions spéciales de serveurs Web tiers. Cesfonctions peuvent être :1. Mappage de répertoires — un sous-répertoire ne se trouvant pas en aval du

répertoire principal des documents est mappé dans l’espace Web.2. Génération d’un espace Web non basé sur un système de fichiers.

Il peut s’agir par exemple d’un serveur Web hébergé sur une base de données.

Sécurisation de query_contentsAccess Manager utilise le programme CGI query_contents pour afficher lesespaces objet des serveurs Web reliés par jonction dans Web portal manager. Il esttrès important de sécuriser ce fichier pour empêcher des utilisateurs nonauthentifiés de l’exécuter.

Vous devez définir une règle de sécurité permettant uniquement à l’identité(pdmgrd) de policy server d’accéder au programme query_contents. L’exemple deLCA suivant (query_contents_acl) répond à ce critère :group ivmgrd-servers Tl

user sec_master dbxTrlcam

Utilisez l’utilitaire pdadmin pour associer cette LCA à l’objet query_contents.sh(UNIX) ou query_contents.exe (Windows) sur les serveurs reliés par jonction. Parexemple (UNIX) :pdadmin> acl attach/WebSEAL/<hôte>/<nom_jonction>/query_contents.sh\query_contents_acl

Chapitre 7. Jonctions WebSEAL 195

Page 216: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

196 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 217: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Chapitre 8. Solutions de connexion unique Web

Lorsque WebSEAL est mis en oeuvre en tant que serveur proxy pour protéger undomaine sécurisé, il est souvent nécessaire de fournir des solutions à connexionunique (SSO, Single Sign On) aux ressources Web. Ce chapitre traite des solutionsSSO pour l’espace Web d’une configuration proxy WebSEAL. Ces solutions sont,par exemple, des jonctions configurées d’une manière particulière, des connexionsglobales (GSO, Global Sign-On) et LTPA.

Index des rubriques :v «Configuration d’en-têtes BA pour des solutions SSO» à la page 197v «Utilisation d’une connexion globale (GSO)» à la page 201v «Configuration d’une connexion unique à IBM WebSphere (LTPA)» à la page 205v «Configuration d’une authentification à base de formulaires (connexion unique)»

à la page 207

Configuration d’en-têtes BA pour des solutions SSOCette section présente les solutions possibles pour créer des configurations SSO viades jonctions WebSEAL à l’aide des options –b.v «Concepts de connexion unique (Single sign-on - SSO)» à la page 197v «Spécification de l’identité client dans les en-têtes BA» à la page 198v «Spécification de l’identité client et du mot de passe générique» à la page 198v «Transmission des informations d’en-tête BA du client» à la page 200v «Suppression des informations d’en-tête BA client» à la page 200v «Spécification de noms d’utilisateur et de mots de passe à partir de GSO» à la

page 201

Concepts de connexion unique (Single sign-on - SSO)Lorsqu’une ressource protégée se trouve sur un serveur d’applications Webd’arrière-plan, un client effectuant une requête au niveau de cette ressource peutêtre obligé de se soumettre à plusieurs connexions : une pour le serveur WebSEALet une autre pour le serveur d’arrière-plan. Chaque connexion requiertvraisemblablement différentes identités de connexion.

Client WebSEALServeur

d’applicationsWeb

Jonction

Connexion n° 1 Connexion n° 2

Figure 38. Connexions multiples

© Copyright IBM Corp. 1999, 2002 197

Page 218: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Un mécanisme de connexion unique (SSO) permet le plus souvent de résoudrecette question d’administration et de gestion de plusieurs identités de connexion.Une solution SSO permet en effet à un utilisateur d’accéder à une ressource, queque soit l’emplacement de cette dernière, uniquement à partir de sa connexioninitiale. Toute autre exigence de connexion provenant des serveurs d’arrière-planest traitée de façon transparente pour l’utilisateur.

Spécification de l’identité client dans les en-têtes BAVous pouvez configurer les jonctions WebSEAL de sorte qu’elles fournissent auserveur d’arrière-plan des informations d’identité client originales ou modifiées.Vous pouvez fournir, grâce à l’ensemble des options –b, des informations d’identitéclient spécifiques dans les en-têtes HTTP d’authentification de base (BA).

En tant qu’administrateur, vous devez analyser l’architecture du réseau et lesexigences en matière de sécurité, puis répondre aux questions suivantes :1. Les informations d’authentification sont-elles nécessaires au serveur

d’arrière-plan ?(WebSEAL utilise l’en-tête HTTP d’authentification de base pour transmettredes informations d’authentification.)

2. Si ces informations d’authentification sont requises par le serveurd’arrière-plan, d’où proviennent-elles ?(Quelles sont les informations placées par WebSEAL dans l’en-tête HTTP ?)

3. La connexion entre WebSEAL et le serveur d’arrière-plan doit-elle êtresécurisée ?(Jonction TCP ou SSL ?)

Après l’authentification initiale entre le client et WebSEAL, WebSEAL peutconstituer un nouvel en-tête d’authentification de base. La requête utilise ce dernierlorsqu’elle joint le serveur d’arrière-plan par le biais de la jonction. Vous spécifiezles options –b pour indiquer les informations d’authentification spécifiquesfournies dans ce nouvel en-tête.

Spécification de l’identité client et du mot de passe générique–b supply

L’option –b supply demande à WebSEAL d’indiquer le nom d’utilisateur AccessManager authentifié (identité existante du client) avec un mot de passe statique etgénérique (“fictif”). Le mot de passe client existant n’est pas utilisé dans ce type descénario.

Client WebSEALServeur

d’applicationsWeb

Nouvel en-tête BAavec informationsd’authentification

fournies par WebSEAL

Premiers résultats d’authentificationdans données d’autorisation

Policy Director

jonction

requête requête

Figure 39. Transmission des informations d’authentification aux serveurs d’arrière-plan

198 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 219: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Un mot de passe générique supprime l’administration de mot de passe et prend encharge l’application utilisateur par utilisateur. Le mot de passe “fictif” est définipar le paramètre basicauth-dummy-passwd du fichier de configurationwebseald.conf :[junction]basicauth-dummy-passwd = <mot_de_passe>

Ce scénario imagine que le serveur d’arrière-plan requiert une authentification dela part d’une identité Access Manager. En mappant un utilisateur client à unutilisateur Access Manager connu, WebSEAL gère l’authentification pour le serveurd’arrière-plan et fournit une solution simple SSO à l’échelle du domaine.

Les conditions suivantes s’appliquent à cette solution :v WebSEAL est configuré pour pouvoir fournir au serveur d’arrière-plan le nom

d’utilisateur contenu dans la requête client originale ainsi qu’un mot de passegénérique (“fictif”).

v Le mot de passe “fictif” est configuré dans le fichier de configurationwebseald.conf.

v Le registre du serveur d’arrière-plan doit reconnaître l’identité Access Managerfournie dans l’en-tête HTTP BA.

v Comme les informations d’authentification confidentielles (nom d’utilisateur etmot de passe) sont transmises au niveau de la jonction, la sécurité de celle-ci estcapitale. Une jonction SSL est donc vivement recommandée.

LimitesLe même mot de passe “fictif” Access Manager sert à toutes les requêtes ; tous lesutilisateurs ont le même mot de passe dans le registre du serveur d’arrière-plan.L’utilisation d’un mot de passe “fictif” commun ne permet donc pas au serveurd’applications de légitimer la connexion d’un client avec ce nom d’utilisateur.

Si les clients passent systématiquement par WebSEAL pour accéder au serveurd’arrière-plan, cette solution ne présente aucun problème de sécurité. Il esttoutefois important de protéger physiquement le serveur d’arrière-plan des autresmoyens d’accès possibles.

Comme ce scénario ne comporte pas de sécurité au niveau du mot de passe, leserveur d’arrière-plan doit implicitement faire confiance à WebSEAL pour lavérification de la légitimité du client.

Client WebSEALjonction SSL Serveur

d’applicationsWeb

WebSEAL fournit l’identitéet le mot de passe

« fictif » Policy Director

touteméthode

d’authentification

Registre Registre

Figure 40. L’en-tête BA contient l’identité et le mot de passe fictif.

Chapitre 8. Solutions de connexion unique Web 199

Page 220: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Le registre du serveur d’arrière-plan doit également reconnaître l’identité AccessManager pour pouvoir l’accepter.

Transmission des informations d’en-tête BA du client–b ignore

L’option –b ignore demande à WebSEAL de transmettre directement l’en-tête BAde client existant au serveur d’arrière-plan, sans interférence. WebSEAL peut êtreconfiguré pour authentifier ces informations, ou pour ignorer l’en-tête BA fourniepar le client, et l’acheminer au serveur d’arrière-plan sans y apporter demodifications.

Remarque : Il ne s’agit pas à proprement parler d’un mécanisme SSO, mais plutôtd’une connexion directe au serveur tiers, de façon transparente pourWebSEAL.

Les conditions suivantes s’appliquent à cette solution :v Le serveur d’arrière-plan a besoin que les informations d’identité client lui soient

fournies par l’authentification de baseLe serveur d’arrière-plan renvoie une demande d’authentification de base (BA)au client. Le client répond, en indiquant des informations de nom d’utilisateur etde mot de passe, que le serveur WebSEAL transmet sans modifications.

v Le serveur d’arrière-plan gère ses propres mots de passe fournis par le clientv WebSEAL est configuré pour pouvoir fournir au serveur d’arrière-plan le nom

d’utilisateur et le mot de passe contenus dans la requête client originale.v Comme les informations d’authentification confidentielles (nom d’utilisateur et

mot de passe) sont transmises au niveau de la jonction, la sécurité de celle-ci estcapitale. Une jonction SSL est donc vivement recommandée.

Suppression des informations d’en-tête BA client–b filter

L’option –b filter demande à WebSEAL de supprimer toutes les informationsd’en-tête BA des requêtes client avant de transmettre ces dernières au serveurd’arrière-plan. Dans ce scénario, WebSEAL devient le seul fournisseur de sécurité.

Client WebSEALjonction

Serveurd’applications

Web

WebSEAL fournit lesinformations d’authentification

client (BA) d’origine

Authentificationde base

Registre Registre

Figure 41. WebSEAL transmet les informations d’identité sur le client d’origine

200 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 221: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Les conditions suivantes s’appliquent à cette solution :v L’authentification de base est configurée entre le client et WebSEALv Le serveur d’arrière-plan ne requiert pas d’authentification de basev Le serveur d’arrière-plan est seulement accessible via WebSEALv WebSEAL gère l’authentification pour le compte du serveur d’arrière-plan

Si vous devez fournir au serveur d’arrière-plan certaines informations relatives auclient, vous pouvez combiner cette option avec l’option –c pour introduire desinformations d’identité client Access Manager dans les champs d’en-tête HTTP.Voir la section «Spécification de l’identité du client dans les en-têtes HTTP (–c)» àla page 182.

Spécification de noms d’utilisateur et de mots de passe àpartir de GSO

–b gso

L’option –b gso demande à WebSEAL de fournir au serveur d’arrière-plan lesinformations d’authentification (nom d’utilisateur et mot de passe) reçues d’unserveur configuré pour gérer une connexion GSO (global sign-on), ou connexionglobale.

Les conditions suivantes s’appliquent à cette solution :v Les applications du serveur d’arrière-plan exigent différents noms d’utilisateur et

mots de passe non contenus dans le registre WebSEAL.v La sécurité est importante pour WebSEAL comme pour le serveur d’arrière-plan.

Comme les informations d’authentification confidentielles (nom d’utilisateur et motde passe) sont transmises au niveau de la jonction, la sécurité de celle-ci estcapitale. Une jonction SSL est donc vivement recommandée.

Ce mécanisme est décrit de façon exhaustive dans la section «Utilisation d’uneconnexion globale (GSO)».

Utilisation d’une connexion globale (GSO)Access Manager permet, à partir d’une seule connexion, de fournir d’autres nomsd’utilisateur et mots de passe au serveur d’applications Web d’arrière-plan.

La fonction GSO permet aux utilisateurs d’accéder aux ressources informatiquesqu’ils sont autorisés à utiliser, par une simple connexion. Conçu pour les grandesentreprises constituées de plusieurs systèmes et applications au sein

Client WebSEALServeurd’applicationsWeb

jonction TCPou SSL

Authentificationde base

aucune authentificationrequise

WebSEAL supprime les informationsd’origine sur l’identité du client

de l’en-tête BA

Figure 42. Suppression des informations d’en-tête BA client

Chapitre 8. Solutions de connexion unique Web 201

Page 222: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

d’environnements hétérogènes et informatiques distribués, GSO élimine le besoindes utilisateurs finaux de gérer plusieurs noms d’utilisateur et mots de passe.

Cette intégration s’effectue par le biais de la création de jonctions “détectant GSO”entre WebSEAL et les serveurs Web d’arrière-plan. Les ressources et groupes deressources GSO doivent être préalablement créés avec le composant Web PortalManager.

Lorsque WebSEAL reçoit une requête portant sur une ressource située sur leserveur relié par jonction, il demande au serveur de registre d’utilisateurs lesinformations d’authentification appropriées. Ce serveur contient la base de donnéesdes mappages (pour chaque utilisateur inscrit) qui fournit d’autres nomsd’utilisateur et mots de passe en fonction des ressources et applications spécifiques.

La figure suivante illustre la façon dont le mécanisme GSO permet d’extraire desnoms d’utilisateur et des mots de passe pour les ressources de l’applicationd’arrière-plan.1. Le client s’authentifie auprès de WebSEAL avec une requête d’accès à une

ressource d’application sur un serveur d’arrière-plan. Une identité AccessManager est obtenue.

Remarque : Le processus de connexion unique est indépendant de la méthoded’authentification initiale.

2. WebSEAL transmet l’identité Access Manager au serveur de registred’utilisateurs.

3. Le registre renvoie un nom d’utilisateur et un mot de passe adéquats pourl’utilisateur et la ressource d’application demandée.

4. WebSEAL insère les informations de nom d’utilisateur et de mot de passe dansl’en-tête HTTP d’authentification de base de la requête qui est envoyée auserveur d’arrière-plan par la jonction.

Jonctions (-b gso)

WebSEAL

Client

Domaine sécurisé

Resources:- accounts-app- travel-app

HTTPSRessources:- expenses-app- payroll-app

HTTP

Hôte : sales_svr

Hôte : adm_svr

La jonction SSL fournit descommunications chiffrées

/

/sales

/admin

1

2

3

4

Serveur LDAPou GSO

/sales

/admin

Identité PolicyDirector

Nom d’utilisateur/mot de passe

Figure 43. Mécanisme de connexion globale

202 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 223: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Mappage des informations d’authentificationL’exemple suivant illustre la façon dont le registre d’utilisateurs fournit desinformations d’authentification à WebSEAL. Si l’utilisateur Michael veut exécuter laressource d’application travel-app (voir la figure 43 à la page 202), WebSEALdemande au serveur de registre d’utilisateurs / LDAP les informationsd’authentification de Michael.

Le serveur de registre d’utilisateurs / LDAP gère une base de donnéesd’authentification complète sous la forme de mappages de ressources avec desinformations d’authentification spécifiques. Les informations d’authentification sontconstituées d’une combinaison nom d’utilisateur / mot de passe, connues sous lenom de données d’autorisation. Les données d’autorisation d’une ressource nepeuvent être créées que pour des utilisateurs inscrits.

Le registre contient une base de données pour Michael qui fait correspondre laressource : travel-app à des données d’autorisation spécifiques pour la ressource.

Le tableau ci-après illustre la structure de la base des données d’autorisation de laressource GSO :

Michael Paul

resource: travel-appusername=mikepassword=123

resource: travel-appusername=bundypassword=abc

resource: payroll-appusername=powellpassword=456

resource: payroll-appusername=jensenpassword=xyz

Dans cet exemple, le registre renvoie le nom d’utilisateur “mike” et le mot depasse “123” à WebSEAL. WebSEAL se sert de ces informations lorsqu’il définitl’en-tête d’authentification de base dans la requête envoyée par la jonction auserveur d’arrière-plan.

Configuration d’une jonction WebSEAL activée GSOLa prise en charge de GSO est configurée au niveau de la jonction entre WebSEALet un serveur d’arrière-plan.

Pour créer une jonction activant GSO, entrez la commande create avec l’option –bgso. L’exemple suivant présente la syntaxe de la commande create :create –t tcp –h <nom_hôte> –b gso–T <ressource><point_jonction>

La liste des options de configuration des jonctions GSO est présentée ci-après :

Options Description

–b gso Indique que GSO doit fournir les informationsd’authentification pour toutes les requêtes passant parcette jonction.

–T <resource/resource-group> Indique la ressource ou le groupe de ressources GSO.Le nom de ressource utilisé comme argument de cetteoption doit exactement correspondre au nom deressource répertorié dans la base de données GSO.Obligatoire pour les jonctions gso.

Chapitre 8. Solutions de connexion unique Web 203

Page 224: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Une jonction utilisée dans une solution WebSEAL/GSO peut être sécurisée aumoyen du protocole SSL si l’option –t ssl est rajoutée au moment de la création dela jonction.

L’usage de jonctions SSL est systématiquement recommandé avec GSO pourgarantir le chiffrement de toutes les données, et notamment les donnéesd’autorisation.

Exemples de jonctions activées GSOJonction de la ressource d’application : travel-app sur l’hôte : sales_svr au pointde jonction /sales :create –t tcp –b gso –T travel-app –h sales_svr /sales

Jonction de la ressource d’application : payroll-app sur l’hôte : adm_svr au pointde jonction /admin et protection de la jonction avec SSL :create –t ssl –b gso –T payroll-app –h adm_svr /admin

Remarque : Dans l’exemple précédent, l’option –t ssl indique le port par défaut443.

Configuration du cache GSOLa fonctionnalité de mémoire cache GSO (Global Sign-on) permet d’optimiser lesperformances des jonctions GSO dans un environnement à forte charge. Par défaut,la mémoire cache GSO est désactivée. Sans optimisation de la mémoire cache, unappel au serveur de registre d’utilisateur est requis pour chaque extraction desinformations sur les destinataires GSO (nom d’utilisateur et mot de passe GSO).

Les paramètres de configuration de la mémoire cache GSO se trouvent dans lastrophe [gso-cache] du fichier de configuration webseald.conf. Vous devez toutd’abord activer la mémoire cache. Les autres paramètres configurent la taille de lamémoire cache ainsi que les valeurs de délai d’expiration pour les entrées demémoire cache. Plus les valeurs de la durée de vie et du délai d’inactivité sontélevées, plus les performances sont optimisées, mais plus les informations résidantdans la mémoire WebSEAL sont exposées. N’activez pas la mémoire cache GSO siles jonctions GSO ne sont pas utilisées dans votre solution de réseau.

Paramètre Description

gso-cache-enabled Active ou désactive la fonctionnalité de lamémoire cache GSO. Les valeurs sont “yes” et“no”. La valeur par défaut est “no”.

gso-cache-size Définit le nombre maximum d’entrées autoriséesdans la table de hachage de la mémoire cache.Affectez à ce paramètre une valeur proche dunombre maximal de sessions utilisateurconcurrentes ayant accès à une application viaune jonction GSO. Plus la valeur est élevée, plusla quantité de mémoire utilisée est importantemais plus l’accès aux informations est rapide.Chaque entrée de la mémoire cache occupeenviron 50 octets.

204 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 225: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Paramètre Description

gso-cache-entry-lifetime Durée maximale (en secondes) de stockage d’uneentrée dans la mémoire cache, quelle que soitl’activité. Lorsqu’une entrée de la mémoire cachearrive à expiration, la requête suivante de cemême utilisateur nécessite un nouvel appel auserveur de registre d’utilisateurs.

gso-cache-entry-idle-timeout Durée maximale (en secondes) de stockage d’uneentrée inactive dans la mémoire cache.

Configuration d’une connexion unique à IBM WebSphere (LTPA)WebSEAL peut fournir des services d’autorisation et d’authentification ainsi qu’uneprotection à un environnement IBM WebSphere. Lorsque WebSEAL est positionnécomme serveur frontal protégeant WebSphere, deux points d’accès possibles seprésentent aux clients. WebSEAL prend donc en charge une solution SSO à un ouplusieurs serveurs IBM WebSphere via des jonctions WebSEAL.

WebSphere fournit une méthode d’authentification LTPA (Lightweight Third PartyAuthentication) basée sur les cookies. Vous pouvez configurer les jonctionsWebSEAL de façon à prendre en charge LTPA et à fournir une solution SSO auxclients.

Lorsqu’un utilisateur demande une ressource WebSphere, il doit tout d’abords’authentifier auprès de WebSEAL. Une fois l’authentification terminée, WebSEALgénère un cookie LTPA pour le compte de l’utilisateur. Le cookie LTPA, qui sert dejeton d’authentification pour WebSphere, contient des informations sur l’identité etle mot de passe de l’utilisateur, ainsi que les données de clé et de jeton, lalongueur de la mémoire tampon et les données d’expiration. Ces informations sontchiffrées à l’aide d’une clé secrète protégée par un mot de passe et partagée entreWebSEAL et le serveur WebSphere.

WebSEAL insère le cookie dans l’en-tête HTTP de la requête qui est envoyée àWebSphere via la jonction. Le serveur d’arrière-plan WebSphere la reçoit, déchiffrele cookie et authentifie l’utilisateur d’après les informations d’identité contenuesdans le cookie.

Pour optimiser les performances, WebSEAL peut stocker le cookie LTPA dans unemémoire cache de façon à pouvoir le réutiliser pour les requêtes suivantes de lamême session utilisateur. Vous pouvez configurer les valeurs de la durée de vie etdu délai d’inactivité du cookie mis en mémoire cache.

Configuration d’une jonction LTPAUne connexion unique à WebSphere via un cookie LTPA nécessite les étapes deconfiguration suivantes :1. Activez le mécanisme LTPA.2. Indiquez l’emplacement du fichier de clés utilisé pour chiffrer les informations

d’identité.3. Indiquez le mot de passe de ce fichier de clés.

Ces trois conditions de configuration sont définies par trois autres options de lacommande create.v L’option –A active les cookies LTPA.

Chapitre 8. Solutions de connexion unique Web 205

Page 226: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

v L’option –F <“fichier_clés”> et l’argument définissent le nom de chemin complet(sur le serveur WebSEAL) du fichier de clés utilisé pour chiffrer les informationsd’identité contenues dans le cookie. La clé partagée est initialement créée sur leserveur WebSphere et copiée en toute sécurité sur le serveur WebSEAL. Pourplus d’informations sur cette tâche, reportez-vous à la documentationWebSphere qui convient.

v L’option –Z <“mot_de_passe_fichier_clés”> définit le mot de passe requis pourouvrir le fichier de clés.Le mot de passe apparaît sous la forme d’un texte chiffré dans le fichier XML dela jonction.

Lorsque vous créez la jonction entre WebSEAL et le serveur d’arrière-planWebSphere, utilisez ces options avec les autres options de jonction requises. Parexemple :create ... -A -F “/abc/xyz/key.file” -Z “abcdefg” ...

Configuration du cache LTPALa création, le chiffrement et le déchiffrement des cookies LTPA entraînent unesurcharge de traitement. La fonctionnalité de mémoire cache LTPA permetd’optimiser les performances des jonctions LTPA dans un environnement à fortecharge. Sans l’optimisation de la mémoire cache, un nouveau cookie LTPA est crééet chiffré pour chaque nouvelle requête de l’utilisateur. Par défaut, la mémoirecache LTPA est activée.

Les paramètres de configuration de la mémoire cache LTPA se trouvent dans lastrophe [ltpa-cache] du fichier de configuration webseald.conf. Les paramètresdéfinissent la taille de la mémoire cache et les valeurs de délai d’expiration pourles entrées de la mémoire cache. Plus les valeurs de la durée de vie et du délaid’inactivité sont élevées, plus les performances sont optimisées, mais plus lesinformations contenues dans la mémoire de WebSEAL sont exposées.

Paramètre Description

ltpa-cache-enabled Active et désactive la fonctionnalité de lamémoire cache LTPA. Les valeurs sont “yes” et“no”. La valeur par défaut est “yes”.

ltpa-cache-size Définit le nombre maximum d’entrées autoriséesdans la table de hachage de la mémoire cache.Affectez à ce paramètre une valeur proche dunombre maximal de sessions utilisateurconcurrentes ayant accès à une application viaune jonction LTPA. Plus la valeur est élevée, plusla quantité de mémoire utilisée est importantemais plus l’accès aux informations est rapide.Chaque entrée de la mémoire cache occupeenviron 50 octets. La valeur par défaut est4096 entrées.

ltpa-cache-entry-lifetime Durée maximale (en secondes) de stockage d’uneentrée dans la mémoire cache, quelle que soitl’activité. Lorsqu’une entrée de la mémoire cachearrive à expiration, la requête suivante de cemême utilisateur nécessite la création d’unnouveau cookie LTPA. La valeur par défaut est3600 secondes.

206 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 227: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Paramètre Description

ltpa-cache-entry-idle-timeout Durée maximale (en secondes) de stockage d’uneentrée inactive dans la mémoire cache. La valeurpar défaut est 600 secondes.

Remarques techniques sur les connexions uniquesv Le fichier de clés contient des informations sur un serveur WebSphere

spécifique. Une jonction LTPA est propre à un serveur WebSphere. Si vousajoutez plusieurs serveurs au même point de jonction, ils partageront tous lemême fichier de clés.

v Pour que les connexions uniques aboutissent, WebSEAL et le serveur WebSpheredoivent, dans une certaine mesure, partager les mêmes informations de registre.

v Le serveur WebSphere prend en charge la configuration de LTPA ainsi que lacréation de la clé secrète partagée. En revanche, WebSEAL permet de configurerles jonctions et la mémoire cache.

Configuration d’une authentification à base de formulaires (connexionunique)

L’authentification à base de formulaires (connexion unique) permet à WebSEAL deconnecter de façon transparente un utilisateur Access Manager authentifié à unserveur d’applications relié au réseau par jonction et nécessitant uneauthentification via un formulaire HTML.

Présentation et objectifsL’authentification à base de formulaires (connexion unique) prend en charge lesapplications existantes qui utilisent des formulaires HTML pour l’authentificationet qui ne peuvent pas être modifiées pour habiliter directement l’authentificationeffectuée par WebSEAL. L’activation de l’authentification à base de formulaires(connexion unique) permet d’obtenir les résultats suivants :v WebSEAL interrompt le processus d’authentification initialisé par l’application

d’arrière-planv WebSEAL spécifie les données requises par le formulaire de connexion et soumet

ce dernier au nom de l’utilisateur.v WebSEAL enregistre et restaure tous les cookies et toutes les en-têtesv L’utilisateur ne sait pas qu’une deuxième connexion est en cours

d’établissement.v L’application d’arrière-plan n’a pas l’information selon laquelle le formulaire de

connexion ne provient pas directement de l’utilisateur.

WebSEAL doit être configuré pour effectuer les opérations suivantes :v Reconnaissance et interception du formulaire de connexionv Transmission des données d’authentification appropriées

L’administrateur active la connexion unique à base de formulaires de l’une desfaçons suivantes :v Création d’un fichier de configuration afin de spécifier le mode de

reconnaissance, de remplissage et de traitement du formulaire de connexion

Chapitre 8. Solutions de connexion unique Web 207

Page 228: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

v Activation de la connexion unique à base de formulaires via la configuration dela jonction appropriée à l’aide de l’option –S (qui spécifie l’emplacement dufichier de configuration)

Processus de la connexion unique à base de formulairesLe scénario suivant suppose que WebSEAL a déjà authentifié l’utilisateur.

1. Le navigateur client nécessite la page suivante :https://webseal/formsso/content.html

2. WebSEAL transmet la requête à la jonction.3. Etant donné que l’application d’arrière-plan nécessite l’authentification de

l’utilisateur, un réacheminement vers la page de connexion de l’application(login.html) est effectué via la jonction.

4. WebSEAL transmet ce réacheminement au navigateur.5. Le navigateur suit le réacheminement et effectue la demande suivante :

https://webseal/formsso/login.html

Remarque : Jusqu’à ce point du processus, les fonctions sont des fonctionsstandard WebSEAL.

6. WebSEAL a été configuré pour les connexions uniques à base de formulaires(option –S pour la jonction). WebSEAL reconnaît la requête comme étant unerequête de page de connexion, sur la base des informations contenues dans lesformulaires du fichier de configuration SSO. La requête est transmise à lajonction. WebSEAL enregistre tous les cookies envoyés par le navigateur afinde les utiliser à l’étape 8.

Figure 44. Processus de connexion unique à base de formulaires

208 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 229: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

7. L’application renvoie la page de connexion et, éventuellement, les cookiesspécifiques aux applications.WebSEAL analyse la page HTML renvoyée afin d’identifier le formulaire deconnexion. Lorsque WebSEAL trouve un formulaire HTML dans le document,il compare l’URI d’action du formulaire à la valeur affectée au paramètrelogin-form-action dans le fichier de configuration personnalisé. Si ces deuxéléments correspondent, WebSEAL utilise le formulaire qu’il a trouvé. Dans lecas contraire, il poursuit sa recherche de formulaires. Si aucun formulaire dela page ne correspond au modèle d’URI d’action figurant dans le fichier deconfiguration, WebSEAL abandonne le traitement de la connexion unique àbase de formulaires et affiche un message d’erreur dans le navigateur.WebSEAL analyse la page HTML afin d’identifier la méthode de requête,l’URI d’action et toute autre zone d’entrée du formulaire, puis les enregistrepour pouvoir les utiliser à l’étape 8.

8. WebSEAL génère la requête d’authentification (remplit le formulaire deconnexion), puis l’envoie à l’application d’arrière-plan.

9. L’application effectue l’authentification à l’aide des données d’authentificationfournies par WebSEAL dans le formulaire. L’application renvoie unréacheminement au fichier content.html.

10. WebSEAL associe les cookies enregistrés à partir des réponses figurant auxétapes 7 et 9, puis renvoie au navigateur ces cookies avec le réacheminement.

Remarque : La fonction spécifique SSO est terminée.11. Le navigateur suit le réacheminement et effectue la demande suivante :

https://webseal/formsso/content.html

12. WebSEAL transmet la requête à l’application d’arrière-plan via la jonction.

Pendant ce processus, le navigateur envoie trois requêtes à WebSEAL. Du point devue de l’utilisateur, seule une requête pour https://webseal/formsso/content.htmlest envoyée. Les autres requêtes sont créées automatiquement via lesacheminements HTTP.

Conditions requises pour le support d’applicationsLa connexion unique pour l’authentification à base de formulaires est prise encharge par les applications qui remplissent les conditions suivantes :1. Les pages de connexion de l’application doivent être identifiables de façon

unique via une ou plusieurs expresssions régulières.2. La page de connexion peut inclure plusieurs formulaires HTML. Toutefois, le

formulaire de connexion doit être identifié grâce à l’application d’uneexpression régulière aux URI d’action de chaque formulaire de connexion, ouencore le formulaire de connexion doit être le premier de la page de connexion.Il est à noter que lors de l’utilisation de l’attribut “action” pour identifier leformulaire de connexion, l’attribut “action” n’a pas franchi le filtrage HTML deWebSEAL. L’expression régulière doit correspondre à l’URI d’action afin depouvoir être filtrée.

3. Vous pouvez utiliser des scripts client pour valider les données d’entrée, maiscela ne doit pas modifier ces données d’entrée. Cela implique l’utilisation deJavascript pour la définition de cookies dans le navigateur de l’utilisateur.

4. Les données de connexion sont soumises à un seul point du processusd’authentification.

5. La jonction vers laquelle la requête d’authentification est acheminée doit être lamême que celle à laquelle la page de connexion est renvoyée.

Chapitre 8. Solutions de connexion unique Web 209

Page 230: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Création du fichier de configuration pour les connexionsuniques à base de formulaires

Le fichier de configuration pour les connexions uniques à base de formulaires estcréé de façon personnalisée par l’administrateur, puis enregistré à l’emplacementsouhaité. L’option –S de la jonction active la fonction de connexion unique à basede formulaires et spécifie l’emplacement du fichier de configuration. Reportez-vousà la section «Activation de la connexion unique à base de formulaires» à la page214. Un exemple de fichier de configuration (contenant les instructionscommentées) est fourni avec WebSEAL et se trouve dans le répertoire suivant :

UNIX :/opt/pdweb/etc/fsso.conf.template

Windows :C:\Program Files\Tivoli\PDWeb\etc\fsso.conf.template

Le fichier de configuration doit commencer par la strophe [forms-sso-login-pages]et est au format suivant[forms-sso-login-pages]login-page-stanza = <xxxxx>#login-page-stanza = <aaaaa>#login-page-stanza = <bbbbb>

[<xxxxx>]login-page = <correspondance_page_expression_régulière>login-form-action = <correspondance_page_expression_régulière>gso-resource = <cible_gso>argument-stanza = <yyyyy>

[<yyyyy>]<nom> =<méthode>:<valeur>

Strophe [forms-sso-login-pages]Le fichier de configuration des connexions uniques à base de formulairescommencent par la strophe [forms-sso-login-pages]. Cette strophe contient une ouplusieurs entrées login-page-stanza qui désignent d’autres strophes personnaliséescontenant des informations de configuration destinées aux pages de connexionlocalisées sur le serveur d’applications d’arrière-plan.

La capacité à prendre en charge plusieurs pages de connexion sur une mêmejonction est importante, car un même serveur d’arrière-plan peut hébergerplusieurs applications qui utilisent chacune une méthode d’authentificationdifférente.

Par exemple :[forms-sso-login-pages]login-page-stanza = loginpage1login-page-stanza = loginpage2

210 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 231: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Strophe de page de connexion personnaliséeChaque strophe de page de connexion personnalisée est utilisée pour l’interceptiond’un modèle d’URL spécifique. Cette strophe peut contenir les paramètressuivants :

Paramètre Description

login-page Ce paramètre spécifie (à l’aide d’une expression régulière) unmodèle qui identifie de façon unique des requêtes relatives à lapage de connexion d’une application. WebSEAL intercepte cespages et démarre le processus de connexion unique à base deformulaires. L’expression régulière est comparée à l’URI de requêteet est relative au point de jonction sur lequel le serveur est monté.

login-form-action Ce paramètre spécifie (à l’aide d’une expression régulière) unmodèle qui identifie le formulaire de la page interceptécorrespondant au formulaire de connexion de l’application. S’ilexiste un seul formulaire dans la page (ou si le formulaire deconnexion est le premier du document), l’expression peut être lasuivante : “*”. Dans le cas contraire, l’expression régulière doitcorrespondre à l’attribut “action” du formulaire de connexion.

gso-resource Ce paramètre spécifie la ressource GSO à utiliser pour l’extractiondu nom d’utilisateur et du mot de passe GSO à partir d’une basede données GSO. N’affectez aucune valeur à ce paramètre si GSOn’est pas utilisé pour le stockage d’un nom d’utilisateur et d’unmot de passe GSO.

argument-stanza Ce paramètre désigne une autre strophe personnalisée quirépertorie les zones et les données obligatoires pour le remplissagedu formulaire de connexion.

Par exemple :[loginpage1]login-page = /cgi-bin/getloginpage*login-form-action = *gso-resource =argument-stanza = form1-data

A propos du paramètre login-page :

La valeur affectée au paramètre login-page est une expression régulière utilisée parWebSEAL pour déterminer si une requête entrante correspond en réalité à unerequête de page de connexion. Si c’est le cas, WebSEAL intercepte cette requête etcommence le traitement de connexion unique à base de formulaires.

Seul un paramètre login-page est autorisé dans chaque strophe de page deconnexion personnalisée. Vous devez créer une strophe supplémentaire deconnexion personnalisée pour chaque paramètre login-page supplémentaire.

L’expression régulière login-page est comparée à l’URI de requête, en fonction dela jonction. Dans l’exemple suivant, l’URI d’une requête destinée à un serveurWebSEAL appelé “websealA” pour une ressource située sur une jonction appelée“junctionX” peut se présenter comme suit :https://websealA.ibm.com/junctionX/auth/login.html

Chapitre 8. Solutions de connexion unique Web 211

Page 232: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

La partie de cette adresse URL qui est comparée à l’expression régulière login-pageest la suivante :/auth/login.html

A propos du paramètre login-form-action :

Le paramètre login-form-action est utilisé pour identifier le formulaire deconnexion dans la page interceptée. Seul un paramètre login-form-action estautorisé dans chaque strophe.

La valeur affectée au paramètre login-form-action est une expression régulière quiest comparée au contenu de l’attribut “action” de la balise HTML “form”.L’attribut “action” est un URI exprimé sous forme de chemin d’accès relatif, absoluou en fonction du serveur. Le paramètre login-form-action doit correspondre à cechemin d’accès car il provient du serveur d’arrière-plan (même s’il estnormalement modifié par WebSEAL avant d’être envoyé au client).

Si plusieurs attributs “action” de la page correspondent à l’expression régulière,seule la première correspondance est acceptée comme formulaire de connexion.

Si l’expression régulière ne correspond pas aux formulaires de la page, un messaged’erreur s’affiche dans le navigateur, indiquant que le formulaire est introuvable.

Vous pouvez définir login-form-action = * afin d’obtenir une correspondance avecle formulaire de connexion lorsque la page en contient un seul.

Utilisation des expressions régulièresLe tableau ci-après répertorie les caractères spéciaux autorisés dans les expressionsrégulières utilisées dans le fichier de configuration des connexions uniques à basede formulaires.

* Correspond à zéro caractères ou plus

? Correspond à tout caractère

\ Echappement (par exemple \? correspondance ?)

[acd] Correspond au caractère a, c, ou d (respect majuscules/minuscules)

[^acd] Correspond à tout caractère à l’exception de a, c ou d (respectmajuscules/minuscules)

[a-z] Correspond à tout caractère compris entre a et z (lettresminuscules)

[^0-9] Correspond à tout caractère non compris entre 0 et 9 (autre qu’unnombre)

[a-zA-Z] Correspond à tout caractère compris entre a et z (minuscules) ouentre A et Z (majuscules)

Dans la plupart des cas, aucun caractère spécial n’est requis car la requête de lapage de connexion se compose d’un seul URI identifiable. Dans certains cas, vouspouvez utiliser le caractère “*” à la fin de l’expression afin que les données derequêtes situées à la fin de l’URI n’empêchent pas d’obtenir la correspondance avecla page de connexion.

212 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 233: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Strophe d’argumentLa strophe d’argument personnalisée contient une ou plusieurs entrées qui seprésentent sous la forme suivante :<nom> =<méthode>:<valeur>

nom

La valeur du paramètre name est définie de telle sorte qu’elle soit égale à la valeurde l’attribut “name” de la balise HTML “input”. Par exemple :<input name=uid type=text>Username</input>

Ce paramètre peut également utiliser la valeur de l’attribut “name “ des balisesHTML “select” ou “textarea”.

method:value

Cette association de paramètres permet d’extraire les données d’authentificationrequises par le formulaire. Les données d’authentification peuvent inclure :v chaînes littérales de données

chaîne :<texte>

L’entrée utilisée est une chaîne de texte.v Nom d’utilisateur et mot de passe GSO

gso:usernamegso:password

L’entrée correspond au nom d’utilisateur et au mot de passe GSO de l’utilisateuractuel (à partir de la cible spécifiée dans la strophe de page de connexionpersonnalisée).

v Valeur d’un attribut inclus dans les données d’autorisation de l’utilisateurcred:<cred-ext-attr-name>

Par défaut, les données d’autorisation incluent des informations telles que lenom d’utilisateur et le DN Access Manager de l’utilisateur. Pour utiliser le nomd’utilisateur Access Manager en tant que valeur d’entrée, spécifiez cette valeurcomme suit :cred:azn_cred_principal_name

Vous pouvez accéder au DN de l’utilisateur de la façon suivante :cred:azn_cred_authzn_id

Les attributs personnalisés des données d’autorisation (ajoutés via l’associationbalise/valeur) peuvent également être utilisés.

Il est inutile de renseigner les zones d’entrée masquées de cette strophe. En effet,elles sont automatiquement extraites du formulaire HTML et soumises en mêmetemps que la requête d’authentification.

Par exemple :[form1-data]uid = string:brian

Chapitre 8. Solutions de connexion unique Web 213

Page 234: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Activation de la connexion unique à base de formulairesUne fois que vous avez complété le fichier de configuration des connexionsuniques à base de formulaires et situé le fichier dans le répertoire approprié, vousdevez configurer la jonction adéquate afin qu’elle prenne en charge les connexionsuniques à base de formulaires. Pour cela, utilisez l’option de jonction –S avec lacommande pdadmin create :-S <config-file-path>

L’argument config-file-path spécifie l’emplacement du fichier de configuration desconnexions uniques à base de formulaires. L’option de jonction –S permet d’activerla fonction de connexion unique à base de formulaires pour une jonction.

Par exemple :pdadmin> server task webseald-<instance> -t tcp -h websvrA \-S /opt/pdweb/fsso/fsso.conf /jctX

Le fichier de configuration est lu au moment de la création de la jonction et lors dechaque lancement de WebSEAL. Toute erreur au sein du fichier de configurationest susceptible d’entraîner un échec de WebSEAL au moment de son lancement.

Exemple de fichier de configuration pour IBM HelpNowLe site IBM HelpNow appelle ses propres connexions à base de formulaires etconstitue par conséquent un exemple d’accès transparent au site, obtenu grâce à lasolution de connexion unique à base de formulaires.

Cette section contient :v Un formulaire qui ressemble au formulaire de la page de connexion HTML

renvoyé par l’application HelpNowv Le fichier de configuration de connexion unique à base de formulaires utilisé

pour le traitement de ce formulaire

Formulaire trouvé dans la page HTML interceptée :<form name="confirm" method="post" action="../files/wcls_hnb_welcomePage2.cgi"><p>Matricule du salarié :&nbsp;<input name="data" size="10" maxlength="6"><p>Nom du pays :<select name="Cntselect" size="1"><OPTION value="notselected" selected>Select Country</OPTION><OPTION value=675>United Arab Emirates - IBM</OPTION><OPTION value=866>United Kingdom</OPTION><OPTION value=897>United States</OPTION><OPTION value=869>Uruguay</OPTION><OPTION value=871>Venezuela</OPTION><OPTION value=852>Vietnam</OPTION><OPTION value=707>Yugoslavia</OPTION><OPTION value=825>Zimbabwe</OPTION></select><p><input type=submit value=Submit></form>

214 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 235: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Fichier de configuration personnalisé utilisé pour le traitement de ceformulaire :Configuration FSSO HelpNow :

[forms-sso-login-pages]login-page-stanza = helpnow

[helpnow]# Le site HelpNow vous réoriente vers cette page # Vous devez vous connecter.login-page = /bluebase/bin/files/wcls_hnb_welcomePage1.cgi

# Le formulaire de connexion est le premier de la page, ce quipermet de l’appeler# ’*’.login-form-action = *

# La ressource GSO, HelpNow, contient le matricule del’employé.gso-resource = helpnow

# Arguments d’authentification.argument-stanza = auth-data

[auth-data]# La zone ’Data’ contient le matricule de l’employé.data = gso:username

# La zone Cntselect contient un nombre correspondant au pays# d’origine du client. La chaîne “897” correspond auxEtats-Unis.Cntselect = string:897

Chapitre 8. Solutions de connexion unique Web 215

Page 236: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

216 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 237: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Chapitre 9. Intégration d’application

WebSEAL supporte l’intégration d’applications de tiers grâce à des variablesd’environnement et une capacité d’URL dynamiques. WebSEAL étend la plage desvariables d’environnement et des en-têtes HTTP pour permettre à des applicationsde tiers d’exécuter des opérations basées sur l’identité du client. En outre,WebSEAL peut fournir un contrôle d’accès sur les adresses URL dynamiques,comme celles contenant du texte de requête.

Index des rubriques :v «Prise en charge de la programmation CGI» à la page 217v «Prise en charge des applications serveur d’arrière-plan» à la page 219v «Meilleures pratiques de jonction applicables à l’intégration d’applications» à la

page 220v «Création d’un service d’individualisation personnalisé» à la page 221v «Activation dynamique des droits d’accès (code/valeur)» à la page 223v «Mise à jour des données sur l’état de la session entre le client et les applications

d’arrière-plan» à la page 226v «Ajout d’un contrôle d’accès à des adresses URL dynamiques» à la page 230v «Exemple d’adresse URL dynamique : Travel Kingdom» à la page 236

Prise en charge de la programmation CGIPour prendre en charge la programmation CGI, WebSEAL ajoute trois variablesd’environnement au jeu standard de variables CGI. Elles peuvent servir à desapplications CGI fonctionnant sur le serveur WebSEAL local ou sur un serveurd’arrière-plan relié par jonction. Ces variables fournissent aux applications CGI desinformations spécifiques d’Access Manager, que ce soit dans le domaine utilisateur,groupe ou données d’autorisation.

Sur un serveur WebSEAL local, ces variables d’environnement sontautomatiquement mises à la disposition des programmes CGI.

Les variables d’environnement utilisées par une application CGI s’exécutant sur unserveur tiers relié par jonction sont générées à partir des informations d’en-têteHTTP transmises au serveur par WebSEAL. Vous devez spécifier l’option –c pourcréer une jonction qui prend en charge des informations d’en-tête spécifiquesd’Access Manager dans les requêtes destinées à un serveur d’arrière-plan.

Voir aussi la section «Spécification de l’identité du client dans les en-têtes HTTP(–c)» à la page 182.

Autres variables d’environnement spécifiques d’Access Manager :

Variables d’environnementCGI

Description

HTTP_IV_USER Nom du compte utilisateur Access Manager de l’émetteurde la requête.

© Copyright IBM Corp. 1999, 2002 217

Page 238: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Variables d’environnementCGI

Description

HTTP_IV_GROUPS Groupes Access Manager auxquels appartient l’émetteurde la requête. Liste de groupes séparés par une virgule —chaque groupe est encadré de guillemets.

HTTP_IV_CREDS Structure de données opaque codée représentant desdonnées d’autorisation Access Manager. Fournit desautorisations aux serveurs éloignés pour que lesapplications de niveau intermédiaire puissent utiliser l’APId’autorisation pour appeler le service d’autorisation.Reportez-vous au document intitulé IBM Tivoli AccessManager Authorization C API Developer’s Reference.

Variable REMOTE_USER sur un serveur WebSEAL local :

Dans l’environnement d’un serveur local contrôlé par WebSEAL, la valeur de lavariable HTTP_IV_USER répertoriée ci-dessus est fournie comme la valeur de lavariable REMOTE_USER standard. La variable REMOTE_USER peut égalementêtre présente dans l’environnement d’une application CGI s’exécutant sur unserveur d’arrière-plan relié par jonction. Sa valeur n’est alors pas contrôlée parWebSEAL.

Variable d’environnementCGI

Description

REMOTE_USER Contient la même valeur que le champ HTTP_IV_USER.

Windows : prise en charge des variables d’environnementWIN32

Cette section est réservée aux jonctions locales.

Windows ne met pas automatiquement toutes ses variables d’environnementsystème à la disposition des processus (par exemple, des applications CGI). Enrègle générale, vous trouverez les variables d’environnement système qui vousseront nécessaires.

Toutefois, si tel n’était pas le cas, vous pouvez vous procurer les variablesWindows dont vous avez besoin dans le fichier de configuration webseald.conf.(Les variables d’environnement Access Manager mentionnées dans la sectionprécédente sont automatiquement disponibles sur toutes les plates-formes.)

Ajoutez les variables d’environnement système Windows requises dans la strophe[cgi-environment-variables] du fichier de configuration webseald.conf enrespectant le format suivant :ENV = <nom_variable>

Par exemple :[cgi-environment-variables]#ENV = SystemDriveENV = SystemRootENV = PATHENV = LANGENV = LC_ALL

218 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 239: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

ENV = LC_CTYPEENV = LC_MESSAGESENV = LOCPATHENV = NLSPATH

Un environnement CGI hérite de toute ligne non mise en commentaire.

Prise en charge des applications serveur d’arrière-planWebSEAL assure également la prise en charge du code exécutable s’exécutantcomme un composant incorporé d’un serveur Web d’arrière-plan. Exemples de cetype de code exécutable côté serveur :v Servlets Javav Cartouches pour Oracle Web Listenerv Plug-ins côté serveur

Lorsque vous créez une jonction avec un serveur d’arrière-plan à l’aide de l’option–c, WebSEAL insère des informations sur l’appartenance de groupe et sur l’identitédu client, propres à Access Manager, dans les en-têtes HTTP des requêtes destinéesà ce serveur.

Les informations de ces en-têtes permettent aux applications des serveurs tiersreliés par une jonction d’exécuter des actions spécifiques de l’utilisateur en fonctionde l’identité Access Manager du client.

WebSEAL comporte un certain nombre d’en-têtes HTTP propres à AccessManager :

Champs d’en-tête HTTPspécifiques de PD

Description

iv-user = Nom du client sous forme abrégée ou détaillée.“Unauthenticated” par défaut, si le client n’est pasauthentifié (inconnu).

iv-groups = Liste des groupes auxquels appartient le client. Seprésente sous forme d’une liste de noms de groupesentre apostrophes, séparés par une virgule.

iv-creds = Structure de données opaque codée représentant desdonnées d’autorisation Access Manager. Fournit desautorisations aux serveurs éloignés pour que lesapplications de niveau intermédiaire puissent utiliserl’API d’autorisation pour appeler le serviced’autorisation. Reportez-vous au document intituléIBM Tivoli Access Manager Authorization C APIDeveloper’s Reference.

Ces en-têtes HTTP sont à la disposition des applications CGI en tant que variablesd’environnement HTTP_IV_USER, HTTP_IV_GROUPS et HTTP_IV_CREDS.Pour les autres structures d’applications non CGI, reportez-vous à ladocumentation propre à chaque produit pour savoir comment extraire des en-têtesà partir de requêtes HTTP.

Voir aussi la section «Spécification de l’identité du client dans les en-têtes HTTP(–c)» à la page 182.

Chapitre 9. Intégration d’application 219

Page 240: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Meilleures pratiques de jonction applicables à l’intégrationd’applications

Cette section inclut les recommandations en matière de “meilleures pratiques”applicables lors de l’utilisation des jonctions WebSEAL.v «Fourniture d’informations d’en-tête HOST complètes avec -v» à la page 220v «Prise en charge du filtrage des adresses URL absolues standard» à la page 220

Fourniture d’informations d’en-tête HOST complètes avec -vLes configurations d’hôte virtuel et les applications du portail nécessitentl’utilisation d’informations correctes sur l’adresse IP (afin d’établir des connexionssocket appropriées) ainsi que des informations complètes sur le nom de serveur(afin d’obtenir un routage précis).

These special back-end application services require complete server name and portdesignation information in any requests from browsers. L’en-tête HOST d’unerequête contient ces informations et permet à l’application de les utiliser. Lorsquevous utilisez les jonctions WebSEAL, ces informations sont transmises à l’en-têteHOST via l’utilisation de l’option de jonction –v.

L’insuffisance ou l’absence d’informations sur le nom de serveur et sur le port apour effet de diminuer les performances des applications d’hébergement virtuel etde portail. En outre, les cookies de domaine définis par ces applications risquentde ne pas contenir suffisamment d’informations.

Pour transmettre les informations les plus complètes possibles à l’en-tête HOST, larecommandation en termes de “meilleures pratiques” consiste à toujours utiliser lenom de domaine complet du serveur relié par jonction et le numéro de port deconnexion dans l’option –v lors de la création ou de l’ajout d’une jonction.

L’option –v utilise la syntaxe suivante :–v<nom_hôte_complet>[:<port>]

Par exemple :-v xyz.ibm.com:7001

Remarque : Le port ne doit être spécifié que si vous utilisez un numéro de portnon standard.

Prise en charge du filtrage des adresses URL absoluesstandard

WebSEAL, en tant que proxy frontal inversé, offre des services de sécurité auxserveurs d’applications reliés par jonction. Les pages renvoyées au client par lesapplications d’arrière-plan contiennent le plus souvent des adresses URLcorrespondant à des ressources situées sur le serveur relié par jonction.

Il est important que ces adresses incluent le nom de la jonction afin qu’ellespuissent acheminer les requêtes vers les emplacements corrects des ressources.WebSEAL utilise un ensemble de règles standard utilisé pour le filtrage desadresses URL statiques et pour l’acheminement de ces informations sur lesjonctions. Une configuration supplémentaire est requise pour le filtrage desadresses URL dans les scripts et des adresses URL générées de façon dynamique.

220 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 241: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Pour plus d’informations sur le filtrage des adresses URL, reportez-vous à lasection «Modification des adresses URL des ressources d’arrière-plan» à la page173.

La capacité de WebSEAL à filtrer correctement les adresses URL absolues enprovenance des pages HTML statiques requiert des informations sur le nom duserveur. Elles se trouvent dans l’option de jonction –h. Cette option permet àWebSEAL d’obtenir le nom du serveur relié par jonction. Les arguments adaptés àcette option peuvent inclure :v Le nom de domaine complet du serveurv Le nom abrégé du serveurv L’adresse IP du serveur

WebSEAL identifie les adresses URL absolues à filtrer en prenant comme base sesconnaissances sur le nom de serveur relié par jonction. En fonction de votreenvironnement réseau, la configuration –h <nom_abrégé> peut ne pas fournir àWebSEAL les informations suffisantes.

Dans l’exemple suivant, une jonction est créée à l’aide de l’option et de l’argumentci-dessous pour un serveur d’arrière-plan situé au sein du réseau ibm.com etportant le nom abrégé “xyz”:-h xyz

Une adresse apparaît comme suit dans une page HTML de ce serveur :http://xyz.ibm.com/doc/release-notes.html

Lorsque cette page est transmise au client pendant une requête, WebSEAL peut setrouver dans l’impossibilité de filtrer cette adresse URL car il n’a pas pu, sur labase des informations fournies par –h, reconnaître “xyz.ibm.com” comme nom deserveur. Sans le nom de jonction dans le chemin d’accès, une requête de notesd’informations échoue.

Pour effectuer un filtrage correct des adresses URL absolues statiques, larecommandation en termes de “meilleures pratiques” consiste à toujours utiliser lenom de domaine complet du serveur relié par jonction dans l’option –h lors de lacréation ou de l’ajout d’une jonction.

Création d’un service d’individualisation personnaliséUn portail Web, également appelé page de lancement, est un service de sites Webintégré qui dresse, de manière dynamique, la liste personnalisée des ressourcesWeb mises à la disposition d’un utilisateur spécifique. Celles-ci peuvent inclure descontenus d’entreprise, des services de maintenance et des outils de formation. Lasortie du portail représente la liste individualisée des ressources basée sur lesdroits d’accès de l’utilisateur. La page de lancement contient uniquement lesressources ayant les droits d’accès qui conviennent pour cet utilisateur.

Vous pouvez utiliser les options de configuration WebSEAL ainsi que le serviced’attribution de droits d’accès de l’API d’autorisation pour créer une solution deportail personnalisée dans un environnement Access Manager.

Le processus de création d’un service de portail WebSEAL personnalisé impliqueles éléments suivants :1. Une région spécifique de l’espace objet protégé est créée pour localiser

l’ensemble des objets ressource du portail.

Chapitre 9. Intégration d’application 221

Page 242: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

2. Les LCA explicites qui conviennent sont associées à chacun de ces objetsressource.

3. Le fichier de configuration WebSEAL est édité de façon à inclure l’adresse URLdu service du portail, le chemin de l’espace objet contenant les ressources duportail et le bit de droits d’accès nécessaire à l’utilisateur pour accéder à cesressources.

4. Pour chaque requête utilisateur envoyée à l’adresse URL du portail, WebSEALutilise le service d’attribution de droits d’accès de l’API d’autorisation pouranalyser cet espace objet et dresser la liste des ressources répondant auxconditions d’autorisation applicables à cet utilisateur.

5. WebSEAL place ces informations dans un en-tête HTTP PD_PORTAL qui estenvoyé au serveur du portail d’arrière-plan (relié par jonction).

6. Le service du portail personnalisé (par exemple, CGI ou servlet) situé sur leserveur d’arrière-plan lit le contenu de l’en-tête PD_PORTAL et, par exemple, lemappe à des descriptions et à des liens URL affichés sur une page Web. Cesinformations représentent la liste individualisée des ressources mises à ladisposition de l’utilisateur en fonction des droits de la liste de contrôle d’accès.

Configuration de WebSEAL pour un service d’individualisation1. Créez une nouvelle jonction WebSEAL pour le service d’individualisation. Par

exemple :pdadmin> server task<nom_serveur> create -t tcp -h portalhost.abc.com \/portal-jct

2. Editez le fichier de configuration webseald.conf pour ajouter une nouvellestrophe [portal-map] :[portal-map]

3. L’entrée de cette strophe identifie l’adresse URL relative au serveur duprogramme du service du portail, la région de l’espace objet dans laquelle sontrecherchées les ressources protégées disponibles, et les droits d’accèsnécessaires. Il s’agit de la liste placée dans l’en-tête PD_PORTAL.[portal-map]<URL> =<région_espace_objet>:<droits_accès>

Remarque : Seuls les objets ressource dont les LCA explicites contiennent lesdroits d’accès qui conviennent pour cet utilisateur sont sélectionnéslors de la recherche.

4. Après avoir ajouté la strophe et les entrées de mappage qui conviennent, vousdevez redémarrer WebSEAL (avec la commande webseald).

Exemple de service d’individualisationv Créez une jonction au serveur du portail :

pdadmin> server task webseald-WS1 -t ssl -h PORTAL1 /portal

v Définissez la région de l’espace objet protégé WebSEAL contenant les ressourcesutilisables par le service d’individualisation :pdadmin> objectspace create /Resources “Portal Object Hierarchy” 10pdadmin> object create /Resources/Content ““ 10 ispolicyattachable yespdadmin> object create /Resources/Support ““ 10 ispolicyattachable yespdadmin> object create /Resources/Content/CGI ““ 11 ispolicyattachable yespdadmin> object create /Resources/Support/Servlet ““ 11 ispolicyattachable yes

222 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 243: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Remarque : L’argument “ispolicyattachable” doit avoir la valeur “yes” pourchaque ressource. Le mécanisme de recherche sélectionneuniquement les objets ressource qualifiés possédant des LCAexplicites.

v Configuration de WebSEAL (webseald.conf) :[portal-map]/portal/servlet/PortalServlet = /Resources:r

v Adresse URL du portail utilisée par l’utilisateur :https://WS1/portal/servlet/PortalServlet

Activation dynamique des droits d’accès (code/valeur)Les entreprises et leurs partenaires ont souvent besoin de partager des droitsd’accès communs tels que des données commerciales (dans une relation business tobusiness) ou des données client (dans une relation business to customer).v Les droits d’accès génériques sont des attributs qui décrivent des informations

nécessaires aux applications fournissant des services. Parmi ces attributs figurentnotamment les informations sur les comptes client et les données de facturation.

v Les droits d’accès de sécurité sont des attributs qui établissent des conditionsrenforcées pour autoriser les requêtes portant sur des ressources. Ceci concernenotamment les rôles utilisateur, les restrictions de contrôle d’accès et les règlesrégissant un accord commercial.

A l’aide d’une extension du service CDAS (Cross Domain Authentication Service),Access Manager fournit un mécanisme souple permettant d’inclure desinformations sur les droits d’accès, sous la forme d’attributs de valeur/codeétendus, dans des autorisations d’utilisateurs lors de l’authentification. Lesapplications peuvent directement extraire ces données à partir d’une autorisationpar le biais de l’API d’autorisation. Pour plus d’informations sur la mise en oeuvrede l’extension CDAS, reportez-vous au document IBM Tivoli Access ManagerWebSEAL Developer’s Reference.

Création de droits d’accès à partir de données LDAPWebSEAL fournit un mécanisme de droits d’accès intégré spécifique permettantd’insérer des informations LDAP supplémentaires définies par l’utilisateur dansdes données d’autorisation sous la forme d’attributs étendus. Vous pouvez ensuiteplacer les valeurs affectées à ces attributs dans l’en-tête HTTP d’une requêteenvoyée à un serveur d’applications d’arrière-plan via une jonction.

Le flux de processus ci-dessous illustre la séquence des opérations :v Les données supplémentaires définies par l’utilisateur issues de n’importe quel

champ d’un compte de registre LDAP d’un utilisateur sont ajoutées sous laforme d’attributs étendus à son autorisation Access Manager.

v Les jonctions WebSEAL sont configurées de façon à extraire ces données à partirde l’autorisation puis à les placer dans l’en-tête HTTP d’une requête envoyée àun serveur d’arrière-plan.

v L’application d’arrière-plan peut extraire les données de l’en-tête sans avoirbesoin d’un code spécial ou de l’API d’autorisation.

La configuration de WebSEAL pour insérer des informations LDAPsupplémentaires dans un en-tête HTTP comprend deux étapes :1. Vous devez extraire les données supplémentaires du registre LDAP et les

insérer dans l’autorisation de l’utilisateur lors de la connexion.

Chapitre 9. Intégration d’application 223

Page 244: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

2. En fonction des attributs étendus définis pour la jonction (HTTP-Tag-Value),vous devez extraire les données qui conviennent de l’autorisation et les insérerdans l’en-tête HTTP de la requête envoyée via la jonction.

Insertions de données LDAP supplémentaires dans uneautorisationIl existe deux méthodes pour placer des données utilisateur LDAP supplémentairesdans une autorisation :1. Dans la strophe [ldap-ext-cred-tags] du fichier de configuration pd.conf, créez

des entrées qui mappent les données LDAP aux champs de l’autorisation.Cette méthode est décrite dans cette section.

2. Créez un module CDAS personnalisé qui mappe toutes les données définiespar l’utilisateur aux attributs étendus des données d’autorisation.Pour plus d’informations sur la mise en oeuvre de ce module CDAS,reportez-vous au document IBM Tivoli Access Manager WebSEAL Developer’sReference.

Pour mapper les données spécifiques de la classe d’objets inetOrgPerson LDAP àun attribut défini par l’utilisateur dans son autorisation, vous pouvez utiliser lastrophe [ldap-ext-cred-tags] du fichier de configuration pd.conf. Les paramètres decette strophe ont le format suivant :<cred-ext-attr-name> = <inetOrgPerson-name>

Dans l’autorisation elle-même, chaque entrée cred-ext-attr-name défini dans le fichierde configuration pd.conf commence par le préfixe “tagvalue_”.Ce préfixe empêchetous les conflits avec les autres informations existantes dans l’autorisation. Parexemple :

Nom et valeur dela classe d’objets inetOrgPerson :

employeeNumber:09876

Nom de l’attribut étendu de l’autorisation : ldap-employee-number

Association du nom d’attributau nom des données LDAP au seinde la strophe[ldap-ext-cred-tags] :

ldap-employee-number = employeeNumber

Nom d’attribut etvaleur tels qu’ils apparaissentdans les données d’autorisationde l’utilisateur :

tagvalue_ldap-employee-number:09876

v Cette fonctionnalité exige que l’utilisateur s’authentifie à l’aide du nomd’utilisateur LDAP et du mot de passe. La méthode d’authentificationpasswd-ldap doit être activée. Le code de la bibliothèque partagée libldapauthn(ldapauthn) recherche dans la strophe [ldap-ext-cred-tags] du fichier deconfiguration pd.conf les informations supplémentaires sur l’autorisationdéfinies par l’utilisateur.

v Les données LDAP peuvent venir d’un champ personnalisé ou standard dans laclasse d’objets inetOrgPerson.

v Vous pouvez placer plusieurs entrées dans la strophe [ldap-ext-cred-tags].v Tous les attributs étendus définis dans les entrées de la strophe sont placés dans

les données d’autorisation lors d’une connexion utilisateur.v Les noms de données LDAP ne distinguent pas les majuscules des minuscules.

224 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 245: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

v Les noms des attributs étendus de l’autorisation distinguent les majuscules desminuscules.

Insertion des données d’autorisation dans l’en-tête HTTPLes données d’autorisation définies par l’utilisateur créées à la section précédentepeuvent être placées dans l’en-tête HTTP de la requête envoyée au serveurd’arrière-plan via la jonction.

Vous devez configurer la jonction afin de pouvoir extraire les informationssupplémentaires sur les attributs étendus des données d’autorisation et insérez-lesdans l’en-tête HTTP de la requête.Pour cela, définissez l’attribut étendu de jonctionHTTP-Tag-Value sur l’objet jonction dans l’espace objet protégé WebSEAL.

Vous pouvez utiliser la commande pdadmin object modify set attribute pourdéfinir des attributs étendus sur un objet jonction dans l’espace objet protégéWebSEAL.pdadmin> object modify <nom_obj> setattribute <nom_attr><valeur_attr>

Un attribut étendu (“attr-name”) permet à la jonction d’effectuer un type defonctionnalité spécifique. L’attribut étendu HTTP-Tag-Value indique à la jonctiond’extraire une valeur spécifique des données d’autorisation d’un utilisateur etd’envoyer cette valeur au serveur d’arrière-plan au sein de l’en-tête HTTP. Lavaleur affectée à l’attribut étendu HTTP-Tag-Value utilise le format suivant :<cred-ext-attr-name>=<http-header-name>

L’entrée cred-ext-attr-name apparaît exactement de la même manière que dans lastrophe [ldap-ext-cred-tags] du fichier de configuration pd.conf. Le préfixe“tagvalue_”, qui apparaît dans les données d’autorisation, n’est pas utilisé. Cetteentrée distingue les majuscules des minuscules. L’entrée http-header-name spécifie lenom de l’en-tête HTTP utilisé pour acheminer les données via la jonction.

Par exemple :pdadmin> object modify /WebSEAL/WS1/junctionA set attribute \HTTP-Tag-Value ldap-employee-number=employee-id

Lorsque WebSEAL transmet une requête utilisateur à un serveur d’applicationsd’arrière-plan, il recherche tous les attributs étendus HTTP-Tag-Value configuréssur l’objet jonction.

Dans cet exemple, la jonction configurée recherche dans les données d’autorisationde l’utilisateur à l’origine de la requête la valeur de l’attribut étendutagvalue_ldap-employee-number, l’extrait puis la place dans un en-tête HTTP sous laforme suivante :employee-id:09876

Pour résumer :

Valeur de l’attribut HTTP-Tag-Valuedéfini sur l’objet jonction :

ldap-employee-number=employee-id

Nom d’attribut et valeur tels qu’ilsapparaissent dans les donnéesd’autorisation de l’utilisateur :

tagvalue_ldap-employee-number:09876

Nom et valeur de l’en-tête HTTP : employee-id:09876

Chapitre 9. Intégration d’application 225

Page 246: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Si l’application d’arrière-plan est une application CGI, la spécification CGI stipuleque les en-têtes HTTP sont fournis aux programmes CGI sous forme de variablesd’environnement qui apparaissent comme suit :HTTP_<http-header-name>

Par exemple :HTTP_employee-id=09876

Différentes données d’attribut utilisateur peuvent être transmises à un serveur reliépar jonction à l’aide de plusieurs commandes pdadmin object modify set attributeafin de définir plusieurs attributs de jonction HTTP-Tag-Value (un attribut parcommande).

Mise à jour des données sur l’état de la session entre le client et lesapplications d’arrière-plan

WebSEAL peut mettre à jour l’état de la session avec les clients sur HTTP et surHTTPS. En outre, vous pouvez configurer WebSEAL de façon à fournir desinformations sur les sessions utilisateurs aux serveurs d’applications reliés parjonction. Grâce à ces informations, les applications d’arrière-plan peuvent mettre àjour l’état de la session avec les clients.

Contexte de la gestion des sessions utilisateursUne connexion sécurisée, ou session, entre un client et un serveur exige que cedernier ait la possibilité de mémoriser (entre de nombreuses requêtes) sesinterlocuteurs. Le serveur doit donc pouvoir recevoir des informations sur l’état dela session, identifiant le client associé à chaque requête.

Si l’état de la session entre le client et le serveur est inconnu, les communicationsentre les deux doivent être renégociées pour chaque nouvelle requête. Lesinformations sur l’état de la session optimisent les performances en évitant lesfermetures et les réouvertures répétées des connexions client/serveur. Le clientpeut se connecter une seule fois et exécuter de nombreuses requêtes sans avoir à seconnecter séparément pour chacune.

WebSEAL met à jour les informations sur l’état de la session grâce à la mémoirecache d’ID de sessions SSL GSKit et à la mémoire cache de sessions/donnéesd’autorisations WebSEAL. La mémoire cache de session GSKit traite lescommunications HTTPS (SSL) lorsque les informations d’ID de session SSL sontutilisées pour gérer l’état des sessions.La mémoire cache des donnéesd’autorisation WebSEAL stocke un ID de session WebSEAL par client, ainsi que desinformations sur les données d’autorisation spécifiques à chaque client.

Vous pouvez configurer WebSEAL afin de stocker un ID de session utilisateurunique par client authentifié, sous forme d’attribut étendu figurant dans lesdonnées d’autorisation de chaque client. Vous pouvez configurer une jonction àl’aide des attributs étendus pour les objets Access Manager afin de transmettre lesinformations d’ID de session utilisateur au serveur d’arrière-plan. Sur ce serveurd’arrière-plan, une application peut bénéficier des informations sur les sessionsutilisateurs en vue de gérer l’interaction client-serveur (comme par exemple lesuivi de l’activité des utilisateurs).

226 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 247: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Activation de la gestion des ID de sessions utilisateursLe paramètre user-session-ids, qui figure dans la strophe [session] du fichier deconfiguration webseald.conf vous permet d’activer et de désactiver la créationd’un ID de session utilisateur unique dans les données d’autorisation de chaqueclient déposant une requête. La valeur par défaut est “yes” (activée) :[session]user-session-ids = yes

L’ID de session utilisateur unique est stocké dans les données d’autorisation d’unutilisateur sous la forme d’un attribut étendu portant un nom et une valeur :tagvalue_user_session_id = <user-session-id>

Dans les données d’autorisation elles-mêmes, le nom d’attribut étendu(user_session_id) est précédé du préfixe “tagvalue_” pour éviter les conflits avecd’autres informations figurant dans les données d’autorisation.

La valeur attribuée à l’ID de session utilisateur est une chaîne qui identifie unesession spécifique associée à un utilisateur authentifié. L’ID de session utilisateurest une chaîne codée MIME-64 qui inclut le nom de l’instance WebSEAL (pour lesupport de nombreuses instances WebSEAL) et l’ID de session standard WebSEALassocié à l’utilisateur.

Un seul utilisateur qui se connecte plusieurs fois (par exemple, à partir dedifférentes machines) possède plusieurs ID de session WebSEAL. Etant donné quel’ID de session utilisateur prend comme base l’ID de session WebSEAL, il existeentre eux un mappage individuel. L’ID de session utilisateur unique est stockédans les données d’autorisation d’un utilisateur.Cela permet d’acheminer cettevaleur via une jonction sous la forme d’un en-tête HTTP (à l’aide de lafonctionnalité tag-value) afin qu’elle puisse être utilisée par une applicationd’arrière-plan.

Insertion des données d’autorisation dans l’en-tête HTTPL’objectif de la gestion des sessions utilisateurs consiste à transmettre l’ID desession utilisateur unique au serveur d’applications d’arrière-plan. Cet objectif estatteint grâce à la configuration de l’attribut étendu HTTP-Tag-Value pour lajonction.

Vous pouvez utiliser la commande pdadmin object modify set attribute pourdéfinir un attribut étendu sur un objet jonction dans l’espace objet protégéWebSEAL.pdadmin> object modify <nom_obj> setattribute <nom_attr><valeur_attr>

Chapitre 9. Intégration d’application 227

Page 248: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Un attribut (“attr-name”) permet à la jonction d’effectuer un type de fonctionnalitéspécifique. L’attribut HTTP-Tag-Value indique à la jonction d’extraire une valeurspécifique de l’attribut figurant dans les données d’autorisation et d’envoyer cettevaleur au serveur d’arrière-plan au sein de l’en-tête HTTP.

La valeur affectée à l’attribut étendu HTTP-Tag-Value utilise le format suivant :<cred-ext-attr-name>=<http-header-name>

Pour les données d’ID de sessions utilisateurs, l’entrée cred-ext-attr-name correspondau nom d’attribut étendu user_session_id dans les données d’autorisation del’utilisateur. Le préfixe “tagvalue_”, qui apparaît dans les données d’autorisationuniquement, n’est pas utilisé. Cette entrée distingue les majuscules des minuscules.La valeur affectée à cet attribut étendu contient l’ID de session utilisateur unique.

L’entrée http-header-name spécifie le nom de l’en-tête HTTP utilisé pour acheminerles données via la jonction. Dans cet exemple, l’en-tête PD-USER-SESSION-ID estutilisé :pdadmin> object modify /WebSEAL/WS1/junctionA set attribute \HTTP-Tag-Value user_session_id=PD-USER-SESSION-ID

Lorsque WebSEAL transmet une requête utilisateur à un serveur d’applicationsd’arrière-plan, il recherche tous les attributs étendus HTTP-Tag-Value configuréssur l’objet jonction.

Dans cet exemple, la jonction configurée recherche dans les données d’autorisationde l’utilisateur à l’origine de la requête la valeur de l’attribut étendutagvalue_user_session_id, puis la place dans un en-tête HTTP sous la formesuivante :PD-USER-SESSION-ID:<user-session-id>

Pour résumer :

Valeur de l’attribut HTTP-Tag-Valuedéfini sur l’objet jonction :

user_session_id=PD-USER-SESSION-ID

Nom d’attribut et valeur tels qu’ilsapparaissent dans les donnéesd’autorisation de l’utilisateur :

tagvalue_user_session_id:<user-session-id>

Nom et valeur de l’en-têteHTTP :

PD-USER-SESSION-ID:<user-session-id>

Si l’application d’arrière-plan est une application CGI, la spécification CGI stipuleque les en-têtes HTTP sont fournis aux programmes CGI sous forme de variablesd’environnement qui apparaissent comme suit :HTTP_<HTTP-header-name>

Par exemple :HTTP_PD-USER-SESSION-ID=<user-session-id>

Pour plus d’information sur la fonctionnalité tag-value, reportez-vous à la section«Activation dynamique des droits d’accès (code/valeur)» à la page 223.

228 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 249: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Fin des sessions utilisateursUn utilisateur peut mettre fin à la session en cours grâce à la commandepkmslogout. En outre, les informations de l’ID de session utilisateur permettentaux administrateurs et aux applications d’arrière-plan de suivre et de gérer lesutilisateurs. Cette section décrit deux méthodes qui permettent de mettre fin à unesession utilisateur au niveau administration :v «Utilisation de l’API d’administration pour mettre fin à des sessions utilisateurs»

à la page 229v «Utilisation de pdadmin pour mettre fin à toutes les sessions utilisateurs» à la

page 229

Utilisation de l’API d’administration pour mettre fin à dessessions utilisateursUne application d’arrière-plan peut utiliser l’API d’administration d’AccessManager pour mettre fin à une session utilisateur spécifique sur la base de l’ID desession utilisateur transmis via la jonction. L’application appelle la fonctionivadmin_server_performtask() au sein de son code. L’instance de serveurWebSEAL et l’ID de session utilisateur sont inclus dans cette fonction sous la formede paramètres.

WebSEAL vérifie que le serveur d’arrière-plan qui effectue l’opération possède lesautorisations appropriées avant de mettre fin à la session utilisateur.

Pour plus d’informations, reportez-vous au document IBM Tivoli Access ManagerAdministration C API Developer’s Reference.

Utilisation de pdadmin pour mettre fin à toutes les sessionsutilisateursUn administrateur peut se servir de l’utilitaire pdadmin pour mettre fin à toutesles sessions d’un utilisateur spécifique sur la base de l’ID utilisateur.pdadmin> server taskwebseald-<nom_instance>terminate all_sessions <id_utilisateur>

La mémoire cache des données d’autorisation WebSEAL est organisée de façon àcroiser l’ID utilisateur, l’ID de session WebSEAL et les informations sur les entréesde mémoire cache. Un utilisateur possède toujours un ID utilisateur unique mêmeen cas de sessions multiples. Toutefois, chaque ID de session WebSEAL est unique.La commande terminate all_sessions permet de supprimer toutes les entrées de lamémoire cache qui appartiennent à user-id.

Chapitre 9. Intégration d’application 229

Page 250: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

WebSEAL vérifie que l’administrateur chargé de lancer la commande possède lesautorisations appropriées avant de mettre fin aux sessions utilisateurs.

Ajout d’un contrôle d’accès à des adresses URL dynamiquesL’environnement Web courant donne aux utilisateurs un accès immédiat à desinformations qui changent rapidement. De nombreuses applications Web génèrentde façon dynamique des adresses URL en réponse à chaque requête utilisateur. Cesadresses URL dynamiques ont généralement une durée de vie limitée. Malgré leurnature provisoire, elles ont besoin d’être bien protégées contre une utilisation ouun accès indésirable.

Composants d’adresses URL dynamiquesCertains outils d’applications Web élaborés utilisent des navigateurs Web standardpour communiquer avec des serveurs d’applications au moyen de l’interface CGId’un serveur Web.

Tous ces outils utilisent des adresses URL dynamiques et des éléments deformulaire caché pour communiquer l’opération demandée (avec sa valeur deparamètre) au serveur d’applications. Une URL dynamique dote l’adresse URLstandard d’informations sur l’opération donnée et ses valeurs de paramètres. Lapartie constituant la chaîne d’interrogation de l’URL contient les opérations,paramètres et valeurs destinés à l’interface d’application Web.

Figure 45. fin de toutes les sessions utilisateurs

230 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 251: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Mappage d’objets de LCA et POP à des adresses URLdynamiques

WebSEAL utilise le modèle de l’espace objet protégé, des modèles de règles (LCA)et POP (Protected Object Policies) pour protéger de façon dynamique les URLgénérées, par exemple celles qui sont générées par des requêtes de base dedonnées. Chaque requête effectuée auprès de WebSEAL est convertie en un objetspécifique, lors de la première étape du processus d’autorisation. Une LCA/POPappliquée à l’objet indique la protection requise sur toute URL dynamiue qui y estmappée.

Comme les URL dynamiques n’ont qu’une durée de vie temporaire, des entréescorrespondantes ne peuvent pas exister dans une base de données de règlesd’autorisation préalablement configurée. Access Manager remédie à cet handicapen fournissant une méthode permettant de mapper de nombreuses URLdynamiques à un seul objet protégé statique.

Les mappages entre objets et modèles sont conservés dans un fichier texte simple :/opt/pdweb/www/lib/dynurl.conf

L’emplacement de ce fichier (par rapport à la racine du serveur) est défini par leparamètre dynurl-map dans la strophe [server] du fichier de configurationwebseald.conf :[server]dynurl-map = lib/dynurl.conf

Ce fichier n’existant pas par défaut, vous devez le créer. L’existence de ce fichier(avec les entrées) permet l’utilisation d’URL dynamiques.

Editez ce fichier pour modifier les mappages. Les entrées de ce fichier ont leformat suivant :<objet> <modèle>

Access Manager fait appel à un sous-ensemble de forme de correspondance deshell UNIX (avec caractères génériques) pour définir le jeu de paramètres quiconstitue un objet dans l’espace objet. Toute URL dynamique correspondant à cesparamètres est mappée à cet objet.

http://www.acme.com/sales/web/fortecgi.cgi?name=catalog&product=shirt&color=red

Protocole ServeurWeb

Chemin durépertoire auprogramme CGI

Opérations, paramètreset valeurs pour l’interfaced’application Web

Fichier duprogramme

CGI

URL de base Chaîne d’interrogation

Figure 46. Transmission de données à une passerelle CGI via une adresse URL

Chapitre 9. Intégration d’application 231

Page 252: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Access Manager accepte les métacaractères du shell UNIX suivants :

Caractère Description

\ Le caractère suivant la barre oblique inversée fait partie d’uneséquence spéciale. Par exemple, \t représente le caractère TAB. Peutégalement jouer le rôle du caractère d’échappement.

? Caractère générique correspondant à un seul caractère. Par exemple,la chaîne “abcde” correspond à l’expression “ab?de”

* Caractère générique correspondant à aucun ou plusieurs caractères.

[] Définit un ensemble de caractères, dont l’un quelconque peutcorrespondre. Par exemple, la chaîne “abcde” correspond àl’expression “ab[cty]de”

^ Indique une négation. Par exemple, l’expression [^ab] correspond àtout sauf aux caractères ‘a’ ou ‘b’.

L’exemple suivant présente une URL dynamique exécutant une consultation derelevé de compte :http://<nom_serveur>/banque_perso/owa/acct.bal?acc=<numéro_compte>

L’objet représentant cette URL dynamique s’afficherait ainsi :http://<nom_serveur>/banque_perso/owa/acct.bal?acc=*

Un examen attentif de l’URL dynamique de cet exemple indique qu’un numéro decompte précis est donné. L’objet pour les soldes bancaires chez banque_persomontre que les droits d’accès de LCA s’appliquent à tout compte (account), car ladernière partie de l’entrée (acc=*) utilise le caractère générique astérisque, quicorrespond à tous les caractères.

La figure ci-après illustre un scénario complet dans lequel une adresse URLdynamique est mappée à un objet protégé :

http://www.acme.com/sales/web/db.cgi?service=SoftWear&catalog=clothing&product=shirt&color=red

www.acme.com/

db.cgi

web/

sales/

redshirt

Entrées d’URL dynamiques :

Espace de nom d'objet protégé

"*product=shirt*color=red*"

Fait correspondre la chaîne d’interrogationavec l’entrée d’espace de nom Web « redshirt »

...group admin -abc---T-m----lrxgroup ABC_company -abc---T-m----lrxany_authenticated --------------unauthenticated --------------...

LCA associée à l’objet :"www.acme.com/sales/web/fortecgi.cgi/redshirt"

Figure 47. Droits d’accès sur une URL dynamique

232 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 253: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Mise à jour de WebSEAL pour les adresses URL dynamiquesUtilisez la commande dynurl update pour mettre à jour l’espace objet protégéWebSEAL avec des entrées saisies dans le fichier de configuration dynurl.conf.1. Créez, modifiez ou supprimez une entrée d’URL dynamique dans le fichier de

configuration dynurl.conf.2. Après avoir apporté les modifications, utilisez la commande dynurl update

pour mettre à jour le serveur :pdadmin> server task webseald-<nom_serveur> dynurlupdate

L’argument nom_serveur représente le nom d’hôte non qualifié de la machineWebSEAL.

Conversion des adresses URL dynamiques dans l’espaceobjet

La conversion d’une URL dynamique en un objet dépend de l’ordre des entréesdans le fichier de configuration dynurl.conf.

Lorsque vous tentez de mapper une URL dynamique à une entrée d’objet, la listedes mappages se trouvant dans le fichier dynurl.conf est lue de haut en basjusqu’à détection de la première occurrence correspondante. A la premièreoccurrence trouvée, l’entrée d’objet correspondante est utilisée pour le contrôled’autorisation qui suit.

En l’absence de toute occurrence correspondante, WebSEAL utilise l’adresse URLelle-même, sans la partie http://<serveur> du chemin.

Conservez en début de liste les mappages correspondant aux LCA les plusrestrictives. Par exemple, si la procédure book.sales d’une application decommandes de livres doit être limitée à un seul groupe d’un club littéraire, alorsque le reste de l’application peut être accessible à tous les utilisateurs, lesmappages doivent intervenir dans l’ordre indiqué dans le tableau suivant :

Entrée de l’espace objet Modèle d’URL

/ows/sales/bksale /ows/db-apps/owa/book.sales*

/ows/sales/general /ows/db-apps/owa/*

N’oubliez pas que si les entrées de mappage se trouvaient dans l’ordre inverse,toutes les procédures enregistrées dans le répertoire /ows/db-apps/owa renverraientà l’objet /ows/sales/general. Cette conversion incorrecte dans l’espace objetpourrait alors introduire une faille dans la sécurité.

Lorsque vous mappez l’expression régulière d’une URL à une entrée de l’espaceobjet, le format de l’URL doit adopter celui produit par la méthode GET, que laméthode utilisée soit POST ou GET.

Avec la méthode de transmission de données GET, les données dynamiques (parexemple, celles qui sont fournies par un utilisateur dans un formulaire) sontajoutées à l’URL.

Avec la méthode POST, les données dynamiques sont intégrées au corps de larequête.

Chapitre 9. Intégration d’application 233

Page 254: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Evaluation de LCA et POPUne fois l’URL dynamique convertie en une entrée d’espace objet, le modèled’héritage de LCA/POP standard détermine si la requête doit être traitée ouannulée (à cause de droits d’accès insuffisants).

Configuration de limites sur les requêtes POSTLe contenu d’une requête POST réside dans son corps. En outre, une requête POSTindique la longueur de ce contenu (déterminée par le navigateur) exprimée enoctets.

request-body-max-read

Le paramètre request-body-max-read dans la strophe [server] du fichier deconfiguration webseald.conf limite l’impact des requêtes POST volumineuses surWebSEAL en indiquant le nombre maximal d’octets à lire dans leur corps. Lecontenu que lit WebSEAL est soumis à des contrôles d’autorisation, comme décritplus haut dans cette section.

La valeur du paramètre request-body-max-read est prise en compte lorsque larequête POST est utilisée pour le traitement des adresses URL dynamiques oul’authentification par formulaires. La valeur par défaut est 4096 octets :[server]request-body-max-read = 4096

Notez que ce paramètre ne limite pas la taille maximale du contenu de la requêtePOST (qui est illimitée). Le paramètre empêche WebSEAL de traiter une requêtePOST trop volumineuse.

dynurl-allow-large-posts

Bien que le paramètre request-body-max-read limite le volume du contenu d’unerequête POST lu et traité par WebSEAL, la requête peut être transmise, dans sonensemble, au serveur d’applications. Dans ce scénario, le contenu non validé esttransmis au serveur d’applications. Si le serveur d’applications ne dispose pas defonctions d’autorisation propres, la sécurité peut être menacée.

Le paramètre dynurl-allow-large-posts permet de contrôler le traitement parWebSEAL des requêtes POST ayant une longueur de contenu supérieure à celledéfinie par request-body-max-read. Si le paramètre a pour valeur “no” (valeur pardéfaut), WebSEAL rejette toutes les requêtes POST dont le contenu dépasse lalongueur définie par request-body-max-read.[server]dynurl-allow-large-posts = no

Si le paramètre a pour valeur “yes”, WebSEAL accepte toute la requête POST maisne valide que le volume de contenu égal à la valeur du paramètrerequest-body-max-read.[server]dynurl-allow-large-posts = yes

Exemple 1 :

v Une requête POST volumineuse est reçue (sa taille dépasse la valeur duparamètre post-max-read).

v dynurl-allow-large-posts = no

v Les adresses URL dynamiques sont activées.

234 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 255: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

v Résultat : 500 “Server Error”

Exemple 2 :

v Une requête POST volumineuse est reçue (sa taille dépasse la valeur duparamètre post-max-read).

v dynurl-allow-large-posts = yes

v Les adresses URL dynamiques sont activées.v Résultat : WebSEAL compare le contenu jusqu’à request-body-max-read à

chacune des expressions régulières figurant dans le fichier de configurationdynurl.conf et effectue un contrôle d’autorisations sur l’objet correspondantlorsqu’une correspondance est trouvée. Dans le cas contraire, le contrôled’autorisations est effectué sur l’objet correspondant à l’URL reçue, comme c’estle cas habituellement. La partie de la requête située après request-body-max-read n’est pas validée.

v Le modèle suivant contient un type de forme de correspondance qui favoriseune mauvaise utilisation par une requête POST de grande taille :/rtpi153/webapp/examples/HitCount\?*action=reset*

Résumé et remarques techniquesRésumé :

v Pour configurer WebSEAL de façon à traiter les adresses URL dynamiques entoute sécurité, créez le fichier suivant :/opt/pdweb/www/lib/dynurl.conf

v Le fichier doit contenir une ou plusieurs lignes du format :<objet> <modèle>

v Si le fichier est vide ou n’existe pas, l’utilisation d’adresses URL dynamiquesn’est pas autorisée.

v Une fois le fichier traité, le nom d’objet apparaît sous la forme d’une ressourceenfant dans l’espace objet WebSEAL.

v Le modèle peut contenir certains des caractères de forme de correspondancestandard. Il peut également contenir une chaîne exacte sans aucun caractère deforme de correspondance.

Le fichier modèle dynurl.conf suivant définit trois objets représentant certaines desapplications Web modèle appartenant au produit IBM WebSphere :

Entrée d’objet Modèle d’URL

/app_showconfig /rtpi153/webapp/examples/ShowConfig*

/app_snoop /rtpi153/servlet/snoop

/app_snoop /rtpi025/servlet/snoop

/app_hitcount/ejb /rtpi153/webapp/examples/HitCount\?source=EJB

/app_hitcount /rtpi153/webapp/examples/HitCount*

Remarques techniques :

v Vous pouvez mapper plusieurs modèles d’URL au même objet (par exemple,app_snoop mappe des adresses URL sur deux serveurs différents).

v Les objets peuvent être imbriqués (par exemple, app_hitcount etapp_hitcount/ejb).

Chapitre 9. Intégration d’application 235

Page 256: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

v Une requête URL entrante est comparée avec les modèles répertoriés dans lefichier, du premier jusqu’au dernier. Lorsqu’une correspondance est trouvée, letraitement s’arrête. Il convient donc de placer les modèles les plus restrictifs audébut du fichier.

v Pour activer les définitions dans le fichier dynurl.conf, exécutez la commandedynurl update (utilisez pdadmin server task).La mise à jour intervient aussitôt et les objets apparaissent dans Web portalmanager lorsque vous actualisez la vue de l’espace objet protégé.

v Evitez d’utiliser des majuscules dans le nom d’objet. Utilisez uniquement desminuscules.

v N’utilisez pas un nom d’objet qui existe déjà dans l’espace objet protégé.v Avant de supprimer un objet dans le fichier dynurl.conf, supprimez toutes les

LCA qui lui sont associées.

Exemple d’adresse URL dynamique : Travel KingdomL’exemple suivant montre comment un réseau intranet peut protéger des adressesURL générées par un programme Oracle Web Listener.

Le serveur Web d’URL dynamiques utilisé dans cet exemple est Oracle WebListener. Cette technologie peut s’appliquer de façon équivalente à d’autresserveurs Web d’URL dynamiques.

Présentation de l’applicationTravel Kingdom est un organisme qui propose à ses clients un service deréservation de voyages sur Internet. L’entreprise compte faire fonctionner deuxapplications de base de données Oracle sur son serveur Web — accessible àl’intérieur du pare-feu d’entreprise et sur Internet.1. Système de réservation de voyage

Les clients autorisés peuvent effectuer une réservation à distance et interrogerleur réservation courante. Le personnel de Travel Kingdom peut égalementeffectuer une réservation par téléphone, gérer des modifications et effectuer denombreuses autres transactions. Comme les clients externes paient les servicesavec une carte de crédit, la transmission des informations doit être parfaitementsécurisée.

2. Responsable administratif

Comme la plupart des sociétés, Travel Kingdom gère une base de donnéesd’administration contenant des informations relatives au salaire, au poste et àl’expérience. Les données sont également accompagnées d’une photographie dechaque membre du personnel.

Présentation de l’interfaceUn serveur Web Oracle est configuré pour fournir l’accès aux procédures suivantesenregistrées dans la base de données :

/db-apps/owa/tr.browse Permet à tous les utilisateurs de se renseigner surles destinations proposées, les prix, etc.

/db-apps/owa/tr.book Sert à effectuer une réservation (personnel del’agence de voyage ou client authentifié).

/db-apps/owa/tr.change Sert à consulter ou modifier une réservation encours.

236 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 257: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

/db-apps/owa/admin.browse Utilisé par les membres du personnel pourvisualiser les informations sur le personnel, sansrestriction, par exemple le numéro de poste,l’adresse électronique et la photographie.

/db-apps/owa/admin.resume Permet à un membre du personnel de visualiser oumodifier les informations concernant son CV dansla base de données d’administration.

/db-apps/owa/admin.update Utilisé par le personnel administratif pour mettre àjour les informations concernant le personnel.

Structure de l’espace WebUn serveur WebSEAL permet de fournir une interface sécurisée à l’espace Webunifié de Travel Kingdom.v Une jonction (/ows) est effectuée avec le serveur Web Oracle exécutant à la fois

l’application de réservation de voyage et l’application d’administration.

Présentation des règles de sécuritéPour fournir une sécurité adéquate aux ressources Web tout en conservant unsystème convivial, l’entreprise a défini les objectifs de sécurité suivants :1. Le personnel de l’agence de voyage a un contrôle total sur toutes les

réservations.2. Les clients authentifiés peuvent effectuer et modifier leurs propres réservations,

mais ne peuvent pas intervenir sur les données des autres clients authentifiés.3. Le personnel administratif a un accès total à toutes les informations

d’administration.4. Le personnel de Travel Kingdom en dehors du service d’administration peut

modifier les informations concernant son propre CV et visualiser desinformations partielles concernant les autres membres du personnel.

Mappages des URL dynamiques dans l’espace objetPour atteindre les objectifs de sécurité décrits ci-dessus, les mappages entre lesURL dynamiques et les entrées d’objet de LCA doivent être configurés commeindiqué dans la table ci-après.

N’oubliez pas que l’ordre de classement de ces mappages est un facteur importantde sécurité, comme indiqué plus haut.

Entrée de l’espace objet Modèle d’URL

/ows/tr/browse /ows/db-apps/owa/tr.browse\?dest=*&date=??/??/????

/ows/tr/auth /ows/db-apps/owa/tr.book\?dest=*&depart=??/??/????& return=??/??/????

/ows/tr/auth /ows/db-apps/owa/tr.change

/ows/admin/forall /ows/db-apps/owa/admin.resume

/ows/admin/forall /ows/db-apps/owa/admin.browse\?empid=[th]???

/ows/admin/auth /ows/db-apps/owa/admin.update\?empid=????

Chapitre 9. Intégration d’application 237

Page 258: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Protection des clientsLe client s’authentifie auprès de WebSEAL sur un canal chiffré et sécurisé.

Les clients souhaitant utiliser l’interface Web doivent en outre s’inscrire auprès duWebmaster de Travel Kingdom pour être dotés d’un compte.

Structure de compte et de groupeQuatre groupes sont créés sur le système :

Staff Membres de l’organisme Travel Kingdom.

TKStaff Employés de l’agence de voyage Travel Kingdom.

AdminStaff Membres du service d’administration de Travel Kingdom. Cesmembres font également partie du groupe Staff.

Customer Clients de Travel Kingdom souhaitant effectuer leurs réservationssur Internet.

Chaque utilisateur reçoit un compte dans le domaine sécurisé pour pouvoir êtreidentifié de façon individuelle par le serveur WebSEAL. Son identité est égalementtransmise aux serveurs Web Oracle de façon à fournir une solution de connexionunique à toutes les ressources Web.

Contrôle d’accèsLe tableau suivant répertorie les contrôles d’accès résultant de l’application desinformations précédentes :

/ows/tr/browse unauthenticated Trany_authenticated Tr

/ows/tr/auth unauthenticated - any_authenticated - groupe TKStaffTr groupe Customer PTr

/ows/admin/forall unauthenticated - any_authenticated - groupe StaffTr

/ows/admin/auth unauthenticated - any_authenticated - groupe AdminStaffTr

Les clients et le groupe TKStaff disposent des mêmes droits d’accès sur les objetsau niveau réservation et voyage, avec la réserve que les clients doivent chiffrerleurs informations (confidentialité) pour renforcer la sécurité lorsqu’ils soumettentdes données confidentielles (telles que des informations de carte de crédit) sur leréseau Internet non sécurisé.

ConclusionCet exemple simple illustre les concepts liés au déploiement d’un système capablede :v protéger les informations confidentielles,v authentifier les utilisateurs,v autoriser l’accès aux informations confidentielles.

En outre, les identités des utilisateurs authentifiés du système sont connues desserveurs Web Oracle et WebSEAL et permettent de fournir une solution àconnexion unique, facilement contrôlable.

238 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 259: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Annexe A. Références du fichier webseald.conf

Fichier de configuration webseald.conf

Catégories et strophes :v WEBSEAL GENERAL

[server]v LDAP

[ldap]v ACTIVE DIRECTORY

[uraf-ad]v DOMINO

[uraf-domino]v SSL

[ssl]v JONCTION

[junction][filter-url][filter-schemes][filter-content-types][script-filtering][gso-cache][ltpa-cache]

v AUTHENTIFICATION[ba][forms][token][certificate][http-headers][auth-headers][ipaddr][authentication-levels][mpa][cdsso][cdsso-peers][failover][e-community-sso][inter-domain-keys][reauthentication][authentication-mechanisms][ssl-qop][ssl-qop-mgmt-hosts][ssl-qop-mgmt-networks]

© Copyright IBM Corp. 1999, 2002 239

Page 260: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

[ssl-qop-mgmt-default]v SESSION

[session]v CONTENU

[content][acnt-mgt][cgi][cgi-types][cgi-environment-variables][content-index-icons][icons][content-cache][content-mime-types][content-encodings]

v CONNEXION[logging]

v API D’AUTORISATION[aznapi-configuration][aznapi-entitlement-services]

v POLICY DIRECTOR[policy-director]

WEBSEAL GENERAL

Paramètre Description

strophe [server]

SYSTEME

unix-user Compte utilisateur UNIX pour le serveur WebSEAL.

unix-group Compte de groupe UNIX pour le serveur WebSEAL.

unix-pid-file Emplacement du fichier PID.

server-root Répertoire racine pour le serveur WebSEAL.

server-name Nom d’instance du serveur WebSEAL.

UNITES D’EXECUTION ET CONNEXIONS

worker-threads Nombre d’unités d’exécution WebSEAL.

client-connect-timeout Délai d’expiration d’une connexion de client initiale.

persistent-con-timeout Délai d’expiration d’une connexion permanenteHTTP/1.1.

CLIENT HTTPS

https Autorise l’accès HTTPS.

https-port Port à utiliser pour les requêtes HTTPS sécurisées.

CLIENT HTTP

http Autorise l’accès HTTP (TCP) non sécurisé.

http-port Port à utiliser pour les requêtes HTTP nonsécurisées.

240 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 261: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

WEBSEAL GENERAL

Paramètre Description

TEXTES DE REQUETES ET MISE EN ANTEMEMOIRE

request-body-max-read Nombre maximal d’octets à lire dans le corps desrequêtes POST.

request-max-cache Quantité maximale par requête de données enantémémoire.

DYNURL

dynurl-map Emplacement du fichier de mappage objetssécurisés/adresses URL

dynurl-allow-large-posts Limite la capacité de WebSEAL à lire les requêtesPOST dont la taille dépasse la valeur depost-max-read.

GESTION DES URI

utf8-url-support-enabled Contrôle la façon dont WebSEAL interprète les URIenvoyées à partir des navigateurs.

SUPPRESSION DE L’IDENTITE SERVEUR

suppress-server-identity Supprime l’identité du serveur WebSEAL dans lesréponses du serveur HTTP.

LDAP

Paramètre Description

strophe [ldap]

ldap-server-config Emplacement du fichier de configuration ldap.conf(défini lors de la configuration).

cache-enabled Active et désactive la mémoire cache LDAP locale.

prefer-readwrite-server Permet de sélectionner un serveur LDAP inscriptibledisponible.

auth-using-compare Accélère les contrôles d’authentification à l’aide d’unmot de passe de comparaison au lieu d’un lienLDAP.

default-policy-override-support Contrôle les règles par défaut ou spécifiques àl’utilisateur.

user-and-group-in-same-suffix Analyse les performances. Indique que les groupessont définis dans le même suffixe LDAP quel’utilisateur.

ssl-enabled Active et désactive SSL pour les communicationsentre WebSEAL et LDAP.

ssl-keyfile Emplacement du fichier de clés SSL.

ssl-keyfile-dn Libellé de certificat dans le fichier de clés SSL, s’ilexiste.

ssl-keyfile-pwd Mot de passe du fichier de clés SSL.

bind-dn Nom distinctif du démon WebSEAL (défini lors de laconfiguration).

bind-pwd Mot de passe du démon WebSEAL (défini lors de laconfiguration).

Annexe A. Références du fichier webseald.conf 241

Page 262: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

ACTIVE DIRECTORY

Paramètre Description

strophe [uraf-ad]

ad-server-config Emplacement du fichier de configuration d’ActiveDirectory (défini lors de la configuration).

bind-id Identité du serveur courant.

bind-pwd Mot de passe du serveur courant.

DOMINO

Paramètre Description

strophe [uraf-domino]

domino-server-config Emplacement du fichier de configuration Domino(défini lors de la configuration).

bind-id Identité du serveur courant.

bind-pwd Mot de passe du serveur courant.

SSL

Paramètre Description

strophe [ssl]

webseal-cert-keyfile Emplacement du fichier de clés contenant lecertificat de serveur envoyé aux navigateurs parWebSEAL lors de la négociation des sessions SSL.

webseal-cert-keyfile-pwd Mot de passe de la clé privée du certificat WebSEAL.

webseal-cert-keyfile-stash Emplacement du fichier caché de mot de passe de laclé privée WebSEAL.

webseal-cert-keyfile-label Nom du certificat WebSEAL à utiliser si différent ducertificat par défaut.

ssl-keyfile Emplacement du fichier de clés du certificatWebSEAL utilisé pour les communications internes.

ssl-keyfile-pwd Mot de passe de la clé privée du certificat WebSEAL(pour les communications internes).

ssl-keyfile-stash Emplacement du fichier caché de mot de passe de laclé privée WebSEAL (pour les communicationsinternes).

ssl-keyfile-label Nom du certificat à utiliser si différent du certificatpar défaut (pour les communications internes).

disable-ssl-v2 Désactive la prise en charge de SSL V2 de manièresélective.

disable-ssl-v3 Désactive la prise en charge de SSL V3 de manièresélective.

disable-tls-v1 Désactive la prise en charge de TLS V1 de manièresélective.

ssl-v2-timeout Délai d’expiration de l’ID de session de la mémoirecache GSKit pour les connexions SSL V2.

ssl-v3-timeout Délai d’expiration de l’ID de session de la mémoirecache GSKit pour les connexions SSL V3.

242 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 263: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

SSL

Paramètre Description

ssl-max-entries Nombre maximum d’entrées concurrentes dans lamémoire cache d’ID de session SSL GSKit.

gsk-crl-cache-size Configuration du cache CRL. Nombre maximald’entrées dans la mémoire cache CRL GSKit.

gsk-crl-cache-entry-lifetime Configuration du cache CRL. Délai d’expiration dela durée de vie des entrées dans la mémoire cacheCRL GSKit.

ssl-ldap-server Serveur LDAP utilisé pour le contrôle de liste derévocation des certificats (LRC).

ssl-ldap-server-port Numéro du port d’écoute de ce serveur LDAP pourle contrôle LRC.

ssl-ldap-user Utilisateur administratif pour le serveur LDAP.

ssl-ldap-user-password Mot de passe de l’utilisateur administratif pour leserveur LDAP.

JONCTION

Paramètre Description

strophe [junction]

junction-db Emplacement de la base de données des jonctions.

jmt-map Emplacement de la table des mappagesjonctions/requêtes (JMT).

http-timeout Délai d’expiration pour l’envoi vers/la lecture surune jonction TCP.

https-timeout Délai d’expiration pour l’envoi vers/la lecture surune jonction SSL.

ping-time Intervalle d’exécution de la routine ping entreWebSEAL et les serveurs reliés par jonction.

basicauth-dummy-passwd Mot de passe global lors de la spécification dedonnées d’authentification de base sur desjonctions “-b supply”.

worker-thread-hard-limit Pourcentage de l’ensemble des unités d’exécutiond’agents qui traitent les requêtes pour unejonction spécifique.

worker-thread-soft-limit Pourcentage de l’ensemble des unités d’exécutiond’agents qui traitent les requêtes pour unejonction spécifique.

io-buffer-size Taille de la mémoire tampon pour l’écrituresur/la lecture à partir d’une jonction.

max-webseal-header-size Taille maximale (exprimée en octets) des en-têtesHTTP générés par WebSEAL.

FILTRAGE DE DOCUMENTS

strophe [filter-url]

<tag> = <attribut> Attributs d’URL filtrés par WebSEAL dans lesréponses des serveurs reliés par jonction.

strophe [filter-schemes]

Annexe A. Références du fichier webseald.conf 243

Page 264: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

JONCTION

Paramètre Description

modèle = <nom_modèle> Liste des modèles d’URL filtrés par WebSEALdans les réponses des serveurs reliés par jonction.

strophe [filter-content-types]

type = texte/html> Type de contenu des documents filtrés parWebSEAL dans les réponses des serveurs reliéspar jonction.

type = texte/vnd.wap.wml Type de contenu des documents filtrés parWebSEAL dans les réponses des serveurs reliéspar jonction.

strophe [script-filtering]

script-filter Active et désactive le filtrage des URL absoluescontenues dans les scripts se trouvant sur lesserveurs reliés par jonction.

MEMOIRE CACHE GSO

strophe [gso-cache]

gso-cache-enabled Active et désactive la mémoire cache GSO.

gso-cache-size Nombre d’entrées dans la mémoire cache GSO.

gso-cache-entry-lifetime Durée de vie maximale d’une entrée dans lamémoire cache GSO.

gso-cache-entry-idle-timeout Durée de vie maximale d’une entrée inactive dansla mémoire cache GSO.

MEMOIRE CACHE LTPA

strophe [ltpa-cache]

ltpa-cache-enabled Active et désactive la mémoire cache LTPA.

ltpa-cache-size Nombre d’entrées dans la mémoire cache LTPA.

ltpa-cache-entry-lifetime Durée de vie maximale d’une entrée dans lamémoire cache LTPA.

ltpa-cache-entry-idle-timeout Durée de vie maximale d’une entrée inactive dansla mémoire cache LTPA.

AUTHENTIFICATION

Paramètre Description

AUTHENTIFICATION DE BASE

strophe [ba]

ba-auth Active et désactive la méthode d’authentification debase.

basic-auth-realm Nom de cellule affiché dans l’invite de connexionBA du navigateur.

FORMULAIRES

strophe [forms]

forms-auth Active et désactive l’authentification par formulaires.

JETON

strophe [token]

244 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 265: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

AUTHENTIFICATION

Paramètre Description

token-auth Active et désactive l’authentification par codes dejeton.

CERTIFICAT

strophe [certificate]

accept-client-certs Configure la gestion des certificats côté clientWebSEAL.

EN-TETES HTTP

strophe [http-headers]

http-headers-auth Active et désactive l’authentification par en-têtesHTTP.

strophe [auth-headers]

header En-têtes HTTP spécifiques utilisés pourl’authentification.

ADRESSE IP

strophe [ipaddr]

ipaddr-auth Active et désactive l’authentification par adresses IP.

AUTHENTIFICATION RENFORCEE

strophe [authentication-levels]

level = unauthenticatedlevel = password

Configuration de l’authentification renforcée.

AGENTS MPA

strophe [mpa]

mpa Active et désactive la prise en charge del’authentification par agents MPA (MultiplexingProxy Agents).

CDSSO

strophe [cdsso]

cdsso-auth Active et désactive l’authentification par jetonsCDSSO.

authtoken-lifetime Valeur de la durée de vie maximale pour le jetond’authentification CDSSO.

strophe [cdsso-peers]

<machine-name> =<keyfile-location>

Domaines homologues utilisant l’authentificationCDSSO.

COOKIES DE SECOURS

strophe [failover]

failover-auth Active et désactive l’acceptation des cookies desecours.

failover-cookies-keyfile Emplacement (chemin absolu) de la clé dechiffrement de cookie générée par cdsso_key_gen.

failover-cookie-lifetime Durée maximale de validité du contenu d’un cookiede secours.

enable-failover-cookie-for-domain Remplace le type cookie de secours de serveur par letype cookie de secours de domaine.

Annexe A. Références du fichier webseald.conf 245

Page 266: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

AUTHENTIFICATION

Paramètre Description

SSO POUR LA e-COMMUNAUTE

strophe [e-community-sso]

e-community-sso-auth Active et désactive les connexions SSO pour lacommunauté électronique.

e-community-name Nom de communauté électronique apparaissantdans les requêtes et les jetons “d’attestation”.

intra-domain-key Emplacement du fichier de clés utilisé pour sécuriserles communications entre les instances WebSEALdans un domaine DNS.

is-master-authn-server Désigne la machine locale comme serveurd’authentification WebSEAL principal.

master-authn-server Nom du serveur d’authentification WebSEALprincipal (si différent de la machine locale).

master-http-port Port d’écoute HTTP non standard du serveurd’authentification principal.

master-https-port Port d’écoute HTTPS non standard du serveurd’authentification principal.

vf-token-lifetime Valeur de la durée de vie du jeton “d’attestation”.

vf-url Adresse URL du jeton “d’attestation”.

ec-cookie-lifetime Valeur de la durée de vie du cookie de communautéélectronique.

strophe [inter-domain-keys]

<domain-name> = <keyfile> Fichiers de clés pour les autres domainesappartenant à la communauté électronique.

NOUVELLE AUTHENTIFICATION

strophe [reauthentication]

reauth-for-inactive Active la nouvelle authentification suite àl’expiration d’une entrée d’antémémoire.

reauth-reset-lifetime Réinitialise, pour la session, le délai d’expiration del’entrée d’antémémoire lorsqu’une nouvelleauthentification a été effectuée avec succès

reauth-extend-lifetime Allonge le délai d’expiration de l’entréed’antémémoire pour terminer le processus denouvelle authentification.

METHODES D’AUTHENTIFICATION ET BIBLIOTHEQUES

strophe [authentication-mechanisms]

246 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 267: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

AUTHENTIFICATION

Paramètre Description

passwd-cdaspasswd-ldappasswd-uraftoken-cdascert-sslcert-cdashttp-requestcdssopasswd-strengthcred-ext-attrssu-passwordsu-token-cardsu-certificatesu-http-requestsu-cdssofailover-passwordfailover-token-cardfailover-certificatefailover-http-requestfailover-cdsso

Liste des méthodes d’authentification et desbibliothèques partagées associées prises en charge.

GESTION DU NIVEAU DE PROTECTION SSL

strophe [ssl-qop]

ssl-qop-mgmt Active et désactive la gestion du niveau deprotection.

strophe [ssl-qop-mgmt-hosts]

<ip-address> Niveau de chiffrement QOP individuel pour leshôtes.

strophe [ssl-qop-mgmt-networks]

<ip-address/mask> Niveau de chiffrement QOP individuel pour lesréseaux.

strophe [ssl-qop-mgmt-default]

default Niveau de chiffrement QOP par défaut pour toutesles autres adresses IP sans correspondance.

SESSION

Paramètre Description

strophe [session]

max-entries Nombre maximum d’entrées concurrentes dans lamémoire cache de session/droits d’accès WebSEAL.

timeout Durée de vie maximale d’une entrée dans lamémoire cache de session/droits d’accès WebSEAL.

inactive-timeout Durée de vie des entrées inactives dans la mémoirecache des droits d’accès WebSEAL.

SESSIONS DE CLIENT SSL

ssl-id-sessions Utilise l’ID SSL pour gérer les sessions de connexionHTTPS.

Annexe A. Références du fichier webseald.conf 247

Page 268: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

SESSION

Paramètre Description

PARTAGE DE SESSIONS

use-same-session Utilise le même ID de session pour les clients quipassent de HTTP à HTTPS et inversement.

ENVOI DE COOKIES DE SESSION

resend-webseal-cookies Envoie n’importe quel cookie de secours et desession configuré avec chaque réponse au client.

ID DE SESSION UTILISATEUR

user-session-ids Active/désactive la création et la gestion des IDutilisateur pour la gestion des sessions.

CONTENU

Paramètre Description

strophe [content]

FICHIERS ET REPERTOIRES LOCAUX

doc-root Répertoire racine de l’arborescence des documentsWeb.

directory-index Nom du fichier d’index du répertoire.

delete-trash-dir Répertoire temporaire de la corbeille pour lesfichiers supprimés par l’administrateur.

REPERTOIRES DES UTILISATEURS LOCAUX

user-dir Ce répertoire est l’arborescence d’accueil del’utilisateur contenant des documents HTML publics.

PAGES D’ERREUR

error-dir Répertoire contenant des fichiers de descriptiond’erreur WebSEAL.

PAGES DE GESTION DES COMPTES

strophe [acnt-mgt]

mgt-pages-root Racine des pages de gestion des comptes.

login Nom du formulaire de connexion standard.

login-success Nom du formulaire de connexion établie.

logout Nom de la page affichée une fois la déconnexionterminée.

account-locked Nom de la page affichée si l’authentification échoueà cause d’un compte verrouillé.

passwd-expired Nom de la page affichée si l’authentification échoueen raison de l’expiration d’un mot de passe.

passwd-change Nom du formulaire de modification de mot depasse.

passwd-change-success Nom de la page affichée si la requête demodification de mot de passe aboutit.

passwd-change-failure Nom de la page affichée si la requête demodification de mot de passe échoue.

help Nom de la page contenant les liens aux pagesd’administration.

248 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 269: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

CONTENU

Paramètre Description

token-login Nom du formulaire de connexion par jeton.

next-token Nom du formulaire de jeton suivant.

stepup-login Nom du formulaire de connexion parauthentification renforcée.

switch-user Nom du formulaire de gestion des changementsd’utilisateurs.

CGI LOCAL

strophe [cgi]

cgi-timeout Valeur du délai d’expiration pour l’écriture et lalecture sur les processus CGI enfants.

strophe [cgi-types]

bat = cmdcmd = cmdpl = perlsh = shtcl = tclsh76

Désigne (pour les serveurs Win32) le programme àexécuter pour une extension de fichier CGIspécifique.

strophe [cgi-environment-variables]

ENV = <nom_variable> Variables d’environnement dont les programmesCGI doivent hériter.

ICONES

strophe [content-index-icons]

image/*video/*audio/*text/htmltext/*application/x-tarapplication/*

Spécifie les icônes graphiques à utiliser lorsqu’unindex des répertoires est généré par WebSEAL (seproduit en l’absence de fichier index.html).

strophe [icons]

diricon Icône à utiliser pour les sous-répertoires.

backicon Icône à utiliser pour le répertoire parent.

unknownicon Icône utilisée pour les types de fichier inconnus.

MISE EN MEMOIRE CACHE DE DOCUMENTS

strophe [content-cache]

text/htmlimage/**/*

Définit la taille et le type de la mémoire cache pourles documents MIME que WebSEAL enregistre enmémoire.

TYPES MIME

strophe [content-mime-types]

<extension> = <type> Définit le type MIME pour des extensions dedocument spécifiques.

deftype Type MIME par défaut à utiliser lorsque le type dedocument ne figure pas dans la table des mappages.

CODAGES DES CONTENUS

strophe [content-encodings]

Annexe A. Références du fichier webseald.conf 249

Page 270: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

CONTENU

Paramètre Description

gz Z Mappe l’extension de document à un type de codagepour les navigateurs prenant en charge le codage decontenu.

CONNEXION

Paramètre Description

strophe [logging]

server-log Emplacement du fichier journal des erreurs duserveur.

max-size Seuil de passage à un autre fichier journal pour lesjournaux HTTP.

flush-time Fréquence de vidage des mémoires tampon dufichier journal HTTP.

requests Active et désactive le journal des requêtes HTTP.

requests-file Emplacement du journal des requêtes HTTP.

referers Active et désactive le journal des liens HTTP.

referers-file Emplacement du journal des liens HTTP.

agents Active et désactive le journal des agents HTTP.

agents-file Emplacement du journal des agents HTTP.

gmt-time Consigne les requêtes avec l’heure GMT au lieu del’heure locale.

API D’AUTORISATION

Paramètre Description

strophe [aznapi-configuration]

db-file Emplacement du fichier cache de la base de donnéesde règles du client local.

cache-refresh-interval Définit l’intervalle entre les contrôles pour les misesà jour (interrogation) du serveur d’autorisationsprincipal.

listen-flags Active et désactive les indicateurs pour la réceptiondes notifications de mise à jour de la mémoire cachedes règles.

JOURNALISATION DE L’API D’AUTORISATION

logclientid=webseald

logsize Seuil de passage à un autre fichier journal pour lagestion du journal d’audit.

logflush Fréquence de vidage des mémoires tampon dufichier journal de l’audit de gestion.

logaudit Active et désactive les fonctions d’audit.

auditlog Emplacement du fichier journal d’audit.

auditcfg = azn Enregistre les événements de droits d’accès.

auditcfg = authn Enregistre les événements d’authentification.

auditcfg = http Enregistre les événements WebSEAL.

250 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 271: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

API D’AUTORISATION

Paramètre Description

DEFINITION DU SERVICE D’API D’AUTORISATION

<service-id>

strophe [aznapi-entitlement-services]

AZN_ENT_EXT_ATTR

POLICY DIRECTOR

Paramètre Description

strophe [policy-director]

config-file Emplacement du fichier de configuration pd.conf.

Annexe A. Références du fichier webseald.conf 251

Page 272: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

252 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 273: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Annexe B. Référence des jonctions WebSEAL

L’utilitaire pdadmin fournit une invite de ligne de commande interactive à partirde laquelle vous pouvez exécuter des tâches de jonction WebSEAL.

Index des rubriques :v «Utilisation de pdadmin pour créer des jonctions» à la page 253v «Commandes de jonction» à la page 255v «Création d’une nouvelle jonction pour un serveur existant» à la page 256v «Ajout d’un serveur supplémentaire à une jonction existante» à la page 258

Utilisation de pdadmin pour créer des jonctionsAvant d’utiliser pdadmin, vous devez vous connecter à un domaine sécurisé entant qu’utilisateur administratif sec_master.

Par exemple :

UNIX :# pdadminpdadmin> loginEntrer ID utilisateur : sec_masterEntrer mot de passe :pdadmin>

Windows :MSDOS> pdadminpdadmin> loginEntrer ID utilisateur : sec_masterEntrer mot de passe :pdadmin>

Pour créer des jonctions WebSEAL, utilisez la commande pdadmin server taskcreate :pdadmin> server task<ID_serveur> create <options>

Le composant ID-serveur de cette commande est une combinaison du serveurAccess Manager utilisé par cette commande et du nom d’hôte du serveur AccessManager.<serveur_Access_Manager>-<nom_hôte>

Syntaxe applicable à un serveur unique WebSEAL :

Pour Access Manager WebSEAL, le composant serveur_Access_Manager estwebseald et le composant the nom_hôte est le nom du serveur WebSEAL :pdadmin> server taskwebseald-<nom_hôte> create<options>

© Copyright IBM Corp. 1999, 2002 253

Page 274: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Le nom du serveur WebSEAL initial installé sur une machine contient toujours lenom de la machine. Par exemple, si le nom de la machine est cruz, l’ID serveurd’une installation WebSEAL à serveur unique est le suivant :webseald-cruz

Syntaxe applicable à plusieurs instances WebSEAL :

Si vous installez plusieurs instances de serveurs WebSEAL sur la même machine, lecomposant serveur_Access_Manager correspond au nom configuré de l’instance duserveur WebSEAL, suivi de webseald et du nom d’hôte :<nom_instance>-webseald-<nom_hôte>

Par exemple, si les noms configurés de deux instances WebSEAL supplémentairessont webseal2 et webseal3, les ID des serveurs sont les suivants :webseal2-webseald-cruzwebseal3-webseald-cruz

Utilisez la commande server list pour vérifier l’ID des serveurs :pdadmin> server listwebseald-cruzwebseal2-webseald-cruzwebseal3-webseald-cruz

Options de commande de jonction obligatoires :

Les options de commande obligatoires pour créer une jonction WebSEAL de basesont les suivantes :v Nom d’hôte du serveur d’applications d’arrière-plan (option –h)v Type de jonction : tcp, ssl, tcpproxy, sslproxy, local (option –t)v Point de jonction (point de montage)pdadmin> server taskwebseald-<nom_hôte> create–t <type>–h <nom_hôte> <point_jct>

254 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 275: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Commandes de jonctionLes commandes de jonction suivantes sont disponibles avec pdadmin server task :

Commande Description

create Crée une nouvelle jonction pour un serveur existant.

add Ajoute un ou plusieurs serveurs à un point de jonctionexistant.

remove Supprime un serveur d’un point de jonction.

Syntaxe : remove –i <id_serveur> <point_de_jonction>

Utilisez la commande show pour connaître l’ID d’un serveurdonné.

delete Supprime le point de jonction.

Syntaxe : delete <point_de_jonction>

list Affiche la liste de tous les points de jonction du serveur.

Syntaxe : list

show Affiche des informations détaillées concernant la jonction.

Syntaxe : show <point_de_jonction>

jmt load jmt clear La commande jmt load fournit à WebSEAL les données de latable de mappage des jonctions (jmt.conf) qui lui permet degérer le traitement des URL relatives au serveur générées defaçon dynamique.

La commande jmt clear supprime de WebSEAL les donnéesde la table de mappage des jonctions.

help Affiche la liste des commandes de jonction.

Syntaxe : help

help <commande> Affiche une aide détaillée sur une commande de jonctionspécifique.

exit Quitte l’utilitaire pdadmin.

Syntaxe : exit

Ces commandes, et les options associées, sont présentées dans les sectionssuivantes.

Annexe B. Référence des jonctions WebSEAL 255

Page 276: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Création d’une nouvelle jonction pour un serveur existantOpération : Créer un nouveau point de jonction et relier un serveur existant.

Syntaxe :create –t <type> –h<nom_hôte> [<options>]<point_de_jonction>

Type de jonction

–t <type> **Obligatoire**

Type de jonction, parmi tcp, ssl, tcpproxy, sslproxy,local.

Le port par défaut de –t tcp est 80. Le port par défautde –t ssl est 443.

Nom d’hôte

–h <nom_hôte> **Obligatoire**

Nom d’hôte DNS ou adresse IP du serveurd’arrière-plan destinataire.

Options

Authentification réciproque via SSL

–K <libellé_clé> WebSEAL utilise le certificat client pour s’authentifierauprès du serveur d’arrière-plan.

–B WebSEAL utilise les informations de l’en-tête BA pours’authentifier auprès du serveur d’arrière-plan. Lesoptions de filtrage –U, –W et –b sont requises.

–U <“nom_utilisateur”> Nom d’utilisateur WebSEAL. A spécifier avec –B pourenvoyer les informations d’en-tête BA au serveurd’arrière-plan.

–W <“mot_de_passe”> Mot de passe WebSEAL. A spécifier avec –B pourenvoyer les informations d’en-tête BA au serveurd’arrière-plan.

–D <“DN”> Spécifie le nom distinctif (DN) du certificat duserveur d’arrière-plan. Cette valeur, mappée avec leDN réel du certificat, renforce l’authentification.

Options de jonction proxy (requiert –t tcpproxy ou –t sslproxy)

–H <nom_hôte> Nom d’hôte DNS ou adresse IP du serveur proxy.

–P <port> Port TCP du serveur proxy.

Spécification d’informations d’en-tête BA

–b <valeur_BA> Définit la façon dont le serveur WebSEAL transmetles informations d’authentification BA au serveurd’arrière-plan. Valeurs possibles :

filter (par défaut), ignore, supply, gso

Options générales de jonction TCP et SSL

–c <types_id> Insère l’identité du client Access Manager dans lesen-têtes HTTP via la jonction. L’argument types_idpeut comprendre une combinaison quelconque detypes d’en-tête HTTP Access Manager : iv-user,iv-user-l, iv-groups, iv-creds, all.

256 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 277: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

–i Le serveur WebSEAL traite les adresses URL sansdistinction majuscules/minuscules.

–j Fournit une identification de jonction dans un cookiepour gérer les URL relatives au serveur, générées parscript.

–k Envoie un cookie de session au serveur de portaild’arrière-plan.

–p <port> Port TCP du serveur d’arrière-plan destinataire. Lavaleur par défaut est 80 pour les jonctions TCP ; 443pour les jonctions SSL.

–q <emplacement> Chemin relatif pour le script query_contents. Pardéfaut, Access Manager recherche query_contentsdans /cgi_bin/. Si ce répertoire ou le fichierquery_contents est différent, servez-vous de cetteoption pour indiquer à WebSEAL la nouvelle adresseURL du fichier.Obligatoire pour les serveurs Windowsd’arrière-plan.

–r Insère une adresse IP entrante dans l’en-tête HTTP viala jonction.

–s Indique que la jonction doit prendre en charge desapplications avec état. Par défaut, les jonctions ne sontpas avec état.

–T <ressource/groupe_ressources>

Nom de la ressource ou du groupe de ressourcesGSO. Obligatoire et utilisé uniquement avec l’option–b gso.

–u <UUID> Spécifie l’UUID d’un serveur d’arrière-plan connecté àWebSEAL via une jonction avec état (–s).

–v<nom_hôte_virtuel>[:<port>]

Nom d’hôte virtuel représenté sur le serveurd’arrière-plan. Cette option prend en charge uneconfiguration d’hôte virtuelle sur le serveurd’arrière-plan.

Vous spécifiez –v lorsque le serveur de jonctiond’arrière-plan attend un en-tête de nom d’hôte carvous effectuez une jonction avec une instancevirtuelle de ce serveur. La requête d’en-tête HTTP pardéfaut émanant du navigateur n’est pas informée quele serveur d’arrière-plan possède plusieurs noms etplusieurs serveurs virtuels. Vous devez configurerWebSEAL pour qu’il fournisse ces informationsd’en-tête supplémentaires dans les requêtes destinéesà un serveur d’arrière-plan configuré comme un hôtevirtuel.

–w Prise en charge du système de fichiers Win32.

Equité des jonctions

–l <valeur_pourcentage> Définit la limite logicielle de consommation des unitésd’exécution.

–L <valeur_pourcentage> Définit la limite matérielle de consommation desunités d’exécution.

Jonctions LTPA

–A Active et désactive les jonctions LTPA.

–F <“fichier_clés”> Emplacement du fichier de clés utilisé pour chiffrerles données de cookie LTPA.

Annexe B. Référence des jonctions WebSEAL 257

Page 278: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

–Z<“mot_de_passe_fichier_clés”>

Mot de passe du fichier de clés.

Jonctions SSL WebSEAL / WebSEAL

–C Authentification réciproque entre un serveurWebSEAL frontal et un serveur WebSEALd’arrière-plan via SSL. Exige le type –t ssl ou –tsslproxy.

Connexion unique à base de formulaires

–S <fichier_config> Emplacement du fichier de configuration desconnexions uniques à base de formulaires.

Options de jonction locale (à utiliser avec –t local)

–d <dir> Répertoire local de la jonction. **Obligatoire.**

–f Force le remplacement d’une jonction existante.

Point de jonction

Emplacement de l’espace de nom WebSEAL où créer la jonction.

Ajout d’un serveur supplémentaire à une jonction existanteOpération : Ajoute un serveur supplémentaire à un point de jonction existant.

Syntaxe :add –h <nom_hôte>[<options>] <point_de_jonction>

Nom d’hôte

–h <nom_hôte> **Obligatoire**

Nom d’hôte DNS ou adresse IP du serveurd’arrière-plan destinataire.

Options

Authentification réciproque via SSL

–D <“DN”> Spécifie le nom distinctif (DN) du certificat duserveur d’arrière-plan. Cette valeur, mappée avec leDN réel du certificat, renforce l’authentification.

Options de jonction proxy (requises avec –t tcpproxy et –t sslproxy)

–H <nom_hôte> Nom d’hôte DNS ou adresse IP du serveur proxy.

–P <port> Port TCP du serveur proxy.

Options de jonction TCP et SSL

–i Le serveur WebSEAL traite les adresses URL sansdistinction majuscules/minuscules.

–p <port> Port TCP du serveur d’arrière-plan tiers. La valeurpar défaut est 80 pour les jonctions TCP ; 443 pourles jonctions SSL.

–q <url> URL relative au script query_contents. AccessManager recherche query_contents dans /cgi_bin/. Sice répertoire est différent ou que le fichierquery_contents est renommé, servez-vous de cetteoption pour indiquer à WebSEAL la nouvelle adresseURL du fichier.

258 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 279: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

–u <UUID> Spécifie l’UUID d’un serveur d’arrière-plan connecté àWebSEAL via une jonction avec état (–s).

–v <nom_hôte_virt> Nom d’hôte virtuel représenté sur le serveurd’arrière-plan. Cette option prend en charge uneconfiguration d’hôte virtuelle sur le serveurd’arrière-plan.

Vous spécifiez –v lorsque le serveur de jonctiond’arrière-plan attend un en-tête de nom d’hôte carvous effectuez une jonction avec une instancevirtuelle de ce serveur. La requête d’en-tête HTTP pardéfaut émanant du navigateur n’est pas informée quele serveur d’arrière-plan possède plusieurs noms etplusieurs serveurs virtuels. Vous devez configurerWebSEAL pour qu’il fournisse ces informationsd’en-tête supplémentaires dans les requêtes destinéesà un serveur d’arrière-plan configuré comme un hôtevirtuel.

–w Prise en charge du système de fichiers Win32.

Point de jonction

Ajoute le serveur à ce point de jonction existant.

Annexe B. Référence des jonctions WebSEAL 259

Page 280: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

260 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 281: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Annexe C. Remarques

Le présent document contient des informations ou des références concernantcertains produits et services proposés aux Etats-Unis.

Il peut contenir des informations ou des références concernant certains produits,logiciels ou services IBM non annoncés dans d’autres pays. Pour plus de détails,référez-vous aux documents d’annonce disponibles dans votre pays, ouadressez-vous à votre partenaire commercial IBM. Toute référence à un produit,logiciel ou service IBM n’implique pas que seul ce produit, logiciel ou servicepuisse être utilisé. Tout autre élément fonctionnellement équivalent peut êtreutilisé, s’il n’enfreint aucun droit d’IBM. Il est de la responsabilité de l’utilisateurd’évaluer et de vérifier lui-même les installations et applications réalisées avec desproduits, logiciels ou services non expressément référencés par IBM.

IBM peut détenir des brevets ou des demandes de brevet couvrant les produitsmentionnés dans le présent document. La remise de ce document ne vous donneaucun droit de licence sur ces brevets ou demandes de brevet. Si vous désirezrecevoir des informations concernant l’acquisition de licences, veuillez en faire lademande par écrit à l’adresse suivante :

IBM EMEA Director of LicensingIBM Europe Middle-East AfricaTour DescartesLa Défense 52, avenue Gambetta92066 - Paris-La Défense CEDEXFrance

Pour le Canada, veuillez adresser votre courrier à :

IBM Director of Commercial RelationsIBM Canada Ltd.3600 Steeles Avenue EastMarkham, OntarioL3R 9Z7Canada

Les informations sur les licences concernant les produits utilisant un jeu decaractères double octet peuvent être obtenues par écrit à l’adresse suivante :

IBM World Trade Asia CorporationLicensing2-31 Roppongi 3-chomeMinato-kuTokyo 106Japon

Le paragraphe suivant ne s’applique pas au Royaume-Uni ou à tout autre paysdans lequel les dispositions qu’il contient sont incompatibles avec laréglementation locale : LE PRESENT DOCUMENT EST LIVRE EN L’ETAT. IBMDECLINE TOUTE RESPONSABILITE, EXPLICITE OU IMPLICITE, RELATIVEAUX INFORMATIONS QUI Y SONT CONTENUES, Y COMPRIS EN CE QUICONCERNE LES GARANTIES DE VALEUR MARCHANDE OU D’ADAPTATION

© Copyright IBM Corp. 1999, 2002 261

Page 282: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

A VOS BESOINS. Certaines juridictions n’autorisent pas l’exclusion des garantiesimplicites, auquel cas l’exclusion ci-dessus ne vous sera pas applicable.

Le présent document peut contenir des inexactitudes ou des coquilles. Il est mis àjour périodiquement. Chaque nouvelle édition inclut les mises à jour. IBM peutmodifier sans préavis les produits et logiciels décrits dans ce document.

Les références à des sites Web non IBM sont fournies à titre d’informationuniquement et n’impliquent en aucun cas une adhésion aux données qu’ilscontiennent. Les éléments figurant sur ces sites Web ne font pas partie deséléments du présent produit IBM et l’utilisation de ces sites relève de votre seuleresponsabilité.

IBM pourra utiliser ou diffuser, de toute manière qu’elle jugera appropriée et sansaucune obligation de sa part, tout ou partie des informations qui lui serontfournies.

Les licenciés souhaitant obtenir des informations permettant : (i) l’échange desdonnées entre des logiciels créés de façon indépendante et d’autres logiciels (dontcelui-ci), et (ii) l’utilisation mutuelle des données ainsi échangées, doivent adresserleur demande à :

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758USA

Ces informations peuvent être soumises à des conditions particulières, prévoyantnotamment le paiement d’une redevance.

Le logiciel sous licence décrit dans ce document et tous les éléments sous licencedisponibles s’y rapportant sont fournis par IBM conformément aux dispositions del’ICA, des Conditions internationales d’utilisation des logiciels IBM ou de toutautre accord équivalent.

Les données de performance indiquées dans ce document ont été déterminées dansun environnement contrôlé. Par conséquent, les résultats peuvent varier de manièresignificative selon l’environnement d’exploitation utilisé. Certaines mesuresévaluées sur des systèmes en cours de développement ne sont pas garanties surtous les systèmes disponibles. En outre, elles peuvent résulter d’extrapolations. Lesrésultats peuvent donc varier. Il incombe aux utilisateurs de ce document devérifier si ces données sont applicables à leur environnement d’exploitation.

Les informations concernant des produits non IBM ont été obtenues auprès desfournisseurs de ces produits, par l’intermédiaire d’annonces publiques ou viad’autres sources disponibles. IBM n’a pas testé ces produits et ne peut confirmerl’exactitude de leurs performances ni leur compatibilité. Elle ne peut recevoiraucune réclamation concernant des produits non IBM. Toute question concernantles performances de produits non IBM doit être adressée aux fournisseurs de cesproduits.

Toute instruction relative aux intentions d’IBM pour ses opérations à venir estsusceptible d’être modifiée ou annulée sans préavis, et doit être considéréeuniquement comme un objectif.

262 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 283: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Le présent document peut contenir des exemples de données et de rapports utiliséscouramment dans l’environnement professionnel. Ces exemples mentionnent desnoms fictifs de personnes, de sociétés, de marques ou de produits à des finsillustratives ou explicatives uniquement. Toute ressemblance avec des noms depersonnes, de sociétés ou des données réelles serait purement fortuite.

NOTICE DE COPYRIGHT :

Le présent logiciel contient des exemples de programmes d’application en langagesource destinés à illustrer les techniques de programmation sur différentesplateformes d’exploitation. Vous avez le droit de copier, de modifier et dedistribuer ces exemples de programmes sous quelque forme que ce soit et sanspaiement d’aucune redevance à IBM, à des fins de développement, d’utilisation, devente ou de distribution de programmes d’application conformes aux interfaces deprogrammation des plateformes pour lesquels ils ont été écrits ou aux interfaces deprogrammation IBM. Ces exemples de programmes n’ont pas été rigoureusementtestés dans toutes les conditions. Par conséquent, IBM ne peut garantirexpressément ou implicitement la fiabilité, la maintenabilité ou le fonctionnementde ces programmes. Vous avez le droit de copier, de modifier et de distribuer cesexemples de programmes sous quelque forme que ce soit et sans paiementd’aucune redevance à IBM, à des fins de développement, d’utilisation, de vente oude distribution de programmes d’application conformes aux interfaces deprogrammation IBM.

Toute copie totale ou partielle de ces programmes exemples et des oeuvres qui ensont dérivées doit comprendre une notice de copyright, libellée comme suit :

© (nom de votre entreprise) (année). Des segments de code sont dérivés desProgrammes exemples d’IBM Corp.© Copyright IBM Corp. _entrez l’année ou lesannées_. Tous droits réservés.

Annexe C. Remarques 263

Page 284: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

MarquesLes termes qui suivent sont des marques d’International Business MachinesCorporation aux Etats-Unis et/ou dans certains autres pays :

AIXDB2IBMIBM logoSecureWayTivolilogo TivoliWebSphere

Microsoft, Windows, Windows NT et le logo Windows sont des marques deMicrosoft Corporation aux Etats-Unis et/ou dans certains autres pays.

Java, ainsi que tous les marques et logos incluant Java, sont des marques de SunMicrosystems, Inc. aux Etats-Unis et/ou dans certains autres pays.

UNIX est une marque enregistrée de The Open Group aux Etats-Unis et/ou danscertains autres pays.

D’autres sociétés sont propriétaires des autres marques, noms de produits ou logosqui pourraient apparaître dans ce document.

264 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 285: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

Index

Aaccept-client-certs 131account-locked 37acct_locked.html 38adresse URL

modification des adresses URL des ressourcesd’arrière-plan 173

utilisation de cookies de jonction 178adresse URL dynamique

conversion 233dynurl-allow-large-posts 234exemple 236limitations des requêtes POST 234mappage d’objets de LCA 231méthodes GET et POST 233mise à jour, dynurl update 233request-body-max-read 234

adresses URL dynamiquescontrôle d’accès 230dynurl-map 231généralités 230résumé et remarques techniques 235

agent.log 44exemple 46format de journalisation d’événements 48

agents 44agents-file 44argument-stanza 211arrêt de WebSEAL 22attribut de jonction HTTP-Tag-Value 225attribut étendu su-admin 72attribut POP étendu document-cache-control 33attribut POP étendu reauth 139attributs étendus

dans les données d’autorisation 224document-cache-control (POP) 33HTTP-Tag-Value (jonction) 224HTTP-Tag-Value (junction) 227reauth (POP) 139

authentificationaccès authentifié aux ressources 12accès non authentifié aux ressources 12adresse IP 134authentification de base 126CDSSO 145certificat 129changement d’utilisateur 65communauté électronique 149configuration de plusieurs méthodes 124configuration par défaut 123connexion unique à base de formulaires 207en-tête HTTP 132explication du processus 111formulaires 127généralités 10généralités sur la configuration 122invite de connexion 124jeton 134méthodes prises en charge 112multiplexage d’agents proxy (MPA) 135nouvelle authentification 138, 141

authentification (suite)objectifs 11paramètres CDAS personnalisés 123paramètres locaux 123types de données de session pris en charge 112

authentification à facteurs multiples 104authentification avancée 99authentification CDSSO 145authentification de base

configuration 126authentification de la communauté électronique 149

chiffrement du jeton ″d’attestation″ 157configuration 158cookie de communauté électronique 156flux de processus 152fonctions 151jeton ″d’attestation″ 157requête et réponse ″d’attestation″ 156

authentification MPA 135authentification par adresse IP 134authentification par certificat 129authentification par en-tête HTTP 132authentification par formulaires 127

solution de connexion unique 207authentification par jeton 134authentification stength POP policy 105authtoken-lifetime 148

Bba-auth 126backicon 30basic-auth-realm 126basicauth-dummy-passwd 198bibliothèque partagée CDMF 145bibliothèque partagée libfailoverauthn 121

Ccache CRL, configuration 43

gsk-crl-cache-entry-lifetime 43gsk-crl-cache-size 43

cache de sessionconfiguration 114, 115délai d’expiration de durée de vie 115délai d’inactivité 116données d’autorisation WebSEAL 113GSKit (SSL) 113

cache de session GSKit (SSL) 113configuration 114

cache GSO, configurer 204cache LTPA, configurer 206cache-refresh-interval 54caractères codés UTF-8 76cdsso 123, 147cdsso-auth 147cdsso_key_gen 122, 148, 157cdssoauthn 147cert-cdas 123cert-ssl 123, 131

© Copyright IBM Corp. 1999, 2002 265

Page 286: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

certificatsgestion 39GSKit 39iKeyman 39types de fichier de la base de données de clés 40

cgi-timeout 28changement d’utilisateur 65

activation 67attribut étendu su-admin 72bibliothèque partagée CDAS 70bibliothèque partagée intégrée 69exclusion d’utilisateurs 69flux de processus 65groupe su-admins 65, 66groupe su-excluded 66impact sur les fonctionnalités WebSEAL 71méthode d’authentification 69méthodes d’authentification valides 68securitygroup 66

client-connect-timeout 27commande d’état pd_start 63commande net (Windows) 64commande pdweb 22, 63connectivité SSL 27connectivité TLS 27connexion 37

conditions d’invite 124connexion globale (GSO) 201connexion interdomaine

CDSSO 145communauté électronique 149

connexion unique-b filter 200-b gso 201-b ignore 200-b supply 198authentification par formulaires 207CDSSO 145communauté électronique 149concepts 197configurer le cache GSO 204connexion globale (GSO) 201LTPA (WebSphere) 205spécifier l’identité client dans les en-têtes BA 198

contrôle LRC 42cookie de communauté électronique 156cookies

jonction 178session 116, 184

cookies de jonction 178cookies de secours

activation 120activation des cookies dans les domaines 122chiffrement/déchiffrage des données de cookie 122configuration 119configuration de la durée de vie des cookies 122

cookies de session 116activation 117

cred-ext-attrs 123

Ddb-file 53déconnexion 37, 125délai d’expiration 115, 140, 143démarrage de WebSEAL 22directory-index 29

diricon 30disable-ssl-v2 27disable-ssl-v3 27disable-tls-v1 27doc-root 28données d’autorisation

attributs étendus 223, 227délai d’expiration de durée de vie 115délai d’inactivité 116généralités 13insertion de données dans des en-têtes HTTP 224insertion de l’ID de session utilisateur dans l’en-tête

HTTP 227données LDAP dans les en-têtes HTTP 223droits d’accès

insertion de données LDAP 223droits d’accès, dynamiques 223droits d’accès (dynamiques) 223droits d’accès dynamiques 223dynurl-allow-large-posts 234dynurl.conf 231dynurl-map 231dynurl update 233

Ee-community-name 159e-community-sso-auth 158ec-cookie-lifetime 160écoute de la notification de mise à jour 53emplacement de la base de données d’autorisation des

répliques 53emplacement des répliques de la base de données

d’autorisation 53en-tête 133en-tête Content-Length 177en-tête HOST, meilleures pratiques en matière de

jonctions 220en-tête HTTP

limitation de la taille 184PD-USER-SESSION-ID 228

en-tête PD_PORTAL 222en-tête PD-USER-SESSION-ID HTTP 228enable-failover-cookie-for-domain 122entrust-client 133error.log 48espace objets protégé 4

objet protégé 4objets de gestion 4objets définis par l’utilisateur 4objets Web 4paramètre server-name de WebSEAL 22ressource système 4

état de la sessionentre le client et les applications d’arrière-plan 226fin d’une session utilisateur 229fin de toutes les sessions utilisateurs 229gestion des ID de sessions utilisateurs 227

état de sessionactiver les cookies de session 117configuration de la mémoire cache des droits d’accès

WebSEAL 115configuration du cache d’ID de session GSKit SSL 114cookies de secours 119cookies de session 116gestion 113types de données d’ID de session valides 118

266 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 287: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

évolutivité 16serveurs d’arrière-plan répliqués 18serveurs frontaux répliqués 16

expressions régulièresliste 212pour adresses URL dynamiques 232pour les connexions uniques à base de formulaires 212

Ffailover-auth 120failover-cdsso 121failover-certificate 121failover-cookie-lifetime 122failover-cookies-keyfile 122failover-http-request 121failover-password 121failover-token-card 121fatal.log 48fichier d’acheminement 48fichier journal, WebSEAL 23filtrage

adresses URL absolues 176adresses URL relatives au serveur 176documents statiques 175en-tête Content-Length

X-Old-Content-Length 177filtrage des adresses URL standard pour WebSEAL 175filtrer les adresses URL absolues avec filtrage de

script 177meilleures pratiques pour les adresses URL absolues 220text/html 175text/vnd.wap.wml 175traitement des adresses URL dans les requêtes 178types MIME de documents 34

filtrage d’adresses URL absolues standard, meilleurespratiques 220

filtrage de documents 34filtrage des adresses URL

en-tête Content-Length 177filtrage de script pour chemins d’accès absolus 177règles de filtrage standard 175traitement des adresses URL dans les requêtes 178

fin d’une session utilisateur 229fin de toutes les sessions utilisateurs 229flush-time 45format combiné NCSA 47format de journal courant (request.log) 45format de journal HTTP courant 45forms-auth 127fsso.conf.template 210

Ggestion d’ID d’arrière-plan 226gestion des ID de sessions utilisateurs

tagvalue_user_session_id 227user-session-ids 227

gestionnaire de ressources 7gmt-time 45groupe su-admins 65, 66, 67, 69groupe su-excluded 66, 67, 69groupe webseal-mpa-servers 137, 138gsk-crl-cache-entry-lifetime 43gsk-crl-cache-size 43GSKit 39

GSKit (suite)cache CRL 43types de fichier 40

GSO 201configurer le cache GSO 204

gso-cache-enabled 204gso-cache-entry-idle-timeout 204gso-cache-lifetime 204gso-cache-size 204gso-resource 211

Hhelp 37help.html 38http 26http-headers-auth 132HTTP_IV_CREDS 182, 217, 219HTTP_IV_GROUPS 182, 217, 219HTTP_IV_REMOTE_ADDRESS 183HTTP_IV_USER 182, 217, 219HTTP_PD_USER_SESSION_ID 226HTTP_PD-USER-SESSION-ID 228http-port 26http-request 123, 133HTTP-Tag-Value junction attribute 227http-timeout (jonctions) 28httpauthn 133https 26https-port 26https-timeout (jonctions) 28

Iicônes de l’index de répertoires 30ID de session SSL 117identité de serveurs (HTTP), suppression 79identité de serveurs HTTP, suppression 79iKeyman 41

certificat de test WebSEAL 130généralités 42jonctions de type SSL 168jonctions SSL authentifiées de façon réciproque 169

inactive-timeout 116interrogation 53interrogation de la base de données d’autorisation 54intra-domain-key 157, 159invite de connexion

conditions 124ipaddr-auth 134is-master-authn-server 159iv-creds 182, 219iv-groups 182, 219iv-remote-address 183iv-user 182, 219ivweb_setup 61ivweb_uninst 63

Jjmt.conf 179jmt load 179jmt-map 179jonctions

-b filter 200-b gso 201

Index 267

Page 288: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

jonctions (suite)-b ignore 200-b supply 198adresses URL sans distinction de casse (-i) 185affectation d’unités d’exécution d’agents (-l) 56affectation d’unités d’exécution d’agents (-L) 56authentification par certificat 190authentifiées de façon réciproque (-D, -K, -B, -U, -W) 169certificat client (WebSEAL) (-K) 170certificat client WebSEAL (-K) 170connexion globale (GSO) 201connexion unique à base de formulaires (S) 214directives en matière de création 164envoyer un cookie de session au serveur de portail

(-k) 184évolutivité 16filtrage des adresses URL dans les réponses 175filtrer les adresses URL absolues avec filtrage de

script 177généralités 14, 163gérer des adresses URL relatives au serveur avec mappage

des jonctions 179gérer des URL relatives au serveur avec des cookies 178HTTP-Tag-Value attribute 227impact des options -b sur des jonctions authentifiées de

façon réciproque 171jonction proxy (-H, -P) 172LTPA (-A, -F, -Z) 205meilleures pratiques 220meilleures pratiques HOST en matière de jonctions

(-v) 220mise en correspondance (-D) des noms distinctifs

(DN) 170mise en oeuvre de droits d’accès 190modification des adresses URL des applications

d’arrière-plan 173monter plusieurs serveurs 190nom d’hôte virtuel (-v) 220nouvelle jonction forcée (-f) 29, 181option host (-h) 166option type (-t) 166options gso (-b gso, -T) 203options obligatoires 166pdadmin server task 165prise en charge d’une jonction avec état (-s, -u) 185query_contents 191référence de commande 253réponses HTTP/1.0 et 1.1 22s’authentifier avec l’en-tête BA (-B, -U, -W) 171spécifier l’identité client dans les en-têtes HTTP (-c) 182spécifier l’UUID d’arrière-plan (-u) 186spécifier les adresses IP dans les en-têtes HTTP (-r) 183systèmes de fichiers Windows (-w) 188table de mappage des jonctions 179traitement des adresses URL dans les requêtes 178WebSEAL / WebSEAL (-C) 173

jonctions authentifiées de façon réciproque 169jonctions avec état 185, 186jonctions WebSEAL, voir jonctions 163journalisation

HTTP (journalisation d’événements) 47HTTP par défaut 44

journalisation d’événementsjournalisation HTTP 47statistiques 88

journalisation HTTPpar défaut 44

journalisation HTTP (suite)utilisation de la journalisation d’événements 47

junction-db 163

LLCA 5ldapauthn 127, 128libcdssoauthn 147libhttpauthn 133libldapauthn 127, 128libsslauthn 131libsuauthn 69libtokenauthn 134limitation des tentatives de connexion 95limite maximale de la jonction 55liste de contrôle d’accès (LCA) 5listen-flags 53logcfg 47, 88login-form-action 211login.html 38, 128login-page 211login-page-stanza 210login_success.html 38logout.html 38LTPA (WebSphere) 205

configurer le cache LTPA 206configurer une jonction 205

ltpa-cache-enabled 206ltpa-cache-entry-idle-timeout 206ltpa-cache-entry-lifetime 206ltpa-cache-size 206LTPA WebSphere 205

Mmaster-authn-server 159master-http-port 158master-https-port 159max-entries 115max-size 45max-webseal-header-size 184meilleures pratiques

filtrage des adresses URL absolues 220fourniture d’informations d’en-tête HOST (-v) 220

mémoire cachedonnées d’autorisation WebSEAL 113GSKit (SSL) 113

mémoire cache d’un document 31règle POP document-cache-control 33vidage des mémoires cache 32

mémoire cache des droits d’accès 113configuration 115nombre maximal d’entrées 115présentation et structure 13

mémoire cache des sessionsprésentation et structure 13

mémoire cache des sessions/des droits d’accès WebSEALconfiguration 115généralités 113présentation et structure 13

messages 48error.log 48fatal.log 48fichier d’acheminement 48notice.log 48

268 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 289: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

messages (suite)warning.log 48

messages d’erreurHTTP 34macro pour HTTP 36mise en service 48

messages d’erreur HTTP 34prise en charge de macros 36

messages de mise en service 48error.log 48fatal.log 48fichier d’acheminement 48notice.log 48warning.log 48

méthode d’authentification, résumé 112méthode GET 233méthode POST 233

configuration de limites 234mgt-pages-root 37, 67mise en mémoire cache des requêtes 72mise en mémoire cache des requêtes côté serveur 72mise en mémoire cache des requêtes POST 72mises à jour et interrogation de la base de données

d’autorisation 53mpa 138multiplexage d’agents proxy (authentification) 135

Nnext-token 37nexttoken.html 38niveau de protection

hôte 52niveau par défaut 51règles POP 107réseau 52

notice.log 48nouvelle authentification

attribut POP étendu reauth 139paramètre reauth-for-inactive 143reauth-extend-lifetime 141, 144reauth-reset-lifetime 140, 143sur la base de l’inactivité de session 141sur la base de la stratégie de sécurité (POP) 138

Oobjet protégé 4objets de gestion 4objets définis par l’utilisateur 4objets Web 4outil de mise en oeuvre de règles 7

Ppages de gestion de comptes 37pages HTML de gestion des comptes

prise en charge de macros 38pages HTML personnalisées 37paramètres de délai d’expiration

cache de session GSKit SSL 114HTTP et HTTPS 27mémoire cache des sessions/des droits d’accès

WebSEAL 115passwd-cdas 123passwd-change 37

passwd-change-failure 37passwd-change-success 37passwd_exp.html 38passwd-expired 37passwd.html 38passwd-ldap 123, 127, 128passwd_rep.html 38pd.conf 224pdadmin server task

commande terminate all_sessions 229pdadmin server task (jonctions) 165PDWeb_config 58pdweb.debug (trace) 90PDWeb_unconfig 63persistent-con-timeout 27ping-time (jonctions) 28pkmscdsso 149pkmslogout 125pkmspasswd 125pkmsvouchfor 156, 160plusieurs instances WebSEAL

commandes de serveur start, stop, restart et status 63configuration sous UNIX 58configuration sous Windows 61déconfiguration 63généralités sur la configuration 58syntaxe des commandes pdadmin 166, 254

pool d’événementshttp 47http.agent 47http.clf 47http.cof 47http.ref 47

pool d’événements http 47pool d’événements http.agent 47pool d’événements http.clf 47pool d’événements http.cof (NCSA) 47pool d’événements http.ref 47POP 5prise en charge de macros

messages d’erreur HTTP 36pages HTML de gestion des comptes 38

programmation CGIprise en charge 217prise en charge de variables d’environnement WIN32 218

Qquery_contents 191

installation 191personnalisation 194sécurisation 195

query_contents.c 191query_contents.cfg 191query_contents.exe 191query_contents.html 191query_contents.sh 191

Rreauth-extend-lifetime 141, 144reauth-for-inactive 143reauth-reset-lifetime 140, 143referer.log 44

exemple 46format de journalisation d’événements 47

Index 269

Page 290: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

referers 44referers-file 44règle de LCA explicite 6règle de LCA héritée 6règle de renforcement de mot de passe 96règles d’objet protégé 5règles de LCA

caractères valides pour les noms de LCA 94définition 5explicite 6héritée 6spécifiques de WebSEAL 93

règles de LCA default-webseal 94règles de sécurité

identification des types de contenu 9niveaux de protection 9planification et mise en oeuvre 8

règles pdadmindisable-time-interval 95max-login-failures 95max-password-repeated-chars 96min-password-alphas 96min-password-length 96min-password-non-alphas 96password-spaces 96

règles POPattribut étendu document-cache-control 33attribut étendu reauth 139authentification basée sur réseau 105définition 5niveau de protection 107renforcement d’authentification (authentification

avancée) 99REMOTE_USER 217répertoire racine, installation WebSEAL 21répertoire racine des documents

modifier l’emplacement 29répertoire racine du serveur 25réplication de serveurs frontaux WebSEAL 57réponses HTTP/1.1 22request-body-max-read 75, 234request.log 44

exemple 46format de journalisation d’événements 47

request-max-cache 74requests 44requests-file 44requête et réponse d’attestation 156resend-webseal-cookies 117ressource système 4

Sscript-filter 177scripts inter-sites

prévention de la vulnérabilité 77strophe illegal-url-substrings 78

securitygroup 66, 67, 69server-log 23server-name 22, 57server-root 25, 67serveur frontal WebSEAL

répliquer 57service d’autorisation 8service d’individualisation

configuration de WebSEAL 222exemple 222

service d’individualisation (suite)généralités 221

session utilisateur 227ssl-id-sessions 117ssl-keyfile 42ssl-keyfile-label 42ssl-keyfile-pwd 42ssl-keyfile-stash 42ssl-ldap-server 42ssl-ldap-server-port 42ssl-ldap-user 42ssl-ldap-user-password 42ssl-max-entries 115ssl-qop-mgmt 51ssl-v2-timeout 114ssl-v3-timeout 114sslauthn 131statistiques 79

activation (stats on) 80activation à l’aide de la journalisation d’événements 88affichage (stats get) 82affichage (stats show) 81commandes stats 79composants 82désactivation (stats off) 81liste (stats list) 82paramètre logcfg 88paramètre stats 88pdweb.authn 82pdweb.authz 83pdweb.doccache 86pdweb.http 83pdweb.https 84pdweb.jct.# 87pdweb.jmt 85pdweb.sescache 85pdweb.threads 85réinitialisation (stats reset) 82syntaxe de la commande stats 79types d’activités 82

statistiques pdweb.authn 82statistiques pdweb.authz 83statistiques pdweb.doccache 86statistiques pdweb.http 83statistiques pdweb.https 84statistiques pdweb.jct.# 87statistiques pdweb.jmt 85statistiques pdweb.sescache 85statistiques pdweb.threads 85stats 88stats, commandes 79stepup-login 37, 102stepuplogin.html 38, 102strophe acnt-mgt 37, 67strophe authentication-levels 99, 105strophe authentication-mechanisms 69strophe aznapi-configuration 47, 53, 88strophe cdsso-peers 148strophe cgi-environment-variables 218strophe cgi-types 30strophe content-caches 31strophe filter-content-types 34strophe filter-schemes 34strophe filter-url 176strophe forms-sso-login-pages 210strophe illegal-url-substrings 78strophe inter-domain-keys 157, 160

270 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 291: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

strophe junction 55strophe ldap-ext-cred-tags 224, 225strophe logging 23strophe ltpa-cache 206strophe portal-map 222strophe script-filtering 177strophe ssl-qop-mgmt-default 51strophe ssl-qop-mgmt-hosts 52strophe ssl-qop-mgmt-networks 52suauthn 69support d’application, arrière-plan 219support d’application d’arrière-plan 219support d’application serveur 219suppress-server-identity 79switch-user 67

Ttable de mappage des jonctions 179tagvalue_user_session_id 227tcp-port 53TLS (Transport Layer Security (TLS) 27token-auth 134token-cdas 123, 134token-login 37tokenauthn 134tokenlogin.html 38type, MIME 34type de données d’ID de session 118types de données de session 112types de fichier de la base de données de clés 40

Uudp-port 53unités d’exécution d’agents

affectation globale 55affectation jonction par jonction 56gestion 54jonctions 55limite maximale de la jonction 55WebSEAL 54

unknownicon 30URL

à propos des chemins d’accès absolus 175à propos des chemins d’accès relatifs 175à propos des chemins d’accès relatifs au serveur 175filtrage des options 175gestion d’UTF-8 76présentation des types de chemins d’accès 175utilisation de la table de mappage des jonctions 179

use-same-session 117user-session-ids 227utf8-url-support-enabled 76utilisateurs non authentifiés, contrôle 108utilitaire de trace 89

composant pdweb.debug 90trace list 90trace set 89trace show 90

Vvaleur de code 223, 227variable d’environnement WIN32, prise en charge 218vf-token-lifetime 160

vf-url 160vidage des mémoires cache 32

Wwarning.log 48Web Portal Manager 7WebSEAL

configuration de plusieurs instances 58dans l’espace objets protégé 22démarrage et arrêt du serveur 22fichier journal 23généralités 1répertoire racine d’installation 21répertoire racine de l’arborescence de documents 28répertoire racine du serveur 25réponses HTTP/1.1 22server-name 22statistiques 79webseald.conf configuration file 23

webseal-cert-keyfile 41webseal-cert-keyfile-label 41, 130, 190webseal-cert-keyfile-pwd 41webseal-cert-keyfile-stash 41webseald.conf

emplacement 23généralités 23référence 239

worker-thread-hard-limit 55worker-thread-soft-limit 55worker-threads 54, 55

Index 271

Page 292: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

272 IBM Tivoli Access Manager - Guide d’administration WebSEAL

Page 293: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00
Page 294: IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/fr... · 2005. 4. 15. · IBM Tivoli Access Manager Guide d’administration WebSEAL Version 39. GC11-1908-00

GC11-1908-00