Tivoli SecureWay Policy Director WebSEAL - Guide d ...publib.boulder.ibm.com/tividd/td/SW_30/GC32-0684... · Microsoft, Windows, Windows NT et le logo Windows sont des marques de

Tivoli SecureWay Policy DirectorWebSEALGuide d’administrationVersion 3.8

Tivoli SecureWay Policy DirectorWebSEALGuide d’administrationVersion 3.8

Tivoli SecureWay Policy Director WebSEAL - Guide d’administrationDeuxième édition - novembre 2001

Réf. US : GC32-0684-01

Notice de copyright© Copyright IBM France 2001. Tous droits réservés.

© Copyright 2001 Tivoli Systems Inc., filiale d’IBM Corporation, y compris cettedocumentation et tout logiciel associé. Tous droits réservés. Ne peut être utilisé quedans le cadre d’un contrat de licence logiciel de Tivoli Systems ou d’un contrat delicence logiciel d’IBM comportant un addendum relatif aux produits Tivoli. Aucunepartie de cette publication ne doit être reproduite, transmise, transcrite, conservée dansun système d’archivage ou convertie en un quelconque langage machine, sous quelqueforme ou quelque moyen que ce soit, électronique, mécanique, magnétique, optique,chimique, manuel ou autre, sans autorisation écrite antérieure de Tivoli Systems. TivoliSystems vous accorde des droits limités vous autorisant à imprimer ou à effectuerd’autres reproductions de toute documentation informatique pour votre propreutilisation, dans la mesure où ces reproductions comportent la mention de copyright deTivoli Systems. Nul autre droit sous copyright n’est accordé sans autorisation écriteantérieure de Tivoli Systems.Le présent document est livré″en l’état″. IBM et Tivoli Systems déclinent touteresponsabilité, expresse ou implicite, relative aux informations qui y sont contenues, ycompris en ce qui concerne les garanties de qualité marchande ou d’adaptation à vosbesoins.

Marques

Les termes qui suivent sont des marques de Tivoli Systems ou d’International BusinessMachines Corporation dans certains pays : IBM, le logo IBM logo, Tivoli, le logoTivoli logo, AIX, Cross-Site, NetView, OS/2, Planet Tivoli, RS/6000, Tivoli Certified,Tivoli Enterprise, Tivoli Enterprise Console, Tivoli Ready et TME.

Microsoft, Windows, Windows NT et le logo Windows sont des marques de MicrosoftCorporation dans certains pays.

UNIX est une marque enregistrée de The Open Group dans certains pays.

Java et toutes les marques incluant Java sont des marques de Sun Microsystems, Inc.dans certains pays.

RemarquesLe présent document peut contenir des informations ou des références concernantcertains produits, logiciels ou services Tivoli Systems ou IBM non annoncés dans cepays. Cela ne signifie pas que Tivoli Systems ou IBM ait l’intention de les y annoncer.Toute référence à un produit, logiciel ou service Tivoli Systems ou IBM n’implique pasque seul ce produit, logiciel ou service puisse être utilisé. Sous réserve de toutepropriété intellectuelle en vigueur chez Tivoli Systems ou IBM ou de tout autre droitpouvant être légalement protégé, tout produit, programme ou service fonctionnellementéquivalent peut remplacer un produit, un programme ou un service auquel il est faitréférence. Il est de la responsabilité de l’utilisateur d’évaluer et de vérifier lui-mêmeles installations et applications réalisées avec des produits, logiciels ou services, nonexpressément référencés par Tivoli Systems ou IBM.Tivoli Systems ou IBM peut détenir des brevets ou des demandes de brevets couvrantles produits mentionnés dans le présent document. La remise de ce document ne vousdonne aucun droit de licence sur ces brevets ou demandes de brevets. Si vous désirezrecevoir des informations concernant l’acquisition de licences, veuillez en faire lademande par écrit à l’adresse suivante : IBM EMEA Director of Licensing, IBMEurope Middle-East Africa, Tour Descartes, 92066 Paris-La Défense Cedex 50.

Pour le Canada, veuillez adresser votre courrier à :

IBM Director of Commercial RelationsIBM Canada Ltd.3600 Steeles Avenue EastMarkham, OntarioL3R 9Z7Canada

iiiTivoli SecureWay Policy Director WebSEAL - Guide d’administration

Pour plus de détails, pour toute demande d’ordre technique, ou pour obtenir desexemplaires de documents IBM, référez-vous aux documents d’annonce disponiblesdans votre pays, ou adressez-vous à votre partenaire commercial.

Vous pouvez également consulter les serveurs Internet suivants :

¶ http://www.fr.ibm.com (serveur IBM en France)

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

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

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

iv Version 3.8

http://www.fr.ibm.com

http://www.can.ibm.com

http://www.ibm.com

Table des matières

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

Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiA qui s’adresse ce guide ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

Contenu de ce guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxii

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

Autres documentations Policy Director. . . . . . . . . . . . . . . . . . . . . . . . . . .xxiv

Accès en ligne aux publications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv

Commande de documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxvi

Commentaires sur les publications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxvi

Comment prendre contact avec le service client. . . . . . . . . . . . . . . . . . . .xxvi

Chapitre 1. Généralités sur WebSEAL . . . . . . . . . . . . . . . . . . . . 1Protection de l’espace Web avec WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . 2

Identification des types de contenu et des niveaux de protection. . . . . . . 4

Planification et mise en oeuvre des règles de sécurité. . . . . . . . . . . . . . . 5

Explication de l’authentification WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . 6

Objectifs de l’authentification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Explication de l’acquisition des données d’autorisation. . . . . . . . . . . . . . . . . . 9

Certificat EPAC (Extended Privilege Attribute Certificate). . . . . . . . . . 10

Explication des jonctions WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Jonctions WebSEAL et évolutivité de site Web. . . . . . . . . . . . . . . . . . . 14

Chapitre 2. Configuration du serveur WebSEAL . . . . . . . 19Informations génériques sur le serveur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Présentation du fichier de configuration webseald.conf. . . . . . . . . . . . . 20

Répertoire racine de l’installation WebSEAL. . . . . . . . . . . . . . . . . . . . 21

vTivoli SecureWay Policy Director WebSEAL - Guide d’administration

Répertoire racine du serveur WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . 22

Démarrage et arrêt de WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Configuration des paramètres de communication. . . . . . . . . . . . . . . . . . . . . 23

Configuration de WebSEAL pour des requêtes HTTP. . . . . . . . . . . . . . 23

Configuration de WebSEAL pour les requêtes HTTPS. . . . . . . . . . . . . 24

Restriction des connexions à partir de versions SSL spécifiques. . . . . . 24

Configuration des unités d’exécution des agents HTTP et HTTPS. . . . 25

Paramètres de délai d’expiration pour les communicationsHTTP/HTTPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Autres paramètres de délai d’expiration du serveur WebSEAL. . . . . . . 27

Gestion de l’espace Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Répertoire racine de l’arborescence des documents Web. . . . . . . . . . . . 28

Configuration de l’indexation des répertoires. . . . . . . . . . . . . . . . . . . . 30

Windows : Conventions de dénomination de fichiers pour lesprogrammes CGI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Configuration de la mémoire cache d’un document Web. . . . . . . . . . . 33

Configuration des messages d’erreur HTTP. . . . . . . . . . . . . . . . . . . . . . . . . 36

Prise en charge des macros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Gestion de pages HTML personnalisées. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Valeurs et paramètres de page personnalisée. . . . . . . . . . . . . . . . . . . . . 41

Descriptions de pages HTML personnalisées. . . . . . . . . . . . . . . . . . . . 42

Gestion des certificats côté client et côté serveur. . . . . . . . . . . . . . . . . . . . . 43

Explication des types de fichier de la base de données de clés GSKit 44

Configuration des paramètres de la base de données de clés pourWebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Utilisation de l’utilitaire de gestion de certificat iKeyman. . . . . . . . . . . 49

Configuration du contrôle LRC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Configuration d’un niveau de protection par défaut. . . . . . . . . . . . . . . . . . . 50

Configuration du niveau de protection pour les réseaux et les hôtesindividuels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

vi Version 3.8

Configuration des interrogations et des mises à jour de la base de donnéesd’autorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Configuration de l’écoute des notifications de mise à jour. . . . . . . . . . 53

Configuration de l’interrogation de la base de données d’autorisation 54

Réplication de serveurs frontaux WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . 54

Configuration de la journalisation HTTP standard. . . . . . . . . . . . . . . . . . . . 55

Activation et désactivation de la journalisation HTTP. . . . . . . . . . . . . . 56

Spécification du type d’horodatage. . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Spécification des seuils de renouvellement pour un autre fichierjournal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Spécification de la fréquence de vidage des mémoires tampon defichier journal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Configuration de la longueur du contenu enregistré dans request.log 58

Format de journal HTTP courant (pour request.log). . . . . . . . . . . . . . . 59

Affichage du fichier request.log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Affichage du fichier agent.log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Affichage du fichier referer.log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Chapitre 3. Règles de sécurité WebSEAL . . . . . . . . . . . . . . . 63Règles de LCA spécifiques de WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . 63

/WebSEAL/<hôte> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

/WebSEAL/<hôte>/<fichier> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Droits d’accès LCA WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Règles de LCA WebSEAL par défaut. . . . . . . . . . . . . . . . . . . . . . . . . . 65

Limitation des tentatives de connexion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Syntaxe de commande. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Règle de renforcement de mot de passe. . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Règle de renforcement de mot de passe définie par l’utilitaire pdadmin 68

Syntaxe de commande. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Exemples de mots de passe valides et invalides. . . . . . . . . . . . . . . . . . 71

viiTivoli SecureWay Policy Director WebSEAL - Guide d’administration

Valeurs globales et spécifiques d’un utilisateur. . . . . . . . . . . . . . . . . . . 71

Règles POP de renforcement d’authentification (authentification avancée) 72

Configuration des niveaux pour une augmentation du niveaud’authentification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Activation de l’authentification renforcée. . . . . . . . . . . . . . . . . . . . . . . 74

Formulaire de connexion avancée. . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Algorithme d’authentification renforcée. . . . . . . . . . . . . . . . . . . . . . . . 78

Notes et limites de l’authentification renforcée. . . . . . . . . . . . . . . . . . . 78

Règles POP d’authentification basée sur réseau. . . . . . . . . . . . . . . . . . . . . . 79

Configuration des niveaux d’authentification. . . . . . . . . . . . . . . . . . . . 80

Spécification des adresses IP et des plages. . . . . . . . . . . . . . . . . . . . . . 81

Désactivation du renforcement d’authentification par adresse IP. . . . . . 82

Algorithme d’authentification basée sur réseau. . . . . . . . . . . . . . . . . . . 83

Notes et limites de l’authentification basée sur réseau. . . . . . . . . . . . . 83

Niveau de protection des règles POP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Gestion des utilisateurs non authentifiés (HTTP / HTTPS). . . . . . . . . . . . . . 84

Traitement d’une requête émanant d’un client anonyme. . . . . . . . . . . . 85

Connexion utilisateur forcée. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Applications de l’accès HTTPS non authentifié. . . . . . . . . . . . . . . . . . 85

Contrôle d’utilisateurs non authentifiés avec des règles de LCA/POP 86

Chapitre 4. Authentification WebSEAL . . . . . . . . . . . . . . . . . . 87Explication du processus d’authentification. . . . . . . . . . . . . . . . . . . . . . . . . 88

Types de données de session pris en charge. . . . . . . . . . . . . . . . . . . . . 89

Méthodes d’authentification prises en charge. . . . . . . . . . . . . . . . . . . . 89

Références à des informations de configuration détaillées. . . . . . . . . . . 90

Gestion des états de session. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Caches de session GSKit et WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . 92

Configuration de la mémoire cache des droits d’accès WebSEAL. . . . . 93

Configuration de la mémoire cache d’ID de session SSL GSKit. . . . . . 95

viii Version 3.8

Gestion de l’état avec des cookies de session. . . . . . . . . . . . . . . . . . . . 96

Identification des types de données d’ID de session valides. . . . . . . . 100

Configuration des cookies de secours. . . . . . . . . . . . . . . . . . . . . . . . . 101

Généralités sur la configuration de l’authentification. . . . . . . . . . . . . . . . . . 104

Paramètres d’authentification locale. . . . . . . . . . . . . . . . . . . . . . . . . . 105

Paramètres d’authentification CDAS personnalisée externe. . . . . . . . . 106

Configuration par défaut pour l’authentification WebSEAL. . . . . . . . . 106

Configuration de plusieurs méthodes d’authentification. . . . . . . . . . . . 107

Invite de connexion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Commandes de déconnexion et de modification de mot de passe. . . . 108

Configuration de l’authentification de base. . . . . . . . . . . . . . . . . . . . . . . . . 110

Activation et désactivation de l’authentification de base. . . . . . . . . . . 110

Définition du nom de cellule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Configuration de la méthode d’authentification de base. . . . . . . . . . . . 111

Conditions de configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Configuration de l’authentification par formulaires. . . . . . . . . . . . . . . . . . . 112

Activation et désactivation de l’authentification par formulaires. . . . . 113

Configuration de la méthode d’authentification par formulaires. . . . . . 113


Personnalisation des formulaires de réponse HTML. . . . . . . . . . . . . . 114

Configuration de l’authentification par certificat côté client. . . . . . . . . . . . 115

Contexte : Authentification réciproque via des certificats. . . . . . . . . . 115

Certificat de test WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Activation et désactivation de l’authentification par certificat. . . . . . . 118

Configuration de la méthode d’authentification par certificat. . . . . . . . 119


Configuration de l’authentification par en-tête HTTP. . . . . . . . . . . . . . . . . 120

Activation et désactivation de l’authentification par en-tête HTTP 120

Spécification des types d’en-tête. . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

ixTivoli SecureWay Policy Director WebSEAL - Guide d’administration

Configuration du mécanisme d’authentification par en-tête HTTP. . . . 121


Configuration de l’authentification par adresse IP. . . . . . . . . . . . . . . . . . . . 122

Activation et désactivation de l’authentification par adresse IP. . . . . . 122

Configuration de la méthode d’authentification par adresse IP. . . . . . 123

Configuration de l’authentification par jeton. . . . . . . . . . . . . . . . . . . . . . . . 123

Activation et désactivation de l’authentification par jeton. . . . . . . . . . 123

Configuration de la méthode d’authentification par jeton. . . . . . . . . . 124

Prise en charge des agents MPA (Multiplexing Proxy Agents). . . . . . . . . . 125

Méthodes d’authentification et type de données de session valides 126

Flux du processus d’authentification pour des agents MPA etplusieurs clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Activation et désactivation de l’authentification MPA. . . . . . . . . . . . . 129

Création d’un compte utilisateur pour l’agent MPA. . . . . . . . . . . . . . 129

Ajout du compte MPA au groupe webseal-mpa-servers. . . . . . . . . . . . 130

Limites de l’authentification MPA. . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Chapitre 5. Solutions de connexion interdomaine 131Configuration de l’authentification CDSSO. . . . . . . . . . . . . . . . . . . . . . . . 131

Intégration d’une bibliothèque partagée CDMF personnalisée. . . . . . . 132

Flux du processus d’authentification pour CDSSO avec CDMF. . . . . 132

Activation et désactivation de l’authentification CDSSO. . . . . . . . . . . 134

Configuration de la méthode d’authentification CDSSO. . . . . . . . . . . 135

Chiffrement des données d’authentification du jeton. . . . . . . . . . . . . . 136

Configuration de l’horodate du jeton. . . . . . . . . . . . . . . . . . . . . . . . . 137

Expression des liens HTML CDSSO. . . . . . . . . . . . . . . . . . . . . . . . . 137

Protection du jeton d’authentification. . . . . . . . . . . . . . . . . . . . . . . . . 137

Configuration de la connexion unique de la communauté électronique. . . . 138

Fonctions et conditions requises de la communauté électronique. . . . . 141

Flux de processus de la communauté électronique. . . . . . . . . . . . . . . 142

x Version 3.8

Explication du cookie de communauté électronique. . . . . . . . . . . . . . 149

Explication de la requête et de la réponse “d’attestation”. . . . . . . . . . 150

Explication du jeton “d’attestation”. . . . . . . . . . . . . . . . . . . . . . . . . . 151

Chiffrement du jeton “d’attestation”. . . . . . . . . . . . . . . . . . . . . . . . . . 152

Configuration d’une communauté électronique. . . . . . . . . . . . . . . . . . 153

Chapitre 6. Jonctions WebSEAL . . . . . . . . . . . . . . . . . . . . . . . 159Généralités sur les jonctions WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Emplacement et format de la base de données des jonctions. . . . . . . . 160

Exécution d’un contrôle d’accès allégé : Résumé. . . . . . . . . . . . . . . . 161

Exécution d’un contrôle d’accès renforcé : Résumé. . . . . . . . . . . . . . 161

Directives en matière de création de jonctions WebSEAL. . . . . . . . . . 161

WebSEAL ne prend en charge qu’HTTP 1.0 sur les jonctions. . . . . . . 162

Références supplémentaires pour les jonctions WebSEAL. . . . . . . . . . 162

Utilisation de la commande “pdadmin server task” pour créer des jonctions 163

Configuration d’une jonction WebSEAL de base. . . . . . . . . . . . . . . . . . . . 164

Jonctions de type TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Jonctions de type SSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Jonctions SSL authentifiées de façon réciproque. . . . . . . . . . . . . . . . . . . . . 168

WebSEAL valide le certificat du serveur d’arrière-plan. . . . . . . . . . . . 169

Mise en correspondance des noms distinctifs (DN). . . . . . . . . . . . . . . 169

WebSEAL s’authentifie avec le certificat client. . . . . . . . . . . . . . . . . 170

WebSEAL s’authentifie avec l’en-tête BA. . . . . . . . . . . . . . . . . . . . . 171

Gestion des informations d’identité du client en cas de jonctions. . . . 171

Création de jonctions proxy TCP et SSL. . . . . . . . . . . . . . . . . . . . . . . . . . 173

Jonctions WebSEAL / WebSEAL via SSL. . . . . . . . . . . . . . . . . . . . . . . . . 174

Options de jonction supplémentaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Nouvelle jonction forcée (–f). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Spécification de l’identité du client dans les en-têtes HTTP (–c). . . . . 177

xiTivoli SecureWay Policy Director WebSEAL - Guide d’administration

Spécification des adresses IP client dans les en-têtes HTTP (–r). . . . . 179

Transmission de cookies de session à des serveurs de portail reliéspar jonction (–k). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Prise en charge d’adresses URL sans distinction de casse (–i). . . . . . . 181

Traitement d’adresses URL à partir de scripts et d’applications côtéclient (–j) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Gestion d’adresses URL relatives au serveur avec mappage desjonctions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Prise en charge d’une jonction avec état (–s, –u). . . . . . . . . . . . . . . . 189

Spécification d’UUID de serveur d’arrière-plan pour des jonctionsavec état (–u). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Etablissement de jonctions avec des systèmes de fichiers Windows(–w) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Remarques techniques sur les jonctions WebSEAL :. . . . . . . . . . . . . . . . . 195

Montage de plusieurs serveurs sur la même jonction. . . . . . . . . . . . . 196

Filtrage d’URL statiques à partir de serveurs reliés par jonction. . . . . 196

Exceptions à la mise en oeuvre de droits d’accès dans des jonctions 198

Authentification par certificat dans des jonctions. . . . . . . . . . . . . . . . 198

Utilisation de query_contents avec des serveurs tiers. . . . . . . . . . . . . . . . . 199

Installation de query_contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Installation de query_contents sur des serveurs UNIX tiers. . . . . . . . . 200

Installation de serveurs Win32 tiers. . . . . . . . . . . . . . . . . . . . . . . . . . 201

Personnalisation de query_contents. . . . . . . . . . . . . . . . . . . . . . . . . . 202

Sécurisation de query_contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Chapitre 7. Solutions Web à connexion unique(SSO). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Configuration d’en-têtes BA pour des solutions SSO. . . . . . . . . . . . . . . . . 205

Concepts de connexion unique (Single Sign-On - SSO). . . . . . . . . . . 206

Spécification de l’identité client dans les en-têtes BA. . . . . . . . . . . . . 207

Spécification de l’identité client et d’un mot de passe générique. . . . . 208

xii Version 3.8

Acheminement des informations d’en-tête BA client existantes. . . . . . 210

Suppression des informations d’en-tête BA client. . . . . . . . . . . . . . . . 211

Spécification de noms d’utilisateur et de mots de passe à partir deGSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Utilisation d’une connexion globale (GSO). . . . . . . . . . . . . . . . . . . . . . . . 213

Mappage des informations d’authentification. . . . . . . . . . . . . . . . . . . 215

Configuration d’une jonction WebSEAL activée GSO. . . . . . . . . . . . . 215

Configuration du cache GSO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Connexion unique à IBM WebSphere (LTPA). . . . . . . . . . . . . . . . . . . . . . . 218

Configuration d’une jonction LTPA. . . . . . . . . . . . . . . . . . . . . . . . . . 219

Configuration du cache LTPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Remarques techniques sur les connexions uniques LTPA. . . . . . . . . . 222

Chapitre 8. Intégration d’application . . . . . . . . . . . . . . . . . . . 223Prise en charge de la programmation CGI. . . . . . . . . . . . . . . . . . . . . . . . . 224

Windows : Prise en charge des variables d’environnement WIN32 225

Prise en charge des applications d’arrière-plan côté serveur. . . . . . . . . . . . 226

Activation des droits d’accès dynamiques. . . . . . . . . . . . . . . . . . . . . . . . . . 228

Création de droits d’accès à partir de données LDAP. . . . . . . . . . . . . 228

Création d’un service d’individualisation personnalisé. . . . . . . . . . . . . . . . 233

Configuration de WebSEAL pour un service d’individualisation. . . . . 234

Exemple de service d’individualisation. . . . . . . . . . . . . . . . . . . . . . . . 234

Ajout d’un contrôle d’accès à des adresses URL dynamiques. . . . . . . . . . . 235

Composants d’une adresse URL dynamique. . . . . . . . . . . . . . . . . . . . 235

Mappage d’objets de LCA à des adresses URL dynamiques. . . . . . . . 236

Mise à jour de WebSEAL pour des adresses URL dynamiques. . . . . . 239

Conversion d’adresses URL dynamiques dans l’espace objet. . . . . . . 240

Configuration de limites sur les requêtes POST. . . . . . . . . . . . . . . . . 241

Résumé et remarques techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

xiiiTivoli SecureWay Policy Director WebSEAL - Guide d’administration

Exemple d’adresse URL dynamique : Travel Kingdom. . . . . . . . . . . . . . . 245

Présentation de l’application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Présentation de l’interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Règles de sécurité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Protection des clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Contrôle d’accès. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

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

Annexe B. Référence des jonctions WebSEAL . . . . . . . . 269Utilisation de la commande “pdadmin server task” pour créer des jonctions 270

Commandes de jonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Création d’une nouvelle jonction pour un serveur existant. . . . . . . . . . . . . 272

Ajout d’un serveur supplémentaire à une jonction existante. . . . . . . . . . . . 276

Annexe C. Gestion de certificats avec iKeyman . . . . . . 279Lancement de l’utilitaire iKeyman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Ouverture de la base de données de clés WebSEAL par défaut. . . . . . . . . . 282

Création d’une nouvelle base de données de clés. . . . . . . . . . . . . . . . . . . . 284

Création d’un nouveau certificat numérique d’auto-signature. . . . . . . . . . . 287

Ajout d’un nouveau certificat de CA racine. . . . . . . . . . . . . . . . . . . . . . . . 290

Suppression d’un certificat de CA racine. . . . . . . . . . . . . . . . . . . . . . . . . . 291

Copie de certificats entre des bases de données. . . . . . . . . . . . . . . . . . . . . 291

Extraction d’un certificat dans un fichier - Ajout d’un certificat àpartir d’un fichier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Importation d’un certificat directement d’une base de données. . . . . . 293

Exportation d’un certificat directement dans une base de données 294

Demande d’un certificat de serveur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

xiv Version 3.8

Réception d’un certificat numérique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Suppression d’un certificat numérique. . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

Attribution d’un nouveau certificat par défaut. . . . . . . . . . . . . . . . . . . . . . . 298

Modification du mot de passe de connexion à la base de données. . . . . . . . 300

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

xvTivoli SecureWay Policy Director WebSEAL - Guide d’administration

xvi Version 3.8

Avis aux lecteurs canadiens

Le présent document a été traduit en France. Voici les principalesdifférences et particularités dont vous devez tenir compte.

Illustrations

Les illustrations sont fournies à titre d’exemple. Certaines peuventcontenir des données propres à la France.

Terminologie

La terminologie des titres IBM peut différer d’un pays à l’autre.Reportez-vous au tableau ci-dessous, au besoin.

IBM France IBM Canada

ingénieur commercial représentant

agence commerciale succursale

ingénieur technico-commercial informaticien

inspecteur technicien du matériel

Claviers

Les lettres sont disposées différemment : le clavier français est detype AZERTY, et le clavier français-canadien de type QWERTY.

OS/2 et Windows - Paramètres canadiens

Au Canada, on utilise :

¶ les pages de codes 850 (multilingue) et 863 (français-canadien),

¶ le code pays 002,

¶ le code clavier CF.

xviiTivoli SecureWay Policy Director WebSEAL - Guide d’administration

Nomenclature

Les touches présentées dans le tableau d’équivalence suivant sontlibellées différemment selon qu’il s’agit du clavier de la France, duclavier du Canada ou du clavier des États-Unis. Reportez-vous à cetableau pour faire correspondre les touches françaises figurant dansle présent document aux touches de votre clavier.

Brevets

Il est possible qu’IBM détienne des brevets ou qu’elle ait déposé desdemandes de brevets portant sur certains sujets abordés dans cedocument. Le fait qu’IBM vous fournisse le présent document nesignifie pas qu’elle vous accorde un permis d’utilisation de cesbrevets. Vous pouvez envoyer, par écrit, vos demandes derenseignements relatives aux permis d’utilisation au directeur généraldes relations commerciales d’IBM, 3600 Steeles Avenue East,Markham, Ontario, L3R 9Z7.

xviii Version 3.8

Assistance téléphonique

Si vous avez besoin d’assistance ou si vous voulez commander dumatériel, des logiciels et des publications IBM, contactez IBM directau 1 800 465-1234.

xixTivoli SecureWay Policy Director WebSEAL - Guide d’administration

xx Version 3.8

Avant-propos

Bienvenue dans le documentTivoli SecureWay Policy DirectorWebSEAL - Guide d’administration.

Tivoli SecureWay Policy Director WebSEAL est le gestionnaire desécurité de ressources Policy Director pour les ressources basées surle Web. WebSEAL est un serveur Web à hautes performances et àplusieurs unités d’exécution, appliquant des règles de sécuritérenforcées à l’espace objet Web sous sa protection. WebSEAL peutfournir des solutions à connexion unique et intégrer des ressourcesdu serveur d’application Web d’arrière-plan dans ses règles desécurité.

Ce guide d’administration contient un ensemble complet deprocédures et d’informations de référence qui peuvent vous aider àgérer les ressources de votre domaine Web sécurisé. Il vous apporteégalement des informations intéressantes en matière de contexte etde concepts, sur la grande gamme des fonctionnalités WebSEAL.

A qui s’adresse ce guide ?Le public visé par ce guide représente :

¶ Administrateurs de sécurité

¶ Administrateurs de l’installation et du déploiement système

¶ Administrateurs système de réseau

¶ Architectes IT

¶ Développeurs d’application

xxiTivoli SecureWay Policy Director WebSEAL - Guide d’administration

Contenu de ce guide¶ Chapitre 1 : Généralités sur WebSEAL

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

¶ Chapitre 2 : Configuration du serveur WebSEAL

Ce chapitre sert de référence technique pour les grandes tâchesde configuration de WebSEAL : gestion de l’espace Web,paramètres de dépassement du délai d’attente, gestion descertificats, gestion des utilisateurs non autorisés, et règlesrelatives à POP et aux listes de contrôle d’accès spécifiques deWebSEAL.

¶ Chapitre 3 : 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èglesPOP et LCA, qualité de la protection, renforcement des règlesd’authentification, règles d’authentification basées sur le réseau,règles de tentatives limitées de connexion et règles derenforcement du mot de passe.

¶ Chapitre 4 : Authentification WebSEAL

Ce chapitre contient des procédures techniques détaillées sur laconfiguration de WebSEAL pour gérer toute une série deméthodes d’authentification : nom d’utilisateur et mot de passe,certificats côté client, passcode de jeton SecurID et donnéesd’en-tête HTTP spéciales.

¶ Chapitre 5 : Solutions de connexion interdomaine

Ce chapitre traite des solutions de connexion interdomaine pourle côté externe d’une configuration proxy WebSEAL (entre leclient et le serveur WebSEAL).

¶ Chapitre 6 : Jonctions WebSEAL

Ce chapitre sert de référence technique exhaustive à l’installationet à l’utilisation des jonctions WebSEAL.

xxii Version 3.8

¶ Chapitre 7 : Solutions de connexion unique Web

Ce chapitre traite des solutions de connexion unique (SSO) pourle côté interne d’une configuration proxy WebSEAL (entre leserveur WebSEAL et le serveur d’applications d’arrière-plan reliépar jonction).

¶ Chapitre 8 : Intégration d’application

Ce chapitre explore diverses capacités de WebSEAL permettantd’intégrer les fonctionnalités d’une application de tiers.

¶ Annexe A : Référence du fichier webseald.conf

¶ Annexe B : Référence des jonctions WebSEAL

¶ Annexe C : Gestion des certificats avec iKeyman

Conventions utilisées dans ce guideLe présent guide applique plusieurs conventions de présentation pourles actions et les termes spéciaux. Ces conventions sont lessuivantes :

Gras Les commandes, mots clés, noms de fichiers, rôlesd’autorisation, adresses URL ou autres informations àutiliser littéralement apparaissent en caractèresgras.

Italique Les variables et les valeurs que vous devez indiquerapparaissent en caractèresitaliques. Les titres despublications, ainsi que les termes et phrases que l’auteur avoulu mettre en évidence apparaissent également encaractèresitaliques.

Monospace Les exemples de code, les lignes de commande, les sortiesd’écran, les noms de fichier et de répertoire ainsi que lesmessages système apparaissent dans la police de caractèresmonospace.

xxiiiTivoli SecureWay Policy Director WebSEAL - Guide d’administration

Autres documentations Policy DirectorLe tableau suivant récapitule les documentations sur Policy Directordisponibles sur le site d’assistance de Tivoli SecureWay Policy :

Documentations techniques sur Tivoli SecureWay Policy Director

Guides d’installation

Tivoli SecureWay Policy Director Base - Guide d’installation

Tivoli SecureWay Policy Director WebSEAL - Guide d’installation

Guides d’administration

Tivoli SecureWay Policy Director Base - Guide d’administration

Tivoli SecureWay Policy Director WebSEAL - Guide d’administration (leprésent document)

Tivoli SecureWay Policy Director Plug-in for Edge Server - Guided’administration

Tivoli SecureWay Policy Director Web Portal Manager - Guided’administration

Guides de référence pour développeurs

Tivoli SecureWay Policy Director Authorization ADK DeveloperReference

Tivoli SecureWay Policy Director Authorization API Java WrappersDeveloper Reference

Tivoli SecureWay Policy Director Administration API DeveloperReference

Tivoli SecureWay Policy Director WebSEAL Developer Reference

Documentations complémentaires

Tivoli SecureWay Policy Director - Notes d’édition

Tivoli SecureWay Policy Director - Optimisation des performances

Tivoli SecureWay Policy Director Capacity Planning Guide

xxiv Version 3.8

Accès en ligne aux publicationsLe site Web de support client Tivoli (http://www.tivoli.com/support/)propose des liens permettant d’accéder aux documentationssuivantes :

¶ Informations techniques, y compris des notes d’édition, desguides d’installation, de configuration et d’administration ainsique des guides de référence pour les développeurs.

¶ Foires aux questions (FAQ)

¶ Informations sur le téléchargement des logiciels

Vous pouvez accéder au guide des services de maintenance(Customer Support Handbook) à l’adresse :http://www.tivoli.com/support/getting/.

Pour accéder à l’index des publications Tivoli en ligne, consultez lesite http://www.tivoli.com/support/documents/. Cliquez surIndexprincipal pour rechercher les pages de support relatives à un produitparticulier.

Pour rechercher une documentation technique Policy Director enfonction de la version d’un produit, consultez le site :https://www.tivoli.com/secure/support/Prodman/html/AB.html#Security

Pour certains produits, la documentation est disponible aux formatsPDF et HTML. Des documents traduits sont également disponiblespour certains produits.

Pour accéder à la plupart de la documentation, vous devez entrer unID et un mot de passe. Vous pouvez obtenir un ID à utiliser sur lesite Web d’assistance en vous connectant au sitehttp://www.tivoli.com/support/getting/ .

Pour plus de détails sur l’obtention d’une assistance et d’unedocumentation technique Tivoli, les distributeurs doivent seconnecter au sitehttp://www.tivoli.com/support/smb/index.html.

xxvTivoli SecureWay Policy Director WebSEAL - Guide d’administration

Les partenaires commerciaux doivent se reporter à la section«Commande de documentation» pour obtenir plus d’informations surl’obtention de la documentation technique Tivoli.

Commande de documentationVous pouvez commander en ligne des publications Tivoli en vousconnectant au sitehttp://www.fr.ibm.com (ou en appelant le numéro1-800-426-4968, pour le Canada).

Commentaires sur les publicationsVos commentaires sur les produits et la documentation Tivoli noussont très utiles, car ils permettent d’améliorer la qualité de nosproduits. Vous pouvez nous faire parvenir vos commentaires etsuggestions sur ce guide en procédant de l’une des manièressuivantes :

¶ Envoyez un courrier électronique à[email protected].

¶ Remplissez le formulaire de commentaire client à l’adressehttp://www.tivoli.com/support/survey/.

Comment prendre contact avec le service clientLe guide des services de maintenance (Tivoli Customer SupportHandbook) à l’adresse :

http://www.tivoli.com/support/handbook/

contient des informations sur tous les aspects du support clientTivoli, notamment sur les points suivants :

¶ Enregistrement et éligibilité

¶ Comment prendre contact avec le support, en fonction de lagravité de l’incident

¶ Numéros de téléphone et adresses électroniques, en fonction dupays

¶ Informations à préparer avant de prendre contact avec le support

xxvi Version 3.8

Généralités sur WebSEAL

Tivoli SecureWay Policy Director WebSEAL est un serveur Web àhautes performances et à plusieurs unités d’exécution, appliquant desrègles de sécurité renforcées à l’espace objet Web sous sa protection.Il peut fournir des solutions à connexion unique et intégrer desressources du serveur d’applications Web d’arrière-plan dans sesrègles de sécurité.

Le présent chapitre vous présente les principales fonctionnalités duserveur WebSEAL.

Index des rubriques :

¶ «Protection de l’espace Web avec WebSEAL» à la page 2

¶ «Explication de l’authentification WebSEAL» à la page 6

¶ «Explication de l’acquisition des données d’autorisation» à lapage 9

¶ «Explication des jonctions WebSEAL» à la page 11

1

1Tivoli SecureWay Policy Director WebSEAL - Guide d’administration

1.G

énéralitéssur

WebS

EA

L

Protection de l’espace Web avec WebSEALTivoli SecureWay Policy Director WebSEAL est le gestionnaire desécurité de ressources Policy Director pour les ressources basées surle Web.

WebSEAL est un serveur Web à hautes performances et à plusieursunité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’applicationsWeb d’arrière-plan dans ses règles de sécurité.

WebSEAL comporte un certain nombre de fonctionnalités :

¶ Prise en charge de plusieurs méthodes d’authentification

Les architectures, tant intégrées que complétées par des modules,autorisent une certaine souplesse, dans la mesure où ellesacceptent toute une variété de méthodes d’authentification.

¶ Prise en charge des requêtes HTTP et HTTPS

¶ Intégration et protection des ressources du serveur d’arrière-plangrâce à la technologie de jonction WebSEAL

¶ Gestion d’un contrôle d’accès renforcé pour l’espace Web duserveur local et d’arrière-plan

Sont notamment prises en charge les ressources suivantes :URL, expressions régulières basées sur une adresse URL,programmes CGI, fichiers HTML, servlets Java et fichiers declasse Java.

¶ Fonctionnement en tant que proxy Web inversé

WebSEAL apparaît comme un serveur Web pour les clients etcomme un navigateur Web pour les serveurs reliés au réseau parune jonction qu’il protège.

¶ Capacités de connexion unique

2 Version 3.8

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


1.G

énéralitéssur

WebS

EA

L

Identification des types de contenu et des niveaux deprotection

En tant qu’administrateur de sécurité de votre espace Web, vousdevez identifier de façon correcte les types de contenu disponiblespour les divers types d’utilisateurs. Si certains contenus doivent êtrehautement protégés et n’être placés qu’à la disposition de certainsutilisateurs spécifiques, d’autres contenus sont destinés à l’ensembledu public. Chaque scénario de sécurité répond donc à diversesexigences sécuritaires et exige donc une configuration WebSEALparticulière.

Il vous incombe de :

¶ Connaître votre contenu Web

¶ Identifier les types d’utilisateurs devant accéder à ce contenu

¶ Comprendre les points forts et les faiblesses des options de laconfiguration WebSEAL proposée pour protéger ce contenu

La protection d’un contenu Web peut correspondre à l’une des troiscatégories suivantes :

1. Contenu public – l’accès ne requiert aucune protection

¶ Accès des clients non authentifiés via HTTP

¶ Données d’autorisation non authentifiées utilisées pour lecontrôle d’accès aux ressources

¶ Configuration WebSEAL basique requise

2. Contenu public – l’accès requiert une certaine confidentialité(chiffrement)

¶ Accès des clients non authentifiés via HTTPS

¶ Chiffrement requis pour protéger les données confidentiellesrequises par le serveur d’applications (comme les numéros decarte de crédit et les informations de compte utilisateur)

¶ Données d’autorisation non authentifiées utilisées pour lecontrôle d’accès aux ressources

¶ La configuration WebSEAL doit stipuler la confidentialité

4 Version 3.8

3. Contenu privé – authentification obligatoire pour l’accès

¶ Accès des clients authentifiés via HTTP ou HTTPS

¶ L’administrateur détermine si le chiffrement est nécessaire ounon

¶ Données d’autorisation authentifiées utilisées pour le contrôled’accès aux ressources : le compte des clients doit êtredéfini dans le registre d’utilisateurs

¶ La configuration WebSEAL est complexe et toutes lesoptions doivent être envisagées avec attention pour quel’impact des règles de sécurité puisse être déterminé

Planification et mise en oeuvre des règles de sécuritéDes règles de sécurité d’entreprise identifient :

1. Les ressources Web exigeant une protection

2. Le niveau de protection

Policy Director utilise une représentation virtuelle de ces ressourcesWeb, appelée l’espace objet protégé. Ce dernier contient des objetsqui représentent les ressources physiques réelles de votre réseau.

Vous mettez en oeuvre les règles de sécurité en appliquant lesmécanismes de sécurité appropriés aux objets nécessitant uneprotection.

Les mécanismes de sécurité peuvent être les suivants :

¶ Stratégies de liste de contrôle d’accès (LCA)

Les stratégies de LCA identifient les types d’utilisateurssusceptibles de se voir accorder l’accès et indiquent lesopérations autorisées au niveau de l’objet.

¶ Stratégies d’objet protégé (POP)

Une stratégie d’objet protégé (POP) spécifie des conditionssupplémentaires d’accès à l’objet protégé, par exemple laconfidentialité, l’intégrité, l’audit et l’accès en temps réel.


1.G

énéralitéssur

WebS

EA

L

¶ Attributs étendus

Les attributs étendus sont des valeurs supplémentaires placéessur un objet, une LCA ou un POP, qui peuvent être lues etinterprétées par des applications provenant de tiers (comme unservice d’autorisation externe).

Le composant central de Policy Director est le service d’autorisation— qui accorde ou refuse l’accès aux objets protégés (ressources) surla base des données d’autorisation de l’utilisateur et des contrôlesd’accès définis sur les objets.

Pour réussir la mise en oeuvre des règles de sécurité, vous devezorganiser de façon logique les différents types de contenu (commedécrit à la section «Planification et mise en oeuvre des règles desécurité» à la page 5) et appliquer les stratégies de LCA et de POPappropriées. La gestion du contrôle d’accès peut se révéler une tâcheextrêmement complexe et est grandement facilitée par unecatégorisation soignée des types de contenu.

Explication de l’authentification WebSEALL’authentification est la méthode qui permet d’identifier unprocessus ou une entité individuel essayant de se connecter à undomaine sécurisé. Lorsque le serveur et le client exigent tous lesdeux une authentification, l’échange porte le nom d’authentificationréciproque.

Client WebSEAL

Qui êtes-vous ?

Qui êtes-vous ?

Figure 2. Authentification réciproque

6 Version 3.8

WebSEAL peut apporter un niveau élevé de sécurité dans undomaine sécurisé en demandant à chaque client de prouver sonidentité. Lorsque l’accès à chaque ressource d’un domaine sécuriséest contrôlé par WebSEAL, le fait que WebSEAL requiert uneauthentification et une autorisation peut fournir une sécurité duréseau très complète.

En architecture de sécurité, l’authentification est distincte del’autorisation. L’autorisation (ou droit d’accès) détermine si unutilisateur authentifié a le droit d’exécuter une opération sur uneressource donnée. L’authentification vérifie que l’individu est biencelui qu’il prétend être, mais n’indique rien en ce qui concerne lacapacité à exécuter des opérations sur une ressource.

Les conditions suivantes s’appliquent à l’authentificationWebSEAL :

¶ WebSEAL prend en charge un ensemble standard de méthodesd’authentification.

Vous pouvez le personnaliser pour lui faire accepter d’autresméthodes d’authentification.

¶ Le processus WebSEAL est indépendant de la méthoded’authentification.

¶ WebSEAL ne requiert qu’une identité de client. A partir de cetteidentité, WebSEAL obtient des données d’autorisationauthentifiées (ou non authentifiées) pouvant être utilisées par leservice d’autorisation pour accorder ou refuser l’accès auxressources.

Cette approche souple de l’authentification permet de baser les règlesde sécurité sur les besoins de l’entreprise et non sur la topologiephysique du réseau.


1.G

énéralitéssur

WebS

EA

L

Objectifs de l’authentificationBien que WebSEAL soit indépendant du processus d’authentification,il a besoin de ses résultats : l’identité du client. Le processusd’authentification se décompose comme suit

1. La méthode d’authentification aboutit à l’identité d’un client

L’authentification client n’est réussie que si l’utilisateur disposed’un compte défini dans le registre d’utilisateurs Policy Director.Sinon, l’utilisateur est désigné comme non authentifié.

2. WebSEAL se sert de l’identité pour acquérir des donnéesd’autorisation pour ce client

WebSEAL fait correspondre l’identité du client authentifié avecun utilisateur Policy Director enregistré. Il se procure ensuite lesdonnées d’autorisation appropriées à cet utilisateur (acquisitiondes données d’autorisation).

Les données d’autorisation incluent le nom de l’utilisateur et lesgroupes éventuels auxquels appartient l’utilisateur.

Si un utilisateur est anonyme, WebSEAL établit des donnéesd’autorisation non authentifiées.

Ces données d’autorisation sont à la disposition du serviced’autorisation, qui accorde ou refuse l’accès aux objets demandésdans l’espace objet protégé par WebSEAL.

Les données d’autorisation peuvent être utilisées par tout servicePolicy Director demandant des informations sur le client. Ellespermettent à Policy Director d’exécuter en toute sécurité unemultitude de services, comme une autorisation, un audit et unedélégation.

Pour plus d’informations sur la prise en charge de méthodesd’authentification spécifiques, reportez-vous à la section«Authentification WebSEAL» à la page 87.

8 Version 3.8

Explication de l’acquisition des donnéesd’autorisation

L’un des premiers objectifs du processus d’authentification estd’obtenir des informations d’autorisation d’accès, relatives àl’utilisateur du poste client. Les données d’autorisation del’utilisateur font partie des éléments clés dans la participation audomaine sécurisé.

Policy Director opère la distinction entre l’authentification del’utilisateur et l’acquisition des données d’autorisation. L’identitéd’un utilisateur reste constante, alors que les données d’autorisation,qui définissent les groupes ou rôles auxquels se rattache unutilisateur, varient. Les données d’autorisation, spécifiques d’uncontexte, peuvent changer dans le temps. Par exemple, à lapromotion d’une personne, les données d’autorisation doivent refléterle nouveau niveau de responsabilité.

Le processus d’authentification aboutit à des informations surl’identité d’un utilisateur, propres à la méthode. Ces informationssont vérifiées par rapport aux informations de compte utilisateur quise trouvent dans le registre d’utilisateurs Policy Director (LDAP pardéfaut). WebSEAL fait correspondre le nom d’utilisateur et lesinformations de groupe avec une représentation de l’ensemble dudomaine et un format communs, connus sous le nom de certificatEPAC (Extended Privilege Attribute Certificate).

Informations d'identit éspécifiques d'une méthode

EPACnom d'utilisateur/mot de passecode de jetonen-tête http personnalisécertificat X.509

Donn ées d'autorisationPolicy Director

Figure 3. Mise en correspondance des informations d’identité avec les donnéesd’autorisation


1.G

énéralitéssur

WebS

EA

L

Les informations d’identité spécifiques d’une méthode, comme lesmots de passe, les jetons et les certificats, représentent les propriétésd’identité physiques de l’utilisateur. Elles peuvent servir à établir unesession sécurisée avec le serveur.

Les données d’autorisation résultantes, qui représentent les droitsd’accès d’un utilisateur sur le domaine sécurisé, décriventl’utilisateur dans un contexte spécifique et ne sont valides que pourla durée de la session.

Les données d’autorisation Policy Director contiennent l’identité del’utilisateur et les groupes dont ce dernier est membre.

Certificat EPAC (Extended Privilege AttributeCertificate)

Les données d’autorisation sont utilisées par tout service PolicyDirector ayant besoin d’informations sur le client.

Par exemple, le service d’autorisation utilise les donnéesd’autorisation pour déterminer si un utilisateur a le droit d’exécutercertaines opérations sur une ressource protégée du domaine sécurisé.

Les certificats EPAC contiennent les UUID (Unique UniversalIdentifier) dont Policy Director a besoin pour utiliser les LCA.

Policy Director utilise des données d’autorisation pour d’autresservices, comme :

¶ Service d’audit

¶ Fonctionnalités de délégation dans des jonctions WebSEAL

Les champs EPAC suivants sont adaptés à Policy Director :

Attribut Description

ID de domaine sécurisé Identificateur du domaine sécurisé d’accueil duprincipal

Principal UUID UUID du principal

Group UUIDs UUID(s) des groupes auxquels appartient leprincipal

10 Version 3.8

Explication des jonctions WebSEALPolicy Director fournit des services d’authentification, d’autorisationet de gestion pour un réseau. Dans un réseau basé sur le Web, cesservices sont fournis de façon optimale par un ou plusieurs serveursWebSEAL frontaux qui intègrent et protègent les ressources et lesapplications Web se trouvant sur des serveurs d’arrière-plan.

La liaison entre un serveur WebSEAL et un serveur d’applicationsWeb d’arrière-plan est appelée jonction, ou jonction WebSEAL. Unejonction WebSEAL est une connexion TCP/IP entre un serveurWebSEAL frontal et un serveur d’arrière-plan.

Le serveur d’arrière-plan est un autre serveur WebSEAL ou, plussouvent, un serveur d’applications Web tiers. L’espace Web duserveur d’arrière-plan est “connecté” au serveur WebSEAL au niveaud’un point de jonction (montage) désigné de façon explicite dansl’espace de nom WebSEAL.

ClientServeur

d'applicationsWeb

Jonction

TCP ou SSL

WebSEAL/

/mnt

Domaine sécurisé

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


1.G

énéralitéssur

WebS

EA

L

Une jonction permet à WebSEAL d’assurer des services deprotection pour le compte du serveur d’arrière-plan. WebSEAL peutexécuter des contrôles d’authentification et d’autorisation sur toutesles requêtes avant de transmettre celles-ci au serveur d’arrière-plan.Si ce dernier exige un contrôle d’accès renforcé sur ses objets, vousdevez exécuter d’autres étapes de configuration pour décrire l’espaceWeb tiers au service de sécurité Policy Director (voir la section«Utilisation de query_contents avec des serveurs tiers» à lapage 199).

Les jonctions fournissent un environnement évolutif et sécurisé, quiassure des capacités d’équilibrage de charge, de haute disponibilité etde gestion de l’état — fonctions qui sont toutes exécutées de façontransparente pour les clients. En tant qu’administrateur, vous pouveztirer profit de cette gestion centralisée de l’espace de nom.

Les jonctions WebSEAL apportent la valeur ajoutée d’unecombinaison logique de l’espace Web d’un serveur d’arrière-planavec l’espace Web du serveur WebSEAL. Les jonctions entre desserveurs travaillant en collaboration aboutissent à un espace Webunique, unifié et distribué qui fonctionne en douceur et entransparence pour les utilisateurs.

Le client n’a jamais besoin de connaître l’emplacement physiqued’une ressource Web. WebSEAL convertit les adresses URL logiquesdans les adresses physiques attendues par le serveur d’arrière-plan.Les objets Web peuvent être déplacés d’un serveur à l’autre sans quel’accès du client à ces objets en soit affecté.

Pour l’administrateur système, un espace Web unifié simplifie lagestion de toutes les ressources. Les autres avantages administratifsincluent l’évolutivité, l’équilibrage de charge et la hautedisponibilité.

12 Version 3.8

La plupart des serveurs Web du commerce ne sont pas à même dedéfinir un espace objet Web logique. Leur contrôle d’accès estconnecté à la structure de répertoires et de fichiers physiques. Lesjonctions WebSEAL peuvent définir de façon transparente un espaceobjet qui reflète la structure organisationnelle plutôt que la machinephysique et la structure des répertoires que l’on trouve généralementsur les serveurs Web standard.

/

Espace Web WebSEAL

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

/point de jonction

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


1.G

énéralitéssur

WebS

EA

L

Les jonctions WebSEAL vous permettent également de créer dessolutions à connexion unique. Une configuration à connexion uniquepermet à un utilisateur d’accéder à une ressource, quel que soitl’emplacement de cette dernière, uniquement à partir de la connexioninitiale. Toute autre exigence de connexion provenant des serveursd’arrière-plan est traitée de façon transparente pour l’utilisateur.

Les jonctions WebSEAL constituent un outil important d’évolutivitéde votre site Web. Elles vous permettent de répondre à des demandesen augmentation sur un site Web, en rattachant des serveurssupplémentaires.

Jonctions WebSEAL et évolutivité de site WebLes jonctions WebSEAL servent à créer un site Web évolutif. Au furet à mesure que les demandes augmentent au niveau du site Web, ilest plus facile d’ajouter d’autres serveurs pour développer lescapacités du site.

Il est possible d’ajouter des serveurs supplémentaires pour les raisonssuivantes :

¶ Pour développer un site en y rajoutant du contenu

¶ Pour dupliquer le contenu existant en vue d’un équilibrage decharge, d’une fonction de secours et d’une haute disponibilité

Serveurs frontaux WebSEAL répliquésLa prise en charge de la jonction pour les serveurs d’arrière-plancommence avec au moins un serveur frontal WebSEAL. Les serveursfrontaux WebSEAL répliqués dotent le site d’un équilibrage decharge pendant les périodes de forte demande. Le mécanismed’é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 desecours (si le serveur tombe en panne pour une raison ou une autre,les autres serveurs de réplique continuent à fournir l’accès au site).Un bon équilibrage de charge combiné à une capacité de fonction desecours aboutissent à une haute disponibilité pour les utilisateurs dusite.

14 Version 3.8

Lorsque vous répliquez des serveurs frontaux WebSEAL, chaqueserveur doit contenir une copie exacte de l’espace Web et de la basede données de jonction.

Les informations de compte pour l’authentification se trouvent dansun registre d’utilisateurs indépendant des serveurs frontaux.

Prise en charge des serveurs d’arrière-planLe contenu d’un site Web peut être pris en charge par le serveurWebSEAL lui-même et/ou par des serveurs d’arrière-plan. Le supportde la jonction WebSEAL par les serveurs d’arrière-plan vous permetde faire évoluer le site Web en y ajoutant du contenu et desressources.

Client SSL Client SSL

Serveur WebSEALprincipal

Internet

Répliquedu serveur WebSEAL

Mécanismed’équilibrage de charge

Figure 6. Serveurs frontaux WebSEAL répliqués


1.G

énéralitéssur

WebS

EA

L

Chaque serveur d’arrière-plan unique doit être relié au réseau auniveau d’un point de jonction séparé (montage). Au fur et à mesureque la demande d’un contenu supplémentaire devient plus forte, unplus grand nombre de serveurs peut être ajouté par des jonctions. Cescénario apporte une solution pour les réseaux dont l’investissementexistant dans des serveurs Web tiers est déjà lourd.

Le graphique suivant illustre la façon dont les jonctions fournissentun espace objet unifié et logique. Transparent pour l’utilisateur, cetespace Web permet une gestion centralisée.

Client SSL


Internet


Serveur tiers/engineering

Client SSL

Serveur tiers/sales

Mécanisme d’équilibragede charge

Figure 7. Liaison de serveurs d’arrière-plan par jonction

16 Version 3.8

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

Serveurs d’arrière-plan répliquésPour étendre les fonctions d’évolutivité à une configuration avec desserveurs d’arrière-plan, vous pouvez utiliser la réplication deserveurs d’arrière-plan. Comme dans le cas des serveurs frontauxrépliqués, les serveurs d’arrière-plan répliqués doivent contenir desespaces Web qui constituent le reflet les uns des autres.

WebSEAL effectue un équilibrage de charge entre les serveursrépliqués à l’aide d’un algorithme d’ordonnancement déterminant leserveur le “moins occupé”. Cet algorithme dirige chaque nouvellerequête vers le serveur comportant le nombre de connexions en coursle plus faible.

WebSEAL déclenche également correctement la fonction de secourslorsqu’un serveur est en panne et commence à réutiliser le serveurlorsqu’il est redémarré.

Arborescence de l’objet Web

/Jonction Engineering Jonction Sales

Figure 8. Espace Web unifié


1.G

énéralitéssur

WebS

EA

L

Si l’application d’arrière-plan exige que son état soit maintenupendant plusieurs pages, des jonctions avec conservation de l’étatpeuvent être utilisées pour garantir que chaque session renvoie aumême serveur d’arrière-plan.

Client SSL


Internet


Client SSL

Répliquesdu serveur Engineering

Répliquesdu serveur Sales

Serveursrépliquésfrontaux


Figure 9. Serveurs d’arrière-plan répliqués

18 Version 3.8

Configuration du serveurWebSEAL

Ce chapitre contient des informations sur les tâches génériquesd’administration et de configuration à exécuter pour personnaliser leserveur WebSEAL en fonction de votre réseau.


¶ «Informations génériques sur le serveur» à la page 20

¶ «Configuration des paramètres de communication» à la page 23

¶ «Gestion de l’espace Web» à la page 28

¶ «Configuration des messages d’erreur HTTP» à la page 36

¶ «Gestion de pages HTML personnalisées» à la page 40

¶ «Gestion des certificats côté client et côté serveur» à la page 43

¶ «Configuration d’un niveau de protection par défaut» à la page50

¶ «Configuration des interrogations et des mises à jour de la basede données d’autorisation» à la page 52

¶ «Réplication de serveurs frontaux WebSEAL» à la page 54

¶ «Configuration de la journalisation HTTP standard» à la page 55

2


2.C

onfigurationdu

serveurW

ebSE

AL

Informations génériques sur le serveurLes sections ci-après contiennent des informations génériques sur leserveur WebSEAL :

¶ «Présentation du fichier de configuration webseald.conf» à lapage 20

¶ «Répertoire racine de l’installation WebSEAL» à la page 21

¶ «Répertoire racine du serveur WebSEAL» à la page 22

¶ «Démarrage et arrêt de WebSEAL» à la page 22

Présentation du fichier de configurationwebseald.conf

Vous pouvez personnaliser le fonctionnement de WebSEAL enconfigurant les paramètres qui se trouvent dans le fichier deconfigurationwebseald.conf. Ce fichier se situe dans le répertoiresuivant :

UNIX :/opt/pdweb/etc/

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

Le tableau suivant récapitule les sections et les strophes :

Sections Strophes

WEBSEAL GENERAL [server]

LDAP [ldap]

SSL [ssl]

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

20 Version 3.8

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][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 la section «Références du fichier webseald.conf» à la page 251.

Remarque : Chaque fois que vous modifiez le fichierwebseald.conf, vous devez redémarrer WebSEALmanuellement pour valider les modifications. Voir lasection «Démarrage et arrêt de WebSEAL» à la page22.

Répertoire racine de l’installation WebSEALLes fichiers programme de WebSEAL sont installés dans lerépertoire racine suivant :

UNIX :/opt/pdweb/

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


2.C

onfigurationdu

serveurW

ebSE

AL

Vous pouvez configurer ce chemin dans une installation PolicyDirector pour Windows, mais vous ne pouvez pas le configurer dansles installations Policy Director sous UNIX.

Dans le présent manuel, la variable <chemin_installation> représentece répertoire racine.

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

Répertoire racine du serveur WebSEALLe paramètreserver-root situé dans le fichier de configurationwebseald.conf définit l’emplacement du serveur WebSEAL audémarrage.[server]server-root = /opt/pdweb/www

Tous les chemins relatifs définis dans les fichiers de configurationwebseald.conf sont relatifs à ce répertoire racine.

Remarque : Normalement, vous ne devez pas modifier ce nom dechemin.

Démarrage et arrêt de WebSEALPour démarrer et arrêter le processus du serveur WebSEAL, vouspouvez utiliser la commandepdweb_start sous UNIX et le panneaude configuration des services sous Windows.

UNIX :pdweb_start {start|stop|restart|status}

Par exemple, pour arrêter le serveur WebSEAL et le redémarrer,utilisez :# pdweb_start restart

La commandepdweb_start est située dans le répertoire suivant :/opt/pdweb/bin/

22 Version 3.8

Windows :

Identifiez le processus du serveur WebSEAL dans le panneau deconfiguration des services et utilisez les boutons de commande quiconviennent.

Configuration des paramètres de communicationLes sections ci-après contiennent des informations génériques sur leserveur WebSEAL :

¶ «Configuration de WebSEAL pour des requêtes HTTP» à la page23

¶ «Configuration de WebSEAL pour les requêtes HTTPS» à lapage 24

¶ «Restriction des connexions à partir de versions SSLspécifiques» à la page 24

¶ «Configuration des unités d’exécution des agents HTTP etHTTPS» à la page 25

¶ «Paramètres de délai d’expiration pour les communicationsHTTP/HTTPS» à la page 26

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

Configuration de WebSEAL pour des requêtes HTTPWebSEAL gère généralement de nombreuses requêtes HTTPémanant d’utilisateurs non authentifiés. Par exemple, il est fréquentque des utilisateurs anonymes détiennent un accès en lecture seule àdes documents sélectionnés dans la section publique de votre siteWeb.

Les paramètres de gestion des requêtes HTTP via le protocole TCPse trouvent dans la strophe[server] du fichier de configurationwebseald.conf.


2.C

onfigurationdu

serveurW

ebSE

AL

Activation/désactivation de l’accès HTTPActivez ou désactivez l’accès HTTP lors de la configuration deWebSEAL :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) setrouvent dans la strophe[server] du fichier de configurationwebseald.conf.

Activation/désactivation de l’accès HTTPSActivez ou désactivez l’accès HTTP lors de la configuration deWebSEAL :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

Restriction des connexions à partir de versions SSLspécifiques

Vous pouvez activer et désactiver séparément les connexions pourSSL version 2, SSL version 3 et TLS version 1. Les paramètres quicontrôlent les connexions pour des versions SSL et TLS spécifiquessont situés dans la strophe[ssl] du fichier de configurationwebseald.conf. Par défaut, toutes les versions SSL et TLS sontactivées.

24 Version 3.8

[ssl]disable-ssl-v2 = nodisable-ssl-v3 = nodisable-tls-v1 = no

Configuration des unités d’exécution des agentsHTTP et HTTPS

Le nombre d’unités d’exécution d’agents configurées spécifie lenombre de requêtes entrantes concurrentes pouvant être prises encharge par un serveur. Les autres connexions arrivant lorsque toutesles unités d’exécution d’agents sont occupées sont mises en mémoiretampon jusqu’à ce qu’une unité d’exécution soit disponible.

Vous pouvez définir le nombre d’unités d’exécution disponibles pourla prise en charge des connexions entrantes dans WebSEAL. Etantdonné les risques encourus au niveau des performances, laconfiguration du nombre d’unités d’exécution d’agents doits’effectuer avec précaution.

Ce paramètre de configuration n’impose pas de limite supérieure aunombre de connexions simultanées. Il simplifie simplement lenombre d’unités d’exécution mises à disposition pour la gestiond’une file d’attente de travaux illimitée.

Le choix du nombre optimal d’unités d’exécution d’agents dépend dela façon dont vous appréhendez la quantité et le type de trafic survotre réseau.

En augmentant le nombre d’unités d’exécution, vous réduisezgénéralement le temps moyen de traitement des requêtes. Mais vousjouez également sur d’autres facteurs qui peuvent avoir un effetnégatif sur les performances du serveur.

WebSEAL gère une liste d’agents générique et unique, ainsi qu’unpool d’unités d’exécution pour le traitement des requêtes émanant declients utilisant des tunnels TCP, SSL ou GSSAPI. Ce mécanismerenforcé permet à WebSEAL d’économiser les ressources systèmetout en gérant une charge nettement plus importante.


2.C

onfigurationdu

serveurW

ebSE

AL

Vous pouvez configurer la taille du pool des unités d’exécution desagents en définissant le paramètreworker-threads de la strophe[server] du fichier de configurationwebseald.conf.[server]worker-threads = 50

Remarque : Il est vivement recommandé de ne modifier ceparamètre qu’en cas de dépannage d’un incident lié auxperformances.

Paramètres de délai d’expiration pour lescommunications HTTP/HTTPS

WebSEAL utilise la mise en oeuvre GSkit (Global Security Kit) IBMde SSL. Lorsque WebSEAL reçoit une requête d’un client HTTPS,GSKit SSL établit la liaison initiale et gère l’état de la session.

WebSEAL prend en charge les paramètres de délai d’expirationsuivants pour les communications HTTP et HTTPS. Ces paramètresse trouvent dans la strophe[server] du fichier de configurationwebseald.conf.

¶ client-connect-timeout

Une fois la liaison initiale établie, ce paramètre indique le délaipendant lequel WebSEAL conserve la connexion pour la requêteinitiale HTTP ou HTTPS. La valeur par défaut est 120 secondes.[server]client-connect-timeout = 120

¶ persistent-con-timeout

Ce paramètre est spécifique des connexions HTTP/1.1 (et nonHTTP/1.0). Après la première requête HTTP/1.1 et la réponse duserveur, ce paramètre contrôle le nombre maximal de secondespendant lequel WebSEAL conserve une connexion HTTP/1.1permanente avant son arrêt. La valeur par défaut est 5 secondes.[server]persistent-con-timeout = 5

26 Version 3.8

Autres paramètres de délai d’expiration du serveurWebSEAL

Les autres paramètres de délai d’expiration ci-après sont définis dansle fichier de configurationwebseald.conf :

Paramètre Description Valeur pardéfaut

(secondes)

[junction]http-timeout

Valeur de dépassement dudélai pour l’envoi vers/lalecture sur un serveurd’arrière-plan via une jonctionTCP.

120

[junction]https-timeout

Valeur de dépassement dudélai pour l’envoi vers/lalecture sur un serveurd’arrière-plan via une jonctionSSL.

120

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 10. Paramètres de délai d’expiration pour les communications HTTP et HTTPS


2.C

onfigurationdu

serveurW

ebSE

AL

Paramètre Description Valeur pardéfaut

(secondes)

[cgi] cgi-timeout Valeur de dépassement dudélai pour l’envoi vers/lalecture sur un processus CFIlocal.

120

[junction] ping-time WebSEAL effectue un pingpériodique en arrière-plan surchaque serveur relié parjonction pour déterminer s’ilfonctionne. Ses tentatives nese produisent pas à un rythmeplus fréquent que toutes les300 secondes (ou quelle quesoit la valeur définie).

300

Gestion de l’espace WebLes sections ci-après décrivent les tâches requises pour gérerl’espace Web :

¶ «Répertoire racine de l’arborescence des documents Web» à lapage 28

¶ «Configuration de l’indexation des répertoires» à la page 30

¶ «Windows : Conventions de dénomination de fichiers pour lesprogrammes CGI» à la page 32

¶ «Configuration de la mémoire cache d’un document Web» à lapage 33

Répertoire racine de l’arborescence des documentsWeb

L’emplacement de l’arborescence des documents Web est le cheminabsolu à la racine de l’arborescence des documents rendusdisponibles par WebSEAL. Le nom de ce chemin est représenté parle paramètredoc-root de la strophe[content] du fichier de

28 Version 3.8

configurationwebseald.conf. L’emplacement par défaut est définiinitialement lors de l’installation de WebSEAL :

UNIX :doc-root = /opt/pdweb/www/docs

Windows :doc-root = C:\Program Files\Tivoli\PDWeb\www\docs

Cette valeur n’est utilisée qu’une fois : lors du premier démarragede WebSEAL après l’installation. Elle est ensuite enregistrée dans labase de données des jonctions. Toute modification ultérieure de cettevaleur danswebseald.conf reste sans effet.

Après l’installation, vous devez avoir recours à l’utilitairepdadminpour modifier la valeur de l’emplacement du répertoire racine desdocuments. L’exemple suivant (le nom de serveur estwebsealA)illustre cette procédure :

1. Connectez-vous àpdadmin :# pdadminpdadmin> loginEntrer ID utilisateur : sec_masterEntrer mot de passe :pdadmin>

2. Servez-vous de la commandeserver task list pour afficher tousles points de jonction en cours :pdadmin> server task websealA list/

3. Servez-vous de la commandeserver task showpour afficher lesdétails de la jonction :pdadmin> server task 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


2.C

onfigurationdu

serveurW

ebSE

AL

4. Créez une nouvelle jonction locale pour remplacer le point dejonction en cours (l’option-f est nécessaire pour forcer unenouvelle jonction à en remplacer une autre) :pdadmin> server task websealA create -t local -f -d /tmp/docs /Created junction at /

5. Affichez le nouveau point de jonction :pdadmin> server task websealA list/

6. Affichez les détails de la jonction :pdadmin> server task 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 des répertoiresVous pouvez spécifier le nom du fichier par défaut renvoyé parWebSEAL lorsque l’expression URL d’une requête se termine par unnom de répertoire. Si ce fichier par défaut existe, WebSEAL lerenvoie au client. S’il n’existe pas, WebSEAL génère de façondynamique un index de répertoires et renvoie la liste au client.

Le paramètre de configuration du fichier d’index des répertoires setrouve dans la strophe[content] du fichier de configurationwebseald.conf.

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 uneautre convention de dénomination. Par exemple :[content]directory-index = homepage.html

WebSEAL génère de façon dynamique un index des répertoires si lerépertoire indiqué dans la requête ne contient pas le fichier d’indexdéfini par le paramètredirectory-index. L’index généré contient la

30 Version 3.8

liste du contenu du répertoire avec les liens vers chaque entrée durépertoire. L’index est généré uniquement si le client qui demandel’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éespar WebSEAL pour chaque fichier répertorié dans un index généré.La strophe[content-index-icons]du fichier de configurationwebseald.conf contient la liste des types MIME de document ainsique 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ônespour chaque type MIME. Les icônes peuvent également être àdistance. Par exemple :application/* = http://www.acme.com/icons/binary.gif

Vous pouvez également configurer la valeur de ces icônessupplémentaires :

¶ Icône utilisée pour représenter les sous-répertoires :[icons]diricon = /icons/folder2.gif

¶ Icône utilisée pour représenter le répertoire parent :[icons]backicon = /icons/back.gif

¶ Icône utilisée pour représenter les types de fichier inconnus :[icons]unknownicon = /icons/unknown.gif


2.C

onfigurationdu

serveurW

ebSE

AL

Windows : Conventions de dénomination de fichierspour les programmes CGI

Les paramètres contenus dans la strophe[cgi-types] du fichier deconfigurationwebseald.conf vous permettent de spécifier les typesd’extension de fichier Windows qui sont reconnus et exécutéscomme des programmes CGI.

Le système d’exploitation UNIX n’a aucune exigence en matièred’extension de nom de fichier. Il faut toutefois définir des typesd’extension pour les systèmes d’exploitation Windows. La strophe[cgi-types] répertorie tous les types d’extension valides et faitcorrespondre chaque extension (le cas échéant) à un programme CGIapproprié.[cgi-types]<extension> = <programme_cgi>

Par défaut, seuls les fichiers dont l’extension correspond à l’une decelles répertoriées dans la strophe seront exécutés comme desprogrammes CGI. Si un programme CGI est doté d’une extensionqui ne figure pas dans la liste, il n’est pas exécuté.

Les fichiers comportant l’extension.exe sont exécutés comme desprogrammes Windows par défaut et n’exigent aucune mise encorrespondance.

Remarque : Cependant, chaque fois que vous voulez installer unfichier .exe sous Windows en vue d’untéléchargement, vous devez renommer l’extension ouinstaller le fichier comme faisant partie d’une archive(comme.zip).

Vous devez fournir les programmes interpréteur appropriés pour lesextensions représentant des fichiers script interprétés. Exemples deces types d’extension : fichiers scripts shell (.sh et .ksh), scriptsPerl (.pl) et scripts TCL (.tcl).

32 Version 3.8

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ès prudent dans leur utilisation car lesquestions de sécurité inhérentes sont importantes.

Configuration de la mémoire cache d’un documentWeb

Il arrive souvent que les clients soient confrontés à des délaisd’accès au réseau et de téléchargement des fichiers à cause demauvaises performances d’extraction de documents Web. Ces faiblesperformances peuvent être dues au fait que les documents sontextraits de serveurs d’arrière-plan reliés au réseau ou que le stockagelocal est lent.

La fonction de mise en mémoire cache des documents Web permetde stocker les types de documents Web auxquels vous accédezrégulièrement dans la mémoire du serveur WebSEAL. Les clientsconnaissent alors des délais de réponse beaucoup plus rapides auxrequêtes portant sur des documents mis en mémoire cache dans leserveur WebSEAL.

Les documents placés dans la mémoire cache peuvent être aussi biendes documents de texte statique que des images graphiques. Lesdocuments générés de façon dynamique, comme les résultats d’uneinterrogation de base de données, ne peuvent en revanche pas êtreplacés dans la mémoire cache.

La mise en mémoire cache d’un document Web permet la prise encharge de documents de façon locale à partir de WebSEAL plutôtqu’à partir d’un serveur d’arrière-plan via une jonction.


2.C

onfigurationdu

serveurW

ebSE

AL

La mise en mémoire cache s’exécute sur la base du type MIME.Lorsque vous configurez WebSEAL pour la mise en mémoire cached’un document Web, vous identifiez les trois paramètres suivants :

¶ Type de document MIME

¶ Type de support de stockage

¶ Taille de support de stockage

Vous définissez la mise en mémoire cache de documents Web dansla strophe[content-cache]du fichier de configurationwebseald.conf. La syntaxe suivante s’applique :<type_mime> =<type_cache>:<taille_cache>

Paramètre Description

type_mime Représente tout type MIME valide fourni dans uneen-tête de réponse “Type_contenu :” HTTP. Cette valeurpeut contenir un caractère générique ( * ). La valeur */*représente une mémoire cache d’objet par défaut quicontiendra 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 lamémoire cache. Cette édition de Policy Director neprend en charge que les “mémoires caches”.

taille_cache Spécifie la taille maximale (en kilo-octets) de lamémoire cache, avant suppression des objets suivantl’algorithme d’ancienneté.

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

Le mécanisme de mise en mémoire cache de documents Webrespecte ces conditions :

¶ La mise en mémoire cache ne se produit qu’à la définition d’unemémoire cache.

¶ Aucune mémoire cache n’est définie lors de l’installation.

34 Version 3.8

¶ Si vous ne spécifiez pas de mémoire cache par défaut, lesdocuments ne correspondant à aucune mémoire cache explicitene sont pas placés dans la mémoire cache.

¶ Une autorisation est toujours exécutée sur toutes les requêtesportant sur des informations placées dans la mémoire cache.

Vidage de toutes les mémoires cacheVous pouvez vous servir de l’utilitairepdadmin pour vider toutes lesmémoires cache configurées. Cet utilitaire ne permet pas de viderdes mémoires cache individuelles.

Vous devez vous connecter au domaine sécurisé commeadministrateur Policy Directorsec_masteravant d’utiliserpdadmin.

Pour vider toutes les mémoires cache des documents Web, entrez lacommande suivante :

UNIX :# pdadmin server task <nom_serveur> cache flush all

Windows :MSDOS> pdadmin server task <nom_serveur> cache flushall

Statistiques de la mémoire cacheVous pouvez vous servir de l’utilitairepdadmin pour fournir desstatistiques de base sur l’utilisation en cours de la mémoire cache.Ces informations statistiques indiquent le nombre d’élémentscontenus dans la mémoire cache et le nombre de requêtes portant surchaque élément.

Vous devez vous connecter au domaine sécurisé commeadministrateur Policy Directorsec_masteravant d’utiliserpdadmin.

Pour obtenir des informations statistiques sur l’utilisation en cours dela mémoire cache, entrez la commande suivante :

UNIX :# pdadmin server task <nom_serveur> cache stat


2.C

onfigurationdu

serveurW

ebSE

AL

Windows :MSDOS> pdadmin server task <nom_serveur> cache stat

Configuration des 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. Parexemple :

¶ Un fichier n’existe pas.

¶ Les paramètres d’autorisation empêchent l’accès.

¶ Des programmes CGI ne sont pas exécutables par suite de droitsd’accès incorrects aux fichiers UNIX ou autre raison similaire.

En cas d’échec à une requête, le serveur renvoie un message d’erreurau navigateur, comme “403 Interdit”, dans une page d’erreur HTML.Plusieurs messages d’erreur sont disponibles, dont chacun est stockédans un fichier HTML séparé.

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

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

Windows :<chemin_installation>\www\lib\errors/<répertoire_env_local>

Le répertoireerrors contient un certain nombre de sous-répertoiresd’environnement local contenant des versions localisées des fichiersde messages d’erreurs.

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

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

Windows : <répertoire_installation>\www\lib\errors/en_US

Les messages de ce répertoire sont au format HTML de façon àpouvoir s’afficher correctement dans un navigateur. Vous pouvezéditer ces pages HTML pour personnaliser leur contenu. Le nom des

36 Version 3.8

fichiers correspond à la valeur hexadécimale des codes d’erreurinternes renvoyés à l’échec des opérations. Ne modifiez pas cesnoms de fichiers.

Le tableau ci-après contient la liste des noms de fichiers et ducontenu des messages 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 paspu être extraites du certificat duclient utilisé. Les raisons possiblessont les suivantes :

¶ l’utilisateur a fourni un certificatincorrect

¶ le certificat a été refusé

¶ les données d’autorisation del’utilisateur sont absentes de labase de donnéesd’authentification

1354a2fa.html Répertoire non vide L’opération demandée exige leretrait d’un répertoire non vide. Ils’agit d’une opération non autorisée.

1898d259.html Impossible d’établirla connexionutilisateur

La ressource demandée exige que leserveur WebSEAL connectel’utilisateur à un autre serveur Web.Un incident s’est toutefois produitpendant la tentative d’extraction desinformations par WebSEAL.

1898d25a.html Aucune donnée deconnexion pour cetutilisateur

WebSEAL n’a pas pu trouverl’utilisateur GSO correspondant à laressource demandée.

1898d25b.html Aucune destinationde connexion pourcet utilisateur

WebSEAL n’a pas pu trouver ledestinataire GSO correspondant à laressource demandée.


2.C

onfigurationdu

serveurW

ebSE

AL


1898d25c.html Plusieursdestinations deconnexion sontdéfinies pourl’utilisateur

Plusieurs destinataires GSO sontdéfinis pour la ressource demandée.Il s’agit d’une erreur deconfiguration.

1898d25d.html Connexionobligatoire

La ressource demandée est protégéepar un serveur Web d’arrière-planrelié au réseau, qui exige queWebSEAL se connecte à ce serveurWeb. Pour ce faire, l’utilisateur doitd’abord se connecter à WebSEAL.

1898d25e.html Impossible d’établirla connexionutilisateur

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

1898d25f.html Questiond’authentificationinattendue

WebSEAL a reçu une questiond’authentification inattendue d’unserveur Web d’arrière-plan relié auréseau par une jonction.

1898d421.html Déplacéprovisoirement

La ressource demandée a étédéplacée provisoirement. Ceci seproduit en cas de mauvaise gestiondu réacheminement.

302

1898d424.html Requête incorrecte WebSEAL a reçu une requête HTTPincorrecte.

400

1898d425.html Connexionobligatoire

La ressource demandée est protégéepar WebSEAL, et pour y accéder,vous devez d’abord établir uneconnexion.

1898d427.html Interdit L’utilisateur ne possède pas de droitd’accès à la ressource demandée.

403

1898d428.html Introuvable La ressource demandée estintrouvable.

404

38 Version 3.8


1898d432.html Service nondisponible

Un service nécessaire à WebSEALpour traiter votre requête n’est pasdisponible.

503

1898d437.html Serveur suspendu Le serveur WebSEAL a étéprovisoirement suspendu parl’administrateur système. Aucunerequête ne sera traitée tant que leserveur ne sera pas remis en servicepar l’administrateur.

1898d439.html Les données de lasession ont étéperdues

La transaction entre le navigateur etle serveur a occasionné une sessionavec un serveur relié au réseau parjonction. Ce serveur ne répond plus.WebSEAL a besoin d’un serviceinstallé sur ce serveur pour terminerle traitement de votre requête.

1898d442.html Service nondisponible

Le service nécessaire à WebSEALse trouve sur un serveurd’arrière-plan relié au réseau parune jonction et sur lequell’authentification SSL réciproque aéchoué.

1898d7aa.html Le programme CGIa échoué

Un programme CGI n’a pas pus’exécuter correctement.

default.html Erreur du serveur WebSEAL n’a pas pu traiter votrerequête suite à une erreurinattendue.

500

deletesuccess.html Terminé La suppression (DELETE)demandée par le client a abouti.

200

putsuccess.html Terminé L’opération PUT demandée par leclient a abouti.

200

relocated.html Déplacéprovisoirement

La ressource demandée a étédéplacée provisoirement.

302

websealerror.html 400 Erreur duserveur WebSEAL

Erreur interne du serveurWebSEAL.

400


2.C

onfigurationdu

serveurW

ebSE

AL

Prise en charge des macrosLes macros suivantes permettent de personnaliser les pages d’erreurHTML répertoriées dans la section précédente. Elles remplacent defaçon dynamique les informations 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.

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

%BACK_URL% Valeur de l’en-tête du référenceur de la requête, ou “/”, s’il n’y ena 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 de pages HTML personnaliséesPolicy Director contient des exemples de formulaires HTML quipeuvent être personnalisés pour renfermer des messages spécifiquesd’un site ou exécuter des actions spécifiques d’un site. La plupartdes formulaires conviennent aux méthodes d’authentification BA, parformulaires et par jeton via HTTP ou HTTPS.

Les emplacements des fichiers correspondant à ces formulaires sontdéfinis par le paramètremgt-pages-rootcontenu dans la strophe[acnt-mgt] du fichier de configurationwebseald.conf.mgt-pages-root = lib/html/<répertoire_lang>

40 Version 3.8

Le répertoire utilisé dépend de la localisation. Ainsi le répertoireutilisé par défaut pour l’anglais US est :lib/html/C

Les fichiers de paramètres régionaux japonais se trouvent dans :lib/html/JP

Valeurs et paramètres de page personnaliséeLes valeurs et les paramètres de page HTML spéciaux suivants setrouvent dans la strophe[acnt-mgt] du fichier de configurationwebseald.conf. Certaines pages ne sont utilisées que par laméthode de connexion à l’aide de formulaires qui permet de fournirdes informations d’identité.

Paramètre Page Syntaxe

login = login.html Connexion à l’aide deformulaires

logout = logout.html Dé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

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 Authentificationrenforcée


2.C

onfigurationdu

serveurW

ebSE

AL

Descriptions de pages HTML personnalisées

Masque Description

login.html Formulaire de demande standard de nom d’utilisateur et demot de passe

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.

Il existe également deux macros pour ces pages. Ces chaînes demacros peuvent être placées dans les fichiers modèles. La macroremplace de façon dynamique les valeurs appropriées.

Macro Description

%USERNAME% Nom de l’utilisateur connecté.

%ERROR% Message d’erreur défini dans le code renvoyé parPolicy Director.

42 Version 3.8

Gestion des certificats côté client et côté serveurCette section décrit les tâches d’administration et de configurationrequises pour configurer WebSEAL en vue d’une gestion descertificats numériques côté client et côté serveur, servant àl’authentification via SSL.

WebSEAL a besoin de certificats dans les cas suivants :

¶ WebSEAL s’identifie auprès des clients SSL avec son certificatcôté serveur

¶ WebSEAL s’identifie auprès d’un serveur d’arrière-plan relié auréseau par une jonction (configuré pour une authentificationréciproque) avec un certificat côté client

¶ WebSEAL se réfère à sa base de données de certificats racine del’autorité de certification (CA) pour valider les clients dotés decertificats côté client

¶ WebSEAL se réfère à sa base de données de certificats racineCA pour valider les serveurs d’arrière-plan reliés au réseau parjonction, configurés pour une authentification réciproque

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

WebSEAL inclut les composants suivants, lors de l’installation, pourprendre en charge l’authentification SSL via des certificatsnumériques :

¶ Une base de données de clés par défaut (pdsrv.kdb)

¶ Un fichier caché (pdsrv.sth) et un mot de passe (“pdsrv”) de labase de données de clés par défaut

¶ Plusieurs certificats racine de CA usuels


2.C

onfigurationdu

serveurW

ebSE

AL

¶ Un certificat de test d’auto-signature dont WebSEAL peut seservir pour s’identifier auprès des clients SSL

Il est conseillé de vous adresser à une autorité de certificationreconnue pour remplacer le certificat de test par un certificatcouramment accepté.

La configuration de gestion du certificat WebSEAL comprend lesétapes suivantes :

¶ «Configuration des paramètres de la base de données de cléspour WebSEAL» à la page 46

¶ «Utilisation de l’utilitaire de gestion de certificat iKeyman» à lapage 49

¶ «Configuration du contrôle LRC» à la page 49

Explication des types de fichier de la base dedonnées de clés GSKit

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

Une base de données de clés CMS contient un fichier avecl’extension .kdb, voire plusieurs fichiers. Le fichier.kdb est créé enmême temps qu’une nouvelle base de données de clés. Unenregistrement de clé contenu dans un fichier.kdb peutcorrespondre à un certificat ou à un certificat avec des informationschiffrées sur les clés privées.

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

44 Version 3.8

Type de fichier Description

.kdb Fichier de la “base de données de clés”. Stocke les certificatspersonnels, les demandes de certificat personnel et les certificatsde signataire. Par exemple, le fichier de la base de données declés WebSEAL est pdsrv.kdb.

.sth Fichier “caché”. Stocke une version chiffrée du mot de passe dela base de données de clés. Le nom dérivé de ce fichier estidentique à celui du fichier .kdb associé.

.rdb Fichier de la base de données de “demandes”. Crééautomatiquement en même temps qu’un fichier de base dedonnées de clés .kdb. Le nom dérivé de ce fichier est identique àcelui du fichier .kdb associé. Ce fichier contient des demandes decertificat en attente qui n’ont pas été renvoyées par la CA.Lorsque la CA renvoie un certificat, la demande de certificatcorrespondante est recherchée dans le fichier .rdb (en fonction dela clé publique). Si une correspondance est trouvée, le certificatest renvoyé et la demande de certificat correspondante estsupprimée du fichier .rdb. Si aucune correspondance n’esttrouvée, la tentative de renvoi du certificat est rejetée. Lademande de certificat inclut le nom de l’utilisateur, l’entreprise,l’adresse, d’autres informations définies en même temps que larequête ainsi que les clés publique et privée associées à cettedemande.

.crl Fichier de la “liste de révocation des certificats”. Normalement, cefichier contient la liste des certificats ayant été refusés pour uneraison quelconque. Toutefois, iKeyman ne fournit aucune prise encharge des listes de révocation des certificats ; c’est pourquoi cefichier est vide.


2.C

onfigurationdu

serveurW

ebSE

AL

Type de fichier Description

.arm Fichier binaire codé ASCII. Un fichier .arm contient unereprésentation ASCII codée en Base64 d’un certificat, y comprissa clé publique, mais pas sa clé privée. Les données de certificatbinaire d’origine sont converties en représentation ASCII.Lorsqu’un utilisateur reçoit un certificat dans un fichier .arm,iKeyman décode la représentation ASCII et place la représentationbinaire dans le fichier .kdb qui convient. De même, lorsqu’unutilisateur extrait un certificat d’un fichier .kdb, iKeymanconvertit les données binaires en données ASCII et les place dansun fichier .arm. Les données ASCII du fichier .arm sont cellesque vous envoyez à la CA lors du processus de demande decertificat. Remarque : Vous pouvez utiliser n’importe quel type defichier (différent de .arm), à condition qu’il s’agisse d’un fichiercodé en Base64.

.der Fichier de “règles de codage distinctif”. Un fichier .der contient lareprésentation binaire d’un certificat, y compris sa clé publiquemais 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 CryptographyStandards” (normes de cryptographie de clé publique). Un fichier.p12 contient la représentation binaire d’un certificat, y compris saclé publique et sa clé privée. Un fichier .p12 peut égalementcontenir plusieurs certificats (par exemple, un certificat, lecertificat de la CA ayant émis le certificat, l’émetteur du certificatde la CA, son émetteur, etc). Dans la mesure où un fichier .p12contient une clé privée, il est protégé par un mot de passe.

Configuration des paramètres de la base de donnéesde clés pour WebSEAL

Fichier de clés de certificat WebSEAL :

Lors de l’installation, WebSEAL fournit une base de données de clésde certificat par défaut. Le paramètrewebseal-cert-keyfile, qui setrouve dans la strophe[ssl] du fichier de configurationwebseald.conf, identifie le nom et l’emplacement de ce fichier :[ssl]webseal-cert-keyfile = /var/pdweb/www/certs/pdsrv.kdb

46 Version 3.8

Vous pouvez vous servir de l’utilitaireiKeyman pour créer unenouvelle base de données de clés. Cependant, vous devez entrer lenom et l’emplacement de ce nouveau fichier de clés dans leparamètrewebseal-cert-keyfilepour que WebSEAL puisse localiseret 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é pardéfaut qui contient le mot de passe du fichier de cléspdsrv.kdb. Leparamètrewebseal-cert-keyfile-stashinforme WebSEAL del’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 textesimple dans le paramètrewebseal-cert-keyfile-pwd. Par exemple :webseal-cert-keyfile-pwd = pdsrv

A l’installation, WebSEAL utilise le fichier caché pour obtenir lemot de passe du fichier de clés. Le paramètrewebseal-cert-keyfile-pwdest placé en commentaire. L’utilisation dufichier caché vous dispense d’afficher le mot de passe sous forme detexte dans le fichier de configurationwebseald.conf.

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

Certificat de test WebSEAL :

A l’installation, WebSEAL fournit un certificat de testd’auto-signature non sécurisé. Le certificat de test, qui sert decertificat côté client, permet à WebSEAL de s’identifier auprès desclients SSL.


2.C

onfigurationdu

serveurW

ebSE

AL

Pour mieux contrôler l’utilisation de ce certificat de test, le certificatn’est pas installé comme certificat par défaut. Le paramètrewebseal-cert-keyfile-labeldésigne le certificat comme certificat côtéclient actif et remplace tous les autres certificats “par défaut” dans labase de données du fichier de clés.webseal-cert-keyfile-label = WebSEAL

Bien que ce certificat de test permette à WebSEAL de répondre àune requête d’un navigateur activé SSL, il ne peut pas être vérifiépar le navigateur (qui ne contient pas de certificat d’autorité decertification approprié). Comme la clé privée de ce certificat pardéfaut se trouve dans chaque distribution WebSEAL, ce certificatn’assure pas de véritables communications sécurisées.

Vous devez avoir recours à l’utilitaireiKeyman pour générer unedemande de certificat qui peut être envoyée à une autorité decertification (CA). UtiliseziKeyman pour installer le certificat deserveur renvoyé et lui affecter un libellé.

Si vous utilisez différents certificats pour d’autres scénarios (parexemple, les jonctions–K), vous pouvez vous servir de l’utilitaireiKeyman pour les créer, les installer et leur affecter un libellé. Lelibellé des fichiers de clés ne doit pas contenir d’espace.

WebSEAL (qui s’exécute par défaut en tant queuser ivmgr) doitdétenir des droits d’accès en lecture (r) sur ces fichiers de base dedonnées de clés.

Voir aussi la section «Gestion de certificats avec iKeyman» à lapage 279.

Communications SSL internes avec les serveurs Policy Director :

La strophe[ssl] du fichier de configurationwebseald.conf contientquatre autres paramètres destinés à configurer le fichier de clésutilisé par WebSEAL pour les communications SSL internes avec lesautres serveurs Policy Director. Vous pouvez modifier ces paramètresuniquement à l’aide du script de configurationpdconfig.

48 Version 3.8

[ssl]ssl-keyfile =ssl-keyfile-pwd =ssl-keyfile-stash =ssl-keyfile-label =

Utilisation de l’utilitaire de gestion de certificatiKeyman

L’utilitaire iKeyman est un outil livré avec GSKit qui permet degérer les certificats numériques utilisés par WebSEAL. Servez-vousde iKeyman pour :

¶ créer une ou plusieurs bases de données de clés,

¶ modifier les mots de passe de connexion à la base de données declés,

¶ créer de nouveaux certificats WebSEAL,

¶ définir un nouveau certificat WebSEAL par défaut,

¶ créer un certificat d’auto-signature pour test,

¶ demander et recevoir des certificats racine de CA,

¶ ajouter des certificats dans la base de données, et en supprimer,

¶ copier des certificats d’une base de données à une autre.

Pour des instructions détaillées sur l’utilisation deiKeyman pourexécuter ces tâches, reportez-vous à la section «Gestion de certificatsavec iKeyman» à la page 279.

Configuration du contrôle LRCLa liste LRC (Liste de révocation des certificats) constitue uneméthode qui empêche la validation des certificats non souhaités. Ellecontient les identités des certificats jugées non fiables. La mise enoeuvre GSKit de SSL utilisée par WebSEAL prend en charge lecontrôle LRC. GSKit permet à WebSEAL d’exécuter le contrôleLRC sur les certificats côté client et sur les certificats émanant dejonctions SSL.

WebSEAL doit connaître l’emplacement de cette liste pour exécuterle contrôle LRC. Vous pouvez trouver les paramètres liés à


2.C

onfigurationdu

serveurW

ebSE

AL

l’emplacement du serveur LDAP pouvant servir de référence pour lecontrôle LRC pendant l’authentification par certificat dans la strophe[ssl] du fichier de configurationwebseald.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>

Par défaut, le contrôle LRC est désactivé (les paramètres sont placésen commentaire). Pour activer le contrôle LRC pendantl’authentification par certificat, annulez la mise en commentaire etentrez les valeurs appropriées.

Une valeur nulle pourssl-ldap-userindique que la méthoded’authentification SSL doit s’associer au serveur LDAP en tantqu’utilisateur anonyme.

Configuration d’un niveau de protection par défautVous pouvez contrôler le niveau de chiffrement par défaut requispour accéder à WebSEAL via SSL (HTTPS) en configurant le niveaude protection (NDP). La gestion du niveau de protection par défautest contrôlée par les paramètres de la section “SSL QUALITY OFPROTECTION MANAGEMENT” du fichier de configurationwebseald.conf :

¶ Activation et désactivation de la gestion du niveau de protectionavec le paramètressl-qop-mgmt

¶ 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èsHTTPS :[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)

50 Version 3.8

# DES-40# DES-56# DES-168# RC2-40# RC2-128# RC4-40# RC4-128default = ALL

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

Configuration du niveau de protection pour lesréseaux et les hôtes individuels

Le paramètressl-qop-mgmt = yesactive également tous lesparamètres apparaissant dans les strophes[ssl-qop-mgmt-hosts]et[ssl-qop-mgmt-networks]. Ces strophes autorisent la gestion duniveau de protection par adresse IP d’hôte/de réseau/de masque deréseau.

La strophe[ssl-qop-mgmt-default] répertorie les méthodes dechiffrement utilisées pour toutes les adresses IP sans correspondancedans 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


2.C

onfigurationdu

serveurW

ebSE

AL

Exemple de syntaxe de configuration pour les réseaux/masques deré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 pour la compatibilité amont uniquement. Il n’est pasconseillé de les utiliser pour la configuration Policy Director 3.8.

Configuration des interrogations et des mises à jourde la base de données d’autorisation

Management Server gère la base de données de règles d’autorisationprincipale et conserve les informations sur les emplacements desautres serveurs Policy Director du domaine sécurisé. Unadministrateur Policy Director peut à tout moment apporter desmodifications aux règles de sécurité du domaine sécurisé.Management Server modifie la base de données d’autorisationprincipale chaque fois que des modifications sont apportées auxrègles de sécurité.

Lorsque Management Server modifie la base de donnéesd’autorisation principale, il peut envoyer une notification de cechangement à toutes les répliques de la base de données dans ledomaine sécurisé qui prennent en charge les différents applicateursde règles (par exemple, WebSEAL). Les applicateurs de règlesdoivent ensuite demander une mise à jour de la base de donnéesréelle à partir de la base de données d’autorisation principale.

52 Version 3.8

En tant que gestionnaire de ressources et applicateur de règles,WebSEAL peut obtenir des informations sur les modificationsapportées à la base de données d’autorisation à l’aide de troisoptions :

¶ Ecoute des notifications de mise à jour à partir de ManagementServer (configurable et activée par défaut) ;

¶ Contrôle (interrogation) de la base de données d’autorisationprincipale à intervalles réguliers (configurable et activé pardéfaut) ;

¶ Activation de l’écoute et de l’interrogation.

La strophe[aznapi-configuration] du fichier de configurationwebseald.conf contient des paramètres destinés à configurer lesinterrogations de base de données et l’écoute des notifications demise à jour.

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

Configuration de l’écoute des notifications de mise àjour

Le paramètrelisten-flags active et désactive l’écoute desnotifications de mise à jour pour WebSEAL. L’écoute est activée pardéfaut. Pour la désactiver, entrez “disable”.[aznapi-configuration]listen-flags = enable

Le paramètretcp-port configure le port TCP pour le programmed’écoute :[aznapi-configuration]tcp-port = 12056

Le paramètreudp-port configure le port UDP pour le programmed’écoute :[aznapi-configuration]udp-port = 0


2.C

onfigurationdu

serveurW

ebSE

AL

Configuration de l’interrogation de la base dedonnées d’autorisation

Vous pouvez configurer WebSEAL de façon à interroger la base dedonnées d’autorisation principale à intervalles réguliers pourrechercher des informations de mise à jour. Le paramètrecache-refresh-interval peut avoir la valeur “default”, “disable” ouindiquer un intervalle de temps spécifique exprimé en secondes. Lavaleur “default” est égale à 600 secondes. L’interrogation estdésactivée par défaut.[aznapi-configuration]cache-refresh-interval = disable

Réplication de serveurs frontaux WebSEAL

Remarque : Les informations suivantes remplacent l’anciennecommandepdadmin server modify baseurl utiliséedans les versions précédentes de Policy Director.

Dans un environnement à forte charge, il est préférable de répliquerdes serveurs frontaux WebSEAL afin d’optimiser l’équilibrage decharge et la fonction de secours. Lorsque vous répliquez des serveursfrontaux WebSEAL, chaque serveur doit contenir une copie exactede l’espace Web, de la base de données des jonctions et de la basede données dynurl.

Cette version de Policy Director prend en charge une procédure deconfiguration manuelle pour répliquer des serveurs frontauxWebSEAL. La commandepdadmin n’est plus utilisée pour cettetâche.

Dans l’exemple suivant, “WS1” est le nom d’hôte du serveurWebSEAL principal. “WS2” est le nom d’hôte de la réplique duserveur WebSEAL.

1. Installez et configurez WebSEAL à la fois sur les serveurs WS1et WS2.

2. Arrêtez WebSEAL sur WS2.

54 Version 3.8

3. Sur WS2, remplacez la valeur “WS2” du paramètreserver-namedu fichier de configurationwebseald.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 basedes évaluations d’autorisation. Le serveur WS2 peut égalementrépondre aux commandesobject list et object showpour les objetssitués sous/WebSEAL/WS1.

L’utilitaire pdadmin répertorie toujours l’objet/WebSEAL/WS2comme faisant partie de l’espace objet. Cet objet est à présent inutileet peut être supprimé :pdadmin> object delete /WebSEAL/WS2

Conditions :

¶ Gestion de l’espace objet global : Bien que l’administrateurpuisse voir une seule hiérarchie d’objets, tous les serveursWebSEAL répliqués sont affectés par les commandesd’administration appliquées à cette hiérarchie et peuvent yrépondre.

¶ Evaluation de l’autorisation globale : Si le serveur WS2 estconfiguré en tant que réplique du serveur WS1, il utilise/WebSEAL/WS1 comme base pour évaluer les autorisations.

¶ Configuration globale : Pour que la réplication du serveurfrontal WebSEAL fonctionne correctement, les configurations del’espace Web, de la base de données des jonctions et de la basede données dynurl doivent être identiques sur chaque serveur.

Configuration de la journalisation HTTP standardWebSEAL gère trois fichiers journaux HTTP classiques quienregistrent l’activité plutôt que les messages :

¶ request.log

¶ agent.log


2.C

onfigurationdu

serveurW

ebSE

AL

¶ referer.log

Par défaut, ces fichiers journaux sont conservés dans le répertoiresuivant :

UNIX : /var/pdweb/www/log/

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

Les paramètres de configuration de la journalisation HTTP standardse trouvent dans la strophe[logging] du fichier de configurationwebseald.conf.

Le tableau ci-après illustre les relations entre les fichiers journauxHTTP et les paramètres du fichier de configuration :

Fichiers journaux Paramètred’emplacement

Activation/désactivationdu 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 fichierrequest.log apparaît comme suit :

UNIX :requests-file = /var/pdweb/www/log/request.log

Windows :requests-file = \Program Files\Tivoli\PDWeb\www\log\request.log

Activation et désactivation de la journalisation HTTPPar défaut, la journalisation HTTP est totalement activée :[logging]requests = yesreferers = yesagents = yes

56 Version 3.8

Chaque journal peut être activé ou désactivé indépendamment desautres. Si un paramètre est défini à “no”, la journalisation estdésactivée pour ce fichier.

Spécification du type d’horodatageVous pouvez choisir d’avoir les données d’horodatage enregistréesdans chaque journal en heure GMT (Greenwich Mean Time) plutôtque dans la zone horaire locale. Par défaut, la zone horaire locale estutilisée :[logging]gmt-time = no

Pour utiliser les données d’horodatage GMT, définissez :gmt-time = yes

Spécification des seuils de renouvellement pour unautre fichier journal

Le paramètremax-sizeindique la taille maximale que peut atteindreun fichier journal HTTP et a la valeur par défaut suivante (enoctets) :[logging]max-size = 2000000

Lorsqu’un fichier journal atteint la valeur spécifiée (ou seuil derenouvellement), le fichier existant est sauvegardé dans un fichier dumême nom, auquel sont ajoutées la date et l’horodate en cours. Unnouveau fichier journal est alors démarré.

Les différentes valeursmax-sizepossibles sont interprétées commesuit :

¶ Si la valeurmax-sizeest inférieure à zéro (< 0), un nouveaufichier journal est créé à chaque appel du processus dejournalisation et toutes les 24 heures à partir de cette instance.

¶ Si la valeurmax-sizeest égale à zéro (= 0), aucun roulementn’est exécuté et le fichier journal augmente à l’infini. Si unfichier journal existe déjà, aucune nouvelle donnée n’y estajoutée.


2.C

onfigurationdu

serveurW

ebSE

AL

¶ Si la valeurmax-sizeest supérieure à zéro (> 0), un roulements’effectue lorsqu’un fichier journal atteint la valeur de seuilconfigurée. Si un fichier journal existe déjà au démarrage,aucune nouvelle donnée n’y est ajoutée.

Spécification de la fréquence de vidage des mémoirestampon de fichier journal

Les fichiers journaux sont enregistrés dans des flux de donnéesmises en mémoire tampon. Si vous contrôlez les fichiers journaux entemps réel, vous voudrez peut-être modifier la fréquence à laquellele serveur force un vidage des mémoires tampon des fichiersjournaux.

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èschaque enregistrement.

Configuration de la longueur du contenu enregistrédans request.log

WebSEAL filtre automatiquement les adresses URL HTML statiquesà partir des serveurs d’applications d’arrière-plan reliés par jonction.La strophe[filter-url] du fichier de configurationwebseald.confdéfinit les attributs d’URL que filtre WebSEAL dans les réponses duserveur d’arrière-plan. Voir la section «Filtrage d’URL statiques àpartir de serveurs reliés par jonction» à la page 196.

Lorsque le contenu demandé à partir d’un serveur d’arrière-plan reliépar jonction contient des adresses URL imbriquées, WebSEAL filtreles chaînes d’URL en ajoutant le point de jonction au chemin.Lorsque l’adresse URL est renvoyée au navigateur, le client peutl’utiliser correctement.

La longueur du contenu final des pages renvoyées au navigateur peutdonc être relativement supérieure à celle du contenu d’originerenvoyé par le serveur relié par jonction à WebSEAL.

58 Version 3.8

Cette version de Policy Director WebSEAL permet de configurer lalongueur du contenu enregistré par le fichierrequest.log (s’il estactivé). Le paramètrelog-filtered-pagessitué dans la strophe[logging] du fichier de configurationwebseald.conf peut être définide façon à enregistrer une taille de zéro octet ou celle des octets nonfiltrés.

Pour enregistrer la taille des octets non filtrés, affectez au paramètrela valeur “yes” (valeur par défaut) :[logging]log-filtered-pages = yes

Pour enregistrer une taille de zéro octet, affectez au paramètre lavaleur “no” :[logging]log-filtered-pages = no

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

où :

host Indique l’adresse IP de la machine émettant larequête.

authuser Ce champ prend la valeur de l’en-têteFrom: de larequête HTTP reçue. La valeur “unauth” est utiliséepour un utilisateur non authentifié.

date Indique la date et l’heure de la requête.

request Indique la première ligne de la requête telle qu’elle aété émise par le client.

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


2.C

onfigurationdu

serveurW

ebSE

AL

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

Affichage du fichier request.logLe journalrequest.log enregistre la journalisation standard desrequêtes HTTP, comme les informations relatives aux adresses URLqui ont été demandées et les informations sur le client (par exemple,l’adresse IP) à l’origine de la requête.

L’exemple suivant montre un exemple de fichierrequest.log :130.105.1.90 - - [26/Aug/2001:17:23:33 -0800]

"GET /xsmith/private_html/ HTTP/1.0" 403 77130.105.1.90 - - [26/Aug/2001:17:23:47 -0800]”GET /icons HTTP/1.0" 302 93

130.105.1.90 - - [26/Aug/2001:17:23:59 -0800]"GET /icons/ HTTP/1.0" 403 77

130.105.1.90 - - [26/Aug/2001:17:24:04 -0800]"GET /xsmith/private_html/ HTTP/1.0" 403 77

130.105.1.90 - - [26/Aug/2001:17:24:11 -0800]"GET /xsmith/ HTTP/1.0" 403 77

Affichage du fichier agent.logLe fichier agent.log enregistre le contenu de l’en-têteUser_Agent:dans la requête HTTP. Ce fichier journal révèle des informations surle navigateur du client, comme l’architecture ou le numéro deversion, pour chaque requête.

L’exemple suivant montre un exemple de version de fichieragent.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)

60 Version 3.8

Affichage du fichier referer.logLe journalreferer.log enregistre l’en-têteReferer: de la requêteHTTP. Pour chaque requête, le fichier journal enregistre le documentqui contenait le lien au document demandé.

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

Ces informations sont utiles pour effectuer le suivi des liens externesaux documents de votre espace Web. Le journal révèle que la sourcementionnée par leréférenceur contient un lien à unobjet page. Ilvous permet de pister les liens périmés et de découvrir les auteurs deliens à vos documents.

L’exemple suivant montre un exemple de fichierreferer.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


2.C

onfigurationdu

serveurW

ebSE

AL

62 Version 3.8

Règles de sécurité WebSEAL

Ce chapitre contient des informations expliquant comment configureret personnaliser les règles de sécurité WebSEAL.


¶ «Règles de LCA spécifiques de WebSEAL»

¶ «Limitation des tentatives de connexion» à la page 65

¶ «Règle de renforcement de mot de passe» à la page 68

¶ «Règles POP de renforcement d’authentification (authentificationavancée)» à la page 72

¶ «Règles POP d’authentification basée sur réseau» à la page 79

¶ «Niveau de protection des règles POP» à la page 83

¶ «Gestion des utilisateurs non authentifiés (HTTP / HTTPS)» à lapage 84

Règles de LCA spécifiques de WebSEALLes considérations de sécurité suivantes s’appliquent au conteneur/WebSEAL dans l’espace objet protégé :

¶ L’objet WebSEAL commence la chaîne de l’héritage de la LCApour la région WebSEAL de l’espace objet

¶ 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é del’ensemble de l’espace Web

3


3.R

èglesde

sécuritéW

ebSE

AL

¶ Le droit d’accès permission est nécessaire pour l’accès à cetobjet ainsi qu’à tout objet se trouvant en aval

Pour des informations complètes sur les règles de LCA PolicyDirector, reportez-vous au documentTivoli SecureWay PolicyDirector Base - Guide d’administration.

/WebSEAL/< hôte >Cette arborescence secondaire contient l’espace Web d’un serveurWebSEAL donné. Les considérations de sécurité suivantess’appliquent à cet objet :

¶ Le droit d’accès traverse est nécessaire pour l’accès à tout objetse trouvant en aval de ce point

¶ 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é del’ensemble de l’espace objet sur cette machine

/WebSEAL/< hôte >/<fichier >Il s’agit de l’objet ressource contrôlé au niveau de l’accès HTTP. Lesdroits d’accès vérifiés dépendent de l’opération demandée.

Droits d’accès LCA WebSEALLe tableau ci-après décrit les droits d’accès LCA applicables à larégion WebSEAL de 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 objet HTTP dans l’espace objet WebSEAL.)

l list Requis par Management Server pour gérer une listede répertoires automatisée de l’espace Web.

Ce droit d’accès gère aussi l’affichage ou non parun client de la liste du contenu du répertoire enl’absence de la page “index.html” par défaut.

64 Version 3.8

Opération Description

g delegation Permet de sécuriser un serveur WebSEAL pour agirau nom d’un client et de transmettre cette requête àun serveur WebSEAL relié par jonction.

Règles de LCA WebSEAL par défautLes entrées centrales de la LCA WebSEALdefault-websealsont lessuivantes :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 dans l’espace objet.

Le groupewebseal-serverscontient une entrée pour chaque serveurWebSEAL dans le domaine sécurisé. Les droits d’accès par défautpermettent aux serveurs de répondre aux requêtes du navigateur.

Le droit d’accès traverse permet d’étendre l’espace Web représentédans Web Portal Manager. Le droit d’accès list permet à Web PortalManager d’afficher le contenu de l’espace Web.

Limitation des tentatives de connexionLe fait de limiter les tentatives de connexion, option possible pourles installations Policy Director basées LDAP, permet de spécifier unnombre maximal d’échecs de connexion (n) ainsi qu’un délai deverrouillage de pénalité (x), de sorte qu’après un nombre “n”d’échecs de connexion, un utilisateur n’a plus le droit d’essayer dese connecter pendant “x” secondes (ou le compte est désactivé).

Cette règle de limitation des tentatives de connexion permet deprotéger l’ordinateur contre des attaques par mot de passe. Elle créeune condition contraignant l’utilisateur à attendre un certain tempsavant de renouveler d’autres tentatives de connexion, en cas d’échec.Par exemple, une règle peut définir que 3 échecs de connexion sont


3.R

èglesde

sécuritéW

ebSE

AL

suivis par une pénalité de 180 secondes. Ce type de règle peut éviterles tentatives de connexion aléatoires générées par ordinateurplusieurs fois par seconde.

Cette règle de connexion nécessite l’association de deux paramètresde la commandepdadmin policy :

¶ Nombre maximal de tentatives de connexion sans succès

policy set max-login-failures

¶ Pénalité pour dépassement du paramètre de tentatives deconnexion sans succès

policy set disable-time-interval

Le paramètre de pénalité peut inclure un intervalle de temps deverrouillage de compte ou une désactivation totale du compte.

Si une règle est définie (pour exemple) selon laquelle trois échecs deconnexion sont suivis d’une pénalité de temps de verrouillagespécifique, une quatrième tentative (correcte ou incorrecte) génèreune page d’erreur indiquant que le compte est provisoirement nondisponible par suite de la règle en matière de mot de passe.

L’intervalle de temps est spécifié en secondes (l’intervalle minimalrecommandé est de 60 secondes).

Si la règledisable-time-interval est définie à “disable”, l’utilisateurn’a plus accès à son compte et l’attribut LDAPaccount validcorrespondant à cet utilisateur est défini à “no”. Un administrateuractive à nouveau le compte via le composant Web Portal Manager.

Remarque : La définition dedisable-time-interval à “disable”entraîne un supplément de temps systèmed’administration. Vous pouvez rencontrer des délais deréplication des informations de validité de compte(account valid) sur le serveur WebSEAL. Cettesituation dépend de votre environnement LDAP. Enoutre, certaines mises en oeuvre LDAP risquent d’êtreconfrontées à des baisses de performances, suite àl’opération de mise à niveau deaccount valid. Ces

66 Version 3.8

raisons expliquent pourquoi il est conseillé d’utiliser unintervalle de dépassement de délai.

Syntaxe de commandeLes commandespdadmin suivantes ne conviennent qu’à un registreLDAP.

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 detentatives de connexion ratées autorisées avant ledéclenchement d’une pénalité. Cette commandedépend d’une pénalité définie dans la commandepolicy set disable-time-interval.

En tant qu’administrateur, vous pouvez appliquer cetterègle à un utilisateur donné ou l’appliquer globalementà tous les utilisateurs figurant 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 pendantlaquelle un compte doit être désactivé si le nombremaximal d’échecs de tentatives de connexion a étéatteint.

En tant qu’administrateur, vous pouvez appliquer cetterègle à un utilisateur donné ou l’appliquer globalementà tous les utilisateurs figurant dans le registre LDAP.

La valeur par défaut est 180 secondes.


3.R

èglesde

sécuritéW

ebSE

AL

Règle de renforcement de mot de passeLa règle de renforcement de mot de passe, disponible pour lesinstallations Policy Director basées LDAP, fait référence auxstipulations établies à la construction d’un mot de passe par lesrègles de stratégie de mot de passe. Policy Director fournit deuxméthodes de contrôle des règles de renforcement de mot de passe :

¶ Cinq commandes de règles de mot de passepdadmin

¶ Un module d’authentification enfichable (PlugableAuthentication Module, ou PAM) qui vous permet depersonnaliser les règles de mot de passe

Reportez-vous au documentTivoli SecureWay Policy DirectorWebSEAL Developer Reference.

Règle de renforcement de mot de passe définie parl’utilitaire pdadmin

Les cinq attributs de renforcement de mot de passe mis en oeuvrepar l’utilitaire pdadmin sont les suivants :

¶ Longueur minimale de mot de passe

¶ Nombre minimal de caractères alphabétiques

¶ Nombre minimal de caractères non alphabétiques

¶ Nombre maximal de caractères répétés

¶ Espaces autorisés

Ces règles sont mises en oeuvre lorsque vous créez un utilisateuravecpdadmin ou le composant Web Portal Manager, et lorsqu’unmot de passe est modifié avecpdadmin, Web Portal Manager oul’utilitaire pkmspasswd.

Syntaxe de commandeLes commandespdadmin suivantes ne conviennent qu’à un registreLDAP. L’option unset désactive cet attribut de règle (autrement dit,la règle n’est pas mise en oeuvre).

68 Version 3.8


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 motde passe.

En tant qu’administrateur, vous pouvez appliquer cetterègle à un utilisateur donné ou l’appliquer globalementà tous les utilisateurs figurant 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 decaractères alphabétiques autorisés dans un mot depasse.



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 decaractères non alphabétiques (numériques) autorisésdans un mot de passe.



policy set max-password-repeated-chars {<nombre>|unset} [-user<nom_utilisateur>]


3.R

èglesde

sécuritéW

ebSE

AL


policy get max-password-repeated-chars [-user <nom_utilisateur>]

Gère les règles contrôlant le nombre maximal decaractères répétés autorisés dans un mot de passe.



policy set password-spaces {yes|no|unset} [-user <nom_utilisateur>]

policy get password-spaces [-user <nom_utilisateur>]

Gère les règles contrôlant le fait qu’un mot de passepeut contenir ou non des espaces.


La valeur par défaut est unset.

Valeurs par défaut des paramètres de la règleLe tableau ci-après répertorie les paramètres de la règle et leursvaleurs par dé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 passequi existait dans les éditions précédentes de Policy Director,appliquez l’optionunset à chacun des cinq paramètres de mot depasse répertoriés ci-dessus.

70 Version 3.8

Exemples de mots de passe valides et invalidesLe tableau ci-après illustre plusieurs exemples de mots de passe etles résultats des règles sur la base des valeurs par défaut des cinqparamètrespdadmin :

Exemple Résultat

password Non valide : doit contenir au moins un caractère nonalphabé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 commandespdadmin policy peuvent être définies pour unutilisateur spécifique (avec l’option- user) ou globalement (en nespécifiant pas l’option- user). Tout paramètre spécifique d’unutilisateur prévaut sur un paramètre global de règle. Vous pouvezégalement désactiver (unset) un paramètre de règle, ce qui signifieque le paramètre ne contient aucune valeur. Toute règle dotée del’option unset 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

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 pourun mot de passe de 4 caractères ; tous les autres utilisateurs sontdotés d’une règle de longueur minimale pour un mot de passe de 8.)


3.R

èglesde

sécuritéW

ebSE

AL

pdadmin> policy set min-password-length unset -user matt

(L’utilisateur matt est désormais soumis à la règle de longueurminimale globale pour 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ésormaissoumis à une règle de longueur minimale pour un mot de passe.)

Règles POP de renforcement d’authentification(authentification avancée)

Les règles POP de renforcement d’authentification permettent decontrôler l’accès aux objets, sur la base de la méthoded’authentification utilisée.

Vous pouvez vous servir de cette fonctionnalité, quelquefois appeléeaugmentation du niveau d’authentification ou authentificationavancée, pour vous assurer que les utilisateurs ayant accès à desressources plus confidentielles utilisent une méthoded’authentification renforcée. Cette condition peut être souhaitable sivous souhaitez vous protéger contre un accès incorrect.

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 enappliquant des règles POP d’authentification qui exigent un niveaud’authentification plus élevé que celui utilisé par le client lors de sonentrée initiale dans le domaine WebSEAL.

Les règles de renforcement d’authentification sont définies dansl’attribut de méthode d’authentification des extrémités IP des règlesPOP (IP Endpoint Authentication Method).

Configuration des niveaux pour une augmentation duniveau d’authentification

La première étape de la configuration d’un accès d’authentificationspécifique consiste à configurer les méthodes d’authentificationprises en charge et à déterminer l’ordre dans lequel ces méthodesdoivent pouvoir paraître renforcées.

72 Version 3.8

Tout client accédant à un serveur WebSEAL dispose d’un niveaud’authentification, comme “unauthenticated” ou “password”, quiindique par quelle méthode le client s’est authentifié pour la dernièrefois auprès de WebSEAL.

Dans certaines situations, il peut se révéler nécessaire de mettre enoeuvre des niveaux d’authentification “de sécurité” minimaux, pouraccéder à certains objets de l’espace Web. Par exemple, dans unenvironnement donné, l’authentification par passcode de jeton peutêtre considérée comme plus sécurisée que l’authentification par nomd’utilisateur et mot de passe. Un autre environnement peut avoir desnormes différentes.

Au lieu de forcer les clients à redémarrer leurs sessions avecWebSEAL lorsqu’ils ne répondent pas au niveau voulud’authentification, la méthode d’authentification avancée donne auxclients une deuxième chance de s’authentifier à nouveau à l’aide dela méthode requise (niveau).

L’authentification avancée indique qu’un utilisateur ne reçoit pasimmédiatement un message “de refus” lorsqu’il essaie d’accéder àune ressource nécessitant un niveau d’authentification “supérieur” àcelui avec lequel ils se sont connectés. Il reçoit à la place une invited’authentification qui demande des informations pour la prise encharge 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’authentificationutilisables dans la méthode d’authentification renforcée :

¶ unauthenticated

¶ password

¶ token-card


3.R

èglesde

sécuritéW

ebSE

AL

Vous pouvez configurer les niveaux d’authentification dans lastrophe[authentication-levels] du fichier de configurationwebseald.conf. Initialement, seulement deux niveaux sontconfigurés :[authentication-levels]level = unauthenticatedlevel = password

Chaque méthode est dotée d’un index de niveau allant de 0 à 2basésur l’ordre d’apparition des méthodes de la liste.

¶ La méthode “unauthenticated”doit toujours être la première dela liste et recevoir l’index de niveau 0.

¶ Les méthodes suivantes peuvent être placées dans un ordrequelconque.

Voir la section «Notes et limites de l’authentification renforcée»à la page 78.

¶ Par défaut, la méthode “password” apparaît comme le niveausuivant (index de niveau 1).

¶ Il doit y avoir au moins deux entrées pour activerl’authentification renforcée.

Remarque : Pour des informations détaillées sur la configurationdes méthodes d’authentification requises, reportez-vousà la section «Authentification WebSEAL» à la page 87.

Activation de l’authentification renforcéeL’authentification renforcée est mise en oeuvre au moyen de règlesPOP placées sur les objets exigeant des droits d’accès basés sur uneauthentification. Vous utilisez l’attribut de méthode d’authentificationdes extrémités IP des règles POP.

La commandepdadmin pop modify set ipauth spécifie les réseauxautorisés et le niveau d’authentification requis dans l’attribut deméthode d’authentification des extrémités IP.

Les niveaux d’authentification configurés peuvent être liés à desplages d’adresses IP. Cette méthode est conçue pour assurer une

74 Version 3.8

souplesse dans la gestion. Si le filtrage des utilisateurs par adresse IPn’est pas important, vous pouvez définir une seule entrée pouranyothernw (any other network, ou tout autre réseau). Ce paramètreaffectera tous les utilisateurs tentant un accès, quelle que soitl’adresse IP, et les oblige à s’authentifier au niveau spécifié. Il s’agitde la méthode de mise en oeuvre de l’authentification renforcée laplus répandue.

Syntaxe :pdadmin> pop modify<nom_pop> set ipauth anyothernw<index_niveau>

L’entréeanyothernw sert de plage de réseaux qui correspondront àtout réseau non spécifié dans les objets protégés (POP). Cetteméthode est utilisée pour créer une entrée par défaut qui peut soitrefuser toutes les adresses IP ne correspondant pas ou permettrel’accès à toute personne pouvant répondre aux exigences du niveaud’authentification.

Par défaut,anyothernw figure dans un objet protégé avec un indexde niveau d’authentification 0. L’entrée apparaît comme “Any OtherNetwork” dans la commandepop 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 danswebseald.conf :

[authentication-levels]level = unauthenticatedlevel = token-card


3.R

èglesde

sécuritéW

ebSE

AL

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’authentificationgrâce au passage vers la méthode d’authentification par code dejeton (niveau 1) pour tous les utilisateurs ayant initialement unaccès “unauthenticated” (niveau 0). Tous les utilisateurs nonauthentifiés tentant d’accéder à des objets protégés par ces règlesPOP reçoivent une invite pour un nom d’utilisateur et unpasscode de jeton.

Voir aussi la section «Règles POP d’authentification basée surréseau» à la page 79.

Formulaire de connexion avancéeWebSEAL présente un formulaire spécial lorsque les règles POPrenforcées sur la ressource demandée forcent le client à demanderune nouvelle authentification. L’emplacement de ce formulaire, oupage HTML, est spécifié par le paramètrestepup-login de la strophe[acnt-mgt] du fichier de configurationwebseald.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 formulaireslogin.htmlou tokenlogin.html.

Ce fichier contient des macros, qui se présentent comme desséquences %TEXT%, remplacées par les valeurs appropriées. Cettesubstitution se produit au sein des fonctions de traitement de fichiermodèle WebSEAL et permet d’utiliser ce formulaire pour lesméthodes d’authentification par mot de passe et par jeton avec une

76 Version 3.8

mise en forme correcte. De même, d’autres informations, du typemessage d’erreur et nom de méthode (renforcée) peuvent êtrerenseignées pour l’utilisateur dans le formulaire.

Figure 11. Formulaire de connexion avancée pour nom d’utilisateur et mot de passe

Figure 12. Formulaire de connexion avancée pour passcode de jeton SecurID


3.R

èglesde

sécuritéW

ebSE

AL

Algorithme d’authentification renforcéeWebSEAL utilise l’algorithme suivant pour traiter les conditions d’unobjet protégé :

1. Vérification des règles de la méthode d’authentification parnoeud 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 renforcée1. L’authentification renforcée est prise en charge à la fois via

HTTP et HTTPS.

2. Vous ne pouvez pas passer du protocole HTTP au protocoleHTTPS.

3. Le niveau non authentifié doit toujours constituer la premièreméthode de la liste, et ne peut pas se trouver à un autre niveaude la liste.

4. Les méthodes ne peuvent être spécifiées qu’une fois dans la listede niveaux.

5. L’authentification par certificat est une méthode prise en chargepour l’authentification renforcée.

Remarque : L’authentification renforcée traite les certificats côtéclient comme un cas à part. Si un client accède àWebSEAL avec un certificat côté client et queWebSEAL est configuré de façon à accepter descertificats, le client est traité comme étant nonauthentifié avec un index de niveau 0.

A partir de la méthode : Peut évoluer à :

unauthenticated password token-card

password token-card

78 Version 3.8

A partir de la méthode : Peut évoluer à :

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 parplusieurs mécanismes d’authentification, par exemple desauthentificateurs locaux et des authentificateurs externespersonnalisés.

WebSEAL suit des règles spécifiques pour déterminerl’authentificateur à sélectionner en cas de configuration deplusieurs instances d’une même méthode d’authentification.

7. Si trois niveaux ont été configurés, les valeurs d’index autoriséessont : 0,1,2. Si une autre valeur d’index est configurée, une paged’erreur s’affiche dès qu’un objet doté de ce POP est demandé.

8. Si les niveaux d’authentification renforcée ne sont pas configuréscorrectement dans le fichier de configurationwebseald.conf, lafonctionnalité de renforcement est désactivée dans WebSEAL.Cette situation peut engendrer un comportementd’authentification inattendu, par exemple la page de connexionpar mot de passe sera émise pour des objets protégés par unerègle POP demandant la méthode d’authentification par passcodede jeton.

Après avoir configuré les niveaux d’authentification renforcée,recherchez les erreurs de configuration consignées dans le fichierwebseald.log.

Règles POP d’authentification basée sur réseauLes règles POP d’authentification basée sur réseau permettent decontrôler l’accès aux objets, sur la base de l’adresse IP del’utilisateur. Vous pouvez avoir recours à cette fonctionnalité pouréviter que certaines adresses IP (ou plages d’adresses IP) puissentaccéder à des ressources de votre domaine protégé.


3.R

èglesde

sécuritéW

ebSE

AL

Vous pouvez également appliquer une configuration de renforcementd’authentification à ces règles et demander une méthoded’authentification spécifique pour chaque plage d’adresses IPspécifiée.

Les règles de renforcement d’authentification sont définies dansl’attribut de méthode d’authentification des extrémités IP (IPEndpoint Authentication Method) des règles POP. Vous devezspécifier deux éléments dans cet attribut :

¶ Niveaux d’authentification

¶ Réseaux autorisés

Configuration des niveaux d’authentificationWebSEAL reconnaît trois méthodes d’authentification renforcée :

¶ unauthenticated

¶ password

¶ token-card

Sur la base de l’ordre des méthodes de la liste, chaque méthode estdotée d’un index de niveau, de 0 à 2.

Vous pouvez configurer les niveaux d’authentification dans lastrophe[authentication-levels] du fichier de configurationwebseald.conf. Initialement, seulement deux niveaux sontconfigurés :[authentication-levels]level = unauthenticatedlevel = password

Vous pouvez vous servir de ces paramètres par défaut lorsque vousconfigurez une authentification basée sur réseau. Dans ce cas,“unauthenticated” correspond au niveau 0 et “password”, au niveau1.

Voir aussi la section «Configuration des niveaux pour uneaugmentation du niveau d’authentification» à la page 72.

80 Version 3.8

Spécification des adresses IP et des plagesVous devez indiquer les adresses IP et les plages d’adresses IPautorisées par ces règles POP.

La commandepdadmin pop modify set ipauth add spécifie leréseau (ou l’ensemble de réseaux) et le niveau d’authentificationrequis dans l’attribut de méthode d’authentification des extrémités IP.

Syntaxe :pdadmin> pop modify <nom_pop> set ipauth add<réseau> <masque_réseau><index_niveau>

Les niveaux d’authentification configurés sont liés aux plagesd’adresses IP. Cette méthode est conçue pour assurer une certainesouplesse. Si le filtrage des utilisateurs par adresse IP n’est pasimportant, vous pouvez définir une seule entrée pouranyothernw(any other network, ou tout autre réseau). Ce paramètre affecte tousles 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 etne vous reporter qu’à l’adresse IP pour autoriser ou refuser l’accès,vous pouvez utiliser le niveau 0 pour les plages à autoriser et leniveau “forbidden” pour les plages à refuser.

L’entréeanyothernw définit une plage de réseaux. Elle correspond àtout réseau non spécifié dans les objets protégés (POP). Cetteméthode est utilisée pour créer une entrée par défaut qui peut soitrefuser toutes les adresses IP ne correspondant pas ou permettrel’accès à toute personne pouvant répondre aux exigences du niveaud’authentification.


3.R

èglesde

sécuritéW

ebSE

AL

Par défaut,anyothernw figure dans un objet protégé avec un indexde niveau d’authentification de 0. L’entrée apparaît comme “AnyOther Network” dans la commandepop 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 uneaugmentation du niveau d’authentification» à la page 72.

ExemplesSeuls les utilisateurs à partir de la plage d’adresses IP 9.0.0.0 et dumasque de ré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 exemplesci-dessus) ne peut accéder à l’objet :pdadmin> pop modify test set ipauth anyothernw forbidden

Désactivation du renforcement d’authentification paradresse IP

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

82 Version 3.8

Algorithme d’authentification basée sur réseauWebSEAL utilise l’algorithme suivant pour traiter les conditions d’unobjet protégé :

1. Vérification des règles de la méthode d’authentification parnoeud 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 basée sur réseauL’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 laconnexion TCP. 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éfinitivel’adresse IP réelle du client. Lorsque vous définissez des règlesd’authentification basée sur réseau, vous devez vous assurer que lesclients du réseau peuvent se connecter directement au serveurWebSEAL.

Niveau de protection des règles POPL’attribut POP de niveau de protection vous permet de spécifier leniveau de protection de données requis pour exécuter une opérationsur un objet.

Actuellement, cet attribut n’est adéquat que dans un environnementWebSEAL.

L’attribut POP de niveau de protection remplace les bits de droitsd’accès de LCA “P” et “I” qui activaient les exigences en matière deconfidentialité et d’intégrité dans les versions précédentes de PolicyDirector. Cette ancienne mise en oeuvre du niveau de protection étaitinefficace et avait des conséquences sur les performances système.


3.R

èglesde

sécuritéW

ebSE

AL

L’attribut POP de niveau de protection permet une transactionunique quand la réponse “yes” à la décision de la LCA inclutégalement le niveau de protection requis. Si le gestionnaire deressources (comme WebSEAL) ne peut pas garantir le niveau deprotection 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).

Integrity(intégrité)

Utilise certains mécanismes pour assurer que lesdonné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’utilisateursauthentifiés ou non authentifiés via HTTP et HTTPS. WebSEAL sebase alors sur le service d’autorisation pour mettre en oeuvre lesrègles de sécurité en autorisant ou refusant l’accès aux ressourcesprotégées.

Pour les utilisateurs non authentifiés qui ont un accès via SSL, lesconditions ci-après s’appliquent :

¶ L’échange d’informations entre l’utilisateur non authentifié etWebSEAL est chiffré (comme avec un utilisateur authentifié).

¶ Une connexion SSL entre un utilisateur authentifié et WebSEALexige uniquement une authentification côté serveur.

84 Version 3.8

Traitement d’une requête émanant d’un clientanonyme

1. 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 ceclient.

3. La requête se poursuit, avec cette autorisation d’accès, versl’objet Web protégé.

4. Le service d’autorisation vérifie les droits d’accès au niveau del’entrée non authentifiée de la LCA pour cet objet, puis accepteou refuse l’opération demandée.

5. Un accès réussi à cet objet dépend de l’entrée LCA nonauthentifiée contenant au moins un accès en lecture (r) ou detype traverse (T).

6. Si la requête ne passe pas le cap de l’autorisation, le client reçoitun formulaire de connexion (BA ou à par formulaire).

Connexion utilisateur forcéeVous pouvez forcer un utilisateur non authentifié à se connecter endéfinissant correctement les droits d’accès appropriés à l’entrée nonauthentifiée dans les règles de la LCA qui protège l’objet demandé.

Les droits d’accès de type lecture (r) et traverse (T) permettentl’accès non authentifié à un objet.

Pour forcer un utilisateur non authentifié à se connecter, supprimezle droit d’accès en lecture (r) de l’entrée non authentifiée dans lesrègles de la LCA qui protège l’objet demandé. L’utilisateur reçoitune invite de connexion (BA ou par à l’aide de formulaires).

Applications de l’accès HTTPS non authentifiéIl existe plusieurs raisons pratiques justifiant la prise en charge d’unaccès non authentifié à WebSEAL via HTTPS :

¶ Certaines applications n’exigent pas de connexion personnelle,mais demandent des informations confidentielles, du type


3.R

èglesde

sécuritéW

ebSE

AL

adresses et numéros de cartes de crédit. C’est le cas par exemplepour l’achat en ligne de tickets d’avion ou autres marchandises.

¶ Certaines applications nécessitent que vous définissiez uncompte commercial avant de poursuivre la transaction. Làencore, des informations confidentielles vont transiter sur leréseau.

Contrôle d’utilisateurs non authentifiés avec desrègles de LCA/POP

Remarque : Le type d’entrée “any-authenticated” (authentifié)équivaut au type d’entrée “any-other”.

1. Pour permettre l’accès d’un utilisateur non authentifié à desobjets publics, protégez le contenu public par une LCA contenantau moins les droits d’accès de type lecture (r) et traverse (T)pour les entrées non authentifiées et authentifiées :unauthenticated Trany-authenticated Tr

Remarque : L’entréeunauthenticated est un masque (uneopération “and” bit par bit) appliqué à l’entréeany-authenticatedquand les droits d’accès sontdéterminés. Un droit d’accès pourunauthenticatedn’est accordé que s’il apparaît également dansl’entréeany-authenticated. Commeunauthenticated dépend deany-authenticated, iln’est pas logique qu’une LCA contienneany-authenticatedsansunauthenticated. Si cettesituation se produit toutefois, la réponse par défautconsiste à n’accorder aucun droit d’accès àunauthenticated.

2. Pour demander le chiffrement (SSL), protégez le contenu par desrègles d’objet protégé (POP) qui spécifient la confidentialitécomme une condition.

Voir la section «Niveau de protection des règles POP» à la page83.

86 Version 3.8

Authentification WebSEAL

Ce chapitre explique comment WebSEAL gère l’état des sessions etle processus d’authentification. Une authentification réussie génèreune identité Policy Director qui représente l’utilisateur. WebSEAL sesert de cette identité pour acquérir des autorisations pour cetutilisateur. Ces données sont utilisées par le service d’autorisationpour accorder ou refuser l’accès aux ressources protégées.


¶ «Explication du processus d’authentification» à la page 88

¶ «Gestion des états de session» à la page 91

¶ «Généralités sur la configuration de l’authentification» à la page104

¶ «Configuration de l’authentification de base» à la page 110

¶ «Configuration de l’authentification par formulaires» à la page112

¶ «Configuration de l’authentification par certificat côté client» àla page 115

¶ «Configuration de l’authentification par en-tête HTTP» à la page120

¶ «Configuration de l’authentification par adresse IP» à la page122

¶ «Configuration de l’authentification par jeton» à la page 123

4


4.A

uthentificationW

ebSE

AL

¶ «Prise en charge des agents MPA (Multiplexing Proxy Agents)»à la page 125

Explication du processus d’authentificationL’authentification est la méthode qui permet d’identifier unprocessus ou une entité individuel essayant de se connecter à undomaine sécurisé.

¶ WebSEAL prend en charge plusieurs méthodes d’authentificationpar défaut et peut être personnalisé pour utiliser d’autresméthodes.

¶ Le résultat d’une authentification réussie auprès de WebSEALest une identité de registre d’utilisateurs Policy Director.

¶ WebSEAL utilise cette identité pour obtenir un droit d’accèspour l’utilisateur.

¶ Le service d’autorisation utilise ce droit d’accès pour autoriserou refuser l’accès à des objets protégés après évaluation desdroits d’accès de la LCA et des conditions POP gérant les règlesrelatives à chaque objet.

Remarque : LCA = liste de contrôle d’accès règles POP = règlesd’objet protégé

Lors de l’authentification, WebSEAL examine une requête client eten particulier les informations suivantes :

¶ Données de session

Les données de session sont des informations identifiant uneconnexion spécifique entre le client et le serveur WebSEAL. Lesdonnées de session sont stockées avec le client et accompagnentles requêtes ultérieures de ce client. Elles permettent d’identifierune deuxième fois la session client auprès du serveur WebSEALet évitent de devoir établir une nouvelle session pour chaquerequête.

¶ Données d’authentification

Les données authentification sont des informations issues duclient qui identifient ce dernier auprès du serveur WebSEAL. Les

88 Version 3.8

données d’authentification comprennent les certificats côté client,les mots de passe et les codes de jeton.

Lorsque WebSEAL reçoit une requête client, il recherche toujours lesdonnées de session en premier, puis les données d’authentification.La requête client initiale ne contient 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 lesdonnées de session dans 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ôlertous les utilisateurs participant au domaine sécurisé. Pour obtenir lesinformations d’identité nécessaires à l’acquisition des droits d’accès,WebSEAL se base sur les informations obtenues à partir duprocessus d’authentification.

WebSEAL prend en charge les méthodes d’authentification suivantespour obtenir des droits d’accès :

Méthode d’authentification Type de connexionaccepté

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


4.A

uthentificationW

ebSE

AL

Méthode d’authentification Type de connexionaccepté

5. Authentification par formulaires (nomd’utilisateur et mot de passe)

HTTP et HTTPS

6. Authentification de base (nom d’utilisateur etmot de passe)

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 lesdonnées d’authentification dans l’ordre de ce tableau.

Les méthodes d’authentification peuvent être activées et désactivéesséparément à la fois pour les transports HTTP et HTTPS. Si aucuneméthode d’authentification n’est activée pour un transport enparticulier, le processus d’authentification est inactif pour les clientsutilisant ce type de transport.

Références à des informations de configurationdétaillées

¶ «Gestion des états de session» à la page 91

¶ «Généralités sur la configuration de l’authentification» à la page104

¶ «Configuration de l’authentification de base» à la page 110

¶ «Configuration de l’authentification par formulaires» à lapage 112

¶ «Configuration de l’authentification par certificat côté client» àla page 115

¶ «Configuration de l’authentification par en-tête HTTP» à lapage 120

¶ «Configuration de l’authentification par adresse IP» à lapage 122

¶ «Configuration de l’authentification par jeton» à la page 123

90 Version 3.8

¶ «Prise en charge des agents MPA (Multiplexing Proxy Agents)»à la page 125

¶ Authentification CDAS

Reportez-vous au documentTivoli SecureWay Policy DirectorWebSEAL Developer Reference.

Gestion des états de sessionUne connexion sécurisée, ou session, entre un client et un serveurexige que ce dernier ait la possibilité de mémoriser (entre denombreuses requêtes) ses interlocuteurs. Le serveur doit doncpouvoir recevoir des informations sur l’état de la session, identifiantle client associé à chaque requête.

Si l’état de la session entre le client et le serveur est inconnu, lescommunications entre les deux doivent être renégociées pour chaquenouvelle requête. Les informations sur l’état de la session optimisentles performances en évitant les fermetures et les réouverturesrépétées des connexions client/serveur. Le client peut se connecterune 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 un protocole “sans état” qui ne fournit aucun moyenpermettant de distinguer une requête d’une autre. En revanche, leprotocole de transport SSL est tout spécialement conçu pour fournirun ID de session de façon à conserver les informations d’état desession. Les communications HTTP peuvent être encapsulées viaSSL pour devenir des communications HTTPS.

Cependant, WebSEAL doit souvent traiter des communicationsHTTP à partir de clients non authentifiés. Parfois, l’ID de sessionSSL n’est pas une solution appropriée. C’est pourquoi WebSEAL estconçu pour utiliser tous les types d’informations suivants pour gérerl’état de la session d’un client :

1. ID SSL ;

2. Cookie de session du serveur ;


4.A

uthentificationW

ebSE

AL

3. Données d’en-tête de l’authentification de base (BA) ;

4. Données d’en-tête HTTP ;

5. Adresse IP.

Caches de session GSKit et WebSEALUne mémoire cache de session permet à un serveur de stocker lesinformations d’ID de session de différents clients. Deux mémoirescache de session sont disponibles pour contenir les informationsd’état de session HTTPS et HTTP.

¶ Mémoire cache des droits d’accès WebSEAL

La mémoire cache des droits d’accès stocke tous les typesd’informations d’ID de session (voir la liste ci-dessus) ainsi queles informations de droits d’accès obtenues pour chaque client.

Les informations de droits d’accès sont mises en mémoire cachede manière à supprimer les interrogations répétitives de la basede données du registre d’utilisateurs lors des contrôlesd’autorisation.

¶ Cache d’ID de session SSL GSKit

La mémoire cache de session GSKit traite les communicationsHTTPS (SSL) lorsque les informations d’ID de session SSL sontutilisées pour gérer l’état des sessions.

La mémoire cache GSKit conserve également les informationsd’état de session pour la connexion SSL entre WebSEAL et leregistre d’utilisateurs LDAP.

92 Version 3.8

Différents paramètres de configuration permettent d’ajuster lesperformances de chaque mémoire cache. Ces paramètres sontrésumés dans la figure ci-après :

Configuration de la mémoire cache des droits d’accèsWebSEAL

Les tâches de configuration suivantes sont disponibles pour lamémoire cache de session/droits d’accès WebSEAL :

¶ Définition de la valeur du nombre maximum d’entréesconcurrentes

¶ Définition de la valeur du délai d’expiration des entrées de lamémoire cache

¶ Définition de la valeur du délai d’inactivité des entrées dans lamémoire cache

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 13. Paramètres de configuration de la mémoire cache de session


4.A

uthentificationW

ebSE

AL

Définition de la valeur du nombre maximum d’entréesconcurrentes

Le paramètre max-entries, situé dans la strophe[session]du fichierde configurationwebseald.conf, définit le nombre maximumd’entrées concurrentes dans la mémoire cache de session/droitsd’accès WebSEAL.

Cette valeur correspond au nombre de sessions de connexionconcurrentes. Lorsque la taille de la mémoire cache atteint cettevaleur, des entrées y sont supprimées suivant l’algorithmed’ancienneté pour permettre de nouvelles connexions entrantes.

Le nombre par défaut de sessions de connexion concurrentes est4096 :[session]max-entries = 4096

Définition de la valeur du délai d’expiration des entrées dela mémoire cache

Le paramètretimeout, situé dans la strophe[session]du fichier deconfigurationwebseald.conf, définit le délai d’expiration maximumde la durée de vie d’une entrée dans la mémoire cache desession/droits d’accès WebSEAL.

WebSEAL met en mémoire cache interne les informationsconcernant les droits d’accès. Le paramètre de dépassement du délaide la mémoire cache de la session définit le délai pendant lequel lesdroits d’accès restent en mémoire sur WebSEAL.

Le paramètre n’est pas un délai d’inactivité. La valeur établit unecorrespondance avec une “durée de vie initiale” plutôt qu’avec un“délai d’expiration” des droits d’accès. L’objectif est de renforcer lasécurité en forçant l’utilisateur à s’authentifier à nouveau lorsque lalimite de dépassement du délai est atteinte.

Par défaut, le délai d’expiration de la session de connexion (ensecondes) est 3600 :[session]timeout = 3600

94 Version 3.8

Définition de la valeur du délai d’inactivité des entrées dansla mémoire cache

Le paramètreinactive-timeout, situé dans la strophe[session]dufichier de configurationwebseald.conf, définit la valeur du délaid’inactivité de la session de connexion.

Par défaut, le délai d’inactivité de la session de connexion (ensecondes) est 600 :[session]inactive-timeout = 600

Pour désactiver cette fonction de délai d’expiration, affectez auparamètre la valeur “0”.

Configuration de la mémoire cache d’ID de sessionSSL GSKit

Les tâches de configuration suivantes sont disponibles pour lamémoire cache d’ID de session SSL GSKit :

¶ Définition de la valeur du délai d’expiration des entrées de lamémoire cache

¶ Définition de la valeur du nombre maximum d’entréesconcurrentes

Définition de la valeur du délai d’expiration des entrées dela mémoire cache

Les paramètres permettant de définir le délai d’expiration maximumde la durée de vie d’une entrée dans la mémoire cache d’ID desession SSL GSKit sont situés dans la strophe[ssl] du fichier deconfigurationwebseald.conf. Il existe deux paramètres : le premierpour les connexions SSL V2 (ssl-v2-timeout) et le second pour lesconnexions SSL V3 (ssl-v3-timeout).

Par défaut, le délai d’expiration de session SSL V2 (en secondes) est100 (les valeurs admises vont de 1 à 100) :[ssl]ssl-v2-timeout = 100


4.A

uthentificationW

ebSE

AL

Par défaut, le délai d’expiration de session SSL V3 (en secondes) est7200 (les valeurs admises vont de 1 à 86400) :[ssl]ssl-v3-timeout = 7200

Définition de la valeur du nombre maximum d’entréesconcurrentes

Le paramètressl-max-entries, situé dans la strophe[ssl] du fichierde configurationwebseald.conf, définit le nombre maximumd’entrées concurrentes dans la mémoire cache d’ID de session SSLGSKit.

Cette valeur correspond au nombre de sessions de connexionconcurrentes. Lorsque la taille de la mémoire cache atteint cettevaleur, des entrées y sont supprimées suivant l’algorithmed’ancienneté pour permettre de nouvelles connexions entrantes.

Le nombre par défaut de sessions de connexion concurrentes est4096 :[ssl]ssl-max-entries = 4096

Gestion de l’état avec des cookies de sessionL’état d’une session entre un client et un serveur peut aussi êtreconservé par le biais d’un cookie contenant ces informations. Leserveur groupe les informations d’état correspondant à un clientdonné dans un cookie qu’il envoie au navigateur du client. A chaquenouvelle requête, le navigateur renvoie le cookie (avec lesinformations sur la session) au serveur pour identifier à nouveau leclient.

L’emploi des cookies de session constitue une solution possiblelorsque le client utilise un navigateur qui renégocie sa session SSLaprès de très courtes périodes. Par exemple, certaines versions dunavigateur Microsoft Internet Explorer renégocient les sessions SSLtoutes les deux ou trois minutes.

Un cookie de session n’assure une nouvelle authentification d’unclient que pour le serveur auprès duquel il s’était récemmentauthentifié préalablement (environ dix minutes). Ce mécanisme

96 Version 3.8

repose sur un “cookie de serveur” qui ne peut être transmis à aucuneautre machine que celle qui l’a généré.

En outre, le cookie de la session ne contient qu’un identificateurnumérique aléatoire utilisé comme index dans la mémoire cache dessessions du serveur. Le cookie de la session ne contient aucune autreinformation. Ce dernier ne peut pas compromettre les règles desécurité.

Explication des cookies de sessionWebSEAL utilise un cookie de session sécurisé spécifique duserveur. Les conditions suivantes s’appliquent à ce mécanisme decookie :

¶ Un cookie ne contient que des informations de session ; il necontient pas d’informations d’identité

¶ Un cookie ne réside que dans la mémoire du navigateur (il n’estpas enregistré dans la réserve de cookies du disque)

¶ Un cookie a une durée de vie limitée (configurable)

¶ Un cookie possède des paramètres de domaine et de cheminempêchant à d’autres serveurs de l’utiliser

Activation et désactivation des cookies d’ID de sessionLe paramètressl-id-sessions, situé dans la strophe[session]dufichier de configurationwebseald.conf, active et désactive lescookies de session. Il détermine si l’ID de session SSL est utilisépour gérer la session de connexion pour les clients qui se connectentvia HTTPS. S’il a la valeur “no”, les cookies de session sont utilisésdans la plupart des méthodes d’authentification.[session]ssl-id-sessions = no

Si ce paramètre de configuration a la valeur “no”, les conditionssuivantes s’appliquent aux clients utilisant HTTPS :

1. L’ID de session SSL n’est jamais utilisé comme données d’ID desession.


4.A

uthentificationW

ebSE

AL

2. Les cookies permettront de gérer des sessions avec les clientsauthentifiés à l’aide de cookies de secours, de jetons d’IDCDSSO, de formulaires (nom d’utilisateur et mot de passe), decodes de jeton et de certificats côté client.

3. Les cookies sont utilisés pour les clients utilisantl’authentification de base uniquement lorsqueuse-same-session= yes (voir section suivante). Sinon, l’en-tête BA est utilisé pourles données d’ID de session.

4. L’en-tête HTTP est utilisé comme données d’ID de session pourles clients qui s’authentifient avec ce type d’en-tête.

5. L’adresse IP est utilisée comme données d’ID de session pour lesclients qui s’authentifient avec ce type d’adresse.

Lorsque vous utilisez un cookie pour gérer l’état de la session, iln’est envoyé qu’une seule fois au navigateur, lorsque la connexionest établie. Toutefois, certains navigateurs limitent le nombre decookies en mémoire qu’ils peuvent stocker simultanément. Danscertains environnements, les applications peuvent placer un grandnombre de cookies en mémoire par domaine sur des systèmes client.Dans ce cas, tous les cookies de secours ou de session WebSEALconfigurés peuvent être facilement remplacés par un autre.

Lorsque vous configurez WebSEAL de façon à utiliser des cookiesde session (voire des cookies de secours), vous pouvez définir leparamètreresend-webseal-cookies, situé dans la strophe[session]dufichier de configurationwebseald.conf afin que WebSEAL lesenvoie au navigateur avec chaque réponse. Cette action permet des’assurer que les cookies de secours et de session restent dans lamémoire du navigateur.

La valeur par défaut du paramètreresend-webseal-cookiesest“no” :[session]resend-webseal-cookies = no

Pour envoyer les cookies de secours et de session WebSEAL avecchaque réponse, remplacez la valeur par défaut par “yes”.

98 Version 3.8

Activation et désactivation des mêmes sessionsVous pouvez configurer WebSEAL de façon à utiliser les mêmesdonnées d’ID de session lorsqu’un client se connecte via un type detransport (HTTP, par exemple), et se déconnecte puis se reconnectevia un autre type de transport (HTTPS, par exemple).

Le paramètreuse-same-session, situé dans la strophe[session]dufichier de configurationwebseald.conf, active et désactive lareconnaissance des données d’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 conditionssuivantes s’appliquent :

1. Les cookies de session permettent d’identifier les types de clientsuivants pour les connexions suivantes via un autre type detransport :

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 avecce type d’en-tête.

3. L’adresse IP est utilisée pour les clients qui se connectent avecce type d’adresse.

4. Le paramètre de configurationssl-id-sessionsest ignoré ; lecomportement obtenu est le même que lorsque qu’il a la valeur“no”.

Cette logique est importante dans la mesure où les clients HTTPn’ont pas d’ID de session SSL utilisable comme données desession.


4.A

uthentificationW

ebSE

AL

5. Dans la mesure où les cookies sont utilisables à la fois par lesclients HTTP et HTTPS, ils ne sont pas marqués comme cookiessécurisés.

Identification des types de données d’ID de sessionvalides

Le type de données de session pour un client qui se connecte avecune méthode d’authentification particulière est déterminé par descombinaisons spécifiques des paramètres de configuration suivants :

¶ Activation ou désactivation des cookies de session(ssl-id-sessions) ;

¶ Activation ou désactivation de la fonction permettant d’utiliserles mêmes données de session lorsqu’un client passe du transportHTTP au transport HTTPS ou inversement (use-same-session).

Les tableaux suivants récapitulent les données d’ID de sessionvalides pour toutes les configurations combinant les paramètresssl-id-sessionset use-same-session:

Clients HTTPS

Méthoded’authentification

ssl-id-sessions =yes

ssl-id-sessions = nouse-same-session =

no

use-same-session =yes ssl-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

Adresse IP ID SSL Adresse IP Adresse IP

100 Version 3.8

Clients HTTP


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 des cookies de secoursLa fonction de cookie de secours suivante (pour HTTP et HTTPS)convient à un client qui se connecte à un groupe de serveursWebSEAL frontaux répliqués via un mécanisme d’équilibrage decharge. L’objectif d’un cookie de secours consiste à empêcher unenouvelle authentification obligatoire lorsque le serveur ayant établi lapremière session avec le client devient subitement indisponible.

Un groupe de serveurs WebSEAL frontaux peut être mis en oeuvrepour fournir une accessibilité avancée des ressources à de nombreuxclients. Le mécanisme d’équilibrage de charge intercepte les requêtesentrantes et les répartit entre les serveurs frontaux disponibles.


4.A

uthentificationW

ebSE

AL

Reportez-vous au graphique suivant :

Le client ignore la configuration des serveurs frontaux répliqués. Lemécanisme d’équilibrage de charge est le seul point de contact pourl’adresse URL demandée. Le mécanisme d’équilibrage de chargeconnecte un client avec un serveur disponible (par exemple, WS1).Un état de session est établi avec le serveur WS1 et toutes lesrequêtes suivantes de ce client sont envoyées à WS1.

Lorsque le serveur WS1 devient indisponible pour une raison ou uneautre (par exemple, panne du système ou déconnexion par unadministrateur), les cookies de secours peuvent apporter une solution.Si le serveur WS1 devient indisponible, le mécanisme d’équilibragede charge réachemine la requête vers l’un des autres serveursrépliqués (WS2 ou WS3). A présent, le mappage session-droitsd’accès d’origine est perdu. Ce serveur de remplacement ne connaîtpas le client qui doit normalement s’authentifier une deuxième fois.

Vous pouvez configurer les serveurs WebSEAL répliqués pourchiffrer les droits d’accès d’un client dans un cookie spécifique duserveur. Le cookie est placé sur le navigateur lorsque le client seconnecte pour la première fois. Si le serveur WebSEAL existantdevient provisoirement indisponible, le cookie (avec les informations

Client


WS1

WS2

WS3

Serveurs WebSEALprincipaux répliqués

Ressourcessecondaires

Figure 14. Scénario de cookie de secours

102 Version 3.8

de droits d’accès chiffrées) est envoyé au serveur de remplacement.Les serveurs WebSEAL répliqués partagent une clé commune quipermet de déchiffrer les informations de droits d’accès. A présent, leclient peut établir une nouvelle session avec une réplique de ceserveur WebSEAL sans être obligé de subir une nouvelleauthentification.

Le point de référence du cookie est le serveur DNS du mécanismed’équilibrage de charge. Cet unique point de référence est importantdans la mesure où le cookie est propre à un serveur et non pas à undomaine. Seul un serveur ayant le même nom DNS que le serveurayant créé le cookie peut accepter ce dernier. Le client effectuetoujours ses requêtes à l’aide du mécanisme d’équilibrage de charge.C’est pourquoi le cookie est toujours accepté, puis transmis auserveur disponible suivant lors d’une opération de secours.

Activation des cookies de secours

Le paramètrefailover-auth, situé dans la strophe[failover] dufichier de configurationwebseald.conf, active ou désactive descookies de secours propres au serveur.

¶ Pour activer les cookies de secours, entrez “http”, “https” ou“both”.

¶ Pour désactiver les cookies de secours, entrez “none” (valeur pardéfaut).

Par exemple :[failover]failover-auth = https

Vous devez définir ce paramètre sur chaque serveur WebSEALfrontal.

Chiffrement et déchiffrement des droits d’accès

Pour protéger les données du cookie, servez-vous de l’utilitairecdsso_key_genfourni par WebSEAL. Ce dernier génère une clé


4.A

uthentificationW

ebSE

AL

symétrique qui chiffre et déchiffre les droits d’accès dans le cookie.Indiquez l’emplacement (chemin d’accès absolu) du fichier de cléslorsque 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 copiezmanuellement le fichier de clés sur tous les autres. Entrezl’emplacement de ce fichier de clés dans la strophe[failover] dufichier de configurationwebseald.conf de chaque serveur. Si vousn’indiquez pas de fichier de clés, la fonctionnalité de cookie desecours est désactivée pour ce serveur :[failover]failover-cookies-keyfile = <chemin_absolu>

Vous pouvez affecter au fichier de clés un nom approprié, parexemplews.key.

Configuration de la durée de vie des cookies

La valeur de la durée de vie des cookies (en minutes) est définie parle paramètre suivant :failover-cookie-lifetime = 60

Généralités sur la configuration de l’authentificationVous pouvez activer et désactiver l’authentification pour les clientsHTTP et HTTPS méthode par méthode.

Les mécanismes pour toutes les méthodes d’authentification prises encharge par WebSEAL sont configurés dans la strophe[authentication-mechanisms]du fichier de configurationwebseald.conf. Les paramètres de méthode d’authentificationacceptés sont les suivants :

¶ Authentificateurs locaux (intégrés)

Les paramètres des authentificateurs locaux spécifient les fichiersde bibliothèques partagées intégrés (UNIX) ou DLL (Windows).

104 Version 3.8

¶ Authentificateurs externes personnalisés

WebSEAL fournit un code serveur modèle qui vous permet dedéfinir et de spécifier un serveur CDAS (Cross DomainAuthentication Service) externe personnalisé.

Un authentificateur CDAS externe spécifie la bibliothèquepartagée personnalisée qui convient.

Paramètres d’authentification localeLes paramètres suivants spécifient les authentificateurs intégréslocaux :


Authentification de base et par formulaires

passwd-ldap Accès client avec nom d’utilisateur et mot de passeLDAP.

Authentification par jeton

token-cdas Accès client avec nom d’utilisateur LDAP etpasscode de jeton SecurID.

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 adresseIP

Authentification par jeton d’ID CDSSO

cdsso Authentification par connexion uniqueinterdomaine.

Vous pouvez utiliser la strophe[authentication-mechanisms]pourconfigurer la méthode d’authentification et la mise en oeuvre dans leformat suivant :<paramètre_de_méthode_d'authentification> =<bibliothèque_partagée>

Voir la section «Références à des informations de configurationdétaillées» à la page 90.


4.A

uthentificationW

ebSE

AL

Paramètres d’authentification CDAS personnaliséeexterne

Les paramètres suivants sont disponibles pour définir lesbibliothèques partagées personnalisées pour les serveurs CDASexternes :


passwd-cdas Accès client avec nom d’utilisateur et mot de passepour un registre tiers.

token-cdas Accès client avec nom d’utilisateur et passcode dejeton.

cert-cdas Accès client avec certificat côté client via SSL.

Pour plus d’informations sur la création et la configuration d’unebibliothèque partagée personnalisée qui met en oeuvre un serveurCDAS, reportez-vous au documentTivoli SecureWay Policy DirectorWebSEAL Developer Reference.

Configuration par défaut pour l’authentificationWebSEAL

Par défaut, WebSEAL est défini pour authentifier des clients via SSLen utilisant les noms d’utilisateur et les mots de passe del’authentification de base (BA) (registre LDAP).

WebSEAL est normalement activé pour les accès TCP et SSL. Uneconfiguration classique de la strophe[authentification-mechanismsinclut donc la prise en charge du nom d’utilisateur et du mot depasse (registre LDAP), ainsi que celle des certificats côté client viaSSL.

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 leparamètre approprié avec sa bibliothèque partagée (ou le module

106 Version 3.8

CDAS). Pour plus d’informations sur la configuration de chaqueméthode d’authentification, reportez-vous à la section «Références àdes informations de configuration détaillées» à la page 90.

Configuration de plusieurs méthodesd’authentification

Pour définir la bibliothèque partagée à utiliser pour une méthoded’authentification prise en charge, modifiez la strophe[authentication-mechanism]du fichier de configurationwebseald.conf. Les conditions suivantes s’appliquent lorsque vousconfigurez plusieurs méthodes d’authentification :

1. Toutes les méthodes d’authentification peuvent fonctionner defaçon indépendante. Vous pouvez configurer une bibliothèquepartagée pour chaque méthode prise en charge.

2. La méthodecert-cdasprévaut sur la méthodecert-ssllorsqu’elles sont toutes les deux configurées. Vous devez activerl’une ou l’autre de ces méthodes pour prendre en charge lescertificats côté client.

3. Seul un authentificateur par mot de passe est réellement utilisélorsque plusieurs authentificateurs de ce type sont configurés.WebSEAL utilise l’ordre de priorité suivant en cas deconfiguration de plusieurs authentificateurs par mot de passe :

a. passwd-cdas

b. passwd-ldap

4. Il est possible de configurer la même bibliothèque personnaliséepour deux méthodes d’authentification différentes. Par exemple,vous pouvez écrire une bibliothèque partagée personnalisée pourtraiter à la fois l’authentification par nom d’utilisateur/mot depasse et l’authentification par en-tête HTTP. Dans cet exemple,les paramètrespasswd-cdaset http-request doivent êtreconfigurés avec la même bibliothèque partagée. Le développeurdoit gérer l’état de session et éviter les conflits entre les deuxméthodes.


4.A

uthentificationW

ebSE

AL

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 utilisantl’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é client

b. Cookie de secours

c. CDSSO

d. Adresse IP

e. En-tête HTTP

2. Lorsqu’un client s’authentifie avec une méthode désactivée parWebSEAL

Commandes de déconnexion et de modification demot de passe

Policy Director fournit les commandes suivantes pour prendre encharge les clients qui s’authentifient via HTTP ou SSL.

pkmslogoutLes clients peuvent exécuter la commandepkmslogout pour sedéconnecter de la session courante lorsqu’ils utilisent une méthoded’authentification qui ne fournit pas de données d’authentificationavec chaque requête. Par exemple,pkmslogout ne fonctionne paspour les clients utilisant l’authentification de base oul’authentification par adresse IP. Dans ce cas, vous devez fermer lenavigateur pour vous déconnecter.

108 Version 3.8

La commandepkmslogout est appropriée pour l’authentification parcertificat côté client, les codes de jeton, l’authentification parformulaires et certaines mises en oeuvres de l’authentification paren-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 lefichier de configurationwebseald.conf :[acnt-mgt]logout = logout.html

Vous pouvez modifier le fichierlogout.html selon vos besoins.

L’utilitaire pkmslogout accepte également plusieurs pages deréponse de déconnexion lorsque l’architecture de réseau exigedifférents écrans de sortie pour les utilisateurs se déconnectant desystè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 deréponse de déconnexion. Ce fichier doit se trouver dans le répertoirelib/html/C, qui contient le fichierlogout.html par défaut etd’autres modèles de formulaires de réponse HTML.

pkmspasswdVous pouvez utiliser cette commande pour modifier votre mot depasse de connexion lorsque vous utilisez l’authentification de base(BA) ou par l’authentification par formulaires. Elle est adaptée auprotocole HTTP ou HTTPS.

Par exemple :https://www.tivoli.com/pkmspasswd


4.A

uthentificationW

ebSE

AL

Pour optimiser la sécurité lorsque l’authentification BA est utiliséeavec WebSEAL, cette commande présente le comportement suivantpour un client BA :

1. Le mot de passe est modifié.

2. L’utilisateur client est déconnecté de la session courante.

3. Lorsque le client effectue une autre requête, le navigateur luienvoie une invite BA.

4. Le client doit se reconnecter pour continuer à effectuer desrequêtes.

Ce scénario s’applique uniquement à un client utilisantl’authentification de base.

Configuration de l’authentification de baseL’authentification de base (BA) est une méthode standard qui permetde fournir un nom d’utilisateur et un mot de passe au systèmed’authentification. Définie par le protocole HTTP, elle peut être miseen oeuvre via HTTP et via HTTPS.

Par défaut, WebSEAL est configuré pour une authentification viaHTTPS au moyen d’une authentification de base (BA) par nomd’utilisateur et mot de passe.

Activation et désactivation de l’authentification debase

Le paramètreba-auth, situé dans la strophe[ba] du fichier deconfigurationwebseald.conf, active et désactive la méthoded’authentification de base.

¶ Pour activer la méthode d’authentification de base, entrez “http”,“https” ou “both”.

¶ Pour désactiver la méthode d’authentification de base, entrez“none”.

110 Version 3.8

Par exemple :[ba]ba-auth = https

Définition du nom de celluleLe nom de cellule est le texte contenu dans la boîte de dialogue quis’affiche lorsque le navigateur invite l’utilisateur à entrer les donnéesde connexion.

Le paramètre de configuration qui définit le nom de domaine estsitué dans la strophe[ba] du fichier de configurationwebseald.conf.

Par exemple :[ba]basic-auth-realm = Policy Director

Configuration de la méthode d’authentification debase

Le paramètrepasswd-ldapdéfinit la bibliothèque partagée utiliséepour gérer l’authentification par nom d’utilisateur et mot de passe.

Figure 15. Invite de connexion BA


4.A

uthentificationW

ebSE

AL

¶ Sous UNIX, le fichier fournissant la fonction de mappageintégrée est la bibliothèque partagéelibldapauthn .

¶ Sous Windows, le fichier fournissant la fonction de mappageintégrée est la DLLldapauthn.


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’utilisateuret mot de passe, entrez le paramètrepasswd-ldapavec le nom dufichier de bibliothèque partagée correspondant à la plate-formeutilisée, dans la strophe[authentication-mechanism]du fichier deconfigurationwebseald.conf. Par exemple :

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 transportspécifique, les paramètres de l’authentification de basecorrespondants seront ignorés.

Configuration de l’authentification par formulairesPolicy Director propose l’authentification par formulaires commesolution alternative à la méthode classique d’authentification de base.Avec cette méthode, un masque (ou formulaire) de connexion HTMLpersonnalisé est fourni par Policy Director au lieu de l’invite deconnexion classique résultant d’une demande d’authentification debase.

112 Version 3.8

Lorsque vous utilisez une connexion par formulaires, le navigateurne place pas les informations de nom d’utilisateur et de mot de passedans la mémoire cache, comme avec une authentification de base.

Activation et désactivation de l’authentification parformulaires

Le paramètreforms-auth, situé dans la strophe[forms] du fichier deconfigurationwebseald.conf, active et désactive la méthoded’authentification par formulaires.

¶ Pour activer la méthode d’authentification par formulaires, entrez“http”, “https” ou “both”.

¶ Pour désactiver la méthode d’authentification par formulaires,entrez “none”.

Par exemple :[forms]forms-auth = https

Configuration de la méthode d’authentification parformulaires

Le paramètrepasswd-ldapdéfinit la bibliothèque partagée utiliséepour gérer l’authentification par nom d’utilisateur et mot de passe.

¶ Sous UNIX, le fichier fournissant la fonction de mappageintégrée est la bibliothèque partagéelibldapauthn .

¶ Sous Windows, le fichier fournissant la fonction de mappageintégrée est la DLLldapauthn.




passwd-ldap libldapauthn.so libldapauthn.a ldapauthn.dll libldapauthn.sl


4.A

uthentificationW

ebSE

AL

Pour configurer la méthode d’authentification par nom d’utilisateuret mot de passe, entrez le paramètrepasswd-ldapavec le nom dufichier de bibliothèque partagée correspondant à la plate-formeutilisée, dans la strophe[authentication-mechanism]du fichier deconfigurationwebseald.conf. Par exemple :

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 transportspécifique, les paramètres de l’authentification de basecorrespondants seront ignorés.

Personnalisation des formulaires de réponse HTMLL’authentification par formulaires exige que vous utilisiez unformulaire de connexion personnalisé. Par défaut, le formulairemodèlelogin.html est situé dans le répertoire suivant :<répertoire_installation>/lib/html

114 Version 3.8

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 de pages HTMLpersonnalisées» à la page 40.

Configuration de l’authentification par certificat côtéclient

WebSEAL prend en charge les communications sécurisées avec lesclients grâce à des certificats numériques côté client via SSL. Aveccette méthode d’authentification, les informations de certificat(comme le nom distinctif ou DN) sont mises en correspondance avecune identité Policy Director.

Contexte : Authentification réciproque via descertificats

L’authentification via des certificats numériques s’effectue en deuxétapes :

¶ WebSEAL s’identifie auprès des clients SSL avec son certificatcôté serveur.

Figure 16. Exemple de formulaire de connexion WebSEAL


4.A

uthentificationW

ebSE

AL

¶ WebSEAL se réfère à la base de données de certificats racine del’autorité de certification (CA) pour valider les clients dotés decertificats côté client

1. Un client SSL demande une connexion à un serveur WebSEAL.

2. En réponse, WebSEAL envoie sa clé publique via un certificatsigné côté serveur. Ce certificat a été préalablement signé parune autorité de certification (CA) tierce digne de confiance.

3. Le client vérifie si l’émetteur du certificat est fiable. Lenavigateur du client contient habituellement une liste decertificats racine provenant de CA dignes de confiance. Si lasignature du certificat WebSEAL correspond à l’une de cescertificats racine, le serveur peut être jugé fiable.

4. Si la signature ne correspond à rien, le navigateur informe sonutilisateur que ce certificat a été émis par une autorité decertification inconnue. Il incombe alors à l’utilisateur d’accepterou de refuser le certificat.

5. Si la signature correspond à une entrée de la base de donnéesdes certificats racine du navigateur, les clés de la session sontnégociées de façon sécurisée entre le client et le serveurWebSEAL.

Le résultat final de ce processus est une voie de transmissionsécurisée via laquelle le client peut s’authentifier (par exemple,

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 17. Le client valide le certificat WebSEAL

116 Version 3.8

via un nom d’utilisateur et un mot de passe). Après uneauthentification réussie, le client et le serveur peuvent continuerà dialoguer de façon sécurisée via cette voie de transmission.

6. Le client envoie alors son certificat de clé publique au serveurWebSEAL.

7. WebSEAL essaie de faire correspondre la signature du certificatclient à une CA connue. Comme le navigateur d’un client, leserveur WebSEAL conserve une liste de certificats racineprovenant de CA dignes de confiance dans sa base de donnéesde clés.

8. En l’absence de toute correspondance avec la signature,WebSEAL génère un code d’erreur SSL qu’il envoie au client.

9. Si une correspondance existe, le client est fiable.L’authentification du client a lieu, et entraîne une identitéPolicy Director.

10. Les clés de la session sont négociées de façon sécurisée entre leclient et le serveur WebSEAL. Le résultat final de ce processusest une voie de transmission sécurisée et fiable entre le client etle serveur, authentifiés de façon réciproque.

Certificat de test WebSEALA l’installation, WebSEAL contient un certificat de serveur de testd’auto-signature. Bien que ce dernier lui permette de répondre à unerequête d’un navigateur SSL, il ne peut pas être vérifié par lenavigateur (qui ne contient pas de certificat d’autorité de certificationracine approprié). Comme la clé privée de ce certificat par défaut setrouve 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èsimportant de s’inscrire à un certificat de serveur de site unique, et del’obtenir auprès d’une autorité de certification digne de confiance.Vous pouvez utiliser l’utilitaire GSKitiKeyman pour générer unedemande de certificat qui est envoyée à la CA. Vous pouvezégalement vous servir deiKeyman pour installer le nouveaucertificat de site et lui affecter un libellé. Utilisez le paramètrewebseal-cert-keyfile-labelcontenu dans la strophe[ssl] du fichier de


4.A

uthentificationW

ebSE

AL

configurationwebseald.conf pour désigner le certificat commecertificat côté serveur WebSEAL actif (ce paramètre remplace tousles 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 utiliser l’utilitaireiKeyman pour créer ces certificatssupplémentaires, les installer et leur affecter un libellé.

Voir la section «Configuration des paramètres de la base de donnéesde clés pour WebSEAL» à la page 46.

Voir la section «Gestion de certificats avec iKeyman» à la page 279.

Activation et désactivation de l’authentification parcertificat

Vous pouvez spécifier la façon dont WebSEAL doit gérerl’authentification au moyen de certificats côté client via SSL endé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 sontoptional 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 estfourni.

118 Version 3.8

Valeur Description

required Demande aux clients un certificat X.509 et utilise uneauthentification basée sur certificat. Si le client neprésente pas de certificat, ne permet pas deconnexion.

Configuration de la méthode d’authentification parcertificat

Le paramètrecert-ssl spécifie la bibliothèque partagée servant aumappage des informations sur l’authentification par certificat.

¶ Sous UNIX, le fichier fournissant la fonction de mappageintégrée est la bibliothèque partagéelibsslauthn.

¶ Sous Windows, le fichier fournissant la fonction de mappageintégrée est la DLLsslauthn.




cert-ssl libsslauthn.so libsslauthn.a sslauthn.dll libsslauthn.sl

Pour configurer la méthode d’authentification par certificat, entrez leparamètrecert-ssl avec le nom du fichier de bibliothèque partagéecorrespondant à la plate-forme utilisée dans la strophe[authentication-mechanism]du fichier de configurationwebseald.conf.

Solaris :[authentication-mechanisms]cert-ssl= libsslauthn.so

Windows :[authentication-mechanisms]cert-ssl = sslauthn.dll

Le mappage par défaut fourni par le fichier de bibliothèque partagéefait directement correspondre un DN de certificat à un DN LDAP.


4.A

uthentificationW

ebSE

AL

Conditions de configurationSi le paramètreaccept-client-certs(acceptation des certificats côtéclient) a la valeur “required”, tous les autres paramètresd’authentification sont ignorés pour les clients HTTPS.

Configuration de l’authentification par en-tête HTTPPolicy Director prend en charge l’authentification au moyend’informations d’en-tête HTTP personnalisées fournies par le clientou par un agent proxy.

Cette méthode exige une fonction de mappage (une bibliothèquepartagée) qui fait correspondre les données d’en-tête (avantauthentification) avec une identité Policy Director. A partir de cetteidentité, WebSEAL peut créer des droits d’accès pour l’utilisateur.

Les données d’en-tête HTTP personnalisées sont supposées avoir étépréalablement authentifiées. C’est la raison pour laquelle il estrecommandé de mettre en oeuvre cette méthode de façon exclusive(sans qu’aucune autre méthode d’authentification ne soit activée). Ilest possible d’usurper les données d’en-tête HTTP personnalisées.

Par défaut, cette bibliothèque partagée est constituée pour fairecorrespondre des données provenant d’en-têtes Entrust Proxy.

Activation et désactivation de l’authentification paren-tête HTTP

Le paramètrehttp-headers-auth, situé dans la strophe[http-headers] du fichier de configurationwebseald.conf, active etdésactive la méthode d’authentification par en-tête HTTP.

¶ Pour activer la méthode d’authentification par en-tête HTTP,entrez “http”, “https” ou “both”.

¶ Pour désactiver la méthode d’authentification par en-tête HTTP,entrez “none”.

Par exemple :[http-headers]http-headers-auth = https

120 Version 3.8

Spécification des types d’en-têteVous devez spécifier tous les types d’en-tête HTTP pris en chargedans la strophe[auth-headers] du fichier de configurationwebseald.conf.[auth-headers]header = <type_en_tête>

Par défaut, cette bibliothèque intégrée est définie (dans le code) pourprendre en charge les données d’en-tête Entrust Proxy.[auth-headers]header = entrust-client

Vous devez personnaliser ce fichier pour authentifier d’autres typesde données d’en-tête spéciales et, en option, faire correspondre cesdonnées à l’identité Policy Director. Pour plus d’informations sur lesressources API, reportez-vous au documentTivoli SecureWay PolicyDirector WebSEAL Developer Reference.

Configuration du mécanisme d’authentification paren-tête HTTP

Le paramètrehttp-request spécifie la bibliothèque partagée servantau mappage des informations sur l’authentification par en-tête HTTP.

¶ Sous UNIX, le fichier fournissant la fonction de mappageintégrée est la bibliothèque partagéelibhttpauthn .

¶ Sous Windows, le fichier fournissant la fonction de mappageintégrée est la DLLhttpauthn .




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 lecode pour mapper les données d’en-tête Entrust Proxy à une identitéPolicy Director valide. Vous devez personnaliser ce fichier pourauthentifier d’autres types de données d’en-tête spéciales et,éventuellement, faire correspondre ces données à l’identité Policy


4.A

uthentificationW

ebSE

AL

Director. Pour plus d’informations sur les ressources API,reportez-vous au documentTivoli SecureWay Policy DirectorWebSEAL Developer Reference.

Pour configurer la méthode d’authentification par en-tête HTTP,entrez le paramètrehttp-request avec le nom du fichier debibliothèque partagée correspondant à la plate-forme utilisée dans lastrophe[authentication-mechanism]du fichier de configurationwebseald.conf.

Par exemple :

Solaris :[authentication-mechanisms]http-request = libhttpauthn.so

Windows :[authentication-mechanisms]http-request = httpauthn.dll

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érerl’état.

2. Si le client rencontre un problème d’autorisation, il reçoit unepage de type “Accès interdit” (HTTP 403).

Configuration de l’authentification par adresse IPPolicy Director prend en charge l’authentification via une adresse IPfournie par le client.

Activation et désactivation de l’authentification paradresse IP

Le paramètreipaddr-auth , situé dans la strophe[ipaddr] du fichierde configurationwebseald.conf, active et désactive la méthoded’authentification par adresse IP.

122 Version 3.8

¶ Pour activer la méthode d’authentification par adresse IP, entrez“http”, “https” ou “both”.

¶ 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 paradresse IP

L’authentification via une adresse IP nécessite une bibliothèquepartagée personnalisée. Utilisez le paramètrehttp-request pour cettebibliothèque partagée.

Configuration de l’authentification par jetonPolicy Director prend en charge l’authentification via un passcode dejeton fourni par le client.

Activation et désactivation de l’authentification parjeton

Le paramètretoken-auth, situé dans la strophe[token] du fichier deconfigurationwebseald.conf, active et désactive la méthoded’authentification par jeton.

¶ Pour activer la méthode d’authentification par jeton, entrez“http”, “https” ou “both”.

¶ Pour désactiver la méthode d’authentification par jeton, entrez“none”.

Par exemple :[token]token-auth = https


4.A

uthentificationW

ebSE

AL

Configuration de la méthode d’authentification parjeton

Le paramètretoken-cdasspécifie la bibliothèque partagée servant aumappage des informations sur l’authentification par passcode dejeton.

¶ Sous UNIX, le fichier fournissant la fonction de mappageintégrée est la bibliothèque partagéelibtokenauthn.

¶ Sous Windows, le fichier fournissant la fonction de mappageintégrée est la DLLtokenauthn.




token-cdas libtokenauthn.so libtokenauthn.a tokenauthn.dll libtokenauthn.sl

Par défaut, cette bibliothèque partagée intégrée est définie dans lecode pour mapper les données de passcode de jeton SecurID. Vouspouvez personnaliser ce fichier pour authentifier d’autres types dedonnées de jeton spéciales et, éventuellement, mapper ces données àune identité Policy Director. Pour plus d’informations sur lesressources API, reportez-vous au documentTivoli SecureWay PolicyDirector WebSEAL Developer Reference.

Pour configurer la méthode d’authentification par jeton, entrez leparamètretoken-cdasavec le nom du fichier de bibliothèquepartagée correspondant à la plate-forme utilisée dans la strophe[authentication-mechanism]du fichier de configurationwebseald.conf.

Par exemple :

Solaris :[authentication-mechanisms]token-cdas = libtokenauthn.so

Windows :[authentication-mechanisms]token-cdas = tokenauthn.dll

124 Version 3.8

Prise en charge des agents MPA (Multiplexing ProxyAgents)

Policy Director fournit des solutions de protection des réseaux àl’aide d’un agent MPA (Multiplexing Proxy Agent).

Les agents SPA (Standard Proxy Agents) sont des passerelles prenanten charge des sessions client par client entre des clients et le serveurd’origine, via protocole SSL ou HTTP. WebSEAL peut appliquer uneauthentification SSL ou HTTP normale à ces sessions.

Les agents MPA (Multiplexing Proxy Agents) sont des passerellesqui permettent l’accès de plusieurs clients. Elles sont quelquefoisappelées passerelles WAP lorsque les clients ont un accès via unprotocole 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 voieapparaissent initialement comme plusieurs requêtes émanant d’unseul client. WebSEAL doit effectuer une distinction entrel’authentification du serveur MPA et l’authentificationsupplémentaire de chaque client.


4.A

uthentificationW

ebSE

AL

Dans la mesure où WebSEAL gère une session authentifiée pourl’agent MPA, il doit gérer simultanément des sessions séparées pourchaque client. Les données de session et la méthoded’authentification utilisée pour l’agent MPA doivent donc êtredifférentes de celles du client.

Méthodes d’authentification et type de données desession valides

Le type de données de session utilisé par l’agent MPA auprès deWebSEAL doit être distinct (différent) de celui du client. Le tableauci-après répertorie les types de session valides pour l’agent MPA etle 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

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 18. Communications via une passerelle MPA

126 Version 3.8

¶ Le client ne peut utiliser l’ID de session SSL comme type dedonnées de session.

¶ Par exemple, si l’agent MPA utilise un en-tête BA comme typede données de session, le client a le choix entre l’en-tête HTTPet le cookie uniquement.

¶ Si l’agent MPA utilise un en-tête HTTP comme données desession, le client peut utiliser un type d’en-tête HTTP différent.

¶ Le cookie du serveur ne contient que des informations desession ; il ne contient pas d’informations d’identité.

¶ Si la prise en charge de l’agent MPA est activée, la fonction dessl-id-sessionsest modifiée. Normalement, sissl-id-sessions=yes, seul l’ID de session SSL est utilisé pourgérer les sessions des clients HTTPS. Pour permettre à l’agentMPA de gérer une session avec un ID de session SSL et auxclients d’en gérer avec une autre méthode, cette restriction estsupprimée. Voir aussi la section «Identification des types dedonnées d’ID de session valides» à la page 100.

La méthode d’authentification utilisée par l’agent MPA auprès deWebSEAL doit être distincte (différente) de celle du client. Letableau ci-après répertorie les méthodes d’authentification validespour 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

¶ Par exemple, si l’agent MPA utilise l’authentification de base, leclient a le choix entre l’authentification par formulaires, parjeton et par en-tête HTTP.


4.A

uthentificationW

ebSE

AL

¶ Les méthodes d’authentification par certificats et par adresse IPne sont pas utilisables par le client.

¶ Normalement, si l’authentification par formulaires (ou par jeton)est activée pour un transport spécifique, l’authentification debase est automatiquement désactivée pour ce transport (voir lasection «Configuration de la méthode d’authentification de base»à la page 111). Si la prise en charge de l’agent MPA est activée,cette restriction est supprimée. Cela permet, d’une part, à l’agentMPA de se connecter, par exemple avec des formulaires (ou desjetons) et, d’autre part, aux clients de se connecter à l’aide del’authentification de base via le même transport.

Flux du processus d’authentification pour des agentsMPA et plusieurs clients

1. L’administrateur WebSEAL effectue la configurationpréliminaire suivante :

¶ Activation de la prise en charge des agents MPA

¶ Création d’un compte Policy Director pour la passerelleMPA spécifique

¶ Ajout de ce compte MPA au groupewebseal-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 larequête du client.

6. WebSEAL authentifie l’agent MPA (avec une méthodedifférente de celle du client) et déduit son identité (lequel MPAdétient déjà un compte WebSEAL).

7. WebSEAL vérifie l’appartenance de l’agent MPA au groupewebseal-mpa-servers.

8. Un droit d’accès est établi pour le MPA et marqué comme typede MPA spécial dans la mémoire cache.

128 Version 3.8

Bien que ce droit d’accès MPA accompagne chaque nouvellerequête du client, il n’est pas utilisé pour les contrôlesd’autorisation menés sur ces requêtes.

9. WebSEAL doit maintenant identifier plus précisément lepropriétaire de la requête.

L’agent MPA est capable de faire la distinction entre lesdifférents clients pour acheminer correctement les invites deconnexion.

10. Le client se connecte et s’authentifie à l’aide d’une méthodedifférente du type d’authentification utilisé par l’agent MPA.

11. WebSEAL crée un droit d’accès à partir des informationsd’authentification du client.

12. Le type de données de session utilisé par chaque client doit êtredifférent de celui de l’agent MPA.

13. Le service d’autorisation accorde ou refuse l’accès aux objetsprotégés, en se fondant sur les droits d’accès de l’utilisateur etles droits d’accès de LCA des objets.

Activation et désactivation de l’authentification MPALe paramètrempa, situé dans la strophe[mpa] du fichier deconfigurationwebseald.conf, active et désactive l’authentificationMPA :

¶ Pour activer la méthode d’authentification MPA, entrez “yes”.

¶ 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 aux documentsTivoli SecureWay Policy Director Base- Guide d’administrationet Tivoli SecureWay Policy Director WebPortal Manager - Guide d’administration.


4.A

uthentificationW

ebSE

AL

Ajout du compte MPA au groupe webseal-mpa-serversPour plus d’informations sur la gestion des groupes, reportez-vousaux documentsTivoli SecureWay Policy Director Base - Guided’administrationet Tivoli SecureWay Policy Director Web PortalManager - Guide d’administration.

Limites de l’authentification MPACette édition de Policy Director n’accepte qu’un agent MPA parserveur WebSEAL.

130 Version 3.8

Solutions de connexioninterdomaine

Lorsque WebSEAL est mis en oeuvre en tant que serveur proxy pourprotéger un domaine sécurisé, il est souvent nécessaire de fournir dessolutions de connexion unique (SSO) aux ressources. Ce chapitretraite de deux solutions de connexion unique interdomaine (CDSSO).


¶ «Configuration de l’authentification CDSSO» à la page 131

¶ «Configuration de la connexion unique de la communautéélectronique» à la page 138

Configuration de l’authentification CDSSOLe mécanisme CDSSO (Cross Domain Single Sign-on ou connexionunique interdomaine) de Policy Director permet de transférer lesdonnées d’autorisation d’un utilisateur entre plusieurs domainessécurisés. CDSSO permet aux utilisateurs Web d’effectuer uneconnexion unique et de passer en douceur d’un domaine sécurisé àun autre. La méthode d’authentification CDSSO ne repose pas sur unserveur d’authentification principal (voir la section Configuration dela connexion unique de la communauté électronique).

CDSSO répond aux objectifs d’une architecture de réseau évolutiveen permettant l’intégration de plusieurs domaines sécurisés. Parexemple, il est possible de mettre sur pied un grand extranet

5


5.S

olutionsde

connexioninterdom

aine

d’entreprise à partir d’au moins deux domaines uniques, chacunpossédant ses propres utilisateurs et espace objet. CDSSO permetaux utilisateurs de passer d’un domaine à l’autre avec une connexionunique.

Lorsqu’un utilisateur demande une ressource située dans un autredomaine, le mécanisme CDSSO transfère un jeton d’identitéd’utilisateur d’un domaine à l’autre. Le deuxième domaine disposealors de l’identité de l’utilisateur (tel qu’il est authentifié dans lepremier domaine), et l’utilisateur n’est pas obligé d’effectuer uneautre connexion.

Intégration d’une bibliothèque partagée CDMFpersonnalisée

Dans plusieurs scénarios CDSSO, il se peut que le mappage un à unpar défaut entre les utilisateurs de différents domaines ne répondentpas à tous les besoins en matière de déploiement.

L’interface de programmation CDMF (Cross Domain MappingFrameWork) permet de créer une bibliothèque partagée personnaliséepouvant gérer des attributs utilisateur étendus et fournir des servicesde mappage pour l’identité des utilisateurs.

L’interface de programmation CDMF permet de personnaliser lemappage des identités d’utilisateur et de traiter les attributsutilisateur avec une certaine souplesse.

Flux du processus d’authentification pour CDSSOavec CDMF

figure 19 illustre la description du flux de processus suivant.

1. Tout utilisateur souhaitant participer à plusieurs domaines doitposséder un compte utilisateur valide dans le domaine principalet une identité pouvant être mappée dans un compte valide danschacun des domaines distants participants.

Un utilisateur peut appeler la fonctionnalité CDSSO sanss’authentifier préalablement auprès d’un domaine sécurisé initial(A) contenant le compte de l’utilisateur.

132 Version 3.8

2. L’utilisateur effectue une requête d’accès à une ressource setrouvant dans le domaine B via un lien personnalisé sur une pageWeb.

Le lien contient une expression CDSSO spéciale :/pkmscdsso?<URL_de_destination>

Par exemple :/pkmscdsso?https://www.domainB.com/index.html

3. Le serveur WebSEAL du domaine A traite la requête en premier.WebSEAL établit un jeton d’authentification contenant l’identitéPolicy Director de l’utilisateur (nom abrégé), le domaine courant(“A”), des informations supplémentaires sur l’utilisateur ainsiqu’une horodate.

Les autres informations sur l’utilisateur sont obtenues en appelantla bibliothèque partagée CDMF personnalisée(cdmf_get_usr_attributes). Celle-ci fournit des attributsutilisateur que peut utiliser le domaine B lors du processus demappage des utilisateurs.

La norme Triple DES de WebSEAL chiffre ces données de jetonavec la clé symétrique générée par l’utilitairecdsso_key_gen. Cefichier de clés est partagé et stocké dans la strophe[cdsso-peers]du fichier de configurationwebseald.conf des serveursWebSEAL du domaine A et du domaine B.

Le jeton contient une horodate configurable (authtoken-lifetime)qui définit sa durée de vie. La valeur d’horodatage, si elle estcorrectement configurée, peut constituer une protection contredes tentatives malveillantes de réexécution.

4. Le serveur WebSEAL du domaine A réachemine la requête plusle jeton chiffré vers le navigateur, puis vers le serveur WebSEALdu domaine B (réacheminement HTTP).

5. Le serveur WebSEAL du domaine B utilise sa version du mêmefichier de clés pour déchiffrer et valider le jeton, commeprovenant du domaine de référence.

6. Le serveur WebSEAL du domaine B fait appel à unebibliothèque de méthodes d’authentification CDSSO. A son tour,


5.S

olutionsde

connexioninterdom

aine

cette bibliothèque CDSSO fait appel à la bibliothèque CDMFpersonnalisée qui effectue le mappage de l’utilisateur proprementdit (cdmf_map_usr).

La bibliothèque CDMF retransmet à la bibliothèque CDSSOl’identité de l’utilisateur et, éventuellement, d’autres informationssur ses attributs. La bibliothèque CDSSO utilise ces informationspour créer une autorisation.

7. Le service d’autorisation du domaine B accorde ou refuse l’accèsaux objets protégés, en se fondant sur les autorisations del’utilisateur et les droits d’accès de LCA associés aux objetsdemandés.

Activation et désactivation de l’authentificationCDSSO

Le paramètrecdsso-auth, situé dans la strophe[cdsso]du fichier deconfigurationwebseald.conf, active et désactive la méthoded’authentification CDSSO.

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 19. Processus de connexion unique interdomaine avec CDMF

134 Version 3.8

¶ Pour activer la méthode d’authentification CDSSO, entrez “http”,“https” ou “both”.

¶ 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 configurationcdssospécifie la bibliothèque partagéedéfinie dans le code servant au mappage des informationsd’authentification.

¶ Sous UNIX, le fichier fournissant la fonction de mappage intégréest la bibliothèque partagéelibcdssoauthn.

¶ Sous Windows, le fichier fournissant la fonction de mappageintégré est le DLLcdssoauthn.




cdsso libcdssoauthn.so libcdssoauthn.a cdssoauthn.dll libcdssoauthn.sl

Pour configurer la méthode d’authentification CDSSO, indiquez leparamètrecdssoavec le nom du fichier de bibliothèque partagéecorrespondant à la plate-forme utilisée, dans la strophe[authentication-mechanism]du fichier de configurationwebseald.conf.

Par exemple :

Solaris :[authentication-mechanisms]cdsso = libcdssoauthn.so


5.S

olutionsde

connexioninterdom

aine

Windows :[authentication-mechanisms]cdsso = cdssoauthn.dll

Chiffrement des données d’authentification du jetonWebSEAL doit chiffrer les données d’authentification placées sur lejeton à l’aide d’une clé générée par l’utilitairecdsso_key_gen. Vousdevez “synchroniser” cette clé en partageant le fichier de clés avecchaque serveur WebSEAL de chaque domaine participant. Chacundes serveurs WebSEAL participant à chaque domaine doit utiliser lamême clé.

Remarque : La création et la distribution de fichiers de clés ne faitpas partie du processus CDSSO de Policy Director.

L’utilitaire cdsso_key_genexige 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 fichier de configurationwebseald.conf du serveurWebSEAL de chaque domaine. Le format inclut le nom de lamachine 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

136 Version 3.8

Dans l’exemple ci-dessus, le fichier A-B.key serait généré sur unemachine (WebSEAL A, par exemple), puis copié manuellement (etde façon sécurisée) sur l’autre machine (WebSEAL B, par exemple).

Configuration de l’horodate du jetonLe jeton contient une horodate configurable qui définit la durée devie du jeton d’identité. Une fois l’horodate expirée, le jeton estconsidéré comme non valide et n’est plus utilisé. Cette horodatepermet d’éviter les tentatives malveillantes de réexécution endéfinissant une valeur suffisamment courte pour éviter le vol dujeton et sa réexécution pendant sa durée de vie.

Le paramètreauthtoken-lifetime, situé dans la strophe[cdsso]dufichier de configurationwebseald.conf définit la valeur de la duréede vie du jeton. La valeur est exprimée en secondes. La valeur pardéfaut est 180 :[cdsso]authtoken-lifetime = 180

Vous devez prendre en compte tout décalage horaire entre lesdomaines participants.

Expression des liens HTML CDSSOLes liens HTML à des ressources d’un domaine sécurisé secondairedoivent contenir 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’informationsd’authentification (comme un nom d’utilisateur et un mot de passe),mais une identité d’utilisateur qui est sécurisée dans le domainerécepteur. Il convient donc de protéger le jeton lui-même contre levol et la réexécution.


5.S

olutionsde

connexioninterdom

aine

Pour la protection contre le vol, le protocole SSL est utilisé pourprotéger les communications entre les serveurs WebSEAL et lesutilisateurs. Un vol est possible au niveau de l’historique dunavigateur de l’utilisateur. Veillez à ce que l’horodate ait une valeursuffisamment 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é, restevulnérable à des agressions cryptographiques. Si la clé utilisée pourle chiffrer est découverte ou compromise d’une manière ou d’uneautre, un utilisateur malveillant pourrait constituer ses propres jetons.

Ces jetons pourraient alors être introduits dans un “fluxpseudo-CDSSO”. Ils seraient alors impossibles à distinguer desvéritables jetons d’authentification pour les serveurs WebSEALfaisant partie du domaine CDSSO. C’est la raison pour laquelle lesclé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 lacommunauté électronique

La connexion unique de la communauté électronique est une autreimplémentation de l’authentification interdomaine dans unenvironnement Policy Director. L’objectif de l’authentificationinterdomaine consiste à autoriser les utilisateurs à accéder auxressources via plusieurs serveurs de différents domaines sansnouvelle authentification.

Une “communauté électronique” est un groupe de domaines distincts(Policy Director ou DNS) liés par une relation de natureéconomique. Ces domaines participants peuvent être configuréscomme appartenant à une seule et même entreprise (etéventuellement sous différents noms DNS pour des raisonsgéographiques) ou à plusieurs entreprises distinctes ayant encommun, par exemple, des locaux, une compagnie d’assurance vieou une société de gestion financière.

138 Version 3.8

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étient les accords qui régissent la communautéélectronique.

Dans les deux scénarios, les informations d’authentification sur lesutilisateurs appartenant à la communauté électronique (y compris lesnoms d’utilisateur et les mots de passe utilisés pourl’authentification) sont conservées dans le domaine d’accueil. Cetteorganisation permet de cantonner à un unique point de référence lesquestions administratives. Par exemple, toutes les demandesd’assistance émanant de la communauté électronique sont dirigéesvers le domaine d’accueil.

De même, vous pouvez utiliser Policy Director Web Portal Managerpour déléguer la gestion de ces informations afin que les domainesparticipants prennent en charge l’administration de leurs propresutilisateurs.

Le diagramme ci-après illustre un exemple de communautéélectronique comprenant deux domaines participants : le domaine A(dA.com) et le domaine B (dB.com). Dans cet exemple, le domaineA représente le domaine d’accueil ou propriétaire tandis que ledomaine B est un domaine participant ou “distant”.


5.S

olutionsde

connexioninterdom

aine

Le domaine d’accueil “détient” les utilisateurs (c’est-à-dire qu’ilcontrôle leurs informations d’authentification). Quel que soitl’emplacement d’où l’utilisateur effectue une requête sur lesressources, le domaine d’accueil se situe toujours sur le serveurauprès duquel il doit s’authentifier.

L’authentification s’effectue auprès d’un serveur d’authentificationprincipal MAS (Master Authentication Server), à savoir un serveur(ou un ensemble de répliques de serveur) situé dans le domained’accueil et configuré de façon à authentifier tous les utilisateurs.Dans le diagramme, mas.dA.com représente le serveur MAS. Vousdevez limiter les fonctions du serveur MAS aux servicesd’authentification. Ce serveur ne doit pas contenir de ressourcesutilisables par les utilisateurs.

Après avoir authentifié un utilisateur, le serveur MAS génère unjeton “d’attestation”. Celui-ci est retransmis au serveur lorsque

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 20. Modèle de communauté électronique

140 Version 3.8

l’utilisateur effectue la requête. Le serveur traite ce jeton“d’attestation” comme étant la preuve que l’utilisateur s’estauthentifié 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 est détaillé dans la section «Flux de processus de lacommunauté électronique» à la page 142.

Fonctions et conditions requises de la communautéélectronique

¶ Le modèle prend en charge l’accès aux ressources via desadresses URL (signets). Cette fonction contraste avec le modèleCDSSO reposant sur un lienpkmscdssoconfiguré d’unemanière particulière (voir «Configuration de l’authentificationCDSSO» à la page 131).

¶ L’implémentation de la communauté électronique nécessite uneconfiguration cohérente entre tous les serveurs WebSEAL detous les domaines de cette communauté.

¶ Tous les utilisateurs appartenant à la communauté électroniques’authentifient auprès d’un serveur MAS situé dans le domained’accueil.

¶ L’implémentation de la communauté électronique permetl’authentification “locale” dans les domaines distants sil’utilisateur n’a pas de compte valide avec le serveur MAS (parexemple, les utilisateurs appartenant au domaine B mais pas à lacommunauté électronique domaine A-domaine B).

Un utilisateur dont l’authentification auprès du serveur MAS aéchoué lors de la requête d’une ressource dans un domaine autreque celui de MAS (mais participant) peut s’authentifier auprèsdu serveur local sur lequel la requête est effectuée.

¶ Le serveur MAS (et éventuellement les autres serveurssélectionnés dans les domaines distants) “atteste” l’identitéauthentifiée de l’utilisateur.

¶ Les cookies spécifiques aux domaines servent à identifier leserveur permettant de fournir des services “d’attestation”. Les


5.S

olutionsde

connexioninterdom

aine

serveurs d’un domaine distant peuvent ainsi demander desinformations “d’attestation” localement. Le contenu chiffré descookies de communauté électronique n’inclut aucune informationsur la sécurité ou l’identité de l’utilisateur.

¶ Des jetons spéciaux sont utilisés pour transmettre l’identitéutilisateur “attestée” chiffrée. Le jeton “d’attestation” ne contientpas les informations d’authentification de l’utilisateur proprementdites. La clé secrète partagée (Triple DES) assure l’intégrité desdonnées. Le jeton contient un délai d’expiration (durée de vie)pour limiter la durée de validité du jeton.

¶ L’implémentation de la communauté électronique est prise encharge à la fois via HTTP et HTTPS.

¶ Chaque domaine de la communauté électronique gère l’identitéde ses propres utilisateurs ainsi que les privilèges associés. Vouspouvez utiliser l’API CDMF pour mapper un utilisateur issud’un domaine distant à un utilisateur valide du domaine local.

Si la communauté électronique partage des identités utilisateurglobales, cette fonction de mappage n’est pas obligatoire.

¶ La configuration de la communauté électronique est définie dansle fichier webseald.conf de chaque serveur WebSEALparticipant.

Flux de processus de la communauté électroniqueUne communauté électronique comprend un serveur MAS WebSEALainsi que d’autres serveurs WebSEAL situés dans le domained’accueil ou les domaines distants. Le serveur MAS peut être uneinstance unique d’un serveur WebSEAL ou un groupe de répliquesde serveur WebSEAL situées derrière un mécanisme d’équilibrage decharge (ce dernier étant identifié comme le serveur MAS).

Tous les serveurs WebSEAL locaux et distants participants doiventêtre configurés de façon à utiliser le serveur MAS du domained’accueil pour l’authentification initiale des clients. Il s’agit d’unecondition matérielle pour les serveurs du domaine d’accueil et d’unecondition 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

142 Version 3.8

ressources qu’ils protègent peuvent fonctionner indépendamment dela communauté électronique s’ils sont situés dans un domaine de lacommunauté.

L’implémentation de la communauté électronique repose sur unsystème “d’attestation”. Normalement, lorsqu’un utilisateur demandeune ressource à partir d’un serveur WebSEAL avec lequel il n’a pasétabli de session valide, WebSEAL lui demande des informationsd’authentification. Dans une configuration de communautéélectronique, le serveur WebSEAL identifie un serveur“d’attestation” et lui demande de vérifier si l’utilisateur s’estauthentifié.

Le serveur “d’attestation” dispose d’informations d’autorisation pourcet utilisateur. Pour la première requête de l’utilisateur, le serveur“d’attestation” est toujours le serveur MAS. Ce dernier sert toujoursde serveur “d’attestation” pour les ressources situées dans le domained’accueil. A mesure que l’utilisateur continue à effectuer desrequê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é issuesdu serveur MAS) et servir de serveur “d’attestation” pour lesressources de son domaine.

La vérification requise du serveur “d’attestation” prend la forme d’unjeton “d’attestation”. Le serveur “d’attestation” crée le jeton et lerenvoie au serveur WebSEAL émettant la requête. Les informationssur l’identité de l’utilisateur contenues 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 dela requête crée des autorisations ainsi qu’une session locale pour cetutilisateur. Celui-ci peut ensuite accéder à la ressource demandée enfonction des contrôles d’autorisation normaux. L’utilisateur n’a pasbesoin de s’authentifier une nouvelle fois (un des objectifs dumodèle de communauté électronique).


5.S

olutionsde

connexioninterdom

aine

Reportez-vous au diagramme ci-après tout au long du flux duprocessus de la communauté électronique jusqu’à la fin de cettesection. Le flux du processus décrit deux scénarios de PREMIERaccès possibles (1 et 2). Ceux-ci sont immédiatement suivis de deuxautres scénarios d’accès SUIVANT possibles (3 et 4). Le scénario 5peut intervenir à tout moment après le premier accès.

Serveurs“d’attestation”

¶ Le serveur MAS est toujours utilisé pour authentifier unutilisateur qui souhaite accéder à une partie de la communautéélectronique pour la première fois.

Il doit fonctionner comme un serveur d’authentificationuniquement et non pas comme un fournisseur de ressources. Leserveur MAS ne doit pas être configuré pour servir de serveurd’authentification principal et protéger les ressources en mêmetemps. Cette recommandation n’est pas une condition de sécuritéobligatoire mais elle affecte les performances.

¶ Le serveur MAS est toujours le serveur “d’attestation” pour ledomaine d’accueil (domaine A dans cet exemple).

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 21. Flux de processus de la communauté électronique

144 Version 3.8

¶ Un cookie de communauté électronique spécifique à un domaineest utilisé pour identifier le serveur “d’attestation” pour tous lesautres serveurs dans un domaine donné. Le serveur“d’attestation” est le premier serveur d’un domaine qui demandeun jeton “d’attestation” à partir du serveur MAS. Le serveur“d’attestation” fournit des informations “d’attestation” àl’utilisateur membre du domaine. Ce serveur peut émettrelocalement d’autres requêtes portant sur des services“d’attestation” dans un domaine distant défini, au lieu d’accéderau serveur MAS en dehors du domaine. Dans le domained’accueil, le cookie de communauté électronique identifie leserveur MAS comme étant le serveur “d’attestation”.

(1) PREMIER accès à la communauté électronique : WebSEAL1 (domaine A)

¶ L’utilisateur demande une ressource protégée par WebSEAL 1(dans le même domaine que celui du serveur MAS). Lenavigateur ne contient pas de cookie de communautéélectronique pour ce domaine. WebSEAL 1 ne dispose d’aucuneautorisation mise en mémoire cache pour l’utilisateur.

¶ WebSEAL 1 est configuré de façon à activer l’authentification dela communauté électronique et à spécifier l’emplacement duserveur MAS. Il réachemine le navigateur vers une adresse URL“d’attestation” spéciale sur le serveur MAS.

¶ Le serveur MAS reçoit la requête “d’attestation” et demande àl’utilisateur de se connecter car aucune autorisationcorrespondante n’a été trouvée.

¶ Une fois la connexion terminée, le serveur MAS crée uneautorisation pour l’utilisateur, la stocke dans la mémoire cache etréachemine le navigateur vers l’adresse URL demandée àl’origine sur WebSEAL 1 avec un jeton “d’attestation” chiffré.En outre, un cookie de communauté électronique spécifique audomaine A est placé sur le navigateur de façon à identifier leserveur “d’attestation” pour ce domaine (dans ce cas, le serveurMAS).

Si la tentative de connexion échoue, le serveur MAS renvoie unjeton “d’attestation” indiquant un état d’échec. Ce jeton est créé


5.S

olutionsde

connexioninterdom

aine

de façon à être indifférenciable d’un jeton “d’attestation”indiquant un état de succès. Le serveur émettant la demanderéagit à un jeton indiquant un état d’échec comme sil’authentification locale de l’utilisateur avait échoué.

¶ WebSEAL 1 déchiffre le jeton et crée sa propre autorisation pourl’utilisateur.

Remarque : Le mappage des identités ne doit pas êtreobligatoire dans le même domaine. Si c’est le cas,WebSEAL 1 doit utiliser la fonction CDMF.

¶ Le service d’autorisation accepte ou refuse la requête.

(2) PREMIER accès à la communauté électronique : WebSEAL3 (domaine B)

¶ L’utilisateur demande une ressource protégée par WebSEAL 3(domaine B distant). Le navigateur ne contient pas de cookie decommunauté électronique pour ce domaine. WebSEAL 3 nedispose d’aucune autorisation mise en mémoire cache pourl’utilisateur.

¶ WebSEAL 3 est configuré de façon à activer l’authentification dela communauté électronique et à spécifier l’emplacement duserveur MAS. Il réachemine le navigateur vers une adresse URL“d’attestation” spéciale sur le serveur MAS.

¶ Le serveur MAS reçoit la requête “d’attestation” et demande àl’utilisateur de se connecter car aucune autorisationcorrespondante n’a été trouvée.

¶ Une fois la connexion terminée, le serveur MAS crée uneautorisation pour l’utilisateur, la stocke dans la mémoire cache etréachemine le navigateur vers l’adresse URL demandée àl’origine sur WebSEAL 3 avec un jeton “d’attestation” chiffré.En outre, un cookie de communauté électronique spécifique audomaine A est placé sur le navigateur de façon à identifier leserveur “d’attestation” pour ce domaine (dans ce cas, le serveurMAS).

Si la tentative de connexion échoue, le serveur MAS renvoie unjeton “d’attestation” indiquant un état d’échec. Ce jeton est créé

146 Version 3.8

de façon à être indifférenciable d’un jeton “d’attestation”indiquant un état de succès. Le serveur émettant la demanderéagit à un jeton indiquant un état d’échec comme sil’authentification locale de l’utilisateur avait échoué.


¶ WebSEAL 3 crée et définit un second cookie de communautéélectronique (valide pour le domaine B) sur le navigateur, enidentifiant WebSEAL 3 comme étant le serveur “d’attestation”pour le domaine B.


(3) Accès SUIVANT à la communauté électronique : WebSEAL 2(domaine A)

¶ L’utilisateur demande une ressource protégée par WebSEAL 2(dans le même domaine que celui du serveur MAS). Lenavigateur contient un cookie de communauté électronique dudomaine 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 pourl’utilisateur.

¶ WebSEAL 2 est configuré de façon à activer l’authentification dela communauté électronique et à spécifier l’emplacement duserveur MAS. La présence du cookie de communautéélectronique du domaine A prévaut sur la configuration deWebSEAL 2 pour l’emplacement du serveur MAS. Le cookiefournit l’identité du serveur “d’attestation” à WebSEAL 2 (si lescénario 2 se produit en premier, un cookie du domaine B seraégalement maintenu sur le navigateur et ne sera envoyé à aucunserveur du domaine A).

¶ WebSEAL 2 réachemine le navigateur vers une adresse URL“d’attestation” spéciale sur le serveur “d’attestation” du domaineA identifié dans le cookie (dans ce cas, le serveur MAS carWebSEAL 2 est situé dans le domaine A).


5.S

olutionsde

connexioninterdom

aine

¶ Le serveur MAS reçoit la requête “d’attestation” et trouve lesautorisations pour cet utilisateur dans la mémoire cache(scénarios 1 et 2).

¶ Le serveur MAS réachemine le navigateur vers l’adresse URLdemandée initialement sur WebSEAL 2 avec un jeton“d’attestation” chiffré.



(4) Accès SUIVANT à la communauté électronique : WebSEAL 4(domaine B)

¶ L’utilisateur demande une ressource protégée par WebSEAL 4(domaine B distant). Si le scénario 2 se produit en premier, lenavigateur contient un cookie de communauté électronique dudomaine 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.

¶ WebSEAL 4 est configuré de façon à activer l’authentification dela communauté électronique et à spécifier l’emplacement duserveur MAS. La présence d’un cookie de communautéélectronique du domaine B prévaut sur la configuration deWebSEAL 4 pour l’emplacement du serveur MAS. Le cookiefournit l’identité du serveur “d’attestation” à WebSEAL 4 (si lescénario 1 se produit en premier, seul un cookie du domaine Asera maintenu sur le navigateur et ne sera envoyé à aucunserveur du domaine B). L’emplacement du serveur MASconfiguré sera utilisé à la place. WebSEAL 4 deviendra ensuitele serveur “d’attestation” pour le domaine B).

¶ Si le scénario 2 se produit en premier, WebSEAL 4 réacheminele navigateur vers une adresse URL “d’attestation” spéciale surle serveur “d’attestation” du domaine B identifié dans le cookiedu domaine B (dans ce cas, WebSEAL 3).

¶ WebSEAL 3 reçoit la requête “d’attestation” et trouve lesautorisations pour cet utilisateur dans la mémoire cache (scénario2).

148 Version 3.8

¶ WebSEAL 3 réachemine le navigateur vers l’adresse URLdemandée initialement sur WebSEAL 4 avec un jeton“d’attestation” chiffré.



(5) AUTRE accès à la communauté électronique : WebSEAL 2(domaine A)

¶ L’utilisateur se connecte à WebSEAL 2 (domaine A) avec unerequête. Si le scénario 3 se produit, WebSEAL 2 disposed’autorisations mises en mémoire cache pour l’utilisateur.


Déconnexion de la communauté électronique

¶ Si l’utilisateur se déconnecte en fermant le navigateur, lessessions SSL et les cookies de communauté électronique sonttous supprimés.

¶ S’il se déconnecte via la page/pkmslogout, la session SSL et lecookie de communauté électronique pour ce domaine sontsupprimés.

Explication du cookie de communauté électronique¶ Le cookie de communauté électronique est un cookie spécifique

au domaine défini par un serveur WebSEAL, stocké dans lamémoire du navigateur de l’utilisateur et transmis aux autresserveurs WebSEAL (du même domaine) lors des requêtessuivantes.

¶ Le cookie spécifique au domaine contient le nom du serveur“d’attestation”, l’identité de la communauté électronique,l’emplacement (adresse URL) du serveur et de la fonctionnalité“d’attestation” ainsi que la valeur de sa durée de vie. Le cookiene contient pas d’informations sur les utilisateurs.

¶ Le cookie de communauté électronique permet aux serveurs desdomaines participants de demander des informations


5.S

olutionsde

connexioninterdom

aine

“d’attestation” localement. Le cookie de communautéélectronique attaché au domaine sur lequel réside le serveurMAS joue un rôle moins important.

¶ La valeur de la durée de vie (délai d’expiration) du cookie estdéfinie dans le fichier de configurationwebseald.conf. Elledéfinit la durée pendant laquelle un serveur distant peut fournirdes informations “d’attestation” à l’utilisateur. Lorsque la duréede vie du cookie arrive à expiration, l’utilisateur doit êtreréacheminé vers le serveur MAS pour être authentifié.

¶ Lorsque le navigateur est fermé, le cookie est supprimé de lamémoire. Si l’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 supprime du navigateur.

Explication de la requête et de la réponse“d’attestation”

L’opération “d’attestation” de la communauté électronique nécessiteune fonctionnalité dédiée accessible par deux adresses URL crééestout spécialement : la requête “d’attestation” et la réponse“d’attestation”. Ces adresses URL sont définies lors desréacheminements HTTP “d’attestation” de la communautéélectronique en fonction des informations de configuration contenuesdans le fichierwebseald.conf.

Requête “d’attestation”

La requête “d’attestation” est déclenchée lorsqu’un utilisateurdemande une ressource à partir d’un serveur de destination(configuré pour la communauté électronique) qui ne contient pas dedonnées d’autorisation pour cet utilisateur. Le serveur envoie unré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>

150 Version 3.8

Le serveur récepteur vérifie la variablenom_communauté_électroniquepour valider l’identité de lacommunauté électronique. Le serveur récepteur utilise la variableURL_de_destinationdans la réponse “d’attestation” pour réacheminerle navigateur vers la page demandée initialement.

L’adresse URL “d’attestation” depkmsvouchfor est configurable.

Par exemple :https://mas.dA.com/pkmsvouchfor?companyABC&https://ws5.dB.com/index.html

Réponse “d’attestation”

La réponse “d’attestation” est la réponse du serveur “d’attestation”au serveur de destination.

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 afin de sélectionner la clé requise pourdéchiffrer le jeton “d’attestation” (PD-VF). Le paramètre PD-VFrepré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, certainesinformations sur l’identité de l’utilisateur doivent être transmisesentre les serveurs. Ces informations confidentielles sont gérées àl’aide d’un réacheminement qui inclut les informations d’identitéchiffrées dans l’adresse URL. Ces données chiffrées sont appeléesjeton “d’attestation” .

¶ 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


5.S

olutionsde

connexioninterdom

aine

complet du serveur ayant créé le jeton, l’identité de lacommunauté électronique ainsi que la date de création.

¶ Le détenteur d’un jeton “d’attestation” valide peut l’utiliser pourétablir une session (et un ensemble d’autorisations) sur unserveur sans avoir à s’authentifier auprès de lui de manièreexplicite.

¶ Le jeton est chiffré à l’aide d’une clé secrète Triple DESpartagée de façon à vérifier son authenticité.

¶ Les informations de jeton chiffrées ne sont pas stockées sur lenavigateur.

¶ Le jeton n’est transmis qu’une seule fois. Le serveur récepteurutilise ces informations pour créer les autorisations utilisateurdans sa propre mémoire cache. Le serveur les utilise lors desrequêtes suivantes de cet utilisateur au cours de la même session.

¶ La valeur de la durée de vie (délai d’expiration) du jeton estdéfinie dans le fichier de configurationwebseald.conf. Cettedurée peut être très courte (quelques secondes) de façon àréduire le risque d’une tentative de réexécution malveillante.

Chiffrement du jeton “d’attestation”WebSEAL doit chiffrer les données d’authentification placées sur lejeton à l’aide d’une clé générée par l’utilitairecdsso_key_gen. Vousdevez “synchroniser” cette clé en partageant le fichier de clés avecchaque serveur WebSEAL de chaque domaine participant. Chacundes serveurs WebSEAL participant à chaque domaine doit utiliser lamême clé.

Remarque : La création et la distribution de fichiers de clés ne faitpas partie du processus de communauté électronique dePolicy Director. Vous devez copier manuellement lesclés sur chaque serveur participant en toute sécurité.

L’utilitaire cdsso_key_genexige que vous spécifiez l’emplacement(chemin absolu) du fichier de clés lorsque vous l’exécutez :

UNIX : # cdsso_key_gen <chemin_absolu>

152 Version 3.8

Windows : MSDOS> cdsso_key_gen <chemin_absolu>

L’emplacement de la clé utilisée pour sécuriser les jetons envoyésentre les serveurs dans le même domaine (accueil et distant) est lavaleur 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 jetonsenvoyés entre le serveur MAS et les serveurs des domaines distantsest défini dans la strophe[inter-domain-keys]. La stropheinter-domain-keys n’est pas requise pour les autres serveursappartenant au même domaine que celui du serveur MAS. Leserveur MAS est le seul qui doit communiquer avec les serveursdans les domaines distants.[inter-domain-keys]<nom_domaine> = <chemin_absolu><nom_domaine> = <chemin_absolu

Configuration d’une communauté électroniqueCette section décrit tous les paramètres de configuration requis pourl’implémentation d’une communauté électronique. Ces paramètres setrouvent dans le fichierwebseald.conf. Vous devez configurer cefichier avec précaution pour chaque serveur membre de lacommunauté é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”. Parexemple :[e-community-sso]e-community-sso-auth = both

Les valeurs “http”, “https” et “both” indiquent le type decommunication utilisée par 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 ce paramètreest “none”.


5.S

olutionsde

connexioninterdom

aine

master-http-port

Si le paramètree-community-sso-authactive l’authentification de lacommunauté électronique HTTP et que le serveur d’authentificationprincipal écoute les requêtes HTTP sur un port différent du portHTTP standard (port 80), le paramètremaster-http-port identifie leport non standard. Ce paramètre est ignoré si ce serveur est leserveur d’authentification principal. Il est désactivé par défaut.[e-community-sso]master-http-port = <numéro_port>

master-https-port

Si le paramètree-community-sso-authactive l’authentification de lacommunauté électronique HTTPS et que le serveur d’authentificationprincipal écoute les requêtes HTTPS sur un port différent du portHTTPS standard (port 443), le paramètremaster-http-port identifiele port non standard. Ce paramètre est ignoré si ce serveur est leserveur 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é électroniquepour tous les serveurs des domaines participants. Par exemple :[e-community-sso]e-community-name = companyABC

La valeur du paramètree-community-namedoit être identique pourtous les serveurs WebSEAL dans l’ensemble des domaines de lacommunauté électronique.

intra-domain-key

Ce paramètre identifie l’emplacement du fichier de clés utilisé pourchiffrer et déchiffrer les jetons qui sont échangés dans le domaine dece serveur. Par exemple :[e-community-sso]intra-domain-key = /abc/xyz/key.file

154 Version 3.8

Vous devez générer ce fichier de clés à un endroit et le copiermanuellement (et en toute sécurité) à l’emplacement défini sur tousles autres serveurs WebSEAL du domaine.

is-master-authn-server

Ce paramètre indique si ce serveur est le serveur MAS. Les valeurssont “yes” ou “no”. Par exemple :[e-community-sso]is-master-authn-server = yes

Plusieurs serveurs WebSEAL peuvent être configurés pour servir deserveurs d’authentification principaux et placés derrière unmécanisme d’équilibrage de charge. Dans ce scénario, tous les autresserveurs WebSEAL de la communauté électronique “reconnaissent”le mécanisme d’équilibrage de charge comme étant le serveur MAS.

master-authn-server

Si le paramètreis-master-authn-servera la valeur “no”, sa mise encommentaire doit être annulée et il doit être défini. Le paramètreidentifie le nom de domaine complet du serveur MAS. Parexemple :[e-community-sso]master-authn-server = mas.dA.com

vf-token-lifetime

Ce paramètre définit la durée de vie (en secondes) du jeton“d’attestation”. Cette valeur est comparée avec l’heure de création ducookie. La valeur par défaut est 180 secondes. Vous devez prendreen compte le décalage horaire entre les serveurs participants. Parexemple :[e-community-sso]vf-token-lifetime = 180


5.S

olutionsde

connexioninterdom

aine

vf-url

Ce paramètre définit l’adresse URL “d’attestation”. La valeur doitcommencer par une 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) ducookie de domaine de communauté électronique. La valeur pardéfaut est 300 minutes. Par exemple :[e-community-sso]ec-cookie-lifetime = 300

Clés interdomaines

L’emplacement des fichiers de clés requis pour chiffrer et déchiffrerles jetons entre le serveur MAS et les serveurs membres desdomaines distants est défini dans la strophe[inter-domain-keys].Vous devez indiquer les noms de domaine complets pour les serveursainsi que les noms de chemin absolu pour les emplacements desfichiers de clés.

L’exemple suivant fournit au serveur MAS (domaine A) les fichiersde clés pour communiquer 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é entrele domaine A et le domaine B tandis quekey.fileC définit celuiutilisé entre le domaine A et le domaine C.

Chaque serveur distant nécessite une copie du fichier de clésapproprié utilisé par le serveur MAS. Pour échanger des jetons avec

156 Version 3.8

le serveur MAS (domaine A), tous les serveurs du domaine Brequièrent des copies dekey.fileB.[inter-domain-keys]dA.com = /efg/hij/key.fileB

Pour échanger des jetons avec le serveur MAS (domaine A), tous lesserveurs du domaine C requièrent des copies dekey.fileC.[inter-domain-keys]dA.com = /efg/hij/key.fileC

Configuration de la méthode d’authentification CDSSOLa configuration de la communauté électronique exige que laméthode d’authentificationcdssosoit activée. Ce mécanisme estnécessaire lorsque le serveur récepteur crée des autorisationsutilisateur à partir des informations d’identité contenues dans le jeton“d’attestation”. Le paramètre de configurationcdssospécifie labibliothèque partagée définie dans le code servant au mappage desinformations d’authentification.

¶ Sous UNIX, le fichier fournissant la fonction de mappage intégréest la bibliothèque partagéelibcdssoauthn.

¶ Sous Windows, le fichier fournissant la fonction de mappageintégré est le DLLcdssoauthn.




cdsso libcdssoauthn.so libcdssoauthn.a cdssoauthn.dll libcdssoauthn.sl

Pour configurer la méthode d’authentification CDSSO, indiquez leparamètrecdssoavec le nom du fichier de bibliothèque partagéecorrespondant à la plate-forme utilisée, dans la strophe[authentication-mechanism]du fichier de configurationwebseald.conf.

Par exemple :

Solaris :[authentication-mechanisms]cdsso = libcdssoauthn.so


5.S

olutionsde

connexioninterdom

aine

Windows :[authentication-mechanisms]cdsso = cdssoauthn.dll

158 Version 3.8

Jonctions WebSEAL

La connexion entre un serveur WebSEAL et un serveurd’applications Web d’arrière-plan est appelée jonction ou jonctionWebSEAL. Une jonction WebSEAL est une connexion TCP/IP entreun serveur WebSEAL frontal et un serveur d’applications Web. Lesjonctions permettent à WebSEAL de protéger les ressources Websituées sur des serveurs d’arrière-plan.

Vous pouvez créer des jonctions WebSEAL avec l’utilitaire de lignede commandepdadmin ou avec Web Portal Manager. Ce chapitreaborde en détails les nombreuses options permettant de configurerles jonctions WebSEAL.


¶ «Généralités sur les jonctions WebSEAL» à la page 160

¶ «Utilisation de la commande “pdadmin server task” pour créerdes jonctions» à la page 163

¶ «Configuration d’une jonction WebSEAL de base» à la page 164

¶ «Jonctions SSL authentifiées de façon réciproque» à la page 168

¶ «Création de jonctions proxy TCP et SSL» à la page 173

¶ «Jonctions WebSEAL / WebSEAL via SSL» à la page 174

¶ «Options de jonction supplémentaires» à la page 175

¶ «Remarques techniques sur les jonctions WebSEAL :» à la page195

6


6.Jonctions

WebS

EA

L

¶ «Utilisation de query_contents avec des serveurs tiers» à la page199

Généralités sur les jonctions WebSEALVous pouvez créer les types de jonction suivants :

¶ WebSEAL / serveur d’arrière-plan via connexion TCP

¶ WebSEAL / serveur d’arrière-plan via connexion SSL

¶ WebSEAL / serveur d’arrière-plan via connexion TCP à l’aided’un serveur proxy HTTP

¶ WebSEAL / serveur d’arrière-plan via connexion SSL à l’aided’un serveur proxy HTTPS

¶ WebSEAL / WebSEAL via connexion SSL

Lorsque vous créez une jonction, vous devez réfléchir aux deuxpoints 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 desjonctions

A présent, les informations de jonction WebSEAL sont stockées dansdes fichiers de base de données au format XML. L’emplacement durépertoire de la base de données des jonctions est défini dans lastrophe[junction] du fichier de configurationwebseald.conf. Cerépertoire est relatif à la racine du WebSEAL (paramètreracine_serveursitué dans la strophe[server]) :[junction]junction-db = jct

¶ Chaque jonction est définie dans un fichier séparé avec uneextension.xml.

¶ Servez-vous de l’utilitairepdadmin pour créer et gérer desjonctions et des options.

160 Version 3.8

¶ Le format XML permet de créer, d’éditer, de dupliquer et desauvegarder manuellement des fichiers de jonction.

Exécution d’un contrôle d’accès allégé : Résumé1. Servez-vous de l’utilitairepdadmin ou de Web Portal Manager

pour créer une jonction entre WebSEAL et le serveurd’arrière-plan.

2. Définissez des règles de LCA appropriées sur le point de jonctionpour fournir un contrôle d’accès allégé au serveur d’arrière-plan.

Exécution d’un contrôle d’accès renforcé : Résumé1. Servez-vous de l’utilitairepdadmin ou de Web Portal Manager

pour créer une jonction entre WebSEAL et le serveurd’arrière-plan.

WebSEAL ne peut pas “voir” ni comprendre automatiquement unsystème de fichiers d’un tiers. Vous devez l’informer de l’espaceobjet tiers avec une application spéciale, appeléequery_contents, qui effectue l’inventaire de l’espace Web tiers eten indique la structure et le contenu à WebSEAL.

2. Copiez le programmequery_contentssur le serveur tiers.

3. Appliquez les règles de LCA aux objets appropriés de l’espaceobjet unifié.

Directives en matière de création de jonctionsWebSEAL

Les directives suivantes récapitulent les “règles” en matière dejonctions :

¶ Vous pouvez ajouter une jonction en un point quelconque del’espace objet WebSEAL principal

¶ Vous pouvez relier plusieurs répliques de serveur sur le mêmepoint de montage

Les répliques de serveur montées sur le même point de jonctiondoivent être du même type : TCP ou SSL

¶ Les règles de sécurité de LCA sont transmises par les jonctionsjusqu’aux serveurs tiers


6.Jonctions

WebS

EA

L

¶ Le point de jonction ne doit pas correspondre à un répertoire del’espace Web du serveur WebSEAL local. Par exemple, siWebSEAL possède des ressources du type/chemin/...,ne créezpas de point de jonction du nom/chemin.

¶ Le point de jonction ne doit pas correspondre à un répertoire del’espace Web du serveur d’arrière-plan si des pages HTML de ceserveur contiennent des programmes (Javascript ou applets, parexemple) ayant des adresses URL relatives au serveur pour cerépertoire. Par exemple, si des pages du serveur d’arrière-plancontiennent des programmes dotés d’une adresse URL du type/chemin/..., ne créez pas de point de jonction nommé/chemin.

WebSEAL ne prend en charge qu’HTTP 1.0 sur lesjonctions

WebSEAL prend en charge uniquement HTTP 1.0 sur les jonctions.Cette limitation peut affecter le réglage des performances et ledéveloppement des applications déployées sur des serveursd’arrière-plan reliés par jonction.

Connexion Protocole accepté Numéro RFC

Frontal (client / WebSEAL) HTTP/1.0 et HTTP/1.1 RFC2068

Arrière-plan (WebSEAL /serveur relié par jonction)

HTTP/1.0 uniquement RFC1945

Remarque : La fonctionnalité “Keep-Alive” de HTTP/1.0 n’est pasprise en charge pour la connexion frontale. Laconnexion permanente HTTP est acceptée pourHTTP/1.1.

Références supplémentaires pour les jonctionsWebSEAL

Pour une présentation conceptuelle des jonctions WebSEAL,reportez-vous à la section «Explication des jonctions WebSEAL» à lapage 11.

162 Version 3.8

Pour plus d’informations sur les options de commande de jonction,reportez-vous à la section «Référence des jonctions WebSEAL» à lapage 269.

Utilisation de la commande “pdadmin server task”pour créer des jonctions

Avant d’utiliser pdadmin, vous devez vous connecter à un domainesécurisé en tant qu’utilisateur administratifsec_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 commandepdadminserver task :pdadmin> server task <nom_serveur><tâche>

L’argumentnom_serveurest l’expression complète du nom de lamachine réelle et le composant de Policy Director utilisé par cettecommande (par exemple, WebSEAL).<composant_Policy_Director>-<nom_machine>

Par exemple, si le nom de la machine estcruz et que le composantde Policy Director est WebSEAL,nom_serveura la valeur :webseald-cruz


6.Jonctions

WebS

EA

L

Utilisez la commandeserver list pour vérifier les expressions denom_serveur:pdadmin> server listwebseald-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 serveursd’applications Web d’arrière-plan.

La jonction entre WebSEAL et le serveur d’arrière-plan estindépendante du type de connexion (et de son niveau de sécurité)entre le client et le serveur WebSEAL.

Les options de commande obligatoires pour créer une jonctionWebSEAL de base à l’aide depdadmin sont les suivantes :

¶ Nom d’hôte du serveur d’applications d’arrière-plan (option–h)

¶ Type de jonction : tcp, ssl, tcpproxy, sslproxy, local (option–t)

¶ Point de jonction (point de montage)pdadmin> server task <nom_serveur> 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

Jonctions de type TCPUne jonction WebSEAL sur une connexion TCP fournit lespropriétés de base d’une jonction, mais ne fournit pas descommunications sécurisées au niveau de la jonction.

164 Version 3.8

Pour créer une jonction TCP sécurisée et ajouter un serveur initial,servez-vous de la commandecreate avec l’option–t tcp :pdadmin> server task<nom_serveur> 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 despécification) est80.

Jonctions de type SSLLes jonctions SSL fonctionnent exactement comme des jonctionsTCP, mais l’atout supplémentaire réside dans le fait que toutes lescommunications entre WebSEAL et le serveur d’arrière-plan sontchiffrées.

JonctionWebSEAL

Client

Domaine s écuris é


Web

HTTP

/

/mnt

TCP

Figure 22. Jonction TCP (HTTP) non sécurisée


6.Jonctions

WebS

EA

L

Les jonctions SSL permettent des transactions sécurisées de bout enbout entre le navigateur et l’application. Vous pouvez utiliser leprotocole SSL pour sécuriser les communications entre le client etWebSEAL, ainsi qu’entre WebSEAL et le serveur d’arrière-plan. Cedernier doit être activé en mode HTTPS lorsque vous utilisez unejonction SSL.

Pour créer une jonction SSL sécurisée et ajouter un serveur initial,servez-vous de la commandecreate avec l’option–t ssl :pdadmin> server task<nom_serveur> 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 despécification) est443.

Vérification du certificat du serveur d’arrière-planLorsqu’un client demande une ressource du serveur d’arrière-plan,WebSEAL, en tant que serveur de sécurité, effectue la requête pourle compte du client. Le protocole SSL spécifie que, si une requêteest effectuée auprès du serveur d’arrière-plan, ce dernier doitapporter la preuve de son identité via un certificat côté serveur.

JonctionWebSEAL

Client


HTTPS

/

/mntSSLTCP


Web

Figure 23. Jonction SSL (HTTPS) sécurisée

166 Version 3.8

Lorsque WebSEAL reçoit ce certificat du serveur d’arrière-plan, ildoit vérifier son authenticité en le comparant à une liste de certificatsd’autorité de certification racine enregistrés dans sa base decertificats.

Policy Director utilise la mise en oeuvre GSkit (Global Security Kit)IBM de SSL. Vous devez vous servir de l’utilitaire GSKitiKeymanpour ajouter le certificat racine de la CA qui a signé le certificat duserveur d’arrière-plan au fichier de clés du certificat WebSEAL(pdsvr.kdb).

Pour des informations exhaustives sur la gestion d’une base dedonnées de clés de certificat, reportez-vous à la section «Gestion decertificats avec iKeyman» à la page 279.

Exemples de jonctions SSLLiaison de l’hôtesales.tivoli.comau point de jonction/sales viaSSL :pdadmin> server task <nom_serveur> create –t ssl–hsales.tivoli.com /sales

Remarque : Dans l’exemple précédent, l’option–t ssl indique leport par défaut 443.

Liaison de l’hôtetravel_svr sur le port4443au point de jonction/travel via SSL :pdadmin> server task <nom_serveur> create –t ssl–p 4443–h travel_svr /travel


6.Jonctions

WebS

EA

L

Jonctions SSL authentifiées de façon réciproqueWebSEAL prend en charge l’authentification réciproque entre unserveur WebSEAL et un serveur d’arrière-plan via une jonction SSL(–t ssl ou –t sslproxy). La description ci-après résume lesfonctionnalités prises en charge en matière d’authentificationréciproque via SSL (les options de commande sont répertoriées sinécessaire) :

1. WebSEAL authentifie le serveur d’arrière-plan (processus SSLnormal)

¶ WebSEAL valide le certificat de serveur à partir du serveurd’arrière-plan. Voir «WebSEAL valide le certificat du serveurd’arrière-plan» à la page 169.

¶ WebSEAL vérifie le nom distinctif (DN) contenu dans lecertificat (–D) (opération facultative, mais fortementrecommandée). Voir la section «Mise en correspondance desnoms distinctifs (DN)» à la page 169.

2. Le serveur d’arrière-plan authentifie WebSEAL (deux méthodes)

¶ Le serveur d’arrière-plan valide le certificat client à partir deWebSEAL (–K). Voir la section «WebSEAL s’authentifieavec le certificat client» à la page 170.

¶ Le serveur d’arrière-plan valide les informations d’identité deWebSEAL dans l’en-tête de l’authentification de base (BA)(–B, –U, –W). Voir «WebSEAL s’authentifie avec l’en-têteBA» à la page 171.

Les options de commande qui contrôlent l’authentification réciproquevia SSL fournissent les fonctions suivantes :

¶ Vous pouvez spécifier une méthode d’authentification BA ou parcertificat client.

¶ Vous pouvez appliquer une méthode d’authentification jonctionpar jonction.

Les différents points à prendre en considération pour la combinaisondes options–b (pour la gestion des informations BA) avec

168 Version 3.8

l’authentification réciproque via SSL sont décrits dans la section«Gestion des informations d’identité du client en cas de 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 fonctiondu protocole SSL standard. Le serveur d’arrière-plan envoie soncertificat de serveur à WebSEAL. WebSEAL valide le certificat deserveur en le comparant à une liste prédéfinie de certificats racine deCA.

Les certificats de CA qui composent la chaîne de confiance pour lecertificat du serveur d’applications (depuis la CA signataire jusqu’aucertificat racine) doivent figurer dans la base de données de clésutilisée par WebSEAL.

Vous avez recours à l’utilitaireiKeyman pour créer et gérer la basede données des certificats racine de CA. Voir la section «Gestion decertificats avec iKeyman» à la page 279.

Mise en correspondance des noms distinctifs (DN)Vous pouvez renforcer la vérification du certificat côté serveur aumoyen de la mise en correspondance des noms distinctifs DN(distinguished name - DN). Pour activer cette fonction, vous devezspécifier le DN du serveur d’arrière-plan lorsque vous créez lajonction SSL à ce serveur. Bien que la mise en correspondance denoms distinctifs soit une configuration facultative, sa mise en oeuvreavec l’authentification réciproque est vivement recommandée sur lesjonctions SSL.

Pendant la vérification du certificat côté serveur, le DN contenu dansle certificat est comparé à celui qui est défini par la jonction. Laconnexion au serveur d’arrière-plan échoue si les deux noms necorrespondent pas.


6.Jonctions

WebS

EA

L

Pour activer cette fonction de mise en correspondance, spécifiez leDN du serveur d’arrière-plan lorsque vous créez la jonction SSLavec l’option–D“<DN>” . Pour maintenir les espaces éventuels de lachaîne, encadrez la chaîne du DN par des guillemets. Par exemple :–D “/C=US/O=Tivoli/OU=SecureWay/CN=Policy Director”

L’option –D doit obligatoirement être accompagnée de l’option–Kou –B.

WebSEAL s’authentifie avec le certificat clientServez-vous de l’option–K pour activer l’authentification WebSEALauprès du serveur d’arrière-plan relié par jonction via le certificatclient.–K “<libellé_clé>”

Les conditions relatives à ce scénario sont les suivantes :

¶ Le serveur d’arrière-plan est configuré pour demander unevérification de l’identité de WebSEAL au moyen d’un certificatclient.

¶ WebSEAL est configuré (webseald.conf) de façon à utiliser uncertificat client spécifique pour s’identifier auprès du serveurd’arrière-plan (ssl_keyfile_label).

¶ Vous êtes également invités à configurer la jonction pour unemise en correspondance des noms distinctifs–D).

L’option –K utilise un argument qui spécifie le libellé de clé ducertificat requis, tel qu’il est enregistré dans la base de données declés GSKit. Servez-vous de l’utilitaireiKeyman pour ajouter denouveaux certificats à la base de données de clés. Utilisez leparamètressl-keyfile-labeldu fichier de configurationwebseald.conf pour configurer le libellé de clé.

Vous devez encadrer l’argument de libellé de clé de guillemets. Parexemple :–K “cert1_Tiv”

Voir la section «Configuration des paramètres de la base de donnéesde clés pour WebSEAL» à la page 46.

170 Version 3.8

WebSEAL s’authentifie avec l’en-tête BAServez-vous de l’option–B –U “<nom_utilisateur>” –W“<mot_de_passe>”pour activer l’authentification WebSEAL vial’authentification de base.–B –U “<nom_utilisateur>” –W“<mot_de_passe>”

Les conditions relatives à ce scénario sont les suivantes :

¶ Le serveur d’arrière-plan est configuré pour demander unevérification de l’identité de WebSEAL au moyen d’un en-têteBA.

¶ Ne configurez pas la jonction avec une option–b. (En interne,l’option –B utilise toutefois le filtre–b.)

¶ WebSEAL est configuré pour transmettre ses informationsd’identité dans un en-tête BA pour s’authentifier auprès duserveur d’arrière-plan.

¶ Vous êtes également vivement invités à configurer la jonctionpour une mise en correspondance des noms distinctifs (–D).

Vous devez encadrer les arguments de nom d’utilisateur et de mot depasse de guillemets. Par exemple :–U “WS1” –W “abCde”

Gestion des informations d’identité du client en casde jonctions

Il est possible qu’une jonction soit définie pour spécifier desinformations d’identité du client dans des en-têtes BA. L’option–bautorise quatre arguments : filter, supply, ignore, gso. Vous trouverezdes détails sur ces arguments à la section «Configuration d’en-têtesBA pour des solutions SSO» à la page 205.

L’option –b joue sur les paramètres de jonction en matièred’authentification réciproque et vous devez envisager la combinaisonappropriée d’options.


6.Jonctions

WebS

EA

L

Utilisation de –b supply¶ 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 nomd’utilisateur du client original et un mot de passe “fictif”.

¶ L’authentification WebSEAL via le certificat client est autoriséeavec cette option.

Utilisation de –b ignore¶ 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 nomd’utilisateur et le mot de passe du client original.


Utilisation de –b gso¶ 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 lesinformations de nom d’utilisateur et de mot de passe fourniespar le serveur GSO.


Utilisation de –b filter¶ En interne, l’option–b filter est utilisée lorsque

l’authentification WebSEAL est définie pour utiliser lesinformations de l’en-tête BA.

Cet en-tête est utilisé pour toutes les transactions HTTP quisuivent. Pour le serveur d’arrière-plan, WebSEAL sembleconnecté tout le temps.


¶ Si le serveur d’arrière-plan exige l’identité réelle du client (àpartir du navigateur), il est possible d’utiliser les variables CGIsuivantes : HTTP_IV_USER, HTTP_IV_GROUP et

172 Version 3.8

HTTP_IV_CREDS. Pour les scripts et les servlets, utilisez lesen-têtes HTTP spécifiques de Policy Director correspondantes :iv-user, iv-groups, iv-creds.

Création de jonctions proxy TCP et SSLVous pouvez créer des jonctions WebSEAL qui permettent auxcommunications de transiter par des topologies de réseau utilisantdes serveurs proxy HTTP ou HTTPS. Vous pouvez configurer lajonction pour qu’elle gère les requêtes comme des communicationsTCP standard ou des communications TCP protégées.

Pour que la commandecreate définisse une jonction TCP ou SSLpar l’intermédiaire d’un serveur proxy, l’un des arguments ci-aprèsdoit être défini pour l’optiontype :

¶ –t tcpproxy

¶ –t sslproxy

Pour identifier le serveur proxy et le serveur Web destinataire, lesdeux commandescreate et add doivent être dotées des options etdes arguments ci-après :

–H <nom_hôte> Nom d’hôte DNS ou adresse IP du serveurproxy.

–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 valeurpar défaut est80 pour les jonctions TCP ;443pour les jonctions SSL.

Exemple de jonction de proxy TCP (entrée sur une ligne) :pdadmin> server task <nom_serveur> create –ttcpproxy–H clipper –P 8081 –h www.ibm.com –p 80 /ibm


6.Jonctions

WebS

EA

L

Exemple de jonction de proxy SSL (entrée sur une ligne) :pdadmin> server task <nom_serveur> create –tsslproxy–H clipper –P 8081 –h www.ibm.com –p 443 /ibm

Jonctions WebSEAL / WebSEAL via SSLPolicy Director accepte les jonctions SSL entre un serveurWebSEAL frontal et un serveur WebSEAL d’arrière-plan. Pour relierpar jonction deux serveurs WebSEAL via SSL et assurer uneauthentification réciproque, spécifiez l’option–C avec la commandecreate.

Exemple :pdadmin> server task <nom_serveur> create –t ssl–C –h serverA /jctA

L’authentification réciproque s’effectue en deux étapes :

¶ Le protocole SSL autorise le serveur WebSEAL d’arrière-plan às’authentifier auprès du serveur WebSEAL frontal au moyen deson certificat de serveur.

¶ L’option –C permet au serveur frontal de transmettre sesinformations d’identité au serveur d’arrière-plan dans un en-têteBA.

Client WebSEALServeur

Web

www.ibm.com


Serveurproxy

Clipper Internet

-H et -P -h et -pjonction à /ibm

Figure 24. Exemple de jonction proxy

174 Version 3.8

En outre, l’option–C active la fonctionnalité de l’option–c, laquellevous permet de placer des informations sur l’appartenance à ungroupe et sur l’identité du client, spécifiques de Policy Director, dansl’en-tête HTTP de la requête destinée au serveur WebSEALd’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 lesen-têtes HTTP (–c)» à la page 177.

Les conditions suivantes s’appliquent aux jonctions WebSEAL /WebSEAL :

¶ La jonction ne convient qu’au type–t ssl ou –t sslproxy.

¶ Les deux serveurs WebSEAL doivent partager un registre LDAPou DCE commun. Le serveur d’arrière-plan peut ainsiauthentifier les informations d’identité du serveur frontal.

Options de jonction supplémentairesVous pouvez ajouter les fonctionnalités de jonction WebSEALsuivantes avec d’autres options :

¶ «Nouvelle jonction forcée (–f)» à la page 176

¶ «Spécification de l’identité du client dans les en-têtes HTTP(–c)» à la page 177

¶ «Spécification des adresses IP client dans les en-têtes HTTP(–r)» à la page 179

¶ «Transmission de cookies de session à des serveurs de portailreliés par jonction (–k)» à la page 180

¶ «Prise en charge d’adresses URL sans distinction de casse (–i)»à la page 181

¶ «Traitement d’adresses URL à partir de scripts et d’applicationscôté client (–j)» à la page 182

¶ «Gestion d’adresses URL relatives au serveur avec mappage desjonctions» à la page 187

¶ «Prise en charge d’une jonction avec état (–s, –u)» à la page 189


6.Jonctions

WebS

EA

L

¶ «Spécification d’UUID de serveur d’arrière-plan pour desjonctions avec état (–u)» à la page 190

¶ «Etablissement de jonctions avec des systèmes de fichiersWindows (–w)» à la page 194

Nouvelle jonction forcée (–f)Lorsque vous souhaitez forcer une nouvelle jonction pour enremplacer une autre, vous devez utiliser l’option–f.

L’exemple suivant (le nom de serveur estwebsealA) illustre cetteprocédure :

1. Connectez-vous àpdadmin :# pdadminpdadmin> loginEntrer ID utilisateur : sec_masterEntrer mot de passe :pdadmin>

2. Servez-vous de la commandeserver task list pour afficher tousles points de jonction en cours :pdadmin> server task websealA list/

3. Servez-vous de la commandeserver task showpour afficher lesdétails de la jonction :pdadmin> server task 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 dejonction en cours (l’option-f est nécessaire pour forcer unenouvelle jonction à en remplacer une autre) :pdadmin> server task websealA create -t local -f -d /tmp/docs /Created junction at /

5. Affichez le nouveau point de jonction :pdadmin> server task websealA list/

176 Version 3.8

6. Affichez les détails de la jonction :pdadmin> server task 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

Spécification de l’identité du client dans les en-têtesHTTP (–c)

L’option –c vous permet d’insérer des informations propres à PolicyDirector sur l’appartenance à un groupe et sur l’identité du clientdans les en-têtes HTTP des requêtes destinées à des serveurs tiersreliés par une jonction. Les informations de ces en-têtes permettentaux applications des serveurs tiers reliés par une jonction d’exécuterdes actions spécifiques de l’utilisateur en fonction de l’identitéPolicy Director du client.

Les informations d’en-tête HTTP doivent être converties par leserveur d’arrière-plan au format de la variable d’environnementcorrespondant à un service du serveur d’arrière-plan. Leurconversion au format d’une variable d’environnement CGI s’effectueen remplaçant tous les tirets (-) par des traits de soulignement (_) etpar le déplacement de “HTTP” en début de chaîne. La valeur del’en-tête HTTP devient celle de la nouvelle variabled’environnement.


6.Jonctions

WebS

EA

L

Champs d’en-têteHTTP spécifiques

de PD

Variablesd’environnement CGI

équivalentes

Description

iv-user = HTTP_IV_USER = Nom du client sous forme abrégée oudétaillée. “Unauthenticated” par défaut, sile 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’autorisationPolicy Director. Fournit des donnéesd’autorisation aux serveurs éloignés pourque les applications de niveauintermédiaire puissent utiliser l’APId’autorisation pour appeler le serviced’autorisation. Reportez-vous audocumentTivoli SecureWay PolicyDirector Authorization DeveloperReference.

Les entrées d’en-tête HTTP spécifiques de Policy Director sontutilisées par les programmes CGI en tant que variablesd’environnementHTTP_IV_USER, HTTP_IV_GROUPS etHTTP_IV_CREDS. Pour les autres produits de structured’application, reportez-vous à la documentation propre à chaqueproduit pour savoir comment extraire des en-têtes à partir derequêtes HTTP.

Syntaxe –cL’option –c spécifie quelles données d’en-tête HTTP spécifiques dePolicy Director sont envoyées au serveur d’applicationsd’arrière-plan.–c <types_en-tête>

Les argumentstypes_en-têtesont les suivants : all, iv_user,iv_user_l, iv_groups et iv_creds.

178 Version 3.8

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 formedétaillée) comme champiv-user de l’en-tête HTTP dela requête.

iv_groups Contient la liste des groupes de l’utilisateur commechampiv-groups de l’en-tête HTTP de la requête.

iv_creds Contient les données d’autorisation de l’utilisateurcomme champiv-creds de l’en-tête HTTP de larequête.

Remarque : Spécifiez iv_user ou iv_user_l, mais pas les deuxensemble.

L’option –c all insère les trois types d’informations d’identité dansl’en-tête HTTP (le nom en format abrégé iv_user est alors utilisé).

Remarque : Pour séparer plusieurs arguments, n’utilisez que desvirgules. N’entrez pas 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êtesHTTP (–r)

L’option –r vous permet d’insérer des informations sur les adressesIP client dans les en-têtes HTTP des requêtes destinées à desserveurs d’applications reliés par une jonction. Les informations deces en-têtes permettent aux applications des serveurs tiers reliés parune jonction d’exécuter des actions en fonction de ces informationssur les adresses IP.


6.Jonctions

WebS

EA

L

Les informations d’en-tête HTTP doivent être converties par leserveur d’arrière-plan au format de la variable d’environnementcorrespondant à un service du serveur d’arrière-plan. Leurconversion au format d’une variable d’environnement CGI s’effectueen remplaçant tous les tirets (-) par des traits de soulignement (_) etpar le déplacement de “HTTP” en début de chaîne. La valeur del’en-tête HTTP devient celle de la nouvelle variabled’environnement.

Remarque : La valeur de l’adresse IP ne représente pas toujoursl’adresse de la machine client d’origine. Elle peutreprésenter celle d’un serveur proxy ou d’unconvertisseur NAT (Network Address Translator).

Champ d’en-têteHTTP spécifiques

de PD

Variabled’environnement CGI

équivalente

Description

iv-remote-address HTTP_IV_REMOTE_ADDRESS

Adresse IP du client. Cette valeur peutreprésenter l’adresse IP d’un serveurproxy ou d’un convertisseur NAT.

L’option –r indique que l’adresse IP de la requête entrante doit êtreenvoyée au serveur d’applications d’arrière-plan. L’option estexprimée sans aucun argument.

Transmission de cookies de session à des serveursde portail reliés par jonction (–k)

Un portail Web est un serveur qui propose une grande gamme deservices et de ressources individualisés. L’option–k vous permetd’envoyer le cookie de session Policy Director (session établieinitialement entre le client et WebSEAL) à un serveur de portaild’arrière-plan. Cette option sert à prendre en charge directementl’intégration de WebSEAL avec la solution Plumtree CorporatePortal.

Lorsqu’un client demande la liste de ses ressources personnelles auserveur de portail, celui-ci la dresse en accédant aux ressourcessituées sur d’autres serveurs d’applications également protégés par

180 Version 3.8

WebSEAL. Le cookie de session permet au serveur de portaild’effectuer une connexion unique transparente à ces serveursd’applications, pour le compte du client.

Lorsque vous créez la jonction entre WebSEAL et le serveur deportail d’arrière-plan, vous devez inclure l’option–k sans aucunargument.

Conditions à prendre en compte pour configurer un serveur deportail :

¶ Pour un accès avec nom d’utilisateur et mot de passe,l’authentification par formulaires est requise. N’utilisez pasl’authentification de base.

¶ Le paramètressl-id-sessionssitué dans la strophe[session]dansles fichiers de configurationwebseald.conf doit avoir la valeur“no”. Pour les communications HTTPS, ce paramètre forcel’utilisation d’un cookie de session, à la place d’un ID de sessionSSL, afin de gérer l’état de la session.

¶ Si le serveur de portail a un groupe de serveurs WebSEALcomme serveurs frontaux, activez le cookie de secours. Celui-cicontient des données d’autorisation chiffrées permettant àl’authentification d’aboutir avec n’importe quel serveurWebSEAL répliqué traitant la requête.

Prise en charge d’adresses URL sans distinction decasse (–i)

Par défaut, lors des contrôles d’accès, Policy Director traite lesadresses URL en faisant la distinction majuscules/minuscules.L’option –i permet de spécifier que WebSEAL traite les URL sansdistinction de casse lors de la gestion d’une requête adressée à unserveur d’arrière-plan relié par jonction.

Lorsque vous définissez cette option pour la jonction, WebSEAL nefait pas la distinction entre les caractères majuscules et minusculeslorsqu’il analyse les adresses URL. Par défaut, les serveurs Web sontcensés être sensibles à la casse.


6.Jonctions

WebS

EA

L

Bien que la plupart des serveurs HTTP acceptent la spécificationHTTP définissant les URL comme étant sensibles à la casse, certainsserveurs HTTP traitent les URL sans distinction de casse.

Par exemple, sur des serveurs ne faisant pas la distinction entre lesmajuscules et les 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’unadministrateur qu’il définisse les mêmes contrôles d’accès (LCA) surles deux URL.

En reliant par jonction un serveur tiers avec l’option–i, WebSEALtraite les adresses URL envoyées à ce serveur sans respecter la casse.

Traitement d’adresses URL à partir de scripts etd’applications côté client (–j)

Cette section décrit la façon dont WebSEAL gère des liens absolus etrelatifs au serveur, générés par script, à des ressources du serveurd’arrière-plan.

¶ «Contexte» à la page 182

¶ «Gestion des URL relatives au serveur avec des cookies dejonction» à la page 184

¶ «Gestion des adresses URL absolues avec filtrage de script» à lapage 186

¶ «Gestion d’adresses URL relatives au serveur avec mappage desjonctions» à la page 187

ContexteLorsqu’un client accède à un serveur Web relié par jonction, lesinformations renvoyées peuvent être le résultat d’une page HTMLsimple, d’une application côté client (applet) ou d’un script. Leslangages de rédaction des scripts Web sont Javascript, VBscript,ASP, JSP et ActiveX.

182 Version 3.8

Tout élément généré (page HTML, script ou applet) est susceptiblede contenir des liens (URL) à d’autres ressources de ce serveurd’arrière-plan ou d’un emplacement quelconque. Les expressionsd’URL peuvent se présenter dans les formats suivants :

¶ absolu

¶ relatif

¶ relatif au serveur

Un lien renvoyant au serveur d’arrière-plan n’est efficace que sil’adresse URL est relative ou contient des informations identifiant lajonction. WebSEAL doit examiner les adresses URL parmi la grandediversité d’informations générées et fournir à point nommé lesinformations d’identité de la jonction.

Les adresses URL exprimées en formatrelatif n’exigent aucunemanipulation de la part de WebSEAL. Les liens au serveurd’arrière-plan exprimés au formatabsolu ou relatif au serveurn’aboutissent pas car les URL d’origine ne contiennent aucuneinformation sur la jonction. Ces liens apparaissent de façonincorrecte comme des requêtes émanant d’objets situés sur le serveurWebSEAL.

Exemples d’expressions d’URL relatives (le lien aboutitsystématiquement) :abc.html ../abc.html

./abc.html sales/abc.html

Exemple d’expression d’URL absolue (le lien nécessite desinformations sur la jonction) :http://www.tivoli.com/abc.html

Exemples d’expressions d’URL relative au serveur (le lien nécessitedes informations sur la jonction) :/abc.html /accounts/abc.html


6.Jonctions

WebS

EA

L

Pour gérer de façon dynamique les URL générées absolues etrelatives au serveur, WebSEAL procède comme suit :

¶ Sources HTML statiques

Comme une page HTML est composée de texte simple et estfacilement analysée, WebSEAL ajoute automatiquement lesinformations de jonction correctes à l’URL, au moment voulu.Voir la section «Filtrage d’URL statiques à partir de serveursreliés par jonction» à la page 196.

¶ Scripts et sources d’application côté client

La complexité des scripts empêche un filtrage correct parWebSEAL des expressions d’URL intégrées absolues et relativesau serveur lorsqu’elles sont échangées entre le serveurd’arrière-plan et le client. WebSEAL doit être configuré pourfournir des informations de jonction, au moment approprié.

Remarque : Tous les programmeurs de scripts Web sont invités àutiliser des liensrelatifs (et non absolus ou relatifs auserveur) pour les URL générées dynamiquement.

Gestion des URL relatives au serveur avec des cookies dejonction

Dans le scénario suivant, un script situé sur le serveur d’arrière-plangénère dynamiquement une expression d’URL relative au serveur.WebSEAL ne peut pas manipuler ce code incorporé lorsqu’il esttransmis au client. Le client voit une URL qui est exprimée de façonincorrecte car elle n’inclut pas d’informations sur la jonction.

/jctA

WebSEAL

Serveurd'applications(prend en charge

Javascript)

URL relative au serveurgénérée de façondynamique : /abc.html

Client

Le client reçoit à tort :/webseal/abc.html

Figure 25. URL générée par script sans filtrage

184 Version 3.8

Si le client demande la ressource spécifiée par ce lien, WebSEALimagine à tort que ce lien pointe vers une page locale. Lorsqu’ildétecte que la page est introuvable, il renvoie une erreur“Introuvable” au client.

L’option –j fournit une solution basée sur cookie pour la gestion desURL relatives au serveur qui sont générées dynamiquement par unscript Web sur le serveur relié par jonction et exécutées sur lamachine cliente.

Syntaxe générale :pdadmin> server task <non_serveur> create ... –j...

Pour chaque requête, un cookie identificateur de jonction est envoyéau client. Le cookie contient la variable et la valeur suivantes :IV_JCT_<nom_serveur_arrière-plan> =</nom_jonction>

Lorsque le client effectue une requête à l’aide de cette URL,WebSEAL traite cette dernière dans son format d’origine. En casd’échec à localiser la ressource, WebSEAL relance immédiatement larequête à l’aide des informations de jonction fournies par le cookie.A l’aide des informations de jonction correctes de l’expressiond’URL, la ressource est localisée.


6.Jonctions

WebS

EA

L

Le diagramme suivant illustre cette solution de filtrage d’adressesURL relatives au serveur

WebSEAL fournit une autre solution, qui n’est pas basée sur uncookie, de gestion des adresses URL relatives à un serveur. Voir lasection «Gestion d’adresses URL relatives au serveur avec mappagedes jonctions» à la page 187.

Gestion des adresses URL absolues avec filtrage de scriptUne configuration supplémentaire de WebSEAL est nécessaire pourlui permettre de gérer des adresses URL générées de façondynamique sur une jonction. Le fichier de configurationwebseald.conf contient un paramètre qui active ou désactive lefiltrage des URL absolues :[script-filtering]script-filter = no

Le filtrage de script est désactivé par défaut. Pour activer le filtragede script, définissez :script-filter = yes

Remarque : Vous devez également spécifier l’option–j pour créerla jonction au serveur d’arrière-plan. Un cookie

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 26. Filtrage d’URL relatives au serveur

186 Version 3.8

identificateur de jonction est envoyé au client, bienqu’il ne soit pas obligatoire, par le mécanisme defiltrage du script.

Le mécanismescript-filter attend des URL absolues respectant leformat standard : schéma, serveur, ressource.http://serveur/ressource

Le mécanismescript-filter remplace les portions schéma et serveurdu lien par les informations de jonction qui conviennent./nom_jonction/ressource

Cette solution, qui rajoute une surcharge au niveau du traitement,peut influer de façon négative sur les performances. Limitez votreutilisation du paramètrescript-filter aux jonctions pour lesquelles lefiltrage d’URL absolue doit être pris en charge.

Le diagramme suivant illustre cette solution de filtrage d’adressesURL :

Gestion d’adresses URL relatives au serveur avecmappage des jonctions

Policy Director propose une solution alternative à la solution baséesur cookie pour le filtrage des URL relatives au serveur. Vous

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 27. Filtrage d’URL absolues


6.Jonctions

WebS

EA

L

pouvez créer et activer une table de mappage des jonctions qui faitcorrespondre des ressources destinataires spécifiques à des noms dejonction.

WebSEAL vérifie les informations d’emplacement dans l’URLrelative au serveur par rapport aux données contenues dans la tablede mappage des jonctions. Si les informations de chemin contenuesdans l’URL correspondent à une entrée de la table, WebSEALadresse la requête à la jonction associée à cet emplacement.

La table est un fichier texte ASCII appeléjmt.conf. Sonemplacement est spécifié dans la strophe[junction] du fichier deconfigurationwebseald.conf.jmt-map = lib/jmt.conf

Le format d’entrée des données dans la table est composé d’un nomde jonction, d’un espace et du modèle d’emplacement de ressource.Vous pouvez également exprimer le modèle d’emplacement deressource à l’aide de caractères génériques.

Dans l’exemple suivant de fichier de configuration de mappage dejonctions, deux serveurs 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 mappagejmt.conf originale est un fichier vide. Aprèsavoir ajouté des données au fichier, servez-vous de la commandejmtload pour “charger” les données afin que WebSEAL soit informé desnouveautés.pdadmin> server task <nom_serveur> jmt loadChargement de la table JMT terminé.

Les conditions suivantes s’appliquent à la solution de table demappage des jonctions :

188 Version 3.8

¶ Cette solution n’exige pas l’option–j ou un cookie de jonction

¶ La table de mappage doit être configurée et activée par unadministrateur de sécurité

¶ Cette solution ne gère pas les liens créés avec des adresses URLabsolues

¶ La mise en correspondance du modèle d’emplacement deressource doit être unique dans l’espace Web local et dans lesserveurs d’applications Web reliés par jonction

¶ En cas d’entrée de modèle en double dans le fichier, la table demappage ne se charge pas. WebSEAL continue cependant às’exécuter.

¶ En cas d’erreur de chargement de la table de mappage, celle-cin’est pas disponible. WebSEAL continue cependant à s’exécuter.

¶ Si la table de mappage est vide ou qu’elle comporte une erreurdans ses entrées, elle ne se charge pas. WebSEAL continuecependant à s’exécuter.

¶ Toute erreur se produisant pendant le chargement de la table demappage génère des entrées de mise en service dans le fichierjournal du serveur WebSEAL (webseald.log).

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’unclient. Cet état sert, par exemple, à :

¶ Suivre la progression d’un utilisateur dans les champs d’unmasque de saisie généré par un programme CGI

¶ Maintenir le contexte d’un utilisateur pendant l’exécution d’unesérie d’interrogations sur la base de données

¶ Maintenir une liste de produits dans une application d’achats enligne où un utilisateur se déplace aléatoirement et sélectionnedes produits à acheter

Il est possible de répliquer les serveurs exécutant des applicationsactivées pour le Web pour améliorer les performances en répartissant


6.Jonctions

WebS

EA

L

la charge. Lorsque le serveur WebSEAL procure une jonction avecces répliques de serveurs d’arrière-plan, il doit vérifier que toutes lesrequêtes contenues au sein d’une session client sont transmises auserveur correct et non réparties entre les répliques en fonction desrègles d’équilibrage de charge.

Par défaut, Policy Director équilibre la charge du serveurd’arrière-plan en répartissant les requêtes entre toutes les répliquesde serveurs disponibles. Il utilise un algorithme de calcul du “moinsoccupé”. Cet algorithme dirige chaque nouvelle requête vers leserveur ayant le nombre de connexions en cours le plus faible.

La commandecreate avec l’option–s ignore cette règled’équilibrage de charge et crée une jonction “avec état” qui garantitl’acheminement des requêtes vers le même serveur pendant toute unesession. A la première requête du client, WebSEAL place dans lesystème client un cookie contenant l’UUID du serveur d’arrière-plandésigné. Lors des requêtes ultérieures du client à la même ressource,les informations d’UUID du cookie garantissent que les requêtes sontacheminées au même serveur d’arrière-plan.

L’option –s convient à un serveur WebSEAL frontal avec plusieursserveurs d’arrière-plan reliés par une jonction au même point dejonction. Vous remarquez qu’une fois la première jonction crééecomme jonction avec état, la commandeadd est spécifiée sansl’option –s pour relier les autres répliques des serveurs d’arrière-planau même point de jonction.

Si le scénario implique plusieurs serveurs WebSEAL frontaux, tousreliés par jonction aux mêmes serveurs d’arrière-plan, utilisezl’option –u pour spécifier correctement chaque UUID de serveurd’arrière-plan pour chaque serveur WebSEAL frontal. Voir la section«Spécification d’UUID de serveur d’arrière-plan pour des jonctionsavec état (–u)».

Spécification d’UUID de serveur d’arrière-plan pourdes jonctions avec état (–u)

A la création d’une jonction avec un serveur d’applications Webd’arrière-plan, WebSEAL génère normalement un UUID (Unique

190 Version 3.8

Universal Identifier) qui identifie ce serveur d’arrière-plan. Utilisé eninterne, cet UUID permet également de gérer les jonctions avec état(create –s).

A la première requête du client, WebSEAL place dans le systèmeclient un cookie contenant l’UUID du serveur d’arrière-plan désigné.Lors des requêtes ultérieures du client à la même ressource, lesinformations d’UUID du cookie garantissent que les requêtes sontacheminées au même serveur d’arrière-plan.

La gestion des jonctions avec état devient plus complexe lorsqueplusieurs serveurs Web frontaux sont reliés par jonction à plusieursserveurs d’arrière-plan. Normalement, chaque jonction entre unserveur WebSEAL frontal et un serveur d’arrière-plan génère unUUID unique pour le serveur d’arrière-plan. Autrement dit, un seulserveur 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écanismed’équilibrage de charge pour répartir la charge entre les deuxserveurs. Par exemple, il est possible qu’un “état” initial ait été établivers un serveur d’arrière-plan par l’intermédiaire du serveurWebSEAL 1 avec un UUID spécifique.

Toutefois, si une future requête du même client est acheminée parl’intermédiaire du serveur WebSEAL 2 au moyen du mécanismed’équilibrage de charge, l’“état” n’existe plus, à moins que le serveur

WebSEAL

Serveurd’applications 1(UUID1)

Serveurd’applications 2(UUID2)

ClientJonctionsavec étatCookie

avecUUID2

Figure 28. Des jonctions avec état utilisent des UUID de serveur d’arrière-plan


6.Jonctions

WebS

EA

L

WebSEAL 2 utilise le même UUID pour identifier le même serveurd’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 serveurd’arrière-plan donné à chaque serveur WebSEAL frontal.

A titre d’exemple, imaginez deux répliques d’un serveur WebSEALfrontal, possédant chacun une jonction avec deux serveursd’arrière-plan. Lorsque vous créez la jonction avec état entre leserveur WebSEAL 1 et le serveur d’arrière-plan 2, 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 serveurWebSEAL 2 et le serveur d’arrière-plan 2, un autre UUID (UUID B)est généré pour identifier le serveur d’arrière-plan 2.

Un “état” établi entre un client et un serveur d’arrière-plan 2, via leserveur WebSEAL 1, échoue si une requête ultérieure du client estacheminée par l’intermédiaire du serveur WebSEAL 2.

Procédez comme suit pour spécifier un UUID pendant la créationd’une jonction :

1. Créez une jonction entre le serveur WebSEAL 1 et chaqueserveur d’arrière-plan.

WebSEAL-1

Jonctionsavec état

WebSEAL-2

UUID B

Serveurd’applications 1UUID A

Serveurd’applications 2

Figure 29. UUID différents

192 Version 3.8

Spécifiezcreate –set add.

2. Répertoriez les UUID générés pour chaque serveur d’arrière-planpendant l’étape 1.

Spécifiezshow.

3. Créez une jonction entre le serveur WebSEAL 2 et chaqueserveur d’arrière-plan, puis indiquez les UUID spécifiés à l’étape2.

Spécifiezcreate –s –uet add –u.

Dans la figure suivante, le serveur d’arrière-plan 1 est identifié parWebSEAL-1 et WebSEAL-2 comme UUID 1. Le serveurd’arrière-plan 2 est identifié par WebSEAL-1 et WebSEAL-2 commeUUID 2.

Exemple :Dans l’exemple suivant,

¶ WebSEAL-1 est appelé WS1

¶ WebSEAL-2 est appelé WS2

¶ Le serveur d’arrière-plan 1 est appelé APP1

¶ 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

WebSEAL-1


(UUID 2)

Jonctionsavec état

Mécanismed’équilibrage

de charge

WebSEAL-2

Client

Cookieavec

UUID 2


(UUID 1)

Figure 30. Spécification d’UUID de serveur d’arrière-plan pour des jonctions avec état


6.Jonctions

WebS

EA

L

(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 serveurd’arrière-plan 2, il reçoit un cookie contenant l’UUID2. L’exempleprécédent assure que le client se connecte systématiquement auserveur d’arrière-plan 2, que les requêtes futures soient acheminéespar WebSEAL-1 ou WebSEAL-2.

Etablissement de jonctions avec des systèmes defichiers Windows (–w)

WebSEAL effectue des contrôles de sécurité sur les requêtes clientportant sur des serveurs d’arrière-plan reliés par jonction, d’après leschemins de fichiers spécifiés dans l’adresse URL. Ce contrôle desécurité peut être compromis car les systèmes de fichiers Win32fournissent 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). La seconde utilise l’ancien format de nom defichier 8.3 pour une compatibilité amont (abcdefx1.txt).

Lorsque vous créez des jonctions dans un environnement Windows,il est important de restreindre le contrôle d’accès à unereprésentation d’objet uniquement et de ne pas laisser de faillespermettant de contourner le mécanisme de sécurité.

L’option –w n’autorise pas le format 8.3. Un utilisateur ne peut paséviter une LCA explicite sur un nom de fichier long en utilisant laforme courte (8.3) du nom de fichier. Le serveur renvoie une erreur“403 Interdit” pour toute entrée d’un nom de fichier court.

Sous Windows, un fichier portant le nom “foo.” est traité comme lefichier “foo”. L’option –w supprime les points de fin des noms defichier dans une adresse URL avant d’envoyer la requête au serveurd’arrière-plan. Les contrôles de LCA sont basés sur le nom de fichiersans le point de fin.

194 Version 3.8

Remarque : La question du non respect de la casse par Win32(abcde.txt = AbCdE.txt) est gérée par l’option–i.Voir la section «Prise en charge d’adresses URL sansdistinction de casse (–i)» à la page 181.

Exemple :Sous Windows NT 4.0, le fichier\Program Files\CompanyInc.\Release.Notes est également accessible par les cheminsd’accès suivants :

1. \program files\company inc.\release.notes

2. \program files\company inc\release.notes

3. \prograx1\companx2\releasx3.not

L’exemple 1 précédent illustre le “non respect de la casse” (résolupar l’option –i et non par l’option–w).

L’exemple 2 illustre la façon dont Windows NT ignore un point defin.

L’exemple 3 illustre la façon dont Windows NT crée un alias (pourcompatibilité DOS) ne contenant pas d’espace dans les noms defichier et conforme au format 8.3.

L’option –w permet de combler les failles éventuelles dans lasécurité, illustrées par les exemples 2 et 3. L’option–w indique queles points de fin sont ignorés et que l’accès aux noms de fichierabrégés contenant un caractère tilde (x) est refusé dans les adressesURL de requête pour ce serveur relié par jonction.

Remarques techniques sur les jonctions WebSEAL :¶ «Montage de plusieurs serveurs sur la même jonction» à la page

196

¶ «Filtrage d’URL statiques à partir de serveurs reliés parjonction» à la page 196

¶ «Exceptions à la mise en oeuvre de droits d’accès dans desjonctions» à la page 198


6.Jonctions

WebS

EA

L

¶ «Authentification par certificat dans des jonctions» à la page 198

Montage de plusieurs serveurs sur la même jonctionVous pouvez monter plusieurs répliques de serveur au même pointde jonction, en nombre illimité.

Tous les serveurs montés au même point de jonction doivent être desrépliques (espaces Web en miroir) et utiliser le même protocole :HTTP ou HTTPS. Ne montez pas des serveurs dissemblables aumême point de jonction.

A partir de l’espace Web du serveur Policy Director principal, vousaccédez aux pages appartenant au(x) serveur(s) relié(s) par jonction.En principe, vous ne devez pas avoir de problème d’accès à cespages (dans la limite de vos droits d’accès, bien évidemment) et lespages doivent sembler cohérentes. S’il arrive qu’une page soitintrouvable ou modifiée, elle n’a pas été répliquée correctement.

Vérifiez que le document existe et est identique à l’arborescence dedocuments des deux serveurs répliqués.

Filtrage d’URL statiques à partir de serveurs reliés parjonction

Seuls les documents statiques de type MIME “text/html”, reçus desserveurs reliés par jonction, sont filtrés.

Il existe deux ensembles d’URL susceptibles d’être modifiées parWebSEAL : les URL absolues et relatives au serveur.

¶ Les adressesURL relatives au serveur indiquent la positiond’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 jonctiondu serveur relié par jonction, par exemple :/jct/dir/file.html

196 Version 3.8

¶ Les adressesURL absoluesindiquent une position de l’URL parrapport à un nom d’hôte (HOST) ou à une adresse IP, et un portde réseau, par exemple :http://servername[:port]/file.html ouhttps://servername[:port]/file.html

Ces URL sont modifiées selon les ensembles de règles suivants :

1. Si l’adresse URL est en mode HTTP et que l’ensemble hôte/portcorrespond à un serveur TCP relié par jonction, l’URL modifiéereflète le point de jonction, par exemple :/jct/...

2. Si l’adresse URL est en mode HTTPS et que l’ensemblehôte/port correspond à un serveur SSL relié par jonction, l’URLmodifiée reflète le point de jonction, par exemple :/jct/...

3. Seules les URL correspondant aux paires code/attribut définiesdans le fichieriv.confsont filtrées.

4. Les codes META sont toujours filtrés pour les requêtesd’actualisation, par exemple :

5. Si un code BASE contient un attribut HREF, il est supprimé dela réponse au client.

Les paramètres de filtrage des adresses URL dans les serveurs reliéspar jonction se trouvent dans la strophe[filter-url] du fichier deconfigurationwebseald.conf.

La strophe[filter-url] contient la liste des codes HTML que leserveur WebSEAL filtre ou modifie pour convertir les adresses URLabsolues obtenues par l’intermédiaire d’un serveur relié par jonction.

Tous les codes HTML courants sont configurés par défaut.L’administrateur doit peut-être rajouter des codes HTML contenantdes adresses URL.

<META HTTP-EQUIV=”Refresh” CONTENT=”5;URL=http://server/url”>


6.Jonctions

WebS

EA

L

Voir aussi la section «Traitement d’adresses URL à partir de scriptset d’applications côté client (–j)» à la page 182.

Exceptions à la mise en oeuvre de droits d’accèsdans des jonctions

Certains droits d’accès Policy Director ne peuvent pas être mis enoeuvre au-delà d’une jonction. Ainsi, vous ne pouvez pas contrôlerl’exécution d’un script CGI avec le droit d’accèsx ou une liste derépertoires avec le droit d’accèsl. WebSEAL ne peut pas déterminerde façon précise si un objet demandé sur un serveur d’arrière-planest, 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 auxprogrammes CGI et aux listes de répertoires, est contrôlé uniquementpar le droit d’accèsr .

Authentification par certificat dans des jonctionsA l’installation, WebSEAL est configuré avec un certificat de testautre que celui par défaut. Le paramètrewebseal-cert-keyfile-label,situé dans la strophe[ssl] du fichier de configurationwebseald.conf, désigne le certificat de test comme certificat côtéclient actif.

Si un serveur d’applications d’arrière-plan relié par jonction exigeque WebSEAL s’identifie avec un certificat côté client, vous devezcommencer par créer ce certificat, l’installer et lui affecter un libelléà l’aide de l’utilitaire iKeyman. Vous pouvez ensuite configurer lajonction avec l’option–K <libellé_clé>. Voir la section «JonctionsSSL authentifiées de façon réciproque» à la page 168

Si la jonction n’est pas configurée avec–K, GSKit traite unedemande d’authentification réciproque en envoyant automatiquementle certificat “par défaut” contenu dans la base de données du fichierde clés. S’il ne s’agit pas de la réponse requise, vous devez vousassurer que la base de données du fichier de clés (pdsrv.kdb) necontient aucun certificat marqué “par défaut” (astérisque).

198 Version 3.8

Pour résumer :

¶ Identifiez tous les certificats requis par leur nom de libellé.

¶ Ne marquez aucun certificat comme étant “par défaut” dans labase de données du fichier de clés.

¶ Contrôlez la réponse de certificat côté client WebSEAL avec leparamètrewebseal-cert-keyfile-label.

¶ Contrôlez la réponse de certificat côté client WebSEAL avecl’option de jonction –K.

Utilisation de query_contents avec des serveurs tiersSi vous voulez protéger les ressources de l’espace Web d’uneapplication tierce à l’aide du service de sécurité Policy Director,vous devez fournir à WebSEAL des informations sur le contenu decet espace Web.

Ces informations peuvent être fournies par un programme CGIappeléquery_contents. Le programmequery_contentsexamine lecontenu de l’espace Web tiers et fournit les informations d’inventaireà Web Portal Manager sur WebSEAL. Fourni avec le programmed’installation de WebSEAL, il doit être installé manuellement sur leserveur tiers. Différents types de fichiers programme sontdisponibles, suivant que le serveur tiers est basé UNIX ou Windows.

Le gestionnaire d’espace objet de Web Portal Manager exécuteautomatiquementquery_contentschaque fois qu’une partie del’espace objet protégé représentant la jonction est développée dansl’écran de gestion de l’espace objet. Une fois que Web PortalManager est informé du contenu de l’espace de l’application tiers,vous pouvez afficher ces informations et appliquer des modèles derègles aux objets appropriés.

Installation de query_contentsL’installation dequery_contentsest en général très facile. Il suffitde copier un ou deux fichiers du serveur Policy Director vers leserveur tiers et de modifier un fichier de configuration.


6.Jonctions

WebS

EA

L

Le répertoire Policy Director ci-après contient un modèle duprogramme :

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 lessystèmes Win32. Doit être installé dans lerépertoirecgi-bin du serveur Web tiers.

query_contents.sh Principal programme exécutable pour lessystèmes UNIX. Doit être installé dans lerépertoirecgi-bin du serveur Web tiers.

query_contents.c Code source. La source est fournie au cas oùvous deviez modifier le comportement dequery_contents. La plupart des cas, ceci n’estpas nécessaire.

query_contents.html Fichier d’aide au format HTML.

query_contents.cfg Exemple de fichier de configuration quiidentifie la racine du document pour le serveurWeb.

Installation de query_contents sur des serveurs UNIXtiers

Localisez le script shellquery_contents.sh dans le répertoiresuivant :<chemin_installation>/www/lib/query_contents

1. Copiezquery_contents.sh dans un répertoire actif/cgi-bindu serveur Web tiers.

2. Supprimez l’extension.sh.

3. Définissez le bit d’exécution UNIX pour le bit d’exécution duserveur Web.

200 Version 3.8

Installation de serveurs Win32 tiersLocalisez le programme exécutablequery_contents.exe et lefichier de configurationquery_contents.cfg dans le répertoiresuivant :

Windows : <chemin_installation>\www\lib\query_contents

1. Assurez-vous que le serveur Web tiers comporte un répertoireCGI correctement configuré.

2. A des fins de test, vérifiez qu’un document valide existe dans lerépertoire principal des documents du serveur Web tiers.

3. Copiezquery_contents.exe dans le répertoire CGI du serveurWeb tiers.

4. Copiezquery_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 c:\windows

Windows NT 3.5x c:\winnt35

Windows NT 4.x c:\winnt

5. Editez le fichierquery_contents.cfg pour y spécifier de façoncorrecte le répertoire principal des documents du serveur Webtiers.

Le fichier contient en général des exemples d’entrées pour leserveur Microsoft Internet Information Server et les serveursNetscape FastTrack. Les lignes commençant par un point-virgulesont des commentaires et sont ignorées par le programmequery_contents.

Test de la configuration1. A partir d’une invite MS-DOS sur la machine Win32, exécutez le

programmequery_contentsdepuis le répertoire CGI commesuit :MSDOS> query_contents dirlist=/


6.Jonctions

WebS

EA

L

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 esttrès important de voir au moins le nombre 100 comme première(et quelquefois seule) valeur.

Si un code d’erreur s’affiche à la place, le fichier deconfiguration n’est pas bien placé ou ne contient pas une entréede répertoire principal des documents valide. Vérifiez laconfiguration du fichierquery_contents.cfg et assurez-vous del’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’étapeprécédente. Si le résultat diffère, la configuration CGI de votreserveur Web est incorrecte. Pour remédier à cet incident,reportez-vous à la documentation relative à votre serveur.

Personnalisation de query_contentsLe but dequery_contentsest de renvoyer le contenu des répertoiresinclus dans une requête URL.

Par exemple, pour obtenir le contenu du répertoire racine d’unespace Web du serveur, le navigateur exécutequery_contentsauniveau d’une adresse URL du type :http://serveur_tiers/cgi-bin/query_contents?dirlist=/

Le scriptquery_contentsexécute les actions suivantes :

1. Il lit $SERVER_SOFTWARE, variable d’environnement CGIstandard, pour déterminer le type de serveur.

Basée sur le type de serveur Web, la variable$DOCROOTDIRest définie sur un emplacement racine de document classique.

202 Version 3.8

2. Il lit la variable d’environnement$QUERY_STRING à partir del’adresse URL demandée pour obtenir l’opération demandée etobtenir lechemin d’objet.

La valeur de l’opération est enregistrée dans la variable$OPERATION , et le chemin d’objet dans$OBJPATH. Dansl’exemple précédent, la variable$OPERATION a la valeurdirlist , et $OBJPATH a la valeur “/”.

3. Demande l’affichage de la liste des répertoires (ls) du chemind’objet et place le résultat dans la sortie standard, à destinationdu serveur Policy Director. Les entrées qui indiquent dessous-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 personnaliserquery_contents.sh pour votre serveur UNIX,vous devez modifier le paramètre de répertoire principal desdocuments.

Si query_contentsrenvoie un état d’erreur (un nombre différent de100) et n’affiche aucun fichier, examinez le script et modifiez lavariable$DOCROOTDIR , si nécessaire, pour la faire correspondreà la configuration de votre serveur.

Si le répertoire principal des documents est spécifié correctement etque le script échoue encore, il est possible que la spécification del’emplacementcgi-bin soit incorrecte. Examinez la variable$FULLOBJPATH et modifiez la valeur qui lui est affectée pourqu’elle reflète l’emplacementcgi-bin qui convient.


6.Jonctions

WebS

EA

L

Windows :

Pour personnaliserquery_contents.exe pour votre serveurWindows, modifiez le fichierquery_contents.cfg.

Fonctionnalités supplémentairesLe code source du programmequery_contents(query_contents.c)est distribué gratuitement avec Policy Director.

Il est possible d’ajouter des fonctionnalités supplémentaires à ceprogramme pour assurer la prise en charge de fonctions spéciales deserveurs Web tiers. Ces fonctions peuvent être :

1. Mappage de répertoires — un sous-répertoire ne se trouvant pasen aval du répertoire principal des documents est mappé dansl’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 unebase de données.

Sécurisation de query_contentsPolicy Director utilise le programme CGIquery_contentspourafficher les espaces objet des serveurs Web reliés par jonction dansWeb Portal Manager. Il est très important de sécuriser ce fichier pourempêcher des utilisateurs non authentifiés de l’exécuter.

Vous devez définir une règle de sécurité permettant uniquement àl’identité (pdmgrd) de Management Server d’accéder au programmequery_contents. L’exemple de LCA 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’objetquery_contents.sh (UNIX) ou query_contents.exe (Windows) sur lesserveurs reliés par jonction. Par exemple (UNIX) :pdadmin> acl attach/WebSEAL/<hôte>/<nom_jonction>/query_contents.shquery_contents_acl

204 Version 3.8

Solutions Web à connexionunique (SSO)

Lorsque WebSEAL est mis en oeuvre en tant que serveur proxy pourprotéger un domaine sécurisé, il est souvent nécessaire de fournir dessolutions à connexion unique (SSO, Single Sign On) aux ressourcesWeb. Ce chapitre traite des solutions SSO pour l’espace Web d’uneconfiguration proxy WebSEAL. Ces solutions sont, par exemple, desjonctions configurées d’une manière particulière, des connexionsglobales (GSO, Global Sign-On) et LTPA.


¶ «Configuration d’en-têtes BA pour des solutions SSO» à la page205

¶ «Utilisation d’une connexion globale (GSO)» à la page 213

¶ «Connexion unique à IBM WebSphere (LTPA)» à la page 218

Configuration d’en-têtes BA pour des solutions SSOCette section présente les solutions possibles pour créer desconfigurations SSO via des jonctions WebSEAL à l’aide des options–b.

¶ «Concepts de connexion unique (Single Sign-On - SSO)» à lapage 206

¶ «Spécification de l’identité client dans les en-têtes BA» à lapage 207

7


7.S

olutionsW

ebà

connexionunique

(SS

O)

¶ «Spécification de l’identité client et d’un mot de passegénérique» à la page 208

¶ «Acheminement des informations d’en-tête BA client existantes»à la page 210

¶ «Suppression des informations d’en-tête BA client» à la page211

¶ «Spécification de noms d’utilisateur et de mots de passe à partirde GSO» à la page 212

Concepts de connexion unique (Single Sign-On -SSO)

Lorsqu’une ressource protégée se trouve sur un serveurd’applications Web d’arrière-plan, un client effectuant une requête auniveau de cette ressource peut être obligé de se soumettre à plusieursconnexions : une pour le serveur WebSEAL et une autre pour leserveur d’arrière-plan. Chaque connexion requiert vraisemblablementdifférentes identités de connexion.

Un mécanisme de connexion unique (SSO) permet le plus souventde résoudre cette question d’administration et de gestion de plusieursidentités de connexion. Une solution SSO permet en effet à unutilisateur d’accéder à une ressource, que que soit l’emplacement decette dernière, uniquement à partir de sa connexion initiale. Touteautre exigence de connexion provenant des serveurs d’arrière-planest traitée de façon transparente pour l’utilisateur.


d’applicationsWeb

Jonction

Connexion n° 1 Connexion n° 2

Figure 31. Connexions multiples

206 Version 3.8

Spécification de l’identité client dans les en-têtes BAVous pouvez configurer les jonctions WebSEAL de sorte qu’ellesfournissent au serveur 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é clientspécifiques dans les en-têtes HTTP d’authentification de base (BA).

En tant qu’administrateur, vous devez analyser l’architecture duréseau et les exigences en matière de sécurité, puis répondre auxquestions suivantes :

1. Les informations d’authentification sont-elles nécessaires auserveur d’arrière-plan ?

(WebSEAL utilise l’en-tête HTTP d’authentification de base pourtransmettre des 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 dansl’en-tête HTTP ?)

3. La connexion entre WebSEAL et le serveur d’arrière-plandoit-elle être sécurisée ?

(Jonction TCP ou SSL ?)

Après l’authentification initiale entre le client et WebSEAL,WebSEAL peut constituer un nouvel en-tête d’authentification debase. La requête utilise ce dernier lorsqu’elle joint le serveurd’arrière-plan par le biais de la jonction. Vous spécifiez les options–b pour indiquer les informations d’authentification spécifiquesfournies dans ce nouvel en-tête.


7.S

olutionsW

ebà

connexionunique

(SS

O)

Spécification de l’identité client et d’un mot de passegénérique

–b supply

L’option –b supply demande à WebSEAL d’indiquer le nomd’utilisateur Policy Director authentifié (identité existante du client)avec un mot de passe statique et générique (“fictif”). Le mot depasse client existant n’est pas utilisé dans ce type de scénario.

Un mot de passe générique supprime l’administration de mot depasse et prend en charge l’application utilisateur par utilisateur. Lemot de passe “fictif” est défini par le paramètrebasicauth-dummy-passwddu fichier de configurationwebseald.conf :[junction]basicauth-dummy-passwd = <mot_de_passe>

Ce scénario imagine que le serveur d’arrière-plan requiert uneauthentification de la part d’une identité Policy Director. En mappantun utilisateur client à un utilisateur Policy Director connu, WebSEALgère l’authentification pour le serveur d’arrière-plan et fournit unesolution simple SSO à l’échelle du domaine.

Les conditions suivantes s’appliquent à cette solution :

¶ WebSEAL est configuré pour pouvoir fournir au serveurd’arrière-plan le nom d’utilisateur contenu dans la requête clientoriginale ainsi qu’un mot de passe générique (“fictif”).


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 32. Spécification d’informations d’authentification aux serveurs d’arrière-plan

208 Version 3.8

¶ Le mot de passe “fictif” est configuré dans le fichier deconfigurationwebseald.conf.

¶ Le registre du serveur d’arrière-plan doit reconnaître l’identitéPolicy Director fournie dans l’en-tête HTTP BA.

¶ Comme les informations d’authentification confidentielles (nomd’utilisateur et mot de passe) sont transmises au niveau de lajonction, la sécurité de celle-ci est capitale. Une jonction SSL estdonc vivement recommandée.

LimitesLe même mot de passe “fictif” Policy Director sert à toutes lesrequêtes ; tous les utilisateurs ont le même mot de passe dans leregistre du serveur d’arrière-plan. L’utilisation d’un mot de passe“fictif” commun ne permet donc pas au serveur d’applications delégitimer la connexion d’un client avec ce nom d’utilisateur.

Si les clients passent systématiquement par WebSEAL pour accéderau serveur d’arrière-plan, cette solution ne présente aucun problèmede sécurité. Il est toutefois important de protéger physiquement leserveur d’arrière-plan des autres moyens d’accès possibles.

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 33. L’en-tête BA contient l’identité et le mot de passe fictif.


7.S

olutionsW

ebà

connexionunique

(SS

O)

Comme ce scénario ne comporte pas de sécurité au niveau du motde passe, le serveur d’arrière-plan doit implicitement faire confianceà WebSEAL pour la vérification de la légitimité du client.

Le registre du serveur d’arrière-plan doit également reconnaîtrel’identité Policy Director pour pouvoir l’accepter.

Acheminement des informations d’en-tête BA clientexistantes

–b ignore

L’option –b ignore demande à WebSEAL de transmettre directementl’en-tête BA de client existant au serveur d’arrière-plan, sansinterférence. WebSEAL peut être configuré pour authentifier cesinformations, ou pour ignorer l’en-tête BA fournie par le client, etl’acheminer au serveur d’arrière-plan sans y apporter demodifications.

Remarque : Il ne s’agit pas à proprement parler d’un mécanismeSSO, mais plutôt d’une connexion directe au serveurtiers, de façon transparente pour WebSEAL.


¶ Le serveur d’arrière-plan a besoin que les informations d’identitéclient lui soient fournies par l’authentification de base

Le serveur d’arrière-plan renvoie une demande d’authentificationde base (BA) au client. Le client répond, en indiquant desinformations de nom d’utilisateur et de mot de passe, que leserveur WebSEAL transmet sans modifications.

¶ Le serveur d’arrière-plan gère ses propres mots de passe fournispar le client

¶ WebSEAL est configuré pour pouvoir fournir au serveurd’arrière-plan le nom d’utilisateur et le mot de passe contenusdans la requête client originale.

210 Version 3.8

¶ Comme les informations d’authentification confidentielles (nomd’utilisateur et mot de passe) sont transmises au niveau de lajonction, la sécurité de celle-ci est capitale. Une jonction SSL estdonc vivement recommandée.

Suppression des informations d’en-tête BA client–b filter

L’option –b filter demande à WebSEAL de supprimer toutes lesinformations d’en-tête BA des requêtes client avant de transmettreces dernières au serveur d’arrière-plan. Dans ce scénario, WebSEALdevient le seul fournisseur de sécurité.


¶ L’authentification de base est configurée entre le client etWebSEAL

¶ Le serveur d’arrière-plan ne requiert pas d’authentification debase

¶ Le serveur d’arrière-plan est seulement accessible via WebSEAL

¶ WebSEAL gère l’authentification pour le compte du serveurd’arrière-plan

Client WebSEALjonction


Web

WebSEAL fournit lesinformations d’authentification

client (BA) d’origine

Authentificationde base

Registre Registre

Figure 34. WebSEAL achemine les informations d’identité client existantes


7.S

olutionsW

ebà

connexionunique

(SS

O)

Si vous devez fournir au serveur d’arrière-plan certaines informationsrelatives au client, vous pouvez combiner cette option avec l’option–c pour introduire des informations d’identité client Policy Directordans les champs d’en-tête HTTP. Voir la section «Spécification del’identité du client dans les en-têtes HTTP (–c)» à la page 177.

Spécification de noms d’utilisateur et de mots depasse à partir de GSO

–b gso

L’option –b gsodemande à WebSEAL de fournir au serveurd’arrière-plan les informations d’authentification (nom d’utilisateur etmot de passe) reçues d’un serveur configuré pour gérer uneconnexion GSO (global sign-on), ou connexion globale.


¶ Les applications du serveur d’arrière-plan exigent différentsnoms d’utilisateur et mots de passe non contenus dans le registreWebSEAL.

¶ La sécurité est importante pour WebSEAL comme pour leserveur d’arrière-plan.

Comme les informations d’authentification confidentielles (nomd’utilisateur et mot de passe) sont transmises au niveau de lajonction, la sécurité de celle-ci est capitale. Une jonction SSL estdonc vivement recommandée.

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 35. Suppression des informations d’en-tête BA client

212 Version 3.8

Ce mécanisme est décrit de façon exhaustive dans la section«Utilisation d’une connexion globale (GSO)».

Utilisation d’une connexion globale (GSO)Policy Director permet, à partir d’une seule connexion, de fournird’autres noms d’utilisateur et mots de passe au serveur d’applicationsWeb d’arrière-plan.

Cette solution, très flexible, est prise en charge et mise en oeuvre dedeux façons, suivant le type de registre d’utilisateurs utilisé :

¶ Domaine sécurisé avec registre DCE – utiliser le produit TivoliGlobal Sign-On (GSO)

¶ Domaine sécurisé avec registre LDAP – l’annuaire LDAP fournitle support GSO

La fonction GSO permet aux utilisateurs d’accéder aux ressourcesinformatiques qu’ils sont autorisés à utiliser, par une simpleconnexion. Conçu pour les grandes entreprises constituées deplusieurs systèmes et applications au sein d’environnementshétérogènes et informatiques distribués, GSO élimine le besoin desutilisateurs finaux de gérer plusieurs noms d’utilisateur et mots depasse.

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 de ressources GSO doivent êtrepréalablement créés avec le composant Web Portal Manager.

Lorsque WebSEAL reçoit une requête portant sur une ressourcesituée sur le serveur relié par jonction, il demande au serveur GSOles informations d’authentification appropriées. Le serveur GSOcontient la base de données des mappages (pour chaque utilisateurinscrit) qui fournit d’autres noms d’utilisateur et mots de passe enfonction des ressources et applications spécifiques.


7.S

olutionsW

ebà

connexionunique

(SS

O)

La figure suivante illustre la façon dont le mécanisme GSO permetd’extraire des noms d’utilisateur et des mots de passe pour lesressources de l’application d’arrière-plan.

1. Le client s’authentifie auprès de WebSEAL avec une requêted’accès à une ressource d’application sur un serveurd’arrière-plan. Une identité Policy Director est obtenue.

Remarque : Le processus de connexion unique est indépendantde la méthode d’authentification initiale.

2. WebSEAL transmet l’identité Policy Director au serveur GSO ouLDAP.

3. Le serveur renvoie un nom d’utilisateur et un mot de passeadéquats pour l’utilisateur et la ressource d’applicationdemandée.

4. WebSEAL insère les informations de nom d’utilisateur et de motde passe dans l’en-tête HTTP d’authentification de base de larequête qui est envoyée au serveur d’arrière-plan par la jonction.

Jonctions (-b gso)

WebSEAL

Client


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 36. Mécanisme GSO (Global Sign=on)

214 Version 3.8

Mappage des informations d’authentificationL’exemple suivant illustre la façon dont GSO fournit desinformations d’authentification à WebSEAL. Si l’utilisateur Michaelveut exécuter la ressource d’applicationtravel-app (voir la sectionfigure 36 à la page 214), WebSEAL demande au serveur GSO /LDAP les informations d’authentification de Michael.

Le serveur GSO / LDAP gère une base de données d’authentificationcomplète sous la forme de mappages de ressources avec desinformations d’authentification spécifiques. Les informationsd’authentification sont constituées d’une combinaison nomd’utilisateur / mot de passe, connues sous le nom dedonnéesd’autorisation . Les données d’autorisation d’une ressource nepeuvent être créées que pour des utilisateurs inscrits.

Le serveur contient une base de données pour Michael qui faitcorrespondre la ressource :travel-app à des données d’autorisationspécifiques pour la ressource.

Le tableau ci-après illustre la structure de la base des donnéesd’autorisation de la ressource GSO :

Michael Paul

resource: travel-app username=mikepassword=123

resource: travel-appusername=bundy password=abc

resource: payroll-appusername=powell password=456

resource: payroll-appusername=jensen password=xyz

Dans cet exemple, GSO renvoie le nom d’utilisateur “mike” et lemot de passe “123” à WebSEAL. WebSEAL se sert de cesinformations lorsqu’il définit l’en-tête d’authentification de base dansla requête envoyée par la jonction au serveur d’arrière-plan.

Configuration d’une jonction WebSEAL activée GSOLa prise en charge de GSO est configurée au niveau de la jonctionentre WebSEAL et un serveur d’arrière-plan.


7.S

olutionsW

ebà

connexionunique

(SS

O)

Pour créer une jonction activant GSO, entrez la commandecreateavec l’option–b gso. L’exemple suivant présente la syntaxe de lacommandecreate :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éeci-après :

Options Description

–b gso Indique que GSO doit fournir les informationsd’authentification pour toutes les requêtes passantpar cette jonction.

–T <ressource/groupe_ressources>

Indique la ressource ou le groupe de ressourcesGSO. Le nom de ressource utilisé commeargument de cette option doit exactementcorrespondre au nom de ressource répertorié dansla base de données GSO. Obligatoire pour lesjonctions gso.

Une jonction utilisée dans une solution WebSEAL/GSO peut êtresécurisée au moyen du protocole SSL si l’option–t ssl est rajoutéeau moment de la création de la jonction.

L’usage de jonctions SSL est systématiquement recommandé avecGSO pour garantir le chiffrement de toutes les données, etnotamment les données d’autorisation.

Exemples de jonctions activées GSOJonction de la ressource d’application :travel-app sur l’hôte :sales_svrau point de 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 point de jonction/admin et protection de la jonctionavec SSL :create –t ssl –b gso –T payroll-app –h adm_svr /admin

216 Version 3.8

Remarque : Dans l’exemple précédent, l’option–t ssl indique leport par défaut 443.

Configuration du cache GSOLa fonctionnalité de mémoire cache GSO (Global Sign-on) permetd’optimiser les performances des jonctions GSO dans unenvironnement à forte charge. Par défaut, la mémoire cache GSO estdésactivée. Sans optimisation de la mémoire cache, un appel auserveur LDAP est requis pour chaque extraction des informations surles destinataires GSO (nom d’utilisateur et mot de passe GSO).

Les paramètres de configuration de la mémoire cache GSO setrouvent dans la strophe[gso-cache]du fichier de configurationwebseald.conf. Vous devez tout d’abord activer la mémoire cache.Les autres paramètres configurent la taille de la mémoire cache ainsique les valeurs de délai d’expiration pour les entrées de mémoirecache. 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 lesinformations résidant dans la mémoire WebSEAL sont exposées.N’activez pas la mémoire cache GSO si les jonctions GSO ne sontpas utilisées dans votre solution de réseau.


gso-cache-enabled Active ou désactive la fonctionnalité dela mémoire cache GSO. Les valeurssont “yes” et “no”. La valeur par défautest “no”.

gso-cache-size Définit le nombre maximum d’entréesautorisées dans la table de hachage dela mémoire cache. Affectez à ceparamètre une valeur proche du nombremaximal de sessions utilisateurconcurrentes ayant accès à uneapplication via une jonction GSO. Plusla valeur est élevée, plus la quantité demémoire utilisée est importante maisplus l’accès aux informations est rapide.Chaque entrée de la mémoire cacheoccupe environ 50 octets.


7.S

olutionsW

ebà

connexionunique

(SS

O)


gso-cache-entry-lifetime Durée maximale (en secondes) destockage d’une entrée dans la mémoirecache, quelle que soit l’activité.Lorsqu’une entrée de la mémoire cachearrive à expiration, la requête suivantede ce même utilisateur nécessite unnouvel appel au serveur LDAP.

gso-cache-entry-idle-timeout Durée maximale (en secondes) destockage d’une entrée inactive dans lamémoire cache.

Connexion unique à IBM WebSphere (LTPA)Policy Director WebSEAL peut fournir des services d’autorisation etd’authentification ainsi qu’une protection à un environnement IBMWebSphere. Lorsque WebSEAL est positionné comme serveur frontalprotégeant WebSphere, deux points d’accès possibles se présententaux clients. WebSEAL prend donc en charge une solution SSO à unou plusieurs serveurs IBM WebSphere via des jonctions WebSEAL.

WebSphere fournit une méthode d’authentification LTPA(Lightweight Third Party Authentication) basée sur les cookies. Vouspouvez configurer les jonctions WebSEAL de façon à prendre encharge LTPA et à fournir une solution SSO aux clients.

Lorsqu’un utilisateur demande une ressource WebSphere, il doit toutd’abord s’authentifier auprès de WebSEAL. Une foisl’authentification terminée, WebSEAL génère un cookie LTPA pourle compte de l’utilisateur. Le cookie LTPA, qui sert de jetond’authentification pour WebSphere, contient des informations surl’identité et le mot de passe de l’utilisateur. Ces informations sontchiffrées à l’aide d’une clé secrète protégée par un mot de passe etpartagée entre WebSEAL et le serveur WebSphere.

WebSEAL insère le cookie dans l’en-tête HTTP de la requête qui estenvoyée à WebSphere via la jonction. Le serveur d’arrière-plan

218 Version 3.8

WebSphere la reçoit, déchiffre le cookie et authentifie l’utilisateurd’après les informations d’identité contenues dans le cookie.

Pour optimiser les performances, WebSEAL peut stocker le cookieLTPA dans une mémoire cache de façon à pouvoir le réutiliser pourles requêtes suivantes de la même session utilisateur. Vous pouvezconfigurer les valeurs de la durée de vie et du délai d’inactivité ducookie mis en mémoire cache.

Configuration d’une jonction LTPAUne connexion unique à WebSphere via un cookie LTPA nécessiteles étapes de configuration suivantes :

1. Activez le mécanisme LTPA.

2. Indiquez l’emplacement du fichier de clés utilisé pour chiffrer lesinformations d’identité.

3. Indiquez le mot de passe de ce fichier de clés.

Ces trois conditions de configuration sont définies par trois autresoptions de la commandecreate.

¶ L’option –A active la jonction de façon à prendre en charge lescookies LTPA.

¶ L’option –F <“ fichier_clés”> et l’argument définissent le nomde chemin complet (sur le serveur WebSEAL) du fichier de clésutilisé pour chiffrer les informations d’identité contenues dans lecookie. La clé partagée est initialement créée sur le serveurWebSphere et copiée en toute sécurité sur le serveur WebSEAL.Pour plus d’informations sur cette tâche, reportez-vous à ladocumentation WebSphere qui convient.

¶ L’option –Z <“ mot_de_passe_fichier_clés”> définit le mot depasse requis pour ouvrir le fichier de clés.

Le mot de passe apparaît sous la forme d’un texte chiffré dans lefichier XML de la jonction.


7.S

olutionsW

ebà

connexionunique

(SS

O)

Lorsque vous créez la jonction entre WebSEAL et le serveurd’arrière-plan WebSphere, utilisez ces options avec les autres optionsde jonction requises. Par exemple :create ... -A -F “/abc/xyz/key.file” -Z “abcdefg” ...

Configuration du cache LTPALa création, le chiffrement et le déchiffrement des cookies LTPAentraînent une surcharge de traitement. La fonctionnalité de mémoirecache LTPA permet d’optimiser les performances des jonctions LTPAdans un environnement à forte charge. Par défaut, la mémoire cacheLTPA est activée. Sans l’optimisation de la mémoire cache, unnouveau cookie LTPA est créé et chiffré pour chaque nouvellerequête de l’utilisateur.

Les paramètres de configuration de la mémoire cache LTPA setrouvent dans la strophe[ltpa-cache] du fichier de configurationwebseald.conf. Les paramètres définissent la taille de la mémoirecache et les valeurs de délai d’expiration pour les entrées de lamé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, maisplus les informations contenues dans la mémoire de WebSEAL sontexposées.

220 Version 3.8


ltpa-cache-enabled Active et désactive la fonctionnalité dela mémoire cache LTPA. Les valeurssont “yes” et “no”. La valeur par défautest “yes”.

ltpa-cache-size Définit le nombre maximum d’entréesautorisées dans la table de hachage dela mémoire cache. Affectez à ceparamètre une valeur proche du nombremaximal de sessions utilisateurconcurrentes ayant accès à uneapplication via une jonction LTPA. Plusla valeur est élevée, plus la quantité demémoire utilisée est importante maisplus l’accès aux informations est rapide.Chaque entrée de la mémoire cacheoccupe environ 50 octets. La valeur pardéfaut est 4096 entrées.

ltpa-cache-entry-lifetime Durée maximale (en secondes) destockage d’une entrée dans la mémoirecache, quelle que soit l’activité.Lorsqu’une entrée de la mémoire cachearrive à expiration, la requête suivantede ce même utilisateur nécessite lacréation d’un nouveau cookie LTPA. Lavaleur par défaut est 3600 secondes.

ltpa-cache-entry-idle-timeout Durée maximale (en secondes) destockage d’une entrée inactive dans lamémoire cache. La valeur par défaut est600 secondes.


7.S

olutionsW

ebà

connexionunique

(SS

O)

Remarques techniques sur les connexions uniquesLTPA

¶ Le fichier de clés contient des informations sur un serveurWebSphere spécifique. Une jonction LTPA est propre à unserveur WebSphere. Si vous ajoutez plusieurs serveurs au mêmepoint de jonction, ils partageront tous le même fichier de clés.

¶ Pour que les connexions uniques aboutissent, WebSEAL et leserveur WebSphere doivent, dans une certaine mesure, partagerles mêmes informations de registre.

¶ Le serveur WebSphere prend en charge la configuration de LTPAainsi que la création de la clé secrète partagée. En revanche,WebSEAL permet de configurer les jonctions et la mémoirecache.

222 Version 3.8

Intégration d’application

WebSEAL supporte l’intégration d’applications de tiers grâce à desvariables d’environnement et une capacité d’URL dynamiques.WebSEAL étend la plage des variables d’environnement et desen-têtes HTTP pour permettre à des applications de tiers d’exécuterdes opérations basées sur l’identité du client. En outre, WebSEALpeut fournir un contrôle d’accès sur les adresses URL dynamiques,comme celles contenant du texte de requête.


¶ «Prise en charge de la programmation CGI» à la page 224

¶ «Prise en charge des applications d’arrière-plan côté serveur» àla page 226

¶ «Activation des droits d’accès dynamiques» à la page 228

¶ «Création d’un service d’individualisation personnalisé» à lapage 233

¶ «Ajout d’un contrôle d’accès à des adresses URL dynamiques» àla page 235

¶ «Exemple d’adresse URL dynamique : Travel Kingdom» à lapage 245

8


8.Intégration

d’application

Prise en charge de la programmation CGIPour prendre en charge la programmation CGI, WebSEAL ajoutetrois variables d’environnement au jeu standard de variables CGI.Elles peuvent servir à des applications CGI fonctionnant sur leserveur WebSEAL local ou sur un serveur d’arrière-plan relié parjonction. Ces variables fournissent aux applications CGI desinformations spécifiques de Policy Director, que ce soit dans ledomaine 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 CGIs’exécutant sur un serveur tiers relié par jonction sont générées àpartir des informations d’en-tête HTTP transmises au serveur parWebSEAL. Vous devez spécifier l’option–c pour créer une jonctionqui prend en charge des informations d’en-tête spécifiques de PolicyDirector dans les requêtes destinées à un serveur d’arrière-plan.

Voir aussi la section «Spécification de l’identité du client dans lesen-têtes HTTP (–c)» à la page 177.

Autres variables d’environnement spécifiques de PolicyDirector :


Description

HTTP_IV_USER Nom du compte utilisateur Policy Director del’émetteur de la requête.

HTTP_IV_GROUPS Groupes Policy Director auxquels appartientl’émetteur de la requête. Liste de groupesséparés par une virgule — chaque groupe estencadré de guillemets.

224 Version 3.8


Description

HTTP_IV_CREDS Structure de données opaque codée représentantdes données d’autorisation Policy Director.Fournit des autorisations aux serveurs éloignéspour que les applications de niveauintermédiaire puissent utiliser l’APId’autorisation pour appeler le serviced’autorisation. Reportez-vous au documentPolicy Director ADK Developer Reference.

Variable REMOTE_USER sur un serveur WebSEAL local :

Dans l’environnement d’un serveur local contrôlé par WebSEAL, lavaleur de la variableHTTP_IV_USER répertoriée ci-dessus estfournie comme la valeur de la variableREMOTE_USER standard.La variableREMOTE_USER peut également être présente dansl’environnement d’une application CGI s’exécutant sur un serveurd’arrière-plan relié par jonction. Sa valeur n’est alors pas contrôléepar WebSEAL.

Variabled’environnement

CGI

Description

REMOTE_USER Contient la même valeur que le champHTTP_IV_USER.

Windows : Prise en charge des variablesd’environnement WIN32

Cette section est réservée aux jonctionslocales.

Windows ne met pas automatiquement toutes ses variablesd’environnement système à la disposition des processus (parexemple, des applications CGI). En règle générale, vous trouverezles variables d’environnement système qui vous seront nécessaires.

Toutefois, si tel n’était pas le cas, vous pouvez vous procurer lesvariables Windows dont vous avez besoin dans le fichier de


8.Intégration

d’application

configurationwebseald.conf. (Les variables d’environnementPolicy Director mentionnées dans la section précédente sontautomatiquement disponibles sur toutes les plates-formes.)

Ajoutez les variables d’environnement système Windows requisesdans la strophe[cgi-environment-variables] du fichier deconfigurationwebseald.conf en respectant le format suivant :ENV = <nom_variable>

Par exemple :[cgi-environment-variables]#ENV = SystemDriveENV = SystemRootENV = PATHENV = LANGENV = LC_ALLENV = LC_CTYPEENV = LC_MESSAGESENV = LOCPATHENV = NLSPATH

Un environnement CGI hérite de toute ligne non mise encommentaire.

Prise en charge des applications d’arrière-plan côtéserveur

WebSEAL assure également la prise en charge du code exécutables’exécutant comme un composant incorporé d’un serveur Webd’arrière-plan. Exemples de ce type de code exécutable côtéserveur :

¶ Servlets Java

¶ Cartouches pour Oracle Web Listener

¶ 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, surl’appartenance de groupe et sur l’identité du client, propres à PolicyDirector, dans les en-têtes HTTP des requêtes destinées à ce serveur.

226 Version 3.8

Les informations de ces en-têtes permettent aux applications desserveurs tiers reliés par une jonction d’exécuter des actionsspécifiques de l’utilisateur en fonction de l’identité Policy Directordu client.

WebSEAL comporte un certain nombre d’en-têtes HTTP propres àPolicy Director :

Champs d’en-têteHTTP spé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 uneautorisation Policy Director. Fournit des autorisationsaux serveurs éloignés pour que les applications deniveau intermédiaire puissent utiliser l’APId’autorisation pour appeler le service d’autorisation.Reportez-vous au documentTivoli SecureWay PolicyDirector Authorization Developer Reference.

Ces en-têtes HTTP sont à la disposition des applications CGI en tantque variables d’environnementHTTP_IV_USER,HTTP_IV_GROUPS et HTTP_IV_CREDS. Pour les autresstructures d’applications non CGI, reportez-vous à la documentationpropre à 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 lesen-têtes HTTP (–c)» à la page 177.


8.Intégration

d’application

Activation des droits d’accès dynamiquesLes entreprises et leurs partenaires ont souvent besoin de partagerdes droits d’accès communs tels que des données commerciales(dans une relation business to business) ou des données client (dansune relation business to customer).

¶ Les droits d’accès génériquessont des attributs qui décriventdes informations nécessaires aux applications fournissant desservices. Parmi ces attributs figurent notamment les informationssur les comptes client et les données de facturation.

¶ Les droits d’accès de sécuritésont des attributs qui établissentdes conditions renforcées pour autoriser les requêtes portant surdes ressources. Ceci concerne notamment les rôles utilisateur, lesrestrictions de contrôle d’accès et les règles régissant un accordcommercial.

A l’aide d’une extension du service CDAS (Cross DomainAuthentication Service), Policy Director fournit un mécanismesouple permettant d’inclure des informations sur les droits d’accès,sous la forme d’attributs de valeur/code étendus, dans desautorisations d’utilisateurs lors de l’authentification. Les applicationspeuvent directement extraire ces données à partir d’une autorisationpar le biais de l’API d’autorisation. Pour plus d’informations sur lamise en oeuvre de l’extension CDAS, reportez-vous au documentTivoli Policy Director WebSEAL Developer 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écifiquepermettant d’insérer des informations LDAP supplémentaires définiespar l’utilisateur dans des données d’autorisation sous la formed’attributs étendus. Vous pouvez ensuite placer ces attributs dansl’en-tête HTTP d’une requête envoyée à un serveur d’applicationsd’arrière-plan via une jonction.

¶ Les données supplémentaires définies par l’utilisateur issues den’importe quel champ d’un compte de registre LDAP d’unutilisateur sont ajoutées sous la forme d’attributs étendus à sonautorisation Policy Director.

228 Version 3.8

¶ WebSEAL est configuré de façon à extraire ces données à partirde l’autorisation puis à les placer dans l’en-tête HTTP d’unerequête envoyée à un serveur d’arrière-plan via une jonctionWebSEAL.

¶ L’application d’arrière-plan peut extraire les données de l’en-têtesans avoir besoin 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 registreLDAP et les insérer dans l’autorisation de l’utilisateur lors de laconnexion.

2. En fonction des conditions applicables à la jonction, vous devezextraire les données qui conviennent de l’autorisation et lesinsérer dans l’en-tête HTTP de la requête envoyée via lajonction.

Insertions de données LDAP supplémentaires dans uneautorisation

Il existe deux méthodes pour placer des données utilisateur LDAPsupplémentaires dans une autorisation :

1. Dans la strophe[ldap-ext-cred-tags] du fichier de configurationpd.conf, créez des entrées qui mappent les données LDAP auxchamps de l’autorisation.

Cette méthode est décrite dans cette section.

2. Créez un module CDAS personnalisé qui mappe toutes lesdonnées définies par l’utilisateur aux champs de l’autorisation.

Pour plus d’informations sur la mise en oeuvre de l’extensionCDAS, reportez-vous au documentTivoli Policy DirectorWebSEAL Developer Reference.


8.Intégration

d’application

Pour mapper les données spécifiques de la classe d’objetsinetOrgPerson LDAP à un champ d’attribut défini par l’utilisateurdans son autorisation, vous pouvez utiliser la strophe[ldap-ext-cred-tags] du fichier de configurationpd.conf. Lesparamètres de cette strophe ont le format suivant :<champ_autorisation_personnalisé> =<champ_inetOrgPerson>

Dans l’autorisation elle-même, le nom de chaque paramètrechamp_autorisation_personnalisédéfini dans le fichier deconfigurationpd.conf commence par le préfixe “tagvalue_”. Cepréfixe empêche tous les conflits avec les autres informationsexistantes dans l’autorisation. Par exemple :

Données utilisateur LDAP issues de laclasse d’objets inetOrgPerson :

employeeNumber:09876

Nom du champ personnalisé del’autorisation :

ldap-employee-number

Entrées de paramètre dans la strophe[ldap-ext-cred-tags] :

ldap-employee-number = employeeNumber

Entrée et valeur placées dansl’autorisation de l’utilisateur :

tagvalue_ldap-employee-number:09876

¶ Cette fonctionnalité exige que l’utilisateur s’authentifie à l’aidedu nom d’utilisateur LDAP et du mot de passe. La méthoded’authentificationpasswd-ldapdoit être activée. Le code de labibliothèque partagéelibldapauthn (ldapauthn) recherche dansla strophe[ldap-ext-cred-tags] du fichier de configurationpd.conf les informations supplémentaires sur l’autorisationdéfinies par l’utilisateur.

¶ Les données LDAP peuvent venir d’un champ personnalisé oustandard dans la classe d’objets inetOrgPerson.

¶ Vous pouvez placer plusieurs entrées dans la strophe[ldap-ext-cred-tags].

230 Version 3.8

¶ Tous les attributs définis dans les entrées de la strophe sontplacés dans les données d’autorisation lors d’une connexionutilisateur.

¶ Les noms d’attribut LDAP ne distinguent pas les majuscules desminuscules.

¶ Le nom du champ de l’autorisation distingue 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 à lasection précédente peuvent être placées dans l’en-tête HTTP de larequête envoyée au serveur d’arrière-plan via la jonction. Cette phasecomporte deux tâches :

1. Configurez la jonction de façon à autoriser des donnéesd’autorisation supplémentaires spécifiques. Pour cela, définissezles attributs étendus qui conviennent sur l’objet jonction dansl’espace objet protégé WebSEAL.

2. Extrayez les informations supplémentaires qui conviennent desdonnées d’autorisation et insérez-les dans l’en-tête HTTP de larequête.

Vous contrôlez l’extraction des données d’autorisation nécessaires surune jonction spécifique en définissant des attributs étendus surl’objet jonction. Le nom de l’attribut étendu estHTTP-Tag-Value.Cet attribut étendu utilise le format suivant :<champ_autorisation_personnalisé>=<champ_en-tête_http>


8.Intégration

d’application

Le paramètrechamp_autorisation_personnaliséapparaît exactementde la même manière que dans la strophe[ldap-ext-cred-tags] dufichier de configurationpd.conf. Le préfixe “tag_value” n’est pasinclus. Le paramètre distingue les majuscules des minuscules. Leparamètrechamp_en-tête_httpindique le nom de l’en-tête HTTPutilisé pour stocker les données. Par exemple :

Attribut étenduHTTP-Tag-Value définisur l’objet jonction :

ldap-employee-number=employee-id

Entrée et valeur trouvées dans lesdonnées d’autorisation de l’utilisateur :

tagvalue_ldap-employee-number:09876

Entrée et valeur placées dans l’en-têteHTTP :

employee-id:09876

Lorsque WebSEAL transmet une requête utilisateur à un serveurd’applications d’arrière-plan, il recherche tous les attributs étendusHTTP-Tag-Value configurés sur l’objet jonction.

Pour configurer une jonction avec des attributs étendus, utilisez lacommandepdadmin object modify set attribute :pdadmin> object modify <nom_obj> setattribute <nom_attr><valeur_attr>

Par exemple :pdadmin> object modify /WebSEAL/WS1/junctionA set attributeHTTP-Tag-Value ldap-employee-number=employee-id

Différentes données d’attribut utilisateur peuvent être transmises à unserveur relié par jonction à l’aide de plusieurs commandespdadminobject modify set attribute afin de définir plusieurs attributsétendusHTTP-Tag-Value (un attribut par commande).

232 Version 3.8

Création d’un service d’individualisationpersonnalisé

Un portail Web, également appelé page de lancement, est un servicede sites Web intégré qui dresse, de manière dynamique, la listepersonnalisée des ressources Web mises à la disposition d’unutilisateur spécifique. Celles-ci peuvent inclure des contenusd’entreprise, des services de maintenance et des outils de formation.La sortie du portail représente la liste individualisée des ressourcesbasée sur les droits d’accès de l’utilisateur. La page de lancementcontient uniquement les ressources ayant les droits d’accès quiconviennent pour cet utilisateur.

Vous pouvez utiliser les options de configuration WebSEAL ainsique le service d’attribution de droits d’accès de l’API d’autorisationpour créer une solution de portail personnalisée dans unenvironnement Policy Director.

Le processus de création d’un service de portail WebSEALpersonnalisé implique les éléments suivants :

1. Une région spécifique de l’espace objet protégé est créée pourlocaliser l’ensemble des objets ressource du portail.

2. Les LCA explicites qui conviennent sont associées à chacun deces objets ressource.

3. Le fichier de configuration WebSEAL est édité de façon à inclurel’adresse URL du service du portail, le chemin de l’espace objetcontenant les ressources du portail et le bit de droits d’accèsnécessaire à l’utilisateur pour accéder à ces ressources.

4. Pour chaque requête utilisateur envoyée à l’adresse URL duportail, WebSEAL utilise le service d’attribution de droits d’accèsde l’API d’autorisation pour analyser cet espace objet et dresserla liste des ressources répondant aux conditions d’autorisationapplicables à cet utilisateur.

5. WebSEAL place ces informations dans un en-tête HTTPPD_PORTAL qui est envoyé au serveur du portail d’arrière-plan(relié par jonction).


8.Intégration

d’application

6. Le service du portail personnalisé (par exemple, CGI ou servlet)situé sur le serveur d’arrière-plan lit le contenu de l’en-têtePD_PORTAL et, par exemple, le mappe à des descriptions et àdes liens URL affichés sur une page Web. Ces informationsreprésentent la liste individualisée des ressources mises à ladisposition de l’utilisateur en fonction des droits de la liste decontrôle d’accès.

Configuration de WebSEAL pour un serviced’individualisation

1. Créez une nouvelle jonction WebSEAL pour le serviced’individualisation. Par exemple :pdadmin> server task <nom_serveur> create -t tcp-h portalhost.abc.com /portal-jct

2. Editez le fichier de configurationwebseald.conf pour ajouterune nouvelle strophe[portal-map] :[portal-map]

3. L’entrée de cette strophe identifie l’adresse URL relative auserveur du programme du service du portail, la région del’espace objet dans laquelle sont recherchées les ressourcesprotégées disponibles, et les droits d’accès nécessaires. Il s’agitde 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 explicitescontiennent les droits d’accès qui conviennent pourcet utilisateur sont sélectionnés lors de la recherche.

4. Après avoir ajouté la strophe et les entrées de mappage quiconviennent, vous devez redémarrer WebSEAL (avec lacommandewebseald).

Exemple de service d’individualisation¶ Créez une jonction au serveur du portail :

pdadmin> server task webseald-WS1 -t ssl -h PORTAL1 /portal

234 Version 3.8

¶ Définissez la région de l’espace objet protégé WebSEALcontenant les ressources utilisables par le serviced’individualisation :pdadmin> objectspace create /Resources“Portal Object Hierarchy” 10pdadmin> object create /Resources/Content ““ 10ispolicyattachable yespdadmin> object create /Resources/Support ““ 10ispolicyattachable yespdadmin> object create /Resources/Content/CGI ““ 11ispolicyattachable yespdadmin> object create /Resources/Support/Servlet ““ 11ispolicyattachable yes

Remarque : L’argument “ispolicyattachable” doit avoir la valeur“yes” pour chaque ressource. Le mécanisme derecherche sélectionne uniquement les objetsressource qualifiés possédant des LCA explicites.

¶ Configuration de WebSEAL (webseald.conf) :[portal-map]/portal/servlet/PortalServlet = /Resources:r

¶ Adresse URL du portail utilisée par l’utilisateur :https://WS1/portal/servlet/PortalServlet

Ajout d’un contrôle d’accès à des adresses URLdynamiques

L’environnement Web courant donne aux utilisateurs un accèsimmédiat à des informations qui changent rapidement. Denombreuses applications Web génèrent de façon dynamique desadresses URL en réponse à chaque requête utilisateur. Ces adressesURL dynamiquesont généralement une durée de vie limitée. Malgréleur nature provisoire, elles ont besoin d’être bien protégées contreune utilisation ou un accès indésirable.

Composants d’une adresse URL dynamiqueCertains outils d’applications Web élaborés utilisent des navigateursWeb standard pour communiquer avec des serveurs d’applications aumoyen de l’interface CGI d’un serveur Web.


8.Intégration

d’application

Tous ces outils utilisent des adresses URL dynamiques et deséléments de formulaire caché pour communiquer l’opérationdemandée (avec sa valeur de paramètre) au serveur d’applications.Une URL dynamique dote l’adresse URL standard d’informations surl’opération donnée et ses valeurs de paramètres. La partie constituantla chaîne d’interrogation de l’URL contient les opérations,paramètres et valeurs destinés à l’interface d’application Web.

Mappage d’objets de LCA à des adresses URLdynamiques

WebSEAL utilise le modèle de l’espace objet protégé et des modèlesde règles (LCA) 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 debase de données. Chaque requête effectuée auprès de WebSEAL estconvertie en un objet spécifique, lors de la première étape duprocessus d’autorisation. Une LCA appliquée à l’objet indique laprotection requise sur toute URL dynamique qui y est mappée.

Comme les URL dynamiques n’ont qu’une durée de vie temporaire,des entrées correspondantes ne peuvent pas exister dans une base dedonnées de règles d’autorisation préalablement configurée. PolicyDirector remédie à cet handicap en fournissant une méthodepermettant de mapper de nombreuses URL dynamiques à un seulobjet protégé statique.

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 37. Transmission de données à une passerelle CGI via une adresse URL

236 Version 3.8

Les mappages entre objets et modèles sont conservés dans un fichiertexte simple :/opt/PolicyDirector/www/lib/dynurl.conf

L’emplacement de ce fichier (par rapport à la racine du serveur) estdéfini par le paramètredynurl-map dans la strophe[server] dufichier de configurationwebseald.conf :[server]dynurl-map = lib/dynurl.conf

Ce fichier n’existant pas par défaut, vous devez le créer. L’existencede ce fichier (avec les entrées) permet l’utilisation d’URLdynamiques.

Editez ce fichier pour modifier les mappages. Les entrées de cefichier ont le format suivant :<objet> <modèle>

Policy Director fait appel à un sous-ensemble de forme decorrespondance de shell UNIX (avec caractères génériques) pourdéfinir le jeu de paramètres qui constitue un objet dans l’espaceobjet. Toute URL dynamique correspondant à ces paramètres estmappée à cet objet.


8.Intégration

d’application

Policy Director accepte les métacaractères du shell UNIX suivants :

Caractère Description

\ Le caractère suivant la barre oblique inversée fait partied’une séquence spéciale. Par exemple, \t représente lecaractère TAB. Peut également jouer le rôle du caractèred’é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 plusieurscaractères.

[] Définit un ensemble de caractères, dont l’un quelconquepeut correspondre. 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 uneconsultation de relevé 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 indiquequ’un numéro de compte précis est donné. L’objet pour les soldesbancaires chezbanque_persomontre que les droits d’accès de LCAs’appliquent àtout compte (account), car la dernière partie del’entrée (acc=*) utilise le caractère générique astérisque, quicorrespond à tous les caractères.

238 Version 3.8

La figure ci-après illustre un scénario complet dans lequel uneadresse URL dynamique est mappée à un objet protégé :

Mise à jour de WebSEAL pour des adresses URLdynamiques

Utilisez la commandedynurl update pour mettre à jour l’espaceobjet protégé WebSEAL avec des entrées saisies dans le fichier deconfigurationdynurl.conf.

1. Créez, modifiez ou supprimez une entrée d’URL dynamique dansle fichier de configurationdynurl.conf.

2. Après avoir apporté les modifications, utilisez la commandedynurl update pour mettre à jour le serveur :pdadmin> server task webseald-<nom_serveur> dynurlupdate

L’argumentnom_serveurreprésente le nom d’hôte non qualifiéde la machine WebSEAL.

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 38. Droits d’accès sur une URL dynamique


8.Intégration

d’application

Conversion d’adresses URL dynamiques dansl’espace objet

La conversion d’une URL dynamique en un objet dépend de l’ordredes entrées dans le fichier de configurationdynurl.conf.

Lorsque vous tentez de mapper une URL dynamique à une entréed’objet, la liste des mappages se trouvant dans le fichierdynurl.conf est lue de haut en bas jusqu’à détection de la premièreoccurrence correspondante. A la première occurrence 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 utilisel’adresse URL elle-même, sans la partiehttp://<serveur> duchemin.

Conservez en début de liste les mappages correspondant aux LCAles plus restrictives. Par exemple, si la procédurebook.salesd’uneapplication de commandes de livres doit être limitée à un seulgroupe d’un club littéraire, alors que le reste de l’application peutêtre accessible à tous les utilisateurs, les mappages doivent intervenirdans 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 dansl’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 objet pourrait alorsintroduire une faille dans la sécurité.

Lorsque vous mappez l’expression régulière d’une URL à une entréede l’espace objet, le format de l’URL doit adopter celui produit parla méthode GET, que la méthode utilisée soit POST ou GET.

240 Version 3.8

Avec la méthode de transmission de données GET, les donnéesdynamiques (par exemple, celles qui sont fournies par un utilisateurdans un formulaire) sont ajoutées à l’URL.

Avec la méthode POST, les données dynamiques sont intégrées aucorps de la requête.

Evaluation de LCAUne fois l’URL dynamique convertie en une entrée d’espace objet, lemodèle d’héritage de LCA standard détermine si la requête doit êtretraitée ou annulé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, unerequête POST indique la longueur de ce contenu (déterminée par lenavigateur) exprimée en octets.

post-max-read

Le paramètrepost-max-readdans la strophe[server] du fichier deconfigurationwebseald.conf limite l’impact des requêtes POSTvolumineuses sur WebSEAL en indiquant le nombre maximald’octets à lire dans leur corps. Le contenu que lit WebSEAL estsoumis à des contrôles d’autorisation, comme décrit plus haut danscette section.

La valeur du paramètrepost-max-readest prise en compte lorsquela requête POST est utilisée pour le traitement des adresses URLdynamiques ou l’authentification par formulaires. La valeur pardéfaut est 4096 octets :[server]post-max-read = 4096

Notez que ce paramètre ne limite pas la taille maximale du contenude la requête POST (qui est illimitée). Le paramètre empêcheWebSEAL de traiter une requête POST trop volumineuse.


8.Intégration

d’application

dynurl-allow-large-posts

Bien que le paramètrepost-max-read limite le volume du contenud’une requête POST lu et traité par WebSEAL, la requête peut êtretransmise, dans son ensemble, au serveur d’applications. Dans cescénario, le contenu non validé est transmis au serveurd’applications. Si le serveur d’applications ne dispose pas defonctions d’autorisation propres, la sécurité peut être menacée.

Le paramètredynurl-allow-large-posts permet de contrôler letraitement par WebSEAL des requêtes POST ayant une longueur decontenu supérieure à celle définie parmax-post-read. Si leparamètre a pour valeur “no” (valeur par défaut), WebSEAL rejettetoutes les requêtes POST dont le contenu dépasse la longueur définiepar max-post-read.[server]dynurl-allow-large-posts = no

Si le paramètre a pour valeur “yes”, WebSEAL accepte toute larequête POST mais ne valide que le volume de contenu égal à lavaleur du paramètremax-post-read.[server]dynurl-allow-large-posts = yes

Exemple 1 :

¶ Une requête POST volumineuse est reçue (sa taille dépasse lavaleur du paramètrepost-max-read).

¶ dynurl-allow-large-posts = no

¶ Les adresses URL dynamiques sont activées.

¶ Résultat : Message d’erreur indiquant que cette opération estinterdite.

Exemple 2 :

¶ Une requête POST volumineuse est reçue (sa taille dépasse lavaleur du paramètrepost-max-read).

¶ dynurl-allow-large-posts = yes

242 Version 3.8

¶ Les adresses URL dynamiques sont activées.

¶ Résultat : WebSEAL mappe le contenu jusqu’à la valeur duparamètrepost-max-readà l’entrée de l’espace objet et exécuteun contrôle d’autorisation basé sur cet objet. Le reste du contenun’est pas mappé à l’entrée de l’espace objet et aucun contrôled’autorisation associé à cet objet n’est exécuté.

¶ Le modèle suivant contient un type de forme de correspondancequi favorise une mauvaise utilisation par une requête POST degrande taille :/rtpi153/webapp/examples/HitCount\?*action=reset*

Résumé et remarques techniquesRésumé :

¶ Pour configurer WebSEAL de façon à traiter les adresses URLdynamiques en toute sécurité, créez le fichier suivant :/opt/PolicyDirector/www/lib/dynurl.conf

¶ Le fichier doit contenir une ou plusieurs lignes du format :<objet> <modèle>

¶ Si le fichier est vide ou n’existe pas, l’utilisation d’adresses URLdynamiques n’est pas autorisée.

¶ Une fois le fichier traité, le nom d’objet apparaît sous la formed’une ressource enfant dans l’espace objet WebSEAL.

¶ Le modèle peut contenir certains des caractères de forme decorrespondance standard. Il peut également contenir une chaîneexacte sans aucun caractère de forme de correspondance.


8.Intégration

d’application

Le fichier modèledynurl.conf suivant définit trois objetsreprésentant certaines des applications Web modèle appartenant auproduit 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 :

¶ Vous pouvez mapper plusieurs modèles d’URL au même objet(par exemple, app_snoop mappe des adresses URL sur deuxserveurs différents).

¶ Les objets peuvent être imbriqués (par exemple, app_hitcount etapp_hitcount/ejb).

¶ Une requête URL entrante est comparée avec les modèlesrépertoriés dans le fichier, du premier jusqu’au dernier.Lorsqu’une correspondance est trouvée, le traitement s’arrête. Ilconvient donc de placer les modèles les plus restrictifs au débutdu fichier.

¶ Pour activer les définitions dans le fichierdynurl.conf,exécutez la commandedynurl update (utilisez pdadmin servertask).

La mise à jour intervient aussitôt et les objets apparaissent dansWeb Portal Manager lorsque vous actualisez la vue de l’espaceobjet protégé.

¶ Evitez d’utiliser des majuscules dans le nom d’objet. Utilisezuniquement des minuscules.

¶ N’utilisez pas un nom d’objet qui existe déjà dans l’espace objetprotégé.

244 Version 3.8

¶ Avant de supprimer un objet dans le fichierdynurl.conf,supprimez toutes les LCA qui lui sont associées.

Exemple d’adresse URL dynamique : TravelKingdom

L’exemple suivant montre comment un réseau intranet peut protégerdes adresses URL générées par un programme Oracle Web Listener.

Le serveur Web d’URL dynamiques utilisé dans cet exemple estOracle Web Listener. Cette technologie peut s’appliquer de façonéquivalente à d’autres serveurs Web d’URL dynamiques.

Présentation de l’applicationTravel Kingdom est un organisme qui propose à ses clients unservice de réservation de voyages sur Internet. L’entreprise comptefaire fonctionner deux applications de base de données Oracle surson serveur Web — accessible à l’intérieur du pare-feu d’entrepriseet sur Internet.

1. Système de réservation de voyage

Les clients autorisés peuvent effectuer une réservation à distanceet interroger leur réservation courante. Le personnel de TravelKingdom peut également effectuer une réservation par téléphone,gérer des modifications et effectuer de nombreuses autrestransactions. Comme les clients externes paient les services avecune carte de crédit, la transmission des informations doit êtreparfaitement sécurisée.

2. Responsable administratif

Comme la plupart des sociétés, Travel Kingdom gère une base dedonnées d’administration contenant des informations relatives ausalaire, au poste et à l’expérience. Les données sont égalementaccompagnées d’une photographie de chaque membre dupersonnel.


8.Intégration

d’application

Présentation de l’interfaceUn serveur Web Oracle est configuré pour fournir l’accès auxprocédures suivantes enregistrées dans la base de données :

/db-apps/owa/tr.browse Permet à tous les utilisateurs de serenseigner sur les destinations proposées,les prix, etc.

/db-apps/owa/tr.book Sert à effectuer une réservation (personnelde l’agence de voyage ou clientauthentifié).

/db-apps/owa/tr.change Sert à consulter ou modifier uneréservation en cours.

/db-apps/owa/admin.browse Utilisé par les membres du personnel pourvisualiser les informations sur lepersonnel, sans restriction, par exemple lenuméro de poste, l’adresse électronique etla photographie.

/db-apps/owa/admin.resume Permet à un membre du personnel devisualiser ou modifier les informationsconcernant son CV dans la base dedonnées d’administration.

/db-apps/owa/admin.update Utilisé par le personnel administratif pourmettre à jour les informations concernantle personnel.

Structure de l’espace WebUn serveur WebSEAL permet de fournir une interface sécurisée àl’espace Web unifié de Travel Kingdom.

¶ Une jonction (/ows) est effectuée avec le serveur Web Oracleexécutant à la fois l’application de réservation de voyage etl’application d’administration.

246 Version 3.8

Règles de sécuritéPour fournir une sécurité adéquate aux ressources Web tout enconservant un système convivial, l’entreprise a défini les objectifs desécurité suivants :

1. Le personnel de l’agence de voyage a un contrôle total sur toutesles réservations.

2. Les clients authentifiés peuvent effectuer et modifier leurspropres réservations, mais ne peuvent pas intervenir sur lesdonnées des autres clients authentifiés.

3. Le personnel administratif a un accès total à toutes lesinformations d’administration.

4. Le personnel de Travel Kingdom en dehors du serviced’administration peut modifier les informations concernant sonpropre CV et visualiser des informations partielles concernant lesautres membres du personnel.

Mappages des URL dynamiques dans l’espace objetPour atteindre les objectifs de sécurité décrits ci-dessus, lesmappages entre les URL dynamiques et les entrées d’objet de LCAdoivent être configurés comme indiqué dans la table ci-après.

N’oubliez pas que l’ordre de classement de ces mappages est unfacteur important de 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=????


8.Intégration

d’application

Protection des clientsLe client s’authentifie auprès de WebSEAL sur un canal chiffré etsécurisé.

Les clients souhaitant utiliser l’interface Web doivent en outres’inscrire auprès du Webmaster de Travel Kingdom pour être dotésd’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 TravelKingdom. Ces membres font également partie dugroupe Staff.

Customer Clients de Travel Kingdom souhaitant effectuer leursréservations sur Internet.

Chaque utilisateur reçoit un compte dans le domaine sécurisé pourpouvoir être identifié de façon individuelle par le serveur WebSEAL.Son identité est également transmise aux serveurs Web Oracle defaçon à fournir une solution de connexion unique à toutes lesressources Web.

Contrôle d’accèsLe tableau suivant répertorie les contrôles d’accès résultant del’application des informations précédentes :

/ows/tr/browse unauthenticated Tr any_authenticated Tr

/ows/tr/auth unauthenticated - any_authenticated -groupe TKStaff Tr groupe CustomerPTr

/ows/admin/forall unauthenticated - any_authenticated -groupe Staff Tr

/ows/admin/auth unauthenticated - any_authenticated -groupe AdminStaff Tr

248 Version 3.8

Les clients et le groupe TKStaff disposent des mêmes droits d’accèssur les objets au niveau réservation et voyage, avec la réserve queles clients doivent chiffrer leurs informations (confidentialité) pourrenforcer la sécurité lorsqu’ils soumettent des données confidentielles(telles que des informations de carte de crédit) sur le réseau Internetnon sécurisé.

ConclusionCet exemple simple illustre les concepts liés au déploiement d’unsystème capable de :

¶ protéger les informations confidentielles,

¶ authentifier les utilisateurs,

¶ autoriser l’accès aux informations confidentielles.

En outre, les identités des utilisateurs authentifiés du système sontconnues des serveurs Web Oracle et WebSEAL et permettent defournir une solution à connexion unique, facilement contrôlable.


8.Intégration

d’application

250 Version 3.8

Références du fichierwebseald.conf

Fichier de configuration webseald.conf

Catégories et strophes :

¶ WEBSEAL GENERAL

[server]

¶ LDAP

[ldap]

¶ SSL

[ssl]

¶ JONCTION

[junction]

[filter-url]

[filter-schemes]

[script-filtering]

[gso-cache]

[ltpa-cache]

¶ AUTHENTIFICATION

[ba]

[forms]

[token]

A


A.

Références

dufichier

webseald.conf

[certificate]

[http-headers]

[auth-headers]

[ipaddr]

[authentication-levels]

[mpa]

[cdsso]

[cdsso-peers]

[failover]

[e-community-sso]

[inter-domain-keys]

[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-variables]

[content-index-icons]

[icons]

[content-cache]

[content-mime-types]

[content-encodings]

¶ CONNEXION

[logging]

252 Version 3.8

¶ API D’AUTORISATION

[aznapi-configuration]

[aznapi-entitlement-services]

¶ POLICY DIRECTOR

[policy-director]

[manager]

WEBSEAL GENERAL


strophe[server]

SYSTEME

unix-user Compte utilisateur UNIX pour le serveurWebSEAL.

unix-group Compte de groupe UNIX pour le serveurWebSEAL.

unix-pid-file Emplacement du fichier PID.

server-root Répertoire racine pour le serveurWebSEAL.

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 declient initiale.

persistent-con-timeout Délai d’expiration d’une connexionpermanente HTTP/1.1.

CLIENT HTTPS

https Autorise l’accès HTTPS.

https-port Port à utiliser pour les requêtes HTTPSsé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.


A.

Références

dufichier

webseald.conf

WEBSEAL GENERAL


REQUETES POST

post-max-read Nombre maximal d’octets à lire dans lecorps des requêtes POST.

DYNURL

dynurl-map Emplacement du fichier de mappage objetssécurisés/adresses URL

dynurl-allow-large-posts Limite la capacité de WebSEAL à lire lesrequêtes POST dont la taille dépasse lavaleur depost-max-read.

GESTION DES URI

utf8-url-spport-enabled

LDAP


strophe[ldap]

ldap-server-config Emplacement du fichier de configurationldap.conf (défini lors de la configuration).

cache-enabled Active et désactive la mémoire cacheLDAP locale.

prefer-readwrite-server Permet de sélectionner un serveur LDAPinscriptible disponible.

auth-using-compare Accélère les contrôles d’authentification àl’aide d’un mot de passe de comparaisonau lieu d’un lien LDAP.

default-policy-override-support

Contrôle les règles par défaut ouspécifiques à l’utilisateur.

user-and-group-in-same-suffix

Analyse les performances. Indique que lesgroupes sont définis dans le même suffixeLDAP que l’utilisateur.

ssl-enabled Active et désactive SSL pour lescommunications entre WebSEAL et LDAP.

ssl-keyfile Emplacement du fichier de clés SSL.

254 Version 3.8

LDAP


ssl-keyfile-dn Libellé de certificat dans le fichier de clésSSL, s’il existe.

ssl-keyfile-pwd Mot de passe du fichier de clés SSL.

bind-dn Nom distinctif du démon WebSEAL (définilors de la configuration).

bind-pwd Mot de passe du démon WebSEAL (définilors de la configuration).

enabled

host

port

SSL


strophe[ssl]

webseal-cert-keyfile Emplacement du fichier de clés contenantle certificat de serveur envoyé auxnavigateurs par WebSEAL lors de lanégociation des sessions SSL.

webseal-cert-keyfile-pwd Mot de passe de la clé privée du certificatWebSEAL.

webseal-cert-keyfile-stash Emplacement du fichier caché de mot depasse de la clé privée WebSEAL.

webseal-cert-keyfile-label Nom du certificat WebSEAL à utiliser sidifférent du certificat par défaut.

ssl-keyfile Emplacement du fichier de clés ducertificat WebSEAL utilisé pour lescommunications internes.

ssl-keyfile-pwd Mot de passe de la clé privée du certificatWebSEAL (pour les communicationsinternes).

ssl-keyfile-stash Emplacement du fichier caché de mot depasse de la clé privée WebSEAL (pour lescommunications internes).


A.

Références

dufichier

webseald.conf

SSL


ssl-keyfile-label Nom du certificat à utiliser si différent ducertificat par défaut (pour lescommunications internes).

disable-ssl-v2 Désactive la prise en charge de SSL V2 demanière sélective.

disable-ssl-v3 Désactive la prise en charge de SSL V3 demanière sélective.

disable-tls-v1 Désactive la prise en charge de TLS V1 demanière sélective.

ssl-v2-timeout Délai d’expiration de l’ID de session de lamémoire cache GSKit pour les connexionsSSL V2.

ssl-v3-timeout Délai d’expiration de l’ID de session de lamémoire cache GSKit pour les connexionsSSL V3.

ssl-max-entries Nombre maximum d’entrées concurrentesdans la mémoire cache d’ID de sessionSSL GSKit.

ssl-ldap-server Serveur LDAP utilisé pour le contrôle deliste de révocation des certificats (LRC).

ssl-ldap-server-port Numéro du port d’écoute de ce serveurLDAP pour le contrôle LRC.

ssl-ldap-user Utilisateur administratif pour le serveurLDAP.

ssl-ldap-user-password Mot de passe de l’utilisateur administratifpour le serveur LDAP.

ssl-auto-refresh

ssl-listening-port

ssl-pwd-life

ssl-authn-type

256 Version 3.8

JONCTION


strophe[junction]

junction-db Emplacement de la base de données desjonctions.

jmt-map Emplacement de la table des mappagesjonctions/requêtes (JMT).

http-timeout Délai d’expiration pour l’envoi vers/lalecture sur une jonction TCP.

https-timeout Délai d’expiration pour l’envoi vers/lalecture sur une jonction SSL.

ping-time Intervalle d’exécution de la routine pingentre WebSEAL et les serveurs reliés parjonction.

basicauth-dummy-passwd Mot de passe global lors de laspécification de donnéesd’authentification de base sur desjonctions “-b supply”.

worker-thread-hard-limit Pourcentage de l’ensemble des unitésd’exécution d’agents qui traitent lesrequêtes pour une jonction spécifique.

worker-thread-soft-limit Pourcentage de l’ensemble des unitésd’exécution d’agents qui traitent lesrequêtes pour une jonction spécifique.

io-buffer-size Taille de la mémoire tampon pourl’écriture sur/la lecture à partir d’unejonction.

FILTRAGE DE DOCUMENTS

strophe[filter-url]

<tag> = <attribut> Attributs d’URL filtrés par WebSEALdans les réponses des serveurs reliés parjonction.

strophe[filter-schemes]

scheme = <nom_modèle> Liste des modèles d’URL filtrés parWebSEAL dans les réponses desserveurs reliés par jonction.


A.

Références

dufichier

webseald.conf

JONCTION


strophe[script-filtering]

script-filter Active et désactive le filtrage des URLabsolues contenues dans les scripts setrouvant sur les serveurs reliés parjonction.

MEMOIRE CACHE GSO

strophe[gso-cache]

gso-cache-enabled Active et désactive la mémoire cacheGSO.

gso-cache-size Nombre d’entrées dans la mémoirecache GSO.

gso-cache-entry-lifetime Durée de vie maximale d’une entréedans la mémoire cache GSO.

gso-cache-entry-idle-timeout Durée de vie maximale d’une entréeinactive dans la mémoire cache GSO.

MEMOIRE CACHE LTPA

strophe[ltpa-cache]

ltpa-cache-enabled Active et désactive la mémoire cacheLTPA.

ltpa-cache-size Nombre d’entrées dans la mémoirecache LTPA.

ltpa-cache-entry-lifetime Durée de vie maximale d’une entréedans la mémoire cache LTPA.

ltpa-cache-entry-idle-timeout Durée de vie maximale d’une entréeinactive dans la mémoire cache LTPA.

AUTHENTIFICATION


AUTHENTIFICATION DE BASE

strophe[ba]

ba-auth Active et désactive la méthoded’authentification de base.

258 Version 3.8

AUTHENTIFICATION


basic-auth-realm Nom de cellule affiché dans l’invite deconnexion BA du navigateur.

FORMULAIRES

strophe[forms]

forms-auth Active et désactive l’authentification parformulaires.

JETON

strophe[token]

token-auth Active et désactive l’authentification parcodes de jeton.

CERTIFICAT

strophe[certificate]

accept-client-certs Configure la gestion des certificats côtéclient WebSEAL.

EN-TETES HTTP

strophe[http-headers]

http-headers-auth Active et désactive l’authentification paren-têtes HTTP.

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 paradresses IP.

AUTHENTIFICATION RENFORCEE

strophe[authentication-levels]

level = unauthenticated level= password

Configuration de l’authentificationrenforcée.

AGENTS MPA

strophe[mpa]


A.

Références

dufichier

webseald.conf

AUTHENTIFICATION


mpa Active et désactive la prise en charge del’authentification par agents MPA(Multiplexing Proxy Agents).

CDSSO

strophe[cdsso]

cdsso-auth Active et désactive l’authentification parjetons CDSSO.

authtoken-lifetime Valeur de la durée de vie maximale pour lejeton d’authentification CDSSO.

strophe[cdsso-peers]

<machine-name> =<keyfile-location>

Domaines homologues utilisantl’authentification CDSSO.

COOKIES DE SECOURS

strophe[failover]

failover-auth Active et désactive l’acceptation descookies de secours.

failover-cookies-keyfile Emplacement (chemin absolu) de la clé dechiffrement de cookie générée parcdsso_key_gen.

failover-cookie-lifetime Durée maximale de validité du contenud’un cookie de secours.

enable-failover-cookie-for-domain

Remplace le type cookie de secours deserveur par le type cookie de secours dedomaine.

SSO POUR LA e-COMMUNAUTE

strophe[e-community-sso]

e-community-sso-auth Active et désactive les connexions SSOpour la communauté électronique.

e-community-name Nom de communauté électroniqueapparaissant dans les requêtes et les jetons“d’attestation”.

260 Version 3.8

AUTHENTIFICATION


intra-domain-key Emplacement du fichier de clés utilisépour sécuriser les communications entreles instances WebSEAL dans un domaineDNS.

is-master-authn-server Désigne la machine locale comme serveurd’authentification WebSEAL principal.

master-authn-server Nom du serveur d’authentificationWebSEAL principal (si différent de lamachine locale).

master-http-port Port d’écoute HTTP non standard duserveur d’authentification principal.

master-https-port Port d’écoute HTTPS non standard duserveur d’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 decommunauté électronique.

strophe[inter-domain-keys]

<domain-name> = <keyfile> Fichiers de clés pour les autres domainesappartenant à la communauté électronique.

METHODES D’AUTHENTIFICATION ET BIBLIOTHEQUES

strophe[authentication-mechanisms]

passwd-cdas passwd-ldappasswd-uraf token-cdascert-ssl cert-cdashttp-request cdssopasswd-strengthcred-ext-attrs

Liste des méthodes d’authentification etdes bibliothèques partagées associéesprises 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]


A.

Références

dufichier

webseald.conf

AUTHENTIFICATION


<ip-address> Niveau de chiffrement QOP individuelpour les hôtes.

strophe[ssl-qop-mgmt-networks]

<ip-address/mask> Niveau de chiffrement QOP individuelpour les réseaux.

strophe[ssl-qop-mgmt-default]

default Niveau de chiffrement QOP par défautpour toutes les autres adresses IP sanscorrespondance.

SESSION


strophe[session]

max-entries Nombre maximum d’entrées concurrentesdans la mémoire cache de session/droitsd’accès WebSEAL.

timeout Durée de vie maximale d’une entrée dansla mémoire cache de session/droits d’accèsWebSEAL.

inactive-timeout Durée de vie des entrées inactives dans lamémoire cache des droits d’accèsWebSEAL.

SESSIONS DE CLIENT SSL

ssl-id-sessions Utilise l’ID SSL pour gérer les sessions deconnexion HTTPS.

PARTAGE DE SESSIONS

use-same-session Utilise le même ID de session pour lesclients qui passent de HTTP à HTTPS etinversement.

ENVOI DE COOKIES DE SESSION

resend-webseal-cookies Envoie n’importe quel cookie de secours etde session configuré avec chaque réponseau client.

262 Version 3.8

CONTENU


strophe[content]

FICHIERS ET REPERTOIRES LOCAUX

doc-root Répertoire racine de l’arborescence desdocuments Web.

directory-index Nom du fichier d’index du répertoire.

delete-trash-dir Répertoire temporaire de la corbeille pourles fichiers supprimés par l’administrateur.

REPERTOIRES DES UTILISATEURS LOCAUX

user-dir Ce répertoire est l’arborescence d’accueilde l’utilisateur contenant des documentsHTML publics.

PAGES D’ERREUR

error-dir Répertoire contenant des fichiers dedescription d’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.

logout Nom de la page affichée une fois ladéconnexion terminée.

account-locked Nom de la page affichée sil’authentification échoue à cause d’uncompte verrouillé.

passwd-expired Nom de la page affichée sil’authentification échoue en raison del’expiration d’un mot de passe.

passwd-change Nom du formulaire de modification de motde passe.

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.


A.

Références

dufichier

webseald.conf

CONTENU


help Nom de la page contenant les liens auxpages d’administration.

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.

CGI LOCAL

strophe[cgi]

cgi-timeout Valeur du délai d’expiration pour l’écritureet la lecture sur les processus CGI enfants.

strophe[cgi-types]

bat = cmd cmd = cmd pl =perl sh = sh tcl = tclsh76

Désigne (pour les serveurs Win32) leprogramme à exécuter pour une extensionde fichier CGI spécifique.

strophe[cgi-environment-variables]

ENV Variables d’environnement dont lesprogrammes CGI doivent hériter.

ICONES

strophe[content-index-icons]

image/* video/* audio/*text/html text/*application/x-tar application/*

Spécifie les icônes graphiques à utiliserlorsqu’un index des répertoires est générépar WebSEAL (se produit en l’absence defichier 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 fichierinconnus.

MISE EN MEMOIRE CACHE DE DOCUMENTS

strophe[content-cache]

264 Version 3.8

CONTENU


text/html image/* */* Définit la taille et le type de la mémoirecache pour les documents MIME queWebSEAL enregistre en mémoire.

TYPES MIME

strophe[content-mime-types]

<extension> = <type> Définit le type MIME pour des extensionsde document spécifiques.

deftype Type MIME par défaut à utiliser lorsque letype de document ne figure pas dans latable des mappages.

CODAGES DES CONTENUS

strophe[content-encodings]

gz Z Mappe l’extension de document à un typede codage pour les navigateurs prenant encharge le codage de contenu.

CONNEXION


strophe[logging]

server-log Emplacement du fichier journal des erreursdu serveur.

max-size Seuil de passage à un autre fichier journalpour les journaux HTTP.

flush-time Fréquence de vidage des mémoires tampondu fichier journal HTTP.

requests Active et désactive le journal des requêtesHTTP.

requests-file Emplacement du journal des requêtesHTTP.

referers Active et désactive le journal des liensHTTP.

referers-file Emplacement du journal des liens HTTP.


A.

Références

dufichier

webseald.conf

CONNEXION


agents Active et désactive le journal des agentsHTTP.

agents-file Emplacement du journal des agents HTTP.

gmt-time Consigne les requêtes avec l’heure GMTau lieu de l’heure locale.

API D’AUTORISATION


strophe[aznapi-configuration]

db-file Emplacement du fichier cache de la basede données de règles du client local.

cache-refresh-interval Définit l’intervalle entre les contrôles pourles mises à jour (interrogation) du serveurd’autorisations principal.

listen-flags Active et désactive les indicateurs pour laréception des notifications de mise à jourde la mémoire cache des règles.

tcp-port Port TCP utilisé par le programmed’écoute.

udp-port Port UDP utilisé par le programmed’écoute.

JOURNALISATION DE L’API D’AUTORISATION

logclientid=webseald

logsize Seuil de passage à un autre fichier journalpour la gestion du journal d’audit.

logflush Fréquence de vidage des mémoires tampondu fichier journal de l’audit de gestion.

logaudit Active et désactive l’audit.

auditlog Emplacement du fichier journal d’audit.

auditcfg = azn Enregistre les événements de droitsd’accès.

266 Version 3.8

API D’AUTORISATION


auditcfg = authn Enregistre les événementsd’authentification.

auditcfg = wand Enregistre les événements WebSEAL.

DEFINITIONS DES SERVICES AZNAPI

<service-id>

mode

azn-server-name

pd-user-name

strophe[aznapi-entitlement-services]

AZN_ENT_EXT_ATTR

POLICY DIRECTOR


strophe[policy-director]

config-file Emplacement du fichier de configurationpd.conf.

strophe[manager]

master-host

master-port

master-dn


A.

Références

dufichier

webseald.conf

268 Version 3.8

Référence des jonctionsWebSEAL

L’utilitaire pdadmin fournit une invite de ligne de commandeinteractive à partir de laquelle vous pouvez exécuter des tâches dejonction WebSEAL.


¶ «Utilisation de la commande “pdadmin server task” pour créerdes jonctions» à la page 270

¶ «Commandes de jonction» à la page 271

¶ «Création d’une nouvelle jonction pour un serveur existant» à lapage 272

¶ «Ajout d’un serveur supplémentaire à une jonction existante» àla page 276

B


B.

Référence

desjonctions

WebS

EA

L

Utilisation de la commande “pdadmin server task”pour créer des jonctions

Avant d’utiliser pdadmin, vous devez vous connecter à un domainesécurisé en tant qu’utilisateur administratifsec_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>

Vous pouvez également obtenir les mêmes résultats avec une seuleligne de commande utilisant les options suivantes :# pdadmin -a sec_master -p <mot_de_passe>pdadmin>

Pour créer des jonctions WebSEAL, utilisez la commandepdadminserver task :pdadmin> server task <nom_serveur><tâche>

L’argumentnom_serveurest l’expression complète du nom de lamachine réelle et du composant Policy Director utilisé par cettecommande (par exemple, WebSEAL).<composant_Policy_Director>-<nom_machine>

Par exemple, si le nom de la machine estcruz et que le composantPolicy Director est WebSEAL,nom_serveura la valeur :webseald-cruz

270 Version 3.8

Utilisez la commandeserver list pour vérifier les expressions denom_serveur:pdadmin> server listwebseald-cruz

Les options de commande obligatoires pour créer une jonctionWebSEAL de base sont les suivantes :

¶ Nom d’hôte du serveur d’applications d’arrière-plan (option–h)

¶ Type de jonction : tcp, ssl, tcpproxy, sslproxy, local (option–t)

¶ Point de jonction (point de montage)pdadmin> server task <nom_serveur> create –t<type>–h <nom_hôte> <point_jct>

Commandes de jonctionLes commandes de jonction suivantes sont disponibles avecpdadmin server task :


create Crée une nouvelle jonction pour un serveurexistant.

add Ajoute un ou plusieurs serveurs à un point dejonction existant.

remove Supprime un serveur d’un point de jonction.

Syntaxe : remove –i <id_serveur><point_de_jonction>

Utilisez la commandeshow pour connaître l’IDd’un serveur donné.

delete Supprime le point de jonction.

Syntaxe : delete <point_de_jonction>

list Affiche la liste de tous les points de jonction duserveur.

Syntaxe : list


B.

Référence

desjonctions

WebS

EA

L


show Affiche des informations détaillées concernant lajonction.

Syntaxe : show <point_de_jonction>

jmt load jmt clear La commandejmt load fournit à WebSEAL lesdonnées de la table de mappage des jonctions(jmt.conf) qui lui permet de gérer le traitementdes URL relatives au serveur générées de façondynamique.

La commandejmt clear supprime de WebSEALles données de 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 dejonction spécifique.

exit Quitte l’utilitaire pdadmin.

Syntaxe : exit

Ces commandes, et les options associées, sont présentées dans lessections suivantes.

Création d’une nouvelle jonction pour un serveurexistant

Opération : Créer un nouveau point de jonction et relier un serveurexistant.

Syntaxe :create –t <type> –h<nom_hôte> [<options>]<point_de_jonction>

272 Version 3.8

Type de jonction

–t <type> **Obligatoire**

Type de jonction, parmitcp, ssl, tcpproxy,sslproxy, local.

Le port par défaut de –t tcp est80. Le portpar défaut de –t ssl est443.

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 pours’authentifier auprès du serveurd’arrière-plan.

–B WebSEAL utilise les informations del’en-tête BA pour s’authentifier auprès duserveur d’arrière-plan. Les options defiltrage –U, –W et –b sont requises.

–U<“nom_utilisateur”>

Nom d’utilisateur WebSEAL. A spécifieravec –B pour envoyer les informationsd’en-tête BA au serveur d’arrière-plan.

–W<“mot_de_passe”>

Mot de passe WebSEAL. A spécifier avec–B pour envoyer les informations d’en-têteBA au serveur d’arrière-plan.

–D <“DN”> Spécifie le nom distinctif (DN) du certificatdu serveur d’arrière-plan. Cette valeur,mappée avec le DN réel du certificat,renforce l’authentification.

Options de jonction proxy (requiert –t tcpproxy ou –tsslproxy)




B.

Référence

desjonctions

WebS

EA

L

Spécification d’informations d’en-tête BA

–b <valeur_BA> Définit la façon dont le serveur WebSEALtransmet les informations d’authentificationBA au serveur d’arrière-plan. Valeurspossibles :

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 Policy Directordans les en-têtes HTTP via la jonction.L’argumenttypes_id peut comprendre unecombinaison quelconque de types d’en-têteHTTP Policy Director : iv-user, iv-user-l,iv-groups, iv-creds, all.

–i Le serveur WebSEAL traite les adressesURL sans distinctionmajuscules/minuscules.

–j Fournit une identification de jonction dansun cookie pour gérer les URL relatives auserveur, générées par script.

–k Envoie un cookie de session au serveur deportail d’arrière-plan.

–p <port> Port TCP du serveur d’arrière-plandestinataire. La valeur par défaut est80pour les jonctions TCP ;443 pour lesjonctions SSL.

–q <url> URL relative au scriptquery_contents.Policy Director recherchequery_contentsdans /cgi_bin/. Si ce répertoire est différentou que le fichierquery_contentsestrenommé, servez-vous de cette option pourindiquer à WebSEAL la nouvelle adresseURL du fichier.

–r Insère une adresse IP entrante dans l’en-têteHTTP via la jonction.

–s Indique que la jonction doit prendre encharge des applications avec état. Pardéfaut, les jonctionsne sont pasavec état.

274 Version 3.8

–T <ressource/groupe_ressources>

Nom de la ressource ou du groupe deressources GSO. Obligatoire et utiliséuniquement avec l’option –b gso.

–u <UUID> Spécifie l’UUID d’un serveur d’arrière-planconnecté à 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 chargeune configuration d’hôte virtuelle sur leserveur d’arrière-plan.

Vous spécifiez –v lorsque le serveur dejonction d’arrière-plan attend un en-tête denom d’hôte car vous effectuez une jonctionavec une instance virtuelle de ce serveur.La requête d’en-tête HTTP par défautémanant du navigateur n’est pas informéeque le serveur d’arrière-plan possèdeplusieurs noms et plusieurs serveursvirtuels. Vous devez configurer WebSEALpour qu’il fournisse ces informationsd’en-tête supplémentaires dans les requêtesdestinées à un serveur d’arrière-planconfiguré comme un hôte virtuel.

–w Prise en charge du système de fichiersWin32.

Jonctions LTPA

–A Active et désactive les jonctions LTPA.

–F <“fichier_clés”> Emplacement du fichier de clés utilisé pourchiffrer les données de cookie LTPA.

–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 sslou –t sslproxy.


B.

Référence

desjonctions

WebS

EA

L

Options de jonction locale (à utiliser avec –t local)

–d <dir> Répertoire local de la jonction.**Obligatoire.**

–f Force le remplacement d’une jonctionexistante.

Point de jonction

Emplacement de l’espace de nom WebSEAL où créer la jonction.

Ajout d’un serveur supplémentaire à une jonctionexistante

Opération : Ajoute un serveur supplémentaire à un point dejonction 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 certificatdu serveur d’arrière-plan. Cette valeur,mappée avec le DN réel du certificat,renforce l’authentification.

Options de jonction proxy (requises avec –t tcpproxy et –tsslproxy)



276 Version 3.8

Options de jonction TCP et SSL

–i Le serveur WebSEAL traite les adressesURL sans distinctionmajuscules/minuscules.

–j Fournit une identification de jonction dansun cookie pour gérer les URL relatives auserveur, générées par script.

–p <port> Port TCP du serveur d’arrière-plan tiers. Lavaleur par défaut est80 pour les jonctionsTCP ; 443 pour les jonctions SSL.

–q <url> URL relative au scriptquery_contents.Policy Director recherchequery_contentsdans /cgi_bin/. Si ce répertoire est différentou que le fichierquery_contentsestrenommé, servez-vous de cette option pourindiquer à WebSEAL la nouvelle adresseURL du fichier.

–u <UUID> Spécifie l’UUID d’un serveur d’arrière-planconnecté à 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 chargeune configuration d’hôte virtuelle sur leserveur d’arrière-plan.

Vous spécifiez –v lorsque le serveur dejonction d’arrière-plan attend un en-tête denom d’hôte car vous effectuez une jonctionavec une instance virtuelle de ce serveur.La requête d’en-tête HTTP par défautémanant du navigateur n’est pas informéeque le serveur d’arrière-plan possèdeplusieurs noms et plusieurs serveursvirtuels. Vous devez configurer WebSEALpour qu’il fournisse ces informationsd’en-tête supplémentaires dans les requêtesdestinées à un serveur d’arrière-planconfiguré comme un hôte virtuel.


B.

Référence

desjonctions

WebS

EA

L

–w Prise en charge du système de fichiersWin32.

Point de jonction

Ajoute le serveur à ce point de jonction existant.

278 Version 3.8

Gestion de certificats aveciKeyman

L’utilitaire iKeyman est un outil qui vous permet de gérer voscertificats numériques. AveciKeyman, vous pouvez créer unenouvelle base de données de clés ou un nouveau certificatnumérique, ajouter des racines de CA à votre base de données,copier des certificats d’une base de données à une autre, demander etrecevoir un certificat numérique auprès d’une CA, définir des cléspar défaut et modifier des mots de passe.

L’utilitaire iKeyman fait partie du module GSKit (Global SecurityKit) livré avec Policy Director.


¶ «Lancement de l’utilitaire iKeyman» à la page 280

¶ «Ouverture de la base de données de clés WebSEAL par défaut»à la page 282

¶ «Création d’une nouvelle base de données de clés» à la page284

¶ «Création d’un nouveau certificat numérique d’auto-signature» àla page 287

¶ «Ajout d’un nouveau certificat de CA racine» à la page 290

¶ «Suppression d’un certificat de CA racine» à la page 291

¶ «Copie de certificats entre des bases de données» à la page 291

C


C.

Gestion

decertificats

aveciK

eyman

¶ «Demande d’un certificat de serveur» à la page 296

¶ «Réception d’un certificat numérique» à la page 297

¶ «Suppression d’un certificat numérique» à la page 298

¶ «Attribution d’un nouveau certificat par défaut» à la page 298

¶ «Modification du mot de passe de connexion à la base dedonnées» à la page 300

Lancement de l’utilitaire iKeymanLancez l’utilitaire iKeyman à partir de l’invite de ligne decommande du système d’exploitation :

Windows :MSDOS> /Program Files/IBM/gsk4/bin/gsk4ikm.exe

UNIX :# /usr/bin/gsk4ikm

La fenêtre IBM Key Management s’affiche.

280 Version 3.8

Figure 39. Fenêtre IBM Key Management


C.

Gestion

decertificats

aveciK

eyman

Ouverture de la base de données de clés WebSEALpar défaut

Une base de données de clés contient les certificats côté client etcôté serveur et les certificats de l’autorité de certification (CA)requis par WebSEAL pour traiter l’authentification basée surcertificat.

Lors de l’installation, WebSEAL fournit une base de données de clésde certificat par défaut (pdsrv.kdb). Le fichier de clés contient uncertificat WebSEAL par défaut (libellé de clé = Policy Director) etune sélection des certificats de CA racine courants.

Pour ouvrir la base de données de clés WebSEAL par défaut,procédez comme suit :

1. Dans la fenêtre IBM Key Management, sélectionnez Open dansle menu Key Database File.

2. Dans la fenêtre Open, accédez au répertoire suivant :

UNIX : /opt/PolicyDirector/lib/certs

Windows : C:\Program Files\Tivoli\PolicyDirector\lib\certs

3. Sélectionnez :pdsrv.kdb

4. Cliquez sur Open.

La boîte de dialogue Password Prompt s’affiche.

5. Tapez le mot de passe WebSEAL par défaut :pdsrv

6. Cliquez sur OK.

Les informations de la base de données remplissent la fenêtre degestion.

Vous pouvez remarquer que le certificat WebSEAL par défautapparaît dans la fenêtre Personal Certificates. Le libellé de clé de cecertificat est “Policy Director”. L’astérisque figurant à côté du libelléindique qu’il s’agit du certificat par défaut.

282 Version 3.8

Voir la section figure 40.

Passez du menu déroulant de choix de certificats de PersonalCertificates à Signer Certificates. La liste des certificats racinecourants de l’autorité de certification s’affiche.

Voir la section figure 41 à la page 284.

Figure 40. Fichier de clés WebSEAL pdsrv.kdb par défaut : Certificat WebSEAL


C.

Gestion

decertificats

aveciK

eyman

Création d’une nouvelle base de données de clésUne base de données de clés contient les certificats côté client etcôté serveur et les certificats de l’autorité de certification (CA)requis par WebSEAL pour traiter l’authentification basée surcertificat.

Lors de l’installation, WebSEAL fournit une base de données de clésde certificat par défaut (pdsrv.kdb). Le fichier de clés contient uncertificat WebSEAL par défaut (libellé de clé = Policy Director) etune sélection des certificats de CA racine courants.

Vous pouvez continuer à utiliser cette base de données par défaut ouen créer une autre. Si vous en créez une et que vous souhaitez queWebSEAL l’utilise comme base de données par défaut, vous devezen informer WebSEAL au moyen du paramètressl-keyfile dans lefichier secmgrd.conf. Voir la section «Configuration des paramètresde la base de données de clés pour WebSEAL» à la page 46.

Figure 41. Fichier de clés WebSEAL pdsrv.kdb par défaut : Certificats du signataire

284 Version 3.8

Pour créer un fichier de base de données de clés, procédez commesuit :

1. Dans la fenêtre IBM Key Management, sélectionnez New dansle menu Key Database File.

La boîte de dialogue New s’affiche.

2. Sélectionnez “CMS key database file” dans le champ Keydatabase type.

3. Entrez un nom de fichier tel quekey.kdb.

4. Acceptez la valeur par défaut du champ Location ou entrez unenouvelle valeur, ou sélectionnez une nouvelle valeur à l’aide dubouton Browse.

5. Cliquez sur OK.

La fenêtre Password Prompt s’affiche.

6. Entrez un mot de passe dans le champ Password, puis tapez-le ànouveau dans le champ Confirm Password.

7. (Facultatif) Cochez la case Set expiration time et entrez unevaleur appropriée.

8. (Facultatif) Cochez la case Stash the password to a file.

Un fichier caché contient l’extension suivante : .sth

Vous devez indiquer ce nouveau fichier caché à WebSEAL enconfigurant le paramètressl-keyfile-stashdans le fichier deconfigurationsecmgrd.conf.

Figure 42. Boîte de dialogue New


C.

Gestion

decertificats

aveciK

eyman

Voir la section «Configuration des paramètres de la base dedonnées de clés pour WebSEAL» à la page 46.

9. Cliquez sur OK.

Une fenêtre de confirmation s’affiche pour que vous puissiezvérifier que vous avez créé une nouvelle base de données declés.

10. Cliquez sur OK.

Vous venez de créer une nouvelle base de données de clés. Lafenêtre IBM Key Management s’affiche à nouveau.

La fenêtre IBM Key Management affiche maintenant le nom devotre nouveau fichier de clés ainsi que vos certificats de signataire.

Les certificats numériques de signataire suivants sont fournis aveciKeyman :

¶ RSA Secure Server CA

¶ Thawte Personal Premium CA

¶ Thawte Personal Freemail CA

¶ Thawte Personal Basic CA

¶ Thawte Premium Server CA

¶ Thawte Server CA

¶ VeriSign Class 1 Public Primary CA



¶ VeriSign Test CA Root Certificate

Ces certificats numériques de signataire sont les certificats racineémanant d’autorités de certification (CA) établies. WebSEAL utiliseces certificats racine pour valider les certificats côté client.

Si vous devez utiliser un certificat de signataire ne figurant pas dansla liste, vous devez le demander à l’autorité de certification etl’ajouter dans votre base de données de clés.

286 Version 3.8

Voir la section «Ajout d’un nouveau certificat de CA racine» à lapage 290 .

Remarque : Le certificat racine VeriSign Test CA Root Certificateest inclus à des fins de test. Vous devez supprimer cetteracine avant de placer une classe de base de donnéesde clés dans une application de production.

La nouvelle base de données doit également inclure un certificat deserveur signé de CA pour que WebSEAL puisse s’authentifier auprèsde clients ou d’autres serveurs. Ce certificat est enregistré dans lasection Personal Certificates de la fenêtre de gestion.

Voir la section «Demande d’un certificat de serveur» à la page 296.

Voir la section «Réception d’un certificat numérique» à la page 297.

Création d’un nouveau certificat numériqued’auto-signature

Lorsque vous développez une application de production, vous n’avezpas forcément envie d’exécuter une authentification par certificatavec un vrai certificat numérique avant d’avoir fini de tester leproduit. AveciKeyman, vous pouvez créer un certificat numériqued’auto-signature à utiliser pour les tests. Il s’agit d’un certificatnumérique temporaire que vous émettez pour vous (avec vous-mêmeen tant que CA).

Remarque : Ne publiez pas d’application de production avec uncertificat numérique d’auto-signature, sinon aucunnavigateur ni client ne pourrait reconnaître ou dialogueren toute sécurité avec votre serveur.

Lors de l’installation, WebSEAL fournit un certificat d’auto-signatureappelé “Policy Director”. Vous pouvez utiliser ce dernier à des finsde test ou vous pouvez en créer un autre.


C.

Gestion

decertificats

aveciK

eyman

Pour créer un certificat numérique d’auto-signature, procédez commesuit :

1. A l’aide de iKeyman, ouvrez le fichier de cléspdsrv.kdb ou unautre fichier de clés personnalisé.

La barre de titre de la fenêtre IBM Key Management affiche lenom du fichier de la base de données de clés sélectionné,indiquant que le fichier est ouvert et prêt à être utilisé.

2. Sélectionnez Personal Certificates dans la liste déroulante.

3. Cliquez sur le bouton New Self-Signed.

La boîte de dialogue Create New Self-Signed Certificates’affiche.

4. Entrez un libellé de clé, par exemple “test-cert”.

5. Entrez un nom usuel et une organisation (obligatoires), puissélectionnez un pays. Pour les autres champs, acceptez lesvaleurs par défaut, ou tapez ou sélectionnez d’autres valeurs.

Voir la section figure 43 à la page 289.

6. Cliquez sur OK.

Le champ Personal Certificates de la fenêtre IBM KeyManagement affiche le nom du certificat numériqued’auto-signature que vous avez créé.

288 Version 3.8

Figure 43. Création d’un certificat d’auto-signature


C.

Gestion

decertificats

aveciK

eyman

Ajout d’un nouveau certificat de CA racineAvant d’ajouter un nouveau certificat racine pour une autorité decertification donnée, demandez-le d’abord à cette CA. Chaque CAest dotée de procédures uniques pour cette tâche. Renseignez-vousauprès de l’autorité de certification appropriée à ce sujet-là.

Après avoir reçu un certificat racine demandé à une CA, ajoutez-ledans votre base de données de clés. La plupart des certificats racinerespectent le format*.arm (par exemple,cert.arm).

Pour ajouter un certificat de CA racine à une base de données,procédez comme suit :

1. Dans la fenêtre IBM Key Management, sélectionnez SignerCertificates dans la liste déroulante.

2. Cliquez sur Add.

La fenêtre Add CA’s Certificate from a File s’affiche.

1. Sélectionnez Base64-encoded ASCII data dans le menu déroulantData type.

2. Entrez le nom de fichier du certificat et l’emplacement ducertificat de CA racine, ou sélectionnez-les en cliquant surBrowse.

3. Cliquez sur OK.

La boîte de dialogue Enter a Label s’affiche.

4. Entrez un libellé de clé pour le certificat de CA racine, commeVeriSign Root CA Certificate, et cliquez sur OK.

Figure 44. Boîte de dialogue Add CA’s Certificate

290 Version 3.8

Le champ Signer Certificates contient désormais le libellé ducertificat de CA racine que vous venez d’ajouter.

Suppression d’un certificat de CA racineSi vous ne voulez plus prendre en charge l’un des signatairesfigurant dans la liste des certificats de signataire, vous devezsupprimer le certificat de CA racine approprié.

Remarque : Avant de supprimer un certificat de CA racine, créez-enune copie de sauvegarde pour pouvoir le re-créeréventuellement ultérieurement.

Pour supprimer un certificat de CA racine d’une base de données,procédez comme suit :

1. Dans la fenêtre IBM Key Management, sélectionnez SignerCertificates dans la liste déroulante.

2. Sélectionnez (mettez en évidence) le certificat à supprimer.

3. Cliquez sur Delete.

La fenêtre Confirm s’affiche.

4. Cliquez sur Yes.

Le libellé du certificat de CA racine que vous venez desupprimer ne figure plus dans le champ Signer Certificates.

Copie de certificats entre des bases de donnéesLorsque vous définissez un réseau privé ou que vous utilisez descertificats d’auto-signature à des fins de test, vous pouvez trouvernécessaire de copier un certificat d’une base de données vers uneautre. Pour déplacer des certificats d’une base à l’autre, troisméthodes sont possibles :

¶ Extraction d’un certificat dans un fichier - Ajout d’un certificatà partir d’un fichier

¶ Importation d’un certificat directement d’une base de données

¶ Exportation d’un certificat directement dans une base de données


C.

Gestion

decertificats

aveciK

eyman

Extraction d’un certificat dans un fichier - Ajout d’uncertificat à partir d’un fichier

Pour extraire un certificat d’une base de données de clés (source)dans un fichier puis l’ajouter à la base de données de clés (cible),procédez comme suit :

1. Ouvrez la base de données de clés “source”.

2. Dans le menu déroulant de la fenêtre IBM Key Management,sélectionnez le type de certificat à exporter : Personal ou Signer.

3. Sélectionnez le certificat à ajouter dans une autre base dedonnées.

4. Si vous sélectionnez Personal, cliquez sur le bouton ExtractCertificate. Si vous sélectionnez Signer, cliquez sur le boutonExtract.

La fenêtre Extract a Certificate to a File s’affiche.


Le type de données doit correspondre à celui du certificatenregistré dans le fichier de certificat. L’outiliKeyman accepteles fichiers ASCII codés en Base64 et les certificats binairescodés DER.

6. Entrez le nom de fichier du certificat et l’emplacement ducertificat de CA où l’enregistrer, ou sélectionnez-les en cliquantsur Browse.

7. Cliquez sur OK.

Le certificat est enregistré dans le fichier spécifié.

Figure 45. Extraction d’un certificat dans un fichier

292 Version 3.8

Pour ajouter un certificat du fichier dans la base de donnéesdestinataire, procédez comme suit :

1. Ouvrez la base de données de clés cible.

2. Sélectionnez le type de certificat à ajouter : Personal ou Signer.

3. Pour un certificat de type Signer, cliquez sur Add. Pour uncertificat de type Personal, cliquez sur Receive.

4. Entrez le nom de fichier du certificat et l’emplacement que vousavez utilisés lors de l’extraction du certificat. Vous pouvezégalement vous servir du bouton Browse.

5. Cliquez sur OK.

6. Une fenêtre de confirmation vous demande si ce certificat sera lecertificat par défaut. Cliquez sur Yes ou No.

Le certificat est désormais ajouté dans la base de donnéesdestinataire et figure dans la liste des certificats.

Importation d’un certificat directement d’une base dedonnées

Pour importer un certificat d’une base de données de clés (source)dans une base de données de clés (cible), procédez comme suit :

1. Ouvrez la base de données de clés “cible”.

2. Dans le menu déroulant de la fenêtre IBM Key Management,sélectionnez le type de certificat à exporter : Personal ou Signer.

3. Cliquez sur le bouton Export/Import.

La fenêtre Export/Import Key s’affiche.

4. Sélectionnez Import dans Choose Action Type.

Figure 46. Réception d’un certificat à partir d’un fichier


C.

Gestion

decertificats

aveciK

eyman

5. Dans le menu déroulant Key file type, sélectionnez CMS keydatabase file.

6. Entrez le nom de fichier et l’emplacement de la base de donnéesde clés source contenant le certificat à importer. Vous pouvezégalement vous servir du bouton Browse.

7. Cliquez sur OK.


8. Entrez le mot de passe et cliquez sur OK.

La fenêtre Select From Key Label List s’affiche.

9. Sélectionnez le certificat à importer et cliquez sur OK.

Le certificat apparaît maintenant dans la liste des bases dedonnées destinataires.

Exportation d’un certificat directement dans une basede données

Pour exporter un certificat d’une base de données de clés (source)dans une base de données de clés (cible), procédez comme suit :

1. Ouvrez la base de données de clés “source”.

2. Dans le menu déroulant de la fenêtre IBM Key Management,sélectionnez le type de certificat à exporter : Personal ouSigner.

3. Sélectionnez (mettez en évidence) le certificat à exporter.

4. Cliquez sur le bouton Export/Import.

Figure 47. Export/Import Key

294 Version 3.8

La fenêtre Export/Import Key s’affiche.

5. Sélectionnez Export dans Choose Action Type.

6. Dans le menu déroulant Key file type, sélectionnez CMS keydatabase file.

7. Entrez le nom de fichier et l’emplacement de la base dedonnées de clés cible dans laquelle envoyer le certificat. Vouspouvez également vous servir du bouton Browse.

Remarque : Un message vous informe que vous êtes sur lepoint de remplacer ce fichier de base de données.Cliquez sur “Yes”. Le certificat exporté ne seraajouté qu’à la base de données destinataire. Rienn’est perdu.

8. Cliquez sur OK.


9. Entrez le mot de passe de la base de données destinataire etcliquez sur OK.

10. Lorsque vous ouvrez la base destinataire, le certificat exportéfigure dans la liste des certificats.

Figure 48. Export/Import Key


C.

Gestion

decertificats

aveciK

eyman

Demande d’un certificat de serveurWebSEAL a besoin d’un certificat signé par une CA pours’authentifier auprès des clients SSL. Il peut avoir besoin dedifférents certificats pour répondre à d’autres besoinsd’authentification (par exemple, pour répondre à un serveurd’applications relié par jonction àjunctioncp –K ).

L’utilitaire iKeyman vous permet de générer une demande decertificat que vous pouvez envoyer à l’autorité de certificationappropriée.

Pour générer une demande de certificat, procédez comme suit :

1. Dans la fenêtre IBM Key Management, sélectionnez PersonalCertificate Requests dans la liste déroulante.

2. Cliquez sur New.

La boîte de dialogue Create New Key and Certificate Requests’affiche.

3. Entrez un libellé de clé pour la demande de certificat.

Figure 49. Create New Key and Certificate Request

296 Version 3.8

4. Entrez un nom usuel et une organisation, puis sélectionnez unpays.

Pour les autres champs, acceptez les valeurs par défaut, ou tapezou sélectionnez d’autres valeurs.

5. En bas de la fenêtre, entrez un nom et un emplacement defichier. Vous pouvez également vous servir du bouton Browse.

6. Cliquez sur OK.

Une fenêtre de confirmation s’affiche pour que vous puissiezvérifier que vous avez créé une demande de nouveau certificatnumérique.

7. Cliquez sur OK.

Dans le champ Personal Certificate Requests, figure le libellé declé de la nouvelle demande de certificat numérique que vousavez créée.

8. Envoyez le fichier à l’autorité de certification voulue poureffectuer votre requête, ou coupez/collez la requête dans leformulaire de requête du site Web de la CA.

Réception d’un certificat numériqueUne fois que l’autorité de certification vous envoie un nouveaucertificat numérique signé, vous devez ajouter ce dernier à la base dedonnées de clés à partir de laquelle vous avez généré la demande.

Pour recevoir un certificat numérique, procédez comme suit :

1. Dans la fenêtre IBM Key Management, sélectionnez PersonalCertificate dans la liste déroulante.

2. Cliquez sur Receive.

La fenêtre Receive Certificate from a File s’affiche.


4. Entrez le nom de fichier du certificat et l’emplacement dunouveau certificat numérique. Vous pouvez également vous servirdu bouton Browse.


C.

Gestion

decertificats

aveciK

eyman

Remarque : Si l’autorité de certification envoie le certificat dansun message électronique, vous devez lecouper-coller dans un autre fichier.

5. Cliquez sur OK.

6. La fenêtre Enter a Label s’affiche.

7. Entrez le libellé du nouveau certificat et cliquez sur OK.

Le champ Personal Certificates contient désormais le libellé dunouveau certificat numérique.

Suppression d’un certificat numériqueSi vous n’avez plus besoin de l’un de vos certificats numériques,vous devez le supprimer de votre base de données.

Remarque : Avant de supprimer un certificat numérique, vousdevez créer une copie de sauvegarde au cas où voussouhaiteriez le re-créer ultérieurement.

Pour supprimer un certificat numérique, procédez comme suit :


2. Sélectionnez (mettez en évidence) le certificat à supprimer etcliquez sur Delete.

La fenêtre Confirm s’affiche.

3. Cliquez sur Yes.

Le libellé du certificat numérique sélectionné ne figure plus dansle champ Personal Certificates.

Attribution d’un nouveau certificat par défautL’utilitaire iKeyman vous permet de spécifier un certificatnumérique par défaut destiné à WebSEAL lorsque la base dedonnées de clés contient plusieurs entrées Personal Certificate. (Vouspouvez en effet vous trouver à la tête de plusieurs certificatsnumériques dans une base de données si vous avez commencé à

298 Version 3.8

utiliser un certificat numérique auto-signé dans l’application (pourtest) en attendant la réception du certificat numérique officielémanant de la CA choisie.)

Après avoir reçu un certificat numérique signé de l’autorité decertification, vous pouvez laisser le certificat numérique auto-signédans la base de données et commencer à utiliser celui qui émane dela CA en désignant ce dernier comme certificat numérique pardéfaut. Le certificat numérique par défaut est signalé par unastérisque (*) devant le libellé de son entrée.

Le premier certificat numérique reçu ou créé en tant qu’auto-signéest automatiquement marqué comme certificat numérique par défaut.Chaque fois qu’un nouveau certificat numérique est reçu ou qu’uncertificat numérique auto-signé est créé, vous pouvez le choisircomme certificat numérique par défaut. Vous pouvez toutefoismodifier à tout moment de façon explicite le certificat numérique pardéfaut.

Pour modifier le certificat numérique par défaut, procédez commesuit :


Le certificat numérique par défaut est signalé par un astérisque(*) devant le libellé de son entrée.

2. Sélectionnez un autre certificat numérique à définir commecertificat numérique par défaut et cliquez sur View/Edit. Vouspouvez également cliquer deux fois sur l’entrée.

La fenêtre Key Information window s’affiche.

3. Cochez la case Set the certificate as the default et cliquez surOK.

Le certificat s’affiche alors comme certificat numérique pardéfaut, avec un astérisque (*) devant le libellé de son entrée.


C.

Gestion

decertificats

aveciK

eyman

Modification du mot de passe de connexion à labase de données

L’outil iKeyman permet de changer le mot de passe de connexion àune base de données de clés.

Pour changer un mot de passe de connexion à une base de donnéesde clés, procédez comme suit :

1. Ouvrez une base de données de clés.

2. Dans le menu déroulant Key Database File, sélectionnez ChangePassword.

La fenêtre Change Password s’affiche.

3. Entrez un nouveau mot de passe dans le champ Password, puistapez-le à nouveau dans le champ Confirm Password.

4. Cochez la case Set expiration time, le cas échéant.

5. Cochez la case Stash the password to a file, le cas échéant.

6. Cliquez sur OK.

Un message de la barre d’état indique que la requête a abouti.

300 Version 3.8

Index

Aaccept-client-certs 118account-locked 41acct_locked.html 42acquisition des données d’autorisation

EPAC 10généralités 9

adresse URL dynamiquecontrôle d’accès 235conversion 240dynurl-allow-large-posts 242dynurl-map 237exemple 245généralités 235limitations des requêtes POST 241mappage d’objets de LCA 236méthodes GET et POST 240mise à jour, dynurl update 239post-max-read 241résumé et remarques techniques 243

agent.log 55exemple 60

agents 55agents-file 55authentification

adresse IP 122authentification de base 110CDSSO 131certificat 115communauté électronique 138configuration de plusieurs méthodes 107en-tête HTTP 120explication du processus 88formulaires 112généralités 6généralités sur la configuration 104invite de connexion 108jeton 123méthodes prises en charge 89

authentification(suite)MPA 125objectifs 8type de données de session pris en

charge 89authentification avancée 72authentification CDSSO 131authentification de base

configuration 110authentification de la communauté

électronique 138chiffrement du jeton″d’attestation″ 152configuration 153cookie de communauté électronique 149flux de processus 142fonctions 141jeton ″d’attestation″ 151requête et réponse″d’attestation″ 150

authentification MPA 125authentification par adresse IP 122authentification par certificat 115authentification par en-tête HTTP 120authentification par formulaires 112authentification par jeton 123authtoken-lifetime 137autorisations

attributs étendus 228insertion de données LDAP 228

Bba-auth 110backicon 31basic-auth-realm 111basicauth-dummy-passwd 208bibliothèque partagée CDMF 132


Index

Ccache de session

configuration 93GSKit 92WebSEAL 92

cache GSO, configurer 217cache LTPA, configurer 220cache-refresh-interval 54cdsso 135cdsso-auth 134cdsso_key_gen 103, 136, 152cdssoauthn 135cert-ssl 119certificats

gestion 43GSKit 43iKeyman 43types de fichier de la base de données de

clés 44cgi-timeout 27client-connect-timeout 26commande pd_start 22connexion 41

conditions d’invite 108connexion globale (GSO) 213connexion unique

-b filter 211-b gso 212-b ignore 210-b supply 208CDSSO 131communauté électronique 138concepts 206configurer le cache GSO 217connexion globale (GSO) 213LTPA (WebSphere) 218spécifier l’identité client dans les en-têtes

BA 207contrôle LRC 49cookie de communauté électronique 149cookie de secours, configuration 101cookies de session 96

activation 97

Ddb-file 53déconnexion 41, 108délai d’expiration 94directory-index 30diricon 31disable-ssl-v2 24disable-ssl-v3 24disable-tls-v1 24doc-root 28données d’autorisation

insertion de données dans des en-têtesHTTP 229

données LDAP dans les en-têtes HTTP 228droits d’accès dynamiques 228dynurl-allow-large-posts 242dynurl.conf 236dynurl-map 237dynurl update 239

Ee-community-name 154e-community-sso-auth 153ec-cookie-lifetime 156écoute de la notification de mise à jour 52écoute des notifications 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 121en-tête PD_PORTAL 233entrust-client 121état de session

activer les cookies de session 97cookies de session 96gestion 91types de données d’ID de session

valides 100évolutivité 14

serveurs d’arrière-plan répliqués 17serveurs frontaux répliqués 14

302 Version 3.8

Ffailover-auth 103failover-cookie-lifetime 104failover-cookies-keyfile 104filtrer des URL HTML statiques

adresses URL absolues 196server-relative-URLs 196

flush-time 58format de journal HTTP courant 59forms-auth 113

Ggmt-time 57groupe webseal-mpa-servers 128, 130GSKit 43

types de fichier 44GSO 213

configurer le cache GSO 217gso-cache-enabled 217gso-cache-entry-idle-timeout 217gso-cache-lifetime 217gso-cache-size 217

Hhelp 41help.html 42http 24http-headers-auth 120HTTP_IV_CREDS 177, 224, 227HTTP_IV_GROUPS 177, 224, 227HTTP_IV_REMOTE_ADDRESS 179HTTP_IV_USER 177, 224, 227http-port 24http-request 121HTTP-Tag-Value 231http-timeout (jonctions) 27httpauthn 121https 24https-port 24

https-timeout (jonctions) 27

Iicônes de l’index de répertoires 31ID de session SSL 97iKeyman 47

ajout d’un nouveau certificat de CAracine 290

attribution d’un nouveau certificat pardéfaut 298

certificat de test WebSEAL 117copie de certificats entre bases de

données 291créer un nouveau certificat

d’auto-signature 287créer une nouvelle base de données de

clés 284demande de certificat de serveur 296démarrage 280généralités 49jonctions de type SSL 166jonctions SSL authentifiées de façon

réciproque 169modification du mot de passe de connexion à

la base de données 300ouvrir la base de données de clés par

défaut 282réception de certificat 297suppression d’un certificat 298suppression d’un certificat de CA racine 291

inactive-timeout 95interrogation 52interrogation de la base de données

d’autorisation 54intra-domain-key 152, 154invite de connexion

conditions 108ipaddr-auth 122is-master-authn-server 155iv-creds 177, 227iv-groups 177, 227iv-remote-address 179iv-user 177, 227


Index

Jjmt.conf 187jmt load 187jmt-map 187jonctions

-b filter 211-b gso 212-b ignore 210-b supply 208authentification par certificat 198authentifiées de façon réciproque (-D, -K, -B,

-U, -W) 168certificat client WebSEAL (-K) 170connexion globale (GSO) 213directives en matière de création 161envoyer un cookie de session au serveur de

portail (-k) 180filtrer des URL HTML statiques 196généralités 11, 160gérer des adresses URL absolues avec filtrage

de script 186gérer des adresses URL relatives au serveur

avec mappage des jonctions 187gérer des URL relatives au serveur avec des

cookies 184impact des options -b sur des jonctions

authentifiées de façon réciproque 171jonction proxy (-H, -P) 173LTPA (-A, -F, -Z) 219mise en correspondance DN (-D) 169mise en oeuvre de droits d’accès 198monter plusieurs serveurs 196nouvelle jonction forcée (-f) 176option host (-h) 164option type (-t) 164options gso (-b gso, -T) 215options obligatoires 164pdadmin server task 163prendre en charge des adresses URL sans

disctinction de casse (-i) 181prise en charge d’une jonction avec état (-s,

-u) 189référence de commande 269s’authentifier avec l’en-tête BA (-B, -U,

-W) 171

jonctions (suite)spécifier l’identité client dans les en-têtes

HTTP (-c) 177spécifier l’UUID d’arrière-plan (-u) 190spécifier les adresses IP dans les en-têtes

HTTP (-r) 179systèmes de fichiers Windows (-w) 194table de mappage des jonctions 187traitement d’adresses URL à partir de scripts

(-j) 182WebSEAL / WebSEAL (-C) 174

jonctions authentifiées de façon réciproque 168jonctions WebSEAL, voir jonctions 159journalisation HTTP 55junction-db 160

Lldapauthn 111, 113libcdssoauthn 135libhttpauthn 121libldapauthn 111, 113libsslauthn 119libtokenauthn 124limitation des tentatives de connexion 65listen-flags 53log-filtered-pages 59login.html 42, 114logout.html 42longueur du contenu, request.log 58LTPA (WebSphere) 218

configurer le cache LTPA 220configurer une jonction 219

ltpa-cache-enabled 220ltpa-cache-entry-idle-timeout 220ltpa-cache-entry-lifetime 220ltpa-cache-size 220LTPA WebSphere 218

304 Version 3.8

Mmaster-authn-server 155master-http-port 154master-https-port 154max-entries 94max-size 57mémoire cache d’un document 33

statistiques de mémoire cache 35vidage des mémoires cache 35

mémoire cache de session GSKitconfiguration 95

messages d’erreur HTTP 36prise en charge de macros 40

méthode d’authentification, résumé 89méthode GET 240méthode POST 240

configuration de limites 241mgt-pages-root 40mpa 129

Nnext-token 41nexttoken.html 42niveau de protection

hôte 51niveau par défaut 50réseau 51

niveau de protection des règles POP 83niveaux de protection 4

Ppages HTML personnalisées 40

prise en charge de macros 42paramètres de délai d’expiration

HTTP et HTTPS 26passwd-change 41passwd-change-failure 41passwd-change-success 41passwd_exp.html 42

passwd-expired 41passwd.html 42passwd-ldap 111, 113passwd_rep.html 42pd.conf 229pdadmin policy

disable-time-interval 65max-login-failures 65max-password-repeated-chars 68min-password-alphas 68min-password-length 68min-password-non-alphas 68password-spaces 68

pdadmin server task (jonctions) 163persistent-con-timeout 26ping-time (jonctions) 27pkmscdsso 137pkmslogout 108pkmspasswd 109pkmsvouchfor 150, 156post-max-read 241programmation CGI

prise en charge 224prise en charge de variables d’environnement

WIN32 225protection des ressources 4

Qquery_contents 199

installation 199personnalisation 202sécurisation 204

query_contents.c 199query_contents.cfg 199query_contents.exe 199query_contents.html 199query_contents.sh 199


Index

Rreferer.log 55

exemple 61referers 55referers-file 55règle de renforcement de mot de passe 68règles de LCA, spécifiques de WebSEAL 63règles de LCA default-webseal 65règles de sécurité

attributs étendus 5planification 5règles d’objet protégé 5règles de LCA 5

règles POPauthentification basée sur réseau 79niveau de protection 83renforcement d’authentification

(authentification avancée) 72REMOTE_USER 224répertoire racine, installation WebSEAL 21répertoire racine des documents

modifier l’emplacement 29réplication de serveurs frontaux WebSEAL 54request.log 55

configurer la longueur du contenuenregistré 58

exemple 60requests 55requests-file 55requête et réponse d’attestation 150resend-webseal-cookies 97

Sscript-filter 186server-name 54server-root 22serveur frontal WebSEAL

répliquer 54service d’individualisation

configuration de WebSEAL 234exemple 234généralités 233

ssl-id-sessions 97ssl-keyfile 48ssl-keyfile-label 48ssl-keyfile-pwd 48ssl-keyfile-stash 48ssl-ldap-server 49ssl-ldap-server-port 49ssl-ldap-user 49ssl-ldap-user-password 49ssl-max-entries 96ssl-qop-mgmt 50ssl-v2-timeout 95ssl-v3-timeout 95sslauthn 119statistiques de mémoire cache 35stepup-login 41, 76stepuplogin.html 42, 76strophe acnt-mgt 40strophe authentication-levels 72, 80strophe aznapi-configuration 53strophe cdsso-peers 136strophe cgi-environment-variables 225strophe cgi-types 32strophe content-caches 33strophe filter-url 58, 197strophe inter-domain-keys 152, 156strophe ldap-ext-cred-tags 229, 231strophe logging 59strophe ltpa-cache 220strophe portal-map 234strophe script-filtering 186strophe ssl-qop-mgmt-default 50strophe ssl-qop-mgmt-hosts 51strophe ssl-qop-mgmt-networks 51support d’application, arrière-plan 226support d’application d’arrière-plan 226

Ttcp-port 53token-auth 123token-cdas 124token-login 41tokenauthn 124

306 Version 3.8

tokenlogin.html 42type de données d’ID de session 100type de données de session 89types de fichier de la base de données de

clés 44

Uudp-port 53unknownicon 31use-same-session 97, 99utilisateurs non authentifiés, contrôle 84

Vvaleur de code 228variable d’environnement WIN32, prise en

charge 225vf-token-lifetime 155vf-url 156vidage des mémoires cache 35

WWebSEAL

démarrage et arrêt du serveur 22généralités 2

webseal-cert-keyfile 46webseal-cert-keyfile-label 46, 117, 198webseal-cert-keyfile-pwd 46webseal-cert-keyfile-stash 46webseald.conf

emplacement 20généralités 20référence 251

worker-threads 25


Index

308 Version 3.8

GC11-1766-01

Documents

Tivoli SecureWay Policy Director WebSEAL - Guide d ...publib.boulder.ibm.com/tividd/td/SW_30/GC32-0684... · Microsoft, Windows, Windows NT et le logo Windows sont des marques de