Tivoli SecureWay Policy Director WebSEAL Guía de ...publib.boulder.ibm.com/tividd/td/SW_30/GC32-0684-01/es...Métodos de autenticación y tipos de datos de sesión válidos..... 125

Tivoli SecureWay Policy DirectorWebSEALGuía de administraciónVersión 3.8

Tivoli SecureWay Policy DirectorWebSEALGuía de administraciónVersión 3.8

Tivoli SecureWay Policy Director WebSEAL Guía de administración

Aviso de copyright

© Copyright IBM Corporation 2001. Reservados todos los derechos. Sólo se puede utilizar conforme aun Acuerdo de licencia de software de Tivoli Systems, un Acuerdo de licencia de software de IBM, unAnexo para productos Tivoli para el Cliente de IBM o el Acuerdo de licencia. No se puede reproducir,transmitir, transcribir, almacenar en un sistema de recuperación o convertir a ningún lenguajeinformático ninguna parte de esta publicación de ninguna forma o medio, ya sea electrónico, mecánico,magnético, óptico, químico, manual u otros, sin un permiso previo por escrito de IBM Corporation.IBM Corporation le otorga un permiso limitado para realizar una copia impresa u otras reproduccionesde documentación electrónica para su propio uso, siempre que esa reproducción incluya el aviso decopyright de IBM Corporation. No se otorga ningún otro derecho bajo copyright sin el permiso previopor escrito de IBM Corporation. El documento no está diseñado para la producción y se proporciona“tal cual” sin ninguna garantía de ningún tipo.En este documento se renuncia a todas las garantías,incluidas las garantías de comerciabilidad y adaptabilidad para un propósito particular.

Derechos restringidos para los usuarios del Gobierno de Estados Unidos: el uso, duplicación odivulgación quedan restringidos por el GSA ADP Schedule Contract con IBM Corporation.

Marcas registradas

IBM, el logotipo de IBM, Tivoli, el logotipo de Tivoli, AIX, Cross-Site, NetView, OS/2, Planet Tivoli,RS/6000, Tivoli Certified, Tivoli Enterprise, Tivoli Enterprise Console, Tivoli Ready y TME son marcasregistradas de International Business Machines Corporation o Tivoli Systems Inc. en Estados Unidos, enotros países o en ambos.

Microsoft, Windows, Windows NT y el logotipo de Windows son marcas registradas de MicrosoftCorporation en Estados Unidos, en otros países o en ambos.

UNIX es una marca registrada de The Open Group en Estados Unidos y en otros países.

Java y todas las marcas registradas basadas en Java son marcas registradas de SunMicrosystems, Inc. en Estados Unidos, en otros países o en ambos.

Avisos

Las referencias de esta publicación a productos, programas o servicios de Tivoli Systems o IBM noimplican que estén disponibles en todos los países en los que opera Tivoli Systems o IBM. Cualquierreferencia a estos productos, programas o servicios no implican que sólo se puedan utilizar productos,programas o servicios de Tivoli Systems o IBM. Sujeto a la propiedad intelectual válida u otrosderechos protegidos legalmente de Tivoli Systems o IBM, se puede utilizar cualquier otro producto,programa o servicio con funciones equivalentes en vez del producto, programa o servicio al que se hacereferencia. La evaluación y verificación del funcionamiento con otros productos, excepto los designadosexpresamente por Tivoli Systems o IBM, son responsabilidad del usuario. Tivoli Systems o IBMpueden tener patentes o solicitudes de patentes pendientes que cubran los temas de este documento. Laposesión de este documento no otorga al usuario ninguna licencia sobre esas patentes. Se pueden enviarsolicitudes de licencia, por escrito, a IBM Director of Licensing, IBM Corporation, North Castle Drive,Armonk, New York 10504-1785, Estados Unidos.

Contenido

Prefacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvA quién va destinada esta guía. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Contenido de esta guía. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Convenios tipográficos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xvii

Documentos de Policy Director relacionados. . . . . . . . . . . . . . . . . . . . . . .xviii

Acceso a la documentación en línea. . . . . . . . . . . . . . . . . . . . . . . . . . . . .xviii

Solicitud de documentación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

Comentarios sobre la documentación de productos. . . . . . . . . . . . . . . . . . . . xx

Cómo ponerse en contacto con el servicio de soporte al cliente. . . . . . . . . . xx

Capítulo 1. Visión general de WebSEAL . . . . . . . . . . . . . . . . . 1Protección del espacio Web con WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . 1

Identificación de tipos de contenido y niveles de protección. . . . . . . . . . 4

Planificación e implementación de la Política de seguridad. . . . . . . . . . 5

Información sobre la autenticación de WebSEAL. . . . . . . . . . . . . . . . . . . . . . 6

Objetivos de la autenticación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Información sobre la adquisición de credenciales. . . . . . . . . . . . . . . . . . . . . . 8

Certificado de atributos de privilegios ampliados (EPAC). . . . . . . . . . . . 9

Información sobre las conexiones (junctions) WebSEAL. . . . . . . . . . . . . . . 10

Conexiones (junctions) WebSEAL y escalabilidad del sitio Web. . . . . . 14

Capítulo 2. Configuración del servidor WebSEAL . . . . . . 19Información general sobre el servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Introducción al archivo de configuración webseald.conf. . . . . . . . . . . . 20

Directorio raíz de la instalación de WebSEAL. . . . . . . . . . . . . . . . . . . 21

Directorio raíz del servidor WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . 22

Cómo iniciar y detener WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

iiiTivoli SecureWay Policy Director WebSEAL Guía de administración

Configuración de los parámetros de comunicación. . . . . . . . . . . . . . . . . . . . 23

Configuración de WebSEAL para peticiones HTTP. . . . . . . . . . . . . . . 23

Configuración de WebSEAL para peticiones HTTPS. . . . . . . . . . . . . . 24

Restricción de conexiones de versiones específicas de SSL. . . . . . . . . 24

Configuración de los threads de trabajo HTTP y HTTPS. . . . . . . . . . . 25

Parámetros de tiempo de espera para la comunicación deHTTP/HTTPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Parámetros adicionales de tiempo de espera del servidor WebSEAL . . . 27

Gestión del espacio Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Directorio raíz del árbol de documentos Web. . . . . . . . . . . . . . . . . . . . 28

Configuración del índice de directorios. . . . . . . . . . . . . . . . . . . . . . . . 30

Windows: convenios de denominación de archivos para programasCGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Configuración de la caché de documentos Web. . . . . . . . . . . . . . . . . . 33

Configuración de mensajes de error de HTTP. . . . . . . . . . . . . . . . . . . . . . . 36

Soporte para macros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Gestión de páginas HTML personalizadas. . . . . . . . . . . . . . . . . . . . . . . . . . 40

Parámetros y valores de página personalizados. . . . . . . . . . . . . . . . . . . 41

Descripciones de páginas HTML personalizadas. . . . . . . . . . . . . . . . . . 42

Gestión de certificados de cliente y servidor. . . . . . . . . . . . . . . . . . . . . . . . 42

Información sobre los tipos de archivos de base de datos de claves deGSKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Configuración de los parámetros de la base de datos de claves paraWebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Utilización de la utilidad de gestión de certificados iKeyman. . . . . . . . 48

Configuración de la comprobación de CRL. . . . . . . . . . . . . . . . . . . . . 49

Configuración de la calidad predeterminada del nivel de protección. . . . . . . 50

Configuración de QOP para redes y hosts individuales. . . . . . . . . . . . . 51

Configuración de actualizaciones y sondeos de la base de datos deautorizaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

iv Versión 3.8

Configuración de la escucha de notificación de actualizaciones. . . . . . 53

Configuración del sondeo de la base de datos de autorizaciones. . . . . . 53

Replicación de servidores WebSEAL frontales. . . . . . . . . . . . . . . . . . . . . . . 54

Configuración del registro de HTTP estándar. . . . . . . . . . . . . . . . . . . . . . . . 55

Activación y desactivación del registro HTTP. . . . . . . . . . . . . . . . . . . 56

Especificación del tipo de indicación de la fecha y hora. . . . . . . . . . . . 56

Especificación de los umbrales de creación de un nuevo archivo deregistro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Especificación de la frecuencia para vaciar los búferes de los archivosde registro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Configuración de la longitud del contenido registrada en request.log 58

Formato de registro de HTTP común (para request.log). . . . . . . . . . . . 59

Visualización del archivo request.log. . . . . . . . . . . . . . . . . . . . . . . . . . 59

Visualización del archivo agent.log. . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Visualización del archivo referer.log. . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Capítulo 3. Política de seguridad de WebSEAL . . . . . . . . 63Políticas de ACL específicas de WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . 63

/WebSEAL/<host> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

/WebSEAL/<host>/<archivo> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Permisos ACL de WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Política de ACL predeterminada de /WebSEAL. . . . . . . . . . . . . . . . . . 65

Política de inicio de sesión de tres intentos. . . . . . . . . . . . . . . . . . . . . . . . . 65

Sintaxis de los comandos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Política de intensidad de la contraseña. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Política de intensidad de la contraseña establecida por la utilidadpdadmin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Sintaxis de los comandos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Ejemplos de contraseñas válidas y no válidas. . . . . . . . . . . . . . . . . . . . 71

Valores globales y específicos de un usuario. . . . . . . . . . . . . . . . . . . . 71

vTivoli SecureWay Policy Director WebSEAL Guía de administración

Política POP de intensidad de la autenticación (incremental). . . . . . . . . . . . 72

Configuración de los niveles de autenticación incremental. . . . . . . . . . 73

Activación de la autenticación incremental. . . . . . . . . . . . . . . . . . . . . . 74

Formulario de inicio de sesión incremental. . . . . . . . . . . . . . . . . . . . . 76

Algoritmo de autenticación incremental. . . . . . . . . . . . . . . . . . . . . . . . 78

Notas y limitaciones de la autenticación incremental. . . . . . . . . . . . . . 78

Política POP de autenticación basada en la red. . . . . . . . . . . . . . . . . . . . . . . 79

Configuración de los niveles de autenticación. . . . . . . . . . . . . . . . . . . 80

Especificación de direcciones y rangos IP. . . . . . . . . . . . . . . . . . . . . . 80

Desactivación de la autenticación incremental por dirección IP. . . . . . . 82

Algoritmo de autenticación basada en la red. . . . . . . . . . . . . . . . . . . . 82

Notas y limitaciones de la autenticación basada en la red. . . . . . . . . . . 83

Política POP de calidad de protección. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Gestión de usuarios no autenticados (HTTP / HTTPS). . . . . . . . . . . . . . . . . 84

Proceso de una petición desde un cliente anónimo. . . . . . . . . . . . . . . . 84

Cómo forzar el inicio de sesión del usuario. . . . . . . . . . . . . . . . . . . . . 85

Aplicaciones de HTTPS sin autenticación. . . . . . . . . . . . . . . . . . . . . . 85

Control de usuarios no autenticados con políticas de ACL/POP. . . . . . 85

Capítulo 4. Autenticación de WebSEAL . . . . . . . . . . . . . . . . . 87Información sobre el proceso de autenticación. . . . . . . . . . . . . . . . . . . . . . . 88

Tipos de datos de sesión soportados. . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Métodos de autenticación soportados. . . . . . . . . . . . . . . . . . . . . . . . . . 89

Referencias a la información de configuración detallada. . . . . . . . . . . . 90

Gestión del estado de la sesión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Las cachés de sesión de GSKit y WebSEAL. . . . . . . . . . . . . . . . . . . . 92

Configuración de la caché de credenciales de WebSEAL. . . . . . . . . . . 93

Configuración de la caché de ID de sesión SSL de GSKit. . . . . . . . . . 95

Mantenimiento del estado con cookies de sesión. . . . . . . . . . . . . . . . . 96

vi Versión 3.8

Determinación de los tipos de datos de ID de sesión válidos. . . . . . . . 99

Configuración de cookies de recuperación tras error. . . . . . . . . . . . . . 101

Visión general de la configuración de la autenticación. . . . . . . . . . . . . . . . 104

Parámetros de autenticación local. . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Parámetros de autenticación de CDAS personalizado externo. . . . . . . 105

Configuración predeterminada para la autenticación de WebSEAL 106

Configuración de varios métodos de autenticación. . . . . . . . . . . . . . . 106

Solicitud de inicio de sesión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Comandos de fin de sesión y de cambio de contraseña. . . . . . . . . . . . 108

Configuración de la autenticación básica. . . . . . . . . . . . . . . . . . . . . . . . . . 109

Activación y desactivación de la autenticación básica. . . . . . . . . . . . . 110

Configuración del nombre de dominio. . . . . . . . . . . . . . . . . . . . . . . . 110

Configuración del mecanismo de autenticación básica. . . . . . . . . . . . . 111

Condiciones de configuración. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Configuración de la autenticación de formularios. . . . . . . . . . . . . . . . . . . . 112

Activación y desactivación de la autenticación de formularios. . . . . . 112

Configuración del mecanismo de autenticación de formularios. . . . . . 113


Personalización de los formularios HTML de respuesta. . . . . . . . . . . 114

Configuración de la autenticación de certificados de cliente. . . . . . . . . . . . 114

Segundo plano: Autenticación mutua mediante certificados. . . . . . . . . 115

El certificado de prueba de WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . 116

Activación y desactivación de la autenticación de certificados. . . . . . 117

Configuración del mecanismo de autenticación de certificados. . . . . . 118


Configuración de autenticación de cabecera HTTP. . . . . . . . . . . . . . . . . . . 119

Activación y desactivación de la autenticación de cabeceras HTTP 120

Especificación de tipos de cabecera. . . . . . . . . . . . . . . . . . . . . . . . . . 120

Configuración del mecanismo de autenticación de cabeceras HTTP 120

viiTivoli SecureWay Policy Director WebSEAL Guía de administración


Configuración de autenticación de direcciones IP. . . . . . . . . . . . . . . . . . . . 122

Activación y desactivación de la autenticación de direcciones IP. . . . 122

Configuración del mecanismo de autenticación de direcciones IP. . . . 122

Configuración de la autenticación de señales. . . . . . . . . . . . . . . . . . . . . . . 122

Activación y desactivación de la autenticación de señales. . . . . . . . . . 123

Configuración del mecanismo de autenticación de señales. . . . . . . . . 123

Soporte para Multiplexing Proxy Agents. . . . . . . . . . . . . . . . . . . . . . . . . . 124

Métodos de autenticación y tipos de datos de sesión válidos. . . . . . . . 125

Flujo de procesos de autenticación para MPA y clientes múltiples 127

Activación y desactivación de la autenticación de MPA. . . . . . . . . . . 128

Creación de una cuenta de usuario para el MPA. . . . . . . . . . . . . . . . . 129

Adición de la cuenta de MPA en el grupo webseal-mpa-servers. . . . . 129

Limitaciones de la autenticación de MPA. . . . . . . . . . . . . . . . . . . . . . 129

Capítulo 5. Soluciones de inicio de sesión endominios cruzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Configuración de la autenticación de CDSSO. . . . . . . . . . . . . . . . . . . . . . . 131

Integración de una biblioteca compartida CDMF personalizada. . . . . . 132

Flujo de procesos de autenticación para CDSSO con CDMF. . . . . . . 132

Activación y desactivación de la autenticación de CDSSO. . . . . . . . . 134

Configuración del mecanismo de autenticación de CDSSO. . . . . . . . . 135

Cifrado de los datos de la señal de autenticación. . . . . . . . . . . . . . . . 136

Configuración de la indicación de fecha y hora de la señal. . . . . . . . . 137

Expresión de vínculos HTML de CDSSO. . . . . . . . . . . . . . . . . . . . . . 137

Protección de la señal de autenticación. . . . . . . . . . . . . . . . . . . . . . . 137

Configuración del inicio de sesión único de comunidad electrónica. . . . . . . 138

Características y requisitos de la comunidad electrónica. . . . . . . . . . . 141

Flujo de procesos de la comunidad electrónica. . . . . . . . . . . . . . . . . . 142

Información sobre la cookie de comunidad electrónica. . . . . . . . . . . . 149

viii Versión 3.8

Información sobre la petición y la respuesta de “garantización”. . . . . 150

Información sobre la señal de “garantización”. . . . . . . . . . . . . . . . . . 151

Cifrado de la señal de “garantización”. . . . . . . . . . . . . . . . . . . . . . . . 152

Configuración de una comunidad electrónica. . . . . . . . . . . . . . . . . . . 153

Capítulo 6. Conexiones (junctions) WebSEAL . . . . . . . . 159Visión general de las conexiones (junctions) WebSEAL. . . . . . . . . . . . . . . 160

Ubicación y formato de la base de datos de conexión (junction). . . . . 160

Aplicación del control de acceso flexible: Resumen. . . . . . . . . . . . . . 161

Aplicación del control de acceso estricto: Resumen. . . . . . . . . . . . . . 161

Directrices para la creación de conexiones (junctions) WebSEAL. . . . 162

WebSEAL sólo da soporte a HTTP 1.0 a través de conexiones(junctions). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Referencias adicionales para las conexiones (junctions) WebSEAL 163

Utilización de “pdadmin server task” para crear conexiones (junctions) 163

Configuración de una conexión (junction) WebSEAL básica. . . . . . . . . . . . 164

Conexiones (junctions) de tipo TCP. . . . . . . . . . . . . . . . . . . . . . . . . . 165

Conexiones (junctions) de tipo SSL. . . . . . . . . . . . . . . . . . . . . . . . . . 165

Conexiones (junctions) SSL autenticadas mutuamente. . . . . . . . . . . . . . . . 167

WebSEAL valida el certificado de servidor de fondo. . . . . . . . . . . . . 168

Coincidencia de Nombre distinguido (DN). . . . . . . . . . . . . . . . . . . . . 169

WebSEAL se autentica con el certificado de cliente .. . . . . . . . . . . . . 169

WebSEAL se autentica con una cabecera de BA. . . . . . . . . . . . . . . . 170

Gestión de la información de identidad del cliente a través deconexiones (junctions). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Creación de conexiones (junctions) proxy TCP y SSL. . . . . . . . . . . . . . . . 172

Conexiones (junctions) de WebSEAL a WebSEAL a través de SSL. . . . . . 174

Opciones de conexión (junction) adicionales. . . . . . . . . . . . . . . . . . . . . . . 175

Cómo forzar una nueva conexión (junction) (–f). . . . . . . . . . . . . . . . 175

Especificación de la identidad del cliente en cabeceras HTTP (–c) 177

ixTivoli SecureWay Policy Director WebSEAL Guía de administración

Especificación de la dirección IP del cliente en cabeceras HTTP (–r) 179

Transferencia de cookies de sesión a servidores de portal conconexión (junction) (–k). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Soporte para direcciones URL no sensibles a mayúsculas yminúsculas (–i). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Proceso de direcciones URL a partir de scripts y aplicaciones decliente (–j). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Gestión de direcciones URL relativas al servidor con correlación deconexiones (junctions). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Soporte para conexiones (junction) con información de estado (–s,–u) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Especificación de UUID de servidor de fondo para conexiones(junctions) con información de estado (–u). . . . . . . . . . . . . . . . . . . . . 190

Conexión (junction) con sistemas de archivos de Windows (–w). . . . . 194

Notas técnicas sobre el uso de conexiones (junctions) WebSEAL. . . . . . . . 196

Montaje de varios servidores en la misma conexión (junction). . . . . . 196

Filtro de direcciones URL HTML estáticas de los servidores conconexión (junction). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Excepciones para aplicar permisos a través de las conexiones(junctions). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Autenticación de certificados a través de las conexiones (junctions) 199

Utilización de query_contents con servidores de terceros. . . . . . . . . . . . . . 200

Instalación de query_contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Instalación de query_contents en servidores UNIX de terceros. . . . . . 201

Instalación de query_contents en servidores Win32 de terceros. . . . . . 201

Personalización de query_contents. . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Protección de query_contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Capítulo 7. Soluciones de inicio de sesión único enla Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Configuración de cabeceras de BA para soluciones de inicio de sesiónúnico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

x Versión 3.8

Conceptos del inicio de sesión único (SSO). . . . . . . . . . . . . . . . . . . . 208

Especificación de la identidad del cliente en cabeceras de BA. . . . . . 209

Especificación de la identidad del cliente y de la contraseña genérica 210

Reenvío de la información de cabecera de BA de cliente original. . . . 212

Eliminación de la información de cabecera de BA de cliente. . . . . . . 213

Especificación de nombres de usuario y contraseñas de GSO. . . . . . . 214

Utilización de Global Sign-on (GSO). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Correlación de la información de autenticación. . . . . . . . . . . . . . . . . 217

Configuración de una conexión (junction) WebSEAL preparada paraGSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Configuración de la caché de GSO. . . . . . . . . . . . . . . . . . . . . . . . . . 219

Inicio de sesión único en IBM WebSphere (LTPA). . . . . . . . . . . . . . . . . . . 220

Configuración de una conexión (junction) LTPA. . . . . . . . . . . . . . . . 221

Configuración de la caché de LTPA. . . . . . . . . . . . . . . . . . . . . . . . . . 222

Notas técnicas sobre el inicio de sesión único de LTPA. . . . . . . . . . . 223

Capítulo 8. Integración de aplicaciones . . . . . . . . . . . . . . . 225Soporte para la programación de CGI. . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Windows: soporte para variables de entorno de WIN32. . . . . . . . . . . 227

Soporte para aplicaciones de un servidor de fondo. . . . . . . . . . . . . . . . . . . 228

Activación de los derechos empresariales dinámicos. . . . . . . . . . . . . . . . . . 230

Creación de derechos empresariales a partir de datos LDAP. . . . . . . . 230

Creación de un servicio de personalización personalizado. . . . . . . . . . . . . . 234

Configuración de WebSEAL para un servicio de personalización. . . . 235

Ejemplo de servicio de personalización. . . . . . . . . . . . . . . . . . . . . . . 236

Especificación del control de acceso a las direcciones URL dinámicas. . . . 237

Componentes de direcciones URL dinámicas. . . . . . . . . . . . . . . . . . . 237

Correlación de objetos ACL con direcciones URL dinámicas. . . . . . . 238

Actualización de WebSEAL para direcciones URL dinámicas. . . . . . . 240

xiTivoli SecureWay Policy Director WebSEAL Guía de administración

Resolución de direcciones URL dinámicas en el espacio de objetos 241

Configuración de limitaciones en las peticiones POST. . . . . . . . . . . . 242

Resumen y notas técnicas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Ejemplo de dirección URL dinámica: Travel Kingdom. . . . . . . . . . . . . . . . 246

La aplicación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

La interfaz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

La política de seguridad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Clientes protegidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Control de acceso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Conclusión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Apéndice A. Referencia de webseald.conf . . . . . . . . . . . . 251

Apéndice B. Referencia para las conexiones(junctions) WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Utilización de “pdadmin server task” para crear conexiones (junctions) 269

Los comandos de la conexión (junction). . . . . . . . . . . . . . . . . . . . . . . . . . 271

Creación de una conexión (junction) nueva para un servidor inicial. . . . . . 272

Adición de un servidor adicional a una conexión (junction) existente. . . . . 276

Apéndice C. Gestión de certificados con iKeyman 279Inicio de la utilidad iKeyman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Apertura de la base de datos de claves predeterminada de WebSEAL. . . . . 282

Creación de una base de datos de claves nueva. . . . . . . . . . . . . . . . . . . . . 284

Creación de un nuevo certificado digital autofirmado. . . . . . . . . . . . . . . . . 287

Adición de un certificado raíz de CA nuevo. . . . . . . . . . . . . . . . . . . . . . . . 290

Supresión de un certificado raíz de CA. . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Copia de certificados entre bases de datos. . . . . . . . . . . . . . . . . . . . . . . . . 291

Extracción de un certificado a un archivo; adición de un certificado aun archivo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

xii Versión 3.8

Importación de un certificado directamente desde una base de datos 293

Exportación de un certificado directamente a una base de datos. . . . . 294

Petición de un certificado de servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

Recepción de un certificado digital. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

Supresión de un certificado digital. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

Asignación de un certificado predeterminado nuevo. . . . . . . . . . . . . . . . . . 299

Cambio de una contraseña de base de datos. . . . . . . . . . . . . . . . . . . . . . . . 300

Índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

xiiiTivoli SecureWay Policy Director WebSEAL Guía de administración

xiv Versión 3.8

Prefacio

Bienvenido aTivoli SecureWay Policy Director WebSEAL Guía deadministración.

Tivoli SecureWay Policy Director WebSEAL es el gestor deseguridad (Security Manager) de recursos de Policy Director para losrecursos basados en la Web. WebSEAL es un servidor Web de altorendimiento y de threads múltiples que aplica una política deseguridad detallada al espacio de objetos Web protegidos. WebSEALpuede proporcionar soluciones de inicio de sesión e incorporarrecursos de servidores de aplicaciones Web de fondo en su políticade seguridad.

Esta guía de administración ofrece un conjunto exhaustivo deprocedimientos e información de referencia para la gestión derecursos de los dominios Web seguros. También incluye informacióngeneral y de conceptos útil para la gran variedad de funciones deWebSEAL.

A quién va destinada esta guíaLos usuarios potenciales de esta guía son:

¶ Administradores de seguridad

¶ Administradores de instalación y despliegue de sistemas

¶ Administradores de sistemas en red

¶ Arquitectos de IT

¶ Desarrolladores de aplicaciones

xvTivoli SecureWay Policy Director WebSEAL Guía de administración

Contenido de esta guía¶ Capítulo 1: Visión general de WebSEAL

Este capítulo le presenta conceptos y funciones importantes deWebSEAL, como por ejemplo: organización y protección delespacio de objetos, autenticación, adquisición de credenciales yconexiones (junctions) WebSEAL.

¶ Capítulo 2: Configuración del servidor WebSEAL

Este capítulo es una referencia técnica para las tareas deconfiguración de WebSEAL, que incluyen: gestión del espacioWeb, parámetros de tiempo de espera, gestión de certificados,gestión de usuarios no autenticados y políticas de ACL y POPespecíficas de WebSEAL.

¶ Capítulo 3: Política de seguridad de WebSEAL

Este capítulo describe procedimientos técnicos detallados parapersonalizar la política de seguridad de WebSEAL, que incluyen:políticas de ACL y POP, calidad de protección, política deautenticación incremental, política de autenticación basada en lared, política de inicio de sesión de tres intentos y política deintensidad de contraseña.

¶ Capítulo 4: Autenticación de WebSEAL

Este capítulo describe procedimientos técnicos detallados paraconfigurar WebSEAL para que gestione varios métodos deautenticación, que incluyen: nombre de usuario y contraseña,certificados de cliente, código de paso de señal de SecurID ydatos de cabecera HTTP especiales.

¶ Capítulo 5: Soluciones de inicio de sesión en dominioscruzados

En este capítulo se describen soluciones de inicio de sesión endominios cruzados para el componente externo de laconfiguración proxy de WebSEAL—entre el cliente y el servidorWebSEAL.

¶ Capítulo 6: Conexiones (junctions) WebSEAL

Este capítulo es una referencia técnica completa para configurary utilizar las conexiones (junctions) WebSEAL.

xvi Versión 3.8

¶ Capítulo 7: Soluciones de inicio de sesión único en la Web

En este capítulo se describen soluciones de inicio de sesiónúnico para el componente interno de la configuración proxy deWebSEAL—entre el servidor WebSEAL y el servidor de fondode aplicaciones con conexión (junction).

¶ Capítulo 8: Integración de aplicaciones

Este capítulo explora diversas posibilidades de WebSEAL paraintegrar la funcionalidad de aplicaciones de terceros.

¶ Apéndice A: Referencia de webseald.conf

¶ Apéndice B: Referencia de las conexiones (junctions)WebSEAL

¶ Apéndice C: Gestión de certificados con iKeyman

Convenios tipográficosEn esta guía se utilizan varios convenios tipográficos para términos yacciones especiales. Su significado es el siguiente:

Negrita Los nombres de comandos y opciones, las palabras clave yotra información que debe utilizarse literalmente aparecenen negrita.

Cursiva Las variables, los argumentos de comandos y los valoresque el usuario debe proporcionar aparecen encursiva. Lostítulos de publicaciones y las palabras o frases especialesque están enfatizadas también aparecen encursiva.

Monoespaciado Los ejemplos de código, las líneas de comandos, la salidaen pantalla, los nombres de archivo y de directorio, y losmensajes del sistema aparecen en una fuentemonoespaciada.

xviiTivoli SecureWay Policy Director WebSEAL Guía de administración

Documentos de Policy Director relacionadosEn la tabla siguiente se resume la documentación disponible dePolicy Director, que se encuentra en el sitio de soporte de TivoliSecureWay Policy Director:

Documentación técnica de Tivoli SecureWay Policy Director

Guías de instalación

Tivoli SecureWay Policy Director Base Guía de instalación

Tivoli SecureWay Policy Director WebSEAL Guía de instalación

Guías de administración

Tivoli SecureWay Policy Director Base Guía de administración

Tivoli SecureWay Policy Director WebSEAL Guía de administración (estedocumento)

Tivoli SecureWay Policy Director Plug-in for Edge Server AdministrationGuide

Tivoli SecureWay Policy Director Web Portal Manager Guía deadministración

Material de referencia para desarrolladores

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

Documentación adicional

Tivoli SecureWay Policy Director Notas del release

Tivoli SecureWay Policy Director Performance Tuning Guide

Tivoli SecureWay Policy Director Capacity Planning Guide

Acceso a la documentación en líneaEl sitio Web de soporte al cliente de Tivoli(http://www.tivoli.com/support/) proporciona vínculos a la siguienteinformación de documentación:

xviii Versión 3.8

¶ Información técnica, incluidas las notas del release, guías deinstalación y configuración, guías de administración y materialde referencia para desarrolladores.

¶ Preguntas frecuentes (FAQ)

¶ Información sobre descarga de software

Puede encontrar la publicación Customer Support Handbook (unaguía de servicios de soporte) en:http://www.tivoli.com/support/getting/.

Puede acceder al índice de publicaciones en línea de Tivoli enhttp://www.tivoli.com/support/documents/. Haga clic enMasterIndex para buscar páginas de soporte para productos específicos.

Puede encontrar la documentación técnica de Policy Director, porversión del producto, en:https://www.tivoli.com/secure/support/Prodman/html/AB.html#Security.

La documentación de algunos productos está disponible en formatoPDF y HTML. También hay documentos traducidos disponibles paraalgunos productos.

Para acceder a la mayor parte de la documentación, necesita un ID yuna contraseña. Para obtener el ID que debe utilizar en el sitio Webde soporte al cliente, diríjase ahttp://www.tivoli.com/support/getting/ .

Los distribuidores deben consultar la direcciónhttp://www.tivoli.com/support/smb/index.html para obtener másinformación sobre cómo obtener asistencia y documentación técnicade Tivoli.

Los Business Partners deben consultar la sección “Solicitud dedocumentación” en la página xx para obtener más información sobrecómo obtener documentación técnica de Tivoli.

xixTivoli SecureWay Policy Director WebSEAL Guía de administración

Solicitud de documentaciónPuede realizar pedidos en línea de documentación de Tivoli enhttp://www.tivoli.com/support/Prodman/html/pub_order.html ollamando a uno de los siguientes números de teléfono:

¶ Clientes de EE.UU.: (800) 879-2755

¶ Clientes de España: 901-100-000

Comentarios sobre la documentación de productosNos interesa conocer sus experiencias con los productos y ladocumentación de Tivoli, y agradeceremos cualquier sugerencia paraaplicar mejoras. Si tiene comentarios o sugerencias sobre nuestrosproductos y la documentación, póngase en contacto con nosotrosutilizando uno de los procedimientos siguientes:

¶ Envíe un mensaje de correo electrónico [email protected].

¶ Rellene la encuesta de opinión del cliente enhttp://www.tivoli.com/support/survey/.

Cómo ponerse en contacto con el servicio desoporte al cliente

La publicaciónTivoli Customer Support Handbook(una guía deservicios de soporte) en:

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

proporciona información acerca de todos los aspectos del servicio desoporte al cliente de Tivoli, entre los que se incluye:

¶ Registro y elegibilidad

¶ Cómo ponerse en contacto con el servicio de soporte, según lagravedad del problema

¶ Números de teléfono y direcciones de correo electrónico, segúnel país donde se encuentre

xx Versión 3.8

¶ Información que debe recopilar antes de ponerse en contacto conel servicio de soporte al cliente

xxiTivoli SecureWay Policy Director WebSEAL Guía de administración

xxii Versión 3.8

Visión general de WebSEAL

Tivoli SecureWay Policy Director WebSEAL es un servidor Web dealto rendimiento y de threads múltiples que aplica una política deseguridad detallada al espacio de objetos Web protegidos. WebSEALpuede proporcionar soluciones de inicio de sesión e incorporarrecursos de servidores de aplicaciones Web de fondo en su políticade seguridad.

Esta visión general le presenta las principales posibilidades delservidor WebSEAL.

Índice de temas:

¶ “Protección del espacio Web con WebSEAL” en la página 1

¶ “Información sobre la autenticación de WebSEAL” en la página6

¶ “Información sobre la adquisición de credenciales” en la página8

¶ “Información sobre las conexiones (junctions) WebSEAL” en lapágina 10

Protección del espacio Web con WebSEALTivoli SecureWay Policy Director WebSEAL es el gestor deseguridad (Security Manager) de recursos de Policy Director para losrecursos basados en la Web.

1

1Tivoli SecureWay Policy Director WebSEAL Guía de administración

1.V

isióngeneralde

WebS

EA

L

WebSEAL es un servidor Web de alto rendimiento y de threadsmúltiples que aplica una política de seguridad detallada al espacio deobjetos Web protegidos. WebSEAL puede proporcionar soluciones deinicio de sesión e incorporar recursos de servidores de aplicacionesWeb de fondo en su política de seguridad.

WebSEAL proporciona las siguientes funciones:

¶ Da soporte a varios métodos de autenticación

Tanto la arquitectura incorporada como la de plug-in permiten laflexibilidad al dar soporte a varios mecanismos de autenticación.

¶ Acepta peticiones HTTP y HTTPS

¶ Integra y protege los recursos de servidor de fondo a través de latecnología de conexiones (junctions) WebSEAL

¶ Gestiona un control de acceso estricto para el espacio Web delservidor local y de fondo

Los recursos soportados incluyen direcciones URL, expresioneshabituales basadas en direcciones URL, programas CGI, archivosHTML, servlets Java y archivos de clase Java.

¶ Funciona como proxy Web inverso

WebSEAL aparece como un servidor Web en los clientes y comoun navegador de Web en los servidores de fondo con conexión(junction) que protege.

¶ Proporciona posibilidades de inicio de sesión único

2 Versión 3.8

Client WebSEAL

� supports multiple authentication methods� integrates Authorization Service� manages fine-grain control of web resources� handles variety of resource types� incorporates and secures back-end server resources� unified protected Web resource space� provides single sign-on solutions

Authentication

WebApplication

Server

/

Secured WebObject Space

WebSEAL junction

Figura 1. Protección del espacio Web con WebSEAL


1.V

isióngeneralde

WebS

EA

L

Identificación de tipos de contenido y niveles deprotección

Como administrador de seguridad del espacio Web, debe identificarcorrectamente los tipos de contenido disponibles para una variedadde tipos de usuario. Se debe proteger en gran manera una parte delcontenido y ponerlo sólo a disposición de usuarios específicos; otraparte del contenido es para el público general. Cada caso deseguridad exige unos requisitos de protección distintos y laconfiguración de WebSEAL asociada.

Es responsabilidad del usuario:

¶ Conocer el contenido Web

¶ Identificar los tipos de usuario que requieren el acceso a esecontenido

¶ Comprender el valor y las debilidades de las opcionesdisponibles de configuración de WebSEAL para proteger estecontenido

La protección del contenido Web se divide en tres ampliascategorías:

1. Contenido público: el acceso no requiere ninguna protección

¶ Acceso de clientes no autenticados a través de HTTP

¶ Credencial no autenticada utilizada para el control de accesoa los recursos

¶ Requisitos de configuración básica de WebSEAL

2. Contenido público: el acceso requiere privacidad (cifrado)

¶ Acceso de clientes no autenticados a través de HTTPS

¶ Cifrado necesario para proteger datos confidencialesrequeridos por el servidor de aplicaciones (como números detarjeta de crédito e información de cuentas de usuario)

¶ Credencial no autenticada utilizada para el control de accesoa los recursos

¶ La configuración de WebSEAL debe estipular la privacidad

4 Versión 3.8

3. Contenido privado: el acceso requiere autenticación

¶ Acceso de clientes autenticados mediante HTTP o HTTPS

¶ El administrador determina la necesidad de cifrado

¶ Credencial autenticada utilizada para el control de acceso alos recursos; los clientes deben tener una cuenta definida enel registro de usuarios

¶ La configuración de WebSEAL es compleja y todas lasopciones se deben considerar con atención para determinar elimpacto de la política de seguridad

Planificación e implementación de la Política deseguridad

Una política de seguridad de empresa identifica:

1. Los recursos Web que requieren protección

2. El nivel de protección

Policy Director utiliza una representación virtual de estos recursosWeb, denominada espacio de objetos protegidos. Este espaciocontiene objetos que representan los recursos físicos reales de la red.

La política de seguridad se implementa al aplicar los mecanismos deseguridad apropiados a los objetos que requieren protección.

Los mecanismos de seguridad son:

¶ Políticas de lista de control de accesos (ACL)

Las políticas de ACL identifican los tipos de usuario que sepueden considerar para el acceso y especifican las operacionespermitidas en el objeto.

¶ Políticas de objetos protegidos (POP)

Una POP especifica las condiciones adicionales que gobiernan elacceso al objeto protegido, como la privacidad, la integridad, laauditoría y el acceso según la hora del día.

¶ Atributos ampliados


1.V

isióngeneralde

WebS

EA

L

Los atributos ampliados son valores adicionales colocados en unobjeto, ACL o POP que otras aplicaciones de terceros puedenleer e interpretar (como un servicio de autorizaciones externo).

El componente esencial de Policy Director es Authorization Service,que permite o deniega el acceso a objetos protegidos (recursos)basado en las credenciales del usuario y los controles de acceso quese encuentran en los objetos.

Para implementar correctamente la política de seguridad, debeorganizar lógicamente los distintos tipos de contenido (tal como sedescribe en el apartado “Planificación e implementación de laPolítica de seguridad” en la página 5) y aplicar las políticas de ACLy POP apropiadas. La gestión del control de acceso puede ser muycompleja y se lleva a cabo mucho más fácilmente mediante lameticulosa categorización de los tipos de contenido.

Información sobre la autenticación de WebSEALLa autenticación es el método para identificar un proceso o entidadindividual que intenta conectarse a un dominio seguro. Cuando tantoel servidor como el cliente requieren la autenticación, el intercambiose denomina autenticación mutua.

WebSEAL puede aplicar un alto grado de seguridad en un dominioseguro al solicitar a cada cliente que proporcione una prueba de suidentidad. Cuando el acceso a cada recurso de un dominio seguro

Client WebSEAL

Who are you?

Who are you?

Figura 2. Autenticación mutua

6 Versión 3.8

está controlado por WebSEAL, las exigencias de WebSEAL para laautenticación y la autorización pueden proporcionar una seguridad dered muy exhaustiva.

En la arquitectura de seguridad, la autenticación es distinta de laautorización. La autorización determina si un usuario autenticadotiene el derecho de efectuar una operación en un recurso específico.La autenticación asegura que el individuo es quien dice ser, pero nodice nada acerca de la posibilidad de llevar a cabo operaciones en unrecurso.

Las siguientes condiciones se aplican a la autenticación deWebSEAL:

¶ WebSEAL da soporte a un conjunto estándar de métodos deautenticación.

Puede personalizar WebSEAL para dar soporte a otros métodosde autenticación.

¶ El proceso de WebSEAL es independiente del método deautenticación.

¶ WebSEAL sólo requiere una identidad de cliente. Desde suidentidad, WebSEAL obtiene una credencial autenticada (o noautenticada) que Authorization Service puede utilizar parapermitir o denegar el acceso a los recursos.

Este enfoque flexible de la autenticación permite que la política deseguridad se base en los requisitos de la empresa y no en latopología física de la red.

Objetivos de la autenticaciónAunque WebSEAL es independiente del proceso de autenticación,WebSEAL requiere el resultado de la autenticación: la identidad delcliente. El proceso de autenticación deriva en las siguientes acciones:

1. El método de autenticación da como resultado una identidad decliente.

La autenticación de cliente sólo es correcta si el usuario tieneuna cuenta definida en el registro de usuarios de Policy Director.Si no, el usuario se designa como no autenticado.


1.V

isióngeneralde

WebS

EA

L

2. WebSEAL utiliza la identidad para adquirir credenciales para esecliente.

WebSEAL compara la identidad de cliente autenticado con unusuario registrado de Policy Director. WebSEAL obtiene entonceslas credenciales apropiadas para ese usuario. Esto se conocecomo adquisición de credenciales.

Las credenciales incluyen el nombre de usuario y cualquier grupodel cual sea miembro el usuario.

Si un usuario es anónimo, WebSEAL crea una credencial noautenticada.

Estas credenciales están disponibles para Authorization Serviceque permite o deniega el acceso a los objetos solicitados en elespacio de objetos protegidos de WebSEAL.

Cualquier servicio de Policy Director que requiera la informaciónacerca de un cliente puede utilizar las credenciales. Las credencialespermiten que Policy Director lleve a cabo de forma segura unamultitud de servicios como, por ejemplo, la autorización, auditoría ydelegación.

Consulte el apartado “Autenticación de WebSEAL” en la página 87para obtener más información acerca del soporte para métodos deautenticación específicos.

Información sobre la adquisición de credencialesUno de los objetivos principales del proceso de autenticación esadquirir la información de credencial que describe el usuario cliente.La credencial de usuario es uno de los requisitos clave paraparticipar en el dominio seguro.

Policy Director distingue la autenticación del usuario de laadquisición de credenciales. La identidad del usuario es siempreconstante. Sin embargo, las credenciales, que definen los grupos oroles en los que participa un usuario, son variables. Las credencialesespecíficas del contexto pueden cambiar con el tiempo. Por ejemplo,cuando se promueve a una persona, las credenciales deben reflejar elnuevo nivel de responsabilidad.

8 Versión 3.8

El proceso de autenticación da como resultado la información deidentidad de usuario específico del método. Esta información secomprueba con la información de cuenta de usuario que reside en elregistro de usuarios de Policy Director (el valor predeterminado esLDAP). WebSEAL correlaciona el nombre de usuario y lainformación de grupo con una representación y formato de todo eldominio común conocido como el certificado EPAC (Certificado deatributos de privilegios ampliados).

La información de identidad específica de un método como, porejemplo, contraseñas, señales y certificados representa laspropiedades de identidad física del usuario. Esta información sepuede utilizar para establecer una sesión segura con el servidor.

La credencial resultante, que representa los privilegios de un usuarioen el dominio seguro, describe el usuario en un contexto específico ysólo es válido para la duración de esa sesión.

Las credenciales de Policy Director contienen la identidad delusuario y los grupos de los cuales es miembro este usuario.

Certificado de atributos de privilegios ampliados(EPAC)

Cualquier servicio de Policy Director que requiera la informaciónacerca de un cliente utiliza las credenciales.

Method-SpecificIdentity Information

EPACUsername/password

Token passcodeCustom HTTP header

X.509 certificate

Policy DirectorCredentials

Figura 3. Correlación de la información de identidad con las credenciales


1.V

isióngeneralde

WebS

EA

L

Por ejemplo, Authorization Service utiliza credenciales paradeterminar si un usuario está autorizado para llevar a cabo lasoperaciones en un recurso protegido del dominio seguro.

Los EPAC contienen los Identificadores universales únicos (UUID)que Policy Director debe utilizar con las listas de control de accesos(ACL).

Policy Director utiliza credenciales para otros servicios como:

¶ Servicio de auditoría

¶ Posibilidades de delegación en conexiones (junctions) WebSEAL

Los siguientes campos de EPAC son apropiados para PolicyDirector:

Atributo Descripción

ID de dominio seguro Identificador de dominio seguro inicial delprincipal

UUID del principal UUID del principal

UUID de grupos Los UUID de los grupos a los que pertenece elprincipal

Información sobre las conexiones (junctions)WebSEAL

Policy Director proporciona autenticación, autorización y serviciosde gestión para una red. En una red basada en la Web, es mejor queestos servicios los suministren uno o más servidores WebSEALfrontales que integren y protejan los recursos y aplicaciones Webubicadas en servidores Web de fondo.

La conexión entre un servidor WebSEAL y un servidor deaplicaciones Web de fondo se conoce como conexión (junction)WebSEAL o conexión (junction). Una conexión (junction) WebSEALes una conexión TCP/IP entre un servidor WebSEAL frontal y unservidor de fondo.

10 Versión 3.8

El servidor de fondo puede ser otro servidor WebSEAL o, lo que esmás habitual, un servidor de aplicaciones Web de terceros. Elespacio Web del servidor de fondo está “conectado” con el servidorWebSEAL en un punto (de montaje) de conexión (junction)especialmente designado en el espacio de nombres de WebSEAL.

Una conexión (junction) permite a WebSEAL proporcionar serviciosde protección en nombre del servidor de fondo. WebSEAL puederealizar comprobaciones de autenticación y autorización en todas laspeticiones antes de pasar esas peticiones al servidor de fondo. Si elservidor de fondo requiere un control de acceso estricto sobre susobjetos, puede seguir pasos de configuración adicionales paradescribir el espacio Web de terceros para el servicio de seguridad dePolicy Director (consulte el apartado “Utilización de query_contentscon servidores de terceros” en la página 200).

Las conexiones (junctions) proporcionan un entorno seguro escalableque permite el equilibrio de la carga, una alta disponibilidad y laposibilidad de gestión del estado, todo ello realizado de una formatransparente para los clientes. Como administrador, puedebeneficiarse de esta gestión centralizada del espacio de nombres.

Las conexiones (junctions) WebSEAL proporcionan el valor añadidode combinar de una forma lógica el espacio Web de un servidor de

ClientWeb

ApplicationServer

Junction

TCP or SSL

WebSEAL/

/mnt

Secure Domain

Figura 4. Las conexiones (junctions) conectan WebSEAL con servidores de fondo


1.V

isióngeneralde

WebS

EA

L

fondo con el espacio Web del servidor WebSEAL. Las conexiones(junctions) entre servidores que cooperan dan como resultado un soloespacio Web distribuido y unificado que es transparente y directopara los usuarios.

El cliente no necesita conocer la ubicación física de un recurso Web.WebSEAL convierte las direcciones URL lógicas en las direccionesfísicas que espera un servidor de fondo. Los objetos Web se puedenmover de servidor a servidor sin que afecte a la forma como elcliente accede a esos objetos.

Un espacio Web simplifica la gestión de todos los recursos para eladministrador del sistema. Las ventajas administrativas adicionalesincluyen la escalabilidad, el equilibrio de la carga y una altadisponibilidad.

12 Versión 3.8

La mayoría de servidores Web comerciales no disponen de laposibilidad de definir un espacio de objetos Web lógico, sino que elcontrol de acceso se conecta al archivo físico y la estructura deldirectorio. Las conexiones (junctions) WebSEAL pueden definir deforma transparente un espacio de objetos que refleje la estructuraorganizativa en vez de la máquina física y la estructura del directorioque se encuentra habitualmente en servidores Web estándar.

Las conexiones (junctions) WebSEAL también permiten crearsoluciones de inicio de sesión único. Una configuración de inicio desesión único permite al usuario acceder a un recurso, con

/

WebSEAL Web space

Combined Web space:WebSEAL plus junctioned server

/junction-point

Figura 5. La conexión (junction) WebSEAL da como resultado un espacio Webunificado


1.V

isióngeneralde

WebS

EA

L

independencia de la ubicación del recurso, utilizando sólo un iniciode sesión inicial. Los requisitos de inicio de sesión posteriores de losservidores de fondo se gestionan de una forma transparente para elusuario.

Las conexiones (junctions) WebSEAL son una herramientaimportante para que el sitio Web sea escalable. Las conexiones(junctions) le permiten responder a las crecientes demandas de unsitio Web al adjuntar servidores adicionales.

Conexiones (junctions) WebSEAL y escalabilidad delsitio Web

Las conexiones (junctions) WebSEAL se utilizan para crear un sitioWeb escalable. Al crecer las demandas del sitio, se pueden agregarfácilmente más servidores para ampliar las posibilidades del sitio.

Se pueden agregar servidores adicionales por los siguientes motivos:

¶ Para ampliar el sitio con contenido adicional

¶ Para duplicar el contenido existente para el equilibrio de lacarga, la posibilidad de recuperación tras error y aumentar ladisponibilidad

Servidores WebSEAL frontales replicadosEl soporte para conexiones (junctions) para los servidores de fondoempieza con, al menos, un servidor WebSEAL frontal. Losservidores WebSEAL frontales replicados proporcionan al sitio unequilibrio de carga durante los períodos de gran demanda. Elmecanismo de equilibrio de carga lo gestiona un mecanismo como,por ejemplo, IBM Network Dispatcher o Cisco Local Director.

La réplica frontal también proporciona al sitio la posibilidad derecuperación tras error: si por algún motivo falla un servidor, losservidores replicados restantes continuarán ofreciendo acceso al sitio.El equilibrio de carga correcto y la posibilidad de recuperación traserror da como resultado una alta disponibilidad para los usuarios delsitio.

14 Versión 3.8

Al replicar servidores WebSEAL frontales, cada servidor debecontener una copia exacta del espacio Web y la base de datos deconexiones (junctions).

La información de cuenta para la réplica reside en un registro deusuarios que es independiente de los servidores frontales.

Soporte para los servidores de fondoEl propio servidor WebSEAL, los servidores de fondo o unacombinación de ambos pueden servir el contenido del sitio Web. Elsoporte para conexiones (junctions) WebSEAL para servidores defondo le permite escalar el sitio Web mediante contenido y recursosadicionales.

Cada servidor de fondo exclusivo debe estar conectado con un punto(de montaje) de conexión (junction) separado. Al crecer la demandade contenido adicional, se pueden agregar más servidores mediante

SSL Client SSL Client

WebSEAL ServerPrimary

Internet

WebSEAL ServerReplica

Load-Balancingmechanism

Figura 6. Servidores WebSEAL frontales replicados


1.V

isióngeneralde

WebS

EA

L

conexiones (junctions). Este ejemplo proporciona una solución pararedes que tengan una gran inversión en servidores Web de terceros.

El diagrama siguiente muestra cómo las conexiones (junctions)proporcionan un espacio de objetos lógico unificado. Este espacioWeb es transparente para el usuario y permite una gestióncentralizada.

SSL Client


Internet


Third-Party Server/engineering

SSL Client

Third-Party Server/sales


Figura 7. Servidores de fondo con conexión (junction)

16 Versión 3.8

Los servidores de fondo replicados están conectados al mismo puntode conexión (junction), tal como se muestra en el siguiente apartado.

Servidores de fondo replicadosPara ampliar las funciones de escalabilidad para una configuraciónde servidor de fondo, puede replicar los servidores de fondo. Comoen el caso de los servidores frontales replicados, los servidores defondo replicados deben contener espacio Web que sean imágenesreflejadas mutuas.

WebSEAL equilibra la carga de los servidores replicados medianteun algoritmo de planificación “menos ocupado”. Este algoritmodirige todas las nuevas peticiones al servidor que tenga el menornúmero de conexiones (junctions) en progreso.

WebSEAL también utilizará la característica de recuperación traserror cuando un servidor no esté activo y volverá a utilizarlo denuevo cuando se haya reiniciado.

Web Object Space

/Engineering Junction Sales Junction

Figura 8. Espacio Web unificado


1.V

isióngeneralde

WebS

EA

L

Si la aplicación de fondo requiere el mantenimiento del estado devarias páginas, se pueden utilizar las conexiones (junctions) deestado que devuelve cada sesión al mismo servidor de fondo.

SSL Client


Internet


SSL Client

ReplicatedEngineering Servers

ReplicatedSales Servers

ReplicatedFront-EndServers


Figura 9. Servidores de fondo replicados

18 Versión 3.8

Configuración del servidorWebSEAL

Este capítulo contiene información que describe las tareas deconfiguración y administración general que se pueden llevar a cabopara personalizar el servidor WebSEAL para la red.

Índice de temas:

¶ “Información general sobre el servidor” en la página 20

¶ “Configuración de los parámetros de comunicación” en la página23

¶ “Gestión del espacio Web” en la página 28

¶ “Configuración de mensajes de error de HTTP” en la página 36

¶ “Gestión de páginas HTML personalizadas” en la página 40

¶ “Gestión de certificados de cliente y servidor” en la página 42

¶ “Configuración de la calidad predeterminada del nivel deprotección” en la página 50

¶ “Configuración de actualizaciones y sondeos de la base de datosde autorizaciones” en la página 52

¶ “Replicación de servidores WebSEAL frontales” en la página 54

¶ “Configuración del registro de HTTP estándar” en la página 55

2


2.C

onfiguracióndel

servidorW

ebSE

AL

Información general sobre el servidorEn los siguientes apartados se describe la información general sobreel servidor WebSEAL:

¶ “Introducción al archivo de configuración webseald.conf” en lapágina 20

¶ “Directorio raíz de la instalación de WebSEAL” en la página 21

¶ “Directorio raíz del servidor WebSEAL” en la página 22

¶ “Cómo iniciar y detener WebSEAL” en la página 22

Introducción al archivo de configuraciónwebseald.conf

Puede personalizar el funcionamiento de WebSEAL configurando losparámetros que se encuentran en el archivo de configuraciónwebseald.conf. Este archivo se encuentra en el siguiente directorio:

UNIX:/opt/pdweb/etc/

Windows:C:\Archivos de programa\Tivoli\PDWeb\etc\

La tabla siguiente resume las secciones y las stanzas:

Secciones Stanzas

GENERAL DE WEBSEAL [server]

LDAP [ldap]

SSL [ssl]

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

20 Versión 3.8

Secciones Stanzas

AUTENTICACIÓN [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]

SESIÓN [session]

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

INICIO DE SESIÓN [logging]

API DE AUTORIZACIÓN [aznapi-configuration][aznapi-entitlement-services]

POLICY DIRECTOR [policy-director]

Consulte el apartado “Referencia de webseald.conf” en la página 251.

Nota: siempre que se efectúe un cambio en el archivowebseald.conf, deberá reiniciar manualmente WebSEALpara que se reconozcan los nuevos cambios. Consulte elapartado “Cómo iniciar y detener WebSEAL” en la página 22.

Directorio raíz de la instalación de WebSEALLos archivos de programa de WebSEAL se instalan en el siguientedirectorio raíz:

UNIX:/opt/pdweb/

Windows:C:\Archivos de programa\Tivoli\PDWeb\


2.C

onfiguracióndel

servidorW

ebSE

AL

Puede configurar esta ruta de acceso en una instalación de PolicyDirector para Windows. No puede configurar esta ruta de acceso eninstalaciones UNIX de Policy Director.

Esta guía utiliza la variable <ruta-instalación> para representar estedirectorio raíz.

En instalaciones UNIX, el siguiente directorio contiene archivosampliables, como, por ejemplo, archivos de auditoría y de registro:/var/pdweb/

Directorio raíz del servidor WebSEALEl parámetroserver-root del archivo de configuraciónwebseald.conf define la ubicación del servidor WebSEAL en elinicio de sesión.[server]server-root = /opt/pdweb/www

Todos los nombres de ruta de acceso relativa expresados en elarchivo de configuraciónwebseald.conf son relativos a estedirectorio raíz.

Nota: en condiciones normales, no se debe cambiar este nombre deruta de acceso.

Cómo iniciar y detener WebSEALEl proceso el servidor WebSEAL se puede iniciar y detenerutilizando el comandopdweb_start en UNIX, o utilizando Serviciosen el Panel de control de Windows.

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

Por ejemplo, para detener el servidor WebSEAL y reiniciarlo acontinuación utilice:# pdweb_start restart

El comandopdweb_start se encuentra en el siguiente directorio:/opt/pdweb/bin/

22 Versión 3.8

Windows:

Identifique el proceso del servidor WebSEAL en Servicios, en elPanel de control, y utilice los botones de control correspondientes.

Configuración de los parámetros de comunicaciónEn los siguientes apartados se describe la información general sobreel servidor WebSEAL:

¶ “Configuración de WebSEAL para peticiones HTTP” en lapágina 23

¶ “Configuración de WebSEAL para peticiones HTTPS” en lapágina 24

¶ “Restricción de conexiones de versiones específicas de SSL” enla página 24

¶ “Configuración de los threads de trabajo HTTP y HTTPS” en lapágina 25

¶ “Parámetros de tiempo de espera para la comunicación deHTTP/HTTPS” en la página 26

¶ “Parámetros adicionales de tiempo de espera del servidorWebSEAL” en la página 27

Configuración de WebSEAL para peticiones HTTPWebSEAL gestiona habitualmente muchas peticiones HTTP deusuarios no autenticados. Por ejemplo, es habitual permitir a losusuarios anónimos el acceso de sólo lectura a los documentosseleccionados de la sección pública del sitio Web.

Los parámetros para gestionar las peticiones HTTP mediante TCP seencuentran en la stanza[server] del archivo de configuraciónwebseald.conf.

Activación/desactivación del acceso HTTPPuede activar o desactivar el acceso HTTP durante la configuraciónde WebSEAL:http = {yes|no}


2.C

onfiguracióndel

servidorW

ebSE

AL

Configuración del valor de puerto de acceso HTTPEl puerto predeterminado para el acceso HTTP es 80:http-port = 80

Para cambiarlo por el puerto 8080, por ejemplo, establezca:http-port = 8080

Configuración de WebSEAL para peticiones HTTPSLos parámetros para gestionar peticiones HTTP mediante SSL(HTTPS) se encuentran en la stanza[server] del archivo deconfiguraciónwebseald.conf.

Activación/desactivación del acceso HTTPSPuede activar o desactivar el acceso HTTPS durante la configuraciónde WebSEAL:https = {yes|no}

Configuración del valor de puerto de acceso HTTPSEl puerto predeterminado para el acceso HTTPS es 443:https-port = 443

Para cambiarlo por el puerto 4343, por ejemplo, establezca:https-port = 4343

Restricción de conexiones de versiones específicasde SSL

Puede activar y desactivar independientemente la conectividad deSSL versión 2, SSL versión 3 y TLS versión 1. Los parámetros quecontrolan las conexiones para las versiones específicas de SSL yTLS se encuentran en la stanza[ssl] del archivo de configuraciónwebseald.conf. De forma predeterminada, están activadas todas lasversiones de SSL y TLS.[ssl]disable-ssl-v2 = nodisable-ssl-v3 = nodisable-tls-v1 = no

24 Versión 3.8

Configuración de los threads de trabajo HTTP yHTTPS

El número de threads de trabajo configurados especifica el númerode peticiones entrantes simultáneas a las que puede dar servicio unservidor. Las conexiones que lleguen cuando todos los threads detrabajo estén ocupados se colocarán en el búfer hasta que haya unthread de trabajo disponible.

Puede establecer el número de threads disponibles para dar servicio alas conexiones de entrada de WebSEAL. La configuración delnúmero de threads de trabajo se debe realizar con cuidado debido aposibles impactos en el rendimiento.

Este parámetro de configuración no impone un límite máximo en elnúmero de conexiones simultáneas. Este parámetro simplementeespecifica el número de threads disponibles para dar servicio a unacola de trabajo potencialmente ilimitada.

La elección del número óptimo de threads de trabajo dependerá de lainformación de la cantidad y el tipo de tráfico de la red.

Al aumentar el número de threads, se suele disminuir el tiempomedio que se tarda en finalizar las peticiones. Sin embargo, elaumento del número de threads tiene un impacto en otros factoresque pueden tener un efecto negativo en el rendimiento del servidor.

WebSEAL mantiene una sola agrupación de threads de trabajo y listade trabajo genérica para gestionar las peticiones de clientes queutilizan el túnel de TCP, SSL o GSSAPI. Este mecanismo mejoradoposibilita el consumo de menos recursos del sistema por parte deWebSEAL, mientras que permite gestionar una cargasignificativamente mayor.

Puede configurar el tamaño de la agrupación de threads de trabajomediante el parámetroworker-threads de la stanza[server] delarchivo de configuraciónwebseald.conf.[server]worker-threads = 50


2.C

onfiguracióndel

servidorW

ebSE

AL

Nota: es muy recomendable que este parámetro sólo se modifiquepara solucionar problemas de rendimiento.

Parámetros de tiempo de espera para lacomunicación de HTTP/HTTPS

WebSEAL utiliza la implementación de SSL de IBM Global SecurityKit (GSKit). Cuando WebSEAL recibe una petición de un clienteHTTPS, GSKit SSL establece el reconocimiento inicial y mantiene elestado de la sesión.

WebSEAL da soporte a los siguientes parámetros de tiempo deespera para la comunicación de HTTP y HTTPS. Estos parámetrosse encuentran en la stanza[server] del archivo de configuraciónwebseald.conf.

¶ client-connect-timeout

Una vez efectuado el reconocimiento inicial, este parámetro dictael tiempo durante el que WebSEAL mantendrá abierta laconexión para la petición de HTTP o HTTPS inicial. El valorpredeterminado es 120 segundos.[server]client-connect-timeout = 120

¶ persistent-con-timeout

Este parámetro es específico de las conexiones HTTP/1.1 (no deHTTP/1.0). Después de la primera petición y respuesta delservidor HTTP/1.1, este parámetro controla el número máximode segundos durante los que el servidor mantendrá una conexiónpersistente de HTTP/1.1 abierta antes de cerrarla. El valorpredeterminado es 5 segundos.[server]persistent-con-timeout = 5

26 Versión 3.8

Parámetros adicionales de tiempo de espera delservidor WebSEAL

Los siguientes parámetros adicionales de tiempo de espera seestablecen en el archivo de configuraciónwebseald.conf:

Parámetro Descripción Valorpredeterminado

(segundos)

[junction]http-timeout

Valor de tiempo de esperapara el envío a un servidor defondo y para la lectura desdeese servidor a través de unaconexión (junction) TCP.

120

[junction]https-timeout

Valor de tiempo de esperapara el envío a un servidor defondo y para la lectura desdeese servidor a través de unaconexión (junction) SSL.

120

Connect

Client WebSEAL

SSL Handshake

HTTP Request

Response

HTTP Request

GSKit controlled

(HTTP/1.1 only)

client-connect-timeout

persistent-con-timeout

Figura 10. Parámetros de tiempo de espera para la comunicación de HTTP y HTTPS


2.C

onfiguracióndel

servidorW

ebSE

AL

Parámetro Descripción Valorpredeterminado

(segundos)

[cgi] cgi-timeout Valor de tiempo de esperapara el envío a un procesoCGI local y para la lecturadesde ese proceso.

120

[junction] ping-time De forma periódica,WebSEAL ejecuta ping ensegundo plano de cadaservidor conectado paradeterminar si funciona.WebSEAL no lo intentará conuna frecuencia superior a 300segundos (o el valorestablecido).

300

Gestión del espacio WebLas siguientes secciones describen las tareas necesarias paragestionar el espacio Web:

¶ “Directorio raíz del árbol de documentos Web” en la página 28

¶ “Configuración del índice de directorios” en la página 30

¶ “Windows: convenios de denominación de archivos paraprogramas CGI” en la página 32

¶ “Configuración de la caché de documentos Web” en la página 33

Directorio raíz del árbol de documentos WebLa ubicación del árbol de documentos Web es la ruta de accesocompleta a la raíz del árbol para los documentos disponibles a travésde WebSEAL. Este nombre de ruta de acceso está representado porel parámetrodoc-root de la stanza[content] del archivo deconfiguraciónwebseald.conf. La ubicación predeterminada seestablece inicialmente durante la instalación de WebSEAL:

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

28 Versión 3.8

Windows:doc-root = C:\Archivos de programa\Tivoli\PDWeb\www\docs

Este valor sólo se utiliza una vez: la primera vez que WebSEAL seinicia después de la instalación. El valor se almacena en la base dedatos de conexiones (junctions). La futura modificación de este valoren webseald.conf no tendrá ningún impacto.

Después de la instalación, deberá utilizar la utilidadpdadmin paracambiar el valor de la ubicación del directorio raíz de documentos.Sirva el siguiente ejemplo (el nombre del servidor eswebsealA) parailustrar este procedimiento:

1. Inicie la sesión enpdadmin:# pdadminpdadmin> loginEscriba el ID de usuario: sec_masterEscriba la contraseña:pdadmin>

2. Utilice el comandoserver task list para mostrar todos los puntosde conexión (junction) actuales:pdadmin> server task websealA list/

3. Utilice el comandoserver task showpara mostrar los detalles dela conexión (junction):pdadmin> server task websealA show /Punto de conexión (junction): /Tipo: LocalLímite de hardware de conexión (junction): 0 - se utilizará el

valor globalLímite de software de conexión (junction): 0 - se utilizará el

valor globalThreads de trabajo activos: 0Directorio raíz: /opt/pdweb/www/docs

4. Cree una conexión (junction) local nueva para sustituir el puntode conexión (junction) actual (la opción-f es necesaria para quese fuerce una nueva conexión (junction) que sobrescriba laconexión (junction) existente):pdadmin> server task websealA create -t local -f -d /tmp/docs /Se ha creado una conexión (junction) en /


2.C

onfiguracióndel

servidorW

ebSE

AL

5. Visualice el punto de conexión (junction) nuevo:pdadmin> server task websealA list/

6. Visualice los detalles de esta conexión (junction):pdadmin> server task websealA show /Punto de conexión (junction): /Tipo: LocalLímite de hardware de conexión (junction): 0 - se utilizará el


valor globalThreads de trabajo activos: 0Directorio raíz: /tmp/docs

Configuración del índice de directoriosPuede especificar el nombre del archivo predeterminado que hadevuelto WebSEAL cuando la expresión de dirección URL de unapetición finalice con un nombre de directorio. Si este archivopredeterminado existe, WebSEAL lo devuelve al cliente. Si elarchivo no existe, WebSEAL genera dinámicamente un índice dedirectorios y devuelve la lista al cliente.

El parámetro para configurar el archivo de índice de directorios seencuentra en la stanza[content] del archivo de configuraciónwebseald.conf.

El valor predeterminado para el archivo de índice es:[content]directory-index = index.html

Puede cambiar este nombre de archivo si el sitio utiliza un conveniodistinto. Por ejemplo:[content]directory-index = homepage.html

WebSEAL genera dinámicamente un índice de directorios si eldirectorio de la petición no contiene el archivo de índice definidopor el parámetrodirectory-index. El índice generado contiene unalista con el contenido del directorio, con vínculos a cada una de las

30 Versión 3.8

entradas del directorio. El índice sólo se genera si el cliente quesolicita acceso al directorio tiene el permiso “list” (l) en la ACL deese directorio.

Puede configurar los iconos gráficos que utiliza WebSEAL para cadatipo de archivo que aparece en el índice generado. La stanza[content-index-icons]del archivo de configuraciónwebseald.confcontiene una lista de los tipos MIME de documentos y los archivos.gif asociados que se muestran:[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

Esta lista se puede configurar para que especifique otros iconos paracada tipo MIME. Los iconos también se pueden ubicar de formaremota. Por ejemplo:application/* = http://www.acme.com/icons/binary.gif

También se pueden configurar estos valores de iconos adicionales:

¶ Icono utilizado para representar subdirectorios:[icons]diricon = /icons/folder2.gif

¶ Icono utilizado para representar el directorio principal:[icons]backicon = /icons/back.gif

¶ Icono utilizado para representar los tipos de archivosdesconocidos:[icons]unknownicon = /icons/unknown.gif


2.C

onfiguracióndel

servidorW

ebSE

AL

Windows: convenios de denominación de archivospara programas CGI

Los parámetros contenidos en la stanza[cgi-types] del archivo deconfiguraciónwebseald.conf le permiten especificar los tipos deextensión de archivo de Windows que se reconocen y ejecutan comoprogramas CGI.

El sistema operativo UNIX no tiene requisitos de extensión denombre de archivo. No obstante, los tipos de extensión deben estardefinidos para los sistemas operativos Windows. La stanza[cgi-types] enumera todos los tipos de extensión válidos ycorrelaciona cada extensión (cuando es necesario) con un programaCGI apropiado.[cgi-types]<extensión> = <programa-cgi>

De forma predeterminada, sólo los archivos con extensiones quecoincidan con las listadas en la stanza se ejecutarán como programasCGI. Si un programa CGI tiene una extensión que no está contenidaen esta lista, el programa no se ejecutará.

Los archivos con extensiones.exe se ejecutan como programassegún el valor predeterminado de Windows y no requieren ningunacorrelación.

Nota: cuando quiera instalar un archivo.exe en Windows para sudescarga, deberá cambiar el nombre de la extensión o bieninstalar el archivo como parte de un archivo dealmacenamiento (por ejemplo,.zip).

Debe proporcionar los programas intérpretes apropiados para lasextensiones que representan los archivos script interpretados. Comoejemplos de esos tipos de extensiones cabe citar: scripts de shell(.sh y .ksh), scripts Perl (.pl) y scripts Tcl (.tcl).

El siguiente ejemplo muestra una configuración típica de la stanza[cgi-types]:

32 Versión 3.8

[cgi-types]bat = cmdcmd = cmdpl = perlsh = shtcl = tclsh76

Nota: existen graves problemas de seguridad implicados en el usode los archivos.bat y .cmd. Utilice esos tipos de archivocon precaución.

Configuración de la caché de documentos WebLos clientes pueden experimentar a menudo un largo tiempo deacceso a la red y de descarga de archivos debido a un pobrerendimiento en la recuperación de documentos Web. Se puedeproducir un bajo rendimiento si el servidor WebSEAL esperadocumentos recuperados de servidores de fondo con conexión(junction) o de un almacenamiento local lento.

La función de almacenamiento en la caché de documentos Webpermite almacenar los tipos de documentos Web a los que se accedehabitualmente en la memoria del servidor WebSEAL. Los clientesexperimentarán una respuesta mucho más rápida a las peticionesreiteradas de documentos que se han almacenado en la caché delservidor WebSEAL.

Los documentos en la caché pueden incluir documentos de textoestáticos e imágenes gráficas. Los documentos generados de formadinámica, como los resultados de consultas de bases de datos, no sepueden almacenar en la caché.

El almacenamiento en la caché de documentos Web ofrece laflexibilidad de servir documentos de forma local desde WebSEAL envez de hacerlo desde un servidor de fondo a través de una conexión(junction).

El almacenamiento en la caché se realiza en base al tipo MIME. Alconfigurar WebSEAL para el almacenamiento en la caché dedocumentos Web, se identifican los tres parámetros siguientes:

¶ Tipo MIME del documento


2.C

onfiguracióndel

servidorW

ebSE

AL

¶ Tipo de medio de almacenamiento

¶ Tamaño del medio de almacenamiento

El almacenamiento en la caché de documentos Web se define en lastanza[content-cache]del archivo de configuraciónwebseald.conf.Se aplica la siguiente sintaxis:<tipo-mime> = <tipo-caché>:<tamaño-caché>

Parámetro Descripción

tipo-mime Representa cualquier tipo MIME transmitido en unacabecera de respuesta “Content-Type:”. Este valor puedecontener un carácter comodín ( * ). Un valor de */*representa una caché de objeto predeterminada queretendrá cualquier objeto que no corresponda a unacaché configurada de forma explícita.

tipo-caché Especifica el tipo de medio de almacenamiento que seutilizará para la caché. Este release de Policy Director dasoporte sólo a cachés de tipo “memory” (memoria).

tamaño-caché Especifica el tamaño máximo (en kilobytes) que puedealcanzar una caché determinada antes de que se eliminenlos objetos según el algoritmo “Usados menosrecientemente”.

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

El almacenamiento en la caché de documentos Web observa estascondiciones:

¶ El almacenamiento en la caché sólo se produce cuando hay unacaché definida.

¶ No se define ninguna caché durante la instalación.

¶ Si no se especifica una caché predeterminada, los documentosque no coinciden con ninguna caché explícita no se almacenanen la caché.

34 Versión 3.8

¶ La autorización se sigue realizando en todas las peticiones parala información en la caché.

Vaciado de todas las cachésPuede utilizar la utilidadpdadmin para vaciar todas las cachésconfiguradas. La utilidad no permite vaciar cachés individuales.

Debe iniciar la sesión en un dominio seguro como administrador dePolicy Directorsec_masterantes de utilizarpdadmin.

Para vaciar todas las cachés de documentos Web, especifique elsiguiente comando:

UNIX:# pdadmin server task <nombre-servidor> cache flush all

Windows:MSDOS> pdadmin server task <nombre-servidor> cache flush all

Estadísticas de la cachéPuede utilizar la utilidadpdadmin para proporcionar estadísticasbásicas sobre el uso actual de la caché. La información deestadísticas indica el número de elementos retenidos en la caché y lacantidad de peticiones que se han realizado para cada elemento.

Debe iniciar la sesión en un dominio seguro como administrador dePolicy Directorsec_masterantes de utilizarpdadmin.

Para obtener información de estadísticas sobre el uso actual de lacaché, especifique el siguiente comando:

UNIX:# pdadmin server task <nombre-servidor> cache stat

Windows:MSDOS> pdadmin server task <nombre-servidor> cache stat


2.C

onfiguracióndel

servidorW

ebSE

AL

Configuración de mensajes de error de HTTPAlgunas veces, el servidor WebSEAL intenta dar servicio a unapetición y se produce un error. Éste puede deberse a muchas causas.Por ejemplo:

¶ No existe un archivo

¶ La configuración de los permisos prohíbe el acceso

¶ No se pueden ejecutar los programas CGI debido a permisos dearchivos UNIX incorrectos u otro motivo similar

Cuando se produce un error al dar servicio a una petición, elservidor devuelve un mensaje de error al navegador, como porejemplo, “403 No autorizado”, en una página de error de HTML.Hay varios mensajes de error disponibles; cada mensaje se almacenaen un archivo HTML separado.

Estos archivos se almacenan en el siguiente directorio:

UNIX: <ruta-instalación>/www/lib/errors/<dir-idioma>

Windows: <ruta-instalación>\www\lib\errors/<dir-idioma>

El directorioerrors contiene varios subdirectorios locales quecontienen versiones traducidas de los archivos de mensajes de error.

Por ejemplo, la ruta de acceso del directorio para mensajes en inglésde EE.UU. es:

UNIX: <ruta-instalación>/www/lib/errors/en_US

Windows: <ruta-instalación>\www\lib\errors/en_US

Los mensajes de este directorio están en formato HTML, por lo quese ven correctamente en un navegador. Puede editar estas páginasHTML para personalizar su contenido. Los nombres de archivo sonlos valores hexadecimales de los códigos de error internos que sedevuelven cuando fallan las operaciones. Estos nombres no se debenmodificar.

36 Versión 3.8

La tabla siguiente contiene una lista con los nombres de archivo y sucontenido de algunos de los mensajes de error más habituales:

Nombre dearchivo

Título Descripción Códigode errorHTTP

132120c8.html La autenticación nose ha ejecutadocorrectamente

No se han podido recuperar lascredenciales para el certificado decliente utilizado. Los motivosposibles son:

¶ El usuario ha proporcionado uncertificado incorrecto

¶ Se ha rechazado el certificado

¶ Faltan las credenciales delusuario en la base de datos deautenticación

1354a2fa.html El directorio no estávacío

La operación indicada solicita laeliminación de un directorio que noestá vacío. Esta operación no estápermitida.

1898d259.html No se ha podidoiniciar la sesión delusuario

El recurso que ha solicitado requiereque el servidor WebSEAL inicie lasesión en otro servidor Web. Sinembargo, ha ocurrido un problemacuando WebSEAL intentaba obtenerla información.

1898d25a.html El usuario no tieneinformación deinicio de sesiónúnico

WebSEAL no ha podido localizar elusuario GSO para el recursosolicitado.

1898d25b.html No hay ningúndestino de inicio desesión único delusuario

WebSEAL no ha podido localizar eldestino GSO para el recursosolicitado.

1898d25c.html El usuario tienevarios destinos deinicio de sesión

Hay varios destinos GSO definidospara el recurso solicitado. Se tratade un error de configuración.


2.C

onfiguracióndel

servidorW

ebSE

AL

Nombre dearchivo


1898d25d.html Se necesita iniciar lasesión

Un servidor Web de fondoconectado protege el recursosolicitado, por lo que WebSEALdebe iniciar la sesión del usuario enese servidor Web. Para ello, elusuario debe iniciar la sesiónprimero en WebSEAL.

1898d25e.html No se ha podidoiniciar la sesión delusuario

El recurso que ha solicitado requiereque WebSEAL inicie la sesión enotro servidor Web. Sin embargo, lainformación de inicio de sesión parala cuenta de usuario es incorrecta.

1898d25f.html Tentativa deautenticacióninesperada

WebSEAL ha recibido una tentativade autenticación inesperada de unservidor Web con conexión(junction).

1898d421.html Trasladadotemporalmente

El recurso que ha solicitado ha sidotrasladado temporalmente. Estosucede a menudo si hay algunaredirección mal gestionada.

302

1898d424.html Petición incorrecta WebSEAL ha recibido una peticiónHTTP incorrecta.

400

1898d425.html Se necesita iniciar lasesión

El recurso que ha solicitado estáprotegido por WebSEAL y, parapoder acceder al mismo, primerodebe iniciar la sesión.

1898d427.html No autorizado El usuario no tiene permisos paraacceder al recurso solicitado.

403

1898d428.html No encontrado No se puede localizar el recursosolicitado.

404

1898d432.html Servicio nodisponible

En este momento, no está disponibleun servicio que WebSEAL necesitapara completar la petición.

503

38 Versión 3.8

Nombre dearchivo


1898d437.html Servidor suspendido El administrador del sistema hainhabilitado temporalmente elservidor WebSEAL. No se atenderáninguna petición hasta que eladministrador vuelva a habilitar elservidor.

1898d439.html Se ha perdido lainformación de lasesión

La interacción entrenavegador/servidor ha sido unasesión con información de estadocon un servidor de fondo conconexión (junction) que ha dejadode responder. WebSEAL requiere unservicio que se encuentra en dichoservidor para ejecutar la petición.

1898d442.html Servicio nodisponible

El servicio que necesita WebSEALse encuentra en un servidor defondo con conexión (junction)donde ha fallado la autenticaciónmutua SSL.

1898d7aa.html Ejecución incorrectadel programa CGI

No se ha ejecutado correctamenteun programa CGI.

default.html Error del servidor WebSEAL no ha podido ejecutar lapetición debido a un errorinesperado.

500

deletesuccess.html Operación ejecutada La operación de supresión(DELETE) iniciada por el cliente seha ejecutado correctamente.

200

putsuccess.html Operación ejecutada La operación de transferencia (PUT)iniciada por el cliente se haejecutado correctamente.

200

relocated.html Trasladadotemporalmente

El recurso que ha solicitado se hatrasladado temporalmente.

302

websealerror.html 400 Error delservidor WebSEAL

Error interno del servidorWebSEAL.

400


2.C

onfiguracióndel

servidorW

ebSE

AL

Soporte para macrosLas siguientes macros están disponibles para personalizar las páginasHTML de error descritas en el apartado anterior. Las macrossustituyen de forma dinámica la información apropiada disponible.

Macro Descripción

%ERROR_CODE% Valor numérico del código de error.

%ERROR_TEXT% Texto asociado con un código de error en el catálogo demensajes.

%METHOD% Método HTTP solicitado por el cliente.

%URL% Dirección URL solicitada por el cliente.

%HOSTNAME% Nombre de host completo.

%HTTP_BASE% Dirección URL de HTTP base del servidor“http://<host>:<puerto-tcp>/”.

%HTTPS_BASE% Dirección URL de HTTPS base del servidor“https://<host>:<puerto-ssl>/”.

%REFERER% Valor de la cabecera de referente procedente de la petición o bien“Desconocida”, si no hay ninguna.

%BACK_URL% Valor de la cabecera de referente procedente de la petición o bien“/”, si no hay ninguna.

%BACK_NAME% Valor “ATRÁS” si hay una cabecera de referente en la petición obien “INICIO”, si no hay ninguna.

Gestión de páginas HTML personalizadasPolicy Director incluye ejemplos de formularios HTML que sepueden personalizar de forma que contengan mensajes específicospara el sitio o lleven a cabo acciones específicas para éste. Lamayoría de formularios son adecuados para la autenticación deformularios, señales y de BA a través de HTTP o HTTPS.

Las ubicaciones de estos formularios se definen mediante elparámetromgt-pages-rootde la stanza[acnt-mgt] del archivo deconfiguraciónwebseald.conf.mgt-pages-root = lib/html/<dir-idioma>

40 Versión 3.8

El directorio real utilizado se basa en el idioma. El directoriopredeterminado para inglés de EE.UU. es:lib/html/C

La configuración regional japonesa ubica los archivos en:lib/html/JP

Parámetros y valores de página personalizadosLos siguientes parámetros y valores especiales de páginas HTML seencuentran en la stanza[acnt-mgt] del archivo de configuraciónwebseald.conf. Algunas páginas sólo las utiliza el método de iniciode sesión de formularios que proporciona la información deidentidad.

Parámetro Página Utilización

login = login.html Inicio de sesión deformularios

logout = logout.html Inicio de sesión deformularios

account-locked = acct_locked.html Cualquier método

passwd-expired = passwd_exp.html Cualquier método

passwd-change = passwd.html Cualquier método

passwd-change-success = passwd_rep.html Cualquier método

passwd-change-failure = passwd.html Cualquier método

help = help.html Cualquier método

token-login = tokenlogin.html Inicio de sesión deseñales

next-token = nexttoken.html Inicio de sesión deseñales

stepup-login = stepuplogin.html Autenticaciónincremental


2.C

onfiguracióndel

servidorW

ebSE

AL

Descripciones de páginas HTML personalizadas

Formulario Descripción

login.html Petición estándar de nombre de usuario y contraseña

logout.html Página que aparece después de finalizar la sesióncorrectamente.

acct_locked.html Página que aparece si falla la autenticación del usuario debidoa una cuenta bloqueada.

passwd_exp.html Página que aparece si falla la autenticación del usuario debidoque ha caducado la contraseña.

passwd.html Formulario de cambio de contraseña. Aparece también si fallala petición de cambio de contraseña.

passwd_rep.html Página que aparece si la petición de cambio de contraseña hasido correcta.

help.html Página que contiene vínculos a páginas de administraciónválidas.

tokenlogin.html Formulario de inicio de sesión de señales.

nexttoken.html Siguiente formulario de señales.

stepuplogin.html Formulario de inicio de sesión de autenticación incremental.

También hay dos macros disponibles para utilizar en estas páginas.Estas cadenas de macros se pueden colocar en los archivos deplantilla. La macro sustituye de forma dinámica los valoresapropiados.

Macro Descripción

%USERNAME% Nombre del usuario conectado

%ERROR% Mensaje de error no modificable devuelto porPolicy Director

Gestión de certificados de cliente y servidorEste apartado describe las tareas de administración y configuraciónnecesarias para configurar WebSEAL de forma que gestionecertificados de cliente y servidor utilizados para la autenticación através de SSL.

42 Versión 3.8

WebSEAL requiere certificados para las siguientes situaciones:

¶ WebSEAL se identifica ante los clientes SSL con su certificadode servidor

¶ WebSEAL se identifica ante un servidor de fondo con conexión(junction) (configurado para la autenticación mutua) con uncertificado de cliente

¶ WebSEAL consulta su base de datos de certificados raíz de CA(entidad emisora de certificados) para validar los clientes queacceden con los certificados de cliente

¶ WebSEAL consulta su base de datos de certificados raíz de CA(entidad emisora de certificados) para validar los servidores defondo con conexión (junction) configurados para la autenticaciónmutua

WebSEAL utiliza la implementación de SSL de IBM Global SecurityKit (GSKit) para configurar y administrar los certificados digitales.GSKit incluye la utilidadiKeyman para configurar y gestionar labase de datos de claves de certificados que contiene uno o máscertificados de servidor/cliente de WebSEAL y los certificados raízde CA.

WebSEAL incluye los siguientes componentes en la instalación paradar soporte a la autenticación de SSL a través de los certificadosdigitales:

¶ Una base de datos de claves predeterminada (pdsrv.kdb)

¶ Una archivo stash de la base de datos de claves predeterminada(pdsrv.sth) y la contraseña (“pdsrv”)

¶ Varios certificados raíz de CA comunes

¶ Un certificado autofirmado de prueba que WebSEAL puedeutilizar para identificarse en clientes SSL.

Es recomendable que solicite un certificado reconocidohabitualmente de una entidad emisora de certificados conocidapara sustituir este certificado de prueba.


2.C

onfiguracióndel

servidorW

ebSE

AL

La configuración para la gestión de certificados de WebSEALincluye:

¶ “Configuración de los parámetros de la base de datos de clavespara WebSEAL” en la página 46

¶ “Utilización de la utilidad de gestión de certificados iKeyman”en la página 48

¶ “Configuración de la comprobación de CRL” en la página 49

Información sobre los tipos de archivos de base dedatos de claves de GSKit

La herramienta Gestión de claves de IBM (iKeyman) utiliza variostipos de archivos que se resumen en la siguiente tabla.

Una base de datos de claves CMS está formada por un archivo conla extensión .kdb y posiblemente dos o más archivos de otro tipo. Elarchivo.kdb se crea cuando se crea una nueva base de datos declaves. Un registro de clave en un archivo.kdb puede ser uncertificado o un certificado con información de clave privada cifrada.

Los archivos.rdb y .crl se crean cuando se crea una nuevapetición de certificados. El archivo.rdb es necesario durante todo elproceso de la petición de certificado de CA.

Tipo de archivo Descripción

.kdb Archivo de “base de datos de claves”. Almacena certificadospersonales, peticiones de certificados personales y certificados defirmante. Por ejemplo, el archivo de base de datos de clavespredeterminado de WebSEAL es pdsrv.kdb.

.sth Archivo “stash”. Almacena una versión cifrada de la contraseñade la base de datos de claves. El nombre del que se deriva de estearchivo es el mismo que el del archivo .kdb asociado.

44 Versión 3.8


.rdb Archivo de base de datos de “peticiones”. Se creaautomáticamente cuando se crea un archivo de base de datos declaves .kdb. El nombre del que se deriva de este archivo es elmismo que el del archivo .kdb asociado. Este archivo contienepeticiones de certificado que son especiales y no se han recibidotodavía de la CA. Cuando se devuelve un certificado de la CA, sebusca la petición de certificados correspondiente en el archivo.rdb (según la clave pública). Si se encuentra alguna, se recibe elcertificado y la petición de certificado se elimina del archivo .rdb.Si no se encuentra, se rechaza el intento de recibir el certificado.En la petición de certificado se incluyen el nombre común, laorganización, la dirección postal y otra información especificadaen el momento de la petición, así como la clave pública y la claveprivada asociadas con la petición.

.crl Archivo de “lista de revocación de certificados”. Este archivocontiene normalmente la lista de certificados que se han revocadopor alguna razón. No obstante, iKeyman no da soporte a las listasde revocación de certificados, por lo que está vacío.

.arm Archivo binario en código ASCII. Un archivo .arm contiene unarepresentación ASCII codificada en base 64 de un certificado,incluida la clave pública, pero no la privada. Los datos originalesbinarios del certificado se transforman en una representaciónASCII. Cuando un usuario recibe un certificado en un archivo.arm, iKeyman decodifica la representación ASCII y coloca larepresentación binaria en el archivo .kdb correspondiente. De lamisma forma, cuando un usuario extrae un certificado de unarchivo .kdb, iKeyman convierte los datos de binario a ASCII, ylos coloca en un archivo .arm. Los datos ASCII del archivo .armes lo que se envía a la CA durante el proceso de petición decertificados. Nota: se puede utilizar cualquier tipo de archivo(distinto de .arm), siempre que el archivo esté codificado enBase64.

.der Archivo de “reglas de codificación distinguida”. Un archivo .dercontiene una representación binaria de un certificado, incluida laclave pública, pero no la privada. Es muy parecido al archivo.arm, excepto que la representación es binaria, no ASCII.


2.C

onfiguracióndel

servidorW

ebSE

AL


.p12 Archivo “PKCS 12”, donde PKCS hace referencia a los“Estándares criptográficos de clave pública”. Un archivo .p12contiene una representación binaria de un certificado, incluidas laclave pública y la clave privada. Un archivo .p12 también puedeincluir más de un certificado; por ejemplo, un certificado, elcertificado de la CA que emitió el certificado, el emisor delcertificado de la CA, su emisor, etc. Como el archivo .p12contiene una clave privada, su contraseña está protegida.

Configuración de los parámetros de la base de datosde claves para WebSEAL

Archivo de claves de certificados de WebSEAL:

Durante la instalación, WebSEAL proporciona una base de datos declaves de certificados predeterminada. El parámetrowebseal-cert-keyfile, ubicado en la stanza[ssl] del archivo deconfiguraciónwebseald.conf, identifica el nombre y la ubicaciónde este archivo:[ssl]webseal-cert-keyfile = /var/pdweb/www/certs/pdsrv.kdb

Puede usar la utilidadiKeyman para crear una base de datos declaves nueva. Sin embargo, deberá especificar el nombre y laubicación de ese archivo de claves nuevo en el parámetrowebseal-cert-keyfilede manera que WebSEAL pueda encontrar yutilizar los certificados contenidos en esa base de datos.

Contraseña del archivo de claves de certificados:

Durante la instalación, WebSEAL proporciona también un archivostash predeterminado que contiene la contraseña para el archivo declavespdsrv.kdb. El parámetrowebseal-cert-keyfile-stashinformaa WebSEAL de la ubicación del archivo stash:webseal-cert-keyfile-stash = /var/pdweb/www/certs/pdsrv.sth

46 Versión 3.8

La contraseña predeterminada cifrada del archivo stash es “pdsrv”.También puede expresar una contraseña como texto sin formato en elparámetrowebseal-cert-keyfile-pwd. Por ejemplo:webseal-cert-keyfile-pwd = pdsrv

Durante la instalación, WebSEAL utiliza el archivo stash paraobtener la contraseña de archivo de claves. El parámetrowebseal-cert-keyfile-pwdestá comentado. Si utiliza el archivo stash,podrá evitar que la contraseña aparezca como texto en el archivo deconfiguraciónwebseald.conf.

Nota: elimine el comentario del parámetro de contraseña específicoque desee utilizar. Si ha especificado la contraseña y elarchivo stash, se utilizará el valor de la contraseña.

Certificado de prueba de WebSEAL:

Durante la instalación, WebSEAL proporciona un certificadoautofirmado de prueba que no es seguro. El certificado de prueba,que funciona como certificado de servidor, permite a WebSEALidentificarse ante los clientes SSL.

Para controlar mejor la utilización de este certificado de prueba, elcertificado no se instala como certificado predeterminado. En sulugar, el parámetrowebseal-cert-keyfile-labeldesigna al certificadocomo certificado de servidor activo, prevaleciendo sobre cualquierotro certificado designado como “predeterminado” en la base dedatos del archivo de claves.webseal-cert-keyfile-label = WebSEAL

Aunque este certificado de prueba permite a WebSEAL responder auna petición de navegador habilitado para SSL, el navegador (que nocontiene ningún certificado raíz de CA apropiado) no lo puedeverificar. Debido a que la clave privada para este certificadopredeterminado está incluida en cada distribución de WebSEAL, estecertificado no ofrece ninguna comunicación verdaderamente segura.


2.C

onfiguracióndel

servidorW

ebSE

AL

Debe usar la utilidadiKeyman para generar una petición decertificado que se pueda enviar a la CA (entidad emisora decertificados). UtiliceiKeyman para instalar y etiquetar el certificadode servidor devuelto.

Si utiliza certificados diferentes para otras situaciones (por ejemplo,para conexiones (junction)–K), puede utilizar la utilidadiKeymanpara crear, instalar y etiquetar estos certificados. La etiqueta delarchivo de claves no debe contener espacios.

WebSEAL (que se ejecuta de forma predeterminada comouserivmgr ) debe disponer de permiso read (r) en esos archivos de basede datos de claves.

Consulte también el apartado “Gestión de certificados con iKeyman”en la página 279.

Comunicación SSL interna del servidor de Policy Director:

La stanza[ssl] del archivo de configuraciónwebseald.conf contienecuatro parámetros adicionales que se utilizan para configurar elarchivo de claves utilizado por WebSEAL en la comunicación SSLinterna con otros servidores de Policy Director. Sólo debe modificarestos parámetros mediante el script de configuraciónpdconfig.[ssl]ssl-keyfile =ssl-keyfile-pwd =ssl-keyfile-stash =ssl-keyfile-label =

Utilización de la utilidad de gestión de certificadosiKeyman

La utilidad iKeyman es una herramienta incluida con GSKit que sepuede utilizar para gestionar los certificados digitales que utilizaWebSEAL. Utilice iKeyman para:

¶ Crear una o más bases de datos de claves

¶ Cambiar las contraseñas de la base de datos de claves

¶ Crear certificados de WebSEAL nuevos

48 Versión 3.8

¶ Establecer un certificado WebSEAL predeterminado nuevo

¶ Crear un certificado autofirmado para realizar una prueba

¶ Solicitar y recibir certificados raíz de CA

¶ Agregar y eliminar certificados de la base de datos

¶ Copiar certificados de una base de datos a otra

Para obtener instrucciones detalladas sobre el uso deiKeyman pararealizar estas tareas, consulte el apartado “Gestión de certificadoscon iKeyman” en la página 279.

Configuración de la comprobación de CRLLa lista CRL (lista de revocación de certificados) es un método paraevitar la validación de certificados no deseados. CRL contiene laidentidad de certificados que se considera que no son fiables. Laimplementación de SSL de GSKit que utiliza WebSEAL da soporte ala comprobación de CRL. GSKit permite a WebSEAL realizar lacomprobación de CRL en certificados de cliente y certificados deconexiones (junctions) de SSL.

WebSEAL debe conocer la ubicación de esta lista para realizar lacomprobación de CRL. Los parámetros para la ubicación delservidor LDAP a los que se puede hacer referencia durante laautenticación de certificados de la comprobación de CRL seencuentran en la stanza[ssl] del archivo de configuraciónwebseald.conf:[ssl]#ssl-ldap-server = <nombre-servidor>#ssl-ldap-server-port = <id-puerto>#ssl-ldap-user = <nombre-admin-webseal>#ssl-ldap-user-password = <contraseña-admin>

La comprobación de CRL está desactivada de forma predeterminada(los parámetros están comentados). Para activar la comprobación deCRL durante la autenticación de certificados, elimine el comentariode cada uno de los parámetros y especifique los valores apropiados.


2.C

onfiguracióndel

servidorW

ebSE

AL

Un valor vacío parassl-ldap-userindica que el mecanismo deautenticación de SSL debe enlazarse al servidor LDAP como usuarioanónimo.

Configuración de la calidad predeterminada del nivelde protección

Para controlar el nivel predeterminado de cifrado necesario paraacceder a WebSEAL a través de SSL (HTTPS), configure la calidadde protección (QOP). La gestión de calidad de protecciónpredeterminada se controla utilizando los parámetros de la sección“GESTIÓN DE LA CALIDAD DE PROTECCIÓN SSL” del archivode configuraciónwebseald.conf.

¶ Puede activar y desactivar la gestión de QOP con el parámetrossl-qop-mgmt

¶ Puede especificar los niveles de cifrado permitidos en la stanza[ssl-qop-mgmt-default]

1. Active la gestión de la calidad de protección:[ssl-qop]ssl-qop-mgmt = yes

2. Especifique el nivel de cifrado predeterminado para el accesoHTTPS:[ssl-qop-mgmt-default]# default = ALL | NONE | <nivel-cifrado># ALL (activa todo los cifrados)# NONE (desactiva todos los cifrados y utiliza la suma de

comprobación MD5 MAC)# DES-40# DES-56# DES-168# RC2-40# RC2-128# RC4-40# RC4-128default = ALL

Tenga en cuenta que también puede especificar un gruposeleccionado de cifrados:

50 Versión 3.8

[ssl-qop-mgmt-default]default = RC4-128default = RC2-128default = DES-168

Configuración de QOP para redes y hosts individualesEl parámetrossl-qop-mgmt = yestambién activa los valores queaparecen en las stanzas[ssl-qop-mgmt-hosts]y[ssl-qop-mgmt-networks]. Estas stanzas permiten la gestión de lacalidad de protección mediante direcciones IP específicas dehost/red/máscara de red.

La stanza[ssl-qop-mgmt-default] ofrece una lista de los cifradosutilizados para todas las direcciones IP que no encuentrancorrespondencia en las stanzas[ssl-qop-mgmt-hosts]y[ssl-qop-mgmt-networks].

Ejemplo de sintaxis de configuración para los hosts:[ssl-qop-mgmt-hosts]# <ip-host> = ALL | NONE | <nivel-cifrado># ALL (activa todo los cifrados)# NONE (desactiva todos los cifrados y utiliza la suma de

comprobación MD5 MAC)# DES-40# DES-56# DES-168# RC2-40# RC2-128# RC4-40# RC4-128xxx.xxx.xxx.xxx = ALLyyy.yyy.yyy.yyy = RC2-128

Ejemplo de sintaxis de configuración para red/máscara de red:[ssl-qop-mgmt-networks]# <red/máscara_red> = ALL | NONE | <nivel-cifrado># ALL (activa todo los cifrados)# NONE (desactiva todos los cifrados y utiliza la suma de

comprobación MD5 MAC)# DES-40# DES-56# DES-168# RC2-40# RC2-128# RC4-40


2.C

onfiguracióndel

servidorW

ebSE

AL

# RC4-128xxx.xxx.xxx.xxx/255.255.255.0 = RC4-128yyy.yyy.yyy.yyy/255.255.0.0 = DES-56

Las stanzas[ssl-qop-mgmt-hosts]y [ssl-qop-mgmt-networks] seproporcionan sólo a efectos de compatibilidad con versionesanteriores. No se recomienda utilizarlas para la configuración dePolicy Director 3.8.

Configuración de actualizaciones y sondeos de labase de datos de autorizaciones

Management Server gestiona la base de datos maestra de políticas deautorización y mantiene la información de ubicación sobre otrosservidores de Policy Director en el dominio seguro. Unadministrador de Policy Director puede realizar cambios de políticade seguridad en el dominio seguro en cualquier momento.Management Server realiza los ajustes necesarios en la base de datosmaestra de autorizaciones siempre que se implementan cambios en lapolítica de seguridad.

Cuando Management Server realiza un cambio en la base de datosmaestra de autorizaciones, puede enviar una notificación de estecambio a todas las bases de datos replicadas en el dominio seguroque dan soporte a los aplicadores de políticas individuales (porejemplo, WebSEAL). Los aplicadores de políticas deben solicitar acontinuación una actualización de la base de datos desde la base dedatos maestra de autorizaciones.

WebSEAL, como gestor de recursos y aplicador de políticas, tienetres opciones para obtener información acerca de los cambios en labase de datos de autorizaciones:

¶ Escuchar las notificaciones de actualizaciones del ManagementServer (configurable y activado de forma predeterminada).

¶ Comprobar (sondear) la base de datos maestra de autorizacionesa intervalos regulares (configurable y desactivado de formapredeterminada).

¶ Activar la escucha y el sondeo.

52 Versión 3.8

La stanza[aznapi-configuration] del archivo de configuraciónwebseald.conf contiene parámetros para configurar el sondeo de labase de datos y la escucha de notificación de actualizaciones.

La ruta de acceso a la base de datos de políticas de autorizacionesreplicadas locales de WebSEAL está definida por el parámetrodb-file:[aznapi-configuration]db-file = /var/pdweb/db/webseald.db

Configuración de la escucha de notificación deactualizaciones

El parámetrolisten-flags activa y desactiva la escucha denotificación de actualizaciones de WebSEAL. La escucha estáactivada de forma predeterminada. Para desactivar la escucha,escriba “disable”.[aznapi-configuration]listen-flags = enable

El parámetrotcp-port configura el puerto TCP para la escucha:[aznapi-configuration]tcp-port = 12056

El parámetroudp-port configura el puerto TCP para la escucha:[aznapi-configuration]udp-port = 0

Configuración del sondeo de la base de datos deautorizaciones

Puede configurar WebSEAL para que sondee regularmente la base dedatos maestra de autorizaciones para obtener información deactualizaciones. El parámetro cache-refresh-interval se puedeestablecer en “default”, “disable” o un intervalo de tiempo específicoen segundos. El valor “default” es igual a 600 segundos. El sondeoestá desactivado de forma predeterminada.[aznapi-configuration]cache-refresh-interval = disable


2.C

onfiguracióndel

servidorW

ebSE

AL

Replicación de servidores WebSEAL frontales

Nota: la siguiente información sustituye al comandopdadminserver modify baseurl, que se utilizaba en las versionesanteriores de Policy Director.

En un entorno con una gran carga, la replicación de servidoresWebSEAL frontales resulta útil para proporcionar un mejor equilibriode carga y la posibilidad de recuperación tras error. Al replicarservidores WebSEAL frontales, cada servidor debe contener unacopia exacta del espacio Web, la base de datos de conexiones(junctions) y la base de datos dynurl.

Esta versión de Policy Director da soporte a un procedimiento deconfiguración manual para replicar servidores WebSEAL frontales.El comandopdadmin ya no se utiliza para esta tarea.

En el siguiente ejemplo, “WS1” es el nombre de host del servidorWebSEAL principal. “WS2” es el nombre de host del servidorWebSEAL replicado.

1. Instale y configure WebSEAL en los servidores WS1 y WS2.

2. Detenga WebSEAL en WS2.

3. En WS2, cambie el valor del parámetroserver-nameen elarchivo de configuraciónwebseald.conf de “WS2” a “WS1”:[server]server-name = WS1

4. Reinicie WebSEAL en WS2.

El servidor WS2 utiliza ahora el objeto/WebSEAL/WS1 como base enlas evaluaciones de autorizaciones. El servidor WS2 también puederesponder a los comandosobject list y object showpara los objetosque residen en/WebSEAL/WS1.

La utilidad pdadmin continúa mostrando el objeto/WebSEAL/WS2como parte del espacio de objetos. Este objeto ahora no essignificativo y se puede eliminar.pdadmin> object delete /WebSEAL/WS2

54 Versión 3.8

Condiciones:

¶ Gestión del espacio de objetos unificado: Aunque eladministrador puede ver una única jerarquía de objetos, todos losservidores WebSEAL están afectados por los comandos deadministración aplicados a esa jerarquía de objetos, y todos losservidores pueden responder a esos comandos.

¶ Evaluaciones de autorizaciones unificadas: Si el servidor WS2 seconfigura como servidor replicado de WS1, el servidor WS2utiliza /WebSEAL/WS1 como base para las evaluaciones deautorizaciones.

¶ Configuración unificada: Para que la replicación de servidoresWebSEAL frontales funcione correctamente, la configuración delespacio Web, la base de datos de conexiones (junction) y la basede datos dynurl debe ser idéntica en cada servidor.

Configuración del registro de HTTP estándarWebSEAL mantiene tres archivos de registro HTTP convencionalesque registran la actividad en vez de los mensajes:

¶ request.log

¶ agent.log

¶ referer.log

De forma predeterminada, los archivos de registro se mantienen enel siguiente directorio:

UNIX: /var/pdweb/www/log/

Windows: C:\Archivos de programa\Tivoli\PDWeb\www\log\

Los parámetros para configurar el registro de HTTP estándar seencuentran en la stanza[logging] del archivo de configuraciónwebseald.conf.

La tabla siguiente muestra la relación entre los archivos de registrode HTTP y los parámetros del archivo de configuración:


2.C

onfiguracióndel

servidorW

ebSE

AL

Archivos de registro Parámetro deubicación

Activar/desactivarparámetro( = yes o no)

request.log requests-file requests

referer.log referers-file referers

agent.log agents-file agents

Por ejemplo, la entrada de la ubicación predeterminada del archivorequest.log aparece de la siguiente manera:

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

Windows:requests-file = \Archivos de programa\Tivoli\PDWeb\www\log\request.log

Activación y desactivación del registro HTTPTodos los registros de HTTP están activados de formapredeterminada:[logging]requests = yesreferers = yesagents = yes

Se puede activar o desactivar cada registro de forma independiente.Si algún parámetro está establecido en “no”, el registro se desactivapara ese archivo.

Especificación del tipo de indicación de la fecha yhora

Puede elegir la especificación de indicación de la fecha y hora en losregistros en GMT (hora del meridiano de Greenwich) en lugar de lazona horaria local. El valor predeterminado es la utilización de lazona horaria local:[logging]gmt-time = no

Para utilizar las indicaciones de la fecha y hora en GMT, establezca:gmt-time = yes

56 Versión 3.8

Especificación de los umbrales de creación de unnuevo archivo de registro

El parámetromax-sizeespecifica el tamaño máximo que puedealcanzar cada uno de los archivos de registro de HTTP y tiene elsiguiente valor predeterminado (en bytes):[logging]max-size = 2000000

Cuando un archivo de registro alcanza el valor especificado(conocido como umbral de creación), se realiza una copia deseguridad del archivo existente en un archivo con el mismo nombrey con la indicación anexada de fecha y hora. A continuación seinicia un archivo de registro nuevo.

Los distintos valores posiblesmax-sizese interpretan de la siguienteforma:

¶ Si el valormax-sizees menor de cero (< 0), se crea un archivode registro nuevo con cada invocación del proceso de registro ycada 24 horas desde esa instancia.

¶ Si el valor demax-sizees igual a cero (= 0), no se crea unnuevo registro y el archivo de registro crece indefinidamente. Siya existe un archivo de registro, los datos nuevos se agregan enéste.

¶ Si el valor demax-sizees mayor que (> 0), se crea un nuevoregistro cuando el archivo de registro alcanza el valor de umbralconfigurado. Si ya existe un archivo de registro en el inicio, losdatos nuevos se agregan en éste.

Especificación de la frecuencia para vaciar losbúferes de los archivos de registro

Los archivos de registro se escriben en flujos de datos con búfer. Sisupervisa los archivos de registro en tiempo real, puede alterar lafrecuencia con la cual el servidor fuerza un vaciado de los búferesdel archivo de registro.

De forma predeterminada, los archivos de registro se vacían cada 20segundos:


2.C

onfiguracióndel

servidorW

ebSE

AL

[logging]flush-time = 20

Si especifica un valor negativo, se forzará un vaciado cada vez quese escriba un registro.

Configuración de la longitud del contenido registradaen request.log

WebSEAL filtra automáticamente las direcciones URL HTMLestáticas de los servidores de fondo de aplicaciones con conexión(junction). La stanza[filter-url] del archivo de configuraciónwebseald.conf define los atributos de dirección URL queWebSEAL filtra como respuesta del servidor de fondo. Consulte elapartado “Filtro de direcciones URL HTML estáticas de losservidores con conexión (junction)” en la página 197.

Cuando el contenido solicitado desde un servidor de fondo conconexión (junction) contiene direcciones URL incrustadas,WebSEAL filtra las cadenas de dirección URL agregando el puntode conexión (junction) a la ruta de acceso. Cuando se devuelve alnavegador, el cliente puede utilizar la dirección URL correctamente.

El contenido final de las páginas devueltas al navegador puede teneruna longitud mayor que el contenido original devuelto desde elservidor con conexión (junction) a WebSEAL.

Esta versión de Policy Director WebSEAL permite configurar lalongitud del contenido registrada por el archivorequest.log (si estáactivado). El parámetrolog-filtered-pagesen la stanza[logging] delarchivo de configuraciónwebseald.conf se puede establecer paraque registre un tamaño de cero bytes o un tamaño de bytes sinfiltrar.

Para registrar el tamaño de bytes sin filtrar, establezca el parámetroen “yes” (predeterminado):[logging]log-filtered-pages = yes

Para registrar un tamaño de cero bytes, establezca el parámetro en“no”:

58 Versión 3.8

[logging]log-filtered-pages = no

Formato de registro de HTTP común (pararequest.log)

Cada respuesta (ya sea de éxito o error) que vuelve a enviar elservidor de Policy Director se registra con una entrada de una líneaen el archivorequest.log utilizando el Formato de registro deHTTP común:host - usuarioaut [fecha] petición estado bytes

donde:

host Especifica la dirección IP de la máquina que realizala petición.

usuarioaut Este campo toma el valor de la cabeceraDe: de lapetición HTTP recibida. El valor “unauth” se utilizapara los usuarios no autenticados.

fecha Especifica la fecha y la hora de la petición.

petición Especifica la primera línea de la petición tal como hallegado del cliente.

estado Especifica el código de estado de HTTP devuelto ala máquina que realiza la petición.

bytes Especifica el número de bytes devueltos a lamáquina que realiza la petición. Este valor—eltamaño de contenido sin filtrar o el tamaño nulo—seconfigura con el parámetrolog-filtered-pages.

Visualización del archivo request.logEl archivorequest.log realiza el registro estándar de peticionesHTTP, por ejemplo la información sobre las direcciones URL que sehan solicitado y la información acerca del cliente (por ejemplo, ladirección IP) que ha realizado la petición.

El ejemplo siguiente muestra una versión de un archivorequest_log:


2.C

onfiguracióndel

servidorW

ebSE

AL

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

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

Visualización del archivo agent.logEl archivoagent.log registra el contenido de la cabeceraUser_Agent: de la petición HTTP. Este registro muestra informaciónacerca del navegador de cliente, por ejemplo la arquitectura onúmero de versión, para cada petición.

El ejemplo siguiente muestra una versión de un archivoagent.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)

Visualización del archivo referer.logEl archivoreferer.log registra la cabeceraReferer: de la peticiónHTTP. Se registra el documento que contiene el vínculo aldocumento solicitado de cada petición.

El registro utiliza el siguiente formato:referente -> objeto

Esta información es útil para realizar un seguimiento de vínculosexternos a documentos del espacio Web. El registro muestra que elorigen indicado por elreferente contiene un vínculo a unobjeto depágina. Este registro le permite realizar un seguimiento de vínculosobsoletos y ver quién crea vínculos a sus documentos.

El ejemplo siguiente muestra una versión de un archivoreferer.log:http://manuel/maybam/index.html -> /pics/tivoli_logo.gifhttp://manuel/maybam/pddl/index.html ->/pics/tivoli_logo.gifhttp://manuel/maybam/ -> /pddl/index.html

60 Versión 3.8

http://manuel/maybam/ -> /pddl/index.htmlhttp://manuel/maybam/pddl/index.html ->/pics/tivoli_logo.gifhttp://manuel/maybam/ -> /pddl/index.html


2.C

onfiguracióndel

servidorW

ebSE

AL

62 Versión 3.8

Política de seguridad deWebSEAL

Este capítulo contiene información que describe cómo configurar ypersonalizar la política de seguridad de WebSEAL.

Índice de temas:

¶ “Políticas de ACL específicas de WebSEAL”

¶ “Política de inicio de sesión de tres intentos” en la página 65

¶ “Política de intensidad de la contraseña” en la página 68

¶ “Política POP de intensidad de la autenticación (incremental)” enla página 72

¶ “Política POP de autenticación basada en la red” en la página 79

¶ “Política POP de calidad de protección” en la página 83

¶ “Gestión de usuarios no autenticados (HTTP / HTTPS)” en lapágina 84

Políticas de ACL específicas de WebSEALLas siguientes consideraciones acerca de la seguridad se aplican alcontenedor /WebSEAL en el espacio de objetos protegidos:

¶ El objeto WebSEAL empieza la cadena de herencia de ACL parala región WebSEAL del espacio de objetos

3


3.P

olíticade

seguridadde

WebS

EA

L

¶ Si no aplica ninguna otra ACL explícita, este objeto define (através de la herencia) la política de seguridad para todo elespacio Web

¶ El permiso traverse es necesario para el acceso a este objeto ycualquier otro objeto a partir de este punto

Consulte la publicaciónTivoli SecureWay Policy Director Base Guíade administraciónpara obtener información completa acerca de laspolíticas de ACL de Policy Director.

/WebSEAL/< host >Este subárbol contiene el espacio Web de un servidor WebSEALconcreto. Las siguientes consideraciones de seguridad se aplican aeste objeto:

¶ El permiso traverse es necesario para el objeto a cualquier objetoa partir de este punto

¶ Si no aplica ninguna otra ACL explícita, este objeto define (através de la herencia) la política de seguridad para todo elespacio de objetos de esta máquina

/WebSEAL/< host >/<archivo >Se trata del objeto de recurso seleccionado para el acceso de HTTP.Los permisos seleccionados dependerán de la operación que sesolicite.

Permisos ACL de WebSEALLa tabla siguiente describe los permisos ACL aplicables para laregión WebSEAL del espacio de objetos:

Operación Descripción

r read Ver el objeto Web.

x execute Ejecutar el programa CGI.

d delete Eliminar el objeto Web del espacio Web.

m modify Realizar la transferencia (PUT) de un objeto HTTP.(Colocar - publicar - un objeto HTTP en el espaciode objetos de WebSEAL.)

64 Versión 3.8

Operación Descripción

l list Requerido por Management Server para generaruna lista de directorios automatizada del espacioWeb.

Este permiso rige también si un cliente puede verla lista de contenido del directorio cuando no seencuentra la página predeterminada “index.html”.

g delegation Concede fiabilidad a un servidor WebSEAL paraque actúe en nombre de un cliente y pase estapetición a un servidor WebSEAL con conexión(junction).

Política de ACL predeterminada de /WebSEALLas entradas esenciales ACL de WebSEAL,default-webseal, son:Grupo iv-admin TcmdbsvarxlGrupo webseal-servers TgmdbsrxlUsuario sec_master TcmdbsvarxlOtros TrxNo autenticado T

Durante la instalación, esta ACL se asocia con el objeto contenedor/WebSEAL en el espacio de objetos.

El grupo,webseal-servers,contiene una entrada para cada servidorWebSEAL en el dominio seguro. Los permisos predeterminadospermiten a los servidores responder a las peticiones del navegador.

El permiso traverse permite la expansión del espacio Web, tal ycomo se representa en el Web Portal Manager. El permiso listpermite a Web Portal Manager visualizar el contenido del espacioWeb.

Política de inicio de sesión de tres intentosLa política de inicio de sesión de tres intentos, disponible parainstalaciones de Policy Director basadas en LDAP, le permiteespecificar un número máximo de intentos de inicio de sesiónfallidos (n) y un tiempo de bloqueo de penalización (x), de forma


3.P

olíticade

seguridadde

WebS

EA

L

que si se producen “n” intentos de inicio de sesión fallidos, elusuario se bloquea durante “x” segundos (o se desactiva la cuenta).

La política de inicio de sesión de tres intentos se utiliza para evitarataques de contraseñas contra el sistema. La política crea unacondición por la cual el usuario debe esperar un período de tiempoantes de realizar otros intentos después del error de un inicio desesión. Por ejemplo, una política puede indicar que después de 3intentos fallidos debe producirse una penalización de 180 segundos.Este tipo de política de inicio de sesión puede evitar que los intentosde inicio de sesión generados por un sistema de forma aleatoria seproduzcan muchas veces por segundo.

La política de tres intentos requiere la contribución conjunta de dosvalores del comandopdadmin policy:

¶ Número máximo de intentos de inicio de sesión fallidos

policy set max-login-failures

¶ Penalización al exceder el valor de intentos de inicio de sesiónfallidos

policy set disable-time-interval

El valor de penalización puede incluir un intervalo de tiempo debloqueo de la cuenta o una desactivación total de ésta.

Si se ha establecido una política de inicio de sesión (como ejemplo)de tres intentos fallidos seguidos de una penalización de tiempo debloqueo específica, un cuarto intento (correcto o incorrecto) darácomo resultado una página de error que indicará que la cuenta noestá disponible temporalmente debido a la política de contraseñas.

El intervalo de tiempo se especifica en segundos (el intervalomínimo recomendado es de 60 segundos).

Si la políticadisable-time-interval está establecida en “disable”(desactivado), se bloquea la cuenta para este usuario y el atributoaccount valid (cuenta válida) se establece en “no” para el usuario.Un administrador puede volver a activar la cuenta a través de WebPortal Manager.

66 Versión 3.8

Nota: si se establecedisable-time-interval en “disable” seproducirá una sobrecarga de administración adicional. Puedenexperimentarse dilaciones al replicar la información deaccount valid (cuenta válida) en el servidor WebSEAL. Estasituación dependerá del entorno LDAP. Además, algunasimplementaciones de LDAP pueden experimentar unadegradación del rendimiento como consecuencia de laoperación de actualización deaccount valid (cuenta válida).Es recomendable el uso de un intervalo de tiempo de espera.

Sintaxis de los comandosLos siguientes comandospdadmin son apropiados sólo para su usocon un registro LDAP.

Comando Descripción

policy set max-login-failures {<número>|unset} [-user<nombre-usuario>]

policy get max-login-failures [-user <nombre-usuario>]

Gestiona la política controlando el número máximo deintentos de inicio de sesión fallidos permitidos antesde imponer una penalización. Este comando dependedel conjunto de penalizaciones del comandopolicy setdisable-time-interval.

Como administrador, puede aplicar esta política a unusuario específico o bien de forma global a todos losusuarios listados en el registro LDAP.

El valor predeterminado es 10 intentos.

policy set disable-time-interval {<número>|unset|disable} [-user<nombre-usuario>]

policy get disable-time-interval [-user <nombre-usuario>]


3.P

olíticade

seguridadde

WebS

EA

L


Gestiona la política de penalizaciones controlando elperíodo de tiempo que debe desactivarse una cuenta sise ha alcanzado el número máximo de intentos deinicio de sesión fallidos.

Como administrador, puede aplicar esta política depenalizaciones a un usuario específico o bien de formaglobal a todos los usuarios listados en el registroLDAP.

El valor predeterminado es 180 segundos.

Política de intensidad de la contraseñaLa política de intensidad de la contraseña, disponible parainstalaciones de Policy Director basadas en LDAP, hace referencia alas estipulaciones de las reglas de la política de contraseñas para laconstrucción de una contraseña. Policy Director proporciona dosformas de controlar la política de intensidad de la contraseña:

¶ Cinco comandospdadmin de política de contraseñas

¶ Un módulo PAM (plugable authentication module) que lepermite personalizar una política de contraseñas

Consulte la publicaciónTivoli SecureWay Policy DirectorWebSEAL Developer Reference.

Política de intensidad de la contraseña establecidapor la utilidad pdadmin

Los cinco atributos de intensidad de la contraseña implementados através de la utilidadpdadmin son:

¶ Longitud mínima de la contraseña

¶ Caracteres alfabéticos mínimos

¶ Caracteres no alfabéticos mínimos

¶ Número máximo de caracteres repetidos

¶ Espacios permitidos

68 Versión 3.8

Estas políticas se aplican al crear un usuario conpdadmin o conWeb Portal Manager y cuando se cambia una contraseña conpdadmin, con Web Portal Manager o con la utilidadpkmspasswd.

Sintaxis de los comandosLos siguientes comandospdadmin sólo son apropiados para el usocon un registro LDAP. La opciónunset desactiva este atributo depolítica, es decir, que no se aplica la política.


policy set min-password-length {<número>|unset} [-user<nombre-usuario>]

policy get min-password-length [-user <nombre-usuario>]

Gestiona la política controlando la longitud mínima deuna contraseña.

Como administrador, puede aplicar esta política a unusuario específico o bien de forma global a todos losusuarios listados en el registro predeterminado.

El valor predeterminado es 8.

policy set min-password-alphas {<número>|unset} [-user<nombre-usuario>]

policy get min-password-alphas [-user <nombre-usuario>]

Gestiona la política controlando el número mínimo decaracteres alfabéticos de una contraseña.



policy set min-password-non-alphas {<número>|unset} [-user<nombre-usuario>]

policy get min-password-non-alphas [-user <nombre-usuario>]


3.P

olíticade

seguridadde

WebS

EA

L


Gestiona la política controlando el número mínimo decaracteres no alfabéticos de una contraseña.



policy set max-password-repeated-chars {<número>|unset} [-user<nombre-usuario>]

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

Gestiona la política controlando el número máximo decaracteres repetidos permitidos en una contraseña.



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

policy get password-spaces [-user <nombre-usuario>]

Gestiona la política controlando si la contraseña puedecontener espacios.


El valor predeterminado es unset (desactivado).

Valores de parámetros de política predeterminadaLa tabla siguiente lista los parámetros de política y los valorespredeterminados:

Parámetro Valor predeterminado

min-password-length 8

min-password-alphas 4

min-password-non-alphas 1

70 Versión 3.8

Parámetro Valor predeterminado

max-password-repeated-chars 2

password-spaces unset

Para crear el comportamiento de la política de contraseñas que seencuentra en releases anteriores de Policy Director, aplique la opciónunset a los cinco parámetros de contraseña listados anteriormente.

Ejemplos de contraseñas válidas y no válidasLa tabla siguiente muestra varios ejemplos de contraseñas y losresultados de la política según los valores predeterminados de loscinco parámetros depdadmin:

Ejemplo Resultado

password No válida: debe contener al menos un carácter noalfabético.

pass No válida: debe contener 8 caracteres como mínimo.

passs1234 No válida: contiene más de dos caracteres repetidos.

12345678 No válida: debe contener al menos cuatro caracteresalfabéticos.

password3 Válida.

Valores globales y específicos de un usuarioLos comandospdadmin policy se pueden establecer para un usuarioespecífico (con la opción-user) o bien globalmente (sin utilizar laopción -user). Los valores específicos de un usuario prevalecensobre los valores globales de la política. También puede desactivar(unset) un parámetro de política, lo que significa que el parámetrono contiene ningún valor. No se comprobarán ni se aplicarán laspolíticas que tengan la opciónunset.

Por ejemplo:pdadmin> policy set min-password-length 8

pdadmin> policy set min-password-length 4 -user miguel

pdadmin> policy get min-password-length


3.P

olíticade

seguridadde

WebS

EA

L

Longitud mínima de la contraseña: 8

pdadmin> policy get min-password-length -user miguel

Longitud mínima de la contraseña: 4

El usuario miguel tiene una política de longitud mínima decontraseña de 4 caracteres; los demás tienen una política de longitudmínima de contraseña de 8.pdadmin> policy set min-password-length unset -user miguel

Ahora, el usuario miguel se rige por la política global de longitudmínima de contraseña de 8 caracteres.pdadmin> policy set min-password-length unset

Ahora ningún usuario, ni siquiera el usuario miguel, tiene unapolítica de longitud mínima de la contraseña.

Política POP de intensidad de la autenticación(incremental)

La política POP de intensidad de la autenticación hace posible elcontrol del acceso a objetos en función del método de autenticaciónque éstos utilizan.

Puede utilizar estas funciones (conocidas a veces como autenticaciónincremental) para garantizar que los usuarios que acceden a recursosmás confidenciales utilicen un mecanismo de autenticación máspotente. Esta condición es recomendable debido a la importanteamenaza que suponen los accesos inadecuados.

Por ejemplo, puede proporcionar una mayor seguridad a una regióncon conexión (junction) del espacio Web aplicando una política POPincremental que requiera un nivel mayor de autenticación del que hautilizado el cliente al entrar inicialmente en el dominio WebSEAL.

La política de intensidad de la autenticación está establecida en elatributo Método de autenticación de Endpoint de IP de una políticaPOP.

72 Versión 3.8

Configuración de los niveles de autenticaciónincremental

El primer paso al configurar el acceso específico de la autenticaciónes configurar los métodos de autenticación soportados y determinarel orden de importancia de estos métodos de autenticación.

Cualquier cliente que accede a un servidor WebSEAL tiene un nivelde autenticación, como “unauthenticated” (no autenticado) o“password” (contraseña), que indica el método mediante el cual seha autenticado el cliente por última vez con WebSEAL.

Es posible que en algunas situaciones sea necesario aplicar losniveles mínimos de “seguridad” de la autenticación necesarios paraacceder a algunos objetos de espacio Web. Por ejemplo, es posibleque en un entorno se considere que la autenticación mediante códigode paso de señal es más segura que la autenticación mediantenombre de usuario y contraseña. Otro entorno puede tener estándaresdistintos.

En lugar de forzar a los clientes a reiniciar sus sesiones conWebSEAL cuando no cumplen el nivel requerido de autenticación, elmecanismo de autenticación incremental les ofrece una segundaoportunidad de volver a autenticarse utilizando el método (nivel)necesario.

La autenticación incremental significa que el usuario no recibeinmediatamente un mensaje de “acceso denegado” cuando intentaacceder a un recurso que requiere un nivel de autenticación “mayor”que el del inicio de sesión, sino que ve una petición de autenticaciónnueva que solicita información para dar soporte a un mayor nivel deautenticación. Si puede proporcionar ese nivel, se permitirá supetición original.

WebSEAL reconoce tres métodos de autenticación (niveles) parautilizarlos en el mecanismo de autenticación incremental:

¶ unauthenticated (no autenticado)

¶ password (contraseña)


3.P

olíticade

seguridadde

WebS

EA

L

¶ token-card (tarjeta de señal)

Los niveles de autenticación se configuran en la stanza[authentication-levels] del archivo de configuraciónwebseald.conf. Inicialmente, sólo se configuran dos niveles:[authentication-levels]level = unauthenticatedlevel = password

Según el orden de los métodos en la lista, se asigna un índice denivel, del 0 al 2, a cada método.

¶ El método “unauthenticated” (no autenticado)debe ser siempreel primero de la lista y tiene asignado el índice de nivel de 0.

¶ Los métodos siguientes pueden estar en cualquier orden.

Consulte el apartado “Notas y limitaciones de la autenticaciónincremental” en la página 78.

¶ De forma predeterminada, “password” (contraseña) aparece en elnivel siguiente, por lo que se encuentra en el índice de nivel 1.

¶ Debe haber al menos dos entradas para activar la autenticaciónincremental.

Nota: consulte el apartado “Autenticación de WebSEAL” en lapágina 87 para obtener información detallada acerca de laconfiguración de los mecanismos de autenticación necesarios.

Activación de la autenticación incrementalLa autenticación incremental se implementa mediante una políticaPOP asociada con los objetos que requieren una autorización deautenticación confidencial. Utilice el atributo Método deautenticación de Endpoint de IP de una política POP.

El comandopdadmin pop modify set ipauth especifica las redespermitidas y el nivel de autenticación necesario en el atributoMétodo de autenticación de Endpoint de IP.

Los niveles de autenticación configurados se pueden vincular arangos de direcciones IP. Este método se ha concebido paraproporcionar una flexibilidad de gestión. Si no es importante el filtro

74 Versión 3.8

de usuarios por dirección IP, puede establecer una sola entrada paraanyothernw (cualquier otra red). Este valor afectará a todos losusuarios que accedan, independientemente de la dirección IP, y lessolicitará que se autentiquen en el nivel especificado. Es el métodomás habitual para implementar la autenticación incremental.

Sintaxis:pdadmin> pop modify <nombre-pop> set ipauth anyothernw <índice-nivel>

La entradaanyothernw se utiliza como rango de red que coincidirácon cualquier red que no esté especificada en la política POP. Estemétodo se utiliza para crear una entrada predeterminada que puederechazar todas las direcciones IP no coincidentes o permitir el accesoa cualquiera que cumpla el requisito de nivel de autenticación.

anyothernw aparece de forma predeterminada en una política POPcon el índice de nivel de autenticación 0. La entrada aparece como“Cualquier otra red” en el comandopop show:pdadmin> pop show test

Política de objetos protegidos: testDescripción: Test POPAviso: noNivel de auditoría: noneCalidad de protección: noneAcceso según hora del día: sun, mon, tue, wed, thu, fri, sat:

anytime:localPolítica de métodos de autenticación de Endpoint de IP

Cualquier otra red 0

Ejemplo1. Configure los niveles de autenticación en el archivo

webseald.conf:[authentication-levels]level = unauthenticatedlevel = token-card

2. Configure el atributo Método de autenticación de Endpoint de IPde la política POP:pdadmin> pop modify test set ipauth anyothernw 1

pdadmin> pop show testPolítica de objetos protegidos: test


3.P

olíticade

seguridadde

WebS

EA

L

Descripción: Test POPAviso: noNivel de auditoría: noneCalidad de protección: noneAcceso según hora del día: mon, wed, fri:anytime:localPolítica de métodos de autenticación de Endpoint de IP


Esta política requiere incrementar la autenticación al método deautenticación de tarjeta de señal (nivel 1) para todos los usuariosque acceden inicialmente como “no autenticados” (nivel 0). Atodos los usuarios no autenticados que intenten acceder a losobjetos protegidos por esta política POP se les solicitará elnombre de usuario y el código de paso de señal.

Consulte también el apartado “Política POP de autenticaciónbasada en la red” en la página 79.

Formulario de inicio de sesión incrementalWebSEAL presenta un formulario especial cuando la política POPincremental del recurso solicitado fuerza la reautenticación delcliente. La ubicación de este formulario HTML se especificamediante el parámetrostepup-login de la stanza[acnt-mgt] delarchivo de configuraciónwebseald.conf.[acnt-mgt]stepup-login = stepuplogin.html

Puede configurar este formulario HTML para que cumpla susrequisitos, de la misma forma que puede configurar los formularioslogin.htmlo tokenlogin.html.

Este archivo contiene macros, en forma de secuencias %TEXTO%,que se sustituyen por los valores apropiados. Esta sustitución seproduce en las funciones de proceso del archivo de plantilla deWebSEAL y permite el uso del formulario para los métodos deautenticación de contraseña y señal con el formato correcto. Tambiénpermite proporcionar otra información, como el mensaje de error yel nombre de método (incremental), en el formulario para el usuario.

76 Versión 3.8

Figura 11. Formulario de inicio de sesión para la autenticación incremental de nombrede usuario y contraseña

Figura 12. Formulario de inicio de sesión para la autenticación incremental de códigode paso de señal de SecurID


3.P

olíticade

seguridadde

WebS

EA

L

Algoritmo de autenticación incrementalWebSEAL utiliza el siguiente algoritmo para procesar lascondiciones de una política POP:

1. Comprobar la política de método de autenticación de Endpointde IP de la política POP.

2. Comprobar los permisos ACL.

3. Comprobar la política de acceso según la hora del día de lapolítica POP.

4. Comprobar la política de nivel de auditoría de la política POP.

Notas y limitaciones de la autenticación incremental1. La autenticación incremental tiene soporte en HTTP y HTTPS.

2. No puede pasar del protocolo HTTP a HTTPS.

3. El método no autenticado debe ser siempre el primero de la listade niveles y no puede encontrarse en ningún otro puesto de lalista.

4. Los métodos sólo se pueden especificar una vez en la lista deniveles.

5. La autenticación de certificados no es un método soportado parala autenticación incremental.

Nota: la autenticación incremental gestiona certificados decliente como caso especial. Si un cliente accede aWebSEAL con un certificado de cliente y WebSEAL estáconfigurado para aceptar certificados, el cliente se tratarácomo no autenticado con un índice de nivel de 0.

Del método: Se puede pasar a:

unauthenticated password token-card

password token-card

token-card password

78 Versión 3.8

6. Los métodos de autenticación representan los niveles deautenticación. Esto significa que es imposible especificar unmecanismo de autenticación preciso para la autenticación en esenivel.

Los métodos de autenticación pueden estar soportados por variosmecanismos de autenticación, incluidos los autenticadores localesy los autenticadores externos personalizados.

WebSEAL sigue reglas específicas para determinar elautenticador que se debe seleccionar cuando se han configuradovarias instancias del mismo tipo de método de autenticación.

7. Si hay tres niveles configurados, los valores de índice válidosson 0, 1 y 2. Si hayalgún otro valor de índice configurado,WebSEAL presenta una página de error siempre que se solicitaun objeto asociado con esa política POP.

8. La configuración incorrecta de los niveles de autenticaciónincremental en el archivo de configuraciónwebseald.conf dancomo resultado la desactivación de la funcionalidad incrementalen WebSEAL. Esta situación puede producir comportamientosinesperados de autenticación como, por ejemplo, la emisión de lapágina de inicio de sesión de contraseña para objetos protegidospor una política POP que requiera el método de autenticación decódigo de paso de señal.

Después de configurar los niveles de autenticación incremental,compruebe el archivowebseald.log para ver si hay informes deerrores de configuración.

Política POP de autenticación basada en la redLa política POP de autenticación basada en la red hace posible elcontrol del acceso a objetos en función de la dirección IP delusuario. Puede utilizar esta función para evitar que direcciones IPespecíficas (o rangos de direcciones IP) accedan a cualquier recursodel dominio seguro.

También puede aplicar la configuración de la autenticaciónincremental a esta política y solicitar un método de autenticaciónespecífico para cada rango de direcciones IP especificado.


3.P

olíticade

seguridadde

WebS

EA

L

La política de autenticación basada en la red está establecida en elatributo Método de autenticación de Endpoint de IP de una políticaPOP. Debe especificar dos requisitos en este atributo:

¶ Niveles de autenticación

¶ Redes permitidas

Configuración de los niveles de autenticaciónWebSEAL reconoce tres métodos de autenticación para utilizarlos enel mecanismo de autenticación incremental:

¶ unauthenticated (no autenticado)

¶ password (contraseña)

¶ token-card (tarjeta de señal)

Según el orden de los métodos en la lista, se asigna un índice denivel, del 0 al 2, a cada método.

Los niveles de autenticación se configuran en la stanza[authentication-levels] del archivo de configuraciónwebseald.conf. Inicialmente, sólo se configuran dos niveles:[authentication-levels]level = unauthenticatedlevel = password

Puede utilizar estos valores predeterminados cuando configure laautenticación basada en la red. En ese caso, “unauthenticated” (noautenticado) es el nivel 0 y “password” (contraseña) es el nivel 1.

Consulte también el apartado “Configuración de los niveles deautenticación incremental” en la página 73.

Especificación de direcciones y rangos IPEspecifique las direcciones IP y los rangos de direcciones IPpermitidos por esta política POP.

El comandopdadmin pop modify set ipauth add especifica tantola red (o rango de redes) como el nivel de autenticación requerido enel atributo Método de autenticación de Endpoint de IP.

80 Versión 3.8

Sintaxis:pdadmin> pop modify <nombre-pop> set ipauth add <red> <máscara-red> <

índice-nivel>

Los niveles de autenticación configurados están vinculados a losrangos de direcciones IP. Este método se ha concebido paraproporcionar flexibilidad. Si no es importante el filtro de usuariospor dirección IP, puede establecer una sola entrada paraanyothernw(cualquier otra red). Este valor afectará a todos los usuarios queaccedan, independientemente de la dirección IP, y les solicitará quese autentiquen en el nivel especificado.

Sintaxis:pdadmin> pop modify <nombre-pop> set ipauth anyothernw <índice-nivel>

De lo contrario, si desea ignorar el nivel de autenticación y permitiro denegar el acceso sólo según la dirección IP, puede utilizar el nivel0 para los rangos que desee permitir y “forbidden” (prohibido) paralos rangos que desee rechazar.

La entradaanyothernw se utiliza como rango de red que coincidecon cualquier red que no esté especificada en la política POP. Estemétodo se utiliza para crear una entrada predeterminada que puederechazar todas las direcciones IP no coincidentes o permitir el accesoa cualquiera que cumpla el requisito de nivel de autenticación.

anyothernw aparece de forma predeterminada en una política POPcon el índice de nivel de autenticación 0. La entrada aparece como“Cualquier otra red” en el comandopop show:pdadmin> pop show test

Política de objetos protegidos: testDescripción: Test POPAviso: noNivel de auditoría: noneCalidad de protección: noneAcceso según hora del día: sun, mon, tue, wed, thu, fri, sat:

anytime:localPolítica de métodos de autenticación de Endpoint de IP



3.P

olíticade

seguridadde

WebS

EA

L

Consulte el apartado “Configuración de los niveles de autenticaciónincremental” en la página 73 para obtener información detalladaacerca de la configuración de los niveles de autenticación.

EjemplosPara solicitar a los usuarios del rango de direcciones IP 9.0.0.0 ymáscara de red 255.0.0.0 la utilización del nivel de autenticación 1(el valor predeterminado es “password”):pdadmin> pop modify test set ipauth add 9.0.0.0 255.0.0.0 1

Para solicitar a un usuario específico la utilización del nivel deautenticación 0:pdadmin> pop modify test set ipauth add 9.1.2.3 255.255.255.255 0

Para evitar que todos los usuarios (distintos de los especificados enlos ejemplos anteriores) tengan acceso al objeto:pdadmin> pop modify test set ipauth anyothernw forbidden

Desactivación de la autenticación incremental pordirección IP

Sintaxis:pdadmin> pop modify <nombre-pop> set ipauth remove <red> <máscara-red>

Por ejemplo:pdadmin> pop modify test set ipauth remove 9.0.0.0 255.0.0.0

Algoritmo de autenticación basada en la redWebSEAL utiliza el siguiente algoritmo para procesar lascondiciones de una política POP:

1. Comprobar la política de método de autenticación de Endpointde IP de la política POP.

2. Comprobar los permisos ACL.

3. Comprobar la política de acceso según la hora del día de lapolítica POP.

4. Comprobar la política de nivel de auditoría de la política POP.

82 Versión 3.8

Notas y limitaciones de la autenticación basada en lared

La dirección IP que utiliza WebSEAL para aplicar la política deautenticación basada en la red debe ser la del originador de laconexión TCP. Si la topología de la red utiliza proxies HTTP, ladirección que reciba WebSEAL puede ser la dirección IP del servidorproxy.

En tal caso, WebSEAL no puede identificar de forma definitiva ladirección IP verdadera del cliente. Debe tener cuidado al configuraruna política de autenticación basada en la red para que los clientesde la red puedan conectarse directamente con el servidor WebSEAL.

Política POP de calidad de protecciónEl atributo POP de calidad de protección le permite especificar elnivel de protección de datos necesario al realizar una operación enun objeto.

Actualmente, este atributo sólo es apropiado en un entornoWebSEAL.

El atributo POP de calidad de protección es la sustitución de los bitsde permisos ACL “P” e “I” que activaban los requisitos deprivacidad e integridad en las versiones anteriores de Policy Director.Esta implementación anterior de la calidad de protección no eraeficaz y minaba el rendimiento del sistema.

El atributo POP de calidad de protección permite una solatransacción donde la respuesta “yes” a la decisión de ACL incluyetambién el nivel de calidad de protección requerido. Si el gestor derecursos (como WebSEAL) no puede garantizar el nivel deprotección requerido, se rechaza la petición.pdadmin> pop modify <nombre-pop> set qop {none|integrity|privacy}

Nivel de QOP Descripción

Privacy(Privacidad)

Es necesario el cifrado de datos (SSL).


3.P

olíticade

seguridadde

WebS

EA

L

Nivel de QOP Descripción

Integrity(Integridad)

Utilizar algún mecanismo para garantizar que no hancambiado los datos.

Por ejemplo:pdadmin> pop modify test set qop privacy

Gestión de usuarios no autenticados (HTTP / HTTPS)WebSEAL acepta las peticiones de usuarios autenticados y noautenticados a través de HTTP y HTTPS. WebSEAL se apoya enAuthorization Service para aplicar la política de seguridad y permitiro rechazar el acceso a los recursos protegidos.

Las siguientes condiciones son aplicables para los usuarios noautenticados que acceden a través de SSL:

¶ El intercambio de información entre el usuario no autenticado yWebSEAL está cifrado, de la misma forma que con los usuariosautenticados.

¶ Las conexiones SSL entre usuarios no autenticados y WebSEALsólo requieren la autenticación de servidor.

Proceso de una petición desde un cliente anónimo1. Un cliente anónimo realiza una petición a WebSEAL (a través de

HTTP o HTTPS).

2. WebSEAL crea una credencial no autenticada para ese cliente.

3. La petición sigue, con esta credencial, hasta el objeto Webprotegido.

4. Authorization Service comprueba los permisos de la entrada noautenticada de la ACL para ese objeto y permite o rechaza laoperación solicitada.

5. El acceso correcto a ese objeto depende de que la entrada deACL no autenticada contenga al menos los permisos read (r) ytraverse (T).

84 Versión 3.8

6. Si la petición no supera la decisión de autorización, el clienterecibe un formulario de inicio de sesión (basado en formularios oBA).

Cómo forzar el inicio de sesión del usuarioPuede obligar a un usuario no autenticado a que inicie una sesiónestableciendo correctamente los permisos apropiados en la entrada noautenticada de la política de ACL que protege el objeto solicitado.

Los permisos read (r) y traverse (T) permiten a los usuarios noautenticados el acceso a un objeto.

Para obligar al usuario no autenticado a iniciar una sesión, elimine elpermiso read (r) de la entrada no autenticada de la política de ACLque protege el objeto. El usuario recibirá un indicador de inicio desesión (basado en formularios o BA).

Aplicaciones de HTTPS sin autenticaciónHay muchos motivos empresariales prácticos para dar soporte alacceso no autenticado a WebSEAL a través de HTTPS:

¶ Algunas aplicaciones no requieren un inicio de sesión personal,pero sí información confidencial como, por ejemplo, direccionesy números de tarjeta de crédito. Es el caso de las compras enlínea de billetes de avión u otros productos.

¶ Algunas aplicaciones requieren que el usuario registre unacuenta con la empresa antes de proceder con otras transacciones.Para ello, se debe pasar información confidencial por la red.

Control de usuarios no autenticados con políticas deACL/POP

Nota: el tipo de entrada “any-authenticated” (cualquier autenticado)es equivalente al tipo de entrada “any-other” (cualquier otro).

1. Para permitir el acceso de un usuario no autenticado a los objetospúblicos, proteja el contenido público con una ACL que contengaal menos los permisos read (r) y traverse (T) para las entradasunauthenticated (no autenticado) y any-authenticated (cualquierautenticado):


3.P

olíticade

seguridadde

WebS

EA

L

unauthenticated Trany-authenticated Tr

Nota: la entradaunauthenticated es una máscara (unaoperación “and” a nivel de bit) contra la entradaany-authenticatedcuando se determinan los permisos.Sólo se otorga un permiso paraunauthenticated si ésteaparece también en la entradaany-authenticated. Puestoqueunauthenticated depende deany-authenticated, notiene sentido que una ACL contengaunauthenticated sinany-authenticated. Si una ACL contieneunauthenticatedsin any-authenticated, la respuesta predeterminada es nootorgar ningún permiso aunauthenticated.

2. Para requerir el cifrado (SSL), proteja el contenido con unapolítica de objetos protegidos (POP) que especifica la privacidadcomo una condición.

Consulte el apartado “Política POP de calidad de protección” enla página 83.

86 Versión 3.8

Autenticación de WebSEAL

En este capítulo se describe cómo WebSEAL mantiene el estado dela sesión y controla el proceso de autenticación. La autenticacióncorrecta deriva en una identidad de Policy Director que representa alusuario. WebSEAL utiliza esta identidad para adquirir lascredenciales para este usuario. Authorization Service utiliza lascredenciales para permitir o denegar el acceso a los recursosprotegidos.

Índice de temas:

¶ “Información sobre el proceso de autenticación” en la página 88

¶ “Gestión del estado de la sesión” en la página 91

¶ “Visión general de la configuración de la autenticación” en lapágina 104

¶ “Configuración de la autenticación básica” en la página 109

¶ “Configuración de la autenticación de formularios” en la página112

¶ “Configuración de la autenticación de certificados de cliente” enla página 114

¶ “Configuración de autenticación de cabecera HTTP” en lapágina 119

¶ “Configuración de autenticación de direcciones IP” en la página122

¶ “Configuración de la autenticación de señales” en la página 122

4


4.A

utenticaciónde

WebS

EA

L

¶ “Soporte para Multiplexing Proxy Agents” en la página 124

Información sobre el proceso de autenticaciónLa autenticación es el método para identificar un proceso o entidadindividual que intenta conectarse a un dominio seguro.

¶ WebSEAL da soporte a varios métodos de autenticación deforma predeterminada y se puede personalizar para que utiliceotros métodos.

¶ El resultado de la autenticación correcta para WebSEAL es unaidentidad en el registro de usuario de Policy Director.

¶ WebSEAL utiliza esta identidad para obtener una credencial paraese usuario.

¶ Authorization Service utiliza esta credencial para permitir odenegar el acceso a los objetos protegidos después de evaluar lospermisos ACL y condiciones de POP que rigen la política paracada objeto.

Nota: ACL = política de lista de control de accesos POP; = políticade objetos protegidos

Durante la autenticación, WebSEAL examina la petición de cliente ybusca la siguiente información:

¶ Datos de sesión

Los datos de sesión es información que identifica una conexiónespecífica entre el cliente y el servidor WebSEAL. Los datos desesión se almacenan en el cliente y acompañan a las siguientespeticiones del cliente. Se utilizan para reidentificar la sesión decliente en el servidor WebSEAL y evitar la sobrecarga deestablecer una nueva sesión en cada petición.

¶ Datos de autenticación

Los datos de autenticación es información del cliente quepermite identificarlo en el servidor WebSEAL. Los tipos dedatos de autenticación son los certificados de cliente, lascontraseñas y los códigos de señal.

88 Versión 3.8

Cuando WebSEAL recibe una petición de cliente, busca siempre enprimer lugar los datos de sesión y, a continuación, los datos deautenticación. La petición de cliente inicial no contiene nunca datosde sesión.

Tipos de datos de sesión soportadosWebSEAL da soporte a los siguientes tipos de datos de sesión:

1. ID de SSL (definido por el protocolo SSL)

2. Cookie de sesión específica del servidor

3. Datos de cabecera BA

4. Datos de cabecera HTTP

5. Dirección IP

Cuando WebSEAL examina una petición de cliente, busca los datosde sesión en el orden especificado en esta lista.

Métodos de autenticación soportadosAunque WebSEAL funciona de manera independiente del proceso deautenticación, WebSEAL utiliza credenciales para supervisar a todoslos usuarios que participan en el dominio seguro. Para obtener lainformación de identidad necesaria para la adquisición decredenciales, WebSEAL confía en la información que se obtiene enel proceso de autenticación.

WebSEAL da soporte a los siguientes métodos de autenticación parala adquisición de credenciales:

Método de autenticación Tipo de conexiónsoportado

1. Cookie de recuperación tras error HTTP y HTTPS

2. Señal de ID de CDSSO HTTP y HTTPS

3. Certificado de cliente HTTPS

4. Código de paso de señal HTTP y HTTPS

5. Autenticación de formularios (nombre deusuario y contraseña)

HTTP y HTTPS


4.A

utenticaciónde

WebS

EA

L

Método de autenticación Tipo de conexiónsoportado

6. Autenticación básica (nombre de usuario ycontraseña)

HTTP y HTTPS

7. Cabeceras HTTP HTTP y HTTPS

8. Dirección IP HTTP y HTTPS

Cuando WebSEAL examina una petición de cliente, busca los datosde autenticación en el orden especificado en esta tabla.

Los métodos de autenticación se pueden activar y desactivar demanera independiente para los transportes HTTP y HTTPS. Si no seactiva ningún método de autenticación para un transportedeterminado, el proceso de autenticación estará desactivado para losclientes que utilicen ese transporte.

Referencias a la información de configuracióndetallada

¶ “Gestión del estado de la sesión” en la página 91

¶ “Visión general de la configuración de la autenticación” en lapágina 104

¶ “Configuración de la autenticación básica” en la página 109

¶ “Configuración de la autenticación de formularios” en lapágina 112

¶ “Configuración de la autenticación de certificados de cliente” enla página 114

¶ “Configuración de autenticación de cabecera HTTP” en lapágina 119

¶ “Configuración de autenticación de direcciones IP” en lapágina 122

¶ “Configuración de la autenticación de señales” en la página 122

¶ “Soporte para Multiplexing Proxy Agents” en la página 124

¶ Autenticación con CDAS

90 Versión 3.8

Consulte la publicaciónTivoli SecureWay Policy DirectorWebSEAL Developer Reference.

Gestión del estado de la sesiónUna conexión o sesión segura entre un cliente y un servidor requiereque el servidor tenga la posibilidad de recordar, a través denumerosas peticiones, con quién está hablando. El servidor debetener algún tipo de información de estado de la sesión queidentifique al cliente asociado con cada petición.

Sin un estado de sesión establecido entre el cliente y el servidor, lacomunicación entre el cliente y el servidor se debe renegociar paracada petición posterior. La información sobre el estado de la sesiónmejora el rendimiento, ya que evita tener que cerrar y volver a abrirrepetidamente las conexiones entre cliente y servidor. El clientepuede iniciar la sesión una vez y realizar numerosas peticiones sinrealizar un inicio de sesión distinto para cada petición.

WebSEAL maneja la comunicación de HTTP y HTTPS. HTTP es unprotocolo “sin información de estado” y no proporciona ningunaforma para distinguir una petición de otra. Por otro lado, el protocolode transporte SSL está especialmente diseñado para proporcionar unID de sesión para mantener la información de estado de la sesión. Lacomunicación de HTTP se puede encapsular en SSL para convertirseen HTTPS.

No obstante, WebSEAL debe manejar a menudo comunicacionesHTTP de clientes sin autenticar. Y hay casos en los que el ID desesión SSL no es la mejor solución. Por lo tanto, WebSEAL estádiseñado para utilizar cualquiera de los siguientes tipos deinformación para mantener el estado de la sesión con un cliente:

1. ID de SSL

2. Cookie de sesión específica del servidor

3. Datos de cabecera BA

4. Datos de cabecera HTTP

5. Dirección IP


4.A

utenticaciónde

WebS

EA

L

Las cachés de sesión de GSKit y WebSEALLa caché de sesión permite a un servidor almacenar la informaciónde ID de sesión de varios clientes. Hay disponibles dos cachés desesión para incluir la información de estado de sesión de HTTPS yHTTP.

¶ Caché de credenciales de WebSEAL

La caché de credenciales de WebSEAL almacena cualquier tipode información de ID de sesión (consultar la lista anterior),además de la información de credenciales obtenida para cadacliente.

La información de credenciales se guarda en la caché paraeliminar las consultas repetitivas a la base de datos de registrode usuarios durante las comprobaciones de autorizaciones.

¶ Caché de ID de sesión SSL de GSKit

La caché de sesión de GSKit maneja la comunicación de HTTPS(SSL) cuando se utiliza la información de ID de sesión SSL paramantener el estado de la sesión.

La caché de GSKit también mantiene la información de estadode sesión para la conexión SSL entre WebSEAL y el registro deusuario LDAP.

Hay disponibles varios parámetros de configuración para cada cachéque permiten ajustar el rendimiento de la caché. Estos parámetros seresumen en la siguiente figura

92 Versión 3.8

Configuración de la caché de credenciales deWebSEAL

Las siguientes tareas de configuración están disponibles para lacaché de credenciales/sesión de WebSEAL:

¶ Configuración del valor máximo de entradas simultáneas

¶ Configuración del valor de tiempo de espera de las entradas dela caché

¶ Configuración del valor de tiempo de espera de inactividad delas entradas de la caché

Configuración del valor máximo de entradas simultáneasEl parámetro max-entries, que se encuentra en la stanza[session]delarchivo de configuraciónwebseald.conf, establece el númeromáximo de entradas simultáneas en la caché de credenciales/sesiónde WebSEAL.

Este valor se corresponde con el número de inicios de sesiónsimultáneos. Cuando el tamaño de la caché alcanza este valor, seeliminan entradas de la caché, según el algoritmo″menos utilizadorecientemente″, para permitir nuevos inicios de sesión entrantes.

WebSEAL

Client

GSK CacheConfiguration Parameters- ssl-v2-timeout- ssl-v3-timeout- ssl-cache-max-sessions

Maintains:- SSL session ID

Maintains:

- Session ID info

- Credential info

WebSEAL CacheConfiguration Parameters- timeout- inactive-timeout- max-entries

GSK SSL SessionCache

WebSEALCredentials Cache

Figura 13. Parámetros de configuración de la caché de sesión


4.A

utenticaciónde

WebS

EA

L

El número predeterminado de inicios de sesión simultáneos es 4096:[session]max-entries = 4096

Configuración del valor de tiempo de espera de las entradasde la caché

El parámetrotimeout, que se encuentra en la stanza[session]delarchivo de configuraciónwebseald.conf, establece el tiempo deespera máximo de duración para una entrada en la caché decredenciales/sesión de WebSEAL.

WebSEAL almacena internamente en la caché la información decredenciales. El parámetro de tiempo de espera de la caché de lasesión dicta el tiempo durante el que la información de la credencialde autorización permanece en la memoria de WebSEAL.

El parámetro no es un tiempo de espera de inactividad. El valor secorrelaciona con una “duración de la credencial” en lugar de un“tiempo de espera de la credencial”. Su objetivo es mejorar laseguridad forzando al usuario la reautenticación cuando se alcanza ellímite de tiempo de espera especificado.

El tiempo de espera predeterminado para el inicio de la sesión (ensegundos) es 3600:[session]timeout = 3600

Configuración del valor de tiempo de espera de inactividadde las entradas de la caché

El parámetroinactive-timeout, que se encuentra en la stanza[session]del archivo de configuraciónwebseald.conf, establece elvalor del tiempo de espera de inactividad en el inicio de sesión.

El tiempo de espera predeterminado de inactividad en el inicio de lasesión (en segundos) es 600:[session]inactive-timeout = 600

Para desactivar esta función de tiempo de espera, establezca el valordel parámetro en “0”.

94 Versión 3.8

Configuración de la caché de ID de sesión SSL deGSKit

Las siguientes tareas de configuración están disponibles para lacaché de ID de sesión SSL de GSKit:

¶ Configuración del valor de tiempo de espera de las entradas dela caché

¶ Configuración del valor máximo de entradas simultáneas

Configuración del valor de tiempo de espera de las entradasde la caché

Los parámetros para establecer el tiempo de espera máximo deduración para una entrada en la caché de ID de sesión SSL de GSKitse encuentran en la stanza[ssl] del archivo de configuraciónwebseald.conf. Existen dos parámetros: uno para las conexionesSSL V2 (ssl-v2-timeout) y otro para las conexiones SSL V3(ssl-v3-timeout).

El tiempo de espera predeterminado de la sesión SSL V2 (ensegundos) es 100 (con un valor posible entre 1 y 100):[ssl]ssl-v2-timeout = 100

El tiempo de espera predeterminado de la sesión SSL V3 (ensegundos) es 7200 (con un valor posible entre 1 y 86400):[ssl]ssl-v3-timeout = 7200

Configuración del valor máximo de entradas simultáneasEl parámetrossl-max-entries, que se encuentra en la stanza[ssl] delarchivo de configuraciónwebseald.conf, establece el númeromáximo de entradas simultáneas en la caché de ID de sesión SSL deGSKit.

Este valor se corresponde con el número de inicios de sesiónsimultáneos. Cuando el tamaño de la caché alcanza este valor, seeliminan entradas de la caché, según el algoritmo menos utilizadorecientemente, para permitir nuevos inicios de sesión entrantes.


4.A

utenticaciónde

WebS

EA

L

El número predeterminado de inicios de sesión simultáneos es 4096:[ssl]ssl-max-entries = 4096

Mantenimiento del estado con cookies de sesiónUn método para mantener el estado de la sesión entre un cliente yun servidor es utilizar una cookie para retener la información de estasesión. El servidor empaqueta la información de estado para uncliente concreto en una cookie y la envía al navegador del cliente.Para cada petición nueva, el navegador se vuelve a identificarenviando la cookie (con la información sobre la sesión) de vuelta alservidor.

Las cookies de sesión ofrecen una posible solución en situaciones enlas que el cliente utiliza un navegador que renegocia su sesión deSSL después de períodos de tiempo breves. Por ejemplo, algunasversiones del navegador Microsoft Internet Explorer renegocian lassesiones de SSL cada dos o tres minutos.

La cookie de sesión sólo proporciona la reautenticación de un clientepara el servidor único que el cliente tenía anteriormente autenticadoen un período corto de tiempo (unos diez minutos). El mecanismo sebasa en una “cookie de servidor” que no se puede pasar a ningunamáquina que no sea la que ha generado la cookie.

Además, la cookie de la sesión contiene sólo un número deidentificador aleatorio que se utiliza para el índice en la caché de lasesión del servidor. No hay más información expuesta en la cookiede la sesión, ya que ésta no puede comprometer la política deseguridad.

Información sobre las cookies de sesiónWebSEAL utiliza una cookie de sesión segura específica para elservidor. Las siguientes condiciones son aplicables a este mecanismode cookies:

¶ La cookie contiene sólo información sobre la sesión; no contieneinformación sobre la identidad

96 Versión 3.8

¶ La cookie reside sólo en la memoria del navegador (no seescribe en el contenedor de cookies del disco)

¶ La cookie tiene una duración limitada (configurable)

¶ La cookie tiene parámetros de ruta de acceso y de dominio queprohíben su uso a otros servidores

Activación y desactivación de las cookies de ID de sesiónEl parámetrossl-id-sessions, que se encuentra en la stanza[session]del archivo de configuraciónwebseald.conf, activa y desactiva lascookies de sesión. Este parámetro controla si se utiliza el ID desesión SSL para mantener el inicio de sesión en los clientes queacceden mediante HTTPS. Si el parámetro se establece en “no”, seutilizan las cookies de sesión en la mayoría de métodos deautenticación.[session]ssl-id-sessions = no

Un valor de configuración “no” para este parámetro da comoresultado las siguientes condiciones en los clientes que accedenmediante HTTPS:

1. El ID de sesión SSL no se utiliza nunca como información de IDde sesión.

2. Las cookies se utilizarán para mantener las sesiones con losclientes que se autentiquen con cookies de recuperación traserror, señales de CDSSO ID, nombre de usuario y contraseña deformulario, código de paso de señal y certificados de clientes.

3. Las cookies se utilizan en los clientes de autenticación básicasólo si use-same-session = yes (consulte el apartadosiguiente). En caso contrario, se utiliza la cabecera BA para losdatos de ID de sesión.

4. La cabecera HTTP se utiliza como información de ID de sesiónen los clientes que se autentican con cabeceras HTTP.

5. La dirección IP se utiliza como información de ID de sesión enlos clientes que se autentican con direcciones IP.


4.A

utenticaciónde

WebS

EA

L

Si se utilizan cookies para mantener el estado de la sesión, la cookiese envía sólo una vez al navegador, después de iniciar la sesióncorrectamente. No obstante, algunos navegadores imponen un límiteal número de cookies en memoria que pueden almacenarsimultáneamente. En algunos entornos, las aplicaciones puedencolocar un gran número de cookies en memoria por dominio en lossistemas cliente. En este caso, cualquier cookie configurada desesión de WebSEAL o de recuperación tras error se puede sustituirfácilmente por otra cookie.

Cuando se configura WebSEAL para utilizar cookies de sesión (yquizás cookies de recuperación tras error), se puede configurar elparámetroresend-webseal-cookies, que se encuentra en la stanza[session]del archivo de configuraciónwebseald.conf, para queWebSEAL envíe la cookie de sesión y la cookie de recuperación traserror al navegador con cada respuesta. Esta acción permite asegurarque la cookie de sesión y la cookie de recuperación tras errorpermanecen en la memoria del navegador.

El parámetroresend-webseal-cookiestiene un valor predeterminadode “no”:[session]resend-webseal-cookies = no

Cambie el valor predeterminado a “yes” para enviar cookies desesión de WebSEAL y cookies de recuperación tras error con cadarespuesta.

Activación y desactivación de las mismas sesionesSe puede configurar WebSEAL para que utilice los datos de ID de lamisma sesión cuando un cliente se conecte mediante un tipo detransporte (HTTP, por ejemplo), se desconecte y vuelva a conectarsecon otro tipo de transporte (HTTPS, por ejemplo).

El parámetrouse-same-session, que se encuentra en la stanza[session]del archivo de configuraciónwebseald.conf, activa ydesactiva el reconocimiento de los datos de ID de la misma sesión.De forma predeterminada, este parámetro se establece en “no”:

98 Versión 3.8

[session]use-same-session = no

Un valor de configuración “yes” para este parámetro da comoresultado las siguientes condiciones:

1. Las cookies de sesión se utilizan para identificar los siguientestipos de clientes en las conexiones posteriores mediante otrotransporte:

a. Cookies de recuperación tras error

b. Certificados de cliente

c. Señal CDSSO ID

d. Código de paso de señal

e. Nombre de usuario y contraseña de formularios

f. Autenticación básica

2. La cabecera HTTP se utiliza para los clientes que acceden concabeceras HTTP.

3. La dirección IP se utiliza para los clientes que acceden condirecciones IP.

4. La configuraciónssl-id-sessionsse omite; el comportamiento quese obtiene es el mismo que si se establecierassl-id-sessionsen“no”.

Esta lógica es importante porque los clientes HTTP no tienen unID de sesión SSL disponible como dato de sesión.

5. Como las cookies están disponibles para los clientes de HTTP yHTTPS, no se etiquetan como cookies seguras.

Determinación de los tipos de datos de ID de sesiónválidos

El tipo de datos de sesión para un cliente que accede con un métodode autenticación concreto viene determinado por combinacionesespecíficas de los siguientes parámetros de configuración:

¶ Activación o desactivación de las cookies de sesión(ssl-id-sessions)


4.A

utenticaciónde

WebS

EA

L

¶ Activación o desactivación de la posibilidad de utilizar los datosde la misma sesión cuando un cliente cambia entre HTTP yHTTPS (use-same-session)

En la tabla siguiente se resumen los datos de ID de sesión válidospara una configuración determinada que combina los parámetrosssl-id-sessionsy use-same-session:

Clientes de HTTPS

Método deautenticación

ssl-id-sessions =yes

ssl-id-sessions = nouse-same-session =

no

use-same-session =yes ssl-id-sessions

ignored

Cookie derecuperación tras error

ID de SSL Cookie Cookie

Certificados ID de SSL Cookie Cookie

CDSSO ID de SSL Cookie Cookie

Señal ID de SSL Cookie Cookie

Formularios ID de SSL Cookie Cookie

BA ID de SSL Cabecera BA Cookie

Cabecera HTTP ID de SSL Cabecera HTTP Cabecera HTTP

Dirección IP ID de SSL Dirección IP Dirección IP

Clientes de HTTP

Método deautenticación

use-same-session = no use-same-session = yes

Cookie de recuperacióntras error

Cookie Cookie

CDSSO Cookie Cookie

Señal Cookie Cookie

Formularios Cookie Cookie

BA Cabecera BA Cookie

Cabecera HTTP Cabecera HTTP Cabecera HTTP

Dirección IP Dirección IP Dirección IP

100 Versión 3.8

Configuración de cookies de recuperación tras errorLa siguiente función de cookie de recuperación tras error (paraHTTP y HTTPS) está especialmente indicada para un cliente que seconecte a un clúster replicado de servidores WebSEAL de fondo através de un mecanismo de equilibrio de carga. El objetivo de lascookies de recuperación tras error es evitar que se tenga que repetirla autenticación cuando el servidor que tiene la sesión original con elcliente no esté disponible.

Se puede implementar un clúster WebSEAL frontal para aumentar ladisponibilidad de los recursos para un número mayor de clientes. Elmecanismo de equilibrio de carga intercepta las peticiones entrantesy las distribuye entre los servidores frontales disponibles.

Consulte el diagrama siguiente para obtener información detallada.

El cliente no conoce la configuración del servidor frontal replicado.El mecanismo de equilibrio de carga es el único punto de contactode la dirección URL solicitada. El mecanismo de equilibrio de cargaconecta un cliente con un servidor disponible (por ejemplo, WS1).Se establece el estado de la sesión con WS1 y las siguientespeticiones de ese cliente se envían a WS1.

Client

Load-balancingmechanism

WS1

WS2

WS3

Replicated Front-endWebSEAL Servers

Back-endResources

Figura 14. Ejemplo de cookie de recuperación tras error


4.A

utenticaciónde

WebS

EA

L

El problema que pueden resolver las cookies de recuperación traserror implica una situación en la que el servidor WS1 deja de estardisponible por alguna razón (por ejemplo, un error del sistema o unainterrupción de la línea por parte del administrador). Si el servidorWS1 deja de estar disponible, el mecanismo de equilibrio de cargaredirecciona la petición a uno de los otros servidores replicados(WS2 o WS3). Se perderá la correlación original de sesión acredencial. El cliente es nuevo para este servidor sustituto, ynormalmente deberá volver a autenticarse.

Puede configurar los servidores WebSEAL replicados para que cifrenlos datos de credencial del cliente en una cookie específica delservidor. La cookie se coloca en el navegador cuando se conecta porprimera vez el cliente. Si el servidor WebSEAL inicial no estádisponible temporalmente, se presenta la cookie (con la informaciónde credencial cifrada) al servidor sustituto. Los servidores WebSEALreplicados comparten una clave común que puede descifrar lainformación de credenciales. El cliente puede establecer ahora unasesión nueva con un servidor WebSEAL replicado sin que tenga quevolver a autenticarse.

El punto de referencia para la cookie es el DNS del mecanismo deequilibrio de carga. Este único punto de referencia es importante yaque la cookie es una cookie específica del servidor y no una cookieespecífica del dominio. La cookie sólo puede ser aceptada por unservidor con el mismo nombre DNS que el del servidor que hacreado la cookie. El cliente siempre realiza peticiones a través delmecanismo de equilibrio de carga. Por lo tanto, siempre se acepta lacookie y se pasa al siguiente servidor disponible durante la operaciónde recuperación tras error.

Activación de cookies de recuperación tras error

El parámetrofailover-auth, que se encuentra en la stanza[failover]del archivo de configuraciónwebseald.conf, activa o desactiva lascookies de recuperación tras error específicas del servidor:

¶ Para activar las cookies de recuperación tras error, escriba“http”, “https” o “both” (ambos).

102 Versión 3.8

¶ Para desactivar las cookies de recuperación tras error, escriba“none” (ninguno) (predeterminado).

Por ejemplo:[failover]failover-auth = https

Debe definir este parámetro en cada uno de los servidores WebSEALfrontales.

Cifrado y descifrado de los datos de credenciales

Para proteger los datos de la cookie, utilice la utilidadcdsso_key_genque proporciona WebSEAL. Esta utilidad genera unaclave simétrica que cifra los datos de credenciales en la cookie.Especifique la ubicación (nombre de ruta de acceso completa) delarchivo de claves cuando se ejecute la utilidad:

UNIX: # cdsso_key_gen <nombre-ruta>

Windows: MSDOS> cdsso_key_gen <nombre-ruta>

Ejecute la utilidad en uno de los servidores replicados y copiemanualmente el archivo de claves en cada uno de los otrosservidores replicados. Especifique esta ubicación del archivo declaves en la stanza[failover] del archivo de configuraciónwebseald.conf de cada servidor. Si no especifica ningún archivo declaves, se desactiva la función de cookies de recuperación tras errorpara ese servidor:[failover]failover-cookies-keyfile = <nombre-ruta-completa>

Puede darle al archivo de claves un nombre como, por ejemplo,ws.key.

Configuración de la duración de la cookie

El valor de duración de la cookie (en minutos) está establecido en elsiguiente parámetro:failover-cookie-lifetime = 60


4.A

utenticaciónde

WebS

EA

L

Visión general de la configuración de laautenticación

Puede activar y desactivar la autenticación para los clientes HTTP yHTTPS en base al método.

Los mecanismos de todos los métodos de autenticación soportadosen WebSEAL están configurados en la stanza[authentication-mechanisms]del archivo de configuraciónwebseald.conf. Losparámetros de los métodos de autenticación soportados son:

¶ Autenticadores locales (incorporados)

Los parámetros para los autenticadores locales especifican losarchivos DLL (Windows) o de bibliotecas (UNIX) compartidosincorporados apropiados.

¶ Autenticadores externos personalizados

WebSEAL proporciona un código de servidor de plantilla que sepuede utilizar para crear y especificar un servidor CDAS(Servicio de autenticación en dominios cruzados) externopersonalizado.

Un autenticador CDAS externo especifica la bibliotecacompartida personalizada correspondiente.

Parámetros de autenticación localLos parámetros siguientes especifican los autenticadores localesincorporados:


Autenticación básica y de formularios

passwd-ldap Acceso de cliente con nombre de usuario ycontraseña de LDAP.

Autenticación de señales

token-cdas Acceso de cliente con nombre de usuario LDAP ycódigo de paso de señal SecurID.

Autenticación de certificados de cliente

cert-ssl Acceso de cliente con certificado de cliente a travésde SSL.

104 Versión 3.8


Autenticación de cabeceras HTTP o direcciones IP

http-request Acceso de cliente mediante cabecera HTTP odirección IP especiales.

Autenticación de señal CDSSO ID

cdsso Autenticación de inicio de sesión único en dominioscruzados.

Puede utilizar la stanza[authentication-mechanisms]paraconfigurar el método de autenticación y la implementación en elsiguiente formato:<parámetro-método-autenticación> = <biblioteca-compartida>

Consulte el apartado “Referencias a la información de configuracióndetallada” en la página 90.

Parámetros de autenticación de CDAS personalizadoexterno

Los siguientes parámetros permiten especificar bibliotecascompartidas personalizadas para servidores CDAS externos:


passwd-cdas Acceso de cliente con nombre de usuario y contraseñapara un registro de terceros.

token-cdas Acceso de cliente con nombre de usuario y código depaso de señal.

cert-cdas Acceso de cliente con certificado de cliente a través deSSL.

Consulte la publicaciónTivoli SecureWay Policy Director WebSEALDeveloper Referencepara obtener más información sobre la creacióny configuración de una biblioteca compartida personalizada queimplemente un servidor CDAS.


4.A

utenticaciónde

WebS

EA

L

Configuración predeterminada para la autenticaciónde WebSEAL

De forma predeterminada, WebSEAL está establecido para autenticarclientes a través de SSL utilizando los nombres de usuario ycontraseñas de autenticación básica (BA) (registro LDAP).

Generalmente, WebSEAL está activado para los accesos TCP y SSL.Por lo tanto, una configuración típica de la stanza[authentication-mechanisms]incluye el soporte para nombres deusuario y contraseñas (registro LDAP) y soporte para certificados decliente a través de SSL.

El siguiente ejemplo representa la configuración típica de la stanza[authentication-mechanisms]para Solaris:[authentication-mechanisms]passwd-ldap = libldapauthn.socert-ssl = libsslauthn.so

Para configurar otros métodos de autenticación, agregue el parámetroapropiado con su biblioteca compartida (o módulo CDAS). Paraobtener información de configuración detallada sobre cada métodode autenticación, consulte el apartado “Referencias a la informaciónde configuración detallada” en la página 90.

Configuración de varios métodos de autenticaciónPuede modificar la stanza[authentication-mechanism]del archivode configuraciónwebseald.conf para especificar la bibliotecacompartida que se debe utilizar para cada método de autenticaciónsoportado. Las siguientes condiciones se aplican cuando seconfiguran varios métodos de autenticación:

1. Todos los métodos de autenticación pueden funcionar de formaindependiente. Se puede configurar una biblioteca compartidapara cada método soportado.

2. El métodocert-cdasprevalece sobre el métodocert-ssl cuandoambos están configurados. Debe activar uno de ellos para darsoporte a los certificados de cliente.

106 Versión 3.8

3. Sólo se utiliza un autenticador de tipo contraseña cuando hayvarios configurados. WebSEAL utiliza el siguiente orden deprioridad para resolver múltiples autenticadores de contraseñaconfigurados:

a. passwd-cdas

b. passwd-ldap

4. Se puede configurar la misma biblioteca personalizada para dosmétodos de autenticación diferentes. Por ejemplo, se puedeescribir una biblioteca compartida personalizada para procesar laautenticación del nombre de usuario/contraseña y de la cabeceraHTTP. En este ejemplo, se podrían configurar los parámetrospasswd-cdasy http-request con la misma biblioteca compartida.Es responsabilidad del desarrollador mantener el estado de lasesión y evitar conflictos entre los dos métodos.

Solicitud de inicio de sesiónWebSEAL solicita al cliente que inicie la sesión si se dan lassiguientes condiciones:

1. Un cliente sin autenticar que no pasa la comprobación deautenticación

2. Un cliente Autenticación básica o de formularios que no pasa lacomprobación de autenticación

Los siguientes tipos de clientes reciben un error “403 failure”:

1. Cuando falla la comprobación de autenticación:

a. Certificado de cliente

b. Cookie de recuperación tras error

c. CDSSO

d. Dirección IP

e. Cabecera HTTP

2. Cuando un cliente se autentica con un método desactivado porWebSEAL


4.A

utenticaciónde

WebS

EA

L

Comandos de fin de sesión y de cambio decontraseña

Policy Director proporciona los siguientes comandos para dar soportea clientes que se autentican a través de HTTP o HTTPS.

pkmslogoutLos clientes pueden utilizar el comandopkmslogout para finalizar lasesión actual si utilizan un método de autenticación que noproporciona datos de autenticación con cada petición. Por ejemplo,pkmslogout no funciona en clientes que utilizan la Autenticaciónbásica o la autenticación de dirección IP. En este caso, se debe cerrarel navegador para finalizar la sesión.

El comandopkmslogout está especialmente indicado para laautenticación mediante certificados de cliente, códigos de paso deseñal, autenticación de formularios y algunas implementaciones de laautenticación de cabeceras HTTP.

Ejecute el comando como se describe a continuación:https://www.tivoli.com/pkmslogout

El navegador muestra un formulario de fin de sesión definido en elarchivo de configuraciónwebseald.conf:[acnt-mgt]logout = logout.html

Puede modificar el archivologout.html para que se ajuste a susrequisitos.

La utilidad pkmslogout también da soporte a varias páginas derespuesta de fin de sesión cuando la arquitectura de la red requierediversas pantallas de salida para los usuarios que finalizan la sesiónen sistemas de fondo distintos.

La siguiente expresión identifica un archivo de respuesta específico:https://www.tivoli.com/pkmslogout?filename=

<archivo_fin_sesión_personalizado>

108 Versión 3.8

dondearchivo_fin_sesión_personalizadoes el nombre de archivode respuesta del fin de sesión. Este archivo debe residir en el mismodirectoriolib/html/C que contiene el archivo predeterminadologout.html y ejemplos de otros formularios HTML de respuesta.

pkmspasswdPuede utilizar este comando para cambiar la contraseña de inicio desesión cuando se utiliza la Autenticación básica (BA) o laAutenticación de formularios. Este comando es apropiado a través deHTTP o HTTPS.

Por ejemplo:https://www.tivoli.com/pkmspasswd

Para garantizar la máxima seguridad cuando se utilice BA conWebSEAL, este comando se comporta de la siguiente forma para uncliente BA:

1. Se cambia la contraseña.

2. Finaliza la sesión del usuario del cliente.

3. Cuando el cliente realiza una petición adicional, el navegadorpresenta al cliente una solicitud de BA.

4. El cliente debe volver a iniciar la sesión para continuarrealizando peticiones.

Este ejemplo sólo se aplica a los clientes que utilizan laAutenticación básica.

Configuración de la autenticación básicaLa Autenticación básica (BA) es un método estándar paraproporcionar un nombre de usuario y una contraseña al mecanismode autenticación. El protocolo HTTP define la BA y se puedeimplementar a través de HTTP y de HTTPS.

WebSEAL se configura de forma predeterminada para laautenticación a través de HTTPS mediante la Autenticación básica(BA) de nombre de usuario y contraseña.


4.A

utenticaciónde

WebS

EA

L

Activación y desactivación de la autenticación básicaEl parámetroba-auth, que se encuentra en la stanza[ba] del archivode configuraciónwebseald.conf, activa y desactiva el método deautenticación básica.

¶ Para activar el método de autenticación básica, escriba “http”,“https”, o “both” (ambos).

¶ Para desactivar el método de autenticación básica, escriba“none”.

Por ejemplo:[ba]ba-auth = https

Configuración del nombre de dominioEl nombre de dominio es el texto que se muestra en el cuadro dediálogo que aparece cuando el navegador solicita al usuario los datosde inicio de sesión.

El parámetro de configuración que establece el nombre de dominiose encuentra en la stanza[ba] del archivo de configuraciónwebseald.conf.

Por ejemplo:[ba]basic-auth-realm = Policy Director

110 Versión 3.8

Configuración del mecanismo de autenticación básicaEl parámetropasswd-ldapespecifica la biblioteca compartida que seutiliza para gestionar la autenticación del nombre de usuario y lacontraseña.

¶ En UNIX, el archivo que proporciona la función de correlaciónincorporada es una biblioteca compartida denominadalibldapauthn .

¶ En Windows, el archivo que proporciona la función decorrelación incorporada es una DLL denominadaldapauthn.

Mecanismo deautenticación

Biblioteca compartida

Solaris AIX Windows HP-UX

passwd-ldap libldapauthn.so libldapauthn.a ldapauthn.dll libldapauthn.sl

Puede configurar el mecanismo de autenticación del nombre deusuario y la contraseña especificando el parámetropasswd-ldapconel nombre específico para la plataforma del archivo de bibliotecacompartida en la stanza[authentication-mechanism]del archivo deconfiguraciónwebseald.conf. Por ejemplo:

Figura 15. Indicador de inicio de sesión de BA


4.A

utenticaciónde

WebS

EA

L

Solaris:[authentication-mechanisms]passwd-ldap = libldapauthn.so

Windows:[authentication-mechanisms]passwd-ldap = ldapauthn.dll

Condiciones de configuraciónSi se activa la Autenticación de formularios para un transportedeterminado, se omitirá la configuración de Autenticación básicapara ese transporte.

Configuración de la autenticación de formulariosPolicy Director proporciona la autenticación de formularios comouna alternativa al mecanismo estándar de Autenticación básica. Estemétodo produce un formulario de inicio de sesión de HTMLpersonalizado de Policy Director en lugar del indicador de inicio desesión estándar que resulta de la tentativa de Autenticación básica.

Cuando se utiliza el inicio de sesión basado en formularios, elnavegador no almacena en la caché la información de nombre deusuario y contraseña, como lo hace la Autenticación básica.

Activación y desactivación de la autenticación deformularios

El parámetroforms-auth, que se encuentra en la stanza[forms] delarchivo de configuraciónwebseald.conf, activa y desactiva elmétodo de autenticación de formularios.

¶ Para activar el método de autenticación de formularios, escriba“http”, “https”, o “both” (ambos).

¶ Para desactivar el método de autenticación de formularios,escriba “none”.

Por ejemplo:[forms]forms-auth = https

112 Versión 3.8

Configuración del mecanismo de autenticación deformularios

El parámetropasswd-ldapespecifica la biblioteca compartida que seutiliza para gestionar la autenticación del nombre de usuario y lacontraseña.

¶ En UNIX, el archivo que proporciona la función de correlaciónincorporada es una biblioteca compartida denominadalibldapauthn .

¶ En Windows, el archivo que proporciona la función decorrelación incorporada es una DLL denominadaldapauthn.




passwd-ldap libldapauthn.so libldapauthn.a ldapauthn.dll libldapauthn.sl

Puede configurar el mecanismo de autenticación del nombre deusuario y la contraseña especificando el parámetropasswd-ldapconel nombre específico para la plataforma del archivo de bibliotecacompartida en la stanza[authentication-mechanism]del archivo deconfiguraciónwebseald.conf. Por ejemplo:

Solaris:[authentication-mechanisms]passwd-ldap = libldapauthn.so

Windows:[authentication-mechanisms]passwd-ldap = ldapauthn.dll

Condiciones de configuraciónSi se activa la Autenticación de formularios para un transportedeterminado, se omitirá la configuración de Autenticación básicapara ese transporte.


4.A

utenticaciónde

WebS

EA

L

Personalización de los formularios HTML derespuesta

La autenticación de formularios requiere el uso de un formulario deinicio de sesión personalizado. De forma predeterminada, elformulario login.html de ejemplo se encuentra en el siguientedirectorio:<directorio-instalación>/lib/html

Puede personalizar el contenido y el diseño de este formulario. Porejemplo:

Para obtener información detallada acerca de los formularios HTMLdisponibles que se pueden personalizar, consulte el apartado “Gestiónde páginas HTML personalizadas” en la página 40.

Configuración de la autenticación de certificados decliente

WebSEAL da soporte a la comunicación segura con clientesmediante certificados digitales de cliente a través de SSL. En estemétodo de autenticación, la información de certificado (como elNombre distinguido o DN) se correlaciona con una identidad dePolicy Director.

Figura 16. Ejemplo de formulario de inicio de sesión de WebSEAL

114 Versión 3.8

Segundo plano: Autenticación mutua mediantecertificados

La autenticación mediante certificados digitales se lleva a cabo endos fases:

¶ WebSEAL se identifica ante los clientes SSL con su certificadode servidor

¶ WebSEAL utiliza su base de datos de certificados raíz de CA(entidad emisora de certificados) para validar los clientes queacceden con los certificados de cliente

1. Un cliente de SSL solicita una conexión con un servidorWebSEAL.

2. Como respuesta, WebSEAL envía su clave pública mediante uncertificado de cliente firmado. Una entidad emisora decertificados (CA) de terceros ha firmado previamente estecertificado.

3. El cliente comprueba si el emisor del certificado es fiable y sepuede aceptar. El navegador del cliente contiene habitualmenteuna lista de certificados raíz de CA fiables. Si la firma delcertificado de WebSEAL coincide con uno de estos certificadosraíz, el servidor es fiable.

Request

Client

Response

WebSEAL Server

"I can trust who you are."

verisign

www.tivoli.com

Server'sDigital ID

belsigncertisignentrustverisign

...

Browser's CARoot Certificates

Figura 17. El cliente valida el certificado de WebSEAL


4.A

utenticaciónde

WebS

EA

L

4. Si no hay ninguna coincidencia con esta firma, el navegadorinforma al usuario de que este certificado ha sido emitido poruna entidad emisora de certificados desconocida. A partir deaquí, es responsabilidad del usuario aceptar o rechazar elcertificado.

5. Si la firma coincide con una entrada de la base de datos decertificados raíz del navegador, las claves de sesión se negociande forma segura entre el cliente y el servidor WebSEAL.

El resultado final de este proceso es un canal seguro a travésdel cual el cliente se puede autenticar (por ejemplo, mediante elnombre de usuario y la contraseña). Después de unaautenticación correcta, el cliente y el servidor puede seguircomunicándose de forma segura a través de este canal.

6. Ahora el cliente envía su certificado de clave pública al servidorWebSEAL.

7. WebSEAL intenta encontrar la firma del certificado de clienteen una CA conocida. Del mismo modo que un navegador decliente, el servidor WebSEAL mantiene una lista de certificadosraíz de CA fiables en su base de datos de claves.

8. Si no hay ninguna coincidencia con esta firma, WebSEALgenerará un código de error de SSL y lo enviará al cliente.

9. Si hay alguna coincidencia con la firma, el cliente es fiable. Selleva a cabo la autenticación del cliente y se proporciona unaidentidad de Policy Director.

10. Las claves de sesión se negocian de forma segura entre elcliente y el servidor WebSEAL. El resultado final de esteproceso es un canal de comunicación seguro y fiable entre elcliente y el servidor autenticados mutuamente.

El certificado de prueba de WebSEALDurante la instalación, WebSEAL contiene un certificado de pruebaautofirmado de servidor. Aunque este certificado de prueba permite aWebSEAL responder a una petición de navegador habilitado paraSSL, el navegador (que no contiene ningún certificado raíz de CAapropiado) no lo puede verificar. Debido a que la clave privada para

116 Versión 3.8

este certificado predeterminado está incluida en cada distribución deWebSEAL, este certificado no ofrece ninguna comunicaciónverdaderamente segura.

Para garantizar una comunicación segura a través de SSL, es muyimportante registrar y obtener un certificado de servidor de sitioúnico desde una entidad emisora de certificados (CA) fiable. Puedeutilizar la utilidad iKeyman de GSKit para generar una petición decertificado que se enviará a la CA. También puede utilizariKeymanpara instalar y etiquetar el certificado de sitio nuevo. Utilice elparámetrowebseal-cert-keyfile-labelen la stanza[ssl] del archivode configuraciónwebseald.conf para designar el certificado comoel certificado de servidor WebSEAL activo (este valor anulacualquier certificado designado como “predeterminado” en la base dedatos del archivo de claves).

Si necesita certificados diferentes para otras situaciones (porejemplo, para conexiones (junctions) autenticadas mutuamente),puede utilizar la utilidadiKeyman para crear, instalar y etiquetarestos certificados adicionales.

Consulte el apartado “Configuración de los parámetros de la base dedatos de claves para WebSEAL” en la página 46.

Consulte el apartado “Gestión de certificados con iKeyman” en lapágina 279.

Activación y desactivación de la autenticación decertificados

Puede especificar la forma en que WebSEAL gestionará laautenticación mediante certificados de cliente a través de SSLespecificando el parámetroaccept-client-certs, que se encuentra enla stanza[certificate] del archivo de configuraciónwebseald.conf.

De forma predeterminada, WebSEAL no acepta certificados decliente:[certificate]accept-client-certs = never


4.A

utenticaciónde

WebS

EA

L

Los valores adicionales para este parámetro incluyenoptional yrequired.

La tabla siguiente muestra una lista que describe los valorespermitidos para el parámetroaccept-client-certs:

Valor Descripción

never No aceptar certificados X.509 de clientes.

optional Solicitar un certificado X.509 a los clientes y utilizarla autenticación basada en certificados, si seproporciona un certificado.

required Solicitar un certificado X.509 a los clientes y utilizarla autenticación basada en certificados. Si el clienteno presenta ningún certificado, no permitir laconexión.

Configuración del mecanismo de autenticación decertificados

El parámetrocert-ssl especifica la biblioteca compartida para lacorrelación de información de autenticación de certificados.

¶ En UNIX, el archivo que proporciona la función de correlaciónincorporada es una biblioteca compartida denominadalibsslauthn.

¶ En Windows, el archivo que proporciona la función decorrelación incorporada es una DLL denominadasslauthn.

Mecanismodeautenticación



cert-ssl libsslauthn.so libsslauthn.a sslauthn.dll libsslauthn.sl

Puede configurar el mecanismo de autenticación de certificadosespecificando el parámetrocert-ssl con el nombre específico para laplataforma del archivo de biblioteca compartida en la stanza[authentication-mechanism]del archivo de configuraciónwebseald.conf.

118 Versión 3.8

Solaris:[authentication-mechanisms]cert-ssl= libsslauthn.so

Windows:[authentication-mechanisms]cert-ssl = sslauthn.dll

La correlación predeterminada que proporciona el archivo debiblioteca compartida correlaciona un DN de certificado con un DNde LDAP.

Condiciones de configuraciónSi la gestión de certificados de cliente se define como “required”, seomitirá el resto de valores de autenticación para los clientes HTTPS.

Configuración de autenticación de cabecera HTTPPolicy Director da soporte a la autenticación mediante la informaciónde cabecera HTTP personalizada proporcionada por el cliente o unagente proxy.

Este mecanismo requiere un función de correlación (una bibliotecacompartida) que correlaciona los datos de cabecera fiables(autenticados previamente) con una identidad de Policy Director.WebSEAL puede tomar esta identidad y crear una credencial para elusuario.

WebSEAL presume que los datos de cabecera HTTP se hanautenticado previamente. Por ello, es recomendable que seimplemente este método exclusivamente, sin ningún otro método deautenticación activado. Es posible imitar los datos de cabecera HTTPpersonalizados.

De forma predeterminada, esta biblioteca compartida se crea paracorrelacionar datos de cabeceras de proxy Entrust.


4.A

utenticaciónde

WebS

EA

L

Activación y desactivación de la autenticación decabeceras HTTP

El parámetrohttp-headers-auth, que se encuentra en la stanza[http-headers] del archivo de configuraciónwebseald.conf, activay desactiva el método de autenticación de cabeceras HTTP.

¶ Para activar el método de autenticación de cabeceras HTTP,escriba “http”, “https”, o “both” (ambos).

¶ Para desactivar el método de autenticación de cabeceras HTTP,escriba “none”.

Por ejemplo:[http-headers]http-headers-auth = https

Especificación de tipos de cabeceraDebe especificar todos los tipos de cabecera HTTP soportados en lastanza[auth-headers] del archivo de configuraciónwebseald.conf.[auth-headers]header = <tipo-cabecera>

De forma predeterminada, esta biblioteca compartida incorporadaestá codificada de forma que no se puede modificar para dar soportea datos de cabecera de proxy Entrust.[auth-headers]header = entrust-client

Debe personalizar este archivo para autenticar otros tipos de datos decabecera especiales y, de forma opcional, correlacionar estos datoscon una identidad de Policy Director. Consulte la publicaciónTivoliSecureWay Policy Director WebSEAL Developer Referenceparaobtener información sobre recursos API.

Configuración del mecanismo de autenticación decabeceras HTTP

El parámetrohttp-request especifica la biblioteca compartida para lacorrelación de información de autenticación de cabeceras HTTP.

120 Versión 3.8

¶ En UNIX, el archivo que proporciona la función de correlaciónincorporada es una biblioteca compartida denominadalibhttpauthn .

¶ En Windows, el archivo que proporciona la función decorrelación incorporada es una DLL denominadahttpauthn .




http-request libhttpauthn.so libhttpauthn.a httpauthn.dll libhttpauthn.sl

De forma predeterminada, esta biblioteca compartida incorporadaestá codificada de forma que no se puede modificar paracorrelacionar datos de cabecera de proxy Entrust con una identidadválida de Policy Director. Debe personalizar este archivo paraautenticar otros tipos de datos de cabecera especiales y, de formaopcional, correlacionar estos datos con una identidad de PolicyDirector. Consulte la publicaciónTivoli SecureWay Policy DirectorWebSEAL Developer Referencepara obtener información sobrerecursos API.

Puede configurar el mecanismo de autenticación de cabeceras HTTPespecificando el parámetrohttp-request con el nombre específicopara la plataforma del archivo de biblioteca compartida en la stanza[authentication-mechanism]del archivo de configuraciónwebseald.conf.

Por ejemplo:

Solaris:[authentication-mechanisms]http-request = libhttpauthn.so

Windows:[authentication-mechanisms]http-request = httpauthn.dll


4.A

utenticaciónde

WebS

EA

L

Condiciones de configuración1. Las cookies de ID de sesión no se utilizan para mantener el

estado sissl-id-sessions = no. El valor de cabecera exclusiva seutiliza para mantener el estado.

2. Si el cliente encuentra un error de autorización, recibe unapágina de “No autorizado” (HTTP 403).

Configuración de autenticación de direcciones IPPolicy Director da soporte a la autenticación a través de la direcciónIP que proporciona el cliente.

Activación y desactivación de la autenticación dedirecciones IP

El parámetroipaddr-auth , que se encuentra en la stanza[ipaddr]del archivo de configuraciónwebseald.conf, activa y desactiva elmétodo de autenticación de direcciones IP.

¶ Para activar el método de autenticación de direcciones IP, escriba“http”, “https”, o “both” (ambos).

¶ Para desactivar el método de autenticación de direcciones IP,escriba “none”.

Por ejemplo:[ipaddr]ipaddr-auth = https

Configuración del mecanismo de autenticación dedirecciones IP

La autenticación mediante una dirección IP requiere una bibliotecacompartida personalizada. Utilice el parámetrohttp-request paraesta biblioteca compartida.

Configuración de la autenticación de señalesPolicy Director da soporte a la autenticación a través del código depaso de señal que proporciona el cliente.

122 Versión 3.8

Activación y desactivación de la autenticación deseñales

El parámetrotoken-auth, que se encuentra en la stanza[token] delarchivo de configuraciónwebseald.conf, activa y desactiva elmétodo de autenticación de señales.

¶ Para activar el método de autenticación de señales, escriba“http”, “https”, o “both” (ambos).

¶ Para desactivar el método de autenticación de señales, escriba“none”.

Por ejemplo:[token]token-auth = https

Configuración del mecanismo de autenticación deseñales

El parámetrotoken-cdasespecifica la biblioteca compartida para lacorrelación de información de autenticación de códigos de paso deseñales.

¶ En UNIX, el archivo que proporciona la función de correlaciónincorporada es una biblioteca compartida denominadalibtokenauthn.

¶ En Windows, el archivo que proporciona la función decorrelación incorporada es una DLL denominadatokenauthn.




token-cdas libtokenauthn.so libtokenauthn.a tokenauthn.dll libtokenauthn.sl

De forma predeterminada, esta biblioteca compartida incorporadaestá codificada de forma que no se puede modificar paracorrelacionar datos de código de paso de señal SecurID. Puedepersonalizar este archivo para autenticar otros tipos de datos deseñales especiales y, de forma opcional, correlacionar estos datos conuna identidad de Policy Director. Consulte la publicaciónTivoli


4.A

utenticaciónde

WebS

EA

L

SecureWay Policy Director WebSEAL Developer Referenceparaobtener información sobre recursos API.

Puede configurar el mecanismo de autenticación de señalesespecificando el parámetrotoken-cdascon el nombre específico parala plataforma del archivo de biblioteca compartida en la stanza[authentication-mechanism]del archivo de configuraciónwebseald.conf.

Por ejemplo:

Solaris:[authentication-mechanisms]token-cdas = libtokenauthn.so

Windows:[authentication-mechanisms]token-cdas = tokenauthn.dll

Soporte para Multiplexing Proxy AgentsPolicy Director proporciona soluciones para proteger las redes queutilizan un MPA (Multiplexing Proxy Agent).

Los SPA (Standard Proxy Agents) son gateways que dan soporte asesiones por cliente entre clientes y el servidor de origen a través deSSL o HTTP. WebSEAL puede aplicar la autenticación SSL o HTTPnormal a estas sesiones por cliente.

Los MPA (Multiplexing Proxy Agents) son gateways que alojanvarios accesos de cliente. Estos gateways se denominan gatewaysWAP cuando los clientes acceden a través de WAP (Wireless AccessProtocol). Los gateways establecen un solo canal autenticado con elservidor de origen y utilizan un “túnel” para todas las peticiones decliente y las respuestas a través de este canal.

Para WebSEAL, la información a través de este canal apareceinicialmente como peticiones múltiples de un cliente. WebSEAL

124 Versión 3.8

debe distinguir entre la autenticación del servidor MPA y laautenticación adicional de cada cliente individual.

Puesto que WebSEAL mantiene una sesión autenticada para el MPA,debe mantener simultáneamente sesiones aparte para cada cliente.Por lo tanto, los datos de sesión y el método de autenticación que seutilizan para el MPA deben ser distintos (diferentes) de los datos deautenticación y el método de autenticación que utiliza cada cliente.

Métodos de autenticación y tipos de datos de sesiónválidos

El tipo de datos de sesión que se utiliza de MPA a WebSEAL debeser distinto (diferente) del tipo de datos de sesión que se utiliza decliente a WebSEAL. En la tabla siguiente se muestran los tipos desesión válidos para el MPA y el cliente:

Tipos de sesión válidos

De MPA a WebSEAL De cliente a WebSEAL

ID de sesión SSL

Cabecera HTTP Cabecera HTTP

Cabecera BA Cabecera BA

Dirección IP

ClientB

MPAGateway

� multiple sessions over single SSL channel� MPA authenticates to WebSEAL� MPA has membership in webseal-mpa-servers

group

WebSEALServer

ClientA

ClientC

A B C

� clients authenticate to WebSEAL

Figura 18. Comunicación a través de un gateway MPA


4.A

utenticaciónde

WebS

EA

L

Tipos de sesión válidos


Cookie Cookie

¶ El cliente no puede utilizar un ID de sesión SSL como tipo dedato de sesión.

¶ Por ejemplo, si el MPA utiliza una cabecera BA para el tipo dedato de sesión, las opciones del cliente para el tipo de dato desesión sólo pueden ser la cabecera HTTP y la cookie.

¶ Si el MPA utiliza una cabecera HTTP para los datos de sesión,el cliente puede utilizar un tipo de cabecera HTTP diferente.

¶ La cookie específica del servidor contiene sólo informaciónsobre la sesión; no contiene información sobre la identidad.

¶ Si está activado el soporte MPA, la función dessl-id-sessionscambia. Normalmente, sissl-id-sessions=yes, sólo se utiliza elID de sesión SSL para mantener las sesiones de los clientesHTTPS. Para que el MPA pueda mantener una sesión con un IDde sesión SSL y tener clientes manteniendo sesiones con otrométodo, se debe eliminar esta restricción. Consulte también elapartado “Determinación de los tipos de datos de ID de sesiónválidos” en la página 99.

El método de autenticación que se utiliza de MPA a WebSEAL debeser distinto (diferente) del método de autenticación que se utiliza decliente a WebSEAL. En la tabla siguiente se muestran los métodosde autenticación válidos para el MPA y el cliente:

Tipos de autenticación válidos


Autenticación básica Autenticación básica

Formularios Formularios

Señal Señal

Cabecera HTTP Cabecera HTTP

Certificados

126 Versión 3.8

Tipos de autenticación válidos


Dirección IP

¶ Por ejemplo, si el MPA utiliza la Autenticación básica, lasopciones del cliente para los métodos de autenticación sólopueden ser de cabeceras HTTP, formularios y señales.

¶ Los métodos de autenticación de direcciones IP y de certificadosno pueden ser utilizados por el cliente.

¶ Normalmente, si se activa la autenticación de formularios (o deseñales) para un transporte determinado, la autenticación básicase desactivará automáticamente para ese transporte (consulte elapartado “Configuración del mecanismo de autenticación básica”en la página 111. Si está activado el soporte MPA, estarestricción se eliminará. Por ejemplo, esto permite al MPAiniciar la sesión con autenticación de formularios (o de señales),mientras que los clientes pueden iniciar la sesión conautenticación básica a través del mismo transporte.

Flujo de procesos de autenticación para MPA yclientes múltiples

1. El administrador de WebSEAL lleva a cabo las siguientes tareasde configuración preliminar:

¶ Activar el soporte para los MPA (Multiplexing ProxyAgents)

¶ Crear una cuenta de Policy Director para el gateway MPAespecífico

¶ Agregar esta cuenta MPA al grupowebseal-mpa-servers

2. Los clientes se conectan al gateway MPA.

3. El gateway convierte la petición en una petición HTTP.

4. El gateway autentica el cliente.

5. El gateway establece una conexión con WebSEAL con lapetición del cliente.


4.A

utenticaciónde

WebS

EA

L

6. El MPA se autentica en WebSEAL (utilizando un métododistinto que el del cliente) y se crea una identidad para el MPA(que ya tiene una cuenta de WebSEAL).

7. WebSEAL verifica que el MPA es miembro del grupowebseal-mpa-servers.

8. Se crea una credencial para el MPA y se etiqueta como un tipoMPA especial en la caché.

Aunque esta credencial MPA acompaña a todas las futuraspeticiones del cliente, no se utiliza para las comprobaciones deautorización de estas peticiones.

9. Ahora WebSEAL necesita identificar al propietario de lapetición.

El MPA puede distinguir los distintos clientes para dirigircorrectamente las indicaciones de inicio de sesión.

10. El cliente inicia la sesión y se autentica utilizando un métododistinto del tipo de autenticación utilizado por el MPA.

11. WebSEAL crea una credencial a partir de los datos deautenticación del cliente.

12. El tipo de datos de sesión que utiliza cada cliente debe serdistinto del tipo de datos de sesión que utiliza el MPA.

13. Authorization Service permite o rechaza el acceso a los objetosprotegidos en base a la credencial del usuario y los permisosACL del objeto.

Activación y desactivación de la autenticación deMPA

El parámetrompa, que se encuentra en la stanza[mpa] del archivode configuraciónwebseald.conf, activa y desactiva el método deautenticación de MPA.

¶ Para activar el método de autenticación de MPA, escriba “yes”.

¶ Para desactivar el método de autenticación de MPA, escriba“no”.

Por ejemplo:

128 Versión 3.8

[mpa]mpa = yes

Creación de una cuenta de usuario para el MPAConsulte las publicacionesTivoli SecureWay Policy Director BaseGuía de administracióny Tivoli SecureWay Policy Director WebPortal Manager Guía de administraciónpara obtener informaciónacerca de la creación de cuentas de usuario.

Adición de la cuenta de MPA en el grupowebseal-mpa-servers

Consulte las publicacionesTivoli SecureWay Policy Director BaseGuía de administracióny Tivoli SecureWay Policy Director WebPortal Manager Guía de administraciónpara obtener másinformación acerca de la gestión de grupos.

Limitaciones de la autenticación de MPAEste release de Policy Director sólo da soporte a un MPA porservidor WebSEAL.


4.A

utenticaciónde

WebS

EA

L

130 Versión 3.8

Soluciones de inicio de sesiónen dominios cruzados

Cuando se implementa WebSEAL como servidor proxy paraproporcionar protección a un dominio seguro, a menudo se debenproporcionar soluciones para un inicio de sesión único en losrecursos. En este capítulo se describen dos soluciones de inicio desesión único en dominios cruzados.

Índice de temas:

¶ “Configuración de la autenticación de CDSSO” en la página 131

¶ “Configuración del inicio de sesión único de comunidadelectrónica” en la página 138

Configuración de la autenticación de CDSSOEl Inicio de sesión único en dominios cruzados (CDSSO) de PolicyDirector proporciona un mecanismo para transferir credenciales deusuario a través de múltiples dominios seguros. CDSSO permite alos usuarios Web realizar un inicio de sesión único y moverse sinproblemas entre dos dominios seguros separados. El mecanismo deautenticación de CDSSO no se apoya en un Servidor maestro deautenticación (véase SSO de comunidad electrónica).

CDSSO da soporte a los objetivos de la arquitectura de red escalableal permitir la integración de varios dominios seguros. Por ejemplo,se puede configurar una gran extranet corporativa con dos o más

5


5.S

oluc.de

iniciode

ses.en

dominios

cruzados

dominios únicos, cada uno con sus propios usuarios y espacio deobjetos. CDSSO permite el movimiento de usuarios entre losdominios con un inicio de sesión único.

Cuando un usuario realiza una petición a un recurso ubicado en otrodominio, el mecanismo CDSSO transfiere una señal de identidad deusuario cifrada del primer dominio al segundo. El segundo dominiotendrá ahora la identidad del usuario (como autenticado en el primerdominio) y el usuario no se verá forzado a iniciar otra sesión.

Integración de una biblioteca compartida CDMFpersonalizada

En muchos casos de CDSSO, es posible que la correlación unívocapredeterminada entre los usuarios en distintos dominios no sirva paratodos los requisitos de despliegue.

Cross Domain Mapping FrameWork (CDMF) es una interfaz deprogramación que permite crear una biblioteca compartidapersonalizada para gestionar atributos de usuarios ampliados yproporcionar servicios de correlación para la identidad del usuario.

La interfaz de programación CDMF ofrece una gran flexibilidad parapersonalizar la correlación de identidades de usuario y gestionar losatributos de usuario.

Flujo de procesos de autenticación para CDSSO conCDMF

La siguiente descripción del flujo de procesos se ilustra en laFigura 19.

1. Cualquier usuario que desee participar en varios dominios debetener una cuenta de usuario válida en el dominio principal y unaidentidad que se pueda correlacionar en una cuenta válida decada uno de los dominios remotos participantes.

Un usuario no puede invocar la funcionalidad de CDSSO sinautenticarse inicialmente en un dominio seguro inicial (A) quecontenga la cuenta del usuario.

132 Versión 3.8

2. El usuario realiza una petición para acceder a un recurso deldominio B a través de un vínculo personalizado en una páginaWeb.

El vínculo contiene una expresión CDSSO especial:/pkmscdsso?<URL-destino>

Por ejemplo:/pkmscdsso?https://www.domainB.com/index.html

3. La petición es procesada en primero lugar por el servidorWebSEAL en el dominio A. WebSEAL crea una señal deautenticación que contiene la identidad de Policy Director delusuario (nombre corto), el dominio actual (“A”), informaciónadicional del usuario y la indicación de fecha y hora.

La información de usuario adicional se obtiene mediante unallamada a la biblioteca compartida CDMF personalizada(cdmf_get_usr_attributes). Esta biblioteca proporciona atributosde usuario que pueden ser utilizados por el dominio B durante elproceso de correlación de usuarios.

WebSEAL cifra mediante DES triple estos datos de señal con laclave simétrica generada por la utilidadcdsso_key_gen. Secomparte y almacena este archivo de claves en la stanza[cdsso-peers]del archivo de configuraciónwebseald.conf delos servidores WebSEAL del dominio A y el dominio B.

La señal contiene una indicación de fecha y hora configurable(authtoken-lifetime) que define la duración de la señal. Laindicación de fecha y hora, cuando se configura correctamente,puede evitar los ataques de respuestas.

4. El servidor WebSEAL del dominio A redirige la petición más laseñal cifrada de vuelta al navegador y, a continuación, al servidorWebSEAL del dominio B (redirección de HTTP).

5. El servidor WebSEAL del dominio B utiliza su versión delmismo archivo de claves para descifrar y validar la señal como sillegara del dominio en cuestión.

6. En estos momentos, el servidor WebSEAL del dominio B llama auna biblioteca de mecanismo de autenticación de CDSSO. Como


5.S

oluc.de

iniciode

ses.en

dominios

cruzados

respuesta, esta biblioteca CDSSO llama a la biblioteca CDMFpersonalizada, que es la que ejecuta la correlación de usuarios(cdmf_map_usr).

La biblioteca CDMF pasa la identidad del usuario, yopcionalmente información adicional de atributos de usuarios, ala biblioteca CDSSO. La biblioteca CDSSO utiliza estainformación para crear una credencial.

7. El servicio de autorización del dominio B permite o rechaza elacceso a los objetos protegidos en base a la credencial delusuario y los permisos ACL específicos asociados con los objetossolicitados.

Activación y desactivación de la autenticación deCDSSO

El parámetrocdsso-auth, que se encuentra en la stanza[cdsso]delarchivo de configuraciónwebseald.conf, activa y desactiva elmétodo de autenticación de CDSSO.

WebSEALA

single sign-onClient

Domain A

/

WebSEALB

Domain B

/

� Client clicks on link to Domain B.� WebSEAL A CDSSO uses CDMF library to get

additional user information. Then builds andsends encrypted ID token with request.

� WebSEAL B decrypts and validates token� WebSEAL B CDSSO calls CDMF shared

library to map the user identity.� Credential is built and client participates in

Domain B

SSL

CDMFSharedLibrary

CDMFSharedLibrary

CDSSOLibrary

/pkmscdsso

Figura 19. Proceso de inicio de sesión único en dominios cruzados con CDMF

134 Versión 3.8

¶ Para activar el método de autenticación de CDSSO, escriba“http”, “https”, o “both” (ambos).

¶ Para desactivar el método de autenticación de CDSSO, escriba“none”.

Por ejemplo:[cdsso]cdsso-auth = https

Configuración del mecanismo de autenticación deCDSSO

El parámetro de configuracióncdssoespecifica la bibliotecacompartida codificada de forma que no se pueda modificar paracorrelacionar la información de autenticación.

¶ En UNIX, el archivo que proporciona la función de correlaciónincorporada es una biblioteca compartida denominadalibcdssoauthn.

¶ En Windows, el archivo que proporciona la función decorrelación incorporada es una DLL denominadacdssoauthn.




cdsso libcdssoauthn.so libcdssoauthn.a cdssoauthn.dll libcdssoauthn.sl

Puede configurar el mecanismo de autenticación de CDSSOespecificando el parámetrocdssocon el nombre específico para laplataforma del archivo de biblioteca compartida en la stanza[authentication-mechanism]del archivo de configuraciónwebseald.conf.

Por ejemplo:

Solaris:[authentication-mechanisms]cdsso = libcdssoauthn.so


5.S

oluc.de

iniciode

ses.en

dominios

cruzados

Windows:[authentication-mechanisms]cdsso = cdssoauthn.dll

Cifrado de los datos de la señal de autenticaciónWebSEAL debe cifrar los datos de autenticación ubicados en la señalmediante una clave generada por la utilidadcdsso_key_gen. Debe“sincronizar” esta clave compartiendo el archivo de claves con todoslos servidores WebSEAL de cada uno de los dominios participantes.Todos los servidores WebSEAL participantes de cada dominio debenutilizar la misma clave.

Nota: la creación y distribución de archivos de claves no formaparte del proceso CDSSO de Policy Director.

La utilidad cdsso_key_genprecisa que se especifique la ubicación(nombre de ruta de acceso completa) del archivo de claves cuando seejecute la utilidad:

UNIX: # cdsso_key_gen <nombre-ruta-completa>

Windows: MSDOS> cdsso_key_gen <nombre-ruta-completa>

Especifique esta ubicación del archivo de claves en la stanza[cdsso-peers]del archivo de configuraciónwebseald.conf delservidor WebSEAL que participa en cada dominio. El formatoincluye el nombre de máquina WebSEAL y la ubicación del archivode claves:[cdsso-peers]<nombre-máquina-webseal> = <ubicación-archivo-claves>

Ejemplo de configuración del Dominio A:[cdsso-peers]www.domainB.com = <nombre-ruta>/A-B.key

Ejemplo de configuración del Dominio B:[cdsso-peers]www.domainA.com = <nombre-ruta>/A-B.key

136 Versión 3.8

En el ejemplo anterior, el archivo A-B.key se generaría en unamáquina (WebSEAL A, por ejemplo) y se copiaría de una formamanual (y segura) en la otra máquina (WebSEAL B, por ejemplo).

Configuración de la indicación de fecha y hora de laseñal

La señal contiene una indicación de fecha y hora configurable quedefine la duración de la señal de identidad. Cuando caduca laindicación de fecha y hora, se considera que la señal no es válida,por lo que no se utiliza. La indicación de fecha y hora se utiliza paraevitar los ataques de respuestas al establecer un valor lo bastantecorto para evitar que se robe la señal y se responda durante superíodo de duración.

El parámetroauthtoken-lifetime, que se encuentra en la stanza[cdsso]del archivo de configuraciónwebseald.conf, establece elvalor de la duración de la señal. El valor se expresa en segundos. Elvalor predeterminado es 180:[cdsso]authtoken-lifetime = 180

Debe tener en cuenta las diferencias horarias entre los dominiosparticipantes.

Expresión de vínculos HTML de CDSSOLos vínculos HTML a los recursos de un dominio seguro secundariodeben contener una expresión CDSSO especial:/pkmscdsso?<URL-destino>

Por ejemplo:/pkmscdsso?https://www.domainB.com/index.html

Protección de la señal de autenticaciónMientras la señal de autenticación no contenga información deautenticación (como nombre de usuario y contraseña), no contendráuna identidad de usuario que sea fiable en el dominio de recepción.La propia señal se debe proteger contra robo y respuesta.


5.S

oluc.de

iniciode

ses.en

dominios

cruzados

La señal está protegida contra robo a través del uso de SSL paraproteger las comunicaciones entre los servidores WebSEAL y losusuarios. La señal podría robarse del historial del navegador delusuario. La indicación de fecha y hora de la señal debería ser lobastante corta para que fuera poco probable que se pudiera robar laseñal y reproducirla durante la duración de la señal.

Sin embargo, las señales caducadas en cuanto a su indicación defecha y hora siguen siendo vulnerables a los ataques criptográficos.Si se descubre la clave utilizada para cifrar la señal o si secompromete de alguna otra forma, algún usuario malintencionadopodría crear sus propias señales.

Éstas se podrían insertar en un “flujo pseudo-CDSSO”. No sepodrían distinguir de las señales de autenticación reales para losservidores WebSEAL que participan en el dominio CDSSO. Por estemotivo, las claves utilizadas para proteger las señales se debengestionar también con cuidado y se deben modificar regularmente.

Configuración del inicio de sesión único decomunidad electrónica

El inicio de sesión único de comunidad electrónica es otraimplementación de la autenticación de dominios cruzados en unentorno de Policy Director. El objetivo de la autenticación dedominios cruzados es permitir el acceso de los usuarios a losrecursos, a través de varios servidores en varios dominios, sinnecesidad de repetir la autenticación.

Una “comunidad electrónica” es un grupo de dominios distintos(Policy Director o DNS) que participan en una relación empresarial.Estos dominios participantes se pueden configurar como parte de unaempresa (quizás utilizando nombres DNS diferentes, por motivosgeográficos), o como empresas distintas con una relación compartida(por ejemplo, oficinas de la compañía, una empresa de seguros o unaempresa de gestión financiera).

138 Versión 3.8

En cada caso, siempre hay un dominio que se designa como dominio“inicial” o “propietario”. En el caso de empresas participantes, eldominio inicial posee los acuerdos empresariales que gobiernan lacomunidad electrónica.

En ambos casos, la información de autenticación sobre los usuariosque participan en la comunidad electrónica (incluidos los nombres deusuario y las contraseñas utilizados para la autenticación) semantiene en el dominio inicial. Esta disposición permite tener unúnico punto de referencia para cuestiones de administración, como,por ejemplo, las llamadas al escritorio de ayuda dentro de lacomunidad electrónica, que hacen todas referencia al dominio inicial.

Otra posibilidad es utilizar Web Portal Manager de Policy Directorpara delegar la gestión de esta información, de manera que losdominios participantes tengan responsabilidades en la administraciónde sus propios usuarios.

En el siguiente diagrama se muestra un ejemplo de una comunidadelectrónica con dos dominios participantes: dominio A (dA.com) ydominio B (dB.com). En este ejemplo, el dominio A representa eldominio inicial o propietario. El dominio B es un dominioparticipante o “remoto”.


5.S

oluc.de

iniciode

ses.en

dominios

cruzados

El dominio inicial es “propietario” de los usuarios —esto es,controla la información de autenticación de los usuarios.Independientemente de dónde haga el usuario la petición de recursos,el dominio inicial siempre es el dominio donde el usuario se tieneque autenticar.

La autenticación se produce en un servidor maestro de autenticación(MAS)—un servidor (o conjunto de servidores replicados) que seencuentra en el dominio inicial y que está configurado paraautenticar todos los usuarios. El diagrama representa el MAS comomas.dA.com. La labor del MAS debe estar restringida a proporcionarservicios de autenticación. El MAS no debe contener recursos queestén disponibles a otros usuarios.

Después de que el usuario se ha autenticado correctamente en elMAS, el MAS genera una señal de “garantización”. Esta señal sepasa de nuevo al servidor en el que el usuario está realizando la

Client

Domain A Domain 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

Figura 20. El modelo de comunidad electrónica

140 Versión 3.8

petición. El servidor considera esta señal de “garantización” comoprueba de que el usuario se ha autenticado correctamente en el MASy puede participar en la comunidad electrónica.

La transferencia de información entre los dominios de la comunidadelectrónica se describe en detalle en el apartado “Flujo de procesosde la comunidad electrónica” en la página 142.

Características y requisitos de la comunidadelectrónica

¶ El modelo da soporte al acceso a través de direcciones URLdirectas (marcadores) a los recursos. Esta característica contrastacon el modelo CDSSO que se basa en un vínculopkmscdssoespecialmente configurado (consulte el apartado “Configuraciónde la autenticación de CDSSO” en la página 131).

¶ La implementación de la comunidad electrónica requiere laconfiguración consistente de todos los servidores WebSEAL entodos los dominios que participan en la comunidad electrónica.

¶ Todos los usuarios que participan en la comunidad electrónica seautentican en un único servidor maestro de autenticación (MAS)que se encuentra en el dominio inicial.

¶ La implementación de la comunidad electrónica permite laautenticación “local” en dominios remotos, si el usuario no tieneuna cuenta válida con el MAS (por ejemplo, los usuarios quepertenecen al dominio B pero que no participan en la comunidadelectrónica de dominio A-dominio B).

Un usuario que no pasa la autenticación con el MAS al solicitarun recurso en un dominio no MAS (pero que sí participa) tienela opción de autenticarse en el servidor local en el que se estárealizando la petición.

¶ El MAS (y los otros servidores seleccionados finalmente en losdominios remotos) “garantizan” la identidad autenticada delusuario.

¶ Se utilizan cookies específicas del dominio para identificar alservidor que puede proporcionar servicios de “garantización”. Deesta forma, los servidores de un dominio remoto pueden solicitar


5.S

oluc.de

iniciode

ses.en

dominios

cruzados

información de “garantización” de forma local. El contenidocifrado de las cookies de la comunidad electrónica no incluyeinformación de seguridad ni de identidad de usuarios.

¶ Se utilizan señales especiales para pasar la identidad de usuario“garantizada” cifrada. La señal de “garantización” no contieneinformación de autenticación del usuario. La integridad vienegarantizada por la clave secreta compartida (DES triple). Laseñal contiene un valor de tiempo de espera (de duración) paralimitar la duración de la validez de la señal.

¶ La implementación de la comunidad electrónica tiene soporte enHTTP y HTTPS.

¶ Los dominios individuales de la comunidad electrónica gestionansus propias identidades de usuario y privilegios asociados. Puedeutilizar la API CDMF (Cross Domain Mapping Function) paracorrelacionar un usuario de un dominio remoto con un usuarioválido en el dominio local.

Si los dominios de la comunidad electrónica compartenidentidades de usuario globales, esta función de correlación noes necesaria.

¶ La configuración de la comunidad electrónica se establece en elarchivowebseald.conf de cada servidor WebSEAL participante.

Flujo de procesos de la comunidad electrónicaUna comunidad electrónica está formada por un servidor maestro deautenticación (MAS) WebSEAL y otros servidores WebSEALubicados en el dominio inicial y los dominios remotos. El MASpuede existir como instancia única de un servidor WebSEAL, ocomo un conjunto de servidores WebSEAL replicados ubicadosdetrás de un equilibrador de cargas (donde el equilibrador de cargasse identifica como el MAS).

Todos los servidores WebSEAL locales y remotos participantestienen que estar configurados para utilizar el MAS del dominioinicial en la autenticación de clientes inicial. Este es un requisitoobligatorio para los servidores en el dominio inicial, y un requisitomodificable para los servidores en los dominios remotos. Porejemplo, algunos servidores en los dominios remotos se pueden

142 Versión 3.8

configurar para que gestionen sus propia autenticación. Estosservidores, y los recursos que protegen, pueden funcionarindependientemente de la comunidad electrónica, incluso si seencuentran en un dominio participante de la comunidad electrónica.

La implementación de la comunidad electrónica se basa en unsistema de “garantización”. Normalmente, cuando un usuario solicitaun recurso a un servidor WebSEAL en el que no ha establecido unasesión válida, WebSEAL solicita al usuario información deautenticación. En una configuración de comunidad electrónica, elservidor WebSEAL identifica un servidor de “garantización” y lepide verificación de que el usuario se ha autenticado.

El servidor de “garantización” tiene información de credencial válidapara ese usuario. Para la primera petición del usuario, el servidor de“garantización” es siempre el MAS. El MAS continúa funcionandocomo servidor de “garantización” para los recursos ubicados en eldominio inicial. Si el usuario continúa realizando peticiones derecursos a través de la comunidad electrónica, un servidor individualen cada dominio remoto puede crear su propia credencial para elusuario (a partir de la información de la identidad del usuario delMAS) y asumir la función de servidor de “garantización” para losrecursos de su dominio.

La verificación solicitada del servidor de “garantización” toma laforma de una señal de “garantización”. El servidor de“garantización” crea la señal y la devuelve al servidor WebSEALque la ha solicitado. La información de la identidad del usuario en laseñal está cifrada. La señal contiene un límite de duración.

Al recibir la señal de “garantización”, el servidor que realiza lapetición crea credenciales y una sesión local para ese usuario. Elusuario tiene ahora acceso al recurso solicitado, siguiendo loscontroles normales de autorización. El usuario tiene la ventaja deque no debe repetir la autenticación—uno de los objetivos delmodelo de comunidad electrónica.

Consulte el siguiente diagrama para seguir el flujo de procesos de lacomunidad electrónica en lo que queda de apartado. El flujo de


5.S

oluc.de

iniciode

ses.en

dominios

cruzados

procesos describe dos ejemplos posibles de PRIMER acceso (1 y 2).A continuación, se presentan dos ejemplos posibles de SIGUIENTEacceso (3 y 4) que siguen inmediatamente después de 2 o 3. Elejemplo 5 se produce en cualquier momento después del accesoinicial.

Servidores de “garantización”

¶ El MAS se utiliza siempre para autenticar el usuario que accedea cualquier parte de la comunidad electrónica por primera vez.

El MAS sólo se debe utilizar como servidor de autenticaciones,y no como proveedor de recursos. El MAS no se debeconfigurar para funcionar como servidor maestro deautenticaciones y, simultáneamente, proteger los recursos. Estarecomendación afecta al rendimiento, y no es un requisito deseguridad.

¶ El MAS es siempre el servidor de “garantización” para eldominio inicial (dominio A en este ejemplo).

¶ Se utiliza una cookie de comunidad electrónica específica deldominio para identificar el servidor de “garantización” para los

Client

Domain A Domain 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

Figura 21. Flujo de procesos de la comunidad electrónica

144 Versión 3.8

otros servidores dentro de un dominio dado. El servidor de“garantización” es el primer servidor en un dominio que solicitauna señal de “garantización” al MAS. El servidor de“garantización” proporciona información de “garantización” parael usuario del dominio. Las siguientes peticiones de servicios de“garantización” en un dominio remoto dado se pueden hacer deforma local mediante este servidor, en lugar de acceder al MASfuera del dominio. En el dominio inicial, la cookie decomunidad electrónica identifica al MAS como el servidor de“garantización”.

(1) PRIMER acceso a la comunidad electrónica : WebSEAL 1(Dominio A)

¶ El usuario solicita un recurso protegido por WebSEAL 1 (dentrodel mismo dominio que MAS). El navegador no contieneninguna cookie de comunidad electrónica para este dominio.WebSEAL 1 no tiene credenciales almacenadas en la caché parael usuario.

¶ La configuración de WebSEAL 1 tiene activada la autenticaciónde la comunidad electrónica, y especifica la ubicación del MAS.WebSEAL 1 redirecciona el navegador a una dirección URLespecial de “garantización” en el MAS.

¶ El MAS recibe la petición de “garantización” y, al no encontrarlas credenciales para ese usuario, solicita al usuario que inicie lasesión.

¶ Si el inicio de sesión es correcto, el MAS crea una credencialpara el usuario, la almacena en la caché, y redirecciona de nuevoel navegador a la dirección URL solicitada originalmente enWebSEAL 1 con una señal de “garantización” cifrada.Asimismo, se coloca una cookie de comunidad electrónicaespecífica del dominio A en el navegador para identificar elservidor de “garantización” de este dominio (en este caso, elMAS).

Si el intento de inicio de sesión no es correcto, el MAS devuelveuna señal de “garantización” que indica un estado de error. Estaseñal se construye para que no sea distinguible de una señal de“garantización” de estado correcto. El servidor que realiza la


5.S

oluc.de

iniciode

ses.en

dominios

cruzados

petición reacciona a una señal de estado de error como si elusuario no hubiera pasado la autenticación local.

¶ WebSEAL 1 descifra la señal y crea su propia credencial para elusuario.

Nota: la correlación de identidades no debería ser necesariadentro del mismo dominio. Si se requiere la correlaciónde identidades, WebSEAL 1 debe utilizar Cross DomainMapping Framework (CDMF).

¶ El servicio de autorización permite o rechaza la petición.

(2) PRIMER acceso a la comunidad electrónica : WebSEAL 3(Dominio B)

¶ El usuario solicita un recurso protegido por WebSEAL 3(dominio B remoto). El navegador no contiene ninguna cookiede comunidad electrónica para este dominio. WebSEAL 3 notiene credenciales almacenadas en la caché para el usuario.

¶ La configuración de WebSEAL 3 tiene activada la autenticaciónde la comunidad electrónica, y especifica la ubicación del MAS.WebSEAL 3 redirecciona el navegador a una dirección URLespecial de “garantización” en el MAS.

¶ El MAS recibe la petición de “garantización” y, al no encontrarlas credenciales para ese usuario, solicita al usuario que inicie lasesión.

¶ Si el inicio de sesión es correcto, el MAS crea una credencialpara el usuario, la almacena en la caché, y redirecciona de nuevoel navegador a la dirección URL solicitada originalmente enWebSEAL 3 con una señal de “garantización” cifrada.Asimismo, se coloca una cookie de comunidad electrónicaespecífica del dominio A en el navegador para identificar elservidor de “garantización” de este dominio (en este caso, elMAS).

Si el intento de inicio de sesión no es correcto, el MAS devuelveuna señal de “garantización” que indica un estado de error. Estaseñal se construye para que no sea distinguible de una señal de“garantización” de estado correcto. El servidor que realiza la

146 Versión 3.8

petición reacciona a una señal de estado de error como si elusuario no hubiera pasado la autenticación local.


¶ WebSEAL 3 crea y establece una segunda cookie de comunidadelectrónica (válida para el dominio B) en el navegador, queidentifica a WebSEAL 3 como el servidor de “garantización”para el dominio B.


(3) SIGUIENTE acceso a la comunidad electrónica: WebSEAL 2(Dominio A)

¶ El usuario solicita un recurso protegido por WebSEAL 2 (dentrodel mismo dominio que MAS). El navegador contiene unacookie de comunidad electrónica del dominio A que identifica alMAS como servidor de “garantización”. WebSEAL 2 recibe estacookie. WebSEAL 2 no tiene credenciales almacenadas en lacaché para el usuario.

¶ La configuración de WebSEAL 2 tiene activada la autenticaciónde la comunidad electrónica, y especifica la ubicación del MAS.La presencia de la cookie de comunidad electrónica del dominioA anula la configuración de WebSEAL 2 para la ubicación deMAS. La cookie proporciona a WebSEAL 2 la identidad delservidor de “garantización”. (Si se da primero el ejemplo 2,también habría una cookie de dominio B mantenida en elnavegador que no se enviaría a un servidor de dominio A).

¶ WebSEAL 2 redirecciona el navegador a una dirección URLespecial de “garantización” en el servidor de “garantización” deldominio A identificado en la cookie (es este caso, el MAS, yaque WebSEAL 2 está en el dominio A).

¶ El MAS recibe la petición de “garantización” y busca lascredenciales para ese usuario en la caché (esto se produce en elejemplo 1 y 2).


5.S

oluc.de

iniciode

ses.en

dominios

cruzados

¶ El MAS redirecciona de nuevo el navegador a la dirección URLsolicitada originalmente en WebSEAL 2 con una señal de“garantización” cifrada.



(4) SIGUIENTE acceso a la comunidad electrónica: WebSEAL 4(Dominio B)

¶ El usuario solicita un recurso protegido por WebSEAL 4(dominio B remoto). Si el ejemplo 2 se produce primero, elnavegador contiene una cookie de comunidad electrónica deldominio B que identifica a WebSEAL 3 como servidor de“garantización”. WebSEAL 4 no tiene credenciales almacenadasen la caché para el usuario.

¶ La configuración de WebSEAL 4 tiene activada la autenticaciónde la comunidad electrónica, y especifica la ubicación del MAS.La presencia de una cookie de comunidad electrónica deldominio B anula la configuración de WebSEAL 4 para laubicación de MAS. La cookie proporciona a WebSEAL 4 laidentidad del servidor de “garantización”. (Si se da primero elejemplo 2, sólo habrá una cookie de dominio A mantenida en elnavegador que no se enviaría a un servidor de dominio B. En sulugar, se utilizará la ubicación configurada del MAS. WebSEAL4 se convertirá en el servidor de “garantización” para el dominioB.)

¶ Si el ejemplo 2 se produce primero, WebSEAL 4 redirecciona elnavegador a una dirección URL especial de “garantización” en elservidor de “configuración” del dominio B identificado en lacookie de dominio B (en este caso WebSEAL 3).

¶ WebSEAL 3 recibe la petición de “garantización” y busca lascredenciales para ese usuario en la caché (esto se produce en elejemplo 2).

¶ WebSEAL 3 redirecciona de nuevo el navegador a la direcciónURL solicitada originalmente en WebSEAL 4 con una señal de“garantización” cifrada.

148 Versión 3.8



(5) OTRO acceso a la comunidad electrónica: WebSEAL 2(Dominio A)

¶ El usuario se conecta a WebSEAL 2 (dominio A) con unapetición. Si se ha producido el ejemplo 3, WebSEAL 2 tienecredenciales almacenadas en la caché para el usuario.


Fin de sesión de la comunidad electrónica

¶ Si el usuario finaliza la sesión cerrando el navegador, se borrarántodas las sesiones SSL y las cookies de comunidad electrónica.

¶ Si el usuario finaliza la sesión a través de la página/pkmslogout, se borrarán la sesión SSL y la cookie decomunidad electrónica para ese dominio.

Información sobre la cookie de comunidad electrónica¶ La cookie de comunidad electrónica es una cookie específica del

dominio establecida por un servidor WebSEAL, almacenada enla memoria del navegador del usuario y transmitida a otrosservidores WebSEAL (en el mismo dominio) en las siguientespeticiones.

¶ La cookie específica del dominio contiene el nombre delservidor de “garantización”, la identidad de la comunidadelectrónica, una ubicación (URL) del servidor de “garantización”y la funcionalidad, y un valor de duración. La cookie nocontiene información del usuario.

¶ La cookie de comunidad electrónica permite a los servidores delos dominios participantes solicitar información de“garantización” de forma local. La cookie de comunidadelectrónica para el dominio en el que reside el MAS juega unpapel menos importante.


5.S

oluc.de

iniciode

ses.en

dominios

cruzados

¶ La cookie tiene un valor de duración (tiempo de espera) que seestablece en el archivo de configuraciónwebseald.conf. Estevalor de duración especifica durante cuánto tiempo puede elservidor remoto proporcionar información de “garantización”para el usuario. Cuando caduca la duración de la cookie, elusuario se debe redireccionar al MAS para su autenticación.

¶ La cookie se borra de la memoria cuando se cierra el navegador.Si el usuario finaliza la sesión de un dominio específica, lacookie de comunidad electrónica se sobrescribe como vacía. Estaacción la elimina definitivamente del navegador.

Información sobre la petición y la respuesta de“garantización”

La operación de “garantización” de la comunidad electrónicarequiere una funcionalidad dedicada, a la que se accede a través dedos direcciones URL especialmente construidas: la petición de“garantización” y la respuesta de “garantización”. Estas direccionesURL se construyen durante las redirecciones de HTTP“garantizadas” de comunidad electrónica, a partir de la informaciónde configuración dewebseald.conf.

La petición de “garantización”

La petición de “garantización” se desencadena cuando un usuariosolicita un recurso de un servidor de destino (configurado para lacomunidad electrónica) que no contiene información de credencialesdel usuario. El servidor envía una redirección HTTP al servidor de“garantización” (el MAS o un servidor identificado en una cookie decomunidad electrónica).

La petición de “garantización” contiene la siguiente información:https://<servidor-garantización>/pkmsvouchfor?<nombre-comunidad

-electrónica>&<URL-destino>

El servidor receptor comprueba elnombre-comunidad-electrónicapara validar la identidad de la comunidad electrónica. El servidorreceptor utiliza laURL-destinode la respuesta de “garantización”para redireccionar de nuevo el navegador a la página solicitadaoriginalmente.

150 Versión 3.8

La dirección URL de “garantización” depkmsvouchfor se puedeconfigurar.

Por ejemplo:https://mas.dA.com/pkmsvouchfor?companyABC&https://ws5.dB.com/index.html

La respuesta de “garantización”

La respuesta de “garantización” es la respuesta del servidor de“garantización” al servidor de destino.

La respuesta de “garantización” contiene la siguiente información:https://<URL-destino>?PD-VFHOST=<servidor-garantización>

&PD-VF=<señal-cifrada>

El parámetro PD-VFHOST identifica al servidor que ha realizado laoperación de “garantización”. El servidor receptor (destino) utilizaesta información para seleccionar la clave correcta necesaria paradescifrar la señal de “garantización” (PD-VF). El parámetro PD-VFrepresenta la señal de “garantización” cifrada.

Por ejemplo:https://w5.dB.com/index.html?PD-VFHOST=

mas.dA.com&PD-VF=3qhe9fjkp...ge56wgb

Información sobre la señal de “garantización”Para conseguir un inicio de sesión único en dominios cruzados, sedebe transmitir información de identidad de usuario entre losservidores. Esta información confidencial se gestiona utilizando unaredirección que incluye la información de identidad cifrada comoparte de la dirección URL. Estos datos cifrados se denominan señalde “autenticación” .

¶ La señal contiene el estado de error o de éxito de“garantización”, la identidad del usuario (si es correcto), elnombre completo del servidor que ha creado la señal, laidentidad de la comunidad electrónica y el valor de hora decreación.


5.S

oluc.de

iniciode

ses.en

dominios

cruzados

¶ El poseedor de una señal de “garantización” válida puedeutilizarla para establecer una sesión (y un conjunto decredenciales) en un servidor sin autenticarse explícitamente enese servidor.

¶ La señal se cifra utilizando una clave secreta compartidamediante DES triple, para que se pueda verificar su autenticidad.

¶ La información de la señal cifrada no se almacena en elnavegador.

¶ La señal sólo se pasa una vez. El servidor receptor utiliza estainformación para crear credenciales de usuario en su propiacaché. El servidor utiliza estas credenciales para futuraspeticiones del usuario durante la misma sesión.

¶ La señal tiene un valor de duración (tiempo de espera) que seestablece en el archivo de configuraciónwebseald.conf. Estevalor puede ser muy breve (segundos) para reducir el riesgo deun ataque de respuestas.

Cifrado de la señal de “garantización”WebSEAL debe cifrar los datos de autenticación ubicados en la señalmediante una clave generada por la utilidadcdsso_key_gen. Debe“sincronizar” esta clave compartiendo el archivo de claves con todoslos servidores WebSEAL de cada uno de los dominios participantes.Todos los servidores WebSEAL participantes de cada dominio debenutilizar la misma clave.

Nota: la creación y distribución de archivos de claves no formaparte del proceso de comunidad electrónica de PolicyDirector. Debe copiar manualmente y con seguridad las clavespara cada servidor participante.

La utilidad cdsso_key_genprecisa que se especifique la ubicación(nombre de ruta de acceso completa) del archivo de claves cuando seejecute la utilidad:

UNIX: # cdsso_key_gen <nombre-ruta-completa>

Windows: MSDOS> cdsso_key_gen <nombre-ruta-completa>

152 Versión 3.8

La ubicación de la clave utilizada para asegurar las señales enviadasentre los servidores de un mismo dominio (local y remoto) seespecifica como el valor del parámetrointra-domain-key en lastanza[e-community-sso]del archivo de configuraciónwebseald.conf.[e-community-sso]intra-domain-key = <nombre-ruta-completa>

La ubicación de los archivos de clave utilizados para asegurar lasseñales enviadas entre el MAS y los servidores de dominios remotosse especifica en la stanza[inter-domain-keys]. Los otros servidoresdel mismo dominio que MAS no necesitan inter-domain-keys. ElMAS es el único servidor que debe comunicarse con los servidoresen los dominios remotos.[inter-domain-keys]<nombre-dominio> = <nombre-ruta-completa><nombre-dominio> =<nombre-ruta-completa

Configuración de una comunidad electrónicaEste apartado repasa todos los parámetros de configuraciónnecesarios para implementar una comunidad electrónica. Estosparámetros se encuentran en el archivowebseald.conf. Debeconfigurar atentamente este archivo para cada uno de los servidoresparticipantes en la comunidad electrónica.

e-community-sso-auth

Este parámetro activa o desactiva la autenticación de la comunidadelectrónica. Los valores son “http”, “https”, “both” (ambos), o“none” (ninguno). Por ejemplo:[e-community-sso]e-community-sso-auth = both

Los valores “http”, “https”, y “both” especifican el tipo decomunicación que utilizan los participantes de la comunidadelectrónica. El valor “none” desactiva la comunidad electrónica paraese servidor. El valor predeterminado es “none”.

master-http-port


5.S

oluc.de

iniciode

ses.en

dominios

cruzados

Si e-community-sso-authactiva la autenticación de la comunidadelectrónica HTTP, y el servidor maestro de autenticación escucha laspeticiones HTTP en un puerto distinto del puerto HTTP estándar(puerto 80), el parámetromaster-http-port permite identificar elpuerto no estándar. Este parámetro se omite si este servidor es elservidor maestro de autenticación. De forma predeterminada, esteparámetro está desactivado.[e-community-sso]master-http-port = <número-puerto>

master-https-port

Si e-community-sso-authactiva la autenticación de la comunidadelectrónica HTTPS, y el servidor maestro de autenticación escuchalas peticiones HTTPS en un puerto distinto del puerto HTTPestándar (puerto 443), el parámetromaster-http-port permiteidentificar el puerto no estándar. Este parámetro se omite si esteservidor es el servidor maestro de autenticación. De formapredeterminada, este parámetro está desactivado.[e-community-sso]master-https-port = <número-puerto>

e-community-name

Este parámetro identifica el número unificado de la comunidadelectrónica para todos los servidores participantes en todos losdominios participantes. Por ejemplo:[e-community-sso]e-community-name = companyABC

El valor e-community-namedebe ser el mismo para todos losservidores WebSEAL en todos los dominios que participan en lacomunidad electrónica.

intra-domain-key

Este parámetro identifica la ubicación del archivo de claves que seutiliza para cifrar y descifrar las señales que se intercambian en eldominio de este servidor. Por ejemplo:

154 Versión 3.8

[e-community-sso]intra-domain-key = /abc/xyz/key.file

Debe generar este archivo de claves en una ubicación y copiarlomanualmente (con seguridad) en la ubicación especificada en losotros servidores WebSEAL dentro del dominio.

is-master-authn-server

Este parámetro identifica si este servidor es el MAS o no. Losvalores posibles son “yes” o “no”. Por ejemplo:[e-community-sso]is-master-authn-server = yes

Se pueden configurar varios WebSEAL para actuar como servidoresmaestros de autenticación y, a continuación, colocarlos detrás de unequilibrador de carga. En este caso, el equilibrador de carga es“reconocido” como el MAS por lo otros servidores WebSEAL en lacomunidad electrónica.

master-authn-server

Si el parámetrois-master-authn-serverse establece en “no”, esteparámetro debe estar especificado y sin comentarios. El parámetroidentifica el nombre de dominio completo del MAS. Por ejemplo:[e-community-sso]master-authn-server = mas.dA.com

vf-token-lifetime

Este parámetro establece el valor de tiempo de espera de duración(en segundos) de la señal de “garantización”. Este valor secomprueba comparándolo con la hora de creación indicada en lacookie. El valor predeterminado es 180 segundos. Debe tener encuenta las diferencias horarias entre los servidores participantes. Porejemplo:[e-community-sso]vf-token-lifetime = 180

vf-url


5.S

oluc.de

iniciode

ses.en

dominios

cruzados

Este parámetro especifica la dirección URL de “garantización”. Elvalor debe empezar con una barra inclinada (/). El valorpredeterminado es/pkmsvouchfor. Por ejemplo:[e-community-sso]vf-url = /pkmsvouchfor

También puede expresar una dirección URL ampliada:vf-url = /ecommA/pkmsvouchfor

ec-cookie-lifetime

Este parámetro especifica la duración máxima (en minutos) de lacookie de dominio de comunidad electrónica. El valorpredeterminado es 300 minutos. Por ejemplo:[e-community-sso]ec-cookie-lifetime = 300

Claves entre dominios

La ubicación de los archivos de clave necesarios para cifrar ydescifrar las señales entre el MAS y los servidores participantes seespecifica en la stanza[inter-domain-keys]. Debe especificar losnombres de dominio completos de los servidores y las rutascompletas de las ubicaciones de los archivos de claves.

El siguiente ejemplo proporciona al MAS (dominio A) los archivosde claves para comunicarse con dos dominios remotos:[inter-domain-keys]dB.com = /abc/xyz/key.fileBdC.com = /abc/xyz/key.fileC

En este ejemplo,key.fileB identifica al archivo de claves utilizadoentre el dominio A y el dominio B.key.fileC identifica el archivode claves utilizado entre el dominio A y el dominio C.

Cada servidor remoto necesitará una copia del archivo de clavescorrespondiente utilizado por el MAS. Para intercambiar señales conel MAS (dominio A), todos los servidores del dominio B necesitancopias dekey.fileB.

156 Versión 3.8

[inter-domain-keys]dA.com = /efg/hij/key.fileB

Para intercambiar señales con el MAS (dominio A), todos losservidores del dominio C necesitan copias dekey.fileC.[inter-domain-keys]dA.com = /efg/hij/key.fileC

Configuración del mecanismo de autenticación de CDSSOLa configuración de la comunidad electrónica necesita que active elmecanismo de autenticación decdsso. Este mecanismo es necesariocuando el servidor que realiza la petición crea credenciales deusuario a partir de la información de identidad contenida en la señalde “garantización”. El parámetro de configuracióncdssoespecificala biblioteca compartida codificada de forma que no se puedamodificar para correlacionar la información de autenticación.

¶ En UNIX, el archivo que proporciona la función de correlaciónincorporada es una biblioteca compartida denominadalibcdssoauthn.

¶ En Windows, el archivo que proporciona la función decorrelación incorporada es una DLL denominadacdssoauthn.




cdsso libcdssoauthn.so libcdssoauthn.a cdssoauthn.dll libcdssoauthn.sl

Puede configurar el mecanismo de autenticación de CDSSOespecificando el parámetrocdssocon el nombre específico para laplataforma del archivo de biblioteca compartida en la stanza[authentication-mechanism]del archivo de configuraciónwebseald.conf.

Por ejemplo:

Solaris:[authentication-mechanisms]cdsso = libcdssoauthn.so


5.S

oluc.de

iniciode

ses.en

dominios

cruzados

Windows:[authentication-mechanisms]cdsso = cdssoauthn.dll

158 Versión 3.8

Conexiones (junctions)WebSEAL

La conexión entre un servidor WebSEAL y un servidor deaplicaciones Web de fondo se conoce como conexión (junction)WebSEAL o conexión (junction). Una conexión (junction) WebSEALes una conexión de TCP/IP entre un servidor WebSEAL frontal y unservidor de aplicaciones Web de fondo. Las conexiones (junctions)permiten a WebSEAL proteger los recursos Web ubicados en losservidores de fondo.

Puede crear conexiones (junctions) WebSEAL con la utilidad de lalínea de comandospdadmin o con Web Portal Manager. Estecapítulo describe los detalles de las distintas opciones paraconfigurar conexiones (junctions) WebSEAL.

Índice de temas:

¶ “Visión general de las conexiones (junctions) WebSEAL” en lapágina 160

¶ “Utilización de “pdadmin server task” para crear conexiones(junctions)” en la página 163

¶ “Configuración de una conexión (junction) WebSEAL básica” enla página 164

¶ “Conexiones (junctions) SSL autenticadas mutuamente” en lapágina 167

6


6.C

onexiones(junctions)

WebS

EA

L

¶ “Creación de conexiones (junctions) proxy TCP y SSL” en lapágina 172

¶ “Conexiones (junctions) de WebSEAL a WebSEAL a través deSSL” en la página 174

¶ “Opciones de conexión (junction) adicionales” en la página 175

¶ “Notas técnicas sobre el uso de conexiones (junctions)WebSEAL” en la página 196

¶ “Utilización de query_contents con servidores de terceros” en lapágina 200

Visión general de las conexiones (junctions)WebSEAL

Puede crear los siguientes tipos de conexión (junction) WebSEAL:

¶ De WebSEAL a servidor de fondo a través de una conexión TCP

¶ De WebSEAL a servidor de fondo a través de una conexión SSL

¶ De WebSEAL a servidor de fondo a través de una conexión TCPmediante el servidor proxy HTTP

¶ De WebSEAL a servidor de fondo a través de una conexión SSLmediante el servidor proxy HTTPS

¶ De WebSEAL a WebSEAL a través de una conexión SSL

Debe ocuparse de los dos temas siguientes al crear una conexión(junction):

1. Decidir dónde conectar (montar) el servidor de aplicaciones Weben el espacio de objetos de WebSEAL.

2. Elegir el tipo de conexión (junction).

Ubicación y formato de la base de datos de conexión(junction)

La información de la conexión (junction) WebSEAL se almacenaahora en los archivos de la base de datos en formato XML. Laubicación del directorio de la base de datos de conexión (junction)

160 Versión 3.8

está definida en la stanza[junction] del archivo de configuraciónwebseald.conf. El directorio es relativo a la raíz del servidorWebSEAL (parámetroserver-root de la stanza[server]):[junction]junction-db = jct

¶ Cada conexión (junction) está definida en un archivo aparte conuna extensión.xml.

¶ Utilice la utilidad pdadmin para crear y gestionar las conexiones(junctions) y las opciones.

¶ El formato XML permite crear, editar, duplicar y hacer copia deseguridad manualmente de los archivos de conexión (junction).

Aplicación del control de acceso flexible: Resumen1. Utilice la utilidadpdadmin o Web Portal Manager para crear

una conexión (junction) entre WebSEAL y el servidor de fondo.

2. Coloque una política de ACL apropiada en el punto de conexión(junction) para proporcionar un control flexible al servidor defondo.

Aplicación del control de acceso estricto: Resumen1. Utilice la utilidadpdadmin o Web Portal Manager para crear

una conexión (junction) entre WebSEAL y el servidor de fondo.

WebSEAL no puede “ver” ni comprender automáticamente unsistema de archivos de terceros. Debe informar a WebSEAL delespacio de objetos de terceros mediante una aplicación especialdenominadaquery_contents, que hace un inventario del espacioWeb de terceros e informa a WebSEAL acerca de la estructura yel contenido.

2. Copie el programaquery_contentsen el servidor de terceros.

3. Aplique la política de ACL a los objetos apropiados del espaciode objetos unificado.


6.C


WebS

EA

L

Directrices para la creación de conexiones (junctions)WebSEAL

Las directrices siguientes resumen las “normas” para las conexiones(junctions):

¶ Puede agregar una conexión (junction) en cualquier punto delespacio de objetos de WebSEAL principal

¶ Puede conectar varios servidores replicados al mismo punto demontaje

Los distintos servidores replicados montados en el mismo puntode conexión (junction) deben ser del mismo tipo, TCP o SSL

¶ Las políticas de ACL se heredan a través de las conexiones(junctions) en los servidores de terceros

¶ El punto de conexión (junction) no debe coincidir con ningúndirectorio del espacio Web del servidor WebSEAL local. Porejemplo, si WebSEAL tiene recursos con el formato/ruta/..., nocree un punto de conexión (junction) con el nombre/ruta.

¶ El punto de conexión (junction) no debe coincidir con ningúndirectorio del espacio Web del servidor de fondo si las páginasHTML del servidor contienen programas (por ejemplo, Javascripto applets) con direcciones URL de ese directorio relativas alservidor. Por ejemplo, si las páginas del servidor de fondocontienen programas con una dirección URL con el formato/ruta/..., no cree un punto de conexión (junction) con el nombre/ruta.

WebSEAL sólo da soporte a HTTP 1.0 a través deconexiones (junctions)

WebSEAL sólo da soporte a HTTP 1.0 a través de conexiones(junctions). Esta limitación puede afectar al ajuste del rendimiento yel desarrollo de aplicaciones desplegadas en servidores de fondo conconexión (junction).

Conexión Protocolo soportado Número de RFC

Frontal (de cliente aWebSEAL)

HTTP/1.0 y HTTP/1.1 RFC2068

162 Versión 3.8

Conexión Protocolo soportado Número de RFC

De fondo (de WebSEAL aservidor con conexión)

Sólo HTTP/1.0 RFC1945

Nota: no se da soporte a HTTP/1.0 “Keep-Alive” para la conexiónfrontal. Se da soporte a la conexión HTTP persistente paraHTTP/1.1.

Referencias adicionales para las conexiones(junctions) WebSEAL

Consulte el apartado “Información sobre las conexiones (junctions)WebSEAL” en la página 10 para obtener una visión generalconceptual de las conexiones (junctions) WebSEAL.

Consulte el apartado “Referencia para las conexiones (junctions)WebSEAL” en la página 269 para obtener información completaacerca de las opciones de comandos de conexión (junction).

Utilización de “pdadmin server task” para crearconexiones (junctions)

Antes de utilizarpdadmin, debe iniciar la sesión en un dominioseguro como usuario de administraciónsec_master.

Por ejemplo:

UNIX:# pdadminpdadmin> loginEscriba el ID de usuario: sec_masterEscriba la contraseña:pdadmin>

Windows:MSDOS> pdadminpdadmin> loginEscriba el ID de usuario: sec_masterEscriba la contraseña:pdadmin>


6.C


WebS

EA

L

Para crear conexiones (junctions) WebSEAL, utilice el comandopdadmin server task:pdadmin> server task <nombre-servidor> <tarea>

El argumentonombre-servidores la expresión completa del nombrereal de la máquina y el componente de Policy Director utilizado poreste comando (por ejemplo, WebSEAL).<componente-policy-director>-<nombre-máquina>

Por ejemplo, si el nombre de la máquina escruz y el componente dePolicy Director es WebSEAL, elnombre-servidores:webseald-cruz

Utilice el comandoserver list para verificar las expresionesnombre-servidor:pdadmin> server listwebseald-cruz

Configuración de una conexión (junction) WebSEALbásica

WebSEAL da soporte a las conexiones (junctions) TCP estándar(HTTP) y SSL segura (HTTPS) entre WebSEAL y los servidores deaplicaciones Web.

La conexión (junction) entre WebSEAL y el servidor de fondo esindependiente del tipo de conexión (y su nivel de seguridad) entre elcliente y el servidor WebSEAL.

Las opciones de comando obligatorias que son necesarias para crearuna conexión (junction) WebSEAL básica mediantepdadmin son:

¶ Nombre de host del servidor de aplicaciones de fondo (opción–h)

¶ Tipo de conexión (junction): tcp, ssl, tcpproxy, sslproxy, local(opción–t)

¶ Punto de conexión (junction) (punto de montaje)pdadmin> server task <nombre-servidor> create –t <tipo> –h<nombre-host> <punto-conexión>

164 Versión 3.8

Por ejemplo:pdadmin> server task webseald-cruz create -t tcp -h doc.tivoli.com /pubs

Conexiones (junctions) de tipo TCPUna conexión (junction) WebSEAL a través de una conexión TCPproporciona las propiedades básicas de una conexión (junction) perono proporcionan una comunicación segura a través de ésta.

Para crear una conexión (junction) TCP segura y agregar un servidorinicial, utilice el comandocreate con la opción–t tcp:pdadmin> server task <nombre-servidor> create –t tcp –h <nombre-host>[–p <puerto>] <punto-conexión>

El valor de puerto predeterminado para una conexión (junction) TCP(si no se ha especificado) es80.

Conexiones (junctions) de tipo SSLLas conexiones (junctions) SSL funcionan exactamente igual que lasconexiones (junctions) TCP, con el valor añadido de que todas lascomunicaciones entre WebSEAL y el servidor de fondo estáncifradas.

JunctionWebSEAL

Client

Secure Domain

WebApplication

Server

HTTP

/

/mnt

TCP

Figura 22. Conexión (junction) TCP no segura (HTTP)


6.C


WebS

EA

L

Las conexiones (junctions) SSL permiten transacciones seguras deextremo a extremo de navegador a aplicación. Puede utilizar SSLpara proteger las comunicaciones del cliente a WebSEAL y deWebSEAL al servidor de fondo. El servidor de fondo debe tenerHTTPS activado al utilizar una conexión (junction) SSL.

Para crear una conexión (junction) SSL segura y agregar un servidorinicial, utilice el comandocreate con la opción–t ssl:pdadmin> server task <nombre-servidor> create –t ssl –h <nombre-host>[–p <puerto>] <punto-conexión>

El valor de puerto predeterminado para una conexión (junction) SSL(si no se ha especificado) es443.

Verificación del certificado de servidor de fondoCuando un cliente realiza una petición para un recurso del servidorde fondo, WebSEAL, en su rol como servidor de seguridad, realizala petición en nombre del cliente. El protocolo SSL especifica quecuando se realiza una petición al servidor de fondo, ese servidordebe proporcionar una prueba de identidad mediante un certificadode servidor.

Cuando WebSEAL recibe este certificado del servidor de fondo, debeverificar su autenticidad comparándolo con una lista de certificadosraíz de CA almacenados en su base de datos de certificados.

JunctionWebSEAL

Client

Secure Domain

WebApplication

Server

HTTPS

/

/mntSSLTCP

Figura 23. Conexión (junction) SSL segura (HTTPS)

166 Versión 3.8

Policy Director utiliza la implementación del IBM Global SecurityKit (GSKit) de SSL. Debe utilizar la utilidadiKeyman de GSKitpara agregar el certificado raíz de la CA que ha firmado elcertificado del servidor de fondo en el archivo de claves decertificados de WebSEAL (pdsvr.kdb).

Para obtener información completa acerca de la gestión de la base dedatos de claves de certificados, consulte el apartado “Gestión decertificados con iKeyman” en la página 279.

Ejemplos de conexiones (junctions) de SSLHost de conexión (junction)sales.tivoli.comen el punto de conexión(junction) /sales a través de SSL:pdadmin> server task <nombre-servidor> create –t ssl –hsales.tivoli.com /sales

Nota: en el ejemplo anterior, la opción–t ssl dicta el puertopredeterminado 443.

Host de conexión (junction)travel_svr en el puerto4443en elpunto de conexión (junction)/travel a través de SSL:pdadmin> server task <nombre-servidor> create –t ssl –p 4443–h travel_svr /travel

Conexiones (junctions) SSL autenticadasmutuamente

WebSEAL da soporte a la autenticación mutua entre un servidorWebSEAL y un servidor de fondo a través de una conexión(junction) SSL (–t ssl o –t sslproxy). El siguiente esquema resumelas funciones soportadas para la autenticación mutua a través de SSL(se incluyen las opciones de comando en la lista donde espertinente):

1. WebSEAL autentica el servidor de fondo (proceso SSL normal)

¶ WebSEAL valida el certificado de servidor del servidor defondo. Consulte el apartado “WebSEAL valida el certificadode servidor de fondo” en la página 168.


6.C


WebS

EA

L

¶ WebSEAL verifica el Nombre distinguido (DN) contenido enel certificado (–D) (opcional, pero muy recomendable).Consulte el apartado “Coincidencia de Nombre distinguido(DN)” en la página 169.

2. El servidor de fondo autentica WebSEAL (dos métodos)

¶ El servidor de fondo valida el certificado de cliente deWebSEAL (–K). Consulte el apartado “WebSEAL seautentica con el certificado de cliente” en la página 169.

¶ El servidor de fondo valida la información de identidad deWebSEAL en la cabecera de Autenticación básica (BA) (–B,–U, –W). Consulte el apartado “WebSEAL se autentica conuna cabecera de BA” en la página 170.

Las opciones de comando que controlan la autenticación mutua através de SSL proporcionan las siguientes funciones:

¶ Puede especificar el certificado de cliente o el método deautenticación BA.

¶ Puede aplicar el método de autenticación según la conexión(junction).

En el apartado “Gestión de la información de identidad del cliente através de conexiones (junctions)” en la página 171 encontraráconsideraciones especiales para combinar las opciones–b (paragestionar la información de BA) con la autenticación mutua a travésde SSL

WebSEAL valida el certificado de servidor de fondoWebSEAL verifica un certificado de servidor de fondo según elprotocolo SSL estándar. El servidor de fondo envía su certificado deservidor a WebSEAL. WebSEAL valida el certificado de servidorcomparándolo con una lista predefinida de certificados de CA(entidad emisora de certificados).

Los certificados de CA (entidad emisora de certificados) que formanla cadena fiable para el certificado de servidor de aplicaciones (de laCA firmante al certificado raíz, éste incluido) deben estar incluidosen la base de datos de claves que utiliza WebSEAL.

168 Versión 3.8

Use la utilidadiKeyman para crear y gestionar la base de datos decertificados raíz de CA. Consulte el apartado “Gestión decertificados con iKeyman” en la página 279.

Coincidencia de Nombre distinguido (DN)Puede mejorar la verificación de certificados de servidor a través dela coincidencia del Nombre distinguido (DN). Para activar lacoincidencia de DN del servidor, debe especificar el DN del servidorde fondo al crear la conexión (junction) SSL con ese servidor.Aunque la coincidencia de DN es una configuración opcional, esmuy recomendable que se implemente esta función con laautenticación mutua a través de las conexiones (junctions) SSL.

Durante la verificación de certificados de servidor, el DN contenidoen el certificado se compara con el DN definido por la conexión(junction). La conexión con el servidor de fondo falla si los dos DNno coinciden.

Para activar la coincidencia de DN del servidor, especifique el DNdel servidor de fondo cuando cree la conexión (junction) SSLmediante la opción–D “<DN>” . Para preservar los espacios enblanco de la cadena, especifique la cadena de DN entre comillas. Porejemplo:–D “/C=US/O=Tivoli/OU=SecureWay/CN=Policy Director”

La opción–D sólo es apropiada cuando se utiliza con la opción–Ko –B.

WebSEAL se autentica con el certificado de clienteUtilice la opción–K para activar la autenticación de WebSEAL conel servidor de fondo con conexión (junction) a través del certificadode cliente.–K “<etiqueta-clave>”

Las condiciones para este ejemplo son:

¶ El servidor de fondo está configurado para que requiera laverificación de la identidad de WebSEAL con un certificado decliente.


6.C


WebS

EA

L

¶ WebSEAL está configurado (webseald.conf) para que utilice uncertificado de cliente específico para autenticarse en el servidorde fondo (ssl-keyfile-label).

¶ Es muy recomendable que configure la conexión (junction) parala coincidencia de DN (–D).

La opción–K utiliza un argumento que especifica la etiqueta clavedel certificado requerido tal como está almacenada en la base dedatos de claves de GSKit. Utilice la utilidadiKeyman para agregarcertificados nuevos en la base de datos de claves. Utilice elparámetrossl-keyfile-labeldel archivo de configuraciónwebseald.conf para configurar la etiqueta de clave.

Debe especificar el argumento de etiqueta clave entre comillas. Porejemplo:–K “cert1_Tiv”

Consulte el apartado “Configuración de los parámetros de la base dedatos de claves para WebSEAL” en la página 46.

WebSEAL se autentica con una cabecera de BAUtilice la opción–B –U “<nombre-usuario>” –W “<contraseña>”para activar la autenticación de WebSEAL mediante la autenticaciónbásica.–B –U “<nombre-usuario>” –W “<contraseña>”

Las condiciones para este ejemplo son:

¶ El servidor de fondo está configurado para que requiera laverificación de la identidad de WebSEAL con una cabecera deBA.

¶ No configure la conexión (junction) con ninguna opción–b. (Sinembargo, internamente la opción–B utiliza –b filter .)

¶ WebSEAL está configurado para pasar la información deidentidad en una cabecera de BA para autenticarse en el servidorde fondo.

¶ Es muy recomendable que configure también la conexión(junction) para la coincidencia de DN (–D).

170 Versión 3.8

Debe especificar los argumentos de nombre de usuario y contraseñaentre comillas. Por ejemplo:–U “WS1” –W “abCde”

Gestión de la información de identidad del cliente através de conexiones (junctions)

Se puede configurar una conexión (junction) para especificar lainformación de identidad del cliente en cabeceras de BA. La opción–b permite cuatro argumentos posibles: filter, supply, ignore, gso.Encontrará información detallada acerca de estos argumentos en elapartado “Configuración de cabeceras de BA para soluciones deinicio de sesión único” en la página 207.

La opción–b tiene un impacto sobre los valores de la conexión(junction) para la autenticación mutua y debe tener en cuenta lacombinación correcta de las opciones.

Utilización de –b supply¶ La autenticación de WebSEAL mediante la cabecera de BA no

se permite con esta opción. Esta opción utiliza la cabecera deBA para el nombre de usuario y una contraseña “simulada” delcliente original.

¶ La autenticación de WebSEAL mediante el certificado de clientese permite con esta opción.

Utilización de –b ignore¶ La autenticación de WebSEAL mediante la cabecera de BA no

se permite con esta opción. Esta opción utiliza la cabecera deBA para el nombre de usuario y una contraseña del clienteoriginal.


Utilización de –b gso¶ La autenticación de WebSEAL mediante la cabecera de BA no

se permite con esta opción. Esta opción utiliza la cabecera de


6.C


WebS

EA

L

BA para la información de nombre de usuario y contraseñaproporcionada por el servidor GSO.


Utilización de –b filter¶ Internamente, la opción–b filter se utiliza cuando se establece

la autenticación de WebSEAL para utilizar la información decabecera de BA.

La cabecera de BA de WebSEAL se utiliza para todas lastransacciones HTTP subsiguientes. En el servidor de fondo,WebSEAL aparece conectado en todo momento.


¶ Si el servidor de fondo requiere una identidad de cliente real(del navegador), se pueden utilizar las variables de CGIHTTP_IV_USER, HTTP_IV_GROUP y HTTP_IV_CREDS.Para los scripts y servlets, utilice las cabeceras HTTP específicasde Policy Director correspondientes: iv-user, iv-groups eiv-creds.

Creación de conexiones (junctions) proxy TCP y SSLPuede crear conexiones (junctions) WebSEAL que permitan lacomunicación para pasar por topologías de red que utilizanservidores proxy HTTP o HTTPS. Puede configurar la conexión(junction) para gestionar peticiones como comunicación TCPestándar o comunicación SSL protegida.

El comandocreate requiere uno de los siguientes argumentos para laopción type para establecer una conexión (junction) basada en TCPo en SSL a través de un servidor proxy:

¶ –t tcpproxy

¶ –t sslproxy

172 Versión 3.8

Los comandoscreate y add requieren que las siguientes opciones yargumentos identifiquen el servidor proxy y el servidor Web dedestino:

–H <nombre-host> Nombre de host DNS o dirección IP del servidorproxy.

–P <puerto> Puerto TCP del servidor proxy.

–h <nombre-host> Nombre de host DNS o dirección IP del servidorWeb de destino.

–p <puerto> Puerto TCP del servidor Web de destino. Elvalor predeterminado es80 para conexiones(junctions) TCP;443 para conexiones (junctions)SSL.

Ejemplo de conexión (junction) proxy TCP (especificado en unalínea):pdadmin> server task <nombre-servidor> create –t tcpproxy–H clipper –P 8081 –h www.ibm.com –p 80 /ibm

Ejemplo de conexión (junction) proxy SSL (especificado en unalínea):pdadmin> server task <nombre-servidor> create –t sslproxy–H clipper –P 8081 –h www.ibm.com –p 443 /ibm

Client WebSEALWeb

Server

www.ibm.com

Secure Domain

-H and -P

ProxyServer

Clipper Internet

-h and -pjunction at /ibm

Figura 24. Ejemplo de conexión (junction) proxy


6.C


WebS

EA

L

Conexiones (junctions) de WebSEAL a WebSEAL através de SSL

Policy Director da soporte a conexiones (junctions) SSL entre unservidor WebSEAL frontal y un servidor WebSEAL de fondo. Utilicela opción–C con el comandocreate para conectar los dos servidoresWebSEAL a través de SSL y proporcionar autenticación mutua.

Ejemplo:pdadmin> server task <nombre-servidor> create –t ssl –C –h serverA /jctA

La autenticación mutua se produce en las dos etapas siguientes:

¶ El protocolo SSL permite al servidor WebSEAL de fondoautenticarse en el servidor WebSEAL frontal a través de sucertificado de servidor.

¶ La opción–C activa el servidor WebSEAL frontal para pasar lainformación de identidad al servidor WebSEAL de fondo en unacabecera de Autenticación básica (BA).

Además, la opción–C activa las funciones de la opción–c que lepermite colocar la identidad de cliente específica de Policy Directory la información de pertenencia a grupos en la cabecera HTTP de lapetición destinada al servidor WebSEAL de fondo. Los parámetrosde cabecera son iv-user, iv-groups e iv-creds. Consulte el apartado“Especificación de la identidad del cliente en cabeceras HTTP (–c)”en la página 177.

Las siguientes condiciones son aplicables a las conexiones(junctions) de WebSEAL a WebSEAL:

¶ La conexión (junction) sólo es apropiada con el tipo de conexión–t ssl o –t sslproxy.

¶ Ambos servidores WebSEAL deben compartir un registro LDAPo DCE común. Esto permite al servidor WebSEAL de fondoautenticar la información de identidad de servidor WebSEALfrontal.

174 Versión 3.8

Opciones de conexión (junction) adicionalesPuede proporcionar las siguientes funciones de conexión (junction)WebSEAL con opciones adicionales:

¶ “Cómo forzar una nueva conexión (junction) (–f)” en la página175

¶ “Especificación de la identidad del cliente en cabeceras HTTP(–c)” en la página 177

¶ “Especificación de la dirección IP del cliente en cabeceras HTTP(–r)” en la página 179

¶ “Transferencia de cookies de sesión a servidores de portal conconexión (junction) (–k)” en la página 180

¶ “Soporte para direcciones URL no sensibles a mayúsculas yminúsculas (–i)” en la página 181

¶ “Proceso de direcciones URL a partir de scripts y aplicacionesde cliente (–j)” en la página 182

¶ “Gestión de direcciones URL relativas al servidor concorrelación de conexiones (junctions)” en la página 187

¶ “Soporte para conexiones (junction) con información de estado(–s, –u)” en la página 189

¶ “Especificación de UUID de servidor de fondo para conexiones(junctions) con información de estado (–u)” en la página 190

¶ “Conexión (junction) con sistemas de archivos de Windows(–w)” en la página 194

Cómo forzar una nueva conexión (junction) (–f)Debe utilizar la opción–f si desea forzar una nueva conexión(junction) que sobrescriba una conexión (junction) existente.

Sirva el siguiente ejemplo (el nombre del servidor eswebsealA) parailustrar este procedimiento:

1. Inicie la sesión enpdadmin:


6.C


WebS

EA

L

# pdadminpdadmin> loginEscriba el ID de usuario: sec_masterEscriba la contraseña:pdadmin>

2. Utilice el comandoserver task list para mostrar todos los puntosde conexión (junction) actuales:pdadmin> server task websealA list/

3. Utilice el comandoserver task showpara mostrar los detalles dela conexión (junction):pdadmin> server task websealA show /Punto de conexión (junction): /Tipo: LocalLímite de hardware de conexión (junction): 0 - se utilizará el


valor globalThreads de trabajo activos: 0Directorio raíz: /opt/pdweb/www/docs

4. Cree una conexión (junction) local nueva para sustituir el puntode conexión (junction) actual (la opción-f es necesaria para quese fuerce una nueva conexión (junction) que sobrescriba laconexión (junction) existente):pdadmin> server task websealA create -t local -f -d /tmp/docs /Se ha creado una conexión (junction) en /

5. Visualice el punto de conexión (junction) nuevo:pdadmin> server task websealA list/

6. Visualice los detalles de esta conexión (junction):pdadmin> server task websealA show /Punto de conexión (junction): /Tipo: LocalLímite de hardware de conexión (junction): 0 - se utilizará el


valor globalThreads de trabajo activos: 0Directorio raíz: /tmp/docs

176 Versión 3.8

Especificación de la identidad del cliente encabeceras HTTP (–c)

La opción–c le permite insertar información de pertenencia a grupose identidad de cliente específica de Policy Director en las cabecerasHTTP de las peticiones destinadas a los servidores de terceros conconexión (junction). La información de cabecera HTTP de PolicyDirector activa las aplicaciones de servidores de terceros conconexión (junction) para realizar acciones específicas del usuariobasadas en la identidad de Policy Director del cliente.

El servidor de fondo debe convertir la información de cabeceraHTTP en un formato de variable de entorno para que lo utilice unservicio del servidor de fondo. Para convertir la información decabecera en un formato de variable de entorno CGI, sustituya todoslos guiones (-) por caracteres de subrayado (_) y agregue “HTTP” alprincipio de la cadena. El valor de la cabecera HTTP se transformaen el valor de la nueva variable de entorno.

Campos decabecera HTTP

específicos de PD

Equivalentes de variablede entorno CGI

Descripción

iv-user = HTTP_IV_USER = Nombre corto o largo del cliente. El valorpredeterminado es “Unauthenticated” si elcliente no está autenticado (desconocido).

iv-groups = HTTP_IV_GROUPS = Lista de grupos a los que pertenece elcliente. Consta de entradas entre comillasseparadas por comas.

iv-creds = HTTP_IV_CREDS = Estructura de datos opacos codificadosque representan una credencial de PolicyDirector. Proporciona credenciales paraservidores remotos para que lasaplicaciones de medio nivel puedanutilizar la API Authorization para llamar aAuthorization Service. Consulte lapublicaciónTivoli SecureWay PolicyDirector Authorization ADK DeveloperReference.


6.C


WebS

EA

L

Las entradas de cabecera HTTP específicas de Policy Director estándisponibles para los programas CGI como variables de entornoHTTP_IV_USER, HTTP_IV_GROUPS y HTTP_IV_CREDS. Sidesea información sobre otros productos de entornos de aplicaciones,consulte la documentación del producto para obtener instruccionesacerca de la extracción de cabeceras de peticiones HTTP.

Sintaxis –cLa opción–c especifica los datos de cabecera HTTP específicos dePolicy Director que se envían al servidor de aplicaciones de fondo.–c <tipos-cabecera>

Los argumentostipos-cabecerason: all, iv_user, iv_user_l,iv_groups e iv_creds.

Argumento Descripción

iv_user Proporciona el nombre de usuario (forma corta) comocampoiv-user de la cabecera HTTP de la petición.

iv_user_l Proporciona el DN completo del usuario (forma larga)como campoiv-user de la cabecera HTTP de lapetición.

iv_groups Proporciona la lista de grupos del usuario como campoiv-groups de la cabecera HTTP de la petición.

iv_creds Proporciona la información de credencial del usuariocomo campoiv-creds de la cabecera HTTP de lapetición.

Nota: utilice iv-user o iv-user-l, pero no ambos.

La opción–c all inserta los tres tipos de información de identidad enla cabecera HTTP (en este caso se utiliza el formato de nombrecorto (iv_user)).

Nota: separe los argumentos múltiples sólo con comas. No inserteespacios.

Ejemplos:

178 Versión 3.8

–c all

–c iv_creds

–c iv_user,iv_groups

–c iv_user_l,iv_groups,iv_creds

Especificación de la dirección IP del cliente encabeceras HTTP (–r)

La opción–r permite insertar información de dirección IP de clienteen las cabeceras HTTP de las peticiones destinadas a los servidoresde aplicaciones con conexión (junction). La información de cabeceraHTTP de Policy Director activa las aplicaciones de servidores deterceros con conexión (junction) para realizar acciones basadas enesta información de dirección IP.

El servidor de fondo debe convertir la información de cabeceraHTTP en un formato de variable de entorno para que lo utilice unservicio del servidor de fondo. Para convertir la información decabecera en un formato de variable de entorno CGI, sustituya todoslos guiones (-) por caracteres de subrayado (_) y agregue “HTTP” alprincipio de la cadena. El valor de la cabecera HTTP se transformaen el valor de la nueva variable de entorno.

Nota: el valor de la dirección IP no representa siempre la direcciónde la máquina cliente de origen. El valor de la dirección IPpuede representar la dirección de un servidor proxy o untraductor de direcciones de red (NAT).

Campo de cabeceraHTTP específico de

PD

Equivalente de variablede entorno CGI

Descripción

iv-remote-address HTTP_IV_REMOTE_ADDRESS

Dirección IP del cliente. Este valor IPpuede representar la dirección IP de unservidor proxy o un traductor dedirecciones de red (NAT).


6.C


WebS

EA

L

La opción–r especifica que se envíe la dirección IP de la peticiónentrante al servidor de aplicaciones de fondo. Esta opción se expresasin argumentos.

Transferencia de cookies de sesión a servidores deportal con conexión (junction) (–k)

Un portal Web es un servidor que ofrece una amplia gama derecursos y servicios personalizados. La opción–k permite enviar lacookie de sesión de Policy Director (establecida originalmente entreel cliente y WebSEAL) a un servidor de portal de fondo. Esta opciónexiste actualmente para dar soporte directamente a la integración deWebSEAL con la solución Plumtree Corporate Portal.

Cuando un cliente solicita una lista de recursos personales desde elservidor de portal, el servidor de portal crea la lista accediendo a losrecursos que se encuentran en otros servidores de aplicaciones desoporte, que están también protegidos por WebSEAL. La cookie desesión permite al servidor de portal ejecutar un inicio de sesiónúnico ininterrumpido en estos servidores de aplicaciones, en nombredel cliente.

La opción–k se incluye, sin argumentos, cuando se crea la conexión(junction) entre WebSEAL y el servidor de portal de fondo.

Condiciones que se deben tener en cuenta en la configuración delservidor de portal:

¶ Para acceder mediante nombre de usuario y contraseña, senecesita la autenticación de formularios. No se debe utilizar laautenticación básica (BA).

¶ El parámetrossl-id-sessionsen la stanza[session]del archivo deconfiguraciónwebseald.conf debe estar establecido en “no”. Enla comunicación HTTPS, este valor exige el uso de una cookiede sesión, en lugar del ID de sesión SSL, para mantener elestado de sesión.

¶ Si el servidor de portal tiene delante un clúster WebSEAL, activela cookie de tipo recuperación tras error. La cookie derecuperación tras error contiene información cifrada de

180 Versión 3.8

credenciales que permite realizar con éxito la autenticación concualquier servidor WebSEAL replicado que procese la petición.

Soporte para direcciones URL no sensibles amayúsculas y minúsculas (–i)

De forma predeterminada, Policy Director trata las direcciones URLcomo sensibles a mayúsculas y minúsculas al aplicar los controles deacceso. La opción–i se utiliza para especificar que WebSEAL debetratar las direcciones URL como sensibles a mayúsculas yminúsculas al gestionar una petición a un servidor de fondo conconexión (junction).

Cuando establezca esta opción en la conexión (junction), WebSEALno distinguirá entre los caracteres en mayúsculas y minúsculas alanalizar las direcciones URL. De forma predeterminada, se esperaque los servidores Web sean sensibles a mayúsculas y minúsculas.

Aunque la mayoría de los servidores HTTP dan soporte a laespecificación de HTTP que define la dirección URL como sensiblea mayúsculas y minúsculas, algunos servidores HTTP tratan lasdirecciones URL como no sensibles.

Por ejemplo, en los servidores no sensibles a mayúsculas yminúsculas, estas dos direcciones URL:http://server/sales/index.htm

http://server/SALES/index.HTM

aparecen como la misma. Este comportamiento requiere que unadministrador defina los mismos controles de acceso (ACL) enambas direcciones URL.

Al conectarse a un servidor de terceros con la opción–i, WebSEALtrata las direcciones URL dirigidas a ese servidor como sensibles amayúsculas y minúsculas.


6.C


WebS

EA

L

Proceso de direcciones URL a partir de scripts yaplicaciones de cliente (–j)

Este apartado describe cómo WebSEAL gestiona los vínculos arecursos del servidor de fondo absolutos y relativos al servidorgenerados por un script.

¶ “Información sobre el problema” en la página 182

¶ “Gestión de direcciones URL relativas al servidor con cookies deconexión (junction)” en la página 184

¶ “Gestión de direcciones URL absolutas con filtro de scripts” enla página 185

¶ “Gestión de direcciones URL relativas al servidor concorrelación de conexiones (junctions)” en la página 187

Información sobre el problemaCuando un cliente accede a un servidor Web con conexión(junction), la información devuelta puede ser el resultado del HTML,una aplicación de cliente (applet) o un script. Los lenguajes decreación de scripts de Web son Javascripts, VBscripts, ASP, JSP yActiveX.

Cualquier página generada por HTML, un script o una applet puedecontener vínculos (direcciones URL) a otros recursos de ese servidorde fondo o a otro sitio. Pueden aparecer expresiones de direcciónURL en los siguientes formatos:

¶ absoluto

¶ relativo

¶ relativo al servidor

Un vínculo que vuelva al servidor de fondo sólo será correcto si ladirección URL es relativa o contiene información que identifique laconexión (junction). WebSEAL debe examinar las direcciones URLcontenidas en esta gran variedad de información generada yproporcionar información de identidad de la conexión (junction)cuando sea apropiado.

182 Versión 3.8

Las direcciones URL expresadas en formatorelativo no requierennunca ningún tipo de manipulación por parte de WebSEAL. Losvínculos al servidor de fondo expresados en formatoabsoluto orelativo al servidor no son correctos porque la dirección URLoriginal no contiene información acerca de la conexión (junction).Estos vínculos aparecen incorrectamente como peticiones de objetosubicados en el servidor WebSEAL local.

Ejemplo de expresiones de dirección URL relativas (el vínculosiempre será correcto):abc.html ../abc.html

./abc.html sales/abc.html

Ejemplo de expresión de dirección URL absoluta (el vínculo requiereinformación sobre la conexión (junction)):http://www.tivoli.com/abc.html

Ejemplo de expresiones de dirección URL relativas al servidor (elvínculo requiere información sobre la conexión (junction)):/abc.html /accounts/abc.html

WebSEAL gestiona direcciones URL absolutas y relativas al servidorgeneradas dinámicamente de las siguientes maneras:

¶ Orígenes HTML estáticos

Puesto que HTML es texto sin formato y se analiza fácilmente,WebSEAL agrega automáticamente al principio la informaciónde conexión correcta en la dirección URL, cuando es apropiado.Consulte el apartado “Filtro de direcciones URL HTML estáticasde los servidores con conexión (junction)” en la página 197.

¶ Orígenes de scripts y aplicaciones de cliente

Debido a la complejidad de los scripts, no es eficaz paraWebSEAL filtrar expresiones de dirección URL incrustadasabsolutas o relativas al servidor cuando pasan del servidor defondo al cliente. WebSEAL se debe configurar para queproporcione información de conexión (junction), cuando seaapropiado.


6.C


WebS

EA

L

Nota: es recomendable que todos los programadores de scripts deWeb utilicen vínculosrelativos (ni absolutos ni relativos alservidor) para las direcciones URL generadas dinámicamente.

Gestión de direcciones URL relativas al servidor concookies de conexión (junction)

En el siguiente ejemplo, un script ubicado en el servidor de fondogenera dinámicamente una expresión de dirección URL relativa alservidor. WebSEAL no puede manipular este código incrustado y lopasa al cliente. El cliente ve una dirección URL expresadaincorrectamente, puesto que no incluye la información de conexión(junction).

Si el cliente solicita el recurso especificado por este vínculo,WebSEAL presumirá incorrectamente que el vínculo apunta a unapágina local. Cuando no encuentre la página, devolverá el error “Noencontrado” al cliente.

La opción–j proporciona una solución basada en cookies paragestionar las direcciones URL relativas al servidor que se hangenerado dinámicamente mediante un script de Web en el servidorcon conexión (junction) y se ejecutan en la máquina del cliente.

Sintaxis general:pdadmin> server task <nombre-servidor> create ... –j ...

Para cada petición, se envía una cookie conexión-identificador alcliente. La cookie contiene la siguiente variable y valor:

Client

WebSEAL Application Server(serves Javascript)

Dynamically generatedserver-relative URL:

/abc.html

/jctA

Client incorrectly receives:/webseal/abc.html

Figura 25. Dirección URL generada por el script sin filtro

184 Versión 3.8

IV_JCT_<nombre-servidor-fondo> = </nombre-conexión>

Cuando el cliente realiza una petición mediante esta dirección URL,WebSEAL procesa la dirección URL en su formato original. Al noencontrar el recurso, WebSEAL vuelve a intentar inmediatamente lapetición mediante la información de conexión (junction)proporcionada por la cookie. Con la información de conexión(junction) correcta en la expresión de dirección URL, el recurso selocaliza correctamente.

El diagrama siguiente muestra esta solución para filtrar direccionesURL relativas al servidor:

WebSEAL proporciona una solución alternativa no basada en cookiespara gestionar las direcciones URL relativas al servidor. Consulte elapartado “Gestión de direcciones URL relativas al servidor concorrelación de conexiones (junctions)” en la página 187.

Gestión de direcciones URL absolutas con filtro de scriptsWebSEAL requiere una configuración adicional para gestionar lasdirecciones URL absolutas generadas dinámicamente a través de unaconexión (junction). El archivo de configuraciónwebseald.confcontiene un parámetro que activa o desactiva el filtro de direccionesURL absolutas:

Client


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

Figura 26. Filtro de direcciones URL relativas al servidor


6.C


WebS

EA

L

[script-filtering]script-filter = no

El filtro de scripts está desactivado de manera predeterminada. Paraactivarlo, establezca:script-filter = yes

Nota: también debe utilizar la opción–j para crear la conexión(junction) con el servidor de fondo. Se envía una cookieconexión-identificador al cliente, aunque el mecanismo defiltro de scripts no la necesita.

El mecanismoscript-filter espera direcciones URL absolutas con unformato estándar de esquema, servidor, recurso:http://server/resource

El mecanismoscript-filter sustituye las partes de esquema yservidor del vínculo por la información de conexión (junction)correcta./nombre-conexión/recurso

Esta solución requiere una carga de proceso adicional y puedeafectar el rendimiento de forma negativa. Limite el uso delparámetroscript-filter sólo a las conexiones (junctions) querequieran soporte para el filtro de direcciones URL absolutas.

El diagrama siguiente muestra esta solución de filtro de direcciónURL:

186 Versión 3.8

Gestión de direcciones URL relativas al servidor concorrelación de conexiones (junctions)

Policy Director proporciona una alternativa a la solución basada encookies para el filtro de direcciones URL relativas al servidor. Puedecrear y activar una tabla de correlaciones de conexiones (junction)que asigne recursos de destino específicos a los nombres deconexión (junction).

WebSEAL comprueba la información de ubicación en la direcciónURL relativa al servidor con los datos contenidos en la tabla decorrelaciones de conexiones (junction). Si la información de ruta deacceso de la dirección URL coincide con una entrada de la tabla,WebSEAL dirige la petición a la conexión (junction) asociada conesa ubicación.

La tabla es un archivo de texto ASCII denominadojmt.conf. Laubicación de este archivo se especifica en la stanza[junction] delarchivo de configuraciónwebseald.conf:jmt-map = lib/jmt.conf

Client


Script containingabsolute URL:

http://server/abc.html

Client receives:/jctA/abc.html

Request Request

Client makes requestusing link:

/jctA/abc.html

abc.htmlsuccessfully located

script-filtering=yesWebSEAL reformats link to:

/jctA/abc.html

1

2

3

/jctAwith -j option

Figura 27. Filtro de direcciones URL absolutas


6.C


WebS

EA

L

El formato para la entrada de datos en la tabla consta del nombre deconexión, un espacio y el patrón de ubicación del recurso. Tambiénse pueden utilizar caracteres comodín para expresar el patrón deubicación del recurso.

En el ejemplo siguiente del archivo de configuración decorrelaciones de conexión, dos servidores de fondo están conectadosa WebSEAL en/jctA y /jctB :#jmt.conf#<nombre-conexión> <patrón-ubicación-recurso>/jctA /documents/release-notes.html/jctA /travel/index.html/jctB /accounts/*/jctB /images/weather/*.jpg

La tabla de correlacionesjmt.conf original es un archivo vacío.Cuando haya agregado datos en el archivo, deberá utilizar elcomandojmt load para “cargar” los datos y que WebSEAL conozcala nueva información.pdadmin> server task <nombre-servidor> jmt loadLa tabla JMT se ha cargado correctamente.

Las siguientes condiciones son aplicables a la solución de tabla decorrelaciones de conexiones (junctions):

¶ Esta solución no requiere la opción– -j ni la cookie de conexión(junction).

¶ La tabla de correlaciones requiere la configuración y activaciónpor parte de un administrador de seguridad.

¶ Esta solución no gestiona los vínculos creados con direccionesURL absolutas.

¶ La coincidencia del patrón de ubicación del recurso debe serexclusiva en el espacio Web local y los servidores deaplicaciones Web con conexión (junction).

¶ Si hay una entrada de patrón duplicada en el archivo, la tabla decorrelaciones no se cargará. Sin embargo WebSEAL seguiráejecutándose.

188 Versión 3.8

¶ Si se produce algún error al cargar la tabla de correlaciones, éstano estará disponible. Sin embargo WebSEAL seguiráejecutándose.

¶ Si la tabla de correlaciones está vacía o hay algún error en lasentradas de la tabla, ésta no se cargará. Sin embargo WebSEALseguirá ejecutándose.

¶ Cualquier error que se produzca al cargar la tabla decorrelaciones producirá entradas de servicio en el archivo deregistro del servidor WebSEAL (webseald.log).

Soporte para conexiones (junction) con informaciónde estado (–s, –u)

La mayoría de las aplicaciones preparadas para Web mantienen un“estado” para una secuencia de peticiones HTTP de un cliente. Esteestado se utiliza, por ejemplo, para:

¶ Seguir el progreso de un usuario a través de los campos de unformulario de entrada de datos generado por un programa CGI

¶ Mantener el contexto de un usuario al realizar una serie deconsultas en la base de datos

¶ Mantener una lista de elementos en una aplicación de compra enlínea donde un usuario navega de manera aleatoria y seleccionaartículos para comprar

Los servidores que ejecutan aplicaciones preparadas para Web sepueden replicar para mejorar el rendimiento a través delcompartimento de cargas. Cuando el servidor WebSEAL proporcionauna conexión (junction) con esos servidores de fondo replicados,debe asegurarse de que todas las peticiones contenidas en la sesióndel cliente se envían al servidor correcto y no se distribuyen enservidores de fondo replicados según las normas de equilibrio decarga.

De forma predeterminada, Policy Director equilibra la carga delservidor de fondo al distribuir peticiones por todos los servidoresreplicados disponibles. Policy Director utiliza un algoritmo de


6.C


WebS

EA

L

“menos ocupado”. Este algoritmo dirige cada petición nueva alservidor con menos conexiones en curso.

El indicador–s del comandocreate sobrescribe esta norma deequilibrio de carga y crea una “conexión (junction) con informaciónde estado” que garantiza que las peticiones del cliente se envíen almismo servidor durante toda la sesión. Cuando se produce lapetición inicial del cliente, WebSEAL coloca una cookie en elsistema del cliente que contiene el UUID del servidor de fondodesignado. Cuando el cliente realiza peticiones futuras al mismorecurso, la información de UUID de la cookie garantiza que laspeticiones se dirijan de forma coherente al mismo servidor de fondo.

La opción–s es apropiada para un solo servidor WebSEAL frontalcon múltiples servidores de fondo conectados al mismo punto deconexión (junction). Observe que una vez creada la conexión(junction) inicial con información de estado, se utiliza el comandoadd sin la opción–s para conectar los servidores de fondo replicadosrestantes al mismo punto de conexión (junction).

Si el caso incluye varios servidores WebSEAL frontales, todosconectados a los mismos servidores de fondo, debe utilizar la opción–u para especificar correctamente cada UUID de servidor de fondocon cada servidor WebSEAL frontal. Consulte el apartado“Especificación de UUID de servidor de fondo para conexiones(junctions) con información de estado (–u)”.

Especificación de UUID de servidor de fondo paraconexiones (junctions) con información de estado(–u)

Cuando se crea una conexión (junction) nueva con un servidor deaplicaciones Web de fondo, WebSEAL suele generar un identificadoruniversal único (UUID) para identificar el servidor de fondo. EsteUUID se utiliza internamente y también para mantener conexiones(junctions) con información de estado (create –s).

Cuando se produce la petición inicial del cliente, WebSEAL colocauna cookie en el sistema del cliente que contiene el UUID delservidor de fondo designado. Cuando el cliente realiza peticiones

190 Versión 3.8

futuras al mismo recurso, la información de UUID de la cookiegarantiza que las peticiones se dirijan de forma coherente al mismoservidor de fondo.

La gestión de conexiones (junctions) con información de estado pasaa ser más compleja cuando hay varios servidores WebSEAL frontalesconectados a varios servidores de fondo. Normalmente, cadaconexión (junction) entre un servidor WebSEAL frontal y unservidor de fondo genera un UUID exclusivo para el servidor defondo. Esto significa que un solo servidor de fondo tendrá un UUIDdiferente en cada servidor WebSEAL frontal.

Si hay varios servidores frontales es necesario un mecanismo deequilibrio de carga para distribuir la carga entre los dos servidores.Por ejemplo, se podría establecer un “estado” inicial en un servidorde fondo a través del servidor WebSEAL 1 mediante un UUIDespecífico.

Sin embargo, si el mecanismo de equilibrio de carga dirige unafutura petición del mismo cliente a través del servidor WebSEAL 2,el “estado” dejará de existir, a menos que el servidor WebSEAL 2utilice el mismo UUID para identificar el mismo servidor de fondo.Normalmente, no sucede así.

La opción–u le permite proporcionar el mismo UUID para unservidor de fondo específico en cada servidor WebSEAL frontal.

WebSEAL

ApplicationServer 1

(UUID1)

ApplicationServer 2

(UUID2)

ClientStateful

JunctionsCookiewith

UUID2

Figura 28. Las conexiones (junctions) con información de estado utilizan UUID deservidor de fondo


6.C


WebS

EA

L

Por ejemplo, tenemos dos servidores WebSEAL frontales, replicados,cada uno con una conexión (junction) con información de estado condos servidores de fondo. Al crear la conexión (junction) coninformación de estado entre el servidor WebSEAL 1 y el servidor defondo 2, se genera un UUID exclusivo (UUID A) para identificar elservidor de fondo 2. Sin embargo, cuando se crea una conexión(junction) con información de estado entre el servidor WebSEAL 2 yel servidor de fondo 2, se genera un UUID (UUID B) nuevo ydistinto para identificar el servidor de fondo 2.

Se producirá un error en el “estado” establecido entre un cliente y elservidor de fondo 2, mediante el servidor WebSEAL 1 si se dirigeuna petición posterior del cliente a través del servidor WebSEAL 2.

Aplique el siguiente proceso para especificar un UUID durante lacreación de una conexión (junction):

1. Cree una conexión (junction) del servidor WebSEAL 1 con elservidor de fondo.

Utilice create –sy add.

2. Visualice el UUID generado para cada servidor de fondo duranteel paso 1.

WebSEAL-1

ApplicationServer 2

StatefulJunctions

WebSEAL-2

UUID B

ApplicationServer 1UUID A

Figura 29. UUID distintos

192 Versión 3.8

Utilice show.

3. Cree una conexión (junction) del servidor WebSEAL 2 con cadaservidor de fondo y especifique los UUID identificados en elpaso 2.

Utilice create –s –uy add –u.

En la figura siguiente, tanto WebSEAL-1 como WebSEAL-2 conocenel servidor de fondo 1 como UUID 1. Y tanto WebSEAL-1 comoWebSEAL-2 conocen el servidor de fondo 2 como UUID 2.

Ejemplo:En el siguiente ejemplo,

¶ WebSEAL-1 se denomina WS1

¶ WebSEAL-2 se denomina WS2

¶ El servidor de fondo 1 se denomina APP1

¶ El servidor de fondo 2 se denomina 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

(Aparecerá UUID1 y UUID2)

WebSEAL-1

ApplicationServer 2

(UUID 2)

StatefulJunctions

LoadBalancing

Mechanism

WebSEAL-2

Client

Cookiewith

UUID 2

ApplicationServer 1

(UUID 1)

Figura 30. Especificación de UUID de servidor de fondo para conexiones (junctions)con información de estado


6.C


WebS

EA

L

pdadmin> server task webseald-WS2 create –t tcp –h APP1 –u <UUID1>–s /mnt

pdadmin> server task webseald-WS2 add –h APP2 –u <UUID2> /mnt

Cuando un cliente establece una conexión con información de estadocon el servidor de fondo 2, recibe una cookie que contiene UUID2.El ejemplo anterior garantiza que el cliente se conectará siempre alservidor de fondo 2, independientemente de si las peticionesposteriores se dirigen a través de WebSEAL-1 o de WebSEAL-2.

Conexión (junction) con sistemas de archivos deWindows (–w)

WebSEAL realiza comprobaciones de seguridad en las peticiones declientes a los servidores de fondo con conexión (junction) basadas enlas rutas de acceso a los archivos especificadas en la dirección URL.Se puede producir un compromiso en esta comprobación deseguridad porque los sistemas de archivos de Win32 proporcionandos métodos distintos para acceder a los nombres de archivo largos.

El primer método reconoce el nombre de archivo entero(abcdefghijkl.txt). El segundo método utiliza el formato denombre de archivo 8.3 antiguo para la compatibilidad con versionesanteriores (abcdefx1.txt).

Al crear conexiones (junctions) en entornos Windows, es importanterestringir el control de acceso a una sola representación de objeto yno permitir la posibilidad de “puertas traseras” que omitan elmecanismo de seguridad.

La opción–w desactiva el formato de nombre de archivo 8.3. Unusuario no puede evitar una ACL explícita en un nombre de archivolargo utilizando el formato corto (8.3) del nombre de archivo. Elservidor devolverá un error “403 No autorizado” en cualquiernombre de archivo de formato corto especificado.

En Windows, los archivos con nombre de archivo “foo.” son tratadosde la misma forma que el nombre de archivo “foo”. La opción–welimina los puntos finales de los nombres de archivo en las

194 Versión 3.8

direcciones URL antes de enviar la petición al servidor de fondo.Las comprobaciones de ACL se basan en el nombre de archivo sin elpunto final.

Nota: el problema derivado del hecho que Win32 no sea sensible amayúsculas y minúsculas (abcde.txt = AbCdE.txt) secorrige con la opción–i. Consulte el apartado “Soporte paradirecciones URL no sensibles a mayúsculas y minúsculas(–i)” en la página 181.

Ejemplo:En Windows NT 4.0, se puede acceder también al archivo\Archivos de programa\Company Inc.\Release.Notes a travésde las siguientes rutas de acceso:

1. \archivos de programa\company inc.\release.notes

2. \archivos de programa\company inc\release.notes

3. \archivx1\companx2\releasx3.not

El ejemplo 1 anterior muestra el efecto de la “no sensibilidad amayúsculas y minúsculas” que se corrige con la opción–i (no –w).

El ejemplo 2 muestra cómo Windows NT omite un punto final deextensión.

El ejemplo 3 muestra cómo Windows NT crea un alias (para lacompatibilidad con DOS) que no contiene espacios en el nombre dearchivo y se ajusta al formato 8.3.

La opción–w corrige los posibles agujeros de seguridad mostradosen los ejemplos 2 y 3. Laopción–w indica que se deben omitir lospuntos finales y que no se debe permitir el acceso a los nombres dearchivo cortos que contienen un carácter tilde (x) en las direccionesURL de la petición para este servidor con conexión (junction).


6.C


WebS

EA

L

Notas técnicas sobre el uso de conexiones(junctions) WebSEAL

¶ “Montaje de varios servidores en la misma conexión (junction)”en la página 196

¶ “Filtro de direcciones URL HTML estáticas de los servidorescon conexión (junction)” en la página 197

¶ “Excepciones para aplicar permisos a través de las conexiones(junctions)” en la página 198

¶ “Autenticación de certificados a través de las conexiones(junctions)” en la página 199

Montaje de varios servidores en la misma conexión(junction)

Puede montar varios servidores replicados en el mismo punto deconexión (junction). Puede haber cualquier cantidad de servidoresmontados en el mismo punto.

Todos los servidores montados en un punto de conexión (junction)deben ser réplicas (espacios Web reflejados) y deben utilizar elmismo protocolo: HTTP o HTTPS. No monte servidores diferentesen el mismo punto de conexión (junction).

Desde el espacio Web del servidor principal de Policy Director,acceda a las páginas que pertenecen a los servidores con conexión(junction). Debe poder acceder a estas páginas (dependiendo,evidentemente, de los permisos) y las páginas deben aparecer deforma coherente. Si no se encuentra alguna página, o si ésta semodifica ocasionalmente, significa que la página no se ha replicadode manera correcta.

Compruebe que exista el documento y que sea idéntico en el árbolde documentos de los dos servidores replicados.

196 Versión 3.8

Filtro de direcciones URL HTML estáticas de losservidores con conexión (junction)

Sólo se filtrarán los documentos estáticos de tipo MIME “text/html”que se reciban de los servidores con conexión (junction).

Hay 2 conjuntos de direcciones URL que WebSEAL puedemodificar: absolutas y relativas al servidor.

¶ Las direcciones URL relativas al servidor indican una posiciónde dirección URL en relación con la raíz de documentos delservidor con conexión (junction), como por ejemplo:/dir/archivo.html

Estas direcciones URL se modifican para reflejar el punto deconexión (junction) del servidor con conexión (junction), comopor ejemplo:/jct/dir/archivo.html

¶ Las direcciones URL absolutasindican una posición dedirección URL en relación con un nombre de HOST o direcciónIP y un puerto de red, como por ejemplo:http://nombre_servidor[:puerto]/archivo.html, o bienhttps://nombre_servidor[:puerto]/archivo.html

Estas direcciones URL se modifican según el siguiente conjunto denormas:

1. Si la dirección URL es HTTP y el host/puerto coincide con unservidor TCP con conexión (junction), se modificará la direcciónURL para que refleje el punto de conexión, como por ejemplo:/jct/...

2. Si la dirección URL es HTTPS y el host/puerto coincide con unservidor SSL con conexión (junction), se modificará la direcciónURL para que refleje el punto de conexión (junction), como porejemplo:/jct/...

3. Sólo se filtrarán las direcciones URL para pares deINDICADOR/Atributo definidos en el archivoiv.conf.


6.C


WebS

EA

L

4. Los indicadores META se filtran siempre para peticiones deactualización, por ejemplo:

5. Si un indicador BASE contiene un atributo HREF, el indicadorse eliminará de la respuesta al cliente.

Los parámetros para filtrar direcciones URL a través de servidorescon conexión (junction) se encuentran en la stanza[filter-url] delarchivo de configuraciónwebseald.conf.

La stanza[filter-url] contiene una lista de indicadores HTML que elservidor WebSEAL filtra o modifica para ajustar las direccionesURL absolutas obtenidas a través de un servidor con conexión(junction).

Todos los indicadores HTML utilizados habitualmente se configurande forma predeterminada. Es posible que el administrador necesiteagregar indicadores HTML adicionales que contengan las direccionesURL.

Consulte también el apartado “Proceso de direcciones URL a partirde scripts y aplicaciones de cliente (–j)” en la página 182.

Excepciones para aplicar permisos a través de lasconexiones (junctions)

Algunos permisos de Policy Director no se pueden aplicar a travésde una conexión (junction). No puede controlar, por ejemplo, laejecución de un script CGI con el permisox o un listado dedirectorios con el permisol. WebSEAL no tiene ninguna forma dedeterminar con precisión si un objeto solicitado de un servidor defondo es, por ejemplo, un archivo de programa CGI, un listado dedirectorios dinámico o un objeto HTTP normal.

El acceso a los objetos a través de conexiones (junctions), incluidoslos programas CGI y los listados de directorios, sólo se controlamediante el permisor .

<META HTTP-EQUIV=”Refresh” CONTENT=”5;URL=http://server/url”>

198 Versión 3.8

Autenticación de certificados a través de lasconexiones (junctions)

Durante la instalación, WebSEAL se configura con un certificado deprueba no predeterminado. El certificado de prueba se designa comoel certificado activo de servidor mediante el parámetrowebseal-cert-keyfile-labelen la stanza[ssl] del archivo deconfiguraciónwebseald.conf.

Si un servidor de aplicaciones de fondo con conexión (junction)requiere que WebSEAL se identifique con un certificado de cliente,deberá crear, instalar y etiquetar primero este certificado utilizando lautilidad iKeyman. A continuación, configure la conexión (junction)con la opción–K <etiqueta-clave>. Consulte el apartado“Conexiones (junctions) SSL autenticadas mutuamente” en la página167

Si la conexión (junction) no se configura con–K, GSKit gestionauna petición para la autenticación mutua, enviando automáticamenteel certificado “predeterminado” contenido en la base de datos delarchivo de claves. Si esta no es la respuesta adecuada, deberáasegurarse de que no haya certificados marcados como“predeterminado” (una marca de asterisco) en la base de datos dearchivos de claves (pdsrv.kdb).

En resumen:

¶ Identifique todos los certificados necesarios por el nombre deetiqueta.

¶ No marque ningún certificado en la base de datos del archivo declaves como “predeterminado”.

¶ Controle la respuesta del certificado de servidor de WebSEALcon el parámetrowebseal-cert-keyfile-label.

¶ Controle la respuesta del certificado de cliente de WebSEALmediante la opción de conexión (junction) –K.


6.C


WebS

EA

L

Utilización de query_contents con servidores deterceros

Si desea proteger los recursos del espacio Web de aplicaciones deterceros mediante el servicio de seguridad de Policy Director, debeproporcionar a WebSEAL información acerca del contenido delespacio Web de terceros.

Un programa CGI denominadoquery_contentsproporciona estainformación. El programaquery_contentsbusca el contenido delespacio Web de terceros y proporciona esta información deinventario a Web Portal Manager en WebSEAL. El programa estáincluido en la instalación de WebSEAL, pero se debe instalarmanualmente en el servidor de terceros. Hay distintos tipos dearchivos de programa disponibles, dependiendo de si el servidor deterceros se ejecuta en UNIX o Windows.

El gestor del espacio de objetos de Web Portal Manager ejecutaautomáticamentequery_contentscada vez que el fragmento delespacio de objetos protegidos que representa la conexión (junction)se amplía en el panel de gestión del espacio de objetos. Ahora queWeb Portal Manager conoce el contenido del espacio de aplicacionesde terceros, puede ver esta información y aplicar las plantillas depolítica a los objetos apropiados.

Instalación de query_contentsLa instalación dequery_contentssuele ser muy fácil. La instalaciónincluye copiar uno o dos archivos del servidor de Policy Director enel servidor de terceros y editar un archivo de configuración.

El siguiente directorio de Policy Director contiene una plantilla delprograma:

UNIX: <ruta-instalación>/www/lib/query_contents

Windows: <ruta-instalación>\www\lib\query_contents

200 Versión 3.8

El contenido del directorio incluye:

Archivo Descripción

query_contents.exe Programa ejecutable principal para sistemasWin32. Debe instalarse en el directoriocgi-bin del servidor Web de terceros.

query_contents.sh Programa ejecutable principal para sistemasUNIX. Debe instalarse en el directoriocgi-bin del servidor Web de terceros.

query_contents.c Código fuente. Se incluye el código fuente porsi es necesario modificar el comportamiento dequery_contents. En la mayoría de los casos,no será necesario.

query_contents.html Archivo de ayuda en formato HTML.

query_contents.cfg Archivo de configuración de muestra queidentifica la raíz de documentos para elservidor Web.

Instalación de query_contents en servidores UNIX deterceros

Localice el script de shell denominadoquery_contents.sh en elsiguiente directorio:<ruta-instalación>/www/lib/query_contents

1. Copiequery_contents.sh en un directorio/cgi-bin enfuncionamiento en el servidor Web de terceros.

2. Elimine la extensión.sh.

3. Establezca el bit de ejecución de UNIX para la cuenta deadministración del servidor Web.

Instalación de query_contents en servidores Win32 deterceros

Localice el programa ejecutable denominadoquery_contents.exe yel archivo de configuración denominadoquery_contents.cfg en elsiguiente directorio:

Windows: <ruta-instalación>\www\lib\query_contents


6.C


WebS

EA

L

1. Asegúrese de que el servidor Web de terceros tenga el directorioCGI configurado correctamente.

2. Para las comprobaciones, asegúrese de que exista un documentoválido en la raíz de documentos del servidor Web de terceros.

3. Copiequery_contents.exe en el directorio CGI del servidorWeb de terceros.

4. Copiequery_contents.cfg en el directorio Windows.

En la tabla siguiente aparecen los valores predeterminados deeste directorio:

Sistema operativo Directorio Windows

Windows 95 c:\windows

Windows NT 3.5x c:\winnt35

Windows NT 4.x c:\winnt

5. Edite el archivoquery_contents.cfg para especificarcorrectamente el directorio raíz de documentos para el servidorWeb de terceros.

Actualmente, el archivo contiene ejemplos de entradas para losservidores Microsoft Internet Information Server y NetscapeFastTrack. Las líneas de este archivo que empiecen con un puntoy coma (;) son comentarios y el programaquery_contentslasomitirá.

Comprobación de la configuración1. Desde un indicador de MS-DOS de la máquina Win32, ejecute el

programaquery_contentsdel directorio CGI de la siguienteforma:MSDOS> query_contents dirlist=/

Aparecerá algo similar a la siguiente salida:100index.htmlcgi-bin//pics//

202 Versión 3.8

El número 100 es un estado de retorno que indica el éxito de laoperación. Es importante ver el número 100 al menos como elprimer valor (y tal vez el último).

Si, por lo contrario, ve un código de error, ello indica que elarchivo de configuración no se encuentra en la ubicación correctao bien no contiene una entrada de raíz de documentos válida.Compruebe la configuración del archivoquery_contents.cfg yasegúrese de que la raíz de documentos existe.

2. Desde un navegador, especifique la siguiente dirección URL:http://<nombre-máquina-win32>/cgi-bin/query_contents.exe?dirlist=/

Debería aparecer el mismo resultado que en el paso anterior. Sino es así, la configuración de CGI del servidor Web no escorrecta. Consulte la documentación del servidor para corregir elproblema.

Personalización de query_contentsLa tarea dequery_contentses devolver el contenido de losdirectorios incluidos en una petición de dirección URL.

Por ejemplo, para obtener el contenido del directorio raíz del espacioWeb de un servidor, el navegador ejecutaquery_contentsen unadirección URL, como por ejemplo:http://servidor-de-terceros/cgi-bin/query_contents?dirlist=/

El script query_contentslleva a cabo las acciones siguientes:

1. Lee$SERVER_SOFTWARE, una variable de entorno CGIestándar, para determinar el tipo de servidor.

Según el tipo de servidor Web, la variable$DOCROOTDIR seestablece en una ubicación raíz de documentos típica.

2. Lee la variable de entorno$QUERY_STRING de la direcciónURL solicitada para obtener laoperación solicitada y obtener laruta de acceso de objetos.


6.C


WebS

EA

L

El valor de la operación se almacena en la variable$OPERATION y la ruta de acceso de objetos en$OBJPATH.En el ejemplo anterior,$OPERATION esdirlist y $OBJPATHes “/”.

3. Muestra un listado de directorios (ls) de la ruta de acceso deobjetos y coloca el resultado en la salida estándar para utilizarlaen el servidor de Policy Director. Las entradas que indicansubdirectorios tienen una barra inclinada doble (//) agregada.

Ésta es una salida típica:100index.htmlcgi-bin//pics//

El número 100 es un estado de retorno que indica el éxito de laoperación.

Personalización del directorio raíz de documentosUNIX:

Para personalizarquery_contents.sh para el servidor UNIX, esposible que deba modificar el valor del directorio raíz dedocumentos.

Si query_contentsdevuelve un estado de error (un número distintode 100) y no incluye ningún archivo en la lista, examine el script ymodifique la variable$DOCROOTDIR , si es necesario, para quecoincida con la configuración del servidor.

Si el directorio raíz de documentos está especificado correctamente yse sigue produciendo un error en el script, es posible que laespecificación de la ubicación decgi-bin sea incorrecta. Examine lavariable$FULLOBJPATH y modifique el valor asignado a éstapara que refleje la ubicación correcta decgi-bin.

Windows:

Para personalizarquery_contents.exe para el servidor Windows,modifique el archivoquery_contents.cfg.

204 Versión 3.8

Funcionalidad adicionalEl código fuente del programaquery_contents(query_contents.c)se distribuye con Policy Director sin necesidad de pagar ningúnderecho.

Se pueden agregar funciones adicionales a este programa para darsoporte a las características especiales de algunos servidores Web deterceros. Estas características son:

1. Correlación de directorios, cuando un subdirectorio que no estépor debajo del directorio raíz de documentos se correlacione enel espacio Web.

2. Generación de un espacio Web que no esté basado en el sistemade archivos.

Puede tratarse de un servidor Web que aloje una base de datos.

Protección de query_contentsPolicy Director utiliza el programa CGI dequery_contentsparavisualizar espacios de objetos de servidor Web con conexión(junction) en Web Portal Manager. Es muy importante proteger estearchivo para que no sea ejecutado por usuarios no autorizados.

Debe establecer una política de seguridad que sólo permita a laidentidad (pdmgrd) del Management Server tener acceso alprogramaquery_contents. La siguiente ACL de ejemplo(query_contents_acl) cumple estos requisitos:group ivmgrd-servers Tl

user sec_master dbxTrlcam

Utilice la utilidad pdadmin para asociar esta ACL con el objeto dequery_contents.sh (UNIX) o query_contents.exe (Windows) en losservidores con conexión (junction). Por ejemplo (UNIX):pdadmin> acl attach /WebSEAL/<host>/<nombre-junction>/query_contents.shquery_contents_acl


6.C


WebS

EA

L

206 Versión 3.8

Soluciones de inicio de sesiónúnico en la Web

Cuando se implementa WebSEAL como servidor proxy paraproporcionar protección a un dominio seguro, a menudo se debenproporcionar soluciones para un inicio de sesión único en losrecursos Web. En este capítulo se describen las soluciones de iniciode sesión único para el espacio Web de una configuración proxy deWebSEAL. Algunos ejemplos son las conexiones (junction)especialmente configuradas, el inicio de sesión global y LTPA.

Índice de temas:

¶ “Configuración de cabeceras de BA para soluciones de inicio desesión único” en la página 207

¶ “Utilización de Global Sign-on (GSO)” en la página 215

¶ “Inicio de sesión único en IBM WebSphere (LTPA)” en lapágina 220

Configuración de cabeceras de BA para solucionesde inicio de sesión único

Este apartado trata las posibles soluciones para crear configuracionesde inicio de sesión único a través de conexiones (junctions)WebSEAL mediante las opciones–b.

¶ “Conceptos del inicio de sesión único (SSO)” en la página 208

7


7.S

olucionesde

iniciode

sesiónúnico

enla

Web

¶ “Especificación de la identidad del cliente en cabeceras de BA”en la página 209

¶ “Especificación de la identidad del cliente y de la contraseñagenérica” en la página 210

¶ “Reenvío de la información de cabecera de BA de clienteoriginal” en la página 212

¶ “Eliminación de la información de cabecera de BA de cliente”en la página 213

¶ “Especificación de nombres de usuario y contraseñas de GSO”en la página 214

Conceptos del inicio de sesión único (SSO)Cuando se encuentra un recurso protegido en un servidor deaplicaciones Web de fondo, se puede requerir a los clientes quesolicitan ese recurso que realicen inicios de sesión múltiples: unopara el servidor WebSEAL y uno para el servidor de fondo. Cadainicio de sesión solicita distintas identidades de inicio de sesión.

El problema de administrar y mantener identidades de inicios desesión múltiples puede resolverse habitualmente con un mecanismode inicio de sesión único (SSO). Una solución de inicio de sesiónúnico permite al usuario acceder a un recurso, con independencia dela ubicación del recurso, utilizando sólo un inicio de sesión inicial.Los requisitos de inicio de sesión posteriores de los servidores defondo se gestionan de una forma transparente para el usuario.

Client WebSEALWeb

ApplicationServer

Junction

Login #1 Login #2

Figura 31. Inicios de sesión múltiples

208 Versión 3.8

Especificación de la identidad del cliente encabeceras de BA

Puede configurar conexiones (junctions) WebSEAL paraproporcionar al servidor de fondo información de identidad decliente original o modificada. El conjunto de opciones–b le permiteproporcionar información de identidad de cliente específica encabeceras de Autenticación básica (BA) de HTTP.

Como administrador, debe analizar la arquitectura de la red y losrequisitos de seguridad y determinar las respuestas a las preguntassiguientes:

1. ¿El servidor de fondo requiere información de autenticación?

(WebSEAL utiliza la cabecera de Autenticación básica HTTPpara transferir la información de autenticación.)

2. Si el servidor de fondo requiere información de autenticación,¿de dónde proviene esa información?

(¿Qué información coloca WebSEAL en la cabecera HTTP?)

3. ¿La conexión entre WebSEAL y el servidor de fondo debe sersegura?

(¿Conexión (junction) TCP o SSL?)

Después de la autenticación inicial entre el cliente y WebSEAL,WebSEAL puede crear una cabecera de Autenticación básica. Lapetición utiliza esta cabecera nueva mientras sigue por la conexión(junction) hasta el servidor de fondo. Utilice las opciones–b paraindicar la información de autenticación específica que se proporcionaen esta cabecera nueva.


7.S

olucionesde

iniciode

sesiónúnico

enla

Web

Especificación de la identidad del cliente y de lacontraseña genérica

–b supply

La opción–b supply indica a WebSEAL que debe proporcionar elnombre de usuario de Policy Director autenticado (identidad originaldel cliente) con una contraseña estática genérica (“simulada”). Lacontraseña de cliente original no se utiliza en este ejemplo.

Una contraseña genérica elimina la administración de contraseñas yda soporte a la aplicación en base al usuario. La contraseña“simulada” está establecida en el parámetrobasicauth-dummy-passwddel archivo de configuraciónwebseald.conf:[junction]basicauth-dummy-passwd = <contraseña>

Este ejemplo presupone que el servidor de fondo requiere laautenticación de una identidad de Policy Director. Al correlacionarun usuario de cliente con un usuario de Policy Director conocido,WebSEAL gestiona la autenticación para el servidor de fondo yproporciona una solución de inicio de sesión único en todo eldominio.

Existen las siguientes condiciones para esta solución:

Client WebSEALWeb

ApplicationServer

New BA header withWebSEAL-supplied

authenticationinformation

Initial authentication resultsin Policy Director

credentials

junction

request request

Figura 32. Especificación de información de autenticación en los servidores de fondo

210 Versión 3.8

¶ WebSEAL está configurado para que proporcione al servidor defondo el nombre de usuario contenido en la petición de clienteoriginal más una contraseña genérica (“simulada”).

¶ La contraseña “simulada” está configurada en el archivo deconfiguraciónwebseald.conf.

¶ El registro del servidor de fondo debe reconocer la identidad dePolicy Director proporcionada en la cabecera de BA HTTP.

¶ Debido a que se pasa información de autenticación confidencial(nombre de usuario y contraseña) a través de la conexión(junction), la seguridad de la conexión es importante. Es muyrecomendable una conexión (junction) SSL.

LimitacionesSe utiliza la misma contraseña “simulada” de Policy Director paratodas las peticiones; todos los usuarios tienen la misma contraseñaen el registro del servidor de fondo. El uso de la contraseña“simulada” común no ofrece ninguna base para que el servidor deaplicaciones compruebe la legitimidad del inicio de sesión del clientecon ese nombre de usuario.

Client WebSEALSSL junction Web

ApplicationServer

WebSEAL supplies PolicyDirector identity and "dummy"

password

anyauthentication

mechanism

Registry Registry

Figura 33. La cabecera de BA contiene la identidad y una contraseña ″simulada″


7.S

olucionesde

iniciode

sesiónúnico

enla

Web

Si los clientes pasan siempre a través de WebSEAL para acceder alservidor de fondo, esta solución no presenta ningún problema deseguridad. Sin embargo, es importante proteger físicamente elservidor de fondo de otras posibles formas de acceso.

Puesto que este ejemplo no tiene ninguna seguridad de nivel decontraseñas, el servidor de fondo debe fiarse implícitamente deWebSEAL para verificar la legitimidad del cliente.

El registro del servidor de fondo debe reconocer también la identidadde Policy Director para aceptarla.

Reenvío de la información de cabecera de BA decliente original

–b ignore

La opción–b ignore indica a WebSEAL que debe pasar la cabecerade Autenticación básica (BA) de cliente original directamente alservidor de fondo sin ninguna interferencia. WebSEAL puedeconfigurarse para que autentique esta información de cliente de BA oignore la cabecera de BA que proporciona el cliente y la reenvíe, sinmodificarla, al servidor de fondo.

Nota: no es un mecanismo de inicio de sesión único verdadero, sinoun inicio de sesión directo al servidor de terceros,transparente para WebSEAL.


¶ El servidor de fondo requiere información de identidad decliente mediante BA.

El servidor de fondo enviará una tentativa de Autenticaciónbásica al cliente. El cliente responde con la información denombre de usuario y contraseña que el servidor WebSEAL pasasin ninguna modificación.

¶ El servidor de fondo mantiene sus propias contraseñasproporcionadas por el cliente.

212 Versión 3.8

¶ WebSEAL está configurado para que proporcione al servidor defondo el nombre de usuario y la contraseña contenidos en lapetición de cliente original.

¶ Debido a que se pasa información de autenticación confidencial(nombre de usuario y contraseña) a través de la conexión(junction), la seguridad de la conexión es importante. Es muyrecomendable una conexión (junction) SSL.

Eliminación de la información de cabecera de BA decliente

–b filter

La opción–b filter indica a WebSEAL que elimine toda lainformación de cabecera de Autenticación básica de las peticiones decliente antes de reenviar las peticiones al servidor de fondo. En esteejemplo, WebSEAL es el único proveedor de seguridad.


¶ La Autenticación básica está configurada entre el cliente yWebSEAL

¶ El servidor de fondo no requiere la Autenticación básica

Client WebSEALjunction Web

ApplicationServer

WebSEAL supplies originalclient authentication (BA)

information

BasicAuthentication

Registry Registry

Figura 34. WebSEAL reenvía la información de identidad de cliente original


7.S

olucionesde

iniciode

sesiónúnico

enla

Web

¶ Sólo se puede acceder al servidor de fondo a través deWebSEAL

¶ WebSEAL gestiona la autenticación en nombre del servidor defondo

Si necesita proporcionar al servidor de fondo alguna información decliente, puede combinar esta opción con la opción–c para insertar lainformación de identidad de cliente de Policy Director en campos decabecera HTTP. Consulte el apartado “Especificación de la identidaddel cliente en cabeceras HTTP (–c)” en la página 177.

Especificación de nombres de usuario y contraseñasde GSO

–b gso

La opción–b gsoindica a WebSEAL que debe proporcionar alservidor de fondo la información de autenticación (nombre deusuario y contraseña) obtenida de la configuración de un servidorpara gestionar el inicio de sesión global (GSO).


¶ Las aplicaciones de servidor de fondo requieren distintosnombres de usuario y contraseñas que no están contenidos en elregistro de WebSEAL.

Client WebSEALWeb

ApplicationServer

TCP or SSLjunction

BasicAuthentication

no authenticationrequired

WebSEAL removes originalclient identity information

from BA header

Figura 35. Eliminación de la información de cabecera de BA de cliente

214 Versión 3.8

¶ La seguridad es importante para WebSEAL y el servidor defondo.

Debido a que se pasa información de autenticación confidencial(nombre de usuario y contraseña) a través de la conexión (junction),la seguridad de la conexión es importante. Es muy recomendable unaconexión (junction) SSL.

Este mecanismo se describe detalladamente en el apartado“Utilización de Global Sign-on (GSO)”.

Utilización de Global Sign-on (GSO)Policy Director da soporte a una solución de inicio de sesión únicoflexible que incluye la posibilidad de proporcionar nombres deusuario y contraseñas alternativos al servidor de aplicaciones Web defondo.

Esta solución de inicio de sesión único está soportada eimplementada de dos formas, según el tipo de registro de usuarioutilizado:

¶ Dominio seguro con registro DCE: utilice el producto TivoliGlobal Sign-On (GSO)

¶ Dominio seguro con registro LDAP: el directorio LDAPproporciona el soporte para Global Sign-on

Global Sign-on garantiza a los usuarios el acceso a los recursos desistemas que están autorizados a utilizar, a través de un inicio desesión único. Concebido para grandes empresas que constan devarios sistemas y aplicaciones dentro de entornos de sistemasdistribuidos heterogéneos, GSO elimina la necesidad de los usuariosfinales de gestionar varios nombres de usuario y contraseñas.

La integración se consigue creando conexiones (junctions)“compatibles con GSO” entre WebSEAL y los servidores Web defondo. Primero se deben crear los recursos de GSO y los grupos derecursos de GSO mediante Web Portal Manager.


7.S

olucionesde

iniciode

sesiónúnico

enla

Web

Cuando WebSEAL recibe una petición para un recurso ubicado en elservidor con conexión (junction), WebSEAL pide al servidor GSO lainformación de autenticación apropiada. El servidor GSO contieneuna base de datos de correlaciones (para cada usuario registrado) queproporciona nombres de usuario y contraseñas alternativos pararecursos y aplicaciones específicos.

La siguiente figura muestra cómo se utiliza el mecanismo GSO pararecuperar nombres de usuario y contraseñas para recursos deaplicaciones de fondo.

1. El cliente se autentica en WebSEAL con una petición paraacceder a un recurso de aplicación en un servidor de fondo. Seobtiene una identidad de Policy Director.

Nota: el proceso de inicio de sesión único es independiente delmétodo de autenticación inicial.

2. WebSEAL pasa la identidad de Policy Director al servidor GSOo LDAP.

3. El servidor devuelve un nombre de usuario y contraseñaapropiados para el usuario y el recurso de aplicación solicitado.

4. WebSEAL inserta la información de nombre de usuario ycontraseña en la cabecera de Autenticación básica de HTTP de lapetición que se envía a través de la conexión (junction) con elusuario de fondo.

216 Versión 3.8

Correlación de la información de autenticaciónEl ejemplo siguiente muestra cómo GSO proporciona información deautenticación a WebSEAL. Si el usuario Michael desea ejecutar elrecurso de aplicacióntravel-app (consulte la Figura 36), WebSEALpide al servidor GSO / LDAP la información de autenticación paraMichael.

El servidor GSO / LDAP mantiene una base de datos completa deinformación de autenticación en forma de correlaciones de recursoscon información de autenticación específica. La información deautenticación es una combinación de nombre de usuario / contraseñaconocida comocredencial de recurso. Sólo los usuarios registradospueden crear las credenciales de recursos.

El servidor contiene una base de datos para Michael que correlacionael recursotravel-app con una credencial de recurso específica.

La siguiente tabla muestra la estructura de la base de datos decredenciales de recursos de GSO:

Junctions (-b gso)

WebSEAL

Client

Secure Domain

Resources:- accounts-app

- travel-app

HTTPSResources:

- expenses-app- payroll-app

HTTP

Host: sales_svr

Host: adm_svr

SSL junction provides encryptedcommunication

/

/sales

/admin

Policy DirectorIdentity

Username /Password

1

2

3

4

LDAP or GSOServer

Figura 36. Mecanismo de Global Sign-on


7.S

olucionesde

iniciode

sesiónúnico

enla

Web

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

En este ejemplo, GSO devuelve el nombre de usuario “mike” y lacontraseña “123” a WebSEAL. WebSEAL utiliza esta informacióncuando construye la cabecera de Autenticación básica en la peticiónenviada a través de la conexión (junction) al servidor de fondo.

Configuración de una conexión (junction) WebSEALpreparada para GSO

El soporte para GSO se configura en la conexión (junction) entreWebSEAL y un servidor de fondo.

Para crear una conexión (junction) que active GSO, utilice elcomandocreate con la opción–b gso. El ejemplo siguiente muestrala sintaxis para el comandocreate:create –t tcp –h <nombre-host> –b gso –T <recurso> <punto-conexión>

A continuación se muestra una lista de opciones para configurarconexiones (junctions) GSO:

Opciones Descripción

–b gso Especifica que GSO debe proporcionarinformación de autenticación para todas laspeticiones que pasan por esta conexión (junction).

–T <recurso/grupo-recursos>

Especifica el recurso o grupo de recursos de GSO.El nombre de recurso utilizado como argumentopara esta opción debe coincidir exactamente conel nombre de recursos tal como se lista en la basede datos de GSO. Necesario para conexiones(junctions) gso.

218 Versión 3.8

Se puede proteger una conexión (junction) utilizada en una soluciónWebSEAL/GSO a través de SSL aplicando también la opción–t sslal crear la conexión.

Es recomendable que utilice siempre conexiones (junctions) SSL conGSO para garantizar el cifrado de credenciales y todos los datos.

Ejemplos de conexiones (junctions) WebSEAL preparadaspara GSO

Para conectar el recurso de aplicacionestravel-app del hostsales_svrcon el punto de conexión (junction)/sales:create –t tcp –b gso –T travel-app –h sales_svr /sales

Para conectar el recurso de aplicacionespayroll-app del hostadm_svr con el punto de conexión (junction)/admin y proteger laconexión con SSL:create –t ssl –b gso –T payroll-app –h adm_svr /admin

Nota: en el ejemplo anterior, la opción–t ssl dicta el puertopredeterminado 443.

Configuración de la caché de GSOLa funcionalidad de la caché de Global Sign-on (GSO) permitemejorar el rendimiento de las conexiones (junctions) GSO en unentorno de carga elevada. De forma predeterminada, la caché deGSO está desactivada. Sin la mejora de la caché, se necesita unallamada al servidor LDAP para cada recuperación de información dedestino de GSO (nombre de usuario de GSO y contraseña de GSO).

Los parámetros para configurar la caché de GSO se encuentran en lastanza[gso-cache]del archivo de configuraciónwebseald.conf.Debe activar primero la caché. El resto de parámetros configuran eltamaño de la caché y los valores de tiempo de espera para lasentradas de la caché. Unos valores de tiempo de espera deinactividad y de duración más altos aumentan el rendimiento, perotambién el riesgo de exposición de la información en la memoria deWebSEAL. No active la caché de GSO si no se utilizan lasconexiones (junctions) GSO en su solución de red.


7.S

olucionesde

iniciode

sesiónúnico

enla

Web


gso-cache-enabled Activa y desactiva la funcionalidad dela caché de GSO. Los valores posiblesson “yes” y “no”. El valorpredeterminado es “no”.

gso-cache-size Establece el número máximo deentradas permitidas en la tabla hash dela caché. Establezca este valor para quese aproxime al valor máximo desesiones de usuario simultáneas queacceden a una aplicación a través deuna conexión (junction) GSO. Un valoralto utiliza más memoria pero permiteun acceso a la información más rápido.Cada entrada de caché consumeaproximadamente 50 bytes.

gso-cache-entry-lifetime Tiempo máximo (en segundos) quepuede permanecer en la caché unaentrada de caché, independientementede la actividad. Cuando la entrada decaché caduca, la siguiente petición delmismo usuario requerirá una nuevallamada al servidor LDAP.

gso-cache-entry-idle-timeout Tiempo máximo (en segundos) quepuede permanecer en la caché unaentrada de caché inactiva.

Inicio de sesión único en IBM WebSphere (LTPA)Policy Director WebSEAL puede proporcionar servicios deautenticación y autorización, y protección en un entorno IBMWebSphere. Si WebSEAL se coloca como frente de protección deWebSphere, los clientes que accedan se encontrarán con dos puntospotenciales de inicio de sesión. Por lo tanto, WebSEAL da soporte auna solución de inicio de sesión único para uno o más servidoresIBM WebSphere a través de las conexiones (junctions) WebSEAL.

WebSphere proporciona un mecanismo ligero de autenticación deterceros (LTPA) basado en cookies. Las conexiones (junctions)

220 Versión 3.8

WebSEAL se pueden configurar para dar soporte a LTPA yproporcionar soluciones de inicio de sesión único a los clientes.

Cuando un usuario realiza la petición de un recurso de WebSphere,el usuario debe autenticarse primero en WebSEAL. Si laautenticación es correcta, WebSEAL genera una cookie LTPA ennombre del usuario. La cookie LTPA, que sirve como señal deautenticación para WebSphere, contiene información de la identidaddel usuario y la contraseña. Esta información se cifra utilizando unaclave secreta protegida por contraseña que comparten WebSEAL y elservidor WebSphere.

WebSEAL inserta la cookie en la cabecera HTTP de la petición quese envía a través de la conexión (junction) a WebSphere. El servidorWebSphere de fondo recibe la petición, descifra la cookie y autenticaal usuario a partir de la información de identidad suministrada en lacookie.

Para aumentar el rendimiento, WebSEAL puede almacenar la cookieLTPA en la caché, y utilizar la cookie LTPA almacenada en la cachépara futuras peticiones durante la misma sesión de usuario. Puedeconfigurar los valores de tiempo de espera de duración y deinactividad (desocupado) para la cookie almacenada en la caché.

Configuración de una conexión (junction) LTPAEl inicio de sesión único en WebSphere a través de una cookie LTPArequiere los siguientes elementos de configuración:

1. Activar el mecanismo LTPA.

2. Proporcionar la ubicación del archivo de claves que se utilizapara cifrar la información de identidad.

3. Proporcionar la contraseña de este archivo de claves.

Estos tres requisitos de configuración se especifican en tres opcionesadicionales para el comandocreate de conexión (junction).

¶ La opción–A activa la conexión para que dé soporte a lascookies LTPA.


7.S

olucionesde

iniciode

sesiónúnico

enla

Web

¶ La opción y el argumento–F <“archivo-claves”> especifican elnombre completo de la ruta de ubicación (en el servidorWebSEAL) del archivo de claves utilizado para descifrar lainformación de identidad contenida en la cookie. La clavecompartida se crea originalmente en el servidor WebSphere y secopia de forma segura en el servidor WebSEAL. Consulte ladocumentación de WebSphere correspondiente para obtenerinformación más detallada sobre esta tarea.

¶ –Z <“ contraseña-archivo-claves”> especifica la contraseñanecesaria para abrir el archivo de claves.

La contraseña aparece como texto cifrado en el archivo XML deconexión (junction).

Utilice estas opciones, además de las otras opciones de conexión(junction) necesarias, cuando cree la conexión (junction) entreWebSEAL y el servidor WebSphere de fondo. Por ejemplo:create ... -A -F “/abc/xyz/key.file” -Z “abcdefg” ...

Configuración de la caché de LTPALa creación, el cifrado y el descifrado de las cookies LTPA introduceuna carga de proceso adicional. La funcionalidad de la caché deLTPA permite mejorar el rendimiento de las conexiones (junctions)LTPA en un entorno de carga elevada. De forma predeterminada, lacaché de LTPA está activada. Sin la mejora de la caché, se crea y secifra una nueva cookie LTPA para cada una de las siguientespeticiones de usuario.

Los parámetros para configurar la caché de LTPA se encuentran enla stanza[ltpa-cache] del archivo de configuraciónwebseald.conf.Los parámetros especifican el tamaño de la caché y los valores detiempo de espera para las entradas de la caché. Unos valores detiempo de espera de inactividad y de duración más altos aumentan elrendimiento, pero también el riesgo de exposición de la informaciónen la memoria de WebSEAL.

222 Versión 3.8


ltpa-cache-enabled Activa y desactiva la funcionalidad dela caché de LTPA. Los valores posiblesson “yes” y “no”. El valorpredeterminado es “yes”.

ltpa-cache-size Establece el número máximo deentradas permitidas en la tabla hash dela caché. Establezca este valor para quese aproxime al valor máximo desesiones de usuario simultáneas queacceden a una aplicación a través deuna conexión (junction) LTPA. Un valoralto utiliza más memoria pero permiteun acceso a la información más rápido.Cada entrada de caché consumeaproximadamente 50 bytes. El valorpredeterminado es 4096 entradas.

ltpa-cache-entry-lifetime Tiempo máximo (en segundos) quepuede permanecer en la caché unaentrada de caché, independientementede la actividad. Cuando la entrada decaché caduca, la siguiente petición delmismo usuario requerirá la creación deuna nueva cookie LTPA. El valorpredeterminado es 3600 segundos.

ltpa-cache-entry-idle-timeout Tiempo máximo (en segundos) quepuede permanecer en la caché unaentrada de caché inactiva. El valorpredeterminado es 600 segundos.

Notas técnicas sobre el inicio de sesión único deLTPA

¶ El archivo de claves contiene información sobre un servidorWebSphere específico. Cada conexión (junction) LTPA esespecífica para un servidor WebSphere. Si agrega más de unservidor al mismo punto de conexión (junction), todos losservidores compartirán el mismo archivo de claves.


7.S

olucionesde

iniciode

sesiónúnico

enla

Web

¶ Para que el inicio de sesión único sea correcto, WebSEAL y elservidor WebSphere deben compartir de alguna manera la mismainformación de registro.

¶ El servidor WebSphere es el responsable de configurar LTPA ycrear la clave secreta compartida. La participación de WebSEALengloba la conexión (junction) y la configuración de la caché.

224 Versión 3.8

Integración de aplicaciones

WebSEAL da soporte a la integración de aplicaciones de terceros através de las variables de entorno y a laposibilidad de direccionesURL dinámicas. WebSEAL amplía el rango de variables de entornoy cabeceras HTTP para hacer posible que las aplicaciones deterceros realicen operaciones basadas en la identidad de un cliente.Además, WebSEAL puede proporcionar el control de acceso en lasdirecciones URL dinámicas, como las que contienen el texto de laconsulta.

Índice de temas:

¶ “Soporte para la programación de CGI” en la página 226

¶ “Soporte para aplicaciones de un servidor de fondo” en la página228

¶ “Activación de los derechos empresariales dinámicos” en lapágina 230

¶ “Creación de un servicio de personalización personalizado” en lapágina 234

¶ “Especificación del control de acceso a las direcciones URLdinámicas” en la página 237

¶ “Ejemplo de dirección URL dinámica: Travel Kingdom” en lapágina 246

8


8.Integración

deaplicaciones

Soporte para la programación de CGIPara dar soporte a la programación de CGI, WebSEAL agrega tresvariables de entorno adicionales al conjunto de variables CGIestándar. Las aplicaciones CGI que se ejecuten en el servidorWebSEAL local o bien en un servidor de fondo con conexión(junction) pueden utilizar estas variables de entorno. Las variablesproporcionan información de usuario, grupo y credencial específicade Policy Director para la aplicación CGI.

En un servidor WebSEAL local, estas variables de entorno estándisponibles automáticamente para los programas CGI.

Las variables de entorno utilizadas por una aplicación CGI que seejecute en un servidor de terceros con conexión (junction) seproducen desde la información de cabecera HTTP pasada al servidordesde WebSEAL. Debe utilizar la opción–c para crear una conexión(junction) que dé soporte a la información de cabecera específica dePolicy Director en las peticiones HTTP destinadas a un servidor defondo.

Consulte también el apartado “Especificación de la identidad delcliente en cabeceras HTTP (–c)” en la página 177.

Variables de entorno adicionales específicas de Policy Director

Variables de entornode CGI

Descripción

HTTP_IV_USER Nombre de cuenta de usuario de Policy Directordel solicitante.

HTTP_IV_GROUPS Grupos de Policy Director a los que perteneceel solicitante. Especificados como lista degrupos separados por comas, cada grupo seespecifica entre comillas.

226 Versión 3.8

Variables de entornode CGI

Descripción

HTTP_IV_CREDS Estructura de datos opacos codificados querepresentan una credencial de Policy Director.Proporciona credenciales para servidoresremotos para que las aplicaciones de medionivel puedan utilizar la API Authorization parallamar a Authorization Service. Consulte lapublicaciónPolicy Director ADK DeveloperReference.

Variable REMOTE_USER en un servidor WebSEAL local:

En un entorno de servidor local controlado por WebSEAL, el valorde la variableHTTP_IV_USER listado anteriormente se incluyecomo valor para la variableREMOTE_USER estándar. Observe quela variableREMOTE_USER puede estar también presente en elentorno de una aplicación CGI que se ejecute en un servidor defondo con conexión (junction). Sin embargo, en esta situación,WebSEAL no controla su valor.

Variable de entornode CGI

Descripción

REMOTE_USER Contiene el mismo valor que el campoHTTP_IV_USER.

Windows: soporte para variables de entorno de WIN32Este apartado se aplica sólo a las conexiones (junctions)locales.

Windows no pone automáticamente todas las variables de entornodel sistema a disposición de procesos como las aplicaciones CGI.Habitualmente, las variables de entorno del sistema necesariasestarán presentes.

Sin embargo, si no se encuentra alguna de las variables de entornodel sistema de Windows que necesite en el entorno CGI, puedeponerlas explícitamente a disposición de los programas CGI a travésdel archivo de configuraciónwebseald.conf. Observe que las


8.Integración

deaplicaciones

variables de entorno de Policy Director mencionadas en el apartadoanterior están disponibles automáticamente en todas las plataformas.

Agregue las variables de entorno del sistema de Windows necesariasen la stanza[cgi-environment-variables] del archivo deconfiguraciónwebseald.conf. Utilice el siguiente formato:ENV = <nombre-variable>

Por ejemplo:[cgi-environment-variables]#ENV = SystemDriveENV = SystemRootENV = PATHENV = LANGENV = LC_ALLENV = LC_CTYPEENV = LC_MESSAGESENV = LOCPATHENV = NLSPATH

Las líneas sin comentarios se heredan en el entorno CGI.

Soporte para aplicaciones de un servidor de fondoWebSEAL proporciona también soporte para el código ejecutableque se ejecuta como componente incrustado de un servidor Web defondo. Entre los ejemplos de código ejecutable de servidor seincluyen:

¶ Servlets Java

¶ Cartuchos para Oracle Web Listener

¶ Plug-ins de servidor

Al crear una conexión (junction) con un servidor de fondo queutilice la opción–c, WebSEAL inserta información de pertenencia agrupos e identidad de cliente específica de Policy Director en lascabeceras HTTP de las peticiones destinadas a ese servidor.

La información de cabecera HTTP específica para Policy Directoractiva las aplicaciones de servidores de terceros con conexión

228 Versión 3.8

(junction) para realizar acciones específicas del usuario basadas en laidentidad de Policy Director del cliente.

WebSEAL proporciona las siguientes cabeceras HTTP específicaspara Policy Director:

Campos decabecera HTTP

específicos de PD

Descripción

iv-user = Nombre corto o largo del cliente. El valorpredeterminado es “Unauthenticated” si el cliente noestá autenticado (desconocido).

iv-groups = Lista de grupos a los que pertenece el cliente.Especificada como lista separada por comas degrupos especificados entre comillas.

iv-creds = Estructura de datos opacos codificados querepresentan una credencial de Policy Director.Proporciona credenciales para servidores remotospara que las aplicaciones de medio nivel puedanutilizar la API Authorization para llamar aAuthorization Service. Consulte la publicaciónTivoliSecureWay Policy Director Authorization ADKDeveloper Reference.

Estas cabeceras HTTP están disponibles para las aplicaciones CGIcomo variables de entornoHTTP_IV_USER, HTTP_IV_GROUPSy HTTP_IV_CREDS. Si desea información sobre otros entornos deaplicaciones que no son CGI, consulte la documentación asociada alproducto para obtener instrucciones acerca de la extracción decabeceras de peticiones HTTP.

Consulte también el apartado “Especificación de la identidad delcliente en cabeceras HTTP (–c)” en la página 177.


8.Integración

deaplicaciones

Activación de los derechos empresariales dinámicosLas empresas y sus socios a menudo deben compartir derechoscomunes como, por ejemplo, datos de socios (en las relaciones deempresa a empresa) o datos de clientes (en las relaciones de empresaa cliente).

¶ Los Derechos genéricosson atributos que describen lainformación que necesitan las aplicaciones proveedoras deservicios. Por ejemplo, la información de la cuenta de cliente ylos datos de facturación del cliente.

¶ Los Derechos de seguridadson atributos que proporcionancondiciones muy detalladas que se utilizan en la autorización delas peticiones de recursos. Ejemplos de estas condiciones son lasnormas empresariales de los usuarios, las restricciones delcontrol de accesos y las normas empresariales que definen uncontrato comercial entre socios.

Mediante una extensión del Servicio de autenticación en dominioscruzados (CDAS), Policy Director proporciona un mecanismoflexible que le permite incluir información de derechos, en forma deatributos indicador/valor ampliados, en credenciales de usuario en elpunto de autenticación. Las aplicaciones pueden extraer directamenteestos datos de la credencial utilizando la API de autorización. Paraobtener más información sobre la implementación de esta extensiónCDAS, consulte la publicaciónTivoli Policy Director WebSEALDeveloper Reference.

Creación de derechos empresariales a partir de datosLDAP

WebSEAL incorpora un mecanismo de derechos específico quepermite insertar información LDAP suplementaria definida por elusuario en una credencial de usuario como atributos ampliados. Acontinuación, estos atributos se pueden colocar en la cabecera HTTPde una petición enviada a un servidor de aplicaciones de fondo através de la conexión (junction).

230 Versión 3.8

¶ Los datos suplementarios, definidos por el usuario, de cualquiercampo de una cuenta de registro LDAP de usuario se añadencomo atributos ampliados a la credencial de Policy Director delusuario.

¶ WebSEAL está configurado para extraer estos datos de lacredencial y colocarlos en la cabecera HTTP de la petición queva a un servidor de fondo a través de una conexión (junction)WebSEAL.

¶ La aplicación de fondo puede extraer los datos de la cabecera sinnecesidad de ningún código especial ni la API de autorización.

La configuración de WebSEAL para insertar información LDAPsuplementaria en una cabecera HTTP implica dos pasos:

1. Recuperar los datos suplementarios del registro LDAP einsertarlos en la credencial de usuario en el inicio de sesión.

2. A partir de las condiciones específicas de la conexión (junction),se deben extraer los datos adecuados de la credencial einsertarlos en una cabecera HTTP de la petición que se envía através de la conexión (junction).

Inserción de datos LDAP suplementarios en una credencialHay dos métodos para colocar datos de usuario LDAPsuplementarios en una credencial:

1. Crear entradas en la stanza[ldap-ext-cred-tags] del archivo deconfiguraciónpd.conf que correlaciona datos LDAP específicoscon los campos en la credencial.

Este método se describe en este apartado.

2. Escribir un módulo CDAS personalizado que correlacione losdatos definidos por el usuario con los campos en la credencial.

Consulte la publicaciónTivoli Policy Director WebSEALDeveloper Referencepara obtener más información sobre laimplementación de esta extensión CDAS.

La stanza[ldap-ext-cred-tags] del archivo de configuraciónpd.confse utiliza para correlacionar datos específicos de la clase de objeto


8.Integración

deaplicaciones

LDAP inetOrgPerson con un campo de atributos definido por elusuario en la credencial del usuario. Los parámetros de esta stanzatienen el siguiente formato:<campo-credencial-personalizado> = <campo-inetOrgPerson>

En la misma credencial, el nombre de cada parámetrocampo-credencial-personalizadodefinido en el archivo deconfiguraciónpd.conf tiene el prefijo “tagvalue_”. Este prefijoimpide que haya conflictos con la otra información existente en lacredencial. Por ejemplo:

Datos de usuario LDAP de la clase deobjeto inetOrgPerson:

employeeNumber:09876

El nombre personalizado del campo dela credencial:

ldap-employee-number

Entradas de parámetro en la stanza[ldap-ext-cred-tags]:

ldap-employee-number = employeeNumber

Entrada y valor colocados en lacredencial de usuario:

tagvalue_ldap-employee-number:09876

¶ Esta funcionalidad requiere que el usuario se autentiquemediante el nombre y la contraseña de usuario LDAP. Elmecanismo de autenticaciónpasswd-ldapdebe estar activado.La biblioteca compartidalibldapauthn (ldapauthn) estácodificada para realizar búsquedas en la stanza[ldap-ext-cred-tags] del archivo de configuraciónpd.conf, paraobtener información suplementaria de la credencial definida porel usuario.

¶ Los datos LDAP pueden provenir de un campo estándar opersonalizado en la clase de objeto inetOrgPerson.

¶ Pueden colocarse varias entradas en la stanza[ldap-ext-cred-tags].

¶ Todos los atributos especificados en las entradas de la stanza secolocan en la credencial durante el inicio de sesión del usuario.

232 Versión 3.8

¶ Los nombres de los atributos LDAP no son sensibles amayúsculas y minúsculas.

¶ El nombre de los campos de credenciales es sensible amayúsculas y minúsculas.

Inserción de datos de credenciales en la cabecera HTTPLa información de credencial definida por el usuario que se hacreado en el apartado anterior se puede colocar en una cabeceraHTTP de la petición que se envía a través de la conexión (junction)al servidor de fondo. Esta fase implica dos tareas:

1. Configurar la conexión (junction) para permitir datos específicossuplementarios de credenciales. Esta tarea se consigue definiendolos atributos ampliados adecuados en el objeto de conexión(junction) del espacio de objetos protegidos de WebSEAL.

2. Extraer la información suplementaria adecuada de la credencial einsertar los datos en una cabecera HTTP de la petición.

La extracción de datos de credencial que se requiere en unaconexión (junction) específica se puede controlar utilizando atributosampliados en el objeto de conexión (junction). El nombre delatributo ampliado esHTTP-Tag-Value. Este atributo ampliadoutiliza el siguiente formato:<campo-credencial-personalizado>=<campo-cabecera-http>

El parámetrocampo-credencial-personalizadoaparece exactamentecomo en la stanza[ldap-ext-cred-tags] del archivo de configuraciónpd.conf. No se incluye el prefijo “tagvalue_”. El parámetro essensible a mayúsculas y minúsculas. El parámetrocampo-cabecera-httpespecifica el nombre de la cabecera HTTPutilizada para almacenar los datos. Por ejemplo:

Atributo ampliadoHTTP-Tag-Value enel objeto de conexión (junction):

ldap-employee-number=employee-id

Entrada y valor que aparecen en lacredencial de usuario:

tagvalue_ldap-employee-number:09876


8.Integración

deaplicaciones

Entrada y valor colocados en la cabeceraHTTP:

employee-id:09876

Cuando WebSEAL pasa una petición de usuario a un servidor deaplicaciones de fondo, busca los atributos ampliadosHTTP-Tag-Value configurados en el objeto de conexión (junction).

Para configurar una conexión (junction) con atributos ampliados, seutiliza el comandopdadmin object modify set attribute:pdadmin> object modify <nombre-obj> set attribute <nombre-atr> <valor-atr>

Por ejemplo:pdadmin> object modify /WebSEAL/WS1/junctionA set attributeHTTP-Tag-Value ldap-employee-number=employee-id

Se pueden pasar múltiples datos de atributos de usuario al servidorcon conexión (junction) utilizando varios comandospdadmin objectmodify set attribute para especificar múltiples atributos ampliadosHTTP-Tag-Value (se especifica un atributo por comando).

Creación de un servicio de personalizaciónpersonalizado

Un portal Web, o página de inicio, es un servicio de sitio Webintegrado que produce de forma dinámica una lista personalizada delos recursos Web disponibles para un usuario determinado. Losrecursos pueden incluir contenidos corporativos, servicios de soportey herramientas de aprendizaje. La salida del portal representa unalista personalizada de recursos a partir de los permisos de acceso delusuario concreto. La página de inicio presenta sólo aquellos recursosque tengan los permisos de acceso correctos para dicho usuario.

Las opciones de configuración de WebSEAL y el Servicio dederechos de API de autorización se pueden utilizar para crear unasolución de portal personalizada en un entorno de Policy Director.

El flujo de procesos para crear un servicio de portal WebSEALpersonalizado incluye los siguientes elementos:

234 Versión 3.8

1. Se crea una región específica del espacio de objetos protegidospara localizar el conjunto de objetos de recursos de portal.

2. Las ACL explícitas correspondientes se asocian con cada uno deestos objetos de recursos.

3. Se edita el archivo de configuración de WebSEAL para incluir ladirección URL del servicio del portal, la ruta del espacio deobjetos que contiene los recursos del portal y el bit de permisoque necesita el usuario para acceder a estos recursos.

4. Para cada petición de usuario a la dirección URL del portal,WebSEAL utiliza el Servicio de derechos de autorización parabuscar este espacio de objetos y producir una lista de recursosque cumplan las condiciones de autorización de este usuario.

5. WebSEAL coloca esta información enuna cabecera HTTPPD_PORTAL que se envía al servidor de fondo del portal conconexión (junction).

6. El servicio de portal personalizado (por ejemplo, un CGI o unservlet) que se encuentra en el servidor de fondo lee el contenidode la cabecera PD_PORTAL y, por ejemplo, correlaciona elcontenido con descripciones y vínculos de URL que se muestranal usuario en la página Web. Esta información representa la listapersonalizada de recursos disponibles para el usuario, a partir delos permisos de control de accesos.

Configuración de WebSEAL para un servicio depersonalización

1. Cree una conexión (junction) WebSEAL nueva en el servicio depersonalización. Por ejemplo:pdadmin> server task <nombre-servidor> create -t tcp-h portalhost.abc.com /portal-jct

2. Edite el archivo de configuraciónwebseald.conf para agregaruna nueva stanza[portal-map] :[portal-map]

3. La entrada en esta stanza identifica la dirección URL relativa alservidor del programa de servicios del portal y la región delespacio de objetos donde se buscan los recursos de portal


8.Integración

deaplicaciones

protegidos disponibles, seguido del permiso necesario para elacceso. Esta es la lista que se coloca en la cabeceraPD_PORTAL.[portal-map]<URL> = <región-espacio-objetos>:<permiso>

Nota: durante la búsqueda, sólo se seleccionan los objetos derecurso con ACL definidas explícitamente que contenganel permiso correspondiente para este usuario.

4. Después de agregar la stanza y las entradas de correlaciónadecuadas, se debe reiniciar WebSEAL (webseald).

Ejemplo de servicio de personalización¶ Cree una conexión (junction) en el servidor de portal:

pdadmin> server task webseald-WS1 -t ssl -h PORTAL1 /portal

¶ Defina la región del espacio de objetos protegidos de WebSEALque contiene los recursos disponibles para el servicio depersonalización: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

Nota: el argumento “ispolicyattachable” debe definirse como“yes” para cada uno de los recursos. El mecanismo debúsqueda sólo selecciona objetos de recursos cualificadoscon ACL definidas explícitamente.

¶ Configuración de WebSEAL (webseald.conf):[portal-map]/portal/servlet/PortalServlet = /Resources:r

¶ Dirección URL del portal que utiliza el usuario:https://WS1/portal/servlet/PortalServlet

236 Versión 3.8

Especificación del control de acceso a lasdirecciones URL dinámicas

El entorno Web actual proporciona a los usuarios acceso inmediato auna información que cambia rápidamente. Muchas aplicaciones Webgeneran dinámicamente direcciones URL (Uniform ResourceLocator) como respuesta a la petición de cada usuario. Estasdirecciones URLdinámicaspueden existir sólo durante un tiempocorto. A pesar de su naturaleza temporal, las direcciones URLdinámicas necesitan una gran protección contra el uso o acceso nodeseado.

Componentes de direcciones URL dinámicasAlgunas herramientas de aplicaciones Web sofisticadas utilizannavegadores Web estándar para comunicarse con servidores deaplicaciones a través de la interfaz CGI de un servidor Web.

Todas estas herramientas utilizan direcciones URL dinámicas comoelementos de formulario ocultos para comunicar la operaciónsolicitada (con su valor de parámetro) al servidor de aplicaciones.Una dirección URL dinámica amplía la dirección URL estándar coninformación acerca de la operación específica y sus valores deparámetros. El fragmento de la cadena de caracteres de consulta dela dirección URL proporciona operaciones, parámetros y valores parala interfaz de aplicaciones Web.

http://www.acme.com/sales/web/fortecgi.cgi?name=catalog&product=shirt&color=red

Protocol WebServer

Directory Pathto CGI Program

Operation, Parameters,and Values for WebApplication Interface

CGIProgram

File

Base URL Query String

Figura 37. Transferencia de datos a un gateway CGI mediante una dirección URL


8.Integración

deaplicaciones

Correlación de objetos ACL con direcciones URLdinámicas

WebSEAL utiliza el modelo de espacio de objetos protegidos y lasplantillas de política (ACL) para proteger las direcciones URLgeneradas dinámicamente, como las generadas por las peticiones dela base de datos. Cada petición a WebSEAL se resuelve en un objetoespecífico como primer paso en el proceso de autorización. UnaACL aplicada al objeto indica la protección necesaria en cualquierdirección URL dinámica correlacionada con ese objeto.

Puesto que las direcciones URL dinámicas sólo existentemporalmente, no es posible tener entradas para éstas en una basede datos de políticas de autorizaciones configuradas previamente.Policy Director resuelve este problema proporcionando unmecanismo por el cual las direcciones URL dinámicas puedencorrelacionarse con un solo objeto protegido estático.

Las correlaciones de objetos con patrones se guardan en un archivode texto sin formato:/opt/PolicyDirector/www/lib/dynurl.conf

La ubicación de este archivo (relativa a la raíz de servidor) estádefinida por el parámetrodynurl-map en la stanza[server] delarchivo de configuraciónwebseald.conf:[server]dynurl-map = lib/dynurl.conf

Debe crear este archivo, ya que no existe de forma predeterminada.La existencia de este archivo (con entradas) ofrece la posibilidad dedirecciones URL dinámicas.

Edite este archivo para modificar las correlaciones. Las entradas delarchivo tienen el formato:<objeto> <plantilla>

Policy Director utiliza un subconjunto de valores que cumplenpatrones específicos de shell de UNIX (incluidos los caracteres

238 Versión 3.8

comodín) para definir el conjunto de parámetros que constituyen unobjeto en el espacio de objetos. Cualquier dirección URL quecoincida con esos parámetros se correlaciona con ese objeto.

Policy Director da soporte a los siguientes caracteres que cumplenpatrones específicos de shell de UNIX:

Carácter Descripción

\ El carácter que sigue a la barra inclinada invertidaforma parte de una secuencia especial. Por ejemplo, \tes el carácter TAB. También puede actuar como carácterde escape.

? Carácter comodín que coincide con un solo carácter. Porejemplo, la cadena de caracteres “abcde” coincide conla expresión “ab?de”

* Carácter comodín que coincide con cero o máscaracteres.

[] Define un conjunto de caracteres del cual puedecoincidir cualquiera de los caracteres. Por ejemplo, lacadena “abcde” coincide con la expresión regular“ab[cty]de”.

^ Indica una negación. Por ejemplo, la expresión [^ab]coincide con cualquier cosa menos con el carácter ‘a’o‘b’.

El ejemplo siguiente muestra el formato de una dirección URLdinámica que realiza una búsqueda de balance de crédito:http://<nombre-servidor>/home-bank/owa/acct.bal?acc=<número-cuenta>

El objeto que representa esta dirección URL dinámica aparecería dela siguiente forma:http://<nombre-servidor>/home-bank/owa/acct.bal?acc=*

Si observamos la dirección URL dinámica de este ejemplo veremosque describe un número de cuenta específico. El objeto para losbalances de cuentas dehome-bank muestra que los permisos ACL


8.Integración

deaplicaciones

se aplican acualquiercuenta, puesto que el último fragmento de laentrada (acc=*) utiliza el carácter comodín asterisco que coincidecon todos los caracteres.

La siguiente figura muestra un ejemplo completo de dirección URLdinámica específica correlacionada con un objeto protegidoespecífico:

Actualización de WebSEAL para direcciones URLdinámicas

Utilice el comandodynurl update para actualizar el espacio deobjetos protegidos de WebSEAL con entradas realizadas en elarchivo de configuracióndynurl.conf.

1. Cree, modifique o elimine una entrada de dirección URLdinámica en el archivo de configuracióndynurl.conf.

http://www.acme.com/sales/web/db.cgi?service=SoftWear&catalog=clothing&product=shirt&color=red

www.acme.com/

db.cgi

web/

sales/

redshirt

Dynamic URL entries:

Protected Object Namespace

"*product=shirt*color=red*"

Match query string with the Webnamespace entry "redshirt"

...group admin -abc---T-m----lrxgroup ABC_company -abc---T-m----lrxany_authenticated --------------unauthenticated --------------...

ACL associated with object:"www.acme.com/sales/web/fortecgi.cgi/redshirt"

Figura 38. Autorización en una dirección URL dinámica

240 Versión 3.8

2. Después de efectuar los cambios, use el comandodynurl updatepara actualizar el servidor:pdadmin> server task webseald-<nombre-servidor> dynurl update

El argumentonombre-servidorrepresenta el nombre de host nocualificado de la máquina WebSEAL.

Resolución de direcciones URL dinámicas en elespacio de objetos

La resolución de una dirección URL dinámica en un objeto dependedel orden de las entradas en el archivo de configuracióndynurl.conf.

Al intentar correlacionar una dirección URL dinámica con unaentrada de objeto, se explora la lista de correlaciones del archivodynurl.conf de principio a fin hasta que se encuentra el primerpatrón que coincide. Cuando se encuentra la primera coincidencia, laentrada de objeto correspondiente se utiliza para la comprobaciónposterior de autorizaciones.

Si no se encuentra ninguna coincidencia, WebSEAL utiliza la propiadirección URL, menos el fragmentohttp://<servidor> de la ruta deacceso.

Mantenga las correlaciones que corresponden con las ACL másrestrictivas en la parte superior de la lista. Por ejemplo, si elprocedimientobook.salesde una aplicación de pedidos de ventas setiene que restringir a un solo grupo del club de reservas, pero todoslos usuarios pueden acceder al resto de la aplicación de pedidos deventas, las correspondencias deben encontrarse en la tabla que semuestra a continuación:

Entrada de espacio deobjetos

Plantilla de dirección URL

/ows/sales/bksale /ows/db-apps/owa/book.sales*

/ows/sales/general /ows/db-apps/owa/*


8.Integración

deaplicaciones

Observe que si las entradas de correlaciones estuvieran en ordeninverso, todos los procedimientos almacenados en el directorio/ows/db-apps/owa se correlacionarían con el objeto/ows/sales/general. Esto podría provocar brechas de seguridad,debido a una resolución incorrecta del espacio de objetos.

Cuando se correlaciona una expresión regular de dirección URL conuna entrada de espacio de objetos, el formato de la dirección URLdebería tomar el formato tal como se produce con el método GET,independientemente de si se utiliza el método POST o GET.

En el método GET de transmisión de datos, los datos dinámicos(como los proporcionados por un usuario en un formulario) seagregan a la dirección URL.

En el método POST de transmisión de datos, los datos dinámicos seincluyen en el texto de la petición.

Evaluación de ACLUna vez resuelta la dirección URL dinámica en una entrada deespacio de objetos, se utiliza el modelo de herencia de ACL estándarpara determinar si la petición se debería procesar o prohibir (debidoa privilegios insuficientes).

Configuración de limitaciones en las peticiones POSTEl contenido de una petición POST está incluido en el cuerpo de lapetición. Además, una petición POST contiene la longituddeterminada por el navegador de este contenido y muestra el valoren bytes.

post-max-read

El parámetropost-max-readen la stanza[server] del archivo deconfiguraciónwebseald.conf limita el impacto de peticiones POSTde gran tamaño en WebSEAL, ya que especifica el número máximode bytes que se pueden leer como contenido en el cuerpo de laspeticiones POST. El contenido que se lee en WebSEAL está sujeto acomprobaciones de autorización, tal y como se ha descritoanteriormente en este apartado.

242 Versión 3.8

El valor del parámetropost-max-readse considera cuando lapetición POST se utiliza en el procesamiento de direcciones URLdinámicas o la autenticación de formularios. El valor predeterminadoes 4096 bytes:[server]post-max-read = 4096

Observe que este parámetro no limita el tamaño máximo decontenido POST (que es ilimitado). El parámetro protege aWebSEAL para que no procese una petición POST de tamañoexcesivo.

dynurl-allow-large-posts

Aunque el parámetropost-max-read limita la cantidad de contenidode POST que se puede leer y procesar en WebSEAL, no impide quela petición se pase íntegramente a través del servidor deaplicaciones. En este caso, se pasa un contenido que no es válido através del servidor de aplicaciones. Si el servidor de aplicaciones notiene sus propias posibilidades de autorización, la situación puedesuponer un riesgo de seguridad.

El parámetrodynurl-allow-large-posts permite controlar la forma enla que WebSEAL maneja las peticiones POST que tienen unalongitud de contenido mayor que la especificada enmax-post-read.Si el valor del parámetro se define como “no” (predeterminado),WebSEAL rechaza totalmente cualquier petición POST con unalongitud de contenido mayor que la especificada enmax-post-read.[server]dynurl-allow-large-posts = no

Si el valor del parámetro se define como “yes”, WebSEAL acepta lapetición POST completa, pero sólo valida la cantidad de contenidoequivalente al valormax-post-read.[server]dynurl-allow-large-posts = yes

Ejemplo 1:


8.Integración

deaplicaciones

¶ Se recibe una petición POST de gran tamaño (mayor que elvalor post-max-read).

¶ dynurl-allow-large-posts = no

¶ Las direcciones URL dinámicas están activadas.

¶ Resultado: Mensaje de error No autorizado.

Ejemplo 2:

¶ Se recibe una petición POST de gran tamaño (mayor que elvalor post-max-read).

¶ dynurl-allow-large-posts = yes

¶ Las direcciones URL dinámicas están activadas.

¶ Resultado: WebSEAL correlaciona la cantidad de contenido hastael valor post-max-readcon la entrada de espacio de objetos, yrealiza una comprobación de autorización a partir de este objeto.El resto del contenido no se correlaciona con la entrada deespacio de objetos, y no se realiza ninguna comprobación deautorización con este objeto.

¶ La siguiente plantilla contiene el tipo de disposición decoincidencia de patrones que crea dificultades debido a unapetición POST de gran tamaño:/rtpi153/webapp/examples/HitCount\?*action=reset*

Resumen y notas técnicasResumen:

¶ Para configurar WebSEAL para que maneje de forma segura lasdirecciones URL dinámicas, se debe crear el siguiente archivo:/opt/PolicyDirector/www/lib/dynurl.conf

¶ El archivo debe contener una o más líneas con el siguienteformato:<objeto> <plantilla>

¶ Si el archivo no existe, o está vacío, no se activa la posibilidadde direcciones URL dinámicas.

244 Versión 3.8

¶ Después de procesarse el archivo, el nombre de objeto aparececomo recurso hijo en el espacio de objetos de WebSEAL.

¶ La plantilla puede contener un subconjunto de los caracteres decoincidencia de patrones estándares. La plantilla también puedeser una serie exacta sin caracteres de coincidencia de patrones.

El siguiente archivo de ejemplodynurl.conf define tres objetos querepresentan algunas de las aplicaciones Web de ejemplo que formanparte del producto IBM WebSphere:

Entrada de objeto Plantilla de dirección 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*

Notas técnicas:

¶ Se pueden correlacionar varias plantillas de dirección URL conel mismo objeto (por ejemplo, app_snoop se correlaciona condirecciones URL en dos servidores diferentes).

¶ Los objetos se pueden anidar (por ejemplo, app_hitcount yapp_hitcount/ejb).

¶ Una petición URL entrante se compara con las plantillas enorden, de arriba a abajo. Cuando se encuentra una coincidencia,el proceso se detiene. Por lo tanto, las plantillas más restrictivasse colocan en la parte superior del archivo.

¶ Para activar las definiciones en el archivodynurl.conf, emita elcomandodynurl update (utilice pdadmin server task).

La actualización se produce inmediatamente, y el objeto apareceen Web Portal Manager cuando se actualiza la vista del espaciode objetos protegidos.

¶ Evite el uso de mayúsculas en el nombre de objeto. Utilice sólocaracteres en minúsculas.


8.Integración

deaplicaciones

¶ No utilice un nombre de objeto que ya exista en el espacio deobjetos protegidos.

¶ Antes de suprimir un objeto en el archivodynurl.conf, eliminelas ACL asociadas conel objeto.

Ejemplo de dirección URL dinámica: Travel KingdomEl siguiente ejemplo muestra cómo una intranet corporativa puedeproteger las direcciones URL generadas por un Oracle Web Listener.

El servidor Web de direcciones URL dinámicas utilizado en esteejemplo es Oracle Web Listener. Esta tecnología se puede aplicarigualmente a otros servidores Web de direcciones URL dinámicas.

La aplicaciónTravel Kingdom es una empresa que ofrece a los clientes un serviciode reserva de viajes a través de Internet. La empresa quiere utilizardos aplicaciones de bases de datos de Oracle en su servidor Web —accesible desde el cortafuegos corporativo y a través de Internet.

1. Sistema de reserva de viajes

Los clientes autorizados pueden efectuar reservas de formaremota y consultar sus reservas actuales. El personal de TravelKingdom también puede efectuar reservas para los clientes quellaman por teléfono, procesar cambios y realizar otras muchastransacciones. Puesto que los clientes externos pagan por losservicios con tarjeta de crédito, la transmisión de esa informacióndebe estar altamente protegida.

2. Gestor de administración

Como muchas otras empresas, Travel Kingdom mantiene unabase de datos de administración que contiene salarios, posición einformación sobre la experiencia. Estos datos van tambiénacompañados de una foto de cada miembro del personal.

La interfazSe configura un servidor Web de Oracle para proporcionar acceso alos siguientes procedimientos almacenados en la base de datos:

246 Versión 3.8

/db-apps/owa/tr.browse Ofrece a todos los usuarios la posibilidadde realizar consultas acerca de losdestinos de viajes, precios, etc.

/db-apps/owa/tr.book Se utiliza para efectuar una reserva(personal de la agencia de viajes oclientes autenticados).

/db-apps/owa/tr.change Se utiliza para revisar o cambiar lasreservas actuales.

/db-apps/owa/admin.browse Los miembros del personal lo utilizanpara ver información no restringida acercade éste, como el número de extensión, ladirección de correo electrónico o lafotografía.

/db-apps/owa/admin.resume Proporciona a un miembro del personal laposibilidad de ver o cambiar lainformación de sus datos personales en labase de datos de administración.

/db-apps/owa/admin.update El personal de administración lo utilizapara actualizar la información acerca delpersonal.

Estructura del espacio WebSe utiliza un servidor WebSEAL para proporcionar una interfazsegura al espacio Web unificado de Travel Kingdom.

¶ Se realiza una conexión (junction) (/ows) con el servidor Webde Oracle ejecutando la aplicación de reserva de viajes y laaplicación de administración.

La política de seguridadPara proporcionar la seguridad apropiada a los recursos Web, almismo tiempo que se mantiene un sistema fácil de usar, la empresaha establecido los siguientes objetivos de seguridad:

1. El personal de la agencia de viajes tiene un control total sobretodas las reservas.


8.Integración

deaplicaciones

2. Los clientes autenticados pueden efectuar y cambiar sus propiasreservas, pero no pueden interferir con los datos de reservas deotros clientes autenticados.

3. El personal de administración tiene acceso completo a toda lainformación de administración.

4. El personal de Travel Kingdom que no es del departamento deadministración puede cambiar la información de sus propiosdatos personales y ver una parte de la información de otrosmiembros del personal.

Correlaciones de direcciones URL dinámicas con el espaciode objetos

Para alcanzar los objetivos de seguridad descritos anteriormente, lascorrelaciones de las direcciones URL dinámicas con las entradas deobjetos de ACL se deben configurar tal como aparece en la siguientetabla.

Recuerde que el orden de esas correlaciones es una parte importantede alcanzar los objetivos de seguridad tratados anteriormente.

Entrada de espacio deobjetos

Patrón de dirección 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=????

Clientes protegidosEl cliente se autentica en WebSEAL a través de un canal segurocifrado.

Los clientes que deseen utilizar la interfaz Web deben registrarsetambién con el administrador de Web de Travel Kingdom pararecibir una cuenta.

248 Versión 3.8

Estructura de cuentas y gruposSe crean cuatro grupos en el sistema:

Staff (Personal)Miembros de la empresa Travel Kingdom.

TKStaff (PersonalTK)Agentes de viajes de Travel Kingdom.

AdminStaff (PersonalAdmin)Miembros del departamento de administración deTravel Kingdom. Observe que los miembros delpersonal de administración se encuentran también enel grupo de personal.

Customer (Cliente)Clientes de Travel Kingdom que desean efectuar susreservas a través de Internet.

Se da a cada usuario una cuenta en el dominio seguro para que elservidor WebSEAL pueda identificarlos individualmente. Laidentidad del usuario se pasa también a los servidores Web de Oraclepara proporcionar una solución de inicio de sesión único para todoslos recursos Web.

Control de accesoLa tabla siguiente muestra una lista de los controles de accesoderivados de la aplicación de la información anterior:

/ows/tr/browse unauthenticated Tr any_authenticated Tr

/ows/tr/auth unauthenticated - any_authenticated -grupo TKStaff Tr grupo Customer PTr

/ows/admin/forall unauthenticated - any_authenticated -grupo Staff Tr

/ows/admin/auth unauthenticated - any_authenticated -grupo AdminStaff Tr

Los grupos Customer (Clientes) y TKStaff (PersonalTK) tienen losmismos privilegios en los objetos de mantenimiento de reservas yplanificación de viajes, con la excepción de que los clientes deben


8.Integración

deaplicaciones

cifrar la información (permiso de privacidad) para proporcionar unamayor seguridad al enviar datos confidenciales (por ejemplo,información de tarjetas de crédito) a través de Internet, que no esfiable.

ConclusiónEste sencillo ejemplo muestra los conceptos de despliegue de unsistema capaz de:

¶ Proteger la información confidencial

¶ Autenticar usuarios

¶ Autorizar el acceso a la información confidencial

Además, los servidores Web de WebSEAL y de Oracle conocen lasidentidades de los usuarios autenticados del sistema y estánhabituados a proporcionar una solución de inicio de sesión único conregistro.

250 Versión 3.8

Referencia de webseald.conf

archivo de configuración webseald.conf

Categorías y stanzas:

¶ GENERAL DE WEBSEAL

[server]

¶ LDAP

[ldap]

¶ SSL

[ssl]

¶ CONEXIÓN (JUNCTION)

[junction]

[filter-url]

[filter-schemes]

[script-filtering]

[gso-cache]

[ltpa-cache]

¶ AUTENTICACIÓN

[ba]

[forms]

[token]

[certificate]

A


A.

Referencia

dew

ebseald.conf

[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]

¶ SESIÓN

[session]

¶ CONTENIDO

[content]

[acnt-mgt]

[cgi]

[cgi-types]

[cgi-environment-variables]

[content-index-icons]

[icons]

[content-cache]

[content-mime-types]

[content-encodings]

¶ INICIO DE SESIÓN

[logging]

¶ API DE AUTORIZACIÓN

252 Versión 3.8

[aznapi-configuration]

[aznapi-entitlement-services]

¶ POLICY DIRECTOR

[policy-director]

[manager]

GENERAL DE WEBSEAL


stanza[server]

SISTEMA

unix-user Cuenta de usuario de UNIX para elservidor WebSEAL.

unix-group Cuenta de grupo de UNIX para el servidorWebSEAL.

unix-pid-file Ubicación del archivo PID.

server-root Directorio raíz del servidor WebSEAL.

server-name Nombre de instancia del servidorWebSEAL.

THREADS Y CONEXIONES

worker-threads Número de threads de trabajo deWebSEAL.

client-connect-timeout Tiempo de espera de conexión inicial delcliente.

persistent-con-timeout Tiempo de espera de conexión persistentede HTTP/1.1

CLIENTE HTTPS

https Permitir el acceso HTTPS.

https-port Puerto que se debe utilizar en laspeticiones HTTPS seguras.

CLIENTE HTTP

http Permitir el acceso HTTP (TCP) no seguro.

http-port Puerto que se debe utilizar en laspeticiones HTTP no seguras.

PETICIONES POST


A.

Referencia

dew

ebseald.conf

GENERAL DE WEBSEAL


post-max-read Número máximo de bytes que se puedenleer como contenido en el cuerpo de laspeticiones POST.

DYNURL

dynurl-map Ubicación del archivo de correlación deobjetos de URL a protegidos

dynurl-allow-large-posts Limitar la capacidad de WebSEAL de leerpeticiones POST mayores de loespecificado enpost-max-read.

Gestión de URI

utf8-url-spport-enabled

LDAP


stanza[ldap]

ldap-server-config Ubicación del archivo de configuraciónldap.conf (establecido durante laconfiguración).

cache-enabled Activar y desactivar la caché local deLDAP.

prefer-readwrite-server Permitir la selección de un servidor LDAPen el que se pueda escribir, cuando estédisponible.

auth-using-compare Permitir comprobaciones de autenticaciónmás rápidas utilizando una operación decomparación de contraseña, en lugar de unenlace LDAP.

default-policy-override-support

Comprobar la política predeterminada o lapolítica específica del usuario.

user-and-group-in-same-suffix

Búsquedas de rendimiento. Indica que losgrupos están definidos en el mismo sufijoLDAP que el usuario.

254 Versión 3.8

LDAP


ssl-enabled Activar y desactivar SSL para lacomunicación de WebSEAL a LDAP.

ssl-keyfile Ubicación del archivo de claves SSL.

ssl-keyfile-dn Etiqueta de certificados en el archivo declaves SSL, si existe.

ssl-keyfile-pwd Contraseña del archivo de claves SSL.

bind-dn Nombre distinguido del daemon deWebSEAL (establecido durante laconfiguración).

bind-pwd Contraseña para el daemon de WebSEAL(establecida durante la configuración).

activado

host

puerto

SSL


stanza[ssl]

webseal-cert-keyfile Ubicación del archivo de claves quecontiene el certificado del servidor enviadoa los navegadores por WebSEAL alnegociar las sesiones SSL.

webseal-cert-keyfile-pwd Contraseña de claves privadas decertificados de WebSEAL.

webseal-cert-keyfile-stash Ubicación del archivo stash de contraseñasde claves privadas de WebSEAL.

webseal-cert-keyfile-label Nombre del certificado de WebSEAL parautilizar en lugar del predeterminado.

ssl-keyfile Ubicación del archivo de claves delcertificado de WebSEAL utilizado en lacomunicación interna.


A.

Referencia

dew

ebseald.conf

SSL


ssl-keyfile-pwd Contraseña de claves privadas decertificados de WebSEAL (para lacomunicación interna).

ssl-keyfile-stash Ubicación del archivo stash de contraseñasde claves privadas de WebSEAL (para lacomunicación interna).

ssl-keyfile-label Nombre de certificado para utilizar enlugar del predeterminado (para lacomunicación interna).

disable-ssl-v2 Desactivar selectivamente el soporte SSLV2.

disable-ssl-v3 Desactivar selectivamente el soporte SSLV3.

disable-tls-v1 Desactivar selectivamente el soporte TLSV1.

ssl-v2-timeout Tiempo de espera del ID de sesión de lacaché de GSKit para las conexiones V2 deSSL.

ssl-v3-timeout Tiempo de espera del ID de sesión de lacaché de GSKit para las conexiones V3 deSSL.

ssl-max-entries Número máximo de entradas simultáneasen la caché del ID de sesión SSL deGSKit.

ssl-ldap-server Servidor LDAP utilizado para lacomprobación de CRL.

ssl-ldap-server-port Número de puerto de escucha de esteservidor LDAP para la comprobación deCRL.

ssl-ldap-user Usuario de administración para el servidorLDAP.

ssl-ldap-user-password Contraseña del usuario de administraciónpara el servidor LDAP.

ssl-auto-refresh

256 Versión 3.8

SSL


ssl-listening-port

ssl-pwd-life

ssl-authn-type

CONEXIÓN (JUNCTION)


stanza[junction]

junction-db Ubicación de la base de datos deconexiones (junctions).

jmt-map Ubicación de la tabla de correlaciones deconexiones (junctions) y peticiones.

http-timeout Tiempo de espera para el envío a unaconexión (junction) basada en TCP ypara la lectura desde esa conexión.

https-timeout Tiempo de espera para el envío a unaconexión (junction) basada en SSL ypara la lectura desde esa conexión.

ping-time Intervalo para la rutina de ping deWebSEAL a servidores con conexión(junction).

basicauth-dummy-passwd Contraseña global cuando se suministrandatos de autenticación básica a través deconexiones (junctions) “-b supply”.

worker-thread-hard-limit Tanto por ciento del total de threads detrabajo que procesan peticiones para unaconexión (junction) particular.

worker-thread-soft-limit Tanto por ciento del total de threads detrabajo que procesan peticiones para unaconexión (junction) particular.

io-buffer-size Tamaño del búfer para leer y escribir enuna conexión (junction).

FILTRADO DE DOCUMENTOS

stanza[filter-url]


A.

Referencia

dew

ebseald.conf

CONEXIÓN (JUNCTION)


<indicador> = <atributo> Atributos de dirección URL queWebSEAL filtra en las respuestas de losservidores con conexión (junction).

stanza[filter-schemes]

scheme = <nombre-esquema> Lista de esquemas de direcciones URLque WebSEAL filtra en las respuestas delos servidores con conexión (junction).

stanza[script-filtering]

script-filter Activar y desactivar el filtro dedirecciones URL absolutas de scripts enservidores con conexión (junction).

CACHÉ DE GSO

stanza[gso-cache]

gso-cache-enabled Activar y desactivar la caché de GSO.

gso-cache-size Número de entradas en la caché deGSO.

gso-cache-entry-lifetime Duración máxima de una entrada decaché de GSO.

gso-cache-entry-idle-timeout Duración máxima de una entrada decaché de GSO inactiva.

CACHÉ DE LTPA

stanza[ltpa-cache]

ltpa-cache-enabled Activar y desactivar la caché de LTPA.

ltpa-cache-size Número de entradas en la caché deLTPA.

ltpa-cache-entry-lifetime Duración máxima de una entrada decaché de LTPA.

ltpa-cache-entry-idle-timeout Duración máxima de una entrada decaché de LTAPA inactiva.

258 Versión 3.8

AUTENTICACIÓN


AUTENTICACIÓN BÁSICA

stanza[ba]

ba-auth Activar y desactivar el mecanismo deautenticación básica.

basic-auth-realm Nombre de dominio que aparece en elindicador de inicio de sesión BA delnavegador.

FORMULARIOS

stanza[forms]

forms-auth Activar y desactivar la autenticaciónutilizando formularios.

SEÑAL

stanza[token]

token-auth Activar y desactivar la autenticaciónutilizando códigos de paso de señal.

CERTIFICADO

stanza[certificate]

accept-client-certs Configurar la gestión de certificados decliente de WebSEAL.

CABECERAS HTTP

stanza[http-headers]

http-headers-auth Activar y desactivar la autenticaciónutilizando cabeceras HTTP.

stanza[auth-headers]

header Cabeceras HTTP específicas utilizadas parala autenticación.

DIRECCIÓN IP

stanza[ipaddr]

ipaddr-auth Activar y desactivar la autenticaciónutilizando información de direcciones IP.

INCREMENTAL

stanza[authentication-levels]


A.

Referencia

dew

ebseald.conf

AUTENTICACIÓN


level = unauthenticated level= password

Configuración de la autenticaciónincremental.

MULTIPLEXING PROXY AGENTS

stanza[mpa]

mpa Activar y desactivar el soporte para laautenticación a través de multiplexingproxy agents.

CDSSO

stanza[cdsso]

cdsso-auth Activar y desactivar la autenticaciónutilizando señales CDSSO.

authtoken-lifetime Valor de duración máxima de una señal deautenticación CDSSO.

stanza[cdsso-peers]

<nombre-máquina> =<ubicación-archivo-claves>

Pares de dominio que participan en elCDSSO.

RECUPERACIÓN TRAS ERROR

stanza[failover]

failover-auth Activar y desactivar la aceptación de lascookies de recuperación tras error.

failover-cookies-keyfile Ubicación (nombre de ruta de accesocompleta) de la clave de cifrado decookies generada porcdsso_key_gen.

failover-cookie-lifetime Límite de tiempo para la validez delcontenido de la cookie de recuperación.

enable-failover-cookie-for-domain

Cambiar el tipo de cookie de recuperacióntras error de cookie específica del servidora cookie específica de dominio.

SSO DE COMUNIDAD ELECTRÓNICA

stanza[e-community-sso]

e-community-sso-auth Activar y desactivar el SSO de lacomunidad electrónica.

260 Versión 3.8

AUTENTICACIÓN


e-community-name Nombre de la comunidad electrónica queaparece en las peticiones y las señales de“garantización”.

intra-domain-key Ubicación del archivo de claves utilizadopara asegurar la comunicación entre lasinstancias de WebSEAL en un dominioDNS.

is-master-authn-server Designar la máquina local como servidormaestro de autenticación WebSEAL.

master-authn-server Nombre del servidor maestro deautenticación WebSEAL (si no es lamáquina local).

master-http-port Puerto HTTP no estándar para la escuchadel servidor maestro de autenticación.

master-https-port Puerto HTTPS no estándar para la escuchadel servidor maestro de autenticación.

vf-token-lifetime Valor de duración de la señal de“garantización”.

vf-url La dirección URL de “garantización”.

ec-cookie-lifetime Valor de duración de la cookie de lacomunidad electrónica.

stanza[inter-domain-keys]

<nombre-dominio> =<archivo-claves>

Los archivos de claves para otros dominiosparticipantes en la comunidad electrónica.

BIBLIOTECAS Y MECANISMOS DE AUTENTICACIÓN

stanza[authentication-mechanisms]

passwd-cdas passwd-ldappasswd-uraf token-cdascert-ssl cert-cdashttp-request cdssopasswd-strengthcred-ext-attrs

Lista de mecanismos de autenticaciónsoportados y las bibliotecas compartidasasociadas.

GESTIÓN DE LA CALIDAD SSL DE PROTECCIÓN

stanza[ssl-qop]


A.

Referencia

dew

ebseald.conf

AUTENTICACIÓN


ssl-qop-mgmt Activar y desactivar la gestión de lacalidad de protección.

stanza[ssl-qop-mgmt-hosts]

<dirección-ip> Nivel de cifrado QOP para los hostsindividuales.

stanza[ssl-qop-mgmt-networks]

<dirección-ip/máscara> Nivel de cifrado QOP para las redesindividuales.

stanza[ssl-qop-mgmt-default]

default Nivel de cifrado QOP predeterminado paralas otras direcciones IP sin correlación.

SESIÓN


stanza[session]

max-entries Número máximo de entradas simultáneasen la caché de credenciales/sesión deWebSEAL.

timeout Duración máxima de una entrada en lacaché de credenciales/sesión de WebSEAL.

inactive-timeout Duración de las entradas inactivas en lacaché de credenciales de WebSEAL.

SESIONES DE CLIENTE SSL

ssl-id-sessions Utilizar el ID de SSL para mantener losinicios de sesión de HTTPS.

SESIONES COMPARTIDAS

use-same-session Utilizar el mismo ID de sesión para losclientes que cambian entre HTTP yHTTPS.

ENVÍO DE COOKIES DE SESIÓN

262 Versión 3.8

SESIÓN


resend-webseal-cookies Enviar todas las cookies configuradas derecuperación tras error y de sesión alcliente con cada respuesta.

CONTENIDO


stanza[content]

DIRECTORIOS Y ARCHIVOS LOCALES

doc-root Directorio raíz del árbol de documentosWeb.

directory-index Nombre del archivo de índice dedirectorios.

delete-trash-dir Directorio de eliminación temporal paraarchivos suprimidos por el administrador.

DIRECTORIOS DE USUARIOS LOCALES

user-dir El directorio es el árbol inicial del usuarioque contiene documentos HTML públicos.

PÁGINAS DE ERROR

error-dir Directorio que contiene los archivos dedescripción de errores de WebSEAL.

PÁGINAS DE GESTIÓN DE CUENTAS

stanza[acnt-mgt]

mgt-pages-root Raíz de las páginas de gestión de cuentas.

login Nombre del formulario de inicio de sesiónestándar.

logout Nombre de la página que aparece despuésde finalizar la sesión correctamente.

account-locked Nombre de la página que aparece si fallala autenticación debido a una cuentabloqueada.


A.

Referencia

dew

ebseald.conf

CONTENIDO


passwd-expired Nombre de la página que aparece si fallala autenticación debido a una contraseñacaducada.

passwd-change Nombre del formulario de cambio decontraseña.

passwd-change-success Nombre de la página que aparece si lapetición de cambio de contraseña se haejecutado correctamente.

passwd-change-failure Nombre de la página que aparece si lapetición de cambio de contraseña no se haejecutado correctamente.

help Nombre de la página que contiene vínculosa páginas de administración válidas.

token-login Nombre del formulario de inicio de sesiónde señales.

next-token Nombre del formulario de las siguientesseñales.

stepup-login Nombre del formulario de inicio de sesiónde autenticación incremental.

CGI LOCAL

stanza[cgi]

cgi-timeout Valor de tiempo de espera para leer yescribir en procesos CGI hijos.

stanza[cgi-types]

bat = cmd cmd = cmd pl =perl sh = sh tcl = tclsh76

Designa, para los servidores Win32, elprograma que se debe ejecutar para unaextensión de archivo CGI determinada.

stanza[cgi-environment-variables]

ENV Variables de entorno que heredarán losprogramas CGI.

ICONOS

stanza[content-index-icons]

264 Versión 3.8

CONTENIDO


image/* video/* audio/*text/html text/*application/x-tar application/*

Especifica los iconos gráficos que se debenutilizar cuando WebSEAL genera un índicede directorios (esto sucede cuando noexiste index.html).

stanza[icons]

diricon Icono utilizado para subdirectorios.

backicon Icono utilizado para el directorio principal.

unknownicon Icono utilizado para tipos de archivodesconocidos.

CACHÉ DE DOCUMENTOS

stanza[content-cache]

text/html image/* */* Define el tipo y tamaño de la caché paratipos MIME de documentos específicosque WebSEAL almacena en la memoria.

TIPOS MIME

stanza[content-mime-types]

<extensión> = <tipo> Define el tipo MIME para extensiones dedocumento específicas.

deftype Tipo MIME predeterminado que se debeutilizar cuando el tipo de documento no seencuentra en la lista de la tabla decorrelaciones.

CODIFICACIÓN DE CONTENIDOS

stanza[content-encodings]

gz Z Correlaciona la extensión del documentocon un tipo de codificación paranavegadores que dan soporte a lacodificación del contenido.

INICIO DE SESIÓN


stanza[logging]


A.

Referencia

dew

ebseald.conf

INICIO DE SESIÓN


server-log Ubicación del archivo de registro deerrores del servidor.

max-size Umbral de creación de un nuevo archivode registro para registros HTTP.

flush-time Frecuencia de vaciado de los búferes dearchivos de registro HTTP.

requests Activar y desactivar el registro depeticiones HTTP.

requests-file Ubicación del registro de peticiones HTTP.

referers Activar y desactivar el registro dereferentes HTTP.

referers-file Ubicación del registro de referentes HTTP.

agents Activar y desactivar el registro de agentesHTTP.

agents-file Ubicación del registro de agentes HTTP.

gmt-time Registrar peticiones con la hora GMT enlugar de la franja horaria local.

API DE AUTORIZACIÓN


stanza[aznapi-configuration]

db-file Ubicación del archivo de caché de la basede datos de políticas del cliente local.

cache-refresh-interval Define el intervalo entre lascomprobaciones de actualizaciones(sondeos) en el servidor maestro deautorizaciones.

listen-flags Activar y desactivar los distintivos para larecepción de las modificaciones deactualización de la caché de políticas.

tcp-port Puerto TCP para la escucha.

udp-port Puerto UDP para la escucha.

266 Versión 3.8

API DE AUTORIZACIÓN


REGISTRO DE API DE AUTORIZACIÓN

logclientid=webseald

logsize Umbral de creación de un nuevo archivode registro para el registro de auditoría degestión.

logflush Frecuencia de vaciado de los búferes dearchivos de registro de auditoría degestión.

logaudit Activar y desactivar la auditoría.

auditlog Ubicación del registro de auditoría.

auditcfg = azn Captura de los eventos de autorización.

auditcfg = authn Captura de los eventos de autenticación.

auditcfg = wand Captura de los eventos de WebSEAL.

DEFINICIONES DE SERVICIOS AZNAPI

<id-servicio>

mode

azn-server-name

pd-user-name

stanza[aznapi-entitlement-services]

AZN_ENT_EXT_ATTR

POLICY DIRECTOR


stanza[policy-director]

config-file Ubicación del archivo de configuraciónpd.conf.

stanza[manager]

master-host

master-port

master-dn


A.

Referencia

dew

ebseald.conf

268 Versión 3.8

Referencia para las conexiones(junctions) WebSEAL

La utilidad pdadmin proporciona un indicador de línea de comandosinteractivo desde el cual se pueden realizar tareas de conexión(junction) WebSEAL.

Índice de temas:

¶ “Utilización de “pdadmin server task” para crear conexiones(junctions)” en la página 269

¶ “Los comandos de la conexión (junction)” en la página 271

¶ “Creación de una conexión (junction) nueva para un servidorinicial” en la página 272

¶ “Adición de un servidor adicional a una conexión (junction)existente” en la página 276

Utilización de “pdadmin server task” para crearconexiones (junctions)

Antes de utilizarpdadmin, debe iniciar la sesión en un dominioseguro como usuario de administraciónsec_master.

B


B.

Ref.

paraconexiones

(junctions)W

ebSE

AL

Por ejemplo:

UNIX:# pdadminpdadmin> loginEscriba el ID de usuario: sec_masterEscriba la contraseña:pdadmin>

Windows:MSDOS> pdadminpdadmin> loginEscriba el ID de usuario: sec_masterEscriba la contraseña:pdadmin>

También puede conseguir estos resultados con una única línea decomandos que utiliza las siguientes opciones:# pdadmin -a sec_master -p <contraseña>pdadmin>

Para crear conexiones (junctions) WebSEAL, utilice el comandopdadmin server task:pdadmin> server task <nombre-servidor> <tarea>

El argumentonombre-servidores la expresión completa del nombrereal de la máquina y el componente de Policy Director utilizado poreste comando (por ejemplo, WebSEAL).<componente-policy-director>-<nombre-máquina>

Por ejemplo, si el nombre de la máquina escruz y el componente dePolicy Director es WebSEAL, elnombre-servidores:webseald-cruz

Utilice el comandoserver list para verificar las expresionesnombre-servidor:pdadmin> server listwebseald-cruz

Las opciones de comando obligatorias necesarias para crear unaconexión (junction) WebSEAL básica son:

270 Versión 3.8

¶ Nombre de host del servidor de aplicaciones de fondo (opción–h)

¶ Tipo de conexión (junction) — tcp, ssl, tcpproxy, sslproxy, local(opción–t)

¶ Punto de conexión (junction) (punto de montaje)pdadmin> server task <nombre-servidor> create –t <tipo>–h <nombre-servidor> <punto-conexión>

Los comandos de la conexión (junction)Los siguientes comandos de conexión (junction) están disponiblescon pdadmin server task:


create Crea una conexión (junction) nueva para unservidor inicial.

add Agrega servidores adicionales a un punto deconexión (junction) existente.

remove Elimina un servidor de un punto de conexión(junction).

Sintaxis: remove –i <id-servidor><punto-conexión>

Utilice el comandoshow para determinar el ID deun servidor concreto.

delete Elimina el punto de conexión (junction).

Sintaxis: delete <punto-conexión>

list Muestra una lista de todos los puntos de conexión(junction) de este servidor.

Sintaxis: list

show Muestra los detalles de una conexión (junction).

Sintaxis: show <punto-conexión>


B.

Ref.

paraconexiones

(junctions)W

ebSE

AL


jmt load jmt clear El comandojmt load proporciona a WebSEAL losdatos de la tabla de correlaciones de conexiones(junctions) (jmt.conf) para gestionar el proceso delas direcciones URL relativas al servidor generadasdinámicamente.

El comandojmt clear elimina los datos de la tablade correlaciones de conexiones (junctions)WebSEAL.

help Muestra una lista de los comandos de conexión(junction).

Sintaxis: help

help <comando> Muestra la ayuda detallada de un comando deconexión (junction) específico

exit Sale de la utilidadpdadmin.

Sintaxis: exit

Estos comandos, y las opciones asociadas, se describen en lossiguientes apartados.

Creación de una conexión (junction) nueva para unservidor inicial

Operación: crea un punto de conexión (junction) nuevo y conectaun servidor inicial.

Sintaxis:create –t <tipo> –h <nombre-host> [<opciones>] <punto-conexión>

272 Versión 3.8

Tipo de conexión (junction)

–t <tipo> **Obligatorio**

Tipo de conexión. Puede ser:tcp, ssl,tcpproxy, sslproxy, local.

El puerto predeterminado para –t tcp es80.El puerto predeterminado para –t ssl es443.

Nombre de host

–h <nombre-host> **Obligatorio**

Nombre de host DNS o dirección IP delservidor de fondo de destino.

Opciones

Autenticación mutua a través de SSL

–K <etiqueta-clave> WebSEAL utiliza el certificado de clientepara autenticarse en el servidor de fondo.

–B WebSEAL utiliza la información decabecera de BA para autenticarse en elservidor de fondo. Requiere las opciones–U, –W y –b filter.

–U<“nombre-usuario”>

Nombre de usuario de WebSEAL. Utilícelocon –B para enviar información de cabecerade BA al servidor de fondo.

–W <“contraseña”> Contraseña de WebSEAL. Utilícelo con –Bpara enviar información de cabecera de BAal servidor de fondo.

–D <“DN”> Especifica el Nombre distinguido delcertificado de servidor de fondo. Este valor,que coincide con el DN de certificado real,mejora la autenticación.

Opciones de conexión (junction) de proxy (requiere –ttcpproxy o –t sslproxy)

–H <nombre-host> Nombre de host DNS o dirección IP delservidor proxy.



B.

Ref.

paraconexiones

(junctions)W

ebSE

AL

Especificación de la información de cabecera de BA

–b <valor-BA> Define cómo el servidor WebSEALtransfiere la información de autenticaciónBA de HTTP al servidor de fondo. Puedeser:

filter (valor predeterminado),ignore,supply, gso

Opciones generales de conexión (junction) TCP y SSL

–c <tipos-id> Inserta la identidad de cliente de PolicyDirector en las cabeceras HTTP a través dela conexión (junction). El argumentotipos-id puede incluir cualquiercombinación de los siguientes tipos decabecera HTTP de Policy Director: iv-user,iv-user-l, iv-groups, iv-creds, all.

–i El servidor WebSEAL trata las direccionesURL como no sensibles a mayúsculas yminúsculas.

–j Proporciona la identificación de conexión(junction) en una cookie para gestionardirecciones URL relativas al servidorgeneradas por script.

–k Enviar cookie de sesión al servidor deportal de fondo.

–p <puerto> Puerto TCP del servidor de fondo deterceros. El valor predeterminado es80 paraconexiones (junctions) TCP;443 paraconexiones (junctions) SSL.

–q <url> Dirección URL relativa para el scriptquery_contents. Policy Director buscaquery_contentsen /cgi_bin/. Si estedirectorio es distinto o si se ha cambiado elnombre del archivoquery_contents, utiliceesta opción para indicar a WebSEAL ladirección URL nueva para el archivo.

–r Insertar dirección IP entrante en la cabeceraHTTP a través de la conexión (junction).

274 Versión 3.8

–s Especifica que la conexión (junction) debedar soporte a aplicaciones con informaciónde estado. De forma predeterminada, lasconexiones (junctions)no tieneninformación de estado.

–T <recurso/grupo-recursos>

Nombre de recurso o grupo de recursos deGSO. Obligatorio y utilizado sólo con laopción –b gso.

–u <UUID> Especifica el UUID de un servidor de fondoconectado a WebSEAL a través de unaconexión (junction) con información deestado (–s).

–v<nombre-host-virt>

Nombre de host virtual representado en elservidor de fondo. Esta opción da soporte auna configuración de host virtual delservidor de fondo.

Utilice –v cuando el servidor de conexión(junction) de fondo espera una cabecera denombre de host porque se conecta a unainstancia virtual de ese servidor. La peticiónde cabecera HTTP predeterminada delnavegador no sabe que el servidor de fondotiene varios nombres y varios servidoresvirtuales. Debe configurar WebSEAL paraque proporcione esa información decabecera adicional en las peticionesdestinadas a una configuración de servidorde fondo como host virtual.

–w Soporte para el sistema de archivos Win32.

Conexiones (junctions) LTPA

–A Activar y desactivar las conexiones(junctions) LTPA.

–F<“archivo-claves”>

Ubicación del archivo de claves utilizadopara cifrar la cookie LTPA.

–Z<“contraseña-archivo-claves”>

Contraseña del archivo de claves


B.

Ref.

paraconexiones

(junctions)W

ebSE

AL

Conexiones (junctions) SSL de WebSEAL a WebSEAL

–C Autenticación mutua entre un servidorWebSEAL frontal y un servidor WebSEALde fondo a través de SSL. Requiere el tipo–t ssl o –t sslproxy.

Opciones de conexión (junction) local (utilícelo con –t local)

–d <dir> Directorio local de la conexión (junction).**Obligatorio.**

–f Forzar la sustitución de una conexión(junction) existente.

Punto de conexión (junction)

Ubicación en el espacio de nombres de WebSEAL para crear laconexión (junction).

Adición de un servidor adicional a una conexión(junction) existente

Operación: agrega un servidor adicional a un punto de conexión(junction) existente.

Sintaxis:add –h <nombre-host> [<opciones>] <punto-conexión>

Nombre de host

–h <nombre-host> **Obligatorio**

Nombre de host DNS o dirección IP delservidor de fondo de destino.

Opciones

Autenticación mutua a través de SSL

–D <“DN”> Especifica el Nombre distinguido delcertificado de servidor de fondo. Este valor,que coincide con el DN de certificado real,mejora la autenticación.

276 Versión 3.8

Opciones de conexión (junction) proxy (obligatorio con –ttcpproxy y –t sslproxy)

–H <nombre-host> Nombre de host DNS o dirección IP delservidor proxy.


Opciones generales de conexión (junction) TCP y SSL

–i El servidor WebSEAL trata las direccionesURL como no sensibles a mayúsculas yminúsculas.

–j Proporciona la identificación de conexión(junction) en una cookie para gestionardirecciones URL relativas al servidorgeneradas por script.

–p <puerto> Puerto TCP del servidor de fondo deterceros. El valor predeterminado es80 paraconexiones (junctions) TCP;443 paraconexiones (junctions) SSL.

–q <url> Dirección URL relativa para el scriptquery_contents. Policy Director buscaquery_contentsen /cgi_bin/. Si estedirectorio es distinto o si se ha cambiado elnombre del archivoquery_contents, utiliceesta opción para indicar a WebSEAL ladirección URL nueva para el archivo.

–u <UUID> Especifica el UUID de un servidor de fondoconectado a WebSEAL a través de unaconexión (junction) con información deestado (–s).


B.

Ref.

paraconexiones

(junctions)W

ebSE

AL

–v<nombre-host-virt>

Nombre de host virtual representado en elservidor de fondo. Esta opción da soporte auna configuración de host virtual delservidor de fondo.

Utilice –v cuando el servidor de conexión(junction) de fondo espera una cabecera denombre de host porque se conecta a unainstancia virtual de ese servidor. La peticiónde cabecera HTTP predeterminada delnavegador no sabe que el servidor de fondotiene varios nombres y varios servidoresvirtuales. Debe configurar WebSEAL paraque proporcione esa información decabecera adicional en las peticionesdestinadas a una configuración de servidorde fondo como host virtual.

–w Soporte para el sistema de archivos Win32.

Punto de conexión (junction)

Agrega un servidor al punto de conexión (junction) existente.

278 Versión 3.8

Gestión de certificados coniKeyman

La utilidad iKeyman es una herramienta que se puede utilizar paragestionar los certificados digitales. ConiKeyman, puede crear unabase de datos de claves nueva, un certificado digital de pruebanuevo, agregar directorios raíz de CA en la base de datos, copiarcertificados de una base de datos a otra, solicitar y recibir uncertificado digital de una CA, establecer claves predeterminadas ycambiar contraseñas. La utilidadiKeyman forma parte del paqueteGlobal Security Kit (GSKit) incluido con Policy Director.

Índice de temas:

¶ “Inicio de la utilidad iKeyman” en la página 280

¶ “Apertura de la base de datos de claves predeterminada deWebSEAL” en la página 282

¶ “Creación de una base de datos de claves nueva” en la página284

¶ “Creación de un nuevo certificado digital autofirmado” en lapágina 287

¶ “Adición de un certificado raíz de CA nuevo” en la página 290

¶ “Supresión de un certificado raíz de CA” en la página 291

¶ “Copia de certificados entre bases de datos” en la página 291

¶ “Petición de un certificado de servidor” en la página 296

C


C.

Gestión

decertificados

coniK

eyman

¶ “Recepción de un certificado digital” en la página 298

¶ “Supresión de un certificado digital” en la página 298

¶ “Asignación de un certificado predeterminado nuevo” en lapágina 299

¶ “Cambio de una contraseña de base de datos” en la página 300

Inicio de la utilidad iKeymanInicie la utilidad iKeyman desde el indicador de línea de comandosdel sistema operativo:

Windows:MSDOS> /Archivos de programa/IBM/gsk4/bin/gsk4ikm.exe

UNIX:# /usr/bin/gsk4ikm

Aparecerá la ventana Gestión de claves de IBM.

280 Versión 3.8

Figura 39. Ventana Gestión de claves de IBM


C.

Gestión

decertificados

coniK

eyman

Apertura de la base de datos de clavespredeterminada de WebSEAL

Una base de datos de claves contiene los certificados de servidor ycliente y los certificados raíz de CA necesarios para que WebSEALprocese la autenticación basada en certificados.

Durante la instalación, WebSEAL proporciona una base de datos declaves de certificados predeterminada (pdsrv.kdb). El archivo declaves contiene un certificado WebSEAL (etiqueta de clave = PolicyDirector) y una selección de los certificados raíz de CA comunes.

Para abrir la base de datos de claves predeterminada de WebSEAL,siga los pasos siguientes:

1. En la ventana Gestión de claves de IBM, seleccione Abrir delmenú Archivo de bases de datos clave.

2. En la ventana Abrir, desplácese hasta el siguiente directorio:

UNIX: /opt/PolicyDirector/lib/certs

Windows: C:\Archivos de programa\Tivoli\PolicyDirector\lib\certs

3. Seleccione:pdsrv.kdb

4. Haga clic en Abrir.

Aparecerá el cuadro de diálogo Solicitud de contraseña.

5. Escriba la contraseña predeterminada de WebSEAL:pdsrv

6. Haga clic en Aceptar.

La ventana de gestión se rellena con la información de base dedatos.

Observe que el certificado WebSEAL predeterminado aparece en laventana Certificados personales. La etiqueta de clave para elcertificado es “Policy Director”. El asterisco que aparece a laizquierda de esta etiqueta marca el certificado como predeterminado.

282 Versión 3.8

Consulte la Figura 40.

Cambie la opción de certificado del menú desplegable deCertificados personales a Certificados de firmante. Aparecerá la listade certificados raíz de CA (entidad emisora de certificados)comunes.

Consulte la Figura 41 en la página 284.

Figura 40. Archivo predeterminado de claves pdsrv.kdb de WebSEAL: CertificadoWebSEAL


C.

Gestión

decertificados

coniK

eyman

Creación de una base de datos de claves nuevaUna base de datos de claves contiene los certificados de servidor ycliente y los certificados raíz de CA necesarios para que WebSEALprocese la autenticación basada en certificados.

Durante la instalación, WebSEAL proporciona una base de datos declaves de certificados predeterminada (pdsrv.kdb). El archivo declaves contiene un certificado WebSEAL (etiqueta de clave = PolicyDirector) y una selección de los certificados raíz de CA comunes.

Puede seguir utilizando esta base de datos de claves predeterminadao bien crear una base de datos nueva. Si crea una base de datosnueva y desea que WebSEAL la utilice como predeterminada, debeinformar a WebSEAL configurando el parámetrossl-keyfile del

Figura 41. Archivo predeterminado de claves pdsrv.kdb de WebSEAL: Certificados defirmante

284 Versión 3.8

archivosecmgrd.conf. Consulte el apartado “Configuración de losparámetros de la base de datos de claves para WebSEAL” en lapágina 46.

Para crear un archivo de base de datos de claves nuevo, siga lospasos siguientes:

1. En la ventana Gestión de claves de IBM, seleccione Nuevo delmenú Archivo de bases de datos clave.

Aparecerá el cuadro de diálogo Nuevo.

2. Seleccione “Archivo de base de datos clave de CMS” en elcampo Tipo de base de datos clave.

3. Escriba un nombre de archivo como, por ejemplokey.kdb.

4. Acepte el valor predeterminado del campo Ubicación,especifique un valor nuevo o bien utilice el botón Examinarpara seleccionar un valor nuevo.


Aparecerá la ventana Solicitud de contraseña.

6. Especifique una contraseña en el campo Contraseña y escríbalade nuevo en el campo Confirmar contraseña.

7. (Opcional) Active la casilla de verificación ¿Establecer fecha decaducidad? y especifique un valor apropiado.

8. (Opcional) Active la casilla de verificación ¿Ocultar lacontraseña para un archivo?

Figura 42. Cuadro de diálogo Nuevo


C.

Gestión

decertificados

coniK

eyman

Un archivo stash tiene la extensión: .sth

Debe informar a WebSEAL de este nuevo archivo stashconfigurando el parámetrossl-keyfile-stashdel archivo deconfiguraciónsecmgrd.conf.

Consulte el apartado “Configuración de los parámetros de labase de datos de claves para WebSEAL” en la página 46.


Aparecerá una ventana de confirmación que verificará que hacreado una base de datos de claves nueva.


Ha creado correctamente una nueva base de datos de claves.Aparecerá la ventana Gestión de claves de IBM.

La ventana Gestión de claves de IBM refleja el nombre del nuevoarchivo de claves y muestra los certificados de firmante.

iKeyman proporciona los siguientes certificados digitales defirmante:

¶ 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

Estos certificados digitales de firmante son los certificados raíz deCA (entidad emisora de certificados). WebSEAL utiliza estoscertificados raíz para validar los certificados de cliente.

286 Versión 3.8

Si necesita utilizar un certificado de firmante que no aparece en estalista, debe solicitarlo a la CA y agregarlo a la base de datos declaves.

Consulte el apartado “Adición de un certificado raíz de CA nuevo”en la página 290.

Nota: el certificado VeriSign Test CA Root Certificate es una CA debaja seguridad incluido para realizar pruebas. Debe eliminarloantes de colocar una clase de base de datos de claves en unaaplicación de producción.

La base de datos nueva necesita también incluir un certificado deCA de servidor firmado para que WebSEAL pueda autenticarse enclientes u otros servidores. Este certificado está almacenado en elapartado Certificados personales de la ventana de gestión.

Consulte el apartado “Petición de un certificado de servidor” en lapágina 296.

Consulte el apartado “Recepción de un certificado digital” en lapágina 298.

Creación de un nuevo certificado digital autofirmadoAl desarrollar una aplicación de producción, es posible que no deseerealizar una autenticación de certificados con un certificado digitalreal hasta que termine las pruebas del producto. ConiKeyman,puede crear un certificado digital autofirmado y utilizarlo pararealizar pruebas. Se trata de un certificado digital temporal quepuede emitir el usuario con el propio usuario como una CA.

Nota: no distribuya una aplicación de producción con un certificadodigital autofirmado; los navegadores o clientes no loreconocerán ni se comunicarán de una forma segura con suservidor.


C.

Gestión

decertificados

coniK

eyman

Durante la instalación, WebSEAL proporciona un certificadoautofirmado denominado “Policy Director”. Puede utilizar estecertificado para realizar pruebas o puede crear un nuevo certificadoautofirmado.

Para crear un certificado digital autofirmado, siga los pasossiguientes:

1. Utilice iKeyman para abrir el archivo de clavespdsrv.kdb uotro archivo de claves personalizado.

La barra de título de la ventana Gestión de claves de IBMmuestra el nombre del archivo de base de datos de clavesseleccionado, indicando que el archivo está abierto y listo.

2. Seleccione Certificados personales de la lista desplegable.

3. Haga clic en el botón Nuevo certificado autofirmado.

Aparecerá el cuadro de diálogo Crear nuevo certificadoautofirmado.

4. Escriba una Etiqueta clave como, por ejemplo “test-cert”.

5. Escriba un Nombre común y una Organización (ambos sonobligatorios) y seleccione un País. Para los campos restantes,acepte los valores predeterminados, o bien escriba o seleccionevalores nuevos.

Consulte la Figura 43 en la página 289.


El campo Certificados personales de la ventana Gestión de clavesde IBM muestra el nombre del certificado digital autofirmadoque ha creado.

288 Versión 3.8

Figura 43. Crear nuevo certificado autofirmado


C.

Gestión

decertificados

coniK

eyman

Adición de un certificado raíz de CA nuevoAntes de agregar un certificado raíz nuevo para una CA específica,primero debe solicitar este certificado a la CA. Cada CA tiene unosprocedimientos exclusivos para esta tarea. Póngase en contacto conla CA apropiada para obtener esta información.

Cuando haya solicitado y recibido un certificado raíz de una CA,puede agregarlo a la base de datos de claves. La mayoría de loscertificados raíz digitales utilizan la forma*.arm (por ejemplo,cert.arm).

Para agregar un certificado raíz de CA a una base de datos, siga lospasos siguientes:

1. En la ventana Gestión de claves de IBM, seleccione Certificadosde firmante de la lista desplegable.

2. Haga clic en Añadir.

Aparecerá la ventana Añadir certificado de CA desde un archivo.

1. Seleccione Datos ASCII codificados en Base64 del menúdesplegable Tipo de datos.

2. Escriba el nombre del archivo de certificado y la ubicación delcertificado raíz de CA o bien haga clic en Examinar paraseleccionar el nombre y la ubicación.


Aparecerá el cuadro de diálogo Entrar una etiqueta.

Figura 44. Cuadro de diálogo Añadir certificado de CA

290 Versión 3.8

4. Especifique una etiqueta de clave para el certificado raíz de CA,por ejemplo VeriSign Root CA Certificate, y haga clic enAceptar.

El campo Certificados de firmante contiene ahora la etiqueta delcertificado raíz de CA que acaba de agregar.

Supresión de un certificado raíz de CASi desea no seguir dando soporte a uno de los firmantes de la listade certificados de firmante, suprima el certificado raíz de CAapropiado.

Nota: antes de suprimirlo, cree una copia de seguridad delcertificado para poder volver a crearlo más adelante.

Para suprimir un certificado raíz de CA de una base de datos, sigalos pasos siguientes:

1. En la ventana Gestión de claves de IBM, seleccione Certificadosde firmante de la lista desplegable.

2. Seleccione (resalte) el certificado raíz de CA que desea suprimir.

3. Haga clic en Suprimir.

Aparecerá la ventana Confirmar.

4. Haga clic en Sí.

La etiqueta del certificado raíz de CA que acaba de suprimir noaparecerá más en el campo Certificados de firmante.

Copia de certificados entre bases de datosAl configurar una red fiable privada o utilizar certificadosautofirmados para realizar pruebas, es posible que necesite copiar uncertificado de una base de datos y agregarlo en otra base de datos.Hay tres métodos para mover certificados entre bases de datos:

¶ Extracción de un certificado a un archivo; adición de uncertificado a un archivo

¶ Importación de un certificado directamente desde una base dedatos


C.

Gestión

decertificados

coniK

eyman

¶ Exportación de un certificado directamente a una base de datos

Extracción de un certificado a un archivo; adición deun certificado a un archivo

Para extraer un certificado de la base de datos de claves (origen) aun archivo y luego agregarlo a una base de datos de claves (destino),siga los pasos siguientes:

1. Abra la base de datos de claves de “origen”.

2. En el menú desplegable de la ventana Gestión de claves de IBM,seleccione el tipo de certificado que desea exportar: uncertificado personal o de firmante.

3. Seleccione el certificado que desea agregar a otra base de datos.

4. Si selecciona un certificado personal, haga clic en el botónExtraer certificado. Si selecciona un certificado de firmante, hagaclic en el botón Extraer.

Aparecerá la ventana Extraer certificado a un archivo.


El tipo de datos debe coincidir con el tipo de datos delcertificado almacenado en el archivo de certificado. LaherramientaiKeyman da soporte a los archivos ASCIIcodificados con Base64 y los certificados binarios codificadoscon DER.

6. Especifique el nombre del archivo de certificado y la ubicacióndonde desea almacenar el certificado o bien haga clic enExaminar para seleccionar nombre y ubicación.

Figura 45. Extraer certificado a un archivo

292 Versión 3.8


El certificado se escribe en el archivo especificado.

Para agregar un certificado del archivo a la base de datos de destino,siga los pasos siguientes:

1. Abra la base de datos de claves de destino.

2. Seleccione el tipo de certificado que desea agregar: un certificadopersonal o de firmante.

3. Haga clic en Añadir para si se trata de un certificado de firmante.Haga clic en Recibir si se trata de un certificado personal.

4. Escriba el nombre del archivo de certificado y la ubicaciónutilizada al extraer el certificado. También puede utilizar el botónExaminar.


6. Una ventana de confirmación le solicitará que seleccione si elcertificado será el predeterminado. Haga clic en Sí o No.

El certificado se agregará a la base de datos de destino yaparecerá en la lista de certificados.

Importación de un certificado directamente desde unabase de datos

Para importar un certificado de una base de datos de claves (origen)a otra base de datos de claves (destino), siga los pasos siguientes:

1. Abra la base de datos de claves de “destino”.

Figura 46. Recibir certificado desde un archivo


C.

Gestión

decertificados

coniK

eyman

2. En el menú desplegable de la ventana Gestión de claves de IBM,seleccione el tipo de certificado que desea exportar: uncertificado personal o de firmante.

3. Haga clic en el botón Exportar/Importar.

Aparecerá la ventana Exportar/Importar claves.

4. En Elegir tipo de acción, seleccione Importar clave.

5. Seleccione Archivo de base de datos clave de CMS en el menúdesplegable Tipo de archivo clave.

6. Especifique el nombre del archivo y la ubicación de la base dedatos de claves de origen que contiene el certificado que deseaimportar. También puede utilizar el botón Examinar.



8. Especifique la contraseña y haga clic en Aceptar.

Aparecerá la ventana Seleccionar en la lista de etiquetas clave.

9. Seleccione el certificado que desea importar y haga clic enAceptar.

El certificado aparecerá en la lista la de base de datos de destino.

Exportación de un certificado directamente a unabase de datos

Para exportar un certificado de una base de datos de claves (origen)a otra base de datos de claves (destino), siga los pasos siguientes:

Figura 47. Exportar/Importar claves

294 Versión 3.8

1. Abra la base de datos de claves de “origen”.

2. En el menú desplegable de la ventana Gestión de claves deIBM, seleccione el tipo de certificado que desea exportar: uncertificado personal o de firmante.

3. Seleccione (resalte) el certificado que desea exportar.

4. Haga clic en el botón Exportar/Importar.

Aparecerá la ventana Exportar/Importar claves.

5. En Elegir tipo de acción, seleccione Exportar clave.

6. Seleccione Archivo de base de datos clave de CMS en el menúdesplegable Tipo de archivo clave.

7. Especifique el nombre de archivo y la ubicación de la base dedatos de claves de destino a la que desea enviar el certificado.También puede utilizar el botón Examinar.

Nota: aparecerá un mensaje acerca de la sustitución de estearchivo de base de datos. Haga clic en “Sí”. Elcertificado exportado se agregará a la base de datos dedestino. No se perderá nada.



9. Especifique la contraseña de la base de datos de destino y hagaclic en Aceptar.

Figura 48. Exportar/Importar claves


C.

Gestión

decertificados

coniK

eyman

10. Cuando abra la base de datos de destino, el certificadoexportado aparecerá en la lista de certificados.

Petición de un certificado de servidorWebSEAL requiere un certificado firmado por una CA paraautenticarse en los clientes SSL. WebSEAL puede necesitar distintoscertificados para dar servicio a otros requisitos de autenticación(como, por ejemplo, la respuesta a un servidor de aplicacionesconectado conjunctioncp –K ).

La utilidad iKeyman le permite generar una petición de certificadoque puede enviar a la CA apropiada.

Para generar una petición de certificado, siga los pasos siguientes:

1. En la ventana Gestión de claves de IBM, seleccione Peticionesde certificados personales de la lista desplegable.

2. Haga clic en Nuevo.

Aparecerá el cuadro de diálogo Crear nueva clave y petición decertificado.

296 Versión 3.8

3. Escriba una Etiqueta clave para la petición del certificado.

4. Escriba un Nombre común y una Organización y seleccione unPaís.

Para los campos restantes, acepte los valores predeterminados, obien escriba o seleccione valores nuevos.

5. En la parte inferior de la ventana, escriba un nombre y unaubicación para el archivo. También puede utilizar el botónExaminar.


Aparecerá una ventana de confirmación que verificará que hacreado correctamente una petición de certificado digital nuevo.


El campo Peticiones de certificados personales muestra laetiqueta de claves de la petición de certificado digital nueva queha creado.

Figura 49. Crear nueva clave y petición de certificado


C.

Gestión

decertificados

coniK

eyman

8. Envíe el archivo a la CA apropiada para solicitar un certificadodigital nuevo o bien corte y pegue la petición en los formulariosde petición del sitio Web de la CA.

Recepción de un certificado digitalCuando la CA le envíe un certificado digital firmado nuevo, deberáagregarlo a la base de datos de claves desde la que se ha generado lapetición.

Para recibir un certificado digital, siga los pasos siguientes:

1. En la ventana Gestión de claves de IBM, seleccione Certificadospersonales de la lista desplegable.

2. Haga clic en Recibir.

Aparecerá la ventana Recibir certificado desde un archivo.


4. Escriba el nombre del archivo de certificado y la ubicación delcertificado digital nuevo. También puede utilizar el botónExaminar.

Nota: si la CA envía el certificado como parte de un mensaje decorreo electrónico, deberá cortar y pegar el certificado enun archivo separado.


6. Aparecerá la ventana Entrar una etiqueta.

7. Especifique una etiqueta para el certificado nuevo y haga clic enAceptar.

El campo Certificados personales contiene ahora la etiqueta delcertificado digital nuevo.

Supresión de un certificado digitalSi ya no utiliza uno de los certificados digitales, puede suprimirlo dela base de datos.

298 Versión 3.8

Nota: antes de suprimirlo, cree una copia de seguridad por si másadelante desea volver a crearlo.

Para suprimir un certificado digital, siga los pasos siguientes:


2. Seleccione (resalte) el certificado digital que desea suprimir yhaga clic en Suprimir.

Aparecerá la ventana Confirmar.

3. Haga clic en Sí.

La etiqueta del certificado digital seleccionado dejará de apareceren el campo Certificados personales.

Asignación de un certificado predeterminado nuevoLa utilidad iKeyman le permite especificar un certificado digitalpredeterminado para WebSEAL para utilizarlo si la base de datos declaves contiene más de una entrada de certificado personal. (Esposible que tenga varios certificados digitales en una base de datos siha empezado a utilizar un certificado digital autofirmado en laaplicación (para realizar pruebas) mientras esperaba el certificadodigital oficial de la CA escogida.)

Cuando haya recibido un certificado digital firmado de la CA, puededejar el certificado digital autofirmado en la base de datos y empezara utilizar el emitido por la CA designándolo como certificado digitalpredeterminado. El certificado digital predeterminado se indicamediante un asterisco (*) delante de la etiqueta de la entrada.

El primer certificado digital recibido o creado como autofirmado semarca de forma automática como certificado digital predeterminado.Cada vez que se reciba un certificado digital nuevo o se cree uncertificado digital autofirmado se le ofrecerá la opción de convertirloen certificado digital predeterminado. De todas formas, puedecambiar este valor de forma explícita en cualquier momento.


C.

Gestión

decertificados

coniK

eyman

Para cambiar el certificado digital predeterminado, siga los pasossiguientes:


El certificado digital predeterminado se indica mediante unasterisco (*) delante de la etiqueta de la entrada.

2. Seleccione otro certificado digital que desee establecer comocertificado digital predeterminado y haga clic en Ver/Editar.También puede hacer doble clic en la entrada.

Aparecerá la ventana Información clave del certificado.

3. Active la casilla de verificación Establecer el certificado comovalor por omisión y haga clic en Aceptar.

El certificado aparecerá como certificado digital predeterminadocon un asterisco (*) delante de la etiqueta.

Cambio de una contraseña de base de datosLa herramienta iKeyman le permite cambiar la contraseña de unabase de datos de claves.

Para cambiar una contraseña de base de datos de claves, siga lospasos siguientes:

1. Abra una base de datos de claves.

2. Seleccione Cambiar contraseña en el menú desplegable Archivode bases de datos clave.

Aparecerá la ventana Cambiar contraseña.

3. Especifique una contraseña nueva en el campo Contraseña nuevay escríbala de nuevo en el campo Confirmar nueva contraseña.

4. Active la casilla de verificación ¿Establecer fecha de caducidad?si es necesario.

5. Active la casilla de verificación ¿Ocultar contraseña para unarchivo? si es necesario.


300 Versión 3.8

Un mensaje en la barra de estado indicará que la petición se harealizado correctamente.


C.

Gestión

decertificados

coniK

eyman

302 Versión 3.8

Índice

Aaccept-client-certs 117account-locked 41acct_locked.html 42adquisición de credenciales

EPAC 9visión general 8

agent.log 55ejemplo 60

agents 55agents-file 55autenticación

autenticación básica 109Cabecera HTTP 119CDSSO 131certificate (certificado) 114comunidad electrónica 138configuración de varios métodos de

autenticación 106dirección IP 122formularios 112información sobre el proceso 88métodos soportados 89MPA 124objetivos 7señal 122solicitud de inicio de sesión 107tipos de datos de sesión soportados 89visión general 6visión general de la configuración 104

autenticación básicaconfiguración 109

autenticación de CDSSO 131autenticación de certificados 114autenticación de comunidad electrónica 138

características 141cifrado de la señal de″garantización″ 152configuración 153cookie de comunidad electrónica 149

autenticación de comunidad electrónica(continuación)

flujo de procesos 142petición y respuesta de garantización 150señal de garantización 151

autenticación de direcciones IP 122autenticación de formularios 112autenticación de señales 122autenticación incremental 72autenticación MPA 124authentication-levels, stanza 73, 80authtoken-lifetime 137

Bba-auth 110backicon 31basic-auth-realm 110basicauth-dummy-passwd 210biblioteca compartida CDMF 132

Ccabecera 120cabecera PD_PORTAL 235caché de documentos 33

estadísticas de la caché 35vaciar cachés 35

caché de GSO, configurar 219caché de LTPA, configurar 222caché de sesión

GSKit 92WebSEAL 92

caché de sesión de GSKit 92configuración 95


Índice

caché de sesión de WebSEAL 92configuración 93

cache-refresh-interval 53calidad de protección

hosts 51nivel predeterminado 50redes 51

cdsso 135cdsso-auth 134cdsso_key_gen 102, 136, 152cdsso-peers, stanza 136cdssoauthn 135cert-ssl 118certificados

gestión 42GSKit 43iKeyman 43tipos de archivos de base de datos de

claves 44cgi-timeout 27client-connect-timeout 26comando pd_start 22conexiones

visión general 10conexiones (junctions)

-b filter 213-b gso 214-b ignore 212-b supply 210aplicar permisos 198autenticación de certificados 199autenticadas mutuamente (-D, -K, -B, -U,

-W) 167autenticar con cabecera de BA (-B, -U,

-W) 170certificado de cliente de WebSEAL (-K) 169coincidencia de DN (-D) 169conexiones (junctions) proxy (-H, -P) 172de WebSEAL a WebSEAL (-C) 174directrices para la creación 162enviar cookie de sesión al servidor de portal

(-k) 180especificar dirección IP en cabeceras HTTP

(-r) 179especificar identidad del cliente en cabeceras

HTTP (-c) 177

conexiones (junctions)(continuación)especificar UUID de fondo (-u) 190filtrar direcciones URL HTML estáticas 197forzar una nueva conexión (junction)

(-f) 175gestionar direcciones URL absolutas con filtro

de scripts 185gestionar direcciones URL relativas al

servidor con cookies 184gestionar direcciones URL relativas al

servidor con correlación de conexiones(junction) 187

global sign-on (GSO) 215impacto de las opciones -b en las conexiones

(junctions) autenticadas mutuamente 171LTPA (-A, -F, -Z) 221montaje de varios servidores 196opción de host (-h) 164opción de tipo (-t) 164opciones gso (-b gso, -T) 218opciones necesarias 164pdadmin server task 163proceso de direcciones URL a partir de scripts

(-j) 182referencia de comandos 269sistemas de archivos Windows (-w) 194soporte para conexiones (junction) con

información de estado (-s, -u) 189soporte para direcciones URL no sensibles a

mayúsculas y minúsculas (-i) 181tabla de correlaciones de conexiones 187

conexiones (junctions) autenticadasmutuamente 167

conexiones (junctions) WebSEAL, véasejunctions 159

cookie de comunidad electrónica 149cookies de recuperación tras error,

configurar 101cookies de sesión 96

activación 97credenciales

atributos ampliados 230insertar datos en cabeceras HTTP 231insertar datos LDAP 230

CRL, comprobación 49

304 Versión 3.8

Ddatos de LDAP en cabeceras HTTP 230db-file 53derechos empresariales dinámicos 230dinámicos, derechos empresariales 230direcciones URL dinámicas

actualizar, dynurl update 240colocar limitaciones en peticiones POST 242correlacionar objetos ACL 238dynurl-allow-large-posts 243dynurl-map 238ejemplo 246métodos GET y POST 242post-max-read 242proporcionar control de acceso 237resolver 241resumen y notas técnicas 244visión general 237

directorio raíz de documentoscambiar ubicación 29

directorio raíz de instalación de WebSEAL. 21directory-index 30diricon 31disable-ssl-v2 24disable-ssl-v3 24disable-tls-v1 24doc-root 28dynurl-allow-large-posts 243dynurl.conf 238dynurl-map 238dynurl update 240

Ee-community-name 154e-community-sso-auth 153ec-cookie-lifetime 156entrust-client 120escalabilidad 14

servidores de fondo replicados 17servidores frontales replicados 14

escucha de notificación de actualizaciones 52,53

estadísticas de la caché 35estado de sesión

activar cookies de sesión 97cookies de sesión 96gestión 91tipos de datos de ID de sesión válidos 99

Ffailover-auth 102failover-cookie-lifetime 103failover-cookies-keyfile 103filtrar direcciones URL HTML estáticas

direcciones URL absolutas 197direcciones URL relativas al servidor 197

fin de sesión 108flush-time 57fondo, soporte para aplicaciones de 228formato de registro de HTTP común 59forms-auth 112

Gglobal sign-on (GSO) 215gmt-time 56GSKit 43

tipos de archivos 44GSO 215

configurar caché de GSO 219gso-cache-enabled 219gso-cache-entry-idle-timeout 219gso-cache-lifetime 219gso-cache-size 219

Hhelp 41help.html 42HTML, páginas personalizadas 40


Índice

HTML, páginas personalizadas(continuación)soporte para macros 42

http 23HTTP, autenticación de cabeceras 119HTTP, mensajes de error 36

soporte para macros 40HTTP, registro 55http-headers-auth 120HTTP_IV_CREDS 177, 226, 229HTTP_IV_GROUPS 177, 226, 229HTTP_IV_REMOTE_ADDRESS 179HTTP_IV_USER 177, 226, 229http-port 24http-request 120HTTP-Tag-Value 233http-timeout (junctions) 27httpauthn 120https 24https-port 24https-timeout (junctions) 27

Iiconos de índice de directorios 31ID de sesión SSL 97iKeyman 47

adición de un certificado raíz de CAnuevo 290

apertura de la base de datos de clavespredeterminada 282

asignación de un certificado predeterminadonuevo 299

cambio de una contraseña de base dedatos 300

certificado de prueba de WebSEAL 116conexiones (junctions) SSL autenticadas

mutuamente 168copia de certificados entre bases de

datos 291creación de un nuevo certificado

autofirmado 287creación de una base de datos de claves

nueva 284inicio 280

iKeyman (continuación)petición de un certificado de servidor 296recepción de un certificado 298SSL, conexiones (junctions) de tipo 166supresión de un certificado 298supresión de un certificado raíz de CA 291visión general 48

inactive-timeout 94inicio de sesión

condiciones de solicitud 107inicio de sesión único

-b filter 213-b gso 214-b ignore 212-b supply 210CDSSO 131comunidad electrónica 138conceptos 208configurar caché de GSO 219especificar identidad del cliente en cabeceras

BA 209global sign-on (GSO) 215LTPA (WebSphere) 220

intra-domain-key 152, 154ipaddr-auth 122is-master-authn-server 155iv-creds 177, 229iv-groups 177, 229iv-remote-address 179iv-user 177, 229

Jjmt.conf 187jmt load 187jmt-map 187junction-db 160junctions

visión general 160

306 Versión 3.8

Lldapauthn 111, 113libcdssoauthn 135libhttpauthn 120libldapauthn 111, 113libsslauthn 118libtokenauthn 123listen-flags 53log-filtered-pages 58login 41login.html 42, 114logout 41logout.html 42longitud del contenido, request.log 58LTPA (WebSphere) 220

configurar caché de LTPA 222configurar conexión (junction) 221

ltpa-cache-enabled 222ltpa-cache-entry-idle-timeout 222ltpa-cache-entry-lifetime 222ltpa-cache-size 222

Mmaster-authn-server 155master-http-port 153master-https-port 154max-entries 93max-size 57método GET 242método POST 242

configurar limitaciones 242métodos de autenticación, resumen 89mgt-pages-root 40mpa 128

Nnext-token 41nexttoken.html 42niveles de protección 4

Pparámetros de tiempo de espera

HTTP y HTTPS 26passwd-change 41passwd-change-failure 41passwd-change-success 41passwd_exp.html 42passwd-expired 41passwd.html 42passwd-ldap 111, 113passwd_rep.html 42pd.conf 231pdadmin server task (junctions) 163persistent-con-timeout 26petición y respuesta de garantización 150ping-time (junctions) 27pkmscdsso 137pkmslogout 108pkmspasswd 109pkmsvouchfor 150, 155política de ACL default-webseal 65política de inicio de sesión de tres intentos 65política de intensidad de la contraseña 68política de pdadmin

disable-time-interval 65max-login-failures 65max-password-repeated-chars 68min-password-alphas 68min-password-length 68min-password-non-alphas 68password-spaces 68

política de seguridadACL, políticas 5atributos ampliados 5planificación 5políticas de objetos protegidos 5

política POP de autenticación basada en lared 79

política POP de calidad de protección 83política POP de intensidad de la

autenticación 72políticas de ACL, específicas de WebSEAL 63POP, política

autenticación basada en la red 79calidad de protección 83


Índice

POP, política(continuación)intensidad de la autenticación

(incremental) 72portal-map, stanza 235post-max-read 242programación de CGI

soporte 226soporte para variables de entorno

WIN32 227protección de recursos 4

Qquery_contents 200

instalar 200personalizar 203proteger 205

query_contents.c 200query_contents.cfg 200query_contents.exe 200query_contents.html 200query_contents.sh 200

Rreferer.log 55

ejemplo 60referers 55referers-file 55registro HTTP 55REMOTE_USER 226replicar servidores WebSEAL frontales 54request.log 55

configurar longitud del contenidoregistrada 58

ejemplo 59requests 55requests-file 55resend-webseal-cookies 97

Sscript-filter 185server-name 54server-root 22servicio de personalización

configuración de WebSEAL 235ejemplo 236visión general 234

servidores WebSEAL frontalesreplicar 54

solicitud de inicio de sesióncondiciones 107

sondeo 52sondeo de la base de datos de autorizaciones 53soporte para aplicaciones de fondo 228ssl-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 95ssl-qop-mgmt 50ssl-v2-timeout 95ssl-v3-timeout 95sslauthn 118stanza acnt-mgt 40stanza aznapi-configuration 53stanza cgi-types 32stanza content-caches 33stanza de variable de entorno cgi 227stanza filter-url 58, 198stanza inter-domain-keys 152, 156stanza ldap-ext-cred-tags 231, 233stanza logging 58stanza ltpa-cache 222stanza script-filtering 185stanza ssl-qop-mgmt-default 50stanza ssl-qop-mgmt-hosts 51stanza ssl-qop-mgmt-networks 51stepup-login 41, 76stepuplogin.html 42, 76

308 Versión 3.8

Ttcp-port 53timeout 94tipos de archivos de base de datos de claves 44tipos de datos de ID de sesión 99tipos de datos de sesión 89token-auth 123token-cdas 123token-login 41tokenauthn 123tokenlogin.html 42

Uubicación de bases de datos de autorizaciones

replicadas 53ubicación de réplicas de base de datos de

autorizaciones 53udp-port 53unknownicon 31use-same-session 97, 98usuarios no autenticados, controlar 84

Vvaciar cachés 35valor de indicador 230variables de entorno de, soporte 227vf-token-lifetime 155vf-url 155

WWebSEAL

iniciar y detener el servidor 22visión general 1

webseal-cert-keyfile 46webseal-cert-keyfile-label 46, 116, 199webseal-cert-keyfile-pwd 46

webseal-cert-keyfile-stash 46webseal-mpa-servers, grupo 127, 129webseald.conf

referencia 251ubicación 20visión general 20

WebSphere LTPA 220worker-threads 25


Índice

310 Versión 3.8

Printed in Denmark by IBM Danmark A/S

GC10-3653-00

Documents

Tivoli SecureWay Policy Director WebSEAL Guía de ...publib.boulder.ibm.com/tividd/td/SW_30/GC32-0684-01/es...Métodos de autenticación y tipos de datos de sesión válidos..... 125