IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/es_ES/PDF/ws... ·...

IBM Tivoli Access Manager

WebSEAL Guía del administradorVersión 3.9

GC10-3839-00

NotaAntes de utilizar esta información y el producto al que da soporte, lea la información incluida en el Apéndice C, “Avisos”en la página 253.

Primera edición (julio de 2002)

Este manual es la traducción del original inglés IBM Tivoli Access Manager WebSEAL Administrator’s Guide ,GC23-4682-00.

© Copyright International Business Machines Corporation 1999, 2002. Reservados todos los derechos.

Contenido

Prefacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixA quién va dirigido este manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixContenido de este manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixPublicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xPublicaciones relacionadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiAcceso a las publicaciones en línea . . . . . . . . . . . . . . . . . . . . . . . . . . xvSolicitud de publicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvComentarios sobre las publicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Accesibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviCómo ponerse en contacto con el soporte al cliente . . . . . . . . . . . . . . . . . . . . . . xviConvenios utilizados en este manual . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Convenios tipográficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Capítulo 1. Visión general de IBM Tivoli Access Manager WebSEAL . . . . . . . . . . 1Presentación de IBM Tivoli Access Manager y WebSEAL . . . . . . . . . . . . . . . . . . . . 1Información sobre el modelo de seguridad de Access Manager . . . . . . . . . . . . . . . . . . 3

Espacio de objetos protegidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Definición y aplicación de políticas de ACL y POP . . . . . . . . . . . . . . . . . . . . . 4Administración de política: Web Portal Manager . . . . . . . . . . . . . . . . . . . . . . 6

Protección del espacio web con WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . 7Planificación e implementación de la política de seguridad . . . . . . . . . . . . . . . . . . . . 8

Identificación de tipos de contenido y niveles de protección . . . . . . . . . . . . . . . . . . 9Información sobre la autenticación de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . 10

Objetivos de autenticación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Acceso autenticado y no autenticado a los recursos . . . . . . . . . . . . . . . . . . . . . 11Estructura de caché de sesión/credenciales de WebSEAL . . . . . . . . . . . . . . . . . . . 12

Información sobre las conexiones (junctions) WebSEAL . . . . . . . . . . . . . . . . . . . . . 14Conexiones (junctions) WebSEAL y escalabilidad de sitios web . . . . . . . . . . . . . . . . . 16

Capítulo 2. Configuración básica del servidor . . . . . . . . . . . . . . . . . . . 21Información general del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Directorio raíz de la instalación de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . 21Inicio y detención de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 22WebSEAL representado en el espacio de objetos protegidos . . . . . . . . . . . . . . . . . . 22WebSEAL devuelve HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Archivo de registro de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Utilización del archivo de configuración de WebSEAL . . . . . . . . . . . . . . . . . . . . . 23Presentación del archivo de configuración webseald.conf . . . . . . . . . . . . . . . . . . . 23Directorio raíz de servidor WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Configuración de los parámetros de comunicación . . . . . . . . . . . . . . . . . . . . . . 25Configuración de WebSEAL para peticiones HTTP . . . . . . . . . . . . . . . . . . . . . 25Configuración de WebSEAL para peticiones HTTPS . . . . . . . . . . . . . . . . . . . . . 26Restricción de conexiones de versiones de SSL específicas . . . . . . . . . . . . . . . . . . . 26Parámetros de tiempo de espera para la comunicación HTTP/HTTPS . . . . . . . . . . . . . . . 26Parámetros adicionales de tiempo de espera del servidor WebSEAL . . . . . . . . . . . . . . . 27

Gestión del espacio web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Directorio raíz del árbol de documentos web . . . . . . . . . . . . . . . . . . . . . . . 28Configuración del índice de directorios . . . . . . . . . . . . . . . . . . . . . . . . . 29Windows: convenios de denominación para programas CGI . . . . . . . . . . . . . . . . . . 30Configuración del almacenamiento en la caché de documentos web . . . . . . . . . . . . . . . 31Especificación de tipos de documento para el filtrado . . . . . . . . . . . . . . . . . . . . 33

Gestión de páginas personalizadas de mensajes de error HTTP . . . . . . . . . . . . . . . . . . 33Soporte para macros de las páginas de mensajes de error HTTP . . . . . . . . . . . . . . . . . 36

Gestión de páginas personalizadas de gestión de cuentas . . . . . . . . . . . . . . . . . . . . 36

© Copyright IBM Corp. 1999, 2002 iii

Parámetros y valores de páginas personalizadas . . . . . . . . . . . . . . . . . . . . . . 36Descripciones de páginas HTML personalizadas . . . . . . . . . . . . . . . . . . . . . . 37

Gestión de certificados de cliente y servidor . . . . . . . . . . . . . . . . . . . . . . . . 38Información sobre tipos de archivo de bases de datos de claves GSKit . . . . . . . . . . . . . . . 39Configuración de parámetros de base de datos de claves . . . . . . . . . . . . . . . . . . . 40Utilización del programa de utilidad de gestión de certificados iKeyman . . . . . . . . . . . . . . 41Configuración de la comprobación de CRL . . . . . . . . . . . . . . . . . . . . . . . . 42Configuración de la caché de CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Configuración del registro HTTP predeterminado . . . . . . . . . . . . . . . . . . . . . . 43Habilitación e inhabilitación del registro HTTP . . . . . . . . . . . . . . . . . . . . . . 43Especificación del tipo de indicación de la hora . . . . . . . . . . . . . . . . . . . . . . 44Especificación de los umbrales de creación de archivo de registro . . . . . . . . . . . . . . . . 44Especificación de la frecuencia de vaciado de los búferes de archivo de registro . . . . . . . . . . . 44Formato de registro común HTTP (para request.log) . . . . . . . . . . . . . . . . . . . . . 45Visualización del archivo request.log . . . . . . . . . . . . . . . . . . . . . . . . . . 45Visualización del archivo agent.log . . . . . . . . . . . . . . . . . . . . . . . . . . 45Visualización del archivo referer.log . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Configuración del registro HTTP mediante el registro de eventos . . . . . . . . . . . . . . . . . 46Registro de mensajes de servicios de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . 47

Capítulo 3. Configuración avanzada del servidor . . . . . . . . . . . . . . . . . . 49Configuración de la calidad predeterminada de nivel de protección . . . . . . . . . . . . . . . . 49

Configuración de QOP para redes y hosts individuales . . . . . . . . . . . . . . . . . . . . 50Configuración de actualizaciones y sondeo de la base de datos de autorizaciones . . . . . . . . . . . . 51

Configuración de la escucha de notificaciones de actualizaciones . . . . . . . . . . . . . . . . 51Configuración del sondeo de la base de datos de autorizaciones . . . . . . . . . . . . . . . . . 52

Gestión de la asignación de threads de trabajo. . . . . . . . . . . . . . . . . . . . . . . . 52Configuración de threads de trabajo de WebSEAL . . . . . . . . . . . . . . . . . . . . . 52Asignación de threads de trabajo para conexiones (junctions) (imparcialidad de conexiones) . . . . . . . 53

Réplica de servidores WebSEAL frontales . . . . . . . . . . . . . . . . . . . . . . . . . 55Configuración de múltiples instancias de servidor WebSEAL . . . . . . . . . . . . . . . . . . . 56

Visión general de la configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Configuración de múltiples instancias de WebSEAL en UNIX. . . . . . . . . . . . . . . . . . 56Configuración de múltiples instancias de WebSEAL en Win NT/2000 . . . . . . . . . . . . . . . 59Desconfiguración de múltiples instancias de WebSEAL . . . . . . . . . . . . . . . . . . . . 61Comandos de inicio, detención, reinicio y estado del servidor . . . . . . . . . . . . . . . . . 61

Configuración del cambio de usuario (SU) para administradores . . . . . . . . . . . . . . . . . 62Información sobre el flujo de proceso de cambio de usuario . . . . . . . . . . . . . . . . . . 63Habilitación del cambio de usuario: Resumen . . . . . . . . . . . . . . . . . . . . . . . 64Configuración del formulario HTML de cambio de usuario . . . . . . . . . . . . . . . . . . 65Habilitación y exclusión de usuarios del cambio de usuario . . . . . . . . . . . . . . . . . . 66Configuración del mecanismo de autenticación de cambio de usuario . . . . . . . . . . . . . . . 67Configuración de un mecanismo de cambio de usuario de CDAS . . . . . . . . . . . . . . . . 68Influencia en otras funciones de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . 69

Configuración del almacenamiento en la caché de peticiones del servidor WebSEAL . . . . . . . . . . . 70Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Flujo de proceso de almacenamiento en la caché del servidor. . . . . . . . . . . . . . . . . . 70Configuración de parámetros del almacenamiento en la caché del servidor . . . . . . . . . . . . . 72Notas y limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Gestión de los caracteres codificados UTF-8 . . . . . . . . . . . . . . . . . . . . . . . . 73Prevención de la vulnerabilidad causada por scripts de sitios cruzados . . . . . . . . . . . . . . . 75

Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Configuración del filtrado de cadenas de direcciones URL . . . . . . . . . . . . . . . . . . . 76

Supresión de la identidad del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 76Utilización de las estadísticas de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . 77

Sintaxis del comando pdadmin stats . . . . . . . . . . . . . . . . . . . . . . . . . . 77Componentes de estadísticas y tipos de actividad. . . . . . . . . . . . . . . . . . . . . . 80Habilitación estática de estadísticas mediante el registro de eventos . . . . . . . . . . . . . . . 85

Utilización del programa de utilidad de rastreo para capturar acciones de WebSEAL . . . . . . . . . . . 86Sintaxis básica del comando trace . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Componentes de rastreo de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . 87

iv IBM Tivoli Access Manager: WebSEAL Guía del administrador

Capítulo 4. Política de seguridad de WebSEAL . . . . . . . . . . . . . . . . . . 89Políticas de ACL específicas de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . 89

/WebSEAL/<host>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89/WebSEAL/<host>/<archivo> . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Permisos ACL de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Política de ACL predeterminada de /WebSEAL . . . . . . . . . . . . . . . . . . . . . . 90Caracteres válidos para nombres de ACL . . . . . . . . . . . . . . . . . . . . . . . . 90

Política de inicio de sesión en tres intentos . . . . . . . . . . . . . . . . . . . . . . . . . 91Sintaxis de los comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Política de intensidad de contraseñas . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Política de intensidad de contraseñas establecida por el programa de utilidad pdadmin . . . . . . . . . 92Sintaxis de los comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Ejemplos de contraseñas válidas y no válidas . . . . . . . . . . . . . . . . . . . . . . . 94Valores globales y específicos para un usuario . . . . . . . . . . . . . . . . . . . . . . . 94

Política POP de intensidad de autenticación (incremental) . . . . . . . . . . . . . . . . . . . . 95Configuración de los niveles de autenticación incremental . . . . . . . . . . . . . . . . . . . 95Habilitación de la autenticación incremental . . . . . . . . . . . . . . . . . . . . . . . 96Formulario de inicio de sesión incremental . . . . . . . . . . . . . . . . . . . . . . . . 97Algoritmo de autenticación incremental . . . . . . . . . . . . . . . . . . . . . . . . . 98Notas y limitaciones de autenticación incremental . . . . . . . . . . . . . . . . . . . . . 99Distinción entre autenticación incremental y de múltiples factores . . . . . . . . . . . . . . . . 100

Política POP de autenticación basada en la red . . . . . . . . . . . . . . . . . . . . . . . 101Configuración de niveles de autenticación . . . . . . . . . . . . . . . . . . . . . . . . 101Especificación de direcciones IP y rangos . . . . . . . . . . . . . . . . . . . . . . . . 101Inhabilitación de la autenticación incremental por dirección IP . . . . . . . . . . . . . . . . . 102Algoritmo de autenticación basada en red . . . . . . . . . . . . . . . . . . . . . . . . 103Notas y limitaciones de autenticación basada en red . . . . . . . . . . . . . . . . . . . . 103

Política POP de calidad de protección . . . . . . . . . . . . . . . . . . . . . . . . . . 103Gestión de usuarios no autenticados (HTTP / HTTPS) . . . . . . . . . . . . . . . . . . . . 104

Proceso de una petición de un cliente anónimo . . . . . . . . . . . . . . . . . . . . . . 104Obligación del inicio de sesión de usuario . . . . . . . . . . . . . . . . . . . . . . . . 104Aplicaciones HTTPS sin autenticar . . . . . . . . . . . . . . . . . . . . . . . . . . 104Control de usuarios no autenticados con políticas de ACL/POP . . . . . . . . . . . . . . . . 105

Capítulo 5. Autenticación de WebSEAL . . . . . . . . . . . . . . . . . . . . . 107Información sobre el proceso de autenticación . . . . . . . . . . . . . . . . . . . . . . . 107

Tipos de datos de sesión soportados. . . . . . . . . . . . . . . . . . . . . . . . . . 108Métodos de autenticación soportados . . . . . . . . . . . . . . . . . . . . . . . . . 108

Gestión del estado de la sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Visión general del estado de la sesión . . . . . . . . . . . . . . . . . . . . . . . . . 109Visión general de la caché de sesión de GSKit y WebSEAL . . . . . . . . . . . . . . . . . . 109Configuración de la caché de ID de sesión SSL de GSKit . . . . . . . . . . . . . . . . . . . 110Configuración de la caché de sesión/credenciales de WebSEAL. . . . . . . . . . . . . . . . . 111Mantenimiento del estado con cookies de sesión. . . . . . . . . . . . . . . . . . . . . . 112Determinación de los tipos de datos válidos de ID de sesión . . . . . . . . . . . . . . . . . 114Configuración de cookies de resolución de errores . . . . . . . . . . . . . . . . . . . . . 115

Visión general de la configuración de autenticación. . . . . . . . . . . . . . . . . . . . . . 118Parámetros de autenticación local. . . . . . . . . . . . . . . . . . . . . . . . . . . 119Parámetros de autenticación de CDAS personalizado externo . . . . . . . . . . . . . . . . . 119Configuración predeterminada para la autenticación de WebSEAL. . . . . . . . . . . . . . . . 119Configuración de múltiples métodos de autenticación . . . . . . . . . . . . . . . . . . . . 120Solicitud de inicio de sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Comandos de fin de sesión y de cambio de contraseña . . . . . . . . . . . . . . . . . . . 121

Configuración de la autenticación básica . . . . . . . . . . . . . . . . . . . . . . . . . 122Habilitación e inhabilitación de la autenticación básica . . . . . . . . . . . . . . . . . . . 122Definición del nombre de dominio . . . . . . . . . . . . . . . . . . . . . . . . . . 122Configuración del mecanismo de autenticación básica . . . . . . . . . . . . . . . . . . . . 123Condiciones de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Configuración de la autenticación de formularios . . . . . . . . . . . . . . . . . . . . . . 123Habilitación e inhabilitación de la autenticación de formularios. . . . . . . . . . . . . . . . . 123Configuración del mecanismo de autenticación de formularios . . . . . . . . . . . . . . . . . 124

Contenido v

Condiciones de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Personalización de los formularios HTML de respuesta . . . . . . . . . . . . . . . . . . . 124

Configuración de la autenticación de certificados del cliente . . . . . . . . . . . . . . . . . . . 125Información general: autenticación mutua mediante certificados . . . . . . . . . . . . . . . . 125El certificado de prueba de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . 126Habilitación e inhabilitación de la autenticación de certificados . . . . . . . . . . . . . . . . . 127Configuración del mecanismo de autenticación de certificados . . . . . . . . . . . . . . . . . 127Condiciones de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Configuración de la autenticación de cabeceras HTTP . . . . . . . . . . . . . . . . . . . . . 128Habilitación e inhabilitación de la autenticación de cabeceras HTTP . . . . . . . . . . . . . . . 128Especificación de tipos de cabecera . . . . . . . . . . . . . . . . . . . . . . . . . . 129Configuración del mecanismo de autenticación de cabeceras HTTP . . . . . . . . . . . . . . . 129Condiciones de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Configuración de autenticación de direcciones IP . . . . . . . . . . . . . . . . . . . . . . 130Habilitación e inhabilitación de la autenticación de direcciones IP . . . . . . . . . . . . . . . . 130Configuración del mecanismo de autenticación de direcciones IP . . . . . . . . . . . . . . . . 130

Configuración de la autenticación de señales . . . . . . . . . . . . . . . . . . . . . . . . 130Habilitación e inhabilitación de la autenticación de señales . . . . . . . . . . . . . . . . . . 130Configuración del mecanismo de autenticación de señales . . . . . . . . . . . . . . . . . . 131

Soporte para agentes MPA (Multiplexing Proxy Agents) . . . . . . . . . . . . . . . . . . . . 131Tipos de datos de sesión y métodos de autenticación válidos . . . . . . . . . . . . . . . . . 132Flujo de proceso de autenticación para MPA y clientes múltiples . . . . . . . . . . . . . . . . 133Habilitación e inhabilitación de la autenticación de MPA . . . . . . . . . . . . . . . . . . . 134Creación de una cuenta de usuario para el MPA. . . . . . . . . . . . . . . . . . . . . . 134Adición de la cuenta de MPA al grupo webseal-mpa-servers . . . . . . . . . . . . . . . . . 134Limitaciones de la autenticación de MPA . . . . . . . . . . . . . . . . . . . . . . . . 134

Configuración de la reautenticación basada en la política de seguridad . . . . . . . . . . . . . . . 134Condiciones que afectan a la reautenticación de POP . . . . . . . . . . . . . . . . . . . . 134Creación y aplicación de la POP de reautenticación. . . . . . . . . . . . . . . . . . . . . 135Configuración del restablecimiento y ampliación de la duración de la caché de sesión . . . . . . . . . 136

Configuración de la reautenticación basada en la política de inactividad de sesión . . . . . . . . . . . 137Condiciones que afectan a la reautenticación por inactividad . . . . . . . . . . . . . . . . . 137Habilitación de la reautenticación por inactividad . . . . . . . . . . . . . . . . . . . . . 139Configuración del restablecimiento y ampliación de la duración de la caché de sesión . . . . . . . . . 139

Capítulo 6. Soluciones de inicio de sesión en dominios cruzados . . . . . . . . . . 141Configuración de la autenticación de CDSSO . . . . . . . . . . . . . . . . . . . . . . . . 141

Integración de una biblioteca compartida CDMF personalizada. . . . . . . . . . . . . . . . . 141Flujo de proceso de autenticación para CDSSO con CDMF . . . . . . . . . . . . . . . . . . 141Habilitación e inhabilitación de la autenticación de CDSSO . . . . . . . . . . . . . . . . . . 143Configuración del mecanismo de autenticación de CDSSO . . . . . . . . . . . . . . . . . . 143Cifrado de los datos de la señal de autenticación . . . . . . . . . . . . . . . . . . . . . 144Configuración de la indicación de la hora de señal . . . . . . . . . . . . . . . . . . . . . 144Expresión de vínculos HTML de CDSSO . . . . . . . . . . . . . . . . . . . . . . . . 145Protección de la señal de autenticación . . . . . . . . . . . . . . . . . . . . . . . . . 145

Configuración de inicio de sesión único de comunidad electrónica . . . . . . . . . . . . . . . . 145Características y requisitos de comunidad electrónica . . . . . . . . . . . . . . . . . . . . 147Flujo de proceso de la comunidad electrónica . . . . . . . . . . . . . . . . . . . . . . 148Información de la cookie de comunidad electrónica . . . . . . . . . . . . . . . . . . . . 152Información sobre la petición y la respuesta de “garantización” . . . . . . . . . . . . . . . . 152Información sobre la señal de “garantización” . . . . . . . . . . . . . . . . . . . . . . 153Cifrado de la señal de “garantización” . . . . . . . . . . . . . . . . . . . . . . . . . 153Configuración de una comunidad electrónica. . . . . . . . . . . . . . . . . . . . . . . 154

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

Ubicación y formato de la base de datos de conexiones (junctions) . . . . . . . . . . . . . . . 159Aplicación del control de accesos flexible: resumen . . . . . . . . . . . . . . . . . . . . . 160Aplicación del control de accesos flexible: resumen . . . . . . . . . . . . . . . . . . . . . 160Directrices para la creación de conexiones (junctions) WebSEAL . . . . . . . . . . . . . . . . 160

vi IBM Tivoli Access Manager: WebSEAL Guía del administrador

Información de consulta adicional para conexiones (junctions) WebSEAL . . . . . . . . . . . . . 161Utilización de pdadmin para crear conexiones (junctions) . . . . . . . . . . . . . . . . . . . 161Configuración de una conexión (junction) WebSEAL básica . . . . . . . . . . . . . . . . . . . 162

Creación de conexiones (junctions) de tipo TCP . . . . . . . . . . . . . . . . . . . . . . 163Creación de conexiones (junctions) de tipo SSL . . . . . . . . . . . . . . . . . . . . . . 163Adición de servidores de fondo adicionales a una conexión (junction) . . . . . . . . . . . . . . 164

Conexiones (junctions) SSL autenticadas mutuamente . . . . . . . . . . . . . . . . . . . . . 165WebSEAL valida el certificado de servidor de fondo . . . . . . . . . . . . . . . . . . . . 165Coincidencia de Nombre distinguido (DN) . . . . . . . . . . . . . . . . . . . . . . . 165WebSEAL se autentica con un certificado de cliente . . . . . . . . . . . . . . . . . . . . 166WebSEAL se autentica con una cabecera de BA . . . . . . . . . . . . . . . . . . . . . . 166Gestión de información de identidad de cliente entre conexiones (junctions) . . . . . . . . . . . . 167

Creación de conexiones (junctions) de proxy TCP y SSL . . . . . . . . . . . . . . . . . . . . 168Conexiones (junctions) de WebSEAL a WebSEAL a través de SSL . . . . . . . . . . . . . . . . . 168Modificación de las direcciones URL de recursos de fondo . . . . . . . . . . . . . . . . . . . 169

Información sobre los tipos de ruta de acceso utilizados en las direcciones URL . . . . . . . . . . . 170Filtrado de las direcciones URL en las respuestas . . . . . . . . . . . . . . . . . . . . . 171Proceso de direcciones URL en las peticiones . . . . . . . . . . . . . . . . . . . . . . . 173

Opciones adicionales de conexión (junction) . . . . . . . . . . . . . . . . . . . . . . . . 176Cómo forzar una nueva conexión (junction) (–f) . . . . . . . . . . . . . . . . . . . . . . 176Especificación de la identidad del cliente en cabeceras HTTP (–c) . . . . . . . . . . . . . . . . 177Especificación de las direcciones IP de cliente en cabeceras HTTP (–r) . . . . . . . . . . . . . . 179Limitación del tamaño de cabeceras HTTP generadas por WebSEAL . . . . . . . . . . . . . . . 179Transferencia de cookies de sesión a servidores de portal con conexión (junction) (–k) . . . . . . . . . 180Soporte para direcciones URL no sensibles a mayúsculas y minúsculas (–i) . . . . . . . . . . . . . 180Soporte para conexión (junction) con información de estado (–s, –u) . . . . . . . . . . . . . . . 181Especificación de UUID de servidor de fondo para conexiones (junctions) con información de estado (–u) . . 182Conexión (junction) con sistemas de archivos de Windows (–w) . . . . . . . . . . . . . . . . 184

Notas técnicas para utilizar conexiones (junctions) WebSEAL . . . . . . . . . . . . . . . . . . 185Montaje de varios servidores en la misma conexión (junction) . . . . . . . . . . . . . . . . . 185Excepciones a la aplicación de permisos entre conexiones (junctions) . . . . . . . . . . . . . . . 186Certificación de autenticación entre conexiones (junctions) . . . . . . . . . . . . . . . . . . 186

Utilización de query_contents con servidores de terceros . . . . . . . . . . . . . . . . . . . . 186Instalación de los componentes de query_contents . . . . . . . . . . . . . . . . . . . . . 187Instalación de query_contents en servidores UNIX de terceros . . . . . . . . . . . . . . . . . 187Instalación de query_contents en servidores Win32 de terceros . . . . . . . . . . . . . . . . . 187Personalización de query_contents . . . . . . . . . . . . . . . . . . . . . . . . . . 189Protección de query_contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Capítulo 8. Soluciones de inicio de sesión único de web . . . . . . . . . . . . . 191Configuración de cabeceras de BA para las soluciones de inicio de sesión único . . . . . . . . . . . . 191

Conceptos de inicio de sesión único (SSO). . . . . . . . . . . . . . . . . . . . . . . . 191Especificación de la identidad de cliente en cabeceras de BA . . . . . . . . . . . . . . . . . 192Especificación de la identidad del cliente y la contraseña genérica . . . . . . . . . . . . . . . . 193Reenvío de la información de cabecera de BA del cliente original . . . . . . . . . . . . . . . . 194Eliminación de la información de cabecera de BA de cliente . . . . . . . . . . . . . . . . . . 195Especificación de los nombres de usuario y las contraseñas de GSO . . . . . . . . . . . . . . . 195

Utilización de Global Sign-on (GSO). . . . . . . . . . . . . . . . . . . . . . . . . . . 196Correlación de la información de autenticación . . . . . . . . . . . . . . . . . . . . . . 197Configuración de una conexión (junction) WebSEAL habilitada para GSO . . . . . . . . . . . . . 198Configuración de la caché de GSO . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Configuración del inicio de sesión único en IBM WebSphere (LTPA) . . . . . . . . . . . . . . . . 199Configuración de una conexión (junction) LTPA . . . . . . . . . . . . . . . . . . . . . . 200Configuración de la caché de LTPA . . . . . . . . . . . . . . . . . . . . . . . . . . 200Notas técnicas para el inicio de sesión único de LTPA . . . . . . . . . . . . . . . . . . . . 201

Configuración de la autenticación de formularios de inicio de sesión único . . . . . . . . . . . . . . 201Contexto y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201Flujo de proceso de inicio de sesión único con formularios . . . . . . . . . . . . . . . . . . 202Requisitos para el soporte de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . 203Creación del archivo de configuración para el inicio de sesión único con formularios . . . . . . . . . 204Habilitación del inicio de sesión único con formularios . . . . . . . . . . . . . . . . . . . 208

Contenido vii

Ejemplo de archivo de configuración para IBM HelpNow . . . . . . . . . . . . . . . . . . 208

Capítulo 9. Integración de aplicaciones . . . . . . . . . . . . . . . . . . . . . 211Soporte para la programación de CGI . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Windows: soporte para variables de entorno de WIN32 . . . . . . . . . . . . . . . . . . . 212Soporte para aplicaciones del servidor de fondo . . . . . . . . . . . . . . . . . . . . . . . 213Mejores prácticas de conexión (junction) para la integración de aplicaciones . . . . . . . . . . . . . 213

Información completa de cabecera HOST con -v . . . . . . . . . . . . . . . . . . . . . . 214Soporte para el filtrado de las direcciones URL absolutas estándar. . . . . . . . . . . . . . . . 214

Creación de un servicio de personalización personalizado . . . . . . . . . . . . . . . . . . . 215Configuración de WebSEAL para un servicio de personalización . . . . . . . . . . . . . . . . 216Ejemplo de servicio de personalización . . . . . . . . . . . . . . . . . . . . . . . . . 216

Habilitación de autorizaciones empresariales dinámicas (señal/valor) . . . . . . . . . . . . . . . 217Creación de autorizaciones empresariales a partir de datos LDAP . . . . . . . . . . . . . . . . 217

Mantenimiento del estado de la sesión entre las aplicaciones clientes y de fondo . . . . . . . . . . . . 220Información sobre la gestión de la sesión de usuario . . . . . . . . . . . . . . . . . . . . 220Habilitación de la gestión de ID de sesión de usuario . . . . . . . . . . . . . . . . . . . . 220Inserción de datos de credenciales en la cabecera HTTP . . . . . . . . . . . . . . . . . . . 221Terminación de sesiones de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Especificación del control de acceso a las direcciones URL dinámicas . . . . . . . . . . . . . . . . 223Componentes de dirección URL dinámica . . . . . . . . . . . . . . . . . . . . . . . . 223Correlación de objetos ACL y POP con direcciones URL dinámicas . . . . . . . . . . . . . . . 224Actualización de WebSEAL para direcciones URL dinámicas . . . . . . . . . . . . . . . . . 226Resolución de direcciones URL dinámicas en el espacio de objetos . . . . . . . . . . . . . . . 226Configuración de limitaciones en las peticiones POST . . . . . . . . . . . . . . . . . . . . 227Resumen y notas técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Ejemplo de dirección URL dinámica: Travel Kingdom . . . . . . . . . . . . . . . . . . . . . 229La aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229La interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230La política de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Clientes seguros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Control de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Apéndice A. Consulta de webseald.conf . . . . . . . . . . . . . . . . . . . . . 233

Apéndice B. Información de consulta de las conexiones (junctions) WebSEAL . . . . 247Utilización de pdadmin para crear conexiones (junctions) . . . . . . . . . . . . . . . . . . . 247Comandos de conexión (junction) . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Creación de una nueva conexión (junction) para un servidor inicial . . . . . . . . . . . . . . . . 249Adición de un servidor adicional a una conexión (junction) existente . . . . . . . . . . . . . . . . 251

Apéndice C. Avisos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Marcas registradas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

viii IBM Tivoli Access Manager: WebSEAL Guía del administrador

Prefacio

Bienvenido a la publicación IBM®Tivoli®Access Manager WebSEAL Guía deladministrador.

IBM Tivoli Access Manager WebSEAL es el gestor de seguridad de recursos paralos recursos basados en web. WebSEAL es un servidor web de alto rendimiento yde threads múltiples que aplica una política de seguridad detallada al espacio deobjetos web protegidos. WebSEAL puede proporcionar soluciones de inicio desesión único e incorporar recursos de servidores de aplicaciones web de fondo a supolítica de seguridad.

Esta guía de administración ofrece un conjunto exhaustivo de procedimientos einformación de consulta para la gestión de los recursos de los dominios webseguros. También incluye información general y de conceptos útil para la granvariedad de funciones de WebSEAL.

A quién va dirigido este manualEste manual va dirigido a los administradores de sistemas que son responsables deconfigurar y mantener un entorno de Access Manager WebSEAL.

Los lectores deben estar familiarizados con los elementos siguientes:v Sistemas operativos de PC y UNIX®

v Arquitectura y conceptos de bases de datosv Gestión de seguridadv Protocolos Internet, incluidos HTTP, TCP/IP, FTP (File Transfer Protocol) y

Telnetv Servicios LDAP (Lightweight Directory Access Protocol) y de directoriov Un registro de usuarios soportadov Autenticación y autorización

Si habilita la comunicación SSL (Secure Sockets Layer), también debe estarfamiliarizado con el protocolo SSL, intercambio de claves (públicas y privadas),firmas digitales, algoritmos criptográficos y entidades emisoras de certificados.

Contenido de este manualv Capítulo 1: Visión general de IBM Tivoli Access Manager WebSEAL

Este capítulo le presenta conceptos y funciones importantes de WebSEAL, comopor ejemplo: organización y protección del espacio de objetos, autenticación,adquisición de credenciales y conexiones (junctions) WebSEAL.

v Capítulo 2: Configuración básica del servidor

Este capítulo contiene información técnica de consulta para las tareas generalesde configuración de WebSEAL, que incluyen: utilización del archivo deconfiguración de WebSEAL, gestión del espacio web, gestión de certificados yconfiguración del registro.

v Capítulo 3: Configuración avanzada del servidor

Este capítulo contiene información técnica de consulta para las tareas avanzadasde configuración de WebSEAL, que incluyen: configuración de múltiples

© Copyright IBM Corp. 1999, 2002 ix

instancias de WebSEAL, configuración de funciones de cambio de usuario,gestión de la asignación de threads de trabajo y configuración de actualizacionesy sondeos de base de datos de autorizaciones.

v Capítulo 4: Política de seguridad de WebSEAL

Este capítulo describe procedimientos técnicos detallados para personalizar lapolítica de seguridad de WebSEAL, que incluyen: políticas de ACL y POP,calidad de protección, política de autenticación incremental, política deautenticación basada en la red, política de inicio de sesión de tres intentos ypolítica de intensidad de contraseñas.

v Capítulo 5: Autenticación de WebSEAL

Este capítulo proporciona procedimientos técnicos detallados para configurarWebSEAL para que gestione varios métodos de autenticación, que incluyen:nombre de usuario y contraseña, certificados de cliente, código de paso de señalde SecurID, datos de cabecera HTTP especiales y funciones de reautenticación.

v Capítulo 6: Soluciones de inicio de sesión en dominios cruzados

En este capítulo se describen soluciones de inicio de sesión en dominioscruzados para el componente externo de la configuración proxy deWebSEAL—entre el cliente y el servidor WebSEAL.

v Capítulo 7: Conexiones (junctions) WebSEAL

Este capítulo contiene información técnica de consulta completa para configurary utilizar las conexiones (junctions) WebSEAL.

v Capítulo 8: Soluciones de inicio de sesión único de web

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

v Capítulo 9: Integración de aplicaciones

Este capítulo explora diversas posibilidades de WebSEAL para integrar lafuncionalidad de aplicaciones de terceros.

v Apéndice A: Información de consulta de webseald.conf

v Apéndice B: Información de consulta de las conexiones (junctions) WebSEAL

PublicacionesEste apartado contiene una lista de publicaciones de la biblioteca de AccessManager y otros documentos relacionados. También describe cómo acceder a laspublicaciones de Tivoli en línea, cómo solicitar publicaciones de Tivoli y cómorealizar comentarios sobre las publicaciones de Tivoli.

IBM Tivoli Access ManagerLa biblioteca de Access Manager está organizada en las siguientes categorías:v Información del releasev Información de Basev Información de WebSEALv Información de seguridad webv Información de consulta para desarrolladoresv Información técnica complementaria

Las publicaciones de la biblioteca del producto están incluidas en formato PDF(Portable Document Format) en el CD del producto. Para acceder a estas

x IBM Tivoli Access Manager: WebSEAL Guía del administrador

publicaciones utilizando un navegador web, abra el archivo infocenter.html, quese encuentra en el directorio /doc del CD del producto.

Para obtener fuentes de información adicionales sobre Access Manager y temasrelacionados, visite los siguientes sitios web:

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

Información del releasev IBM Tivoli Access Manager for e-business Read Me First

GI11-0918 (am39_readme.pdf)Proporciona información sobre la instalación e iniciación al uso de AccessManager.

v IBM Tivoli Access Manager for e-business Release Notes

GI11-0919 (am39_relnotes.pdf)Proporciona información de última hora, como limitaciones de software,soluciones temporales y actualizaciones de la documentación.

Información de Basev IBM Tivoli Access Manager Base Installation Guide

GC32-0844 (am39_install.pdf)Describe cómo instalar, configurar y actualizar el software Access Manager,incluida la interfaz Web Portal Manager.

v IBM Tivoli Access Manager Base Guía del administrador

GC10-3838 (am39_admin.pdf)Describe los conceptos y procedimientos para la utilización de los servicios deAccess Manager. Proporciona instrucciones para realizar tareas desde la interfazWeb Portal Manager y mediante el comando pdadmin.

v IBM Tivoli Access Manager Base for Linux on zSeries™ Installation Guide

GC23-4796 (am39_zinstall.pdf)Describe cómo instalar y configurar Access Manager Base para Linux en laplataforma zSeries.

Información de WebSEALv IBM Tivoli Access Manager WebSEAL Installation Guide

GC32-0848 (amweb39_install.pdf)Proporciona instrucciones de instalación, configuración y eliminación delservidor WebSEAL y del kit de desarrollo de aplicaciones WebSEAL.

v IBM Tivoli Access Manager WebSEAL Guía del administrador

GC10-3839 (amweb39_admin.pdf)Proporciona material de consulta, procedimientos de administración einformación técnica de consulta sobre la utilización de WebSEAL para gestionarlos recursos de su dominio web seguro.

v IBM Tivoli Access Manager WebSEAL Developer’s Reference

GC23-4683 (amweb39_devref.pdf)Proporciona información de administración y programación para CDAS(Cross-domain Authentication Service), CDMF (Cross-domain MappingFramework) y para el Módulo de intensidad de contraseñas.

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

Prefacio xi

GC23-4797 (amweb39_zinstall.pdf)Proporciona instrucciones de instalación, configuración y eliminación delservidor WebSEAL y del kit de desarrollo de aplicaciones WebSEAL para Linuxen la plataforma zSeries.

Información de seguridad webv IBM Tivoli Access Manager for WebSphere Application Server Guía del usuario

GC10-3840 (amwas39_user.pdf)Proporciona instrucciones de instalación, eliminación y administración de AccessManager for IBM WebSphere® Application Server.

v IBM Tivoli Access Manager for WebLogic Server User’s Guide

GC32-0851 (amwls39_user.pdf)Proporciona instrucciones de instalación, eliminación y administración de AccessManager for BEA WebLogic Server.

v IBM Tivoli Access Manager Plug-in for Edge Server User’s Guide

GC23-4685 (amedge39_user.pdf)Describe cómo instalar, configurar y administrar Plug-in for IBM WebSphereEdge Server.

v IBM Tivoli Access Manager Plug-in for Web Servers User’s Guide

GC23-4686 (amws39_user.pdf)Proporciona instrucciones de instalación, procedimientos de administración einformación técnica de consulta para proteger su dominio web utilizando laaplicación Plug-in for Web Servers.

Material de consulta para desarrolladoresv IBM Tivoli Access Manager Authorization C API Developer’s Reference

GC32-0849 (am39_authC_devref.pdf)Proporciona material de consulta que describe cómo utilizar la API C deautorización de Access Manager y la interfaz de plug-in de servicio de AccessManager para agregar la seguridad de Access Manager a aplicaciones.

v IBM Tivoli Access Manager Authorization Java Classes Developer’s Reference

GC23-4688 (am39_authJ_devref.pdf)Proporciona información de consulta sobre la utilización de la implementaciónen lenguaje Java™ de la API de autorización para permitir que una aplicaciónutilice la seguridad de Access Manager.

v IBM Tivoli Access Manager Administration C API Developer’s Reference

GC32-0843 (am39_adminC_devref.pdf)Proporciona información de consulta sobre la utilización de la API deadministración para permitir que una aplicación pueda realizar tareas deadministración de Access Manager. Este documento describe la implementaciónde C de la API de administración.

v IBM Tivoli Access Manager Administration Java Classes Developer’s Reference

SC32-0842 (am39_adminJ_devref.pdf)Proporciona información de consulta sobre la utilización de la implementaciónen lenguaje Java de la API de administración para permitir que una aplicaciónpueda realizar tareas de administración de Access Manager.

v IBM Tivoli Access Manager WebSEAL Developer’s Reference

GC23-4683 (amweb39_devref.pdf)

xii IBM Tivoli Access Manager: WebSEAL Guía del administrador

Proporciona información de administración y programación para CDAS(Cross-domain Authentication Service), CDMF (Cross-domain MappingFramework) y para el Módulo de intensidad de contraseñas.

Información técnica complementariav IBM Tivoli Access Manager Performance Tuning Guide

GC43-0846 (am39_perftune.pdf)Proporciona información de ajuste del rendimiento para un entorno compuestopor Access Manager con IBM SecureWay Directory definido como el registro deusuarios.

v IBM Tivoli Access Manager Capacity Planning Guide

GC32-0847 (am39_capplan.pdf)Proporciona asistencia a los responsables de planificación para determinar elnúmero de servidores web de fondo, WebSEAL y LDAP necesarios paraconseguir la carga de trabajo deseada.

v IBM Tivoli Access Manager Error Message Reference

SC32-0845 (am39_error_ref.pdf)Proporciona explicaciones y acciones recomendadas para los mensajes generadospor Access Manager.

La publicación Tivoli Glossary incluye definiciones de muchos de los términostécnicos relacionados con el software de Tivoli. La publicación Tivoli Glossary estádisponible, sólo en inglés, en el siguiente sitio web:

http://www.tivoli.com/support/documents/glossary/termsm03.htm

Publicaciones relacionadasEste apartado contiene una lista de las publicaciones relacionadas con la bibliotecade Access Manager.

IBM DB2® Universal Database ™

IBM DB2 Universal Database es necesario al instalar los servidores IBM SecureWayDirectory, z/OS™ y OS/390® SecureWay LDAP. La información de DB2 estádisponible en el siguiente sitio web:

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

IBM Global Security ToolkitAccess Manager proporciona cifrado de datos mediante el uso de IBM GlobalSecurity Toolkit (GSKit). GSKit se proporciona en el CD de IBM Tivoli AccessManager Base para su plataforma específica.

El paquete GSKit instala el programa de utilidad de gestión de claves iKeyman(gsk5ikm), que permite crear bases de datos de claves, pares de claves pública yprivada y peticiones de certificado. El siguiente documento está disponible en eldirectorio /doc/GSKit:v Secure Sockets Layer Introduction and iKeyman User’s Guide

gskikm5c.pdf

Proporciona información para administradores de red o administradores deseguridad de sistemas que tienen planificado habilitar la comunicación SSL en eldominio seguro de Access Manager.

Prefacio xiii

IBM SecureWay DirectoryIBM SecureWay Directory, Versión 3.2.2, se incluye en el CD de IBM Tivoli AccessManager Base para su plataforma específica. Si está planificando instalar elservidor IBM SecureWay Directory como su registro de usuarios, los siguientesdocumentos están disponibles en la ruta de acceso /doc/Directory del CD de IBMTivoli Access Manager Base para su plataforma específica:v IBM SecureWay Directory Installation and Configuration Guide

(aparent.pdf, lparent.pdf, sparent.pdf, wparent.pdf)Proporciona información de instalación, configuración y migración para loscomponentes de IBM SecureWay Directory en los sistemas operativos AIX®,Linux, Solaris y Microsoft® Windows®.

v IBM SecureWay Directory Release Notes

(relnote.pdf)Contiene información complementaria a la documentación del producto IBMSecureWay Directory, Versión 3.2.2, y describe las características y funciones queestán disponibles en este release.

v IBM SecureWay Directory Readme Addendum

(addendum322.pdf)Proporciona información sobre los cambios y arreglos realizados después de latraducción de la documentación de IBM SecureWay Directory. Este archivo estádisponible sólo en inglés.

v IBM SecureWay Directory Server Readme

(server.pdf)Proporciona una descripción de IBM SecureWay Directory Server, Versión 3.2.2.

v IBM SecureWay Directory Client Readme

(client.pdf)Proporciona una descripción de IBM SecureWay Directory Client SDK, Versión3.2.2. Este kit de desarrollo de software (SDK) proporciona soporte para eldesarrollo de aplicaciones LDAP.

v SSL Introduction and iKeyman User’s Guide

(gskikm5c.pdf)Proporciona información para administradores de red o administradores deseguridad de sistemas que tienen planificado habilitar la comunicación SSL en eldominio seguro de Access Manager.

v IBM SecureWay Directory Configuration Schema

(scparent.pdf)Describe el árbol de información de directorios (DIT) y los atributos utilizadospara configurar el archivo slapd32.conf. En IBM SecureWay Directory Versión3.2, los valores de directorio se almacenan utilizando el formato LDIF (LDAPDirectory Interchange Format) en el archivo slapd32.conf.

v IBM SecureWay Directory Tuning Guide

(tuning.pdf)Proporciona información de ajuste del rendimiento para IBM SecureWayDirectory. Incluye consideraciones sobre los ajustes del tamaño de los directoriosque tienen desde varios miles de entradas hasta millones de entradas, cuandoprocede.

Para obtener más información sobre IBM SecureWay Directory, visite el siguientesitio web:

xiv IBM Tivoli Access Manager: WebSEAL Guía del administrador

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

IBM WebSphere Application ServerIBM WebSphere Application Server, Advanced Single Server Edition, Versión 4.0.2,se instala con la interfaz Web Portal Manager. Para obtener información sobre IBMWebSphere Application Server, visite el siguiente sitio web:

http://www.ibm.com/software/webservers/appserv/infocenter.html

Acceso a las publicaciones en líneaLas publicaciones de la biblioteca del producto están incluidas en formato PDF(Portable Document Format) en el CD del producto. Para acceder a estaspublicaciones utilizando un navegador web, abra el archivo infocenter.html, quese encuentra en el directorio /doc del CD del producto.

Cuando IBM publica una versión actualizada de una o más publicaciones impresaso en línea, se envían a Tivoli Information Center. Tivoli Information Centercontiene las versiones más recientes de las publicaciones de la biblioteca delproducto en formato PDF o HTML, o en ambos. También están disponiblesdocumentos traducidos de algunos productos.

Puede acceder a Tivoli Information Center y a otras fuentes de información técnicadesde el siguiente sitio web:

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

La información está organizada por producto e incluye las notas del release, guíasde instalación, guías del usuario, guías del administrador y material de consultapara desarrolladores.

Nota: Si desea imprimir documentos PDF en un papel que no sea de tamaño carta,seleccione la casilla de verificación Ajustar a página en el diálogo deimpresión de Adobe Acrobat (que está disponible al hacer clic en Archivo →Imprimir) para asegurarse de que se imprima todo el contenido de lapágina en tamaño carta en el papel que esté utilizando.

Solicitud de publicacionesPuede realizar pedidos de muchas publicaciones de Tivoli en línea en el siguientesitio web:

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi

También puede realizar pedidos por teléfono llamando a uno de estos números:v En Estados Unidos: 800-879-2755v En España: 901-100-000v Para obtener una lista de números de teléfono de otros países, visite el siguiente

sitio web:http://www.tivoli.com/inside/store/lit_order.html

Comentarios sobre las publicacionesNos interesa conocer sus experiencias con los productos y la documentación deTivoli, y agradeceremos cualquier sugerencia para aplicar mejoras. Si tiene

Prefacio xv

comentarios o sugerencias sobre nuestros productos y la documentación, póngaseen contacto con nosotros utilizando uno de los procedimientos siguientes:v Envíe un mensaje de correo electrónico a [email protected] Rellene la encuesta de opinión del cliente en el siguiente sitio web:

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

AccesibilidadLas características de accesibilidad ayudan a los usuarios que tienen unadiscapacidad física, como movilidad restringida o visión limitada, a utilizar losproductos de software sin problemas. En este producto, puede utilizar tecnologíasde asistencia para tener acceso a la interfaz y navegar por ella. También puedeutilizar el teclado en lugar del ratón para realizar todas las funciones de la interfazgráfica de usuario.

Cómo ponerse en contacto con el soporte al clienteSi tiene algún problema con cualquier producto de Tivoli, puede ponerse encontacto con el soporte al cliente de Tivoli. Consulte el manual Tivoli CustomerSupport Handbook en el siguiente sitio web:

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

En el manual se proporciona información sobre cómo ponerse en contacto con elsoporte al cliente de Tivoli, según la gravedad del problema, y la siguienteinformación:v Registro y elegibilidadv Números de teléfono y direcciones de correo electrónico, según el país donde se

encuentrev Qué información debe reunir antes de ponerse en contacto con el servicio de

soporte

Convenios utilizados en este manualEsta guía utiliza varias convenios para algunos términos y acciones especiales,comandos y rutas de acceso del sistema operativo, y gráficos de margen.

Convenios tipográficosEn este manual se utilizan los siguientes convenios tipográficos:

Negrita Los nombres de comandos y opciones, las palabras clave y otrainformación que debe utilizarse literalmente aparecen en negrita.

Cursiva Las variables, opciones de comandos y valores que el usuario debeproporcionar aparecen en cursiva. Los títulos de publicaciones y laspalabras o expresiones especiales que están enfatizadas tambiénaparecen en cursiva.

Monoespaciado Los ejemplos de código, las líneas de comandos, la salida enpantalla, los nombres de archivo y de directorio, y los mensajes delsistema aparecen en una fuente monoespaciada.

xvi IBM Tivoli Access Manager: WebSEAL Guía del administrador

Capítulo 1. Visión general de IBM Tivoli Access ManagerWebSEAL

IBM®Tivoli®Access Manager for e-business (Access Manager) es una solución degestión centralizada de políticas sólida y segura para e-business y aplicacionesdistribuidas. IBM Tivoli Access Manager WebSEAL es un servidor web de altorendimiento y de threads múltiples que aplica una política de seguridad detalladaal espacio de objetos web protegidos de Access Manager. WebSEAL puedeproporcionar soluciones de inicio de sesión único e incorporar recursos deservidores de aplicaciones web de fondo a su política de seguridad.

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

Índice de temas:v “Presentación de IBM Tivoli Access Manager y WebSEAL” en la página 1v “Información sobre el modelo de seguridad de Access Manager” en la página 3v “Protección del espacio web con WebSEAL” en la página 7v “Planificación e implementación de la política de seguridad” en la página 8v “Información sobre la autenticación de WebSEAL” en la página 10v “Información sobre las conexiones (junctions) WebSEAL” en la página 14

Presentación de IBM Tivoli Access Manager y WebSEALIBM Tivoli Access Manager:

IBM Tivoli Access Manager es una solución completa de gestión de políticas deautorización y seguridad de red que proporciona una protección máxima deextremo a extremo de los recursos a través de intranets y extranetsgeográficamente dispersas.

Además de sus avanzadas características de gestión de políticas de seguridad,Access Manager proporciona posibilidades de autenticación, autorización,seguridad de datos y gestión centralizada de los recursos. Puede utilizar AccessManager junto con aplicaciones estándar basadas en Internet para construirintranets de alta seguridad y bien gestionadas.

En su núcleo, Access Manager proporciona:v Infraestructura de autenticación

Access Manager proporciona una amplia gama de autenticadores incorporados yda soporte a autenticadores externos.

v Infraestructura de autorizaciónEl servicio de autorizaciones de Access Manager, al que se accede a través de laAPI de autorización de Access Manager, proporciona decisiones de permiso ydenegación en las peticiones de recursos protegidos ubicados en el dominioseguro.

Con Access Manager, las empresas pueden gestionar de forma segura el acceso alos recursos internos privados basados en red, al tiempo que se aprovecha laamplia conectividad y la facilidad de uso de Internet. Access Manager, en

© Copyright IBM Corp. 1999, 2002 1

combinación con un sistema de cortafuegos corporativo, puede proporcionar unaprotección completa de la intranet empresarial contra accesos no autorizados eintrusiones.

IBM Tivoli Access Manager WebSEAL:

IBM Tivoli Access Manager WebSEAL es el gestor de recursos que es responsablede gestionar y proteger información y recursos basados en web.

WebSEAL es un servidor web de alto rendimiento y threads múltiples que aplicauna política de seguridad detallada al espacio de objetos web protegidos de AccessManager. WebSEAL puede proporcionar soluciones de inicio de sesión único eincorporar recursos de servidores de aplicaciones web de fondo a su política deseguridad.

WebSEAL actúa normalmente como un proxy web inverso al recibir peticionesHTTP/HTTPS de un navegador web y proporcionar contenido de su propioservidor web o de servidores de aplicaciones web de fondo con conexión(junction). Las peticiones que pasan a través de WebSEAL se evalúan mediante elservicio de autorizaciones de Access Manager para determinar si el usuario estáautorizado para acceder al recurso solicitado.

WebSEAL proporciona las siguientes funciones:v Da soporte a varios métodos de autenticación

Tanto la arquitectura incorporada como la de plug-in permiten la flexibilidad aldar soporte a varios mecanismos de autenticación.

v Acepta peticiones HTTP y HTTPSv Integra y protege los recursos de servidor de fondo a través de la tecnología de

conexiones (junctions) WebSEALv Gestiona un control de acceso estricto para el espacio web del servidor local y

de fondoLos recursos soportados incluyen direcciones URL, expresiones regularesbasadas en direcciones URL, programas CGI, archivos HTML, servlets Java yarchivos de clase Java.

v Funciona como proxy web inversoWebSEAL aparece como un servidor web en los clientes y como un navegadorweb en los servidores de fondo con conexión (junction) que protege.

v Proporciona posibilidades de inicio de sesión único

2 IBM Tivoli Access Manager: WebSEAL Guía del administrador

Información sobre el modelo de seguridad de Access ManagerLa política de seguridad para un dominio seguro de Access Manager se mantiene yrige mediante dos estructuras de seguridad clave:v Registro de usuarios

El registro de usuarios (tal como LDAP, Lotus Domino o Microsoft ActiveDirectory) contiene todos los usuarios y grupos que tienen permiso paraparticipar en el dominio seguro de Access Manager.

v Base de datos maestra de (política de) autorizaciones

La base de datos de autorizaciones contiene una representación de todos losrecursos del dominio (el espacio de objetos protegidos). El administrador deseguridad puede establecer cualquier nivel de seguridad aplicando reglas,conocidas como políticas de lista de control de accesos (ACL) y políticas deobjetos protegidos (POP) a aquellos recursos que necesiten protección.

La identidad de un usuario se demuestra en WebSEAL mediante el proceso deautenticación. Un usuario puede participar en el dominio seguro como autenticadoo no autenticado. Sólo los usuarios con una entrada en el registro de usuariospueden convertirse en usuarios autenticados. Utilizando las políticas de ACL yPOP, el administrador de seguridad puede establecer como disponibles ciertosrecursos públicos para usuarios no autenticados. Otros recursos pueden quedardisponibles únicamente para determinados usuarios autenticados.

Cuando un usuario se autentica correctamente en WebSEAL, se crea una credencialpara ese usuario. La credencial contiene la identidad del usuario, las pertenencias agrupos y cualquier atributo de seguridad especial (“ampliado”).

El servicio de autorizaciones de Access Manager aplica políticas de seguridadcomparando las credenciales de autenticación de un usuario con los permisos depolíticas asignados al recurso solicitado. La recomendación resultante se pasa algestor de recursos (por ejemplo, WebSEAL), que completa la respuesta a la peticiónoriginal. La credencial de usuario es esencial para la plena participación en eldominio seguro.

Figura 1. Protección del espacio web con WebSEAL

Capítulo 1. Visión general de IBM Tivoli Access Manager WebSEAL 3

Espacio de objetos protegidosEl espacio de objetos protegidos es una representación jerárquica de los recursosque pertenecen a un dominio seguro de Access Manager. Los objetos virtuales queaparecen en el espacio de objetos jerárquico representan los recursos reales de lared física.v Recurso del sistema – la aplicación o el archivo físico real.v Objeto protegido – la representación lógica de un recurso del sistema real

utilizado por el servicio de autorizaciones, Web Portal Manager y otrosprogramas de utilidad de gestión de Access Manager.

Pueden asociarse plantillas de política con objetos en el espacio de objetos paraproporcionar protección al recurso. El servicio de autorizaciones toma lasdecisiones sobre la autorización de acuerdo con estas plantillas.

Access Manager utiliza las siguientes categorías de espacio de objetos:v Objetos web

Estos objetos representan cualquier elemento que pueda direccionarse con unadirección URL HTTP. Incluye páginas web estáticas y direcciones URL dinámicasque se convierten en consultas de base de datos u otro tipo de aplicación. Elservidor WebSEAL es responsable de proteger los objetos web.

v Objetos de gestión de Access Manager

Estos objetos representan las actividades de gestión que se pueden realizar através de Web Portal Manager. Los objetos representan las tareas necesarias paradefinir los usuarios y establecer la política de seguridad. Access Manager dasoporte a la delegación de las actividades de gestión y puede restringir lacapacidad de un administrador para establecer una política de seguridad en unsubconjunto del espacio de objetos.

v Objetos definidos por el usuario

Estos objetos representan tareas definidas por el usuario o recursos de redprotegidos por aplicaciones utilizando el servicio de autorizaciones a través de laAPI de autorización de Access Manager.

Definición y aplicación de políticas de ACL y POPLos administradores de seguridad protegen los recursos del sistema de AccessManager definiendo reglas, que se conocen como políticas de ACL y POP, yaplicando estas políticas a las representaciones de objetos de dichos recursos en elespacio de objetos protegidos.

Figura 2. Espacio de objetos protegidos de Access Manager


El servicio de autorizaciones de Access Manager toma decisiones de autorizaciónbasadas en las políticas aplicadas a estos objetos. Cuando se permite una operaciónsolicitada en un objeto protegido, la aplicación responsable del recurso implementaesta operación.

Una política puede establecer los parámetros de protección de muchos objetos.Cualquier cambio en la regla afectará a todos los objetos con los que se haasociado la plantilla.

La lista de control de accesos (ACL)Una política de lista de control de accesos, o política de ACL, es el conjunto dereglas (permisos) que especifica las condiciones necesarias para realizardeterminadas operaciones en ese recurso. Las definiciones de política de ACL soncomponentes importantes de la política de seguridad establecida para el dominioseguro. Las políticas de ACL, como todas las políticas, se utilizan para indicar losrequisitos de seguridad de una organización en los recursos representados en elespacio de objetos protegidos.

Una política de ACL controla, de forma específica:1. Qué operaciones se pueden realizar en el recurso2. Quién puede realizar estas operaciones

Una política de ACL se compone de una o más entradas que incluyendesignaciones de usuario y de grupo y sus permisos o derechos específicos. UnaACL también puede contener reglas que se apliquen a usuarios no autenticados.

Políticas de objetos protegidos (POP)Las políticas de ACL proporcionan el servicio de autorizaciones con informaciónpara responder “sí” o “no” en una petición de acceso a un objeto protegido yrealizar algunas operaciones en dicho objeto.

Las políticas POP contienen condiciones adicionales sobre la petición que se pasande vuelta a Access Manager Base y al gestor de recursos (como WebSEAL) juntocon la decisión “sí” de política de ACL del servicio de autorizaciones. Esresponsabilidad de Access Manager y del gestor de recursos aplicar las condicionesde la política POP.

Figura 3. Política de ACL


Las tablas siguientes listan los atributos disponibles para una política POP:

Aplicado por Access Manager Base

Atributo POP Descripción

Nombre Nombre de la política. Se convierte en <nombre-pop> enlos comandos pdadmin pop.

Descripción Texto descriptivo de la política. Aparece en el comandopop show.

Modalidad de aviso Proporciona a los administradores un medio para probarlas políticas de ACL y POP.

Nivel de auditoría Especifica el tipo de auditoría: toda, ninguna, accesocorrecto, acceso denegado, errores.

Acceso según hora del día Restricciones de día y hora para acceder correctamente alobjeto protegido.

Aplicado por el Gestor de recursos (como WebSEAL)

Atributo POP Descripción

Calidad de protección Especifica el grado de la protección de datos: ninguna,integridad y privacidad.

Política de métodos deautenticación de punto final IP

Especifica los requisitos de autenticación para el accesode los miembros de redes externas.

Políticas explícitas y heredadasLa política se puede aplicar de forma explícita o puede heredarse. El espacio deobjetos protegidos de Access Manager da soporte a la herencia de los atributos delas políticas de ACL y POP. Es una cuestión importante para el administrador deseguridad que gestiona el espacio de objetos. El administrador sólo tiene queaplicar políticas explícitas en los puntos de la jerarquía en que deban modificarselas reglas.

Administración de política: Web Portal ManagerWeb Portal Manager es una aplicación gráfica basada en web que se utiliza paragestionar la política de seguridad en un dominio seguro de Access Manager. Elprograma de utilidad de línea de comandos pdadmin proporciona las mismasposibilidades de administración que Web Portal Manager, además de algunoscomandos no soportados por Web Portal Manager.

Figura 4. Políticas explícitas y heredadas


Desde Web Portal Manager (o pdadmin) se puede gestionar el registro de usuarios,la base de datos maestra de política de autorizaciones y los servidores de AccessManager. También puede agregar y suprimir usuarios/grupos y aplicar políticas deACL y POP a los objetos de red.

Protección del espacio web con WebSEALCuando WebSEAL aplica la seguridad en un dominio seguro, cada cliente debeproporcionar pruebas de su identidad. A su vez, la política de seguridad de AccessManager determina si se permite a ese cliente que realice una operación en unrecurso solicitado. Dado que el acceso a cada recurso web en un dominio seguroestá controlado por WebSEAL, las exigencias de autenticación y autorización deWebSEAL pueden proporcionar una seguridad de red exhaustiva.

En los sistemas de seguridad, la autorización es distinta de la autenticación. Laautorización determina si un cliente autenticado tiene derecho a realizar unaoperación en un recurso específico de un dominio seguro. La autenticación puedevalidar la identidad de un cliente, pero no indica nada sobre el derecho del clientea realizar operaciones en un recurso protegido.

En el modelo de autorización de Access Manager, la política de autorizaciones seimplementa independientemente del mecanismo que se utilice para laautenticación de usuarios. Los usuarios pueden autenticar su identidad utilizandomecanismos de clave pública/privada, de clave secreta o definidos por el cliente.

Una parte del proceso de autenticación implica la creación de una credencial quedescriba la identidad del cliente. Las decisiones sobre autorizaciones realizadas porun servicio de autorizaciones se basan en las credenciales de usuario.

Los recursos de un dominio seguro reciben un nivel de protección de acuerdo conlo que dicte la política de seguridad para el dominio. La política de seguridaddefine los participantes legítimos del dominio seguro y el grado de protección querodea a cada recurso que requiere protección.

El proceso de autorización consta de los siguientes componentes básicos:v Un gestor de recursos es responsable de implementar la operación solicitada

cuando se otorga la autorización. WebSEAL es un gestor de recursos.Un componente del gestor de recursos es un aplicador de políticas que dirige lapetición al servicio de autorizaciones para su proceso.

Nota: Las aplicaciones tradicionales agrupan el aplicador de políticas y el gestorde recursos en un solo proceso. Son ejemplos de esta estructura WebSEALy aplicaciones de terceros.

v Un servicio de autorizaciones realiza en la petición la acción de toma dedecisiones.

El diagrama siguiente muestra el proceso completo de autorización:


1. Una petición de cliente autenticada para un recurso se dirige al gestor derecursos y la intercepta el proceso de aplicador de políticas.El gestor de recursos puede ser WebSEAL (para acceso HTTP, HTTPS) o unaaplicación de terceros.

2. El proceso de aplicador de políticas utiliza la API de autorización de AccessManager para llamar al servicio de autorizaciones y solicitar una decisión deautorización.

3. El servicio de autorizaciones realiza una comprobación de autorización en elrecurso, representado como un objeto en el espacio de objetos protegidos. Enprimer lugar se comprueban las políticas POP de base. A continuación, lapolítica de ACL asociada con el objeto se comprueba con las credenciales delcliente. Luego se comprueban las políticas POP aplicadas por el gestor derecursos.

4. La decisión de aceptar o denegar la petición se devuelve como recomendaciónal gestor de recursos (a través del aplicador de políticas).

5. Si finalmente se aprueba la petición, el gestor de recursos pasa la petición a laaplicación responsable del recurso.

6. El cliente recibe los resultados de la operación solicitada.

Planificación e implementación de la política de seguridadUna política de seguridad de empresa identifica:1. Los recursos web que requieren protección2. El nivel de protección

Access Manager utiliza una representación virtual de estos recursos web,denominada espacio de objetos protegidos. Este espacio contiene objetos querepresentan los recursos físicos reales de la red.

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

Los mecanismos de seguridad son:

Figura 5. Proceso de autorización de Access Manager


v Políticas de lista de control de accesos (ACL)Las políticas de ACL identifican los tipos de usuario que se pueden considerarpara el acceso y especifican las operaciones permitidas en el objeto.

v Políticas de objetos protegidos (POP)Una POP especifica las condiciones adicionales que gobiernan el acceso al objetoprotegido, como la privacidad, la integridad, la auditoría y el acceso según lahora del día.

v Atributos ampliadosLos atributos ampliados son valores adicionales colocados en un objeto, ACL oPOP que otras aplicaciones de terceros pueden leer e interpretar (como unservicio de autorizaciones externo).

El componente esencial de Access Manager es el servicio de autorizaciones deAccess Manager, que permite o deniega el acceso a los objetos protegidos(recursos) según las credenciales del usuario y los controles de acceso que se hanpuesto en los objetos.

Para implementar correctamente la política de seguridad, debe organizarlógicamente los distintos tipos de contenido (tal como se describe en el apartado“Identificación de tipos de contenido y niveles de protección” en la página 9 yaplicar las políticas de ACL y POP apropiadas. La gestión del control de accesopuede ser muy compleja y se lleva a cabo mucho más fácilmente mediante lameticulosa categorización de los tipos de contenido.

Identificación de tipos de contenido y niveles de protecciónComo administrador de seguridad del espacio web, debe identificar correctamentelos tipos de contenido disponibles para una variedad de tipos de usuario. Se debeproteger en gran manera una parte del contenido y ponerlo sólo a disposición deusuarios específicos; otra parte del contenido es para el público general. Cada casode seguridad exige unos requisitos de protección distintos y la configuración deWebSEAL asociada.

Es responsabilidad del usuario:v Conocer el contenido webv Identificar los tipos de usuario que requieren el acceso a ese contenidov Comprender las ventajas y los inconvenientes de las opciones disponibles de

configuración de WebSEAL para proteger este contenido

La protección del contenido web se divide en tres amplias categorías:1. Contenido público: el acceso no requiere ninguna protecciónv Acceso de clientes no autenticados a través de HTTPv Credencial no autenticada utilizada para el control de acceso a los recursosv Requisitos de configuración básica de WebSEAL

2. Contenido público: el acceso requiere privacidad (cifrado)v Acceso de clientes no autenticados a través de HTTPSv Cifrado necesario para proteger datos confidenciales requeridos por el

servidor de aplicaciones (como números de tarjeta de crédito e informaciónde cuentas de usuario)

v Credencial no autenticada utilizada para el control de acceso a los recursosv La configuración de WebSEAL debe estipular la privacidad

3. Contenido privado: el acceso requiere autenticación


v Acceso de clientes autenticados mediante HTTP o HTTPSv El administrador determina la necesidad de cifradov Credencial autenticada utilizada para el control de acceso a los recursos; los

clientes deben tener una cuenta definida en el registro de usuariosv La configuración de WebSEAL es compleja y todas las opciones se deben

considerar con atención para determinar el impacto de la política deseguridad

Información sobre la autenticación de WebSEALLa autenticación es el método para identificar un proceso o entidad individual queintenta iniciar la sesión en un dominio seguro. Cuando tanto el servidor como elcliente requieren la autenticación, el intercambio se denomina autenticación mutua.

WebSEAL puede aplicar un alto grado de seguridad en un dominio seguro alsolicitar a cada cliente que proporcione una prueba de su identidad.

Las siguientes condiciones se aplican a la autenticación de WebSEAL:v WebSEAL da soporte a un conjunto estándar de métodos de autenticación.

Puede personalizar WebSEAL para dar soporte a otros métodos de autenticación.v El proceso de servidor WebSEAL es independiente del método de autenticación.v WebSEAL sólo requiere una identidad de cliente. A partir de esta identidad,

WebSEAL crea una credencial autenticada (o no autenticada) que el servicio deautorizaciones de Access Manager puede utilizar para permitir o denegar elacceso a los recursos.

Este enfoque flexible de la autenticación permite que la política de seguridad sebase en los requisitos de la empresa y no en la topología física de la red.

Objetivos de autenticaciónAunque WebSEAL es independiente del proceso de autenticación, WebSEALrequiere el resultado de la autenticación: la identidad del cliente. El proceso deautenticación produce las acciones siguientes:1. El método de autenticación produce una identidad de cliente

La autenticación de cliente sólo es correcta si el usuario tiene una cuentadefinida en el registro de usuarios de Access Manager o un CDAS la haprocesado correctamente. Si no, el usuario se designa como no autenticado.La información de identidad específica de un método como, por ejemplo,contraseñas, señales y certificados representa las propiedades de identidadfísica del usuario. Esta información se puede utilizar para establecer una sesiónsegura con el servidor.

Figura 6. Autenticación mutua


2. WebSEAL utiliza la identidad para adquirir credenciales para ese clienteWebSEAL compara la identidad del cliente con un usuario registrado de AccessManager. A continuación, WebSEAL crea las credenciales adecuadas para esteusuario. Esto se conoce como adquisición de credenciales.La credencial representa los privilegios de un usuario en el dominio seguro,describe al usuario en un contexto específico y sólo es válida durante laduración de esa sesión. Los datos de credenciales incluyen el nombre deusuario, las pertenencias a grupos y cualquier atributo de seguridad especial“ampliado”.Si un usuario no es miembro del registro de usuarios (“anónimo”), WebSEALcrea una credencial no autenticada para ese usuario. Recuerde que una ACLpuede contener reglas especiales que rijan a los usuarios no autenticados.Estas credenciales están disponibles para el servicio de autorizaciones quepermite o deniega el acceso a los objetos solicitados en el espacio de objetosprotegidos de WebSEAL.

Cualquier servicio de Access Manager que requiera información acerca del clientepuede utilizar las credenciales. Las credenciales permiten que Access Manager llevea cabo de forma segura una multitud de servicios como, por ejemplo, laautorización, auditoría y delegación.

Access Manager distingue la autenticación del usuario de la adquisición decredenciales. La identidad de un usuario es siempre constante. Sin embargo, lascredenciales, que definen los grupos o roles en los que participa un usuario, sonvariables. Las credenciales específicas del contexto pueden cambiar con el tiempo.Por ejemplo, cuando se promueve a una persona, las credenciales deben reflejar elnuevo nivel de responsabilidad.

Consulte el apartado Capítulo 5, “Autenticación de WebSEAL” en la página 107para obtener más información acerca del soporte para métodos de autenticaciónespecíficos.

Acceso autenticado y no autenticado a los recursosEn un entorno de dominio seguro de Access Manager, la identidad de un usuariose demuestra en WebSEAL a través del proceso de autenticación. En general, unusuario puede participar en el dominio seguro como autenticado o no autenticado.

En cualquiera de ambos casos, el servicio de autorizaciones de Access Managerrequiere una credencial de usuario para tomar decisiones de autorización sobre laspeticiones de recursos en el dominio seguro. WebSEAL gestiona las credenciales deusuario autenticado de forma distinta de las credenciales de usuario noautenticado.

La credencial de un usuario no autenticado es simplemente un pasaporte genéricoque permite al usuario participar en el dominio seguro y acceder a recursos queestán disponibles para los usuarios no autenticados.

La credencial de un usuario autenticado es un pasaporte exclusivo que describe unusuario específico que pertenece al registro de usuarios de Access Manager (o seprocesa correctamente mediante un CDAS). La credencial de usuario autenticadocontiene la identidad del usuario, las pertenencias a grupos y cualquier atributo deseguridad especial (“ampliado”).

El flujo de proceso para los usuarios autenticados es el siguiente:


v Un usuario efectúa una petición de un recurso protegido por WebSEAL. Laprotección del recurso requiere que el usuario se autentique. WebSEAL solicita alusuario que inicie la sesión.

v Sólo puede producirse una autenticación correcta si el usuario es miembro delregistro de usuarios de Access Manager o lo gestiona una operación de CDAS.

v Se crea un ID de sesión de WebSEAL para el usuario.v Se crea una credencial para este usuario a partir de la información que contiene

el registro acerca de este usuario (como las pertenencias a grupos).v El ID de sesión y la credencial, más otros datos, se almacenan como una entrada

en la caché de sesión/credenciales de WebSEAL.v Mientras WebSEAL procesa esta petición —y futuras peticiones a lo largo de esta

sesión—, mantiene disponible la información de las credenciales.v Siempre que es necesaria una comprobación de autorización, el servicio de

autorizaciones de Access Manager utiliza la información de las credencialesdurante el proceso de toma de decisiones.

v Cuando el usuario finaliza la sesión, se elimina la entrada de caché de eseusuario y se termina la sesión.

El flujo de proceso para los usuarios no autenticados es el siguiente:v Un usuario efectúa una petición de un recurso protegido por WebSEAL. La

protección del recurso no requiere que el usuario se autentique. WebSEAL nosolicita al usuario que inicie la sesión.

v WebSEAL crea una credencial no autenticada para el usuario.v No se crea ninguna entrada en la caché de sesión/credenciales de WebSEAL.v El usuario puede acceder a los recursos que contienen los permisos correctos

para la categoría de tipo no autenticado de usuario.v Si el usuario requiere el acceso a un recurso no disponible para los usuarios no

autenticados, WebSEAL solicita que el usuario inicie la sesión.v Si se inicia la sesión correctamente, el estado del usuario cambia a autenticado.v Si el inicio de sesión no es correcto, se devuelve un mensaje 403 “No

autorizado”. El usuario aún puede seguir accediendo a otros recursosdisponibles para los usuarios no autenticados.

Estructura de caché de sesión/credenciales de WebSEALLa caché de sesión de WebSEAL también se conoce como caché de credenciales deWebSEAL. La caché se puede representar como una tabla interna en que WebSEALalmacena información acerca de todas las sesiones establecidas por los usuariosautenticados.


Cada sesión de usuario se representa mediante una entrada en la tabla de caché.

Cada entrada de la caché contiene los siguientes tipos de información:v ID de sesión

El ID de sesión es un identificador exclusivo que se envía con cada peticiónefectuada por ese usuario. El ID de sesión identifica la entrada específica de lacaché para ese usuario.

v Datos de la caché

El dato más importante que se almacena en la entrada de la caché es lacredencial del usuario. La credencial es necesaria siempre que el usuario solicitarecursos protegidos. El servicio de autorizaciones utiliza la información de lacredencial para permitir o denegar el acceso al recurso.WebSEAL puede marcar, o “poner un indicador” en una entrada de la cachépara que dé soporte a una funcionalidad determinada. Por ejemplo, cuando lareautenticación por inactividad de sesión está habilitada, se “pone un indicador”en la entrada de la caché cuando haya caducado el valor de inactividad de lasesión.

v Indicaciones de la hora

La indicación de la hora de la creación para la entrada de la caché se convierteen el punto de referencia para el valor de la duración de la sesión. La indicaciónde la hora que fue la “última activa” para la entrada de la caché se convierte enel punto de referencia para el temporizador de inactividad de sesión.

La credencial de usuario contiene:v Nombre de usuariov Pertenencias a gruposv Atributos ampliados

Los atributos ampliados permiten almacenar los datos personalizados en lacredencial del usuario. Un ejemplo de atributo ampliado de credencial es elatributo tagvalue_user_session_id. El valor de este atributo se puede insertar enuna cabecera HTTP para permitir que un servidor de fondo con conexión(junction) para mantener el estado de la sesión con el usuario.

Figura 7. Caché de sesión/credenciales de WebSEAL


Información sobre las conexiones (junctions) WebSEALAccess Manager proporciona servicios de autenticación, autorización y gestión parauna red. En una red basada en la web, es mejor que estos servicios los suministrenuno o más servidores WebSEAL frontales que integren y protejan los recursos yaplicaciones web ubicadas en servidores web de fondo.

La conexión entre un servidor WebSEAL y un servidor de aplicaciones web defondo se conoce como conexión (junction) WebSEAL o conexión (junction). Unaconexión (junction) WebSEAL es una conexión TCP/IP entre un servidor WebSEALfrontal y un servidor de fondo.

El servidor de fondo puede ser otro servidor WebSEAL o, lo que es más habitual,un servidor de aplicaciones web de terceros. El espacio web del servidor de fondoestá “conectado” con el servidor WebSEAL en un punto (de montaje) de conexión(junction) especialmente designado en el espacio web de WebSEAL.

Una conexión (junction) permite a WebSEAL proporcionar servicios de protecciónen nombre del servidor de fondo. WebSEAL puede realizar comprobaciones deautenticación y autorización en todas las peticiones antes de pasar esas peticionesal servidor de fondo. Si el servidor de fondo requiere un control de accesodetallado sobre sus objetos, debe realizar pasos de configuración adicionales paradescribir el espacio web de terceros para el servicio de seguridad de AccessManager (consulte el apartado “Utilización de query_contents con servidores deterceros” en la página 186).

Las conexiones (junctions) proporcionan un entorno seguro escalable que permiteel equilibrio de la carga, una alta disponibilidad y la posibilidad de gestión delestado, todo ello realizado de una forma transparente para los clientes. Comoadministrador, puede beneficiarse de esta gestión centralizada del espacio web.

Las conexiones (junctions) WebSEAL proporcionan el valor añadido de combinarde una forma lógica el espacio web de un servidor de fondo con el espacio webdel servidor WebSEAL. Las conexiones (junctions) entre servidores que cooperandan como resultado un solo espacio web distribuido y unificado que estransparente y directo para los usuarios.

El cliente no necesita conocer la ubicación física de un recurso web. WebSEALconvierte las direcciones URL lógicas en las direcciones físicas que espera unservidor de fondo. Los objetos web se pueden mover de servidor a servidor sinque afecte a la forma en que el cliente accede a esos objetos.

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


Un espacio web simplifica la gestión de todos los recursos para el administradordel sistema. Las ventajas administrativas adicionales incluyen la escalabilidad, elequilibrio de la carga y una alta disponibilidad.

La mayoría de servidores web comerciales no disponen de la posibilidad de definirun espacio de objetos web lógico, sino que el control de acceso se conecta alarchivo físico y la estructura del directorio. Las conexiones (junctions) WebSEALpueden definir de forma transparente un espacio de objetos que refleje laestructura organizativa 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 crear soluciones de iniciode sesión único. Una configuración de inicio de sesión único permite al usuarioacceder a un recurso, con independencia de la ubicación del recurso, utilizandosólo un inicio de sesión inicial. Los requisitos de inicio de sesión posteriores de losservidores de fondo se gestionan de una forma transparente para el usuario.

Las conexiones (junctions) WebSEAL son una herramienta importante para que elsitio web sea escalable. Las conexiones (junctions) le permiten responder a lascrecientes demandas de un sitio web al conectar servidores adicionales.

Figura 9. La conexión (junction) WebSEAL da como resultado un espacio web unificado


Conexiones (junctions) WebSEAL y escalabilidad de sitiosweb

Las conexiones (junctions) WebSEAL se utilizan para crear un sitio web escalable.Al crecer las demandas del sitio, se pueden agregar fácilmente más servidores paraampliar las posibilidades del sitio.

Se pueden agregar servidores adicionales por los siguientes motivos:v Para ampliar el sitio con contenido adicionalv Para duplicar el contenido existente para el equilibrio de la carga, la posibilidad

de migración tras error y aumentar la disponibilidad

Servidores WebSEAL frontales replicadosEl soporte para conexiones (junctions) para los servidores de fondo empieza con, almenos, un servidor WebSEAL frontal. Los servidores WebSEAL frontales replicadosproporcionan al sitio un equilibrio de carga durante los períodos de gran demanda.El mecanismo 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 de migración traserror: si por algún motivo falla un servidor, los servidores replicados restantescontinuarán ofreciendo acceso al sitio. El equilibrio de carga correcto y laposibilidad de migración tras error da como resultado una alta disponibilidad paralos usuarios del sitio.

Al replicar servidores WebSEAL frontales, cada servidor debe contener una copiaexacta del espacio web y la base de datos de conexiones (junctions).

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

Figura 10. Servidores WebSEAL frontales replicados


Soporte para servidores de fondoEl propio servidor WebSEAL, los servidores de fondo o una combinación de ambospueden servir el contenido del sitio web. El soporte para conexiones (junctions)WebSEAL para servidores de fondo le permite escalar el sitio web mediantecontenido y recursos adicionales.

Cada servidor de fondo exclusivo debe estar conectado con un punto (de montaje)de conexión (junction) separado. Al crecer la demanda de contenido adicional, sepueden agregar más servidores mediante conexiones (junctions). Este ejemploproporciona una solución para redes que tengan una gran inversión en servidoresweb de terceros.

El diagrama siguiente muestra cómo las conexiones (junctions) proporcionan unespacio de objetos lógico unificado. Este espacio web es transparente para elusuario y permite una gestión centralizada.

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


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

Servidores de fondo replicadosPara ampliar las funciones de escalabilidad para una configuración de servidor defondo, puede replicar los servidores de fondo. Como en el caso de los servidoresfrontales replicados, los servidores de fondo replicados deben contener espacioweb que sean imágenes reflejadas mutuas.

WebSEAL equilibra la carga de los servidores replicados mediante un algoritmo deplanificación “menos ocupado”. Este algoritmo dirige todas las nuevas peticionesal servidor que tenga el menor número de conexiones (junctions) en progreso.

WebSEAL también utilizará la característica de migración tras error cuando unservidor no esté activo y volverá a utilizarlo de nuevo cuando se haya reiniciado.

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

Figura 12. Espacio web unificado


Figura 13. Servidores de fondo replicados


Capítulo 2. Configuración básica del servidor

Este capítulo contiene información que describe las tareas generales deconfiguración y administración que se pueden llevar a cabo para personalizar elservidor WebSEAL para la red.

Índice de temas:v “Información general del servidor” en la página 21v “Utilización del archivo de configuración de WebSEAL” en la página 23v “Configuración de los parámetros de comunicación” en la página 25v “Gestión del espacio web” en la página 28v “Gestión de páginas personalizadas de mensajes de error HTTP” en la página 33v “Gestión de páginas personalizadas de gestión de cuentas” en la página 36v “Gestión de certificados de cliente y servidor” en la página 38v “Configuración del registro HTTP predeterminado” en la página 43v “Configuración del registro HTTP mediante el registro de eventos” en la página

46v “Registro de mensajes de servicios de WebSEAL” en la página 47

Información general del servidorEn los siguientes apartados se proporciona información general sobre el servidorWebSEAL:v “Directorio raíz de la instalación de WebSEAL” en la página 21v “Inicio y detención de WebSEAL” en la página 22v “WebSEAL representado en el espacio de objetos protegidos” en la página 22v “WebSEAL devuelve HTTP/1.1” en la página 22v “Archivo de registro de WebSEAL” en la página 23

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

UNIX:/opt/pdweb/

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

Puede configurar esta ruta de acceso en una instalación de Access Manager paraWindows. No puede configurar esta ruta de acceso en las instalaciones UNIX deAccess Manager.

Esta guía utiliza la variable <ruta-acceso-instalación> para representar este directorioraíz.

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


Inicio y detención de WebSEALEl proceso del servidor WebSEAL se puede iniciar y detener utilizando el comandopdweb en UNIX o utilizando Servicios en el Panel de control de Windows.

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

El comando pdweb está ubicado en el siguiente directorio:/usr/bin/

Por ejemplo, para detener el servidor WebSEAL y reiniciarlo a continuación utilice:# /usr/bin/pdweb restart

Windows:

Identifique el proceso del servidor WebSEAL en Servicios, en el Panel de control, yutilice los botones de control correspondientes.

WebSEAL representado en el espacio de objetos protegidosEl parámetro server-name del archivo de configuración webseald.conf especifica elpunto en el espacio de objetos protegidos de Access Manager que representa estainstancia de servidor WebSEAL.

Para una sola instalación de servidor WebSEAL, este valor se estableceautomáticamente utilizando el nombre de host de la máquina en que se estáinstalando este servidor WebSEAL.

Por ejemplo, si el nombre de máquina (host) es sales1, el valor del parámetro seestablece como:[server]server-name = sales1

La representación de esta instancia de servidor WebSEAL en el espacio de objetosprotegidos de Access Manager aparecería como:/WebSEAL/sales1

Consulte también: “Réplica de servidores WebSEAL frontales” en la página 55.

Para tener múltiples instancias de WebSEAL en la misma máquina, este valor seestablece mediante la opción –i en el script PDWeb_config (UNIX) o ivweb_setup(Windows) utilizado para crear las múltiples instancias de servidor WebSEAL.

Consulte también: “Configuración de múltiples instancias de servidor WebSEAL”en la página 56.

WebSEAL devuelve HTTP/1.1Las peticiones HTTP/1.0 sólo se envían a servidores de fondo con conexión(junction) si dichos servidores devuelven un estado 400 (Petición incorrecta), sidevuelven un estado 504 (Versión de HTTP no soportada) o si el navegador delcliente especifica HTTP/1.0 en la petición.

En caso contrario, si el servidor de fondo acepta HTTP/1.1, WebSEAL envíapeticiones HTTP/1.1.


Sin embargo, aun cuando WebSEAL envía una petición HTTP/1.0 a un servidor defondo con conexión (junction) (y el servidor de fondo devuelve una respuestaHTTP/1.0), WebSEAL devuelve siempre una respuesta HTTP/1.1 al navegador delcliente.

Archivo de registro de WebSEALEl archivo de registro de WebSEAL registra mensajes de servicios tales comomensajes de aviso y de error del servidor. El nombre y la ubicación del archivo deregistro se define mediante el parámetro server-log en la stanza [logging] delarchivo de configuración webseald.conf:

UNIX:[logging]server-log = /var/pdweb/log/webseald.log

Windows:[logging]server-log = C:/Archivos de programa/Tivoli/PDWeb/log/webseald.log

Consulte también el apartado “Registro de mensajes de servicios de WebSEAL” enla página 47.

Utilización del archivo de configuración de WebSEALEn los siguientes apartados se proporciona información sobre el archivo deconfiguración de WebSEAL (webseald.conf):v “Presentación del archivo de configuración webseald.conf” en la página 23v “Directorio raíz de servidor WebSEAL” en la página 25

Presentación del archivo de configuración webseald.confPuede personalizar el funcionamiento de WebSEAL configurando los parámetrosque se encuentran en el archivo de configuración webseald.conf. Este archivo seencuentra en el siguiente directorio:

UNIX:/opt/pdweb/etc/

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

Los archivos de configuración de Access Manager están basados en texto ASCII yse pueden editar mediante un editor de texto común. Los archivos deconfiguración contienen entradas de parámetro en el formato siguiente:parámetro = valor

La instalación inicial de Access Manager establece valores predeterminados para lamayoría de parámetros. Algunos parámetros son estáticos y no cambian nunca;otros pueden modificarse para personalizar la funcionalidad y el rendimiento delservidor.

Cada archivo contiene secciones, o stanzas, que contienen uno o más parámetrospara una categoría específica de la configuración. Las cabeceras de las stanzasaparecen entre corchetes:[nombre-stanza]

Capítulo 2. Configuración básica del servidor 23

Por ejemplo, la stanza [junction] de webseald.conf define los valores deconfiguración que afectan a las conexiones (junctions) WebSEAL. La stanza[authentication-mechanisms] define los mecanismos de autenticación soportadospor WebSEAL, junto con los archivos de bibliotecas compartidas asociados.

Los archivos de configuración contienen comentarios que explican el uso de cadaparámetro. El carácter “#” se utiliza para designar una línea como un comentario.Todas las líneas de comentario comienzan con el carácter “#”. Por consiguiente, elcarácter “#” no es un carácter válido para su uso en los valores de parámetro.

Nota: Siempre que se efectúe un cambio en el archivo webseald.conf, deberáreiniciar manualmente WebSEAL para que se reconozcan los nuevoscambios. Consulte el apartado “Inicio y detención de WebSEAL” en lapágina 22.

La tabla siguiente resume las secciones y las stanzas contenidas en el archivo deconfiguración webseald.conf:

Secciones Stanzas

GENERAL DE WEBSEAL [server]

LDAP [ldap]

ACTIVE DIRECTORY [uraf-ad]

DOMINO [uraf-domino]

SSL [ssl]

CONEXIÓN (JUNCTION) [junction][filter-url][filter-schemes][filter-content-types][script-filtering][gso-cache][ltpa-cache]

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

SESIÓN [session]


Secciones Stanzas

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 Apéndice A, “Consulta de webseald.conf” en la página 233.

Directorio raíz de servidor WebSEALEl parámetro server-root del archivo de configuración webseald.conf define laubicación raíz del servidor WebSEAL para otros parámetros de este archivo. Todoslos nombres de ruta de acceso relativa expresados en el archivo de configuraciónwebseald.conf son relativos a este directorio raíz.

UNIX:[server]server-root = /opt/pdweb/www

Windows:[server]server-root = C:\Archivos de programa\Tivoli\PDWeb\www

Nota: En condiciones normales, no se debe cambiar este nombre de ruta de acceso.

Configuración de los parámetros de comunicaciónEn los siguientes apartados se describe la información general sobre el servidorWebSEAL:v “Configuración de WebSEAL para peticiones HTTP” en la página 25v “Configuración de WebSEAL para peticiones HTTPS” en la página 26v “Restricción de conexiones de versiones de SSL específicas” en la página 26v “Parámetros de tiempo de espera para la comunicación HTTP/HTTPS” en la

página 26v “Parámetros adicionales de tiempo de espera del servidor WebSEAL” en la

página 27

Configuración de WebSEAL para peticiones HTTPWebSEAL manipula habitualmente muchas peticiones HTTP de usuarios noautenticados. Por ejemplo, es habitual permitir a los usuarios anónimos el accesode sólo lectura a los documentos seleccionados de la sección pública del sitio web.

Los parámetros para manipular las peticiones HTTP mediante TCP se encuentranen la stanza [server] del archivo de configuración webseald.conf.


Habilitación e inhabilitación del acceso HTTPPuede habilitar o inhabilitar el acceso HTTP durante la configuración de WebSEAL:http = {yes|no}

Definición del valor de puerto del 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 manipular peticiones HTTP mediante SSL (HTTPS) seencuentran en la stanza [server] del archivo de configuración webseald.conf.

Habilitación e inhabilitación del acceso HTTPSPuede habilitar o inhabilitar el acceso HTTPS durante la configuración deWebSEAL:https = {yes|no}

Definición del valor de puerto del 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 de SSL específicasPuede habilitar e inhabilitar independientemente la conectividad de SSL (SecureSockets Layer) versión 2, SSL versión 3 y TLS (Transport Layer Security) versión 1.Los parámetros que controlan las conexiones para las versiones específicas de SSLy TLS se encuentran en la stanza [ssl] del archivo de configuración webseald.conf.De forma predeterminada, están habilitadas todas las versiones de SSL y TLS.[ssl]disable-ssl-v2 = nodisable-ssl-v3 = nodisable-tls-v1 = no

Parámetros de tiempo de espera para la comunicaciónHTTP/HTTPS

WebSEAL utiliza la implementación de SSL de IBM Global Security Kit (GSKit).Cuando WebSEAL recibe una petición de un cliente HTTPS, GSKit SSL establece elreconocimiento inicial y mantiene el estado de la sesión.

WebSEAL da soporte a los siguientes parámetros de tiempo de espera para lacomunicación HTTP y HTTPS. Estos parámetros se encuentran en la stanza[server] del archivo de configuración webseald.conf.v client-connect-timeout

Una vez efectuado el reconocimiento inicial, este parámetro establece el tiempodurante el que WebSEAL mantendrá abierta la conexión para la petición HTTP oHTTPS inicial. El valor predeterminado es 120 segundos.[server]client-connect-timeout = 120


v persistent-con-timeout

Después de la primera petición HTTP y la respuesta del servidor, este parámetrocontrola el número máximo de segundos durante los que el servidor mantendráabierta una conexión persistente HTTP antes de cerrarla. El valorpredeterminado es 5 segundos.[server]persistent-con-timeout = 5

Parámetros adicionales de tiempo de espera del servidorWebSEAL

Los siguientes parámetros adicionales de tiempo de espera se establecen en elarchivo de configuración webseald.conf:

Parámetro Descripción Valor predeterminado(segundos)

[junction]http-timeout

Valor de tiempo de espera para elenvío a un servidor de fondo y parala lectura desde ese servidor a travésde una conexión (junction) TCP.

120

[junction]https-timeout

Valor de tiempo de espera para elenvío a un servidor de fondo y parala lectura desde ese servidor a travésde una conexión (junction) SSL.

120

[cgi]cgi-timeout Valor de tiempo de espera para elenvío a un proceso CGI local y parala lectura desde ese proceso.

120

[junction]ping-time

De forma periódica, WebSEALejecuta ping en segundo plano decada servidor con conexión(junction) para determinar sifunciona. WebSEAL no lo intentarácon una frecuencia superior a 300segundos (o el valor establecido).

300

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


Gestión del espacio webLos siguientes apartados describen las tareas necesarias para gestionar el espacioweb:v “Directorio raíz del árbol de documentos web” en la página 28v “Configuración del índice de directorios” en la página 29v “Windows: convenios de denominación para programas CGI” en la página 30v “Configuración del almacenamiento en la caché de documentos web” en la

página 31v “Especificación de tipos de documento para el filtrado” en la página 33

Directorio raíz del árbol de documentos webLa ubicación del árbol de documentos web es la ruta de acceso absoluta deldirectorio raíz del árbol de documentos para los documentos disponibles medianteWebSEAL. Este nombre de ruta de acceso está representado por el parámetrodoc-root de la stanza [content] del archivo de configuración webseald.conf. Laubicación predeterminada se establece inicialmente durante la instalación deWebSEAL:

UNIX:[content]doc-root = /opt/pdweb/www/docs

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

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

Cómo cambiar el directorio raíz de documentos después de la instalación:

Después de la instalación, deberá utilizar el programa de utilidad pdadmin paracambiar el valor de la ubicación del directorio raíz de documentos. El ejemplosiguiente (el nombre de la máquina, o host, es websealA) ilustra esteprocedimiento:1. Inicie la sesión en pdadmin:

# pdadminpdadmin> loginEscriba el ID de usuario: sec_masterEscriba la contraseña:pdadmin>

2. Utilice el comando server task list para mostrar todos los puntos de conexión(junction) actuales:pdadmin> server task webseald-websealA list/

3. Utilice el comando server task show para mostrar los detalles de la conexión(junction):pdadmin> server task webseald-websealA show /Punto de conexión (junction): /Tipo: Local


Límite fijo de conexión (junction): 0 - se utilizará el valor globalLímite dinámico de conexión (junction): 0 - se utilizará el valor globalThreads de trabajo activos: 0Directorio raíz: /opt/pdweb/www/docs

4. Cree una nueva conexión (junction) local para sustituir el punto de conexión(junction) actual (la opción -f es necesaria para forzar una nueva conexión(junction) que sobrescriba una conexión (junction) existente:pdadmin> server task webseald-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 webseald-websealA list/

6. Visualice los detalles de esta conexión (junction):pdadmin> server task webseald-websealA show /Punto de conexión (junction): /Tipo: LocalLímite fijo de conexión (junction): 0 - se utilizará el valor globalLímite dinámico 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 ha devueltoWebSEAL cuando la expresión de dirección URL de una petición finalice con unnombre de directorio. Si este archivo predeterminado existe, WebSEAL lo devuelveal cliente. Si el archivo 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 se encuentra en lastanza [content] del archivo de configuración webseald.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 convenio distinto. Porejemplo:[content]directory-index = homepage.html

WebSEAL genera dinámicamente un índice de directorios si el directorio de lapetición no contiene el archivo de índice definido por el parámetrodirectory-index. El índice generado contiene una lista con el contenido deldirectorio, con vínculos a cada una de las entradas del directorio. El índice sólo segenera si el cliente que solicita acceso al directorio tiene el permiso “list” (l) en laACL de ese directorio.

Puede configurar los iconos gráficos que utiliza WebSEAL para cada tipo dearchivo que aparece en el índice generado. La stanza [content-index-icons] delarchivo de configuración webseald.conf contiene una lista de los tipos MIME dedocumentos y los archivos .gif asociados que se muestran:[content-index-icons]image/*= /icons/image2.gifvideo/* = /icons/movie.gifaudio/* = /icons/sound2.gif


text/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 para cada tipoMIME. Los iconos también se pueden ubicar de forma remota. Por ejemplo:application/* = http://www.acme.com/icons/binary.gif

También se pueden configurar estos valores de iconos adicionales:v Icono utilizado para representar subdirectorios:

[icons]diricon = /icons/folder2.gif

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

v Icono utilizado para representar los tipos de archivos desconocidos:[icons]unknownicon = /icons/unknown.gif

Windows: convenios de denominación para programas CGILos parámetros contenidos en la stanza [cgi-types] del archivo de configuraciónwebseald.conf le permiten especificar los tipos de extensión de archivo deWindows que se reconocen y ejecutan como programas CGI.

El sistema operativo UNIX no tiene requisitos de extensión de nombre de archivo.No obstante, los tipos de extensión deben estar definidos para los sistemasoperativos Windows. La stanza [cgi-types] enumera todos los tipos de extensiónválidos y correlaciona cada extensión (cuando es necesario) con un programa CGIapropiado.[cgi-types]<extensión> = <programa-cgi>

De forma predeterminada, sólo los archivos con extensiones que coincidan con laslistadas en la stanza se ejecutarán como programas CGI. Si un programa CGI tieneuna extensión que no está contenida en esta lista, el programa no se ejecutará.

Los archivos con extensiones .exe se ejecutan como programas según el valorpredeterminado de Windows y no requieren ninguna correlación.

Nota: Cuando quiera instalar un archivo .exe en Windows para su descarga,deberá cambiar el nombre de la extensión o bien instalar el archivo comoparte de un archivador (por ejemplo, .zip).

Debe proporcionar los programas intérpretes apropiados para las extensiones querepresentan los archivos script interpretados. Como ejemplos de esos tipos deextensiones 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]:[cgi-types]bat = cmdcmd = cmdpl = perlsh = shtcl = tclsh76


Nota: Existen graves problemas de seguridad implicados en el uso de los archivos.bat y .cmd. Utilice esos tipos de archivo con precaución.

Configuración del almacenamiento en la caché dedocumentos web

Los clientes pueden experimentar a menudo un largo tiempo de acceso a la red yde descarga de archivos debido a un pobre rendimiento en la recuperación dedocumentos web. Se puede producir un bajo rendimiento si el servidor WebSEALespera documentos recuperados de servidores de fondo con conexión (junction) ode un almacenamiento local lento.

El almacenamiento en la caché de documentos web ofrece la flexibilidad de servirdocumentos de forma local desde WebSEAL en vez de hacerlo desde un servidorde fondo a través de una conexión (junction). La función de almacenamiento en lacaché de documentos web permite almacenar los tipos de documentos web a losque se accede habitualmente en la memoria del servidor WebSEAL. Los clientespueden experimentar una respuesta mucho más rápida a las peticiones reiteradasde documentos que se han almacenado en la caché del servidor WebSEAL.

Los documentos en la caché pueden incluir documentos de texto estáticos eimágenes gráficas. Los documentos generados de forma dinámica, como losresultados de consultas de bases de datos, no se pueden almacenar en la caché.

El almacenamiento en la caché se realiza según el tipo MIME. Al configurarWebSEAL para el almacenamiento en la caché de documentos web, se identificanlos tres parámetros siguientes:v Tipo MIME del documentov Tipo de medio de almacenamientov Tamaño del medio de almacenamiento

El almacenamiento en la caché de documentos web se define en la stanza[content-cache] del archivo de configuración webseald.conf. Se aplica la siguientesintaxis:<tipo-mime> = <tipo-caché>:<tamaño-caché>

Parámetro Descripción

tipo-mime Representa cualquier tipo MIME transmitido en una cabecera derespuesta “Content-Type:”. Este valor puede contener un caráctercomodín ( * ). Un valor de */* representa una caché de objetospredeterminada que retendrá cualquier objeto que no corresponda auna caché configurada de forma explícita.

tipo-caché Especifica el tipo de medio de almacenamiento que se utilizará parala caché. Este release de Access Manager da soporte sólo a cachés detipo “memory” (memoria).

tamaño-caché Especifica el tamaño máximo (en kilobytes) que puede alcanzar unacaché determinada antes de que se eliminen los objetos según elalgoritmo “Usados menos recientemente”.

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


Condiciones que afectan al almacenamiento en la caché dedocumentos webEl mecanismo de almacenamiento en la caché de documentos web observa lascondiciones siguientes:v El almacenamiento en la caché sólo se produce cuando se define una caché en

webseald.conf.v De forma predeterminada, no se define ninguna caché durante la instalación.v Si no se especifica una caché predeterminada, los documentos que no coinciden

con ninguna caché explícita no se almacenan en la caché.v La autorización se sigue realizando en todas las peticiones de información en la

caché.v El mecanismo de almacenamiento en la caché no almacena en la caché las

respuestas a las peticiones que contienen cadenas de consulta.v El mecanismo de almacenamiento en la caché no almacena en la caché las

respuestas a las peticiones realizadas a través de conexiones (junctions)configuradas con las opciones –c y –C.

Vaciado de todas las cachésPuede utilizar el programa de utilidad pdadmin para vaciar todas las cachésconfiguradas. El programa de utilidad no permite vaciar cachés individuales.

Debe iniciar la sesión en el dominio seguro como administrador de AccessManager sec_master antes de que pueda utilizar pdadmin.

Para vaciar todas las cachés de documentos web, especifique el siguiente comando:

UNIX:# pdadmin server taskwebseald-<nombre-máquina> cache flush all

Windows:MSDOS> pdadmin server task webseald-<nombre-máquina> cache flush all

Control del almacenamiento en la caché para documentosespecíficosSe puede almacenar documentos específicos en la caché asociando una Política deobjetos protegidos (POP) con esos objetos. Esta POP debe contener un atributoampliado denominado document-cache-control.

El atributo ampliado document-cache-control reconoce los dos valores siguientes:

Valor Descripción

no-cache El valor no-cache indica que WebSEAL no almacene este documentoen la caché. Recuerde que todos los hijos del objeto con la POPheredan también las condiciones de la POP.

public El valor public permite que WebSEAL almacene el documento en lacaché, omitiendo el hecho de que la conexión (junction) se creó conuna opción –c o –C. Además, este valor también permite elalmacenamiento en la caché de este documento cuando se envía lapetición con una cabecera de autorización (como la AutenticaciónBásica (BA)). Asimismo, esta condición incluye una petición en queWebSEAL inserta información de BA en nombre del cliente (como lasconexiones (junctions) GSO o –b supply). En circunstancias normales,los servidores proxy no almacenan en la caché los documentos derespuesta a las peticiones que incluyen cabeceras de autorización.


Utilice los comandos pdadmin pop create, pdadmin pop modify y pdadmin popattach. El ejemplo siguiente muestra cómo crear una POP denominada “doc-cache”con el atributo ampliado document-cache-control y cómo asociarla con un objeto(budget.html):pdadmin> pop create doc-cachepdadmin> pop modify doc-cache set attribute document-cache-control no-cachepdadmin> pop attach /WebSEAL/hostA/junction/budget.html doc-cache

WebSEAL no almacena nunca en la caché el documento budget.html. Cadapetición de este documento debe efectuarse directamente al servidor de fondodonde está ubicado.

Los detalles acerca del programa de utilidad de línea de comandos pdadminpueden encontrarse en la publicación IBM Tivoli Access Manager Base Guía deladministrador.

Especificación de tipos de documento para el filtradoPuede especificar los tipos de contenido de documento que WebSEAL filtra en lasrespuestas de servidores de fondo con conexión (junction). El parámetro type de lastanza [filter-content-types] del archivo de configuración webseald.conf acepta unvalor de tipo MIME. WebSEAL está configurado de forma predeterminada parafiltrar documentos de dos tipos MIME:[filter-content-types]type = text/htmltype = text/vnd.wap.wml

Las especificaciones de tipo MIME en esta stanza determinan qué filtrado adicionalrealizará WebSEAL en las respuestas de servidores de fondo de conexión(junction). Entre las funciones de filtrado adicionales están las siguientes:v Filtrado de esquemas de direcciones URL

stanza [filter-schemes]en webseald.conf

v Filtrado de atributos de direcciones URLConsulte el apartado “Reglas de filtrado estándar de direcciones URL paraWebSEAL” en la página 171.

v Filtrado de scripts para direcciones URL absolutasConsulte el apartado “Modificación de las direcciones URL absolutas con filtradode scripts” en la página 172.

Gestión de páginas personalizadas de mensajes de error HTTPAlgunas veces, el servidor WebSEAL intenta dar servicio a una petición y seproduce un error. Éste puede deberse a muchas causas. Por ejemplo:v No existe un archivov La configuración de los permisos prohíbe el accesov No se pueden ejecutar los programas CGI debido a permisos de archivos UNIX

incorrectos u otro motivo similar

Cuando se produce un error al dar servicio a una petición, el servidor devuelve unmensaje de error al navegador, como por ejemplo, “403 No autorizado”, en unapágina de error HTML. Hay varios mensajes de error disponibles; cada mensaje sealmacena en un archivo HTML separado.


Estos archivos se almacenan en el siguiente directorio:

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

Windows:<ruta-acceso-instalación>\www\lib\errors\<dir-entornolocal>

El directorio errors contiene varios subdirectorios locales que contienen versionestraducidas de los archivos de mensajes de error.

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

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

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

Los mensajes de este directorio están en formato HTML, por lo que se vencorrectamente en un navegador. Puede editar estas páginas HTML parapersonalizar su contenido. Los nombres de archivo son los valores hexadecimalesde los códigos de error internos que se devuelven cuando fallan las operaciones.Estos nombres no se deben modificar.

La tabla siguiente contiene una lista con los nombres de archivo y su contenido dealgunos de los mensajes de error más habituales:

Nombre dearchivo

Título Descripción Código deerror HTTP

132120c8.html La autenticación no se haejecutado correctamente

No se han podido recuperar las credenciales parael certificado de cliente utilizado. Los motivosposibles son:

v El usuario ha proporcionado un certificadoincorrecto

v Se ha rechazado el certificado

v Faltan las credenciales del usuario en la base dedatos de autenticación

38ad52fa.html El directorio no está vacío La operación indicada solicita la eliminación de undirectorio que no está vacío. Esta operación noestá permitida.

38cf013d.html Error en el almacenamientoen la caché de la petición

Se han sobrepasado los valores derequest-max-cache o request-body-max-read.

38cf0259.html No se ha podido iniciar lasesión del usuario

El recurso que ha solicitado requiere que elservidor WebSEAL inicie la sesión en otro servidorweb. Sin embargo, ha ocurrido un problemacuando WebSEAL intentaba obtener lainformación.

38cf025a.html El usuario no tieneinformación de inicio desesión único

WebSEAL no ha podido localizar el usuario GSOpara el recurso solicitado.

38cf025b.html No hay ningún destino deinicio de sesión único delusuario

WebSEAL no ha podido localizar el destino GSOpara el recurso solicitado.

38cf025c.html El usuario tiene variosdestinos de inicio de sesión

Hay varios destinos GSO definidos para el recursosolicitado. Se trata de un error de configuración.


Nombre dearchivo

Título Descripción Código deerror HTTP

38cf025d.html Se necesita iniciar la sesión Un servidor web de fondo con conexión (junction)protege el recurso solicitado, por lo que WebSEALdebe iniciar la sesión del usuario en ese servidorweb. Para ello, el usuario debe iniciar la sesiónprimero en WebSEAL.

38cf025e.html No se ha podido iniciar lasesión del usuario

El recurso que ha solicitado requiere queWebSEAL inicie la sesión en otro servidor web. Sinembargo, la información de inicio de sesión parala cuenta de usuario es incorrecta.

38cf025f.html Tentativa de autenticacióninesperada

WebSEAL ha recibido una tentativa deautenticación inesperada de un servidor web conconexión (junction).

38cf0421.html Trasladado temporalmente El recurso que ha solicitado ha sido trasladadotemporalmente. Esto sucede a menudo si hayalguna redirección mal manipulada.

302

38cf0424.html Petición incorrecta WebSEAL ha recibido una petición HTTPincorrecta.

400

38cf0425.html Se necesita iniciar la sesión El recurso que ha solicitado está protegido porWebSEAL y, para poder acceder al mismo, primerodebe iniciar la sesión.

38cf0427.html No autorizado El usuario no tiene permisos para acceder alrecurso solicitado.

403

38cf0428.html No encontrado No se puede localizar el recurso solicitado. 404

38cf0432.html Servicio no disponible En este momento, no está disponible un servicioque WebSEAL necesita para completar la petición.

503

38cf0437.html Servidor suspendido El administrador del sistema ha inhabilitadotemporalmente el servidor WebSEAL. No seatenderá ninguna petición hasta que eladministrador vuelva a habilitar el servidor.

38cf0439.html Se ha perdido lainformación de la sesión

La interacción entre navegador/servidor ha sidouna sesión con información de estado con unservidor de fondo con conexión (junction) que hadejado de responder. WebSEAL requiere unservicio que se encuentra en dicho servidor paraejecutar la petición.

38cf0442.html Servicio no disponible El servicio que necesita WebSEAL se encuentra enun servidor de fondo con conexión (junction)donde ha fallado la autenticación mutua SSL.

38cf07aa.html Ejecución incorrecta delprograma CGI

No se ha ejecutado correctamente un programaCGI.

default.html Error del servidor WebSEAL no ha podido ejecutar la petición debidoa un error inesperado.

500

deletesuccess.html Operación ejecutada La operación de supresión (DELETE) iniciada porel cliente se ha ejecutado correctamente.

200

putsuccess.html Operación ejecutada La operación de transferencia (PUT) iniciada por elcliente se ha ejecutado correctamente.

200

relocated.html Trasladado temporalmente El recurso que ha solicitado se ha trasladadotemporalmente.

302

websealerror.html 400 Error del servidorWebSEAL

Error interno del servidor WebSEAL. 400


Soporte para macros de las páginas de mensajes de errorHTTP

Las siguientes macros están disponibles para personalizar las páginas HTML deerror descritas en el apartado anterior. Las macros sustituyen de forma dinámica lainformació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 HTTP base del servidor“http://<host>:<puerto-tcp>/”.

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

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

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

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

Gestión de páginas personalizadas de gestión de cuentasAccess Manager incluye ejemplos de páginas HTML de gestión de cuentas que sepueden personalizar de forma que contengan mensajes específicos para el sitio olleven a cabo acciones específicas para éste. La mayoría de formularios sonadecuados para la autenticación de formularios, señales y de BA a través de HTTPo HTTPS.

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

El directorio real utilizado se basa en el idioma. El directorio predeterminado parainglé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áginas personalizadasLos siguientes parámetros y valores especiales de páginas HTML se encuentran enla stanza [acnt-mgt] del archivo de configuración webseald.conf. Algunas páginassólo las utiliza el método de inicio de sesión de formularios que proporciona lainformación de identidad.


Parámetro Página Utilización

login = login.html Inicio de sesión deformularios

login-success = login_success.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 de señales

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

stepup-login = stepuplogin.html Autenticación incremental

Descripciones de páginas HTML personalizadas

Formulario Descripción

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

login_success.html Página que aparece después de iniciar la sesióncorrectamente.

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 usuariodebido a una cuenta bloqueada.

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

passwd.html Formulario de cambio de contraseña. Aparece también sifalla la petición de cambio de contraseña.

passwd_rep.html Página que aparece si la petición de cambio de contraseñaha sido 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ónincremental.

Soporte para macros de las páginas de gestión de cuentasTambién hay dos macros disponibles para utilizar en estas páginas. Estas cadenasde macros se pueden colocar en los archivos de plantilla. La macro sustituye deforma dinámica los valores apropiados.


Macro Descripción

%USERNAME% Nombre del usuario conectado

%ERROR% Mensaje de error no modificable devuelto por AccessManager

%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 HTTP base del servidor“http://<host>:<puerto-tcp>/”.

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

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

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

%BACK_NAME% Valor “ATRÁS” si hay una cabecera de referente en lapetición o bien “INICIO”, si no hay ninguna.

Gestión de certificados de cliente y servidorEste apartado describe las tareas de administración y configuración necesarias paraconfigurar WebSEAL de forma que manipule certificados de cliente y servidorutilizados para la autenticación a través de SSL.

WebSEAL requiere certificados para las siguientes situaciones:v WebSEAL se identifica ante los clientes SSL con su certificado de servidorv WebSEAL se identifica ante un servidor de fondo con conexión (junction)

(configurado para la autenticación mutua) con un certificado de clientev WebSEAL consulta su base de datos de certificados raíz de CA (entidad emisora

de certificados) para validar los clientes que acceden con los certificados decliente

v WebSEAL consulta su base de datos de certificados raíz de CA (entidad emisorade certificados) para validar los servidores de fondo con conexión (junction)configurados para la autenticación mutua

WebSEAL utiliza la implementación de SSL de IBM Global Security Kit (GSKit)para configurar y administrar los certificados digitales. GSKit incluye el programade utilidad iKeyman para configurar y gestionar la base de datos de claves decertificados que contiene uno o más certificados de servidor/cliente de WebSEAL ylos certificados raíz de CA.

WebSEAL incluye los siguientes componentes en la instalación para dar soporte ala autenticación de SSL a través de los certificados digitales:v Una base de datos de claves predeterminada (pdsrv.kdb)v Una archivo stash de la base de datos de claves predeterminada (pdsrv.sth) y la

contraseña (“pdsrv”)v Varios certificados raíz de CA comunesv Un certificado autofirmado de prueba que WebSEAL puede utilizar para

identificarse en clientes SSL.


Es recomendable que solicite un certificado reconocido habitualmente de unaentidad emisora de certificados conocida para sustituir este certificado deprueba.

La configuración para la gestión de certificados de WebSEAL incluye:v “Configuración de parámetros de base de datos de claves” en la página 40v “Utilización del programa de utilidad de gestión de certificados iKeyman” en la

página 41v “Configuración de la comprobación de CRL” en la página 42

Información sobre tipos de archivo de bases de datos declaves GSKit

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

Una base de datos de claves CMS está formada por un archivo con la extensión.kdb y posiblemente otros dos o más archivos. El archivo .kdb se crea cuando secrea una nueva base de datos de claves. Un registro de clave en un archivo .kdbpuede ser un certificado o un certificado con información de clave privada cifrada.

Los archivos .rdb y .crl se crean cuando se crea una nueva petición decertificados. El archivo .rdb es necesario durante todo el proceso de la petición decertificado de CA.

Tipo dearchivo

Descripción

.kdb Archivo de “base de datos de claves”. Almacena certificados personales, peticiones de certificadospersonales y certificados de firmante. 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ña de la base de datos de claves. Elnombre del que se deriva este archivo es el mismo que el del archivo .kdb asociado.

.rdb Archivo de base de datos de “peticiones”. Se crea automáticamente cuando se crea un archivo debase de datos de claves .kdb. El nombre del que se deriva este archivo es el mismo que el delarchivo .kdb asociado. Este archivo contiene peticiones de certificado que son especiales y no se hanrecibido todavía de la CA. Cuando se devuelve un certificado de la CA, se busca la petición decertificados correspondiente en el archivo .rdb (según la clave pública). Si se encuentra alguna, serecibe el certificado y la petición de certificado se elimina del archivo .rdb. Si no se encuentra, serechaza el intento de recibir el certificado. En la petición de certificado se incluyen el nombrecomún, la organización, la dirección postal y otra información especificada en el momento de lapetición, así como la clave pública y la clave privada asociadas con la petición.

.crl Archivo de “lista de revocación de certificados”. Este archivo contiene normalmente la lista decertificados que se han revocado por 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 una representación ASCII codificada enbase 64 de un certificado, incluida la clave pública, pero no la privada. Los datos originales binariosdel certificado se transforman en una representación ASCII. Cuando un usuario recibe uncertificado en un archivo .arm, iKeyman decodifica la representación ASCII y coloca larepresentación binaria en el archivo .kdb correspondiente. De la misma forma, cuando un usuarioextrae un certificado de un archivo .kdb, iKeyman convierte los datos de binario a ASCII, y loscoloca en un archivo .arm. Los datos ASCII del archivo .arm es lo que se envía a la CA durante elproceso de petición de certificados. Nota: Se puede utilizar cualquier tipo de archivo (distinto de.arm), siempre que el archivo esté codificado en Base64.


Tipo dearchivo

Descripción

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

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

Configuración de parámetros de base de datos de clavesArchivo de claves de certificados de WebSEAL:

Durante la instalación, WebSEAL proporciona una base de datos de claves decertificados predeterminada. El parámetro webseal-cert-keyfile, ubicado en lastanza [ssl] del archivo de configuración webseald.conf, identifica el nombre y laubicación de este archivo:[ssl]webseal-cert-keyfile = /var/pdweb/www/certs/pdsrv.kdb

Puede usar el programa de utilidad iKeyman para crear una base de datos declaves nueva. Sin embargo, deberá especificar el nombre y la ubicación de esearchivo de claves nuevo en el parámetro webseal-cert-keyfile de manera queWebSEAL pueda encontrar y utilizar los certificados contenidos en esa base dedatos.

Contraseña del archivo de claves de certificados:

Durante la instalación, WebSEAL proporciona también un archivo stashpredeterminado que contiene la contraseña para el archivo de claves pdsrv.kdb. Elparámetro webseal-cert-keyfile-stash informa a WebSEAL de la ubicación delarchivo stash:webseal-cert-keyfile-stash = /var/pdweb/www/certs/pdsrv.sth

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

Durante la instalación, WebSEAL utiliza el archivo stash para obtener la contraseñade archivo de claves. El parámetro webseal-cert-keyfile-pwd está comentado. Siutiliza el archivo stash, podrá evitar que la contraseña aparezca como texto en elarchivo de configuración webseald.conf.

Nota: Elimine el comentario del parámetro de contraseña específico que deseeutilizar. Si ha especificado la contraseña y el archivo stash, se utilizará elvalor de la contraseña.

Certificado de prueba de WebSEAL:

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


Para controlar mejor la utilización de este certificado de prueba, el certificado no seinstala como certificado predeterminado. En su lugar, el parámetrowebseal-cert-keyfile-label designa al certificado como certificado de servidoractivo, prevaleciendo sobre cualquier otro certificado designado como“predeterminado” en la base de datos del archivo de claves.webseal-cert-keyfile-label = WebSEAL

Aunque este certificado de prueba permite a WebSEAL responder a una peticiónde navegador habilitado para SSL, el navegador (que no contiene ningúncertificado raíz de CA apropiado) no lo puede verificar. Debido a que la claveprivada para este certificado predeterminado está incluida en cada distribución deWebSEAL, este certificado no ofrece ninguna comunicación verdaderamentesegura.

Debe usar el programa de utilidad iKeyman para generar una petición decertificado que se pueda enviar a la CA (entidad emisora de certificados). UtiliceiKeyman para instalar y etiquetar el certificado de servidor devuelto.

Si utiliza certificados diferentes para otras situaciones (por ejemplo, paraconexiones (junction) –K), puede utilizar el programa de utilidad iKeyman paracrear, instalar y etiquetar estos certificados. La etiqueta del archivo de claves nodebe contener espacios.

WebSEAL (que se ejecuta de forma predeterminada como user ivmgr) debedisponer de permiso read (r) en esos archivos de base de datos de claves.

Comunicación SSL interna del servidor de Access Manager:

La stanza [ssl] del archivo de configuración webseald.conf contiene cuatroparámetros adicionales que se utilizan para configurar el archivo de clavesutilizado por WebSEAL para la comunicación SSL interna con otros servidores deAccess Manager. Sólo debe modificar estos parámetros mediante el script deconfiguración pdconfig.[ssl]ssl-keyfile =ssl-keyfile-pwd =ssl-keyfile-stash =ssl-keyfile-label =

Utilización del programa de utilidad de gestión de certificadosiKeyman

El programa de utilidad iKeyman es una herramienta incluida con GSKit que sepuede utilizar para gestionar los certificados digitales que utiliza WebSEAL. UtiliceiKeyman para:v Crear una o más bases de datos de clavesv Cambiar las contraseñas de la base de datos de clavesv Crear certificados de WebSEAL nuevosv Establecer un certificado WebSEAL predeterminado nuevov Crear un certificado autofirmado para realizar una pruebav Solicitar y recibir certificados raíz de CAv Agregar y eliminar certificados de la base de datosv Copiar certificados de una base de datos a otra


Configuración de la comprobación de CRLLa lista CRL (lista de revocación de certificados) es un método para evitar lavalidación de certificados no deseados. CRL contiene la identidad de certificadosque se considera que no son fiables. La implementación de SSL de GSKit queutiliza WebSEAL da soporte a la comprobación de CRL. GSKit permite a WebSEALrealizar la comprobación de CRL en certificados de cliente y certificados deconexiones (junctions) de SSL.

WebSEAL debe conocer la ubicación de esta lista para realizar la comprobación deCRL. Los parámetros para la ubicación del servidor LDAP a los que se puedehacer referencia durante la autenticación de certificados de la comprobación deCRL se encuentran en la stanza [ssl] del archivo de configuración webseald.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á inhabilitada de forma predeterminada (losparámetros están comentados). Para habilitar la comprobación de CRL durante laautenticación de certificados, elimine el comentario de cada uno de los parámetrosy especifique los valores apropiados.

Un valor vacío para ssl-ldap-user indica que el mecanismo de autenticación de SSLdebe enlazarse al servidor LDAP como usuario anónimo.

Configuración de la caché de CRLGSKit permite a WebSEAL realizar la comprobación de CRL en certificados decliente y certificados de conexiones (junctions) de SSL.Para mejorar el rendimientode la comprobación CRL, puede almacenar CRL en la caché desde una entidademisora de certificados (CA) determinada. Posteriormente se realizancomprobaciones CRL en esta versión en caché de la lista.

Los valores de los dos parámetros del archivo de configuración webseald.confdescritos en este apartado se pasan directamente al programa de utilidad GSKit.Para obtener información adicional acerca de la funcionalidad de GSKit, consulte ladocumentación de GSKit.

Definición del número máximo de entradas de cachéEl parámetro gsk-crl-cache-size especifica el número máximo de entradas en lacaché CRL de GSKit. Cada entrada representa un CRL entero para una entidademisora de certificados (CA) determinada. El valor predeterminado es “0”. Unvalor mayor que “0” es necesario para activar la caché. Cuando gsk-crl-cache-sizey gsk-crl-cache-entry-lifetime se establecen en “0” (valor predeterminado), seinhabilita el almacenamiento en caché CRL.[ssl]gsk-crl-cache-size = 0

Definición del valor de tiempo de espera de duración de la cachéde GSKitEl parámetro gsk-crl-cache-entry-lifetime especifica el valor de tiempo de esperade duración para todas las entradas de la caché CRL de GSKit. El valor se expresaen segundos y puede tener un rango de 0 a 86400 segundos. Cuandogsk-crl-cache-size y gsk-crl-cache-entry-lifetime se establecen en “0” (valorpredeterminado), se inhabilita el almacenamiento en caché CRL.


[ssl]gsk-crl-cache-size = 0

Configuración del registro HTTP predeterminadoWebSEAL mantiene tres archivos de registro HTTP convencionales que registran laactividad en vez de los mensajes:v request.log

v agent.log

v referer.log

De forma predeterminada, estos archivos de registro están ubicados en el siguientedirectorio:

UNIX:/var/pdweb/www/log/

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

Los parámetros para configurar el registro HTTP estándar se encuentran en lastanza [logging] del archivo de configuración webseald.conf.

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

Archivos de registro Parámetro de ubicaciónHabilitación/inhabilitación de pará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 archivo request.logaparece 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

Habilitación e inhabilitación del registro HTTPTodos los registros HTTP están habilitados de forma predeterminada:[logging]requests = yesreferers = yesagents = yes

Se puede habilitar o inhabilitar cada registro de forma independiente. Si algúnparámetro se establece en “no”, el registro se inhabilita para ese archivo.


Una vez habilitado tal como se ha descrito anteriormente, el registro HTTP deWebSEAL lo manipula realmente el mecanismo de registro de eventos de AccessManager, tal como se describe en “Configuración del registro HTTP mediante elregistro de eventos” en la página 46.

Especificación del tipo de indicación de la horaPuede elegir que las especificaciones de indicación de la hora se registren en GMT(Hora del meridiano de Greenwich) en lugar de hacerlo en la zona horaria local. Elvalor predeterminado es la utilización de la zona horaria local:[logging]gmt-time = no

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

Especificación de los umbrales de creación de archivo deregistro

El parámetro max-size especifica el tamaño máximo que puede alcanzar cada unode los archivos de registro HTTP y tiene el siguiente valor predeterminado (enbytes):[logging]max-size = 2000000

Cuando un archivo de registro alcanza el valor especificado (conocido comoumbral de creación), se realiza una copia de seguridad del archivo existente en unarchivo con el mismo nombre y con la indicación anexada de la fecha y la horaactuales. A continuación se inicia un archivo de registro nuevo.

Los distintos valores posibles de max-size se interpretan de la siguiente forma:v Si el valor de max-size es menor que cero (< 0), se crea un archivo de registro

nuevo con cada invocación del proceso de registro y cada 24 horas desde esainstancia.

v Si el valor de max-size es igual a cero (= 0), no se crea un nuevo registro y elarchivo de registro crece indefinidamente. Si ya existe un archivo de registro, losdatos nuevos se agregan a éste.

v Si el valor de max-size es mayor que cero (> 0), se crea un nuevo registrocuando el archivo de registro alcanza el valor de umbral configurado. Si yaexiste un archivo de registro en el inicio, los datos nuevos se agregan a éste.

Especificación de la frecuencia de vaciado de los búferes dearchivo de registro

Los archivos de registro se escriben en flujos de datos con búfer. Si supervisa losarchivos de registro en tiempo real, puede alterar la frecuencia con la cual elservidor fuerza un vaciado de los búferes del archivo de registro.

De forma predeterminada, los archivos de registro se vacían cada 20 segundos:[logging]flush-time = 20

Si especifica un valor negativo, se forzará un vaciado cada vez que se escriba unregistro.


Formato de registro común HTTP (para request.log)Cada respuesta (ya sea de éxito o error) que vuelve a enviar el servidor de AccessManager se registra con una entrada de una línea en el archivo request.logutilizando el siguiente formato de registro HTTP común:host - usuarioaut [fecha] petición estado bytes

donde:

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

usuarioaut Este campo toma el valor de la cabecera From: de la petición HTTPrecibida. El valor “unauth” se utiliza para los usuarios noautenticados.

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

petición Especifica la primera línea de la petición tal como ha llegado delcliente.

estado Especifica el código de estado HTTP enviado a la máquina querealiza la petición.

bytes Especifica el número de bytes devueltos a la máquina que realizala petición. Este valor—el tamaño de contenido sin filtrar o untamaño cero—se configura con el parámetro log-filtered-pages.

Visualización del archivo request.logEl archivo request.log realiza el registro estándar de peticiones HTTP, por ejemplola información sobre las direcciones URL que se han solicitado y la informaciónacerca del cliente (por ejemplo, la dirección IP) que ha realizado la petición.

El ejemplo siguiente muestra una versión de un archivo request_log:130.15.1.90 - - [26/Ene/2002:17:23:33 -0800] "GET /~am/a_html/ HTTP/1.0" 403 77130.15.1.90 - - [26/Ene/2002:17:23:47 -0800] ”GET /icons HTTP/1.0" 302 93130.15.1.90 - - [26/Ene/2002:17:23:59 -0800] "GET /icons/ HTTP/1.0" 403 77130.15.1.90 - - [26/Ene/2002:17:24:04 -0800] "GET /~am/a_html/ HTTP/1.0" 403 77130.15.1.90 - - [26/Ene/2002:17:24:11 -0800] "GET /~am/ HTTP/1.0" 403 77

Visualización del archivo agent.logEl archivo agent.log registra el contenido de la cabecera User_Agent: de lapetición HTTP. Este registro muestra información acerca del navegador del cliente,por ejemplo la arquitectura o número de versión, para cada petición.

El ejemplo siguiente muestra una versión de un archivo agent.log:Mozilla/4.01 [en] (WinNT; U)Mozilla/4.01 [en] (WinNT; U)Mozilla/4.01 [en] (WinNT; U)Mozilla/4.01 [en] (WinNT; U)

Visualización del archivo referer.logEl archivo referer.log registra la cabecera Referer: de la petición HTTP. Seregistra el documento que contiene el vínculo al documento solicitado de cadapetición.

El registro utiliza el siguiente formato:referente -> objeto


Esta información es útil para realizar un seguimiento de vínculos externos adocumentos del espacio web. El registro muestra que el origen indicado por elreferente contiene un vínculo a un objeto de página. Este registro le permiterealizar un seguimiento de vínculos obsoletos y ver quién crea vínculos a susdocumentos.

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

Configuración del registro HTTP mediante el registro de eventosEl registro HTTP de WebSEAL puede configurarse en la stanza[aznapi-configuration] del archivo de configuración webseald.conf utilizando elparámetro de registro de eventos logcfg para definir uno o más agentes de registro(registradores), que reúne una categoría específica de información de registro de laagrupación de eventos y dirige esta información a un destino:[aznapi-configuration]logcfg = <categoría>:{stdout|stderr|file|pipe|remote} [[<parám>[=<valor>]][,<parám>[=<valor>]]...]

Consulte el capítulo “Registro de eventos” de la publicación IBM Tivoli AccessManager Base Guía del administrador para obtener detalles completos sobre laconfiguración del registro de eventos.

Los valores de categoría que son adecuados para el registro HTTP incluyen lossiguientes:v http

Toda la información de registro HTTPv http.clf

Información de petición HTTP en formato de registro comúnv http.ref

Información de cabecera HTTP Refererv http.agent

Información de cabecera HTTP User_Agentv http.cof

El formato combinado NCSA captura información de petición HTTP (con laindicación de la hora) y agrega las cadenas de referente y agente citadas alformato de registro común estándar.

Las siguientes configuraciones de agente de registro están habilitadas cuando losparámetros de registro HTTP de WebSEAL están habilitados (consulte“Configuración del registro HTTP predeterminado” en la página 43). Tenga encuenta que las configuraciones de agente de registro aceptan los valores de losparámetros requests-file, referers-file, agents-file, flush-time y max-size de lastanza [logging] de webseald.conf:

request.log (formato de registro común):logcfg = http.clf:file path=<requests-file>,flush=<flush-time>, \rollover=<max-size>,log=clf,buffer_size=8192,queue_size=48


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

agent.log (formato de registro común):logcfg = http.agent:file path=<agents-file>,flush=<flush-time>, \rollover=<max-size>,log=agent,buffer_size=8192,queue_size=48

Dado que el registro HTTP predeterminado está configurado en una stanza distinta([logging]) que la configuración del registro de eventos ([aznapi-configuration]), esposible que haya dos entradas duplicadas para cada evento que aparezcan en unarchivo de registro cuando ambos mecanismos de registro estén habilitados.

El mecanismo de registro de eventos proporciona mucha más flexibilidadreuniendo información de registro HTTP y personalizando su salida.

Registro de mensajes de servicios de WebSEALLos mensajes de servicios de Access Manager WebSEAL están controlados por elarchivo routing de Access Manager WebSEAL. El archivo routing está ubicado enel siguiente directorio:

UNIX:/opt/pdweb/etc/

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

El archivo routing es un archivo ASCII que contiene información adicional enforma de líneas de comentarios. Las entradas de este archivo de configuracióndeterminan los tipos de mensajes de servicios que se registran. Para habilitarcualquier entrada, elimine el carácter de comentario (#). El archivo routing incluyelas siguientes entradas predeterminadas:

UNIX:FATAL:STDERR:-ERROR:STDERR:-WARNING:STDERR:-#NOTICE:FILE.10.100:/opt/pdweb/log/notice.log#NOTICE_VERBOSE:FILE.10.100:/opt/pdweb/log/notice.log

Windows:FATAL:STDERR:-ERROR:STDERR:-WARNING:STDERR:-#NOTICE:FILE.10.100:%PDWEBDIR%/log/notice.log#NOTICE_VERBOSE:FILE.10.100:%PDWEBDIR%/log/notice.log

Nota: En un sistema Windows, la variable de entorno especial PDWEBDIR sedefine durante la ejecución en el directorio de instalación de WebSEAL.

De forma predeterminada, cuando WebSEAL se ejecuta en primer plano, todos losmensajes se envían a la pantalla (STDERR).

De forma predeterminada, cuando WebSEAL se ejecuta de fondo, los mensajes seredirigen desde STDERR y se envían al archivo de registro del servidor WebSEALtal como se ha definido en la stanza [logging] del archivo de configuración


webseald.conf:

Servidor Archivo deconfiguración

Ubicación del archivo de registro

Servidor WebSEAL(webseald)

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

Para habilitar verbose.log, descomente de la línea NOTICE_VERBOSE.

La sintaxis FILE del mensaje NOTICE controla la creación de nuevos archivos deregistro y el reciclado de archivos:FILE.<máx-archivos>.<máx-registros>

El valor de máx-archivos especifica el número de archivos que se utiliza.

El valor de máx-registros especifica el número máximo de entradas por archivo.

En el ejemplo predeterminado anterior, FILE.10.100 significa que se han creado 10archivos, cada uno de ellos con un máximo de 100 entradas. Los archivos sedenominan:notice.log.1notice.log.2...notice.log.10

Los mensajes se “reinician” en el primer archivo después de que el último archivohaya alcanzado su límite o cuando el servidor se detenga y se reinicie. Cuando sevuelve a utilizar un archivo de registro, se sobrescriben (borran) los registrosexistentes.


Capítulo 3. Configuración avanzada del servidor

Este capítulo contiene información que describe las tareas generales deconfiguración y administración que se pueden llevar a cabo para personalizar elservidor WebSEAL para la red.

Índice de temas:v “Configuración de la calidad predeterminada de nivel de protección” en la

página 49v “Configuración de actualizaciones y sondeo de la base de datos de

autorizaciones” en la página 51v “Gestión de la asignación de threads de trabajo” en la página 52v “Réplica de servidores WebSEAL frontales” en la página 55v “Configuración de múltiples instancias de servidor WebSEAL” en la página 56v “Configuración del cambio de usuario (SU) para administradores” en la página

62v “Configuración del almacenamiento en la caché de peticiones del servidor

WebSEAL” en la página 70v “Gestión de los caracteres codificados UTF-8” en la página 73v “Prevención de la vulnerabilidad causada por scripts de sitios cruzados” en la

página 75v “Supresión de la identidad del servidor” en la página 76v “Utilización de las estadísticas de WebSEAL” en la página 77v “Utilización del programa de utilidad de rastreo para capturar acciones de

WebSEAL” en la página 86

Configuración de la calidad predeterminada de nivel de protecciónPara controlar el nivel predeterminado de cifrado necesario para acceder aWebSEAL a través de SSL (HTTPS), configure la calidad de protección (QOP). Lagestión de calidad de protección predeterminada se controla utilizando losparámetros de la sección “GESTIÓN DE LA CALIDAD DE PROTECCIÓN SSL”del archivo de configuración webseald.conf.v Puede habilitar e inhabilitar la gestión de QOP con el parámetro ssl-qop-mgmt

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

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

2. Especifique el nivel de cifrado predeterminado para el acceso HTTPS:[ssl-qop-mgmt-default]# default = ALL | NONE | <nivel-cifrado># ALL (habilita todos los cifrados)# NONE (inhabilita 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 grupo seleccionado decifrados:[ssl-qop-mgmt-default]default = RC4-128default = RC2-128default = DES-168

Configuración de QOP para redes y hosts individualesEl parámetro ssl-qop-mgmt = yes también habilita los valores que aparecen en lasstanzas [ssl-qop-mgmt-hosts] y [ssl-qop-mgmt-networks]. Estas stanzas permitenla gestión de la calidad 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 cifrados utilizados paratodas las direcciones IP que no encuentran correspondencia 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 (habilita todos los cifrados)# NONE (inhabilita 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 (habilita todos los cifrados)# NONE (inhabilita 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/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] se proporcionan sóloa efectos de compatibilidad con versiones anteriores. Es recomendable que no lasutilice para llevar a cabo la configuración de Access Manager.


Configuración de actualizaciones y sondeo de la base de datos deautorizaciones

Access Manager Policy Server (pdmgrd) gestiona la base de datos maestra depolíticas de autorización y mantiene la información de ubicación acerca de otrosservidores de Access Manager en el dominio seguro. Un administrador de AccessManager puede realizar cambios de política de seguridad en el dominio seguro encualquier momento. Policy Server realiza los ajustes necesarios en la base de datosmaestra de autorizaciones siempre que se implementan cambios en la política deseguridad.

Cuando Policy Server realiza un cambio en la base de datos maestra deautorizaciones, puede enviar una notificación de este cambio a todas las bases dedatos replicadas del dominio seguro que dan soporte a los aplicadores de políticasindividuales (por ejemplo, WebSEAL). Los aplicadores de políticas deben solicitar acontinuación una actualización de la base de datos desde la base de datos maestrade autorizaciones.

WebSEAL, como gestor de recursos y aplicador de políticas, tiene tres opcionespara obtener información acerca de los cambios en la base de datos deautorizaciones:v Escuchar las notificaciones de actualizaciones de Policy Server (configurable y

habilitado de forma predeterminada).v Comprobar (sondear) la base de datos maestra de autorizaciones a intervalos

regulares (configurable e inhabilitado de forma predeterminada).v Habilitar la escucha y el sondeo.

La stanza [aznapi-configuration] del archivo de configuración webseald.confcontiene parámetros para configurar el sondeo de la base de datos y la escucha denotificaciones de actualizaciones.

La ruta de acceso de la base de datos de políticas de autorizaciones replicada localde WebSEAL está definida por el parámetro db-file:[aznapi-configuration]db-file = /var/pdweb/db/webseald.db

Configuración de la escucha de notificaciones deactualizaciones

El parámetro listen-flags habilita e inhabilita la escucha de notificaciones deactualizaciones de WebSEAL. La escucha está habilitada de forma predeterminada.Para inhabilitar la escucha, escriba “disable”.[aznapi-configuration]listen-flags = enable

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

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

Capítulo 3. Configuración avanzada del servidor 51

Configuración del sondeo de la base de datos deautorizaciones

Puede configurar WebSEAL para que sondee regularmente la base de datosmaestra de autorizaciones para obtener información de actualizaciones. Elparámetro cache-refresh-interval se puede establecer en “default”, “disable” o unintervalo de tiempo específico en segundos. El valor “default” es igual a 600segundos. El sondeo está inhabilitado de forma predeterminada.[aznapi-configuration]cache-refresh-interval = disable

Gestión de la asignación de threads de trabajov “Configuración de threads de trabajo de WebSEAL” en la página 52v “Asignación de threads de trabajo para conexiones (junctions) (imparcialidad de

conexiones)” en la página 53

Configuración de threads de trabajo de WebSEALEl número de threads de trabajo configurados especifica el número de peticionesentrantes simultáneas a las que puede dar servicio un servidor. Las conexiones quelleguen cuando todos los threads de trabajo estén ocupados se colocarán en elbúfer hasta que haya un thread de trabajo disponible.

Puede establecer el número de threads disponibles para dar servicio a lasconexiones de entrada de WebSEAL. La configuración del número de threads detrabajo se debe realizar con cuidado debido a posibles impactos en el rendimiento.

Este parámetro de configuración no impone un límite máximo en el número deconexiones simultáneas. Este parámetro simplemente especifica el número dethreads disponibles para dar servicio a una cola de trabajo potencialmenteilimitada.

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

Al aumentar el número de threads, se suele disminuir el tiempo medio que setarda en finalizar las peticiones. Sin embargo, el aumento del número de threadstiene un impacto en otros factores que pueden tener un efecto negativo en elrendimiento del servidor.

WebSEAL mantiene una sola agrupación de threads de trabajo y de lista de trabajogenérica para gestionar las peticiones de clientes que utilizan TCP o SSL. Estemecanismo mejorado posibilita el consumo de menos recursos del sistema porparte de WebSEAL, mientras que permite gestionar una carga significativamentemayor.

Puede configurar el tamaño de la agrupación de threads de trabajo mediante elparámetro worker-threads de la parte de stanza [server] del archivo deconfiguración webseald.conf.[server]worker-threads = 50

Nota: Es muy recomendable que este parámetro sólo se modifique para solucionarproblemas de rendimiento.


Asignación de threads de trabajo para conexiones (junctions)(imparcialidad de conexiones)

Se puede configurar la asignación de los threads de trabajo de WebSEAL que seutilizan para procesar peticiones entre varias conexiones (junctions) de maneraglobal o previa a la conexión. El mecanismo de configuración mantiene unadistribución “imparcial” de threads de trabajo en todas las conexiones (junctions) yevita que una sola conexión vacíe la agrupación de threads de trabajo.

ContextoWebSEAL extrae de su agrupación de threads de trabajo para procesar múltiplespeticiones. El número de threads de trabajo disponibles en WebSEAL se especificacon el parámetro worker-threads del archivo de configuración webseald.conf.

Puede ajustar el valor de worker-threads para servir mejor a su implementaciónespecífica de WebSEAL. Cuando no hay threads de trabajo disponibles paramanejar las peticiones entrantes, los usuarios experimentan que un servidorWebSEAL no responde.

Los threads de trabajo se utilizan para manejar las peticiones entrantes en lasaplicaciones que residen en múltiples servidores de programas de fondo conconexión (junction). Sin embargo, la agrupación de threads de trabajo se puedevaciar rápidamente si una aplicación de programa de fondo determinada esespecialmente lenta al responder a un alto volumen de peticiones y procesarlas. Elvaciado de la agrupación de threads de trabajo por esta aplicación hace queWebSEAL no pueda responder a peticiones de servicios en los servidores deaplicaciones con conexión (junction) restantes.

Puede configurar límites globales o por conexión (junction) basados en el númerode los threads de trabajo utilizadas para las aplicaciones de servicio en múltiplesconexiones. Estos límites permiten que prevalezca la “imparcialidad” para todas lasconexiones (junctions) e impiden que una aplicación cualquiera pueda reclamarmás threads de trabajo que los que le corresponden.

Asignación global de threads de trabajo para conexiones(junctions)Dos parámetros ubicados en la stanza [junction] del archivo de configuraciónwebseald.conf controlan la asignación global de threads de trabajo entre todas lasconexiones (junctions) correspondientes a un servidor WebSEAL determinado. Losvalores utilizados para estos parámetros se expresan como porcentajes dentro delrango de 0 a 100. El valor por omisión 100 (%) indica que no hay ningún límite.v worker-thread-soft-limit

Este parámetro sirve para actuar como aviso antes de que se alcance el límite“fijo”. Cuando se sobrepasa el valor de worker-thread-soft-limit, se envíanmensajes de aviso (cada 30 segundos) al archivo de registro de errores deWebSEAL.Por ejemplo, cuando worker-threads=50, el valor 60 (%) hace que se emitanmensajes de aviso si la conexión (junction) consume más de 30 threads detrabajo. Todas las peticiones que sobrepasen los 30 threads de trabajo se siguenprocesando hasta que se alcanza el límite “fijo”.

v worker-thread-hard-limit

Este parámetro actúa como punto de interrupción para dar servicio a peticionesen una conexión (junction). Cuando se sobrepasa el valor de


worker-thread-hard-limit, se envían mensajes de error (cada 30 segundos) alarchivo de registro de errores de WebSEAL. Además, se envía al usuario unmensaje 503 “Servicio no disponible”.Por ejemplo, cuando worker-threads=50, el valor 80 (%) hace que se emitanmensajes de error si la conexión (junction) consume más de 40 threads detrabajo. Todas las peticiones que representan más de 40 threads de trabajo en laconexión (junction) se devuelven con un mensaje 503 “Servicio no disponible”.

Estos valores globales se aplican por igual a todas las conexiones (junctions)configuradas. Cuando se configuran estos dos parámetros, es lógico que seestablezca el límite “dinámico” en un valor inferior al límite “fijo”.

Asignación por conexión (junction) de threads de trabajo paraconexionesComo alternativa, puede limitar el consumo de threads de trabajo en base a laasignación por conexión (junction). Las siguientes opciones del comando pdadminserver task create permiten al usuario especificar los límites de trabajo fijos ydinámicos en una conexión (junction) específica:v –l <valor-porcentaje>

Esta opción establece un valor (porcentaje) en la conexión (junction) que defineel límite dinámico para el consumo de threads de trabajo. Como sucede con elvalor del límite dinámico global, esta opción hace que se emitan mensajes deaviso cuando la conexión (junction) consume más threads de trabajo de lospermitidos por ese valor.

v –L <valor-porcentaje>Esta opción establece un valor (porcentaje) en la conexión (junction) que defineel límite fijo para el consumo de threads de trabajo. Como sucede con el valordel límite físico global, esta opción hace que se emitan mensajes de aviso cuandola conexión (junction) intenta consumir más threads de trabajo de los permitidospor ese valor. Además, se envía al usuario un mensaje 503 “Servicio nodisponible”.

Por ejemplo:pdadmin> server taskwebseald-<nombre-servidor> create -t tcp-h <nombre-host> \-l 60 -L 80 <punto-conex(jct)>

Los valores por conexión (junction) siempre prevalecen sobre los valores globalesdel archivo webseald.conf. Unos valores inadecuados en una conexión (junction)específica podrían afectar negativamente a la política establecida por los valoresglobales.

Notas para la resolución de problemasv Puede utilizar el comando pdadmin server task show para ver el número de

threads de trabajo activas que hay en una conexión (junction) específica:pdadmin> server taskwebseald-<nombre-servidor> show/<punto-conex(jct)>

Esta información podría ser útil cuando se desea determinar la ubicación de unaconexión (junction) que absorbe más recursos de thread de trabajo de los que lecorresponden.

v Si especifica un valor de límite dinámico que sea mayor que el valor de límitefijo en una conexión (junction) específica, esta conexión no se creará.


v Debe especificar los valores del límite tanto fijo como dinámico (las opciones –ly –L) en una conexión (junction) específica.

Réplica de servidores WebSEAL frontales

Nota: La información siguiente sustituye al comando pdadmin server modifybaseurl que se utilizaba en versiones anteriores de Access Manager.

En un entorno con una gran carga, la réplica de servidores WebSEAL frontalesresulta útil para proporcionar un mejor equilibrio de carga y la posibilidad demigración tras error. Al replicar servidores WebSEAL frontales, cada servidor debecontener una copia exacta del espacio web, la base de datos de conexiones(junctions) y la base de datos dynurl.

Esta versión de Access Manager da soporte a un procedimiento de configuraciónmanual para replicar servidores WebSEAL frontales. El comando pdadmin ya no seutiliza para esta tarea.

En el siguiente ejemplo, “WS1” es el nombre de host del servidor WebSEALprincipal. “WS2” es el nombre de host del servidor WebSEAL 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ámetro server-name en el archivo de

configuración webseald.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 en las evaluacionesde autorizaciones. El servidor WS2 también puede responder a los comandosobject list y object show para los objetos que residen en /WebSEAL/WS1.

El programa de utilidad pdadmin continúa mostrando el objeto /WebSEAL/WS2como parte del espacio de objetos. Este objeto ahora no es significativo y se puedeeliminar.pdadmin> object delete /WebSEAL/WS2

Condiciones:v Gestión del espacio de objetos unificado: Aunque el administrador puede ver

una única jerarquía de objetos, todos los servidores WebSEAL están afectadospor los comandos de administración aplicados a esa jerarquía de objetos, y todoslos servidores pueden responder a esos comandos.

v Evaluaciones de autorizaciones unificadas: Si el servidor WS2 se configura comoservidor replicado de WS1, el servidor WS2 utiliza /WebSEAL/WS1 como base paralas evaluaciones de autorizaciones.

v Configuración unificada: Para que la réplica de servidores WebSEAL frontalesfuncione correctamente, la configuración del espacio web, la base de datos deconexiones (junction) y la base de datos dynurl debe ser idéntica en cadaservidor.


Configuración de múltiples instancias de servidor WebSEALAccess Manager proporciona la posibilidad de configurar múltiples instancias delservidor WebSEAL en una sola máquina.

Visión general de la configuraciónA fines de la configuración, una instancia de un servidor WebSEAL se definemediante una combinación exclusiva de interfaz de red (dirección IP) y número depuerto.

Se pueden configurar múltiples instancias de WebSEAL mediante uno de losmétodos siguientes para crear combinaciones exclusivas de interfaz de red:puerto:v Utilice una sola interfaz de red (dirección IP) y asigne instancias de WebSEAL a

puertos de escucha HTTP/HTTPS exclusivosv Asigne instancias de WebSEAL a interfaces de red exclusivas (tarjetas de interfaz

de red física o alias de red lógica) y utilice los puertos de escucha HTTP/HTTPScomunes

Nota: En ambos escenarios, el valor del puerto entre servidores especificado por laopción –m debe ser exclusivo para todas las instancias de WebSEAL.

Cada instancia configurada de WebSEAL tiene un nombre exclusivo, un número depuerto interno exclusivo (para la comunicación entre servidores de AccessManager), una ubicación de directorio exclusiva y un archivo de configuraciónexclusivo. Múltiples archivos de configuración se convierten en exclusivos con elnombre de instancia del servidor, al que se agrega el prefijo webseald-. Porejemplo:/opt/pdweb/etc/webseald-<nombre-instancia>.conf

Las herramientas de configuración necesarias para configurar y eliminar laconfiguración de múltiples instancias de servidor WebSEAL son, entre otras:v Sistemas UNIX:

Programa de utilidad de línea de comandos PDWeb_config

Programa de utilidad de línea de comandos PDWeb_unconfig

Nota: El programa de utilidad pdconfig puede utilizarse para crear la instanciainicial de WebSEAL. La línea de comandos PDWeb_config debe utilizarsepara crear todas las instancias adicionales. En este análisis de múltiplesinstancias se supone que el usuario ha configurado un servidor WebSEALinicial.

v Sistemas Windows:Programa de utilidad de línea de comandos ivweb_setup

Programa de utilidad de línea de comandos ivweb_uninst

Configuración de múltiples instancias de WebSEAL en UNIXEl programa de utilidad PDWeb_config se encuentra en el siguiente directorio:/opt/pdweb/sbin/

Sintaxis de PDWeb_config:# ./PDWeb_config –i<nombre-instancia> –m<puerto-interno> [–n<interfaz-red>]


Argumento Descripción

nombre-instancia Nombre exclusivo para esta instancia. Debe utilizar estenombre para eliminar la configuración de la instancia. Lalongitud de este nombre está limitada a 20 caracteres.

puerto-interno Número de puerto exclusivo para la comunicación entreservidores Access Manager. El valor debe ser mayor que1023. (Los valores menores o iguales que 1023 estánreservados.)

interfaz-red Argumento opcional para especificar la dirección IP deuna interfaz de red.

Nota: El valor del puerto entre servidores especificado por la opción –m debe serexclusivo para todas las instancias de WebSEAL.

Configuración de múltiples instancias en puertos HTTP/HTTPS exclusivos:

1. Suposición: la máquina está configurada con un servidor WebSEAL inicial(pdconfig) y una sola tarjeta de red/dirección IP (por ejemplo: 1.2.3.4).

2. Cambie la ubicación de directorio:# cd /opt/pdweb/sbin

3. Ejecute el comando PDWeb_config para crear y configurar una instanciaadicional de WebSEAL.En este escenario, múltiples instancias de servidor se convierten en exclusivasmediante designaciones exclusivas de puerto entre servidores y de puerto deescucha HTTP/HTTPS en la interfaz de red predeterminada. Por consiguiente,no utilice la opción –n para especificar una interfaz de red. Por ejemplo:# ./PDWeb_config –i webseal2 –m 3232

4. Aparece la pantalla de configuración:Compruebe la configuración del servidor web:1. ¿Habilitar TCP HTTP? Sí2. Puerto HTTP 803. ¿Habilitar HTTPS? Sí4. Puerto HTTPS 4435. Directorio raíz de documentos web /opt/pdweb/www-webseal2/docsa. Aceptar la configuración y continuar la instalaciónx. Salir de la instalaciónSeleccione el elemento que desea modificar:

5. De forma predeterminada, el servidor WebSEAL inicial escucha las peticionesen *:80 y *:443. Seleccione los elementos de menú de los puertos HTTP yHTTPS y proporcione valores exclusivos de puerto que no utilice ningún otroservidor (por ejemplo, 81 y 444).

Nota: Aparece un mensaje de aviso si selecciona un valor de puerto que ya seestá utilizando. Se le da la oportunidad de seleccionar un valor distinto.

6. Ejecute el comando PDWeb_config para crear y configurar cualquier instanciaadicional del servidor WebSEAL (con los puertos entre servidores exclusivos).Por ejemplo:# ./PDWeb_config –i webseal3 –m 3233

7. Desde la pantalla de configuración, configure unos valores exclusivos para lospuertos HTTP y HTTPS.

Nota: El número máximo de instancias permitidas de WebSEAL está regido porlas limitaciones de la configuración del sistema, como la RAM y el


espacio de disco disponibles. Si se excede cualquier recurso del sistema,aparecerán mensajes de error de configuración y de anomalía dearranque.

Configuración de múltiples instancias en interfaces exclusivas de red lógica:

1. Suposición: la máquina está configurada con un servidor WebSEAL inicial(pdconfig) y una sola tarjeta de red/dirección IP.

2. De forma predeterminada, el servidor WebSEAL inicial escucha las peticionesen *:80 y *:443. Debe asignar una dirección IP específica para esta interfaz dered inicial antes de que pueda configurar y ejecutar servidores WebSEALadicionales.

Nota: No se pueden iniciar servidores WebSEAL adicionales si el servidorWebSEAL inicial escucha en *:80 y *:443.

3. Edite el archivo de configuración webseald.conf y especifique la dirección IPadecuada para el servidor WebSEAL inicial agregando el parámetronetwork-interface a la stanza [server]. Por ejemplo:[server]network-interface = 1.2.3.4

4. Reinicie el servidor WebSEAL:# /opt/pdweb/bin/pdweb restart

5. Para cada instancia adicional del servidor WebSEAL, configure una interfaz dered lógica adicional (alias). Por ejemplo (en la versión 2.8 de Solaris):# ifconfig hme0 addif 1.2.3.5 netmask w.x.y.z up# ifconfig hme0 addif 1.2.3.6 netmask w.x.y.z up

Nota: Como alternativa, puede asignar cada instancia de WebSEAL a unatarjeta de red física preconfigurada exclusiva.


7. Ejecute el comando PDWeb_config para crear y configurar una instanciaadicional de WebSEAL.En este escenario, múltiples instancias de servidor se convierten en exclusivasmediante una interfaz de red exclusiva en puertos de escucha entre servidoresy HTTP/HTTPS comunes. Por consiguiente, debe utilizar la opción –n. Porejemplo:# ./PDWeb_config –i webseal2 –m 3232 –n 1.2.3.5

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

HP-UX utiliza el nombre de interfaz de red en lugar de la dirección IP. Elprograma de utilidad PDWeb_config comprueba si la interfaz tiene unadirección IP válida.

8. Aparece la pantalla de configuración:Compruebe la configuración del servidor web:1. ¿Habilitar TCP HTTP? Sí2. Puerto HTTP 803. ¿Habilitar HTTPS? Sí4. Puerto HTTPS 4435. Directorio raíz de documentos web /opt/pdweb/www-webseal2/docsa. Aceptar la configuración y continuar la instalaciónx. Salir de la instalaciónSeleccione el elemento que desea modificar:


9. Acepte los valores de puerto HTTP y HTTPS estándar tal como están listados.10. Ejecute el comando PDWeb_config para crear y configurar instancias

adicionales de servidor WebSEAL. Por ejemplo:# ./PDWeb_config –i webseal3 –m 3233 -n 1.2.3.6

HP-UX (nombre de interfaz de red = lan0:2):# ./PDWeb_config –i webseal3 –m 3232 –n lan0:2

11. Desde la pantalla de configuración, acepte los valores de puerto HTTP yHTTPS estándar tal como están listados.

Nota: El número máximo de instancias permitidas de WebSEAL está regido por laslimitaciones de la configuración del sistema, como la RAM y el espacio dedisco disponibles. Si se excede cualquier recurso del sistema, apareceránmensajes de error de configuración y de anomalía de arranque.

Configuración de múltiples instancias de WebSEAL en WinNT/2000

Suposiciones:v Se ha configurado la instancia del servidor WebSEAL inicialv Los procedimientos descritos son adecuados para una plataforma Windows

NT/2000

Sintaxis de ivweb_setup:MSDOS> ivweb_setup -m <contraseña-pdadmin> -i <nombre-instancia> \-M <puerto-interno> -u {yes|no} -r <puerto-http> -U {yes|no} \-R <puerto-https> [-n <interfaz-red>]

Opción y argumento Descripción

–m <contraseña-pdadmin> Contraseña de administración.

–i <nombre-instancia> Nombre exclusivo para esta instancia. Debe utilizar estenombre para eliminar la configuración de la instancia. Lalongitud de este nombre está limitada a 20 caracteres.

–M <puerto-interno> Número de puerto exclusivo para la comunicación entreservidores Access Manager. El valor debe ser mayor que1023. (Los valores menores o iguales que 1023 estánreservados.)

–u {yes|no} Habilitar/inhabilitar el acceso HTTP.

–r <puerto-http> Número de puerto para el acceso HTTP.

–U {yes|no} Habilitar/inhabilitar el acceso HTTPS.

–R <puerto-https> Número de puerto para el acceso HTTPS.

–n <interfaz-red> Argumento opcional para especificar la dirección IP deuna interfaz de red.

Nota: El valor del puerto entre servidores especificado por la opción –M debe serexclusivo para todas las instancias de WebSEAL.

Configuración de múltiples instancias en puertos HTTP/HTTPS exclusivos:

1. Suposición: Windows está configurado con un servidor WebSEAL inicial(pdconfig) y una tarjeta de red física/dirección IP (para este ejemplo: 1.2.3.4).

2. Cambie la ubicación de directorio:


MSDOS> cd C:\Archivos de programa\Tivoli\Policy Director\PDWeb\bin

3. Ejecute el comando ivweb_setup para crear y configurar una instanciaadicional de WebSEAL.En este escenario, múltiples instancias de servidor se convierten en exclusivasmediante designaciones exclusivas de puerto entre servidores y de escuchaHTTP/HTTPS en una interfaz de red común. Por consiguiente, no utilice laopción –n para especificar interfaces de red adicionales. Por ejemplo:MSDOS> ivweb_setup -m xxxxx –i webseal2 –M 3232 -u yes -r 81 -U yes -R 444

Nota: Aparece un mensaje de aviso si selecciona un valor de puerto que ya seestá utilizando. Se le da la oportunidad de seleccionar un valor distinto.

4. Ejecute el comando ivweb_setup para crear y configurar instancias adicionalesde servidor WebSEAL. Por ejemplo:MSDOS> ivweb_setup -m xxxxx –i webseal3 –M 3233 -u yes -r 82 -U yes -R 445

Configuración de múltiples instancias en interfaces exclusivas de red lógica:

1. Suposición: Windows está configurado con un servidor WebSEAL inicial y unasola tarjeta de red/dirección IP.

2. De forma predeterminada, el servidor WebSEAL inicial escucha las peticionesen *:80 y *:443. Debe asignar una dirección IP específica para esta interfaz dered inicial antes de que pueda configurar y ejecutar servidores WebSEALadicionales.

Nota: No se pueden iniciar servidores WebSEAL adicionales si el servidorWebSEAL inicial escucha en *:80 y *:443.

3. Edite el archivo de configuración webseald.conf y especifique la dirección IPadecuada para el servidor WebSEAL inicial agregando el parámetronetwork-interface a la stanza [server]. Por ejemplo:[server]network-interface = 1.2.3.4

4. Reinicie el servidor WebSEAL en Servicios del Panel de control.5. Para cada instancia adicional del servidor WebSEAL, configure una interfaz de

red lógica adicional (alias) utilizando Conexiones de red del Panel de control.Por ejemplo (en Windows 2000):a. Panel de control > Conexiones de redb. Haga clic con el botón derecho en Conexiones de área local y seleccione

Propiedades.c. Seleccione Protocolo Internet (TCP/IP).d. Haga clic en Propiedades y seleccione Avanzadas.e. En la ficha Configuración de IP, haga clic en Agregar.f. Entre una dirección IP para la nueva interfaz de red.g. Entre una máscara de subred.h. Haga clic en Agregar.i. Abra una ventana de indicador de comandos y entre:

MSDOS> ipconfig -all

Todas las interfaces de red deben aparecer en estado de escucha.j. Repita estos pasos para las interfaces de red adicionales.

6. Cambie la ubicación de directorio:MSDOS> cd C:\Archivos de programa\Tivoli\PDWeb\bin


7. Ejecute el comando ivweb_setup para crear y configurar una instanciaadicional de WebSEAL.En este escenario, múltiples instancias de servidor se convierten en exclusivasmediante una interfaz de red exclusiva en puertos de escucha entre servidoresy HTTP/HTTPS comunes. Por consiguiente, debe utilizar la opción –n. Porejemplo:MSDOS> ivweb_setup -m xxxxx –i webseal2 –M 3232 -u yes -r 80 -U yes \-R 443 -n 1.2.3.5

8. Ejecute el comando ivweb_setup para crear y configurar instancias adicionalesde servidor WebSEAL. Por ejemplo:MSDOS> ivweb_setup -m xxxxx –i webseal3 –M 3233 -u yes -r 80 -U yes \-R 443 -n 1.2.3.6

Desconfiguración de múltiples instancias de WebSEALNo se puede desconfigurar el servidor WebSEAL inicial hasta que se hayandesconfigurado primero todas las instancias del servidor.

UNIX:PDWeb_unconfig -i <nombre-instancia>


2. Ejecute el comando PDWeb_unconfig para cada instancia. Por ejemplo:# ./PDWeb_unconfig -i webseal2# ./PDWeb_unconfig -i webseal3

Windows:ivweb_uninst -deconfig -m <contraseña-pdadmin> -i <nombre-instancia>

1. Cambie la ubicación de directorio:MSDOS> cd C:\Archivos de programa\Tivoli\PDWeb\bin

2. Ejecute el comando ivweb_uninst para cada instancia. Por ejemplo:MSDOS> ivweb_uninst -deconfig -m xxxxxx -i webseal2MSDOS> ivweb_uninst -deconfig -m xxxxxx -i webseal3

Comandos de inicio, detención, reinicio y estado del servidorUNIX:

El programa de utilidad pdweb proporciona la posibilidad de efectuar un inicio,detención, reinicio y estado del servidor WebSEAL inicial y un número cualquierade múltiples instancias de servidor. También puede aplicar un comando a unainstancia específica del servidor.pdweb {start|stop|restart|status} [<nombre-instancia>]

Ejemplos:

Iniciar el servidor WebSEAL inicial y todas las instancias de servidor configuradas:# /usr/bin/pdweb start

Iniciar únicamente una instancia específica de servidor:# /usr/bin/pdweb start webseal3

Reiniciar el servidor WebSEAL inicial y todas las instancias de servidorconfiguradas:


# /usr/bin/pdweb restart

Detener el servidor WebSEAL inicial y todas las instancias de servidorconfiguradas:# /usr/bin/pdweb stop

Detener únicamente una instancia específica de servidor:# /usr/bin/pdweb stop webseal3

Mostrar el estado de todos los servidores configurados:# /opt/PolicyDirector/bin/pd_start statusServidores de Access ManagerServidor Activado En ejec.------------------------------------------pdmgrd sí sípdacld sí síwebseald sí síwebseald-webseal2 sí síwebseald-webseal3 sí sí

Windows:

Servicios del Panel de control de Windows proporciona información de inicio,detención y estado del servidor.

Como alternativa, el comando net proporciona la posibilidad de efectuar un inicioy detención del servidor WebSEAL inicial y un número cualquiera de múltiplesinstancias de servidor.net {start|stop} <nombre-instancia>

Ejemplos:

Iniciar el servidor WebSEAL inicial y todas las instancias de servidor configuradas(debe repetir el comando para cada instancia):MSDOS> net start websealdMSDOS> net start webseal2MSDOS> net start webseal3

Detener el servidor WebSEAL inicial y todas las instancias de servidorconfiguradas (debe repetir el comando para cada instancia):MSDOS> net stop websealdMSDOS> net stop webseal2MSDOS> net stop webseal3

Mostrar el estado de todos los servidores configurados:Inicio > Configuración > Panel de control > Servicios

Configuración del cambio de usuario (SU) para administradoresLas funciones de cambio de usuario de WebSEAL permite a los administradoresespecíficos asumir la identidad de un usuario que sea miembro del dominio segurode Access Manager. La implementación del cambio de usuario es similar alcomando su en los entornos UNIX. En el entorno WebSEAL, el administradoradquiere las credenciales verdaderas del usuario e interactúa con recursos yaplicaciones de fondo exactamente con las mismas capacidades que el usuario real.


El cambio de usuario se puede utilizar en un entorno de Panel de ayuda pararesolver y diagnosticar los problemas. El cambio de usuario también puedeutilizarse para probar el acceso de un usuario a los recursos y realizar la prueba deintegración de aplicaciones.

Los elementos siguientes resaltan las características importantes del cambio deusuario:v El cambio de usuario no requiere una contraseña del usuario.v El administrador utiliza una credencial que representa al usuario real.v El cambio de usuario está restringido a los miembros de un grupo especial del

administrador. Un administrador no puede cambiar el usuario a ningún otromiembro de este grupo.

v Los procesos de Access Manager, sec_master, y otros usuarios seleccionadospueden excluirse de las posibilidades de cambio de usuario mediante lapertenencia a un grupo de exclusión.

v Se utiliza un formulario HTML especial para proporcionar información decambio de usuario y activar un mecanismo de autenticación especial quedevuelve la credencial del usuario especificado sin requerir una contraseña.

v El administrador utiliza el programa de utilidad pkmslogout para finalizar unasesión de cambio de usuario.

Información sobre el flujo de proceso de cambio de usuarioLa secuencia siguiente describe el flujo de proceso de cambio de usuario:

1. Suposiciones: El administrador (miembro del grupo su-admins) estáautenticado en WebSEAL, se ha establecido una sesión y se ha creado unaentrada para el administrador en la caché de sesión/credenciales deWebSEAL.

2. El administrador conecta con un formulario HTML preconfigurado de cambiode usuario. Este formulario sólo está disponible para los miembros del gruposu-admins.

3. El formulario de cambio de usuario se completa y se devuelve con lasiguiente información: nombre de usuario (el administrador “cambia” a esteusuario), una dirección URL de destino y un método de autenticación.Esta acción da como resultado que se envíe una petición POST a/pkmssu.form.

4. Una autenticación especial de cambio de usuario se realiza mediante labiblioteca compartida de cambio de usuario incorporada o una bibliotecaCDAS personalizada de cambio de usuario. La biblioteca de cambio deusuario (sea personalizada o incorporada) devuelve una credencial válida parael usuario sin que necesite la contraseña del usuario para efectuar la entrada.

5. Durante la autenticación del cambio de usuario, WebSEAL comprueba losgrupos su-admins, securitygroup y su-excluded de Access Manager paraasegurarse de que el nombre de usuario proporcionado en el formulario decambio de usuario no sea miembro de uno de estos grupos.

6. Tras la autenticación correcta del usuario designado, se crea una nuevaestructura de datos de caché que contiene la credencial del usuario.

7. Los datos originales de caché del administrador se eliminan de la entrada decaché de sesión WebSEAL del administrador y se almacenan en una ubicacióndistinta. Los datos de la caché de usuario ocupan su lugar. La entrada decaché contiene ahora el ID de sesión original del administrador y los datos decaché del usuario (con la credencial). La credencial contiene también un nuevoID de sesión de usuario que puede utilizarse para cualquier situación de


gestión de sesiones de usuario. La entrada de caché de sesión se indexa con elmismo ID de sesión utilizado por el administrador antes de la operación decambio de usuario.

8. WebSEAL envía una redirección al navegador para la dirección URL dedestino proporcionada en el formulario de cambio de usuario.

9. La petición se procesa normalmente, utilizando la credencial del usuario, y seaccede a la dirección URL. El administrador puede continuar haciendo otraspeticiones. Todas las decisiones de autorización para estas peticiones se basanen la credencial del usuario.

10. El administrador finaliza la sesión de cambio de usuario utilizando elprograma de utilidad /pkmslogout estándar de Access Manager.

11. Tras un fin de sesión correcto, los datos de la caché del usuario se suprimen ylos datos de caché originales del administrador (y la credencial) se restauran.El administrador se devuelve a la página original desde la que se ha solicitadoel formulario de cambio de usuario. El servicio de autorizaciones utiliza lacredencial original del administrador para todas las peticiones posteriores.

Habilitación del cambio de usuario: ResumenPara habilitar la funcionalidad de cambio de usuario:1. Descomente de los mecanismos de autenticación adecuados en webseald.conf y

agregue la ruta de acceso de la biblioteca compartida que maneja la operaciónde cambio de usuario.

2. Utilice el programa de utilidad pdadmin para agregar administradores a lacuenta de grupo su-admins.

3. Utilice el programa de utilidad pdadmin para agregar usuarios a la cuenta degrupo su-excluded.

4. Opcionalmente, modifique el formulario switchuser.html para especificar losdatos preconfigurados, como el método de autenticación y la dirección URL dedestino.

5. Opcionalmente, diseñe otros formularios para validar o procesar los datos quese han de someter a /pkmssu.form.

Figura 15. Intercambio de los datos de caché de administrador y de usuario durante elcambio de usuario


Configuración del formulario HTML de cambio de usuarioEl formulario de cambio de usuario está definido en la stanza [acnt-mgt] delarchivo de configuración webseald.conf.v El parámetro switch-user especifica el nombre del archivo. De forma

predeterminada, el nombre de archivo es switchuser.html:[acnt-mgt]switch-user = switchuser.html

v El parámetro mgt-pages-root especifica la ubicación de subdirectorio para eldirectorio de localización que contiene este archivo:[acnt-mgt}mgt-pages-root = lib/html/<IDIOMA>

En los sistemas de inglés americano, el directorio IDIOMA se denomina “C”.v El segmento de la ruta de acceso lib/html es relativo al valor del parámetro

server-root :UNIX:[server]server-root = /opt/pdweb/www

Windows:[server]server-root = C:/Archivos de programa/Tivoli/PDWeb/www

El formulario de cambio de usuario puede editarse para el aspecto y lafuncionalidad personalizados. El formulario contiene peticiones para:v Nombre de usuario (el administrador “cambia” a este usuario)

Este usuario no puede ser miembro de los grupos su-excluded, su-admins osecuritygroup.

v Dirección URL de destino

Esta página aparece después de una operación correcta de cambio de usuario.Puede configurarla como una entrada oculta que contiene una página depresentación adecuada o una página de confirmación correcta de cambio deusuario.

v Método de autenticación

El método de autenticación determina el tipo de información utilizado para crearla credencial de usuario. Puede configurar este campo como una entrada oculta.Consulte las notas siguientes para crear una lista de los parámetros válidos demétodo de autenticación.

El formulario predeterminado de cambio de usuario tiene el siguiente aspecto:


Notas de formulario de cambio de usuario:

v El formulario sólo está disponible para los miembros del grupo su-admins. Noes necesaria una ACL en este archivo. WebSEAL realiza una comprobación nomodificable de pertenencia a grupos. WebSEAL devuelve un error 404 “Noencontrado” cuando falla la comprobación de pertenencia a grupos.

v El nombre de usuario, la dirección URL de destino y el método de autenticaciónson datos necesarios.

v Los datos necesarios se pueden incorporar en el formulario como camposocultos.

v WebSEAL verifica que todos los datos necesarios estén presentes en elformulario sometido. Si faltan datos, se devuelve el formulario al administradorcon un mensaje descriptivo.

v Los valores válidos para el método de autenticación son:su-basu-formssu-certificatesu-token-cardsu-http-requestsu-cdsso

Estos parámetros del método de autenticación especifican qué mecanismo deautenticación debe utilizar WebSEAL.

v Los métodos su-ba y su-forms se correlacionan con el mecanismo deautenticación su-password especificado en el archivo de configuraciónwebseald.conf.

v Los datos del formulario de cambio de usuario se someten a la dirección URL deacción /pkmssu.form.

Habilitación y exclusión de usuarios del cambio de usuarioSólo los administradores que son miembros del grupo su-admins pueden utilizarla función de cambio de usuario y recibir el formulario HTML de cambio deusuario. La funcionalidad de cambio de usuario está habilitada para cualquierusuario que sea miembro del grupo su-admins.

Los administradores pueden cambiar de usuario a cualquier cuenta de AccessManager, salvo las que pertenecen a ciertos grupos. Puede excluir otros usuariosde Access Manager del cambio de usuario haciéndolos miembros del gruposu-excluded. Además, los miembros del grupo securitygroup de Access Manager

Figura 16. Formulario de datos de cambio de usuario


están excluidos de la funcionalidad de cambio de usuario. Habitualmente,sec_master y los procesos de Access Manager son miembros de securitygroup.

Durante el cambio de usuario, WebSEAL realiza comprobaciones en los tresgrupos. No se puede “cambiar” a un usuario que sea miembro de los grupossu-admins, su-excluded o securitygroup.

Configuración del mecanismo de autenticación de cambio deusuario

La responsabilidad principal del mecanismo de autenticación de cambio de usuario(una biblioteca compartida incorporada) consiste en crear una credencial querepresente al usuario al que se ha “cambiado”, basándose en el nombre de usuarioy el método de autenticación proporcionados, sin que se necesite una contraseñacomo entrada. Un mecanismo personalizado de autenticación de CDAS debecumplir el mismo requisito.

Especifique los mecanismos de autenticación de cambio de usuario en la stanza[authentication-mechanisms] del archivo de configuración webseald.conf. Estánsoportados los siguientes mecanismos de autenticación:[authentication-mechanisms]#su-password = <biblioteca-contraseña-su>#su-token-card = <biblioteca-tarjeta-señal-su>#su-certificate = <biblioteca-certificado-su>#su-http-request = <biblioteca-petición-http-su>#su-cdsso = <biblioteca-cdsso-su>

Access Manager proporciona una sola biblioteca de cambio de usuario que puedeutilizarse para habilitar uno cualquiera de los mecanismos de autenticaciónanteriores en un entorno predeterminado y no personalizado. La biblioteca decambio de usuario difiere de las bibliotecas de autenticación estándar. La bibliotecaespecifica un mecanismo de autenticación que toma la identidad de usuario(proporcionada en el formulario de cambio de usuario) y devuelve una credencialválida para ese usuario sin que se necesite la contraseña de usuario para efectuar laentrada.

La biblioteca compartida de cambio de usuario incorporada que se proporcionacon Access Manager se denomina:

Solaris libsuauthn.so

AIX libsuauthn.a

HP-UX libsuauthn.sl

Windows suauthn.dll

La funcionalidad de cambio de usuario también da soporte a mecanismos deautenticación de CDAS personalizados. Este soporte es importante porque, amenudo, un CDAS personalizado proporciona información adicional a lacredencial del usuario.

El usuario es responsable de escribir un CDAS de cambio de usuario personalizadoque emule el comportamiento del CDAS existente, al tiempo que da soporte alrequisito de devolver una credencial sin necesitar la contraseña de usuario para laentrada. Consulte la publicación IBM Tivoli Access Manager WebSEAL Developer’sReference.


Cada biblioteca configurada de autenticación de cambio de usuario debedenominarse de manera exclusiva, incluso cuando se utilice la bibliotecapredeterminada (libsuauthn) para más de un método de autenticación.

EjemploEn el ejemplo siguiente (para una plataforma Solaris), un entorno existente tienehabilitados tres métodos de autenticación:1. Autenticación de formularios utilizando la biblioteca libldapauthn incorporada2. Autenticación de certificados utilizando la biblioteca libsslauthn incorporada3. Autenticación de señal utilizando un mecanismo de CDAS personalizado

El entorno se amplía para dar soporte a la funcionalidad de cambio de usuariopara cualquiera de estos tres métodos de autenticación. En el archivo deconfiguración webseald.conf deben habilitarse tres parámetros adicionales deautenticación para el cambio de usuario. Además, debe escribirse una nuevabiblioteca CDAS personalizada para emular el CDAS de señal existente y darsoporte a los requisitos de autenticación del cambio de usuario:[authentication-mechanisms]passwd-ldap = /opt/PolicyDirector/lib/libldapauthn.socert-ssl = /opt/PolicyDirector/lib/libsslauthn.sotoken-cdas = /opt/PolicyDirector/lib/libcustom.sosu-password = /opt/PolicyDirector/lib/libsuformauthn.sosu-certificate = /opt/PolicyDirector/lib/libsucert.sosu-token-card = /opt/PolicyDirector/lib/libsucustom.so

Recuerde que el método de autenticación su-forms proporcionado en el formulariode cambio de usuario se correlaciona con el parámetro del mecanismo deautenticación su-password de webseald.conf. Además, se ha cambiado el nombrede la biblioteca libsuauthn que se proporciona tanto para los formularios comopara los mecanismos de certificado.

Configuración de un mecanismo de cambio de usuario deCDAS

Un mecanismo de autenticación de CDAS existente suele devolver informaciónadicional acerca del usuario que se incorpora a la credencial del usuario. Si utilizala característica de cambio de usuario en un entorno de estas características, debeescribir un CDAS especial de cambio de usuario que emule el comportamiento delCDAS existente, al tiempo que se da soporte al requisito de devolver unacredencial sin que se necesite la contraseña del usuario para efectuar la entrada.

La API de CDAS de Access Manager proporciona un conjunto de componentes deidentidad que pueden utilizarse para pasar información de autenticación declientes a la biblioteca CDAS compartida de cambio de usuario. Esta informaciónse pasa utilizando un formato de lista de nombre/valor, en que el nombre es unidentificador que especifica el tipo del valor.

La información se almacena en el tipo de datos xnlist_t data. Se puede acceder alos valores mediante la función del programa de utilidad xnvlist_get().

Los componentes de identidad adecuados para un CDAS de cambio de usuarioson los siguientes:xauthn_su_methodxauthn_admin_namexauthn_admin_credxauthn_existing_cred


xauthn_usernamexauthn_qopxauthn_ipaddrxauthn_browser_info

Los componentes de identidad xauthn_browser_info, xauthn_qop yxauthn_ipaddr representan los del administrador, no los del usuario al que se ha“cambiado”. Estos datos se proporcionan para cualquier CDAS que deba realizarvalidaciones adicionales de la cuenta del administrador.

Consulte la publicación IBM Tivoli Access Manager WebSEAL Developer’s Referencepara obtener información completa y material de consulta relativo a la escritura deun CDAS personalizado.

Influencia en otras funciones de WebSEAL

Influencia en la configuración de tiempo de espera de la cachéde sesiónLas funciones de los valores configurados de tiempo de espera de inactividad de lacaché de sesión de WebSEAL y los de duración no se ven afectadas por laoperación de cambio de usuario. Los temporizadores de inactividad y de duraciónse asocian con la entrada de la caché de sesión del administrador y no con losdatos de la caché, que cambian durante una operación de cambio de usuario.

El temporizador de inactividad se sigue restableciendo mientras el administradorefectúa peticiones como usuario al que se ha “cambiado”. Cuando el administradorfinaliza la sesión de cambio de usuario, la inactividad sigue siendo válida para lasesión restablecida del administrador.

El valor de duración no se amplía a causa de una operación de cambio de usuario.Es posible que el tiempo de espera de duración de la entrada de caché de sesióncaduque durante una operación de cambio de usuario. Si se produce este tiempode espera, se suprime la caché de sesión y finaliza la sesión del administrador. Eladministrador debe volver a autenticarse e iniciar de nuevo la operación de cambiode usuario.

Incorporación de los niveles de autenticación incrementalLa especificación de biblioteca compartida puede tomar argumentos adicionalescon el formato:<biblioteca>&<arg1> <arg2> .... <argx>

Puede designar niveles de autenticación incremental utilizando la opción –lseguida del número de nivel. Por ejemplo:su-password = /opt/PolicyDirector/lib/libsuformauthn.so& -l 1su-certificate = /opt/PolicyDirector/lib/libsucert.so& -l 0su-token-card = /opt/PolicyDirector/lib/libsucustom.so& -l 2

Nota: Para esta versión de Access Manager, el administrador debe saber lacontraseña del usuario para realizar correctamente la autenticaciónincremental.

Soporte para la reautenticaciónLa operación de cambio de usuario reconoce la funcionalidad de la reautenticaciónde WebSEAL. Si se necesita la reautenticación durante una operación de cambio deusuario, el administrador debe autenticarse como usuario al que se ha “cambiado”.


Nota: Para esta versión de Access Manager, el administrador debe saber lacontraseña del usuario al que se ha “cambiado” para realizar unareautenticación correcta.

Soporte para la gestión de la sesión de usuarioLa operación de cambio de usuario da soporte a la gestión de la sesión de usuario.El administrador tiene un ID de sesión de usuario exclusivo. Además, durante unaoperación de cambio de usuario, existe un ID de sesión de usuario exclusivo parael usuario al que se ha “cambiado”. Las tareas de terminar sesiones de usuarioúnico y terminar todas las sesiones de usuario se realizan tal como se esperaba.

Soporte para tag-value (indicador-valor)La funcionalidad de cambio de usuario reconoce y da soporte a la posibilidadtag-value (indicador-valor) utilizada a menudo por un CDAS.

Auditoría del administrador durante el cambio de usuarioEs posible auditar al administrador durante una operación de cambio de usuario.La funcionalidad de cambio de usuario agrega un atributo ampliado a la credencialde usuario al que se ha “cambiado” que identifica al administrador. El atributoampliado se denomina su-admin:su-admin = <nombre-su-admin>

Este atributo ampliado está disponible para cualquier mecanismo de auditoría.

Configuración del almacenamiento en la caché de peticiones delservidor WebSEAL

ContextoEn versiones anteriores de WebSEAL utilizando la autenticación de formularios,WebSEAL ha creado una entrada de caché para la dirección URL de una peticiónde usuario siempre que ha necesitado la autenticación. Tras una autenticacióncorrecta, WebSEAL ha enviado una redirección HTTP al navegador que incluía estadirección URL. A continuación, el navegador ha seguido la redirección hasta laubicación original del recurso.

La limitación de esta implementación resulta aparente cuando, por ejemplo, untiempo de espera de sesión interrumpe una petición POST que ha solicitado unproceso de reautenticación. Dado que WebSEAL sólo ha almacenado en la caché ladirección URL de la petición original, los datos POST (incluidos METHOD yCuerpo del mensaje) se han perdido durante la redirección HTTP. El usuario hatenido que volver a crear la petición POST.

WebSEAL almacena ahora en la caché un conjunto más completo de datos depetición y utiliza estos datos de la caché para volver a crear la petición durante laredirección HTTP, si un requisito de reautenticación interrumpe la finalización delproceso de peticiones. Esta solución beneficia especialmente a las peticiones POSTy PUT, dado que estos tipos de peticiones pueden incluir diversos campos deinformación.

Flujo de proceso de almacenamiento en la caché del servidorCuando un requisito de autenticación interrumpe una petición, WebSEAL almacenaen la caché toda la información necesaria para volver a crear la petición durante laredirección HTTP que sigue a la reautenticación. Los datos de la petición en lacaché incluyen la dirección URL, METHOD, Cuerpo del mensaje, cadenas de


consulta y todas las cabeceras HTTP (incluyendo las cookies). Estos datos sealmacenan temporalmente en la caché de credenciales/sesión de WebSEAL.

Tras realizar un autenticación (o reautenticación) correcta, WebSEAL envía unaredirección HTTP al navegador. El navegador sigue la redirección hasta ladirección URL original contenida en la redirección. WebSEAL intercepta laredirección y vuelve a crear la petición utilizando los datos de la caché. La peticiónque se ha vuelto a crear se entrega a la dirección URL de destino.

El siguiente diagrama muestra un flujo de proceso típico de almacenamiento en lacaché de peticiones del servidor:1. El usuario inicia la sesión correctamente (autenticación de formularios) y envía

una petición HTTP de un recurso que implica un formulario de datos generadocon CGI. WebSEAL crea un ID de sesión para el usuario y lo almacena en lacaché.

2. El servidor de aplicaciones de fondo devuelve el formulario al usuario.3. Durante el período de tiempo que el usuario tarda en rellenar el formulario,

caduca el tiempo de espera de sesión configurado para el usuario. WebSEALelimina la entrada de caché de credenciales del usuario y el ID de sesión.

4. Finalmente, el usuario envía el formulario completado (POST). WebSEAL noencuentra ninguna entrada de caché para el usuario, crea una caché nueva yalmacena en ella temporalmente la información completa contenida en lapetición POST.

5. Dado que WebSEAL no encuentra credenciales para este usuario, éste se debeautenticar. WebSEAL envía un formulario de inicio de sesión al usuario.

6. El usuario devuelve el formulario de inicio de sesión completado a WebSEAL(POST). La autenticación es correcta. La caché contiene ahora las credencialesdel usuario, así como la petición almacenada en la caché.

7. WebSEAL envía una redirección HTTP de vuelta al navegador, que contiene ladirección URL del recurso solicitado originalmente.

8. El navegador sigue la redirección (GET). WebSEAL intercepta la redirección yvuelve a crear la petición (formulario) original utilizando los datos de POST dela caché. La petición (formulario) restaurada se entrega a la designación de ladirección URL.


Configuración de parámetros del almacenamiento en la cachédel servidor

Aunque el almacenamiento en la caché de la petición se produce automáticamentepara la autenticación de formularios de WebSEAL, pueden especificarse límites altamaño de la petición que WebSEAL almacena en la caché. Los parámetrosrequest-max-cache y request-body-max-read están ubicados en la stanza [server]del archivo de configuración webseald.conf.

request-max-cache

El parámetro request-max-cache especifica la cantidad máxima de datos, en bytes,que WebSEAL almacena en la caché para cada petición. Por ejemplo:[server]request-max-cache = 8192

Tal como se describe a continuación, debe tener en cuenta el valor del parámetrorequest-body-max-read al especificar request-max-cache.

request-body-max-read

El parámetro request-body-max-read especifica el tamaño máximo del cuerpo demensaje de la petición, en bytes, que WebSEAL almacena en la caché para cada

Figura 17. Ejemplo de flujo de proceso de almacenamiento en la caché de una petición deWebSEAL


petición. Este parámetro influye particularmente en los tipos de petición quecontienen datos de cuerpo de mensaje, como las peticiones POST y PUT. Porejemplo:[server]request-body-max-read = 4096

Este parámetro no limita el tamaño máximo de POST (que es ilimitado) para laspeticiones que no requieren autenticación.

Tenga en cuenta que el valor de request-max-cache debe acomodar correctamenteel valor de request-body-max-read más el tamaño de todos los demáscomponentes de la petición. Por ejemplo, si especifica 2048 como límite de la cachépara los cuerpos de mensajes de las peticiones y prevé que el tamaño máximo detodos los demás componentes de la petición (tales como cabeceras y cookies) seráde 4096 bytes, entonces:1. Defina request-body-max-read = 20482. Defina request-max-cache = 2048 + 4096 = 6144

Si se han excedido los valores de request-body-max-read o request-max-cachedurante una petición, WebSEAL anula el proceso de almacenamiento en la cachéde la petición, devuelve al navegador un mensaje de error Error en elalmacenamiento en caché de la petición y escribe el error en el archivo de registro.Puede personalizar este mensaje de error. Consulte el apartado “Gestión depáginas personalizadas de mensajes de error HTTP” en la página 33.

Notas y limitacionesv El valor de request-body-max-read influye también en las peticiones de

dirección URL dinámica porque la parte de consulta de la petición POST estácontenida en el cuerpo del mensaje de la petición.

v El valor de request-body-max-read influye también en la autenticación deformularios, ya que pone un límite al tamaño de los datos de POST que seprocesan durante la autenticación.

v Los parámetros request-body-max-read y request-max-cache protegen aWebSEAL de ataques del tipo de denegación de servicio, que hacen queWebSEAL almacene en la caché más datos de los que puede gestionar.

v El almacenamiento en la caché de la petición del servidor no funcionarácorrectamente si el valor de tiempo de espera de la sesión del usuario caducadurante el proceso de inicio de sesión. En esta situación, se pierde la entrada dela caché.

v El almacenamiento en la caché de la petición en el servidor puede causarlimitaciones en la capacidad del navegador de manipular el recurso. Elnavegador no sabe que WebSEAL ha vuelto a crear la redirección HTTP. Porconsiguiente, la función de recarga y renovación y la capacidad dealmacenamiento en la caché del navegador pueden quedar afectadas.

Gestión de los caracteres codificados UTF-8De acuerdo con las especificaciones HTTP, los navegadores tienen una limitaciónrespecto al juego de caracteres que puede utilizarse de forma válida en unadirección URL. Este rango está definido como los caracteres imprimibles del juegode caracteres ASCII (entre los códigos hexadecimales 0x20 y 0x7e). Para idiomasdistintos del inglés y otras finalidades, los caracteres situados fuera del juego de


caracteres ASCII imprimible suelen ser necesarios en las direcciones URL. Estoscaracteres pueden codificarse utilizando caracteres imprimibles para su transmisióne interpretación.

Hay varios métodos distintos de codificación para transmitir caracteres fuera delrango permitido. A pesar de las especificaciones HTTP, hay también numerososservidores web comerciales que simplemente toleran y aceptan los caracteres quese encuentran fuera del rango válido. WebSEAL, al actuar como proxy de web,debe ser capaz de gestionar todos estos casos.

El método de codificación de caracteres que goza de una aceptación más amplia(“estándar de facto”) es UTF-8. Muchos servidores web comerciales actualespueden configurarse para que acepten la codificación UTF-8.

El parámetro utf8-url-support-enabled de la stanza [server] del archivo deconfiguración webseald.conf controla cómo WebSEAL interpreta las direccionesURL enviadas desde los navegadores. El parámetro reconoce tres valores:v yes

WebSEAL sólo reconoce la codificación UTF-8 en las cadenas de direcciones URLy descodifica la información al juego de caracteres nativo (página de códigoslocal). No se aceptan otras técnicas de codificación, como el juego de caracteresde doble byte (DBCS) y Unicode.

v no

WebSEAL no reconoce la codificación UTF-8 en las cadenas de las direccionesURL. Ninguna información codificada con UTF-8 se interpretará correctamente.Se aceptan otras técnicas de codificación.

v auto

WebSEAL intenta distinguir entre UTF-8 y otros formatos de codificación decaracteres lingüísticos (DBCS y Unicode). WebSEAL procesa correctamentecualquier codificación UTF-8 construida correctamente. Si no parece tratarse dela codificación UTF-8, la codificación se procesa como DBCS o Unicode.

Cuando utf8-url-support-enabled se establece en “yes” (valor predeterminado),WebSEAL supone que las direcciones URL pueden incluir caracteres codificadosUTF-8. A continuación, estos caracteres UTF-8 se validan y se tienen en cuenta a lahora de determinar los derechos de acceso a la dirección URL. La dirección URL senormaliza (es decir, los caracteres codificados se convierten a sus equivalentes de lapágina de códigos local) y la comprobación de ACL se aplica a la dirección URLnormalizada. El valor predeterminado no permite las direcciones URL concaracteres DBCS o Unicode con el formato %uXXXX. Ésta es la configuraciónrecomendada para WebSEAL.

Algunas aplicaciones y servidores web existentes no funcionan correctamente conWebSEAL si está habilitado el soporte para UTF-8, ya que estas aplicacionesutilizan DBCS (como Shift-JIS) en la dirección URL u otros mecanismos decodificación.

Si es éste el caso de su despliegue, tiene que realizar las dos tareas siguientes:1. Edite webseald.conf y establezca el nuevo parámetro de la manera siguiente:

utf8-url-support-enabled = no

2. Asegúrese de que todos los servidores con conexión NO aceptan direccionesURL con codificación UTF-8. Desde la perspectiva de la seguridad, esimportante que WebSEAL interprete las direcciones URL de la misma maneraque los servidores con conexión (junction).


La estrategia de despliegue recomendada es la siguiente:1. A menos que se necesite con fin al contenido, comprobar y establecer

inmediatamente la política de ACL default-webseal en los despliegues deproducción existentes NO permite el acceso “r” no autenticado. Este hecholimita la exposición de seguridad a los usuarios que tienen una cuenta válidaen el dominio de Access Manager.

2. Asegúrese de que el parámetro utf8-url-support-enabled se establece en elvalor predeterminado, “yes”.

3. Pruebe las aplicaciones. Si funcionan correctamente, utilice este valor.4. Si falla alguna aplicación con errores de “Petición errónea”, vuelva a intentar la

aplicación estableciendo el parámetro utf8-url-support-enabled en “no”. Si estofunciona correctamente, puede realizar el despliegue con el parámetroestablecido en “no”. Sin embargo, también debe asegurarse de que no hayaningún servidor web con conexión (junction) que esté configurado para aceptardirecciones URL con codificación UTF-8.

Prevención de la vulnerabilidad causada por scripts de sitios cruzadosEl script de sitios cruzados hace referencia a una técnica utilizada para causar lavulnerabilidad de servidores web al incorporar código malicioso en las direccionesURL de las peticiones web. WebSEAL proporciona cierta protección incorporadapara este tipo de vulnerabilidad y permite refinar más la protección configurandoel filtrado de cadenas de direcciones URL.

Nota: El término “script de sitios cruzados”, aunque aceptado por el sector, nodescribe por completo el rango de asuntos que implican la inserción decódigo malicioso.

ContextoEl script de sitios cruzados es un tipo específico de vulnerabilidad de losservidores web que se produce cuando una petición de dirección URL del clienteincluye un script malicioso incorporado. Por ejemplo (Javascript):<script>código_malicioso</script>

Otros indicadores de script que pueden utilizarse para crear vulnerabilidad son<OBJECT>, <APPLET> y <EMBED>. Cuando un usuario hace clic en un vínculoque contiene el código malicioso (o entra directamente en una dirección URL deeste tipo), el script se ejecuta cuando el navegador del usuario lee el HTML.

Por ejemplo, puede producirse un ataque cuando un usuario hace clic en unvínculo que contiene la dirección URL siguiente:https://<host-webseal>/<script>código_malicioso</script>

En este ejemplo, el objeto no se encuentra y WebSEAL responde devolviendo unapágina de error 404 “Página no encontrada” de HTML. Esta página de errorincluye la dirección URL que contiene el Javascript malicioso. El navegadorinterpreta la dirección URL y ejecuta el script.

Consulte la siguiente lista de advertencias del CERT para obtener informacióncompleta acerca de la mecánica de los scripts de sitios cruzados y tomar medidaspreventivas de carácter general:

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


Configuración del filtrado de cadenas de direcciones URLEl programa de los scripts de sitios cruzados —y del código malicioso incorporadoen general— se gestiona de dos maneras.

WebSEAL codifica ahora los corchetes angulares (<, >) en las direcciones URLredirigidas. La codificación puede ayudar a prevenir que el navegador realice unainterpretación normal de los scripts.

Además, ahora puede agregar una nueva stanza al archivo de configuraciónwebseald.conf. La stanza, [illegal-url-substrings], puede contener parámetros queespecifiquen uno o más fragmentos de cadenas. Por ejemplo:[illegal-url-substrings]substring = <scriptsubstring = <appletsubstring = <embed

Si WebSEAL detecta cualquier fragmento de cadena configurado en la direcciónURL solicitada, la dirección URL no se considera válida y no se acepta. WebSEALdevuelve una página de error 400 “Petición errónea”.

Este flexible mecanismo permite gestionar futuros esquemas de ataque al agregarvalores adicionales de subcadenas.

WebSEAL filtra, de forma predeterminada, las cadenas que contienen <script>. Noes necesario que se agregue manualmente la stanza [illegal-url-substrings] parafiltrar esta cadena en particular. No obstante, cuando se requiere un filtradoadicional, debe crear la stanza y listar individualmente todas las subcadenas, comoen el ejemplo anterior.

Para inhabilitar por completo la característica de filtrado de cadenas de direccionesURL (incluido el comportamiento predeterminado), ponga una stanza[illegal-url-substrings] vacía en el archivo webseald.conf.

Notas funcionales:v Las subcadenas se localizan mediante una búsqueda no sensible a mayúsculas y

minúsculasv El filtrado de subcadenas acomoda caracteres de múltiples bytesv El mecanismo protege a los servidores con conexión (junction)

Supresión de la identidad del servidorEn circunstancias normales, las respuestas del servidor HTTP contienen laidentidad y la versión del servidor:content-type: text/htmldate: Tue, 05 Mar 2002 02:34:18 GMTcontent-length: 515server: WebSEAL/3.9.0last-modified: Thu, 21 Feb 2002 08:03:46 GMTconnection: close

Por razones de seguridad, puede que prefiera que WebSEAL suprima estainformación en sus respuestas a los clientes. Para suprimir la identidad delservidor en las respuestas del servidor HTTP, establezca el parámetrosuppress-server-identity en la stanza [server] del archivo de configuraciónwebseald.conf en “yes”:


[server]suppress-server-identity = yes

El valor predeterminado es “no”.

Utilización de las estadísticas de WebSEALWebSEAL proporciona una serie de módulos de software incorporados que,cuando están habilitados, pueden supervisar la actividad específica del servidor yrecopilar información acerca de esas actividades. En cualquier momento, puedevisualizar la información estadística recopilada desde que se habilitó ese módulo.Además, puede dirigir esta información estadística a archivos de registro.

Cuando se muestra la información estadísticas, se ve una “instantánea” de lainformación desde que se habilitó el módulo. La información recopilada por lasestadísticas de WebSEAL proporciona una vista relativa de la actividad que se estáregistrando. Si se capturan estadísticas a intervalos regulares durante un ciertoperíodo de tiempo, se puede generar una vista gráfica de la relación relativa de lasactividades del servidor.

Sintaxis del comando pdadmin statsUtilice el comando pdadmin stats para gestionar los componentes de estadísticas.En este apartado se describen las operaciones válidas para el comando pdadminstats:

Comando básico de pdadmin statspdadmin> server task webseald-<instancia> stats <comando>

Con el comando pdadmin stats se pueden realizar las siguientes tareas:

stats on Habilitar estadísticas dinámicamente, por componente

stats off Inhabilitar estadísticas, por componente o todos los componentes a la vez

stats show Listar componentes habilitados

stats get Mostrar valores actuales de estadísticas por componente o todos loscomponentes a la vez

stats reset Restablecer los valores de estadísticas por componente o todos loscomponentes a la vez

stats list Listar todos los componentes de estadísticas disponibles

Habilitar estadísticas dinámicamentePuede habilitar dinámicamente el informe de estadísticas con el comando pdadminstats on o de forma estática con los parámetros de configuración del archivo deconfiguración webseald.conf.

Utilice el comando pdadmin stats on para habilitar la recopilación de estadísticas yestablecer la frecuencia, número y destino de los informes de estadísticas para uncomponente.stats on <componente> [<intervalo> [<recuento>]] [<agentereg>]



componente Nombre del componente de estadísticas. Necesario. Las estadísticas serecopilan en la memoria de WebSEAL para este componente. Lasestadísticas para este componente también se pueden registrar en unarchivo de registro especificando los argumentos opcionales de estecomando.

intervalo El intervalo de tiempo entre informes de información. Este argumentoes opcional y produce como resultado que se envíen las estadísticas aun archivo de registro. Cuando se especifica esta opción, las estadísticasse envían, de forma predeterminada, a la salida estándar del servidorWebSEAL, que es el archivo de registro de WebSEAL. Para especificarotra ubicación de salida, utilice el argumento agentereg. Si no seespecifica intervalo, no se envían estadísticas a ningún archivo deregistro. Sin embargo, el componente de estadísticas seguirá habilitado.Puede obtener informes de forma dinámica en cualquier momentomediante pdadmin stats get.

recuento Recuento de informes enviados a un archivo de registro. Esteargumento es opcional y requiere que se especifique el argumentointervalo. Si se especifica intervalo sin número, la duración del informe esindefinida. Después de alcanzar el valor de recuento, se detiene elinforme a un archivo de registro. Sin embargo, el componente deestadísticas seguirá habilitado. Puede obtener informes de formadinámica en cualquier momento mediante pdadmin stats get.

agentereg Especifica de forma opcional un destino para la información estadísticarecopilada para el componente especificado. Consulte el capítulo“Utilización del registro de eventos” de la publicación IBM Tivoli AccessManager Base Guía del administrador para obtener detalles completossobre la configuración.

Nota: De manera predeterminada, los componentes pdweb.threads,pdweb.doccache y pdweb.jmt también se habilitan y no se puedeninhabilitar.

Consulte también el apartado “Habilitación estática de estadísticas mediante elregistro de eventos” en la página 85.

Ejemplo 1:

Este ejemplo habilita el componente pdweb.http. Dado que no se ha especificadola opción intervalo, sólo se puede obtener información estadística para estecomponente de forma dinámica utilizando pdadmin stats get.pdadmin> server task webseald-<instancia> stats on pdweb.http

Ejemplo 2:

Este ejemplo habilita el componente pdweb.http. Dado que se ha especificado elargumento intervalo, la información se envía (de forma predeterminada) al archivode registro estándar de WebSEAL. Los argumentos intervalo y recuento hacen que elarchivo de registro acumule 100 entradas que representan informes de estadísticascon 20 segundos de diferencia.pdadmin> server task webseald-<instancia> stats on pdweb.http 20 100


Ejemplo 3:

Este ejemplo habilita el componente pdweb.http. El argumento agentereg utiliza laconfiguración de registro de eventos para especificar un archivo de destino para lainformación estadística. Cada 20 segundos y de forma indefinida, el argumentointervalo (sin el valor de recuento) envía información estadística para estecomponente al archivo de registro. El crecimiento del archivo de registro estácontrolado por el parámetro rollover_size. Consulte el capítulo “Utilización delregistro de eventos” de la publicación IBM Tivoli Access Manager Base Guía deladministrador para obtener detalles completos sobre la configuración del registro deeventos.pdadmin> server task webseald-<instancia> stats on pdweb.http 20 filepath=/tmp/jmt-stats.log,rollover_size=-1,flush_interval=20

Ejemplo 4:

Este ejemplo ilustra una limitación de la gestión dinámica de estadísticas. Elprimer comando habilita el componente pdweb.http y dirige la información deestadísticas al archivo A.log. El segundo comando intenta activar un segundoarchivo de registro, B.log. No obstante, esta acción produce finalmente comoresultado la desactivación de A.log , al tiempo que se activa B.log.pdadmin> server task webseald-<instancia> stats on pdweb.http 20 file path=/tmp/A.logpdadmin> server task webseald-<instancia> stats on pdweb.http 20 file path=/tmp/B.log

Inhabilitar estadísticasInhabilita la recopilación de estadísticas para un componente o para todos loscomponentes a la vez.stats off [<componente>]

Ejemplo:pdadmin> server task webseald-<instancia> stats off pdweb.sescache

Nota: De forma predeterminada, los componentes pdweb.threads,pdweb.doccache y pdweb.jmt están siempre habilitados y no se puedeninhabilitar.

Mostrar componentes de estadísticas habilitadosLista todos los componentes de estadísticas habilitados o un componentehabilitado determinado. Si un componente específico no está habilitado, no semostrará ninguna salida.stats show [<componente>]

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

Ejemplo 2:pdadmin> server task webseald-<instancia> stats show pdweb.authnpdweb.authn

Obtener dinámicamente los valores de estadísticas actualesMuestra los valores actuales de las estadísticas que recopila un componente otodos los componentes habilitados.


stats get [<componente>]

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

Restablecer valores de estadísticasRestablece los valores recopilados por un componente habilitado o por todos loscomponentes habilitados a la vez.stats reset [<componente>]

Ejemplo:pdadmin> server task webseald-<instancia> stats reset pdweb.threads

Listar todos los componentes de estadísticas disponiblesLista todos los componentes disponibles para recopilar y generar informes deestadísticas.stats list

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

Componentes de estadísticas y tipos de actividadEn este apartado se describen los componentes de estadísticas disponibles paraIBM Tivoli Access Manager WebSEAL.

Componente pdweb.authnEl componente de estadísticas pdweb.authn recopila información relativa a laautenticación de WebSEAL. La tabla siguiente describe los tipos de informacióndisponibles:

Tipo Descripción

pass Número total de autenticaciones correctas

fail Número total de autenticaciones incorrectas

pwd exp Número total de intentos de autenticación efectuados con una contraseñacaducada

max Período máximo de tiempo para un solo proceso de autenticación.

avg Período medio de tiempo para un solo proceso de autenticación.

total Período de tiempo total para todo el proceso de autenticación


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

Componente pdweb.authzEl componente de estadísticas pdweb.authz recopila información relativa a laautorización de WebSEAL. La tabla siguiente describe los tipos de informacióndisponibles:

Tipo Descripción

pass Número total de peticiones de autorización correctas (a cuántos recursosse ha accedido correctamente)

fail Número total de autorizaciones incorrectas

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

Componente pdweb.httpEl componente de estadísticas pdweb.http recopila información relativa a lacomunicación HTTP de WebSEAL. La tabla siguiente describe los tipos deinformación disponibles:

Tipo Descripción

reqs Número total de peticiones HTTP recibidas

max-worker Período máximo de tiempo utilizado por un solo thread de trabajo paraprocesar una petición HTTP

total-worker Período de tiempo total utilizado por todos los threads de trabajo queprocesan peticiones HTTP

max-webseal Período máximo de tiempo utilizado para procesar una sola peticiónHTTP, medido dentro del thread de trabajo, después de haber leído lascabeceras de petición y eliminando la actividad general de configuraciónde la conexión

total-webseal Período total de tiempo utilizado para procesar todas las peticionesHTTP, medido dentro del thread de trabajo, después de haber leído lascabeceras de petición y eliminando la actividad general de configuraciónde la conexión

Ejemplo:pdadmin> server task webseald-<instancia> stats get pdweb.httpreqs : 0max-worker : 0.000total-worker : 0.000max-webseal : 0.000total-webseal : 0.000

Componente pdweb.httpsEl componente de estadísticas pdweb.https recopila información relativa a lacomunicación HTTPS de WebSEAL. La tabla siguiente describe los tipos deinformación disponibles:


Tipo Descripción

reqs Número total de peticiones HTTPS recibidas

max-worker Período máximo de tiempo utilizado por un solo thread de trabajo paraprocesar una petición HTTPS

total-worker Período de tiempo total utilizado por todos los threads de trabajo queprocesan peticiones HTTPS

max-webseal Período máximo de tiempo utilizado para procesar una sola peticiónHTTPS, medido dentro del thread de trabajo, después de haber leído lascabeceras de petición y eliminando la actividad general de configuraciónde la conexión

total-webseal Período total de tiempo utilizado para procesar todas las peticionesHTTPS, medido dentro del thread de trabajo, después de haber leído lascabeceras de petición y eliminando la actividad general de configuraciónde la conexión

Ejemplo:pdadmin> server task webseald-<instancia> stats get pdweb.httpsreqs : 0max-worker : 0.000total-worker : 0.000max-webseal : 0.000total-webseal : 0.000

Componente pdweb.threadsEl componente de estadísticas pdweb.threads recopila información relativa a laactividad de los threads de trabajo de WebSEAL. Este componente está siemprehabilitado de forma predeterminada y no se puede inhabilitar. La tabla siguientedescribe los tipos de información disponibles:

Tipo Descripción

active Número total de threads de trabajo activos que gestionan peticiones

total Número total de threads de trabajo configurados

Ejemplo:pdadmin> server task webseald-<instancia> stats get pdweb.threadsactive : 0total : 50

Componente pdweb.jmtEl componente de estadísticas pdweb.jmt recopila información relativa a la tablade correlación de conexiones (junctions) WebSEAL. Este componente está siemprehabilitado de forma predeterminada y no se puede inhabilitar. La tabla siguientedescribe los tipos de información disponibles:

Tipo Descripción

hits Número total de peticiones que necesitaban la correlación de direccionesURL a través de la tabla de correlaciones de conexión (junction)

Ejemplo:pdadmin> server task webseald-<instancia> stats get pdweb.jmthits : 5


Componente pdweb.sescacheEl componente de estadísticas pdweb.sescache recopila información relativa a laactividad de caché de sesión/credenciales de WebSEAL. La tabla siguiente describelos tipos de información disponibles:

Tipo Descripción

hit El número de peticiones que han dado como resultado un acierto de lacaché de sesión, es decir, el usuario tenía una entrada en la caché desesión y ésta se ha referenciado correctamente

miss Número de peticiones que han fallado un acierto de caché de sesión

add Número de entradas que se han agregado a la caché de sesión

del Número de entradas que se han suprimido de la caché

inactive Número de entradas eliminadas de la caché debido a que ha caducado elvalor de tiempo de espera de inactividad

lifetime Número de entradas eliminadas de la caché debido a que ha caducado elvalor de tiempo de espera de duración

LRU expired Número de veces que una entrada de caché de “Utilizado en fechamenos reciente” ha caducado o se ha eliminado para crear espacio parauna entrada nueva.

Ejemplo:pdadmin> server task webseald-<instance> stats get pdweb.sescachehit : 0miss : 0add : 0del : 0inactive : 0lifetime : 0LRU expired : 0

Componente pdweb.doccacheEl componente de estadísticas pdweb.doccache recopila información relativa a laactividad de almacenamiento en la caché de documentos de WebSEAL. Estecomponente informa de estadísticas para todos los tipos MIME habilitados en lastanza [content-cache] del archivo de configuración webseald.conf. Estecomponente está siempre habilitado de forma predeterminada y no se puedeinhabilitar.

La tabla siguiente describe los tipos de información global disponibles para todoslos tipos MIME:

Tipo Descripción

General Errors (Erroresgenerales)

Número de errores sobre los que ha informado el componentepdweb.doccache cuando haya anomalías de asignación dememoria, anomalías de inicialización y valores de cabecera detipo MIME no válidos.

Uncachable (Noalmacenable en caché)

Número de instancias en que no hay ninguna caché definidapara el tipo MIME del documento que se ha de almacenar encaché

Pending Deletes(Supresionespendientes)

Número de entradas marcadas para su supresión, pero quetodavía se están utilizando

Tamaño pendiente Número de bytes utilizados por las entradas marcadas para susupresión, pero que todavía se están utilizando


Tipo Descripción

Misses (Fallos) Número de veces que se busca una dirección URL en la caché dedocumentos y no se encuentra. Un documento encontrado en lacaché elimina la necesidad de acceder de nuevo al documentoreal.

Tipo MIME de caché El tipo MIME de documentos almacenados en esta caché.

Estadísticas de tipo MIME de caché:

Tipo Descripción

Max size (Tamañomáximo)

Tamaño máximo combinado en bytes de todos los documentos dela caché.

Max entry size(Tamaño máximo deentrada)

El tamaño máximo en bytes para cualquier documento separado enla caché. Si el tamaño del documento sobrepasa este valorcalculado internamente, no se almacena en la caché.

Size (Tamaño) Recuento total en bytes para todos los documentos que residenactualmente en la caché

Count (Recuento) Número actual de entradas en la caché.

Hits (Aciertos) Número de búsquedas satisfactorias (los documentos se hanencontrado correctamente en la caché)

Stale hits (Aciertoscaducados)

Número de búsquedas satisfactorias que han encontrado unaentrada demasiado antigua y que se ha depurado

Create waits (Crearesperas)

Número de veces que peticiones posteriores de un documento hansido bloqueadas (hacer que esperasen) mientras inicialmente se haalmacenado en la caché el contenido del documento

Cache no room (Sinespacio en la caché)

Número de veces que un documento válido para sualmacenamiento en la caché no puede encajar en la caché porquehay demasiadas entradas que se están creando al mismo tiempo

Additions(Adiciones)

Número de nuevas entradas correctas en la caché

Aborts (Anulaciones) Número de veces que se ha anulado la creación de una nuevaentrada de caché a causa de problemas o de una cabecera queindica que la entrada no debe almacenarse en la caché

Deletes (Supresiones) Número de entradas de caché suprimidas porque la entrada hacaducado o la creación se ha anulado

Updates(Actualizaciones)

Número de entradas de las que se ha actualizado la fecha decaducidad

Too big errors(Errores dedemasiado grande)

Número de intentos de almacenar documentos en la caché queexceden el tamaño máximo de la entrada (y, por consiguiente, nose almacenan en la caché)

MT errors (Errores deMT)

Número de veces que más de un thread intenta crear la mismaentrada en la caché (MT=Múltiples threads)

Ejemplo:pdadmin> server task webseald-<instancia> stats get pdweb.doccacheGeneral Errors : 0Uncachable : 0Pending Deletes: 0Pending Size : 0Misses : 0Cache MIME type : text/htmlMax size : 2048000


Max entry size : 128000Size : 0Count : 0Hits : 0Stale hits : 0Create waits : 0Cache no room : 0Additions : 0Aborts : 0Deletes : 0Updates : 0Too big errors : 0MT errors : 0

Componente pdweb.jct.#El componente de estadísticas pdweb.jct.# recopila información relativa a lasconexiones (junctions) WebSEAL. La tabla siguiente describe los tipos deinformación disponibles:

Tipo Descripción

[/] Nombre real de la conexión (junction) (listado como un número en elcomando)

reqs Número total de peticiones direccionadas a través de esta conexión(junction)

max Período máximo de tiempo consumido en una sola petición a través deesta conexión (junction)

total Período de tiempo total consumido por las peticiones a través de estaconexión (junction)

Ejemplo:pdadmin> server task webseald-<instancia> stats get pdweb.jct.1[/]reqs : 0max : 0.000total : 0.000

Habilitación estática de estadísticas mediante el registro deeventos

Las estadísticas pueden configurarse de manera estática en la stanza[aznapi-configuration] del archivo de configuración webseald.conf utilizando elparámetro stats para habilitar la interfaz de estadísticas y utilizando el parámetrode registro de eventos logcfg para dirigir la información de estadísticas a undestino:[aznapi-configuration]stats = <componente> [intervalo [recuento]]logcfg = stats.<componente>:<destino>

Consulte “Habilitar estadísticas dinámicamente” en la página 77 para obtenerinformación sobre los argumentos intervalo y recuento.

Consulte el capítulo “Utilización del registro de eventos” de la publicación IBMTivoli Access Manager Base Guía del administrador para obtener detalles completossobre la configuración del registro de eventos.


Ejemplo 1:

En este ejemplo, el parámetro stats habilita el componente y cualquier argumentointervalo y recuento. El parámetro logcfg especifica el destino de esta información.Consulte el capítulo “Utilización del registro de eventos” de la publicación IBMTivoli Access Manager Base Guía del administrador para obtener detalles completossobre la configuración.[aznapi-configuration]stats = pdweb.jmt 20logcfg = stats.pdweb.jmt:file path=/tmp/jmt.log,rollover_size=-1,flush=20

Ejemplo 2:

En este ejemplo, varios parámetros stats habilitan varios componentes. Variosparámetros logcfg especifican varios destinos. Tenga en cuenta que, a diferenciadel comando stats on dinámico, puede especificar varios archivos de destino parael mismo componente. Consulte el capítulo “Utilización del registro de eventos” dela publicación IBM Tivoli Access Manager Base Guía del administrador para obtenerdetalles completos sobre la configuración del registro de eventos.[aznapi-configuration]stats = pdweb.jmt 20stats = pdweb.authn 40stats = pdweb.jct.1 50logcfg = stats.pdweb.jmt:file path=/tmp/jmtA.log,rollover_size=-1,flush=20logcfg = stats.pdweb.jmt:file path=/tmp/jmtB.log,rollover_size=-1,flush=20logcfg = stats.pdweb.authn:file path=/tmp/an.log,rollover_size=-1,flush=20logcfg = stats.pdweb.jct.1:file path=/tmp/jct.log,rollover_size=-1,flush=20

Utilización del programa de utilidad de rastreo para capturar accionesde WebSEAL

El programa de utilidad trace permite capturar información acerca de lascondiciones de error y el flujo de control de programas en Access Manager Base yAccess Manager WebSEAL. Esta información se almacena en un archivo y seutiliza con fines de depuración. El programa de utilidad trace se proporcionaprincipalmente para asistir al personal de soporte en el diagnóstico de problemasque se producen con el funcionamiento del software de Access Manager.

Como usuario, puede encontrar útiles algunos de los componentes de rastreo deWebSEAL. No obstante, la mayoría son escasamente ventajosos, a menos que estédiagnosticando problemas complejos con la ayuda de personal de soporte técnico.

Nota: Utilice trace con precaución. Está pensada como una herramienta que debeutilizarse bajo la dirección de personal de soporte técnico. Los mensajes detrace son en ocasiones crípticos, no están traducidos y pueden degradargravemente el rendimiento del sistema.

Sintaxis básica del comando tracepdadmin> server task webseald-<instancia> trace <comando>

Con el comando pdadmin trace se pueden realizar las siguientes tareas:

trace set Habilita el nivel de rastreo y el destino del mensaje de rastreo para uncomponente y sus subordinados

trace show Muestra el nombre y el nivel de todos los componentes habilitados delrastreo o para el componente especificado


trace list Lista todos los componentes de rastreo disponibles

Habilitar rastreoUtilice el comando pdadmin trace set para habilitar la recopilación de informaciónde rastreo para el componente y nivel especificados.trace set <componente><nivel>[<agentereg>]


componente Nombre del componente de rastreo. Necesario. Los componentesespecíficos de WebSEAL tienen el prefijo “pdweb”.

nivel Nivel de informe. Necesario. El argumento de nivel especifica lacantidad de detalles recopilados por el programa de utilidad trace. Elrango es de 1 a 9. El nivel 1 especifica la salida más detallada y el nivel9 especifica la salida menos detallada.

agentereg Especifica de forma opcional un destino para la información de rastreorecopilada para el componente especificado. Consulte el capítulo“Utilización del registro de eventos” de la publicación IBM Tivoli AccessManager Base Guía del administrador para obtener detalles completossobre la configuración.

Mostrar componentes de rastreo habilitadosLista todos los componentes de rastreo habilitados o un componente habilitadodeterminado. Si un componente específico no está habilitado, no se mostraráninguna salida.trace show [<componente>]

Ejemplo:pdadmin> server task webseald-<instancia>trace set pdweb.debug 2pdadmin> server task webseald-<instancia> trace showpdweb.debug 2

Listar todos los componentes de rastreo disponiblesLista el componente especificado o todos los componentes disponibles pararecopilar la información de rastreo y generar un informe.trace list [<componente>]

Componentes de rastreo de WebSEAL

pdweb.debugNota: El componente pdweb.debug sólo opera en el nivel 2.

El comando siguiente invoca el programa de utilidad trace para el componentepdweb.debug en el nivel 2 y dirige la salida a un archivo utilizando el mecanismode registro de eventos para especificar un agente de registro de archivos.pdadmin> server task webseald-<instancia> trace set pdweb.debug 2 \file path=/opt/pdweb/log/debug.log

La salida de ejemplo de este comando tal como aparece en el archivo debug.log:/src/wand/wand/log.c:277: -------------- Browser ===> PD --------------Thread_ID:17GET /test/index.html HTTP/1.1Host: bevan


User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)Gecko/20011128 Netscape6/6.2.1Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css,*/*;q=0.1Accept-Language: en-usAccept-Encoding: gzip, deflate, compress;q=0.9Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66Keep-Alive: 300Connection: keep-alive---------------------------------------------------

/src/wand/wand/log.c:277: -------------- PD ===> BackEnd --------------Thread_ID:17GET /index.html HTTP/1.1via: HTTP/1.1 bevan:443host: mokum.santacruz.na.tivoli.comuser-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)Gecko/20011128 Netscape6/6.2.1accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css,*/*;q=0.1accept-language: en-usaccept-charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66accept-encoding: gzip, deflate, compress;q=0.9keep-alive: 300connection: close---------------------------------------------------

/src/wand/wand/log.c:277: -------------- PD <=== BackEnd --------------Thread_ID:17content-type: text/htmldate: Mon, 25 Mar 2002 19:48:32 GMTcontent-length: 7017etag: "0-1b69-3b688e48"last-modified: Thu, 02 Aug 2001 00:18:32 GMTserver: IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Win32)connection: closeaccept-ranges: bytes---------------------------------------------------

/src/wand/wand/log.c:277: -------------- Browser <=== PD --------------Thread_ID:17HTTP/1.1 200 Document followscontent-type: text/htmldate: Mon, 25 Mar 2002 19:48:32 GMTcontent-length: 7017etag: "0-1b69-3b688e48"last-modified: Thu, 02 Aug 2001 00:18:32 GMTserver: IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Win32)connection: closeaccept-ranges: bytes---------------------------------------------------


Capítulo 4. Política de seguridad de WebSEAL

Este capítulo contiene información que describe cómo configurar y personalizar lapolítica de seguridad de WebSEAL.

Índice de temas:v “Políticas de ACL específicas de WebSEAL”v “Política de inicio de sesión en tres intentos” en la página 91v “Política de intensidad de contraseñas” en la página 92v “Política POP de intensidad de autenticación (incremental)” en la página 95v “Política POP de autenticación basada en la red” en la página 101v “Política POP de calidad de protección” en la página 103v “Gestión de usuarios no autenticados (HTTP / HTTPS)” en la página 104

Políticas de ACL específicas de WebSEALLas siguientes consideraciones de seguridad se aplican al contenedor /WebSEAL delespacio de objetos protegidos:v El objeto WebSEAL empieza la cadena de herencia de ACL para la región

WebSEAL del espacio de objetosv Si no aplica ninguna otra ACL explícita, este objeto define (a través de la

herencia) la política de seguridad para todo el espacio webv El permiso traverse es necesario para el acceso a cualquier objeto situado por

debajo de este punto

Consulte la publicación IBM Tivoli Access Manager Base Guía del administrador paraobtener información completa sobre las políticas de ACL de Access Manager.

/WebSEAL/< host >Esta entrada de subdirectorio representa el inicio del espacio web para unainstancia determinada de servidor WebSEAL. Las siguientes consideraciones deseguridad se aplican a este objeto:v El permiso traverse es necesario para el acceso a cualquier objeto situado por

debajo de este puntov Si no aplica ninguna otra ACL explícita, este objeto define (a través de la

herencia) la política de seguridad para todo el espacio de objetos de estamáquina

/WebSEAL/< host >/<archivo >Esta entrada de subdirectorio representa el objeto de recurso comprobado para elacceso HTTP. Los permisos comprobados dependerán de la operación que sesolicite.

Permisos ACL de WebSEALLa tabla siguiente describe los permisos ACL aplicables para la región WebSEALdel 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 espacio de objetos deWebSEAL.)

l list Requerido por Policy Server para generar una lista dedirectorios automatizada del espacio web.

Este permiso rige también si un cliente puede ver la lista decontenido del directorio cuando no se encuentra la páginapredeterminada “index.html”.

g delegation Concede fiabilidad a un servidor WebSEAL para que actúe ennombre de un cliente y pase las peticiones a un servidorWebSEAL con conexión (junction).

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

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

El grupo, webseal-servers, contiene una entrada para cada servidor WebSEAL enel dominio seguro. Los permisos predeterminados permiten a los servidoresresponder a las peticiones del navegador.

El permiso traverse permite la expansión del espacio web tal y como se representaen Web Portal Manager. El permiso list permite a Web Portal Manager visualizar elcontenido del espacio web.

Caracteres válidos para nombres de ACLLos siguientes caracteres son válidos para crear nombres de ACL:v A-Zv a-zv subrayado (_)v guión (-)v barra inclinada invertida (\)v Cualquier carácter de un juego de caracteres de doble byte

Para obtener información detallada acerca de la creación de nombres de ACL,consulte la publicación IBM Tivoli Base Guía del administrador.


Política de inicio de sesión en tres intentosLa política de inicio de sesión en tres intentos, disponible para instalaciones deAccess Manager basadas en LDAP, permite especificar un número máximo deintentos de inicio de sesión fallidos (n) y un tiempo de bloqueo de penalización (x),de forma que si se producen “n” intentos de inicio de sesión fallidos, el usuarioqueda bloqueado durante “x” segundos (o se inhabilita la cuenta).

La política de inicio de sesión en tres intentos se utiliza para evitar ataques decontraseñas contra el sistema. La política crea una condición por la cual el usuariodebe esperar un período de tiempo antes de realizar otros intentos después delerror de un inicio de sesión. Por ejemplo, una política puede indicar que despuésde 3 intentos fallidos debe producirse una penalización de 180 segundos. Este tipode política de inicio de sesión puede evitar que los intentos de inicio de sesióngenerados por un sistema de forma aleatoria se produzcan muchas veces porsegundo.

La política de inicio de sesión en tres intentos requiere la contribución conjunta dedos valores del comando pdadmin policy:v Número máximo de intentos de inicio de sesión fallidos

policy set max-login-failures

v Penalización al exceder el valor de intentos de inicio de sesión fallidospolicy set disable-time-interval

El valor de penalización puede incluir un intervalo de tiempo de bloqueo de lacuenta o una inhabilitación total de ésta.

Si se ha establecido una política de inicio de sesión (como ejemplo) en tres intentosfallidos seguidos de una penalización de tiempo de bloqueo específica, un cuartointento (correcto o incorrecto) dará como resultado una página de error queindicará que la cuenta no está disponible temporalmente debido a la política decontraseñas.

El intervalo de tiempo se especifica en segundos (el intervalo mínimorecomendado es de 60 segundos).

Si la política disable-time-interval está establecida en “disable” (inhabilitado), sebloquea la cuenta para este usuario y el atributo account valid (cuenta válida) deLDAP se establece en “no” para el usuario. Un administrador puede volver ahabilitar la cuenta a través de Web Portal Manager.

Nota: Si se establece disable-time-interval en “disable” se producirá unasobrecarga de administración adicional. Pueden experimentarse dilaciones alreplicar la información de account valid (cuenta válida) en el servidorWebSEAL. Esta situación dependerá del entorno LDAP. Además, algunasimplementaciones de LDAP pueden experimentar una degradación delrendimiento como consecuencia de la operación de actualización de accountvalid (cuenta válida). Por estos motivos es recomendable el uso de unintervalo de tiempo de espera.

Sintaxis de los comandosLos siguientes comandos pdadmin son apropiados sólo para su uso con unregistro LDAP.

Capítulo 4. Política de seguridad de WebSEAL 91

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 de intentos deinicio de sesión fallidos permitidos antes de imponer unapenalización. Este comando depende de una penalizaciónestablecida en el comando policy set disable-time-interval.

Como administrador, puede aplicar esta política a un usuarioespecífico o bien de forma global a todos los usuarios listados en elregistro 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>]

Gestiona la política de penalizaciones controlando el período detiempo que debe inhabilitarse una cuenta si se ha alcanzado elnúmero máximo de intentos de inicio de sesión fallidos.

Como administrador, puede aplicar esta política de penalizacionesa un usuario específico o bien de forma global a todos los usuarioslistados en el registro LDAP.

El valor predeterminado es 180 segundos.

Política de intensidad de contraseñasLa política de intensidad de contraseñas, disponible para instalaciones de AccessManager basadas en LDAP, hace referencia a las estipulaciones de las reglas de lapolítica de contraseñas para la construcción de una contraseña. Access Managerproporciona dos formas de controlar la política de intensidad de contraseñas:v Cinco comandos pdadmin de política de contraseñasv Un módulo PAM (plugable authentication module) que le permite personalizar

una política de contraseñasConsulte la publicación IBM Tivoli Access Manager WebSEAL Developer’s Reference.

Política de intensidad de contraseñas establecida por elprograma de utilidad pdadmin

Los cinco atributos de intensidad de contraseñas implementados a través delprograma de utilidad pdadmin son:v Longitud mínima de la contraseñav Caracteres alfabéticos mínimosv Caracteres no alfabéticos mínimosv Número máximo de caracteres repetidosv Espacios permitidos

Estas políticas se aplican al crear un usuario con pdadmin o con Web PortalManager y cuando se cambia una contraseña con pdadmin, con Web PortalManager o con el programa de utilidad pkmspasswd.


Sintaxis de los comandosLos siguientes comandos pdadmin sólo son apropiados para el uso con un registroLDAP. La opción unset inhabilita este atributo de política, es decir, que no seaplica 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 de unacontraseña.

Como administrador, puede aplicar esta política a un usuarioespecífico o bien de forma global a todos los usuarios listados en elregistro 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 de caracteresalfabéticos permitidos en una contraseña.



policy set min-password-non-alphas {<número>|unset} [-user <nombre-usuario>]

policy get min-password-non-alphas [-user <nombre-usuario>]

Gestiona la política controlando el número mínimo de caracteresno alfabéticos (numéricos) permitidos en 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 de caracteresrepetidos 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 una contraseña puede contenerespacios.


El valor predeterminado es unset (no establecido).

Valores predeterminados de los parámetros de políticaLa tabla siguiente lista los parámetros de política y los valores predeterminados:

Parámetro Valor predeterminado

min-password-length 8

min-password-alphas 4

min-password-non-alphas 1

max-password-repeated-chars 2

password-spaces unset

Para crear el comportamiento de la política de contraseñas que se encuentra enreleases anteriores de Access Manager, aplique la opción unset a cada uno de loscinco 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 los resultados de lapolítica según los valores predeterminados de los cinco parámetros de pdadmin:

Ejemplo Resultado

password No válida: debe contener al menos un carácter no alfabé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 caracteres alfabéticos.

password3 Válida.

Valores globales y específicos para un usuarioLos comandos pdadmin policy se pueden establecer para un usuario específico(con la opción -user) o bien globalmente (sin utilizar la opción -user). Los valoresespecíficos para un usuario prevalecen sobre los valores globales de la política.También puede inhabilitar (unset) un parámetro de política, lo que significa que elparámetro no contiene ningún valor. No se comprobarán ni se aplicarán laspolíticas que tengan la opción unset.

Por ejemplo:pdadmin> policy set min-password-length 8

pdadmin> policy set min-password-length 4 -user miguel


pdadmin> policy get min-password-length

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 de contraseña de 4caracteres; los demás tienen una política de longitud mí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 longitud mínima decontraseña de 8 caracteres.pdadmin> policy set min-password-length unset

Ahora ningún usuario, ni siquiera el usuario miguel, tiene una política de longitudmínima de la contraseña.

Política POP de intensidad de autenticación (incremental)Puede utilizar políticas de objetos protegidos (POP) para aplicar determinadascondiciones de acceso en recursos específicos. La política POP de intensidad deautenticación hace posible el control del acceso a objetos en función del método deautenticación.

Puede utilizar estas funciones (conocidas a veces como autenticación incremental)para garantizar que los usuarios que acceden a recursos más confidenciales utilicenun mecanismo de autenticación más potente. Tal vez prefiera esta condición,debido a la mayor amenaza que representa el acceso inadecuado a determinadosrecursos.

Por ejemplo, puede proporcionar una mayor seguridad a una región con conexión(junction) del espacio web aplicando una política POP incremental que requiera unnivel mayor de autenticación del que ha utilizado el cliente al entrar inicialmenteen el dominio WebSEAL.

La política de intensidad de autenticación está establecida en el atributo Método deautenticación de punto final de IP de una política POP.

Configuración de los niveles de autenticación incrementalEl primer paso al configurar el acceso específico de la autenticación es configurarlos métodos de autenticación soportados y determinar el orden de importancia deestos métodos de autenticación.

Cualquier cliente que accede a un servidor WebSEAL tiene un nivel deautenticación, como “unauthenticated” (no autenticado) o “password” (contraseña),que indica el método mediante el cual se ha autenticado el cliente por última vezcon WebSEAL.

Es posible que en algunas situaciones sea necesario aplicar los niveles mínimos de“seguridad” de la autenticación necesarios para acceder a ciertos recursos. Porejemplo, es posible que en un entorno se considere que la autenticación mediantecódigo de paso de señal es más segura que la autenticación mediante nombre deusuario y contraseña. Otro entorno puede requerir estándares distintos.


En lugar de forzar a los clientes a reiniciar sus sesiones con WebSEAL cuando nocumplen el nivel requerido de autenticación, el mecanismo de autenticaciónincremental proporciona a los clientes una segunda oportunidad de volver aautenticarse utilizando el método (nivel) necesario.

La autenticación incremental significa que el usuario no recibe inmediatamente unmensaje de “acceso denegado” cuando intenta acceder a un recurso que requiereun nivel de autenticación “mayor” que el del inicio de sesión, sino que ve unapetición de autenticación nueva que solicita información para dar soporte a unmayor nivel de autenticación. Si puede proporcionar ese nivel, se permitirá supetición original.

WebSEAL reconoce tres métodos de autenticación (niveles) para utilizarlos en elmecanismo de autenticación incremental:v unauthenticated (no autenticado)v password (contraseña)v token-card (tarjeta de señal)

Los niveles de autenticación se configuran en la stanza [authentication-levels] delarchivo de configuración webseald.conf. Inicialmente, sólo hay configurados dosniveles:[authentication-levels]level = unauthenticatedlevel = password

Según el orden de los métodos en la lista, se asigna un índice de nivel, del 0 al 2, acada método.v El método “unauthenticated” (no autenticado) debe ser siempre el primero de la

lista y tiene asignado el índice de nivel 0.v Los métodos siguientes pueden estar en cualquier orden.

Consulte el apartado “Notas y limitaciones de autenticación incremental” en lapágina 99.

v De forma predeterminada, “password” (contraseña) aparece en el nivelsiguiente, por lo que se encuentra en el índice de nivel 1.

v Debe haber al menos dos entradas para habilitar la autenticación incremental.

Nota: Consulte el apartado Capítulo 5, “Autenticación de WebSEAL” en lapágina 107 para obtener información detallada acerca de la configuración delos mecanismos de autenticación necesarios.

Habilitación de la autenticación incrementalLa autenticación incremental se implementa mediante una política POP asociadacon los objetos que requieren una autorización de autenticación confidencial.Utilice el atributo Método de autenticación de punto final de IP de una políticaPOP.

El comando pdadmin pop modify set ipauth especifica las redes permitidas y elnivel de autenticación necesario en el atributo Método de autenticación de puntofinal de IP.

Los niveles de autenticación configurados se pueden vincular a rangos dedirecciones IP. Este método se ha concebido para proporcionar una flexibilidad degestión. Si no es importante el filtro de usuarios por dirección IP, puede estableceruna sola entrada para anyothernw (cualquier otra red). Este valor afectará a todos


los usuarios que accedan, independientemente de la dirección IP, y les solicitaráque se autentiquen en el nivel especificado. Es el método más habitual paraimplementar la autenticación incremental.

Sintaxis:pdadmin> pop modify <nombre-pop> set ipauth anyothernw <índice-nivel>

La entrada anyothernw se utiliza como rango de red que coincidirá con cualquierred que no esté especificada en la política POP. Este método se utiliza para crearuna entrada predeterminada que puede rechazar todas las direcciones IP nocoincidentes o permitir el acceso a cualquiera que cumpla el requisito de nivel deautenticación.

anyothernw aparece de forma predeterminada en una política POP con el índicede nivel de autenticación 0. La entrada aparece como “Cualquier otra red” en elcomando pop 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 punto final 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 punto final de IP de lapolítica POP:pdadmin> pop modify test set ipauth anyothernw 1

pdadmin> pop show testPolítica de objetos protegidos: testDescripció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 punto final de IP


Esta política requiere incrementar la autenticación al método de autenticaciónde tarjeta de señal (nivel 1) para todos los usuarios que acceden inicialmentecomo “no autenticados” (nivel 0). A todos los usuarios no autenticados queintenten acceder a los objetos protegidos por esta política POP se les solicitaráel nombre de usuario y el código de paso de señal.

Consulte también el apartado “Política POP de autenticación basada en la red”en la página 101.

Formulario de inicio de sesión incrementalWebSEAL presenta un formulario especial cuando la política POP incremental delrecurso solicitado fuerza la reautenticación del cliente. La ubicación de este


formulario HTML se especifica mediante el parámetro stepup-login de la stanza[acnt-mgt] del archivo de configuración webseald.conf.[acnt-mgt]stepup-login = stepuplogin.html

Puede configurar este formulario HTML para que cumpla sus requisitos, de lamisma forma que puede configurar los formularios login.html o tokenlogin.html.

Este archivo contiene macros, en forma de secuencias %TEXTO%, que se sustituyenpor los valores apropiados. Esta sustitución se produce en las funciones de procesodel archivo de plantilla de WebSEAL y permite el uso del formulario para losmétodos de autenticación de contraseña y señal con el formato correcto. Tambiénpermite proporcionar otra información, como el mensaje de error y el nombre demétodo (incremental), en el formulario para el usuario.

Algoritmo de autenticación incrementalWebSEAL utiliza el siguiente algoritmo para procesar las condiciones de unapolítica POP:

Figura 18. Formulario de inicio de sesión personalizado incremental para nombre de usuarioy contraseña

Figura 19. Formulario de inicio de sesión personalizado incremental para código de paso deseñal de SecurID


1. Comprobar la política de método de autenticación de punto final de IP de lapolítica POP.

2. Comprobar los permisos ACL.3. Comprobar la política de acceso según la hora del día de la política POP.4. Comprobar la política de nivel de auditoría de la política POP.

Notas y limitaciones de 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 lista de niveles y

no puede encontrarse en ningún otro puesto de la lista.4. Los métodos sólo se pueden especificar una vez en la lista de niveles.5. La autenticación de certificados no es un método soportado para la

autenticación incremental.

Nota: La autenticación incremental gestiona certificados de cliente como casoespecial. Si un cliente accede a WebSEAL con un certificado de cliente yWebSEAL está configurado para aceptar certificados, el cliente se tratarácomo no autenticado con el índice de nivel 0.

Del método: Se puede pasar a:

unauthenticated password token-card

password token-card

token-card password

6. Los métodos de autenticación representan los niveles de autenticación. Estosignifica que es imposible especificar un mecanismo de autenticación precisopara la autenticación en ese nivel.Los métodos de autenticación pueden estar soportados por varios mecanismosde autenticación, incluidos los autenticadores locales y los autenticadoresexternos personalizados.WebSEAL sigue reglas específicas para determinar el autenticador que se debeseleccionar cuando se han configurado varias instancias del mismo tipo demétodo de autenticación.

7. Si hay tres niveles configurados, los valores de índice válidos son 0, 1 y 2. Sihay algún otro valor de índice configurado, WebSEAL presenta una página deerror siempre que se solicita un objeto asociado con esa política POP.

8. La configuración incorrecta de los niveles de autenticación incremental en elarchivo de configuración webseald.conf da como resultado la inhabilitación dela funcionalidad incremental en WebSEAL. Esta situación puede producircomportamientos inesperados de autenticación como, por ejemplo, la emisiónde la página de inicio de sesión de contraseña para objetos protegidos por unapolítica POP que requiera el método de autenticación de código de paso deseñal.Después de configurar los niveles de autenticación incremental, compruebe elarchivo webseald.log para ver si hay informes de errores de configuración.


Distinción entre autenticación incremental y de múltiplesfactores

La autenticación incremental y la autenticación de múltiples factores de AccessManager son dos mecanismos diferentes y separados de control del acceso a losrecursos. Access Manager sólo proporciona funciones de autenticación incremental,que se describen en este capítulo.

La autenticación de múltiples factores obliga al usuario a autenticarse utilizandodos o más niveles de autenticación. Por ejemplo, el control de acceso en un recursoprotegido puede requerir que el usuario se autentique con el nombre deusuario/contraseña y con el nombre de usuario/código de paso de señal.

La autenticación incremental de Access Manager se basa en una jerarquíapreconfigurada de niveles de autenticación y aplica un nivel específico deautenticación según la política establecida en un recurso. La autenticaciónincremental no obliga al usuario a autenticarse utilizando múltiples niveles deautenticación para acceder a cualquier recurso dado, sino que la autenticaciónincremental requiere que el usuario se autentique a un nivel por lo menos tan altocomo necesite la política que protege el recurso.

Ejemplo de autenticación incremental:

Niveles de autenticación configurados:v nivel de autenticación 1 = nombre usuario/contraseñav nivel de autenticación 2 = nombre usuario/código paso señal

El siguiente objeto está protegido por una POP que requiere el nivel deautenticación 1:/WebSEAL/hostA/junction

El siguiente objeto está protegido por una POP que requiere el nivel deautenticación 2:/WebSEAL/hostA/junction/aplicaciónA

Bajo la autenticación incremental, la autenticación de nombre deusuario/contraseña es necesaria para acceder a /WebSEAL/hostA/junction.

No obstante, la autenticación de nombre de usuario/código de paso de señal (nivel2) es necesaria para acceder a /WebSEAL/hostA/junction/aplicaciónA. Si el usuarioha iniciado la sesión con un nombre de usuario y una contraseña, aparece unasolicitud que solicita la información de nombre de usuario y de código de paso deseñal (incremental). No obstante, si el usuario inicia la sesión inicialmente enWebSEAL con el nombre de usuario y el código de paso de señal, el acceso aaplicaciónA es inmediato (suponiendo que haya una comprobación positiva deACL).

La autenticación de múltiples factores requeriría ambas autenticaciones de nivel 1 yde nivel 2 para acceder a aplicaciónA.


Política POP de autenticación basada en la redLa política POP de autenticación basada en la red hace posible el control del accesoa objetos en función de la dirección IP del usuario. Puede utilizar esta función paraevitar que direcciones IP específicas (o rangos de direcciones IP) accedan acualquier recurso del dominio seguro.

También puede aplicar la configuración de la autenticación incremental a estapolítica y solicitar un método de autenticación específico para cada rango dedirecciones IP especificado.

La política de autenticación basada en la red está establecida en el atributo Métodode autenticación de punto final de IP de una política POP. Debe especificar dosrequisitos en este atributo:v Niveles de autenticaciónv Redes permitidas

Configuración de niveles de autenticaciónWebSEAL reconoce tres métodos de autenticación para utilizarlos en el mecanismode autenticación incremental:v unauthenticated (no autenticado)v password (contraseña)v token-card (tarjeta de señal)

Según el orden de los métodos en la lista, se asigna un índice de nivel, del 0 al 2, acada método.

Los niveles de autenticación se configuran en la stanza [authentication-levels] delarchivo de configuración webseald.conf. Inicialmente, sólo hay configurados dosniveles:[authentication-levels]level = unauthenticatedlevel = password

Puede utilizar estos valores predeterminados cuando configure la autenticaciónbasada en la red. En ese caso, “unauthenticated” (no autenticado) es el nivel 0 y“password” (contraseña) es el nivel 1.

Consulte también el apartado “Configuración de los niveles de autenticaciónincremental” en la página 95.

Especificación de direcciones IP y rangosEspecifique las direcciones IP y los rangos de direcciones IP permitidos por estapolítica POP.

El comando pdadmin pop modify set ipauth add especifica tanto la red (o rangode redes) como el nivel de autenticación requerido en el atributo Método deautenticación de punto final de IP.

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 los rangos dedirecciones IP. Este método se ha concebido para proporcionar flexibilidad. Si no es


importante el filtro de usuarios por dirección IP, puede establecer una sola entradapara anyothernw (cualquier otra red). Este valor afectará a todos los usuarios queaccedan, independientemente de la dirección IP, y les solicitará que se autentiquenen el nivel especificado.

Sintaxis:pdadmin> pop modify <nombre-pop> set ipauth anyothernw <índice-nivel>

De lo contrario, si desea omitir el nivel de autenticación y permitir o denegar elacceso sólo según la dirección IP, puede utilizar el nivel 0 para los rangos quedesee permitir y “forbidden” (prohibido) para los rangos que desee rechazar.

La entrada anyothernw se utiliza como rango de red que coincide con cualquierred que no esté especificada en la política POP. Este método se utiliza para crearuna entrada predeterminada que puede rechazar todas las direcciones IP nocoincidentes o permitir el acceso a cualquiera que cumpla el requisito de nivel deautenticación.

anyothernw aparece de forma predeterminada en una política POP con el índicede nivel de autenticación 0. La entrada aparece como “Cualquier otra red” en elcomando pop 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 punto final de IP


Consulte el apartado “Configuración de los niveles de autenticación incremental”en la página 95 para obtener información detallada acerca de la configuración de

los niveles de autenticación.

EjemplosPara solicitar a los usuarios del rango de direcciones IP 9.0.0.0 y máscara de red255.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 de autenticació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 en los ejemplosanteriores) tengan acceso al objeto:pdadmin> pop modify test set ipauth anyothernw forbidden

Inhabilitación de la autenticación incremental por dirección IPSintaxis: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 redWebSEAL utiliza el siguiente algoritmo para procesar las condiciones de unapolítica POP:1. Comprobar la política de método de autenticación de punto final de 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 la política POP.4. Comprobar la política de nivel de auditoría de la política POP.

Notas y limitaciones de autenticación basada en redLa dirección IP que utiliza WebSEAL para aplicar la política de autenticaciónbasada en la red debe ser la del originador de la conexión TCP. Si la topología dela red utiliza proxies HTTP, la dirección que reciba WebSEAL puede ser ladirección IP del servidor proxy.

En tal caso, WebSEAL no puede identificar de forma definitiva la dirección IPverdadera del cliente. Debe tener cuidado al configurar una política deautenticación basada en la red para que los clientes de la red puedan conectarsedirectamente con el servidor WebSEAL.

Política POP de calidad de protecciónEl atributo POP de calidad de protección le permite especificar el nivel deprotección de datos necesario al realizar una operación en un objeto.

Actualmente, este atributo sólo es apropiado en un entorno WebSEAL.

El atributo POP de calidad de protección es la sustitución de los bits de permisosACL “P” e “I” que activaban los requisitos de privacidad e integridad en lasversiones anteriores de Access Manager. Esta implementación anterior de la calidadde protección no era eficaz y minaba el rendimiento del sistema.

El atributo POP de calidad de protección permite una sola transacción donde larespuesta “yes” a la decisión de ACL incluye también el nivel de calidad deprotección requerido. Si el gestor de recursos (como WebSEAL) no puedegarantizar el nivel de protecció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).

Integrity(Integridad)

Utilizar algún mecanismo para garantizar que no han cambiado losdatos.

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 no autenticados a travésde HTTP y HTTPS. WebSEAL utiliza entonces en el servicio de autorizaciones paraaplicar la política de seguridad y permitir o rechazar el acceso a los recursosprotegidos.

Las siguientes condiciones son aplicables para los usuarios no autenticados queacceden a través de SSL:v El intercambio de información entre el usuario no autenticado y WebSEAL está

cifrado, de la misma forma que con los usuarios autenticados.v Las conexiones SSL entre usuarios no autenticados y WebSEAL sólo requieren la

autenticación de servidor.

Proceso de una petición de 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 web protegido.4. El servicio de autorizaciones comprueba los permisos en la entrada no

autenticada de ACL para este objeto y permite o rechaza la operaciónsolicitada.

5. El acceso correcto a ese objeto depende de que la entrada de ACL noautenticada contenga al menos los permisos read (r) y traverse (T).

6. Si la petición no supera la decisión de autorización, el cliente recibe unformulario de inicio de sesión (basado en formularios o BA).

Obligación del inicio de sesión de usuarioPuede obligar a un usuario no autenticado a que inicie una sesión estableciendocorrectamente los permisos apropiados en la entrada no autenticada de la políticade ACL que protege el objeto solicitado.

Los permisos read (r) y traverse (T) permiten a los usuarios no autenticados elacceso a un objeto.

Para obligar al usuario no autenticado a iniciar una sesión, elimine el permiso read(r) de la entrada no autenticada de la política de ACL que protege el objeto. Elusuario recibirá una solicitud de inicio de sesión (basado en formularios o BA).

Aplicaciones HTTPS sin autenticarHay muchos motivos empresariales prácticos para dar soporte al acceso noautenticado a WebSEAL a través de HTTPS:v Algunas aplicaciones no requieren un inicio de sesión personal, pero sí

información confidencial como, por ejemplo, direcciones y números de tarjeta decrédito. Es el caso de las compras en línea de billetes de avión u otros productos.

v Algunas aplicaciones requieren que el usuario registre una cuenta en la empresaantes de proceder con otras transacciones. Para ello, se debe pasar informaciónconfidencial por la red.


Control de usuarios no autenticados con políticas deACL/POP

Nota: El tipo de entrada “any-authenticated” (cualquier autenticado) esequivalente al tipo de entrada “any-other” (cualquier otro).

1. Para permitir el acceso de un usuario no autenticado a los objetos públicos,proteja el contenido público con una ACL que contenga al menos los permisosread (r) y traverse (T) para las entradas unauthenticated (no autenticado) yany-authenticated (cualquier autenticado):unauthenticated Trany-authenticated Tr

Nota: La entrada unauthenticated es una máscara (una operación “and” anivel de bit) contra la entrada any-authenticated cuando se determinanlos permisos. Sólo se otorga un permiso para unauthenticated si ésteaparece también en la entrada any-authenticated. Puesto queunauthenticated depende de any-authenticated, no tiene sentido queuna ACL contenga unauthenticated sin any-authenticated. Si una ACLcontiene unauthenticated sin any-authenticated, la respuestapredeterminada es no otorgar ningún permiso a unauthenticated.

2. Para requerir el cifrado (SSL), proteja el contenido con una política de objetosprotegidos (POP) que especifica la privacidad como una condición.Consulte el apartado “Política POP de calidad de protección” en la página 103.


Capítulo 5. Autenticación de WebSEAL

En este capítulo se describe cómo WebSEAL mantiene el estado de la sesión ycontrola el proceso de autenticación. Una autenticación correcta produce unaidentidad de Access Manager que representa al usuario. WebSEAL utiliza estaidentidad para adquirir las credenciales para este usuario. El servicio deautorizaciones utiliza las credenciales para permitir o denegar el acceso a losrecursos protegidos.

Índice de temas:v “Información sobre el proceso de autenticación” en la página 107v “Gestión del estado de la sesión” en la página 109v “Visión general de la configuración de autenticación” en la página 118v “Configuración de la autenticación básica” en la página 122v “Configuración de la autenticación de formularios” en la página 123v “Configuración de la autenticación de certificados del cliente” en la página 125v “Configuración de la autenticación de cabeceras HTTP” en la página 128v “Configuración de autenticación de direcciones IP” en la página 130v “Configuración de la autenticación de señales” en la página 130v “Soporte para agentes MPA (Multiplexing Proxy Agents)” en la página 131v “Configuración de la reautenticación basada en la política de seguridad” en la

página 134v “Configuración de la reautenticación basada en la política de inactividad de

sesión” en la página 137

Información sobre el proceso de autenticaciónLa autenticación es el método para identificar un proceso o entidad individual queintenta conectarse a un dominio seguro.v WebSEAL da soporte a varios métodos de autenticación de forma

predeterminada y se puede personalizar para que utilice otros métodos.v El resultado de la autenticación correcta en WebSEAL es una identidad en el

registro de usuarios de Access Manager.v WebSEAL utiliza esta identidad para obtener una credencial para ese usuario.v El servicio de autorizaciones utiliza esta credencial para permitir o denegar el

acceso a los objetos protegidos después de evaluar los permisos ACL y lascondiciones de POP que rigen la política para cada objeto.

Nota: ACL = política de lista de control de accesos POP; = política de objetosprotegidos

Durante la autenticación, WebSEAL examina la petición de cliente y busca lasiguiente información:v Datos de sesión

Los datos de sesión es información que identifica una conexión específica entreel cliente y el servidor WebSEAL. Los datos de sesión se almacenan en el clientey acompañan a las siguientes peticiones del cliente. Se utilizan para volver a


identificar la sesión de cliente en el servidor WebSEAL y evitar la sobrecarga deestablecer una nueva sesión en cada petición.

v Datos de autenticación

Los datos de autenticación es información del cliente que permite identificarloen el servidor WebSEAL. Los tipos de datos de autenticación son los certificadosde cliente, las contraseñas y los códigos de señal.

Cuando WebSEAL recibe una petición de cliente, busca siempre en primer lugarlos datos de sesión y, a continuación, los datos de autenticación. La petición decliente inicial no contiene nunca datos de 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 servidor3. Datos de cabecera BA4. Datos de cabecera HTTP5. Dirección IP

Cuando WebSEAL examina una petición de cliente, busca los datos de sesión en elorden especificado en esta lista.

Métodos de autenticación soportadosAunque WebSEAL funciona de manera independiente del proceso de autenticación,WebSEAL utiliza credenciales para supervisar a todos los usuarios que participanen el dominio seguro. Para obtener la información de identidad necesaria para laadquisición de credenciales, 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 para la adquisiciónde credenciales:

Método de autenticación Tipo de conexiónsoportado

1. Cookie de resolución de errores 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 de usuario ycontraseña)

HTTP y HTTPS

6. Autenticación básica (nombre de usuario y contraseñ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 datos deautenticación en el orden especificado en esta tabla.

Los métodos de autenticación se pueden habilitar e inhabilitar de maneraindependiente para los transportes HTTP y HTTPS. Si no se habilita ningún


método de autenticación para un transporte determinado, el proceso deautenticación estará desactivado para los clientes que utilicen ese transporte.

Gestión del estado de la sesiónUna conexión o sesión segura entre un cliente y un servidor requiere que elservidor tenga la posibilidad de recordar, a través de numerosas peticiones, conquién está hablando. El servidor debe tener algún tipo de información de estadode la sesión que identifique al cliente asociado con cada petición.

Este apartado contiene los temas siguientes:v “Visión general del estado de la sesión” en la página 109v “Visión general de la caché de sesión de GSKit y WebSEAL” en la página 109v “Configuración de la caché de ID de sesión SSL de GSKit” en la página 110v “Configuración de la caché de sesión/credenciales de WebSEAL” en la página

111v “Mantenimiento del estado con cookies de sesión” en la página 112v “Determinación de los tipos de datos válidos de ID de sesión” en la página 114v “Configuración de cookies de resolución de errores” en la página 115

Visión general del estado de la sesiónSin un estado de la sesión establecido entre el cliente y el servidor, la comunicaciónentre el cliente y el servidor se debe renegociar para cada petición posterior. Lainformación sobre el estado de la sesión mejora el rendimiento, ya que evita tenerque cerrar y volver a abrir repetidamente las conexiones entre cliente y servidor. Elcliente puede iniciar la sesión una vez y realizar numerosas peticiones sin realizarun inicio de sesión distinto para cada petición.

WebSEAL maneja la comunicación HTTP y HTTPS. HTTP es un protocolo “sininformación de estado” y no proporciona ninguna forma para distinguir unapetición de otra. Por otro lado, el protocolo de transporte SSL está especialmentediseñado para proporcionar un ID de sesión para mantener la información deestado de la sesión. La comunicación HTTP se puede encapsular en SSL paraconvertirse en HTTPS.

No obstante, WebSEAL debe manejar a menudo comunicaciones HTTP de clientessin autenticar. Y hay casos en los que el ID de sesión SSL no es la mejor solución.Por lo tanto, WebSEAL está diseñado para utilizar cualquiera de los siguientestipos de información para mantener el estado de la sesión con un cliente:1. ID de SSL2. Cookie de sesión específica del servidor3. Datos de cabecera BA4. Datos de cabecera HTTP5. Dirección IP

Visión general de la caché de sesión de GSKit y WebSEALLa caché de sesión permite a un servidor almacenar la información de ID de sesiónde varios clientes. WebSEAL utiliza dos tipos de cachés de sesión para acomodarinformación de estado de la sesión HTTPS y HTTP.v Caché de sesión/credenciales de WebSEAL

Capítulo 5. Autenticación de WebSEAL 109

La caché de sesión/credenciales de WebSEAL almacena cualquier tipo deinformación de ID de sesión (vea la lista anterior), así como la información decredenciales que se haya obtenido para cada cliente.La información de credenciales se guarda en la caché para eliminar las consultasrepetitivas a la base de datos de registro de usuarios durante las comprobacionesde autorizaciones.

v Caché de ID de sesión SSL de GSKitLa caché de sesión de GSKit maneja la comunicación HTTPS (SSL) cuando seutiliza la información de ID de sesión SSL para mantener el estado de la sesión.La caché de GSKit también mantiene la información de estado de la sesión parala conexión SSL entre WebSEAL y el registro de usuarios de LDAP.

Hay disponibles varios parámetros de configuración para cada caché que permitenajustar el rendimiento de la caché. Estos parámetros se resumen en la siguientefigura

Configuración de la caché de ID de sesión SSL de GSKitLas siguientes tareas de configuración están disponibles para la caché de ID desesión SSL de GSKit:v Definición del valor de tiempo de espera de entrada de cachév Definición del valor máximo de entradas simultáneas

Definición del valor de tiempo de espera de entrada de cachéLos parámetros para establecer el tiempo de espera máximo de duración para unaentrada en la caché de ID de sesión SSL de GSKit se encuentran en la stanza [ssl]del archivo de configuración webseald.conf. Existen dos parámetros: uno para lasconexiones SSL 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 (en segundos) es 100 (conun valor posible entre 1 y 100):[ssl]ssl-v2-timeout = 100

El tiempo de espera predeterminado de la sesión SSL V3 (en segundos) es 7200(con un valor posible entre 1 y 86400):

Figura 20. Parámetros de configuración de caché de sesión


[ssl]ssl-v3-timeout = 7200

Definición del valor máximo de entradas simultáneasEl parámetro ssl-max-entries, que se encuentra en la stanza [ssl] del archivo deconfiguración webseald.conf, establece el número máximo de entradas simultáneasen la caché de ID de sesión SSL de GSKit.

Este valor se corresponde con el número de inicios de sesión simultáneos. Cuandoel tamaño de la caché alcanza este valor, se eliminan entradas de la caché, según elalgoritmo de menos utilizado recientemente, para permitir nuevos inicios de sesiónentrantes.

El número predeterminado de inicios de sesión simultáneos es 4096:[ssl]ssl-max-entries = 4096

Configuración de la caché de sesión/credenciales deWebSEAL

Las siguientes tareas de configuración están disponibles para la caché decredenciales/sesión de WebSEAL:v Definición del valor máximo de entradas simultáneasv Definición del valor de tiempo de espera de duración de la entrada de cachév Definición del valor del tiempo de espera de inactividad de entrada de caché

Definición del valor máximo de entradas simultáneasEl parámetro max-entries, ubicado en la stanza [session] del archivo deconfiguración webseald.conf, establece el número máximo de entradas simultáneasen la caché de sesión/credenciales de WebSEAL.

Este valor se corresponde con el número de inicios de sesión simultáneos. Cuandoel tamaño de la caché alcanza este valor, se eliminan entradas de la caché, según elalgoritmo de menos utilizado recientemente, para permitir nuevos inicios de sesiónentrantes.

El número predeterminado de inicios de sesión simultáneos es 4096:[session]max-entries = 4096

Definición del valor de tiempo de espera de duración de laentrada de cachéEl parámetro timeout, ubicado en la stanza [session] del archivo de configuraciónwebseald.conf, establece el valor máximo del tiempo de espera de duración paratodas las sesiones de usuario que están almacenadas en la caché desesión/credenciales de WebSEAL.

WebSEAL almacena internamente en la caché la información de credenciales. Elparámetro de tiempo de espera de la caché de la sesión establece el tiempo duranteel que la información de la credencial de autorizaciones permanece en la memoriade WebSEAL.

El parámetro no es un tiempo de espera de inactividad. El valor se correlacionacon una “duración de credencial” en lugar de un “tiempo de espera de inactividadde sesión”. Su objetivo es mejorar la seguridad forzando al usuario lareautenticación cuando se alcanza el límite de tiempo de espera especificado.


El tiempo de espera predeterminado de duración de la entrada de caché de sesión(en segundos) es de 3600:[session]timeout = 3600

Definición del valor del tiempo de espera de inactividad deentrada de cachéEl parámetro inactive-timeout, ubicado en la stanza [session] del archivo deconfiguración webseald.conf, establece el valor del tiempo de espera deinactividad de la sesión del usuario.

El tiempo de espera predeterminado de inactividad en el inicio de la sesión (ensegundos) es 600:[session]inactive-timeout = 600

Para inhabilitar esta función de tiempo de espera, establezca el valor del parámetroen “0”.

Mantenimiento del estado con cookies de sesiónUn método para mantener el estado de la sesión entre un cliente y un servidor esutilizar una cookie para retener la información de esta sesión. El servidorempaqueta la información de estado para un cliente concreto en una cookie y laenvía al navegador del cliente. Para cada petición nueva, el navegador se vuelve aidentificar enviando 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 en las que elcliente utiliza un navegador que renegocia su sesión de SSL después de períodosde tiempo breves. Por ejemplo, algunas versiones del navegador Microsoft InternetExplorer renegocian las sesiones de SSL cada dos o tres minutos.

La cookie de sesión sólo proporciona la reautenticación de un cliente para elservidor único que el cliente tenía anteriormente autenticado en un período cortode tiempo (unos diez minutos). El mecanismo se basa en una “cookie de servidor”que no se puede pasar a ninguna máquina que no sea la que ha generado lacookie.

Además, la cookie de la sesión contiene sólo un número de identificador aleatorioque se utiliza para el índice en la caché de la sesión del servidor. No hay másinformación expuesta en la cookie de la sesión, ya que ésta no puede comprometerla política de seguridad.

Información sobre las cookies de sesiónWebSEAL utiliza una cookie de sesión segura específica para el servidor. Lassiguientes condiciones son aplicables a este mecanismo de cookies:v La cookie contiene sólo información sobre la sesión; no contiene información

sobre la identidadv La cookie reside sólo en la memoria del navegador (no se escribe en el

contenedor de cookies del disco)v La cookie tiene una duración limitadav La cookie tiene parámetros de ruta de acceso y de dominio que prohíben su uso

a otros servidores


Habilitación e inhabilitación de las cookies de ID de sesiónEl parámetro ssl-id-sessions, que se encuentra en la stanza [session] del archivo deconfiguración webseald.conf, habilita e inhabilita las cookies de sesión. Esteparámetro controla si se utiliza el ID de sesión SSL para mantener el inicio desesión en los clientes que acceden mediante HTTPS. Si el parámetro se establece en“no”, se utilizan las cookies de sesión en la mayoría de métodos de autenticación.[session]ssl-id-sessions = no

Un valor de configuración “no” para este parámetro da como resultado lassiguientes condiciones en los clientes que acceden mediante HTTPS:1. El ID de sesión SSL no se utiliza nunca como información de ID de sesión.2. Las cookies se utilizarán para mantener las sesiones con los clientes que se

autentiquen con cookies de resolución de errores, señales de ID de CDSSO,nombre de usuario y contraseña de formularios, código de paso de señal ycertificados de clientes.

3. Las cookies se utilizan en los clientes de autenticación básica sólo siuse-same-session = yes (consulte el apartado siguiente). En caso contrario, seutiliza la cabecera BA para los datos de ID de sesión.

4. La cabecera HTTP se utiliza como información de ID de sesión en los clientesque se autentican con cabeceras HTTP.

5. La dirección IP se utiliza como información de ID de sesión en los clientes quese autentican con direcciones IP.

Si se utilizan cookies para mantener el estado de la sesión, la cookie se envía sólouna vez al navegador, después de iniciar la sesión correctamente. No obstante,algunos navegadores imponen un límite al número de cookies en memoria quepueden almacenar simultáneamente. En algunos entornos, las aplicaciones puedencolocar un gran número de cookies en memoria por dominio en los sistemascliente. En este caso, cualquier cookie configurada de sesión de WebSEAL o deresolución de errores se puede sustituir fácilmente por otra cookie.

Cuando se configura WebSEAL para utilizar cookies de sesión (y quizás cookies deresolución de errores), se puede configurar el parámetro resend-webseal-cookies,que se encuentra en la stanza [session] del archivo de configuraciónwebseald.conf, para que WebSEAL envíe la cookie de sesión y la cookie deresolución de errores al navegador con cada respuesta. Esta acción permiteasegurar que la cookie de sesión y la cookie de resolución de errores permanecenen la memoria del navegador.

El parámetro resend-webseal-cookies tiene un valor predeterminado de “no”:[session]resend-webseal-cookies = no

Cambie el valor predeterminado a “yes” para enviar cookies de sesión deWebSEAL y cookies de resolución de errores con cada respuesta.

Habilitación e inhabilitación de las mismas sesionesSe puede configurar WebSEAL para que utilice los datos de ID de la misma sesióncuando un cliente se conecte mediante un tipo de transporte (HTTP, por ejemplo),se desconecte y vuelva a conectarse con otro tipo de transporte (HTTPS, porejemplo).


El parámetro use-same-session, que se encuentra en la stanza [session] del archivode configuración webseald.conf, habilita e inhabilita el reconocimiento de los datosde ID de la misma sesión. De forma predeterminada, este parámetro se estableceen “no”:[session]use-same-session = no

Un valor de configuración “yes” para este parámetro da como resultado lassiguientes condiciones:1. Las cookies de sesión se utilizan para identificar los siguientes tipos de clientes

en las conexiones posteriores mediante otro transporte:a. Cookies de resolución de erroresb. Certificados de clientec. Señal CDSSO IDd. Código de paso de señale. Nombre de usuario y contraseña de formulariosf. Autenticación básica

2. La cabecera HTTP se utiliza para los clientes que acceden con cabeceras HTTP.3. La dirección IP se utiliza para los clientes que acceden con direcciones IP.4. La configuración ssl-id-sessions se omite; el comportamiento que se obtiene es

el mismo que si se estableciera ssl-id-sessions en “no”.Esta lógica es importante porque los clientes HTTP no tienen un ID de sesiónSSL disponible como datos de sesión.

5. Como las cookies están disponibles para los clientes HTTP y HTTPS, no seetiquetan como cookies seguras.

Determinación de los tipos de datos válidos de ID de sesiónEl tipo de datos de sesión para un cliente que accede con un método deautenticación concreto viene determinado por combinaciones específicas de lossiguientes parámetros de configuración:v Habilitación o inhabilitación de las cookies de sesión (ssl-id-sessions)v Habilitación o inhabilitación de la posibilidad de utilizar los datos de la misma

sesión cuando un cliente cambia entre HTTP y HTTPS (use-same-session)

En la tabla siguiente se resumen los datos de ID de sesión válidos para unaconfiguración determinada que combina los parámetros ssl-id-sessions yuse-same-session:

Clientes HTTPS

Método de autenticación ssl-id-sessions = yes ssl-id-sessions = nouse-same-session = no

use-same-session= yesssl-id-sessions ignored

Cookie de resolución deerrores

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


Clientes HTTPS

Método de autenticación ssl-id-sessions = yes ssl-id-sessions = nouse-same-session = no

use-same-session= yesssl-id-sessions ignored

Dirección IP ID de SSL Dirección IP Dirección IP

Clientes HTTP

Método de autenticación use-same-session = no use-same-session = yes

Cookie de resolución deerrores

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

Configuración de cookies de resolución de erroresLa siguiente función de cookie de resolución de errores (para HTTP y HTTPS) estáespecialmente indicada para un cliente que se conecte a un clúster replicado deservidores WebSEAL de fondo a través de un mecanismo de equilibrio de carga. Elobjetivo de las cookies de resolución de errores es evitar que se tenga que repetir laautenticación cuando el servidor que tiene la sesión original con el cliente no estédisponible.

Se puede implementar un clúster WebSEAL frontal para aumentar ladisponibilidad de los recursos para un número mayor de clientes. El mecanismo deequilibrio de carga intercepta las peticiones entrantes y las distribuye entre losservidores frontales disponibles.

Consulte el diagrama siguiente para obtener información detallada.

El cliente no conoce la configuración del servidor frontal replicado. El mecanismode equilibrio de carga es el único punto de contacto de la dirección URL solicitada.

Figura 21. Escenario de cookie de resolución de errores


El mecanismo de equilibrio de carga conecta 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.

El problema que pueden resolver las cookies de resolución de errores implica unasituación en la que el servidor WS1 deja de estar disponible por alguna razón (porejemplo, un error del sistema o una interrupción de la línea por parte deladministrador). Si el servidor WS1 deja de estar disponible, el mecanismo deequilibrio de carga redirecciona la petición a uno de los otros servidores replicados(WS2 o WS3). Se perderá la correlación original de sesión a credencial. El cliente esnuevo para este servidor sustituto, y normalmente deberá volver a autenticarse.

Puede configurar los servidores WebSEAL replicados para que cifren los datos deidentificación del cliente en una cookie específica del servidor. La cookie se colocaen el navegador cuando el cliente se conecta por primera vez. Si el servidorWebSEAL inicial no está disponible temporalmente, la cookie (con la informaciónde identidad cifrada) se presenta al servidor sustituto.

La cookie de resolución de errores contiene el nombre de usuario, la indicación dela hora y el método de autenticación original. Los servidores WebSEAL replicadoscomparten una clave común que puede descifrar la información de la cookie.Cuando el servidor WebSEAL sustituto recibe esta cookie, puede utilizar el nombrede usuario y el método de autenticación para regenerar la credencial del cliente,incluidos los atributos ampliados. El cliente puede establecer ahora una sesiónnueva con un servidor WebSEAL replicado sin que tenga que volver a autenticarse.

El punto de referencia para la cookie es el DNS del mecanismo de equilibrio decarga. Este único punto de referencia es importante, ya que la cookie es una cookieespecífica del servidor y no una cookie específica del dominio. La cookie sólopuede ser aceptada por un servidor con el mismo nombre DNS que el del servidorque ha creado la cookie. El cliente siempre realiza peticiones a través delmecanismo de equilibrio de carga. Por lo tanto, siempre se acepta la cookie y sepasa al siguiente servidor disponible durante la operación de migración tras error.

Habilitación de cookies de resolución de erroresEl parámetro failover-auth, que se encuentra en la stanza [failover] del archivo deconfiguración webseald.conf, habilita o inhabilita las cookies de resolución deerrores específicas del servidor:v Para habilitar las cookies de resolución de errores, escriba “http”, “https” o

“both” (ambos).v Para inhabilitar las cookies de resolución de errores, escriba “none” (ninguno)

(predeterminado).

Por ejemplo:[failover]failover-auth = https

Debe definir este parámetro en cada uno de los servidores WebSEAL frontales.

Para cada método de autenticación soportado del entorno de clúster de WebSEAL,también debe habilitar un parámetro equivalente del método de migración traserror en la stanza [authentication-mechanisms] del archivo de configuraciónwebseald.conf. Cada parámetro del método de autenticación de migración traserror apunta a una biblioteca compartida de autenticación especial que imita labiblioteca compartida de autenticación original y, además, recupera los atributosampliados que se colocaron originalmente en la credencial del usuario.


Están disponibles los siguientes parámetros del método de autenticación demigración tras error:[authentication-mechanisms]#failover-password = <biblioteca-contraseña-migracióntraserror>#failover-token-card = <biblioteca-tarjeta-señal-migracióntraserror>#failover-certificate = <biblioteca-certificados-migracióntraserror>#failover-http-request = <biblioteca-petición-http-migracióntraserror>#failover-cdsso = <biblioteca-cdsso-migracióntraserror>

WebSEAL proporciona una biblioteca compartida de migración tras error estándarque funciona para todos los métodos de autenticación anteriores. Esta biblioteca sedenomina:

Solaris libfailoverauthn.so

AIX libfailoverauthn.a

HP-UX libfailoverauthn.sl

Windows failoverauthn.dll

Como alternativa, puede proporcionar una biblioteca CDAS personalizada queproporciona las posibilidades específicas de autenticación que necesita el entornodel usuario.

Por ejemplo:1. El usuario autentica en WS1 a través del nombre de usuario y la contraseña. La

biblioteca estándar libldapauthn agrega (a través de un atributo ampliadoHTTP-Tag-Value en la conexión) ciertos atributos ampliados de LDAP a lacredencial del usuario.Además, un módulo CDAS encadenado agrega otros atributos ampliados a lacredencial del usuario a través de su biblioteca cred-ext-attrs.

2. El servidor WS1 falla y se redirige al usuario al servidor WS2.3. WS2 recibe la cookie de resolución de errores desde el navegador del usuario y

decodifica la cookie. Dado que el usuario se autentificó inicialmente con elmétodo de nombre de usuario y contraseña, la biblioteca libfailoverauthn seconecta al servidor LDAP y recupera los datos de credencial estándar para estemétodo, más los atributos ampliados que proporciona el mecanismo decódigo/valor.A continuación, la identidad del usuario se pasa a la biblioteca cred-ext-attrspersonalizada que proporciona sus atributos ampliados adicionales.WS2 ha generado ahora la misma credencial completa para el usuario que WS1utilizó.

Si el entorno de este ejemplo incluye también el soporte para la autenticación decertificados, la stanza [authentication-mechanisms] aparecerá de la manerasiguiente:[authentication-mechanisms]passwd-ldap = /opt/pdweb/lib/libldapauthn.socert-ssl = /opt/pdweb/lib/libsslauthn.sofailover-password = /opt/pdweb/lib/libfailoverauthn.sofailover-certificate = /opt/pdweb/lib/libfailoverauthn.socred-ext-attrs = /usr/lib/custom-ext-attrs-CDAS.so

Cifrado y descifrado de los datos de cookiePara proteger los datos de la cookie, utilice el programa de utilidad cdsso_key_genque proporciona WebSEAL. Este programa de utilidad genera una clave simétrica


que cifra y descifra los datos de la cookie. Especifique la ubicación (nombre de rutade acceso completa) del archivo de claves cuando se ejecute el programa deutilidad:

UNIX:# cdsso_key_gen <nombre-ruta-acceso>

Windows:MSDOS> cdsso_key_gen <nombre-ruta-acceso>

Ejecute el programa de utilidad en uno de los servidores replicados y copiemanualmente el archivo de claves en cada uno de los otros servidores replicados.Especifique esta ubicación del archivo de claves en la stanza [failover] del archivode configuración webseald.conf de cada servidor. Si no especifica ningún archivode claves, se inhabilita la función de cookies de resolución de errores para eseservidor:[failover]failover-cookies-keyfile = <nombre-ruta-acceso-completa>

Puede darle al archivo de claves un nombre como, por ejemplo, ws.key.

Configuración de la duración de la cookieEl valor de la duración de la cookie de resolución de errores (en minutos) seestablece con el parámetro failover-cookie-lifetime:[failover]failover-cookie-lifetime = 60

Habilitación de cookies de resolución de errores de todo eldominioPuede permitir que las cookies de resolución de errores se envíen a cualquierservidor del mismo dominio que el servidor WebSEAL estableciendo el parámetroenable-failover-cookie-for-domain en el valor “yes”. De forma predeterminada, lafuncionalidad de cookies de resolución de errores del dominio está inhabilitada:[failover]enable-failover-cookie-for-domain = no

Visión general de la configuración de autenticaciónPuede habilitar e inhabilitar la autenticación para los clientes HTTP y HTTPS enbase al método.

Los mecanismos de todos los métodos de autenticación soportados en WebSEALestán configurados en la stanza [authentication-mechanisms] del archivo deconfiguración webseald.conf. Los parámetros de los métodos de autenticaciónsoportados son:v Autenticadores locales (incorporados)

Los parámetros para los autenticadores locales especifican los archivos DLL(Windows) o de bibliotecas (UNIX) compartidos incorporados apropiados.

v Autenticadores externos personalizadosWebSEAL proporciona un código de servidor de plantilla que se puede utilizarpara crear y especificar un servidor CDAS (Servicio de autenticación endominios cruzados) externo personalizado.Un autenticador CDAS externo especifica la biblioteca compartida personalizadacorrespondiente.


Parámetros de autenticación localLos parámetros siguientes especifican los autenticadores locales incorporados:


Autenticación básica y de formularios

passwd-ldap Acceso de cliente con nombre de usuario y contraseña deLDAP.

Autenticación de señales

token-cdas Acceso de cliente con nombre de usuario LDAP y código depaso de señal SecurID.

Autenticación de certificados de cliente

cert-ssl Acceso de cliente con certificado de cliente a través de SSL.

Autenticación de cabeceras HTTP o direcciones IP

http-request Acceso de cliente mediante cabecera HTTP o dirección IPespeciales.

Autenticación de señal CDSSO ID

cdsso Autenticación de inicio de sesión único en dominios cruzados.

Puede utilizar la stanza [authentication-mechanisms] para configurar el método deautenticación y la implementación en el siguiente formato:<parámetro-método-autenticación> = <biblioteca-compartida>

Parámetros de autenticación de CDAS personalizado externoLos siguientes parámetros permiten especificar bibliotecas compartidaspersonalizadas para servidores CDAS externos:


passwd-cdas Acceso de cliente con nombre de usuario y contraseña para unregistro de terceros.

token-cdas Acceso de cliente con nombre de usuario y código de paso deseñal.

cert-cdas Acceso de cliente con certificado de cliente a través de SSL.

http-request Acceso de cliente mediante cabecera HTTP o dirección IPespeciales.

cred-ext-attrs CDAS lo utiliza para proporcionar datos de atributos ampliados ala credencial del usuario.

Consulte la publicación IBM Tivoli Access Manager WebSEAL Developer’sReference para obtener más detalles sobre la creación y configuración de unabiblioteca compartida personalizada que implemente un servidor CDAS.

Configuración predeterminada para la autenticación deWebSEAL

De forma predeterminada, WebSEAL está establecido para autenticar clientes através de SSL utilizando los nombres de usuario y contraseñas de autenticaciónbásica (BA) (registro LDAP).


Generalmente, WebSEAL está habilitado para los accesos TCP y SSL. Por lo tanto,una configuración típica de la stanza [authentication-mechanisms] incluye elsoporte para nombres de usuario y contraseñas (registro LDAP) y soporte paracertificados de cliente 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ámetro apropiadocon su biblioteca compartida (o módulo CDAS).

Configuración de múltiples métodos de autenticaciónPuede modificar la stanza [authentication-mechanism] del archivo deconfiguración webseald.conf para especificar la biblioteca compartida que se debeutilizar para cada método de autenticación soportado. Las siguientes condicionesse aplican cuando se configuran varios métodos de autenticación:1. Todos los métodos de autenticación pueden funcionar de forma independiente.

Se puede configurar una biblioteca compartida para cada método soportado.2. El método cert-cdas prevalece sobre el método cert-ssl cuando ambos están

configurados. Debe habilitar uno de ellos para dar soporte a los certificados decliente.

3. Sólo se utiliza un autenticador de tipo contraseña cuando hay variosconfigurados. WebSEAL utiliza el siguiente orden de prioridad para resolvermúltiples autenticadores de contraseña configurados:a. passwd-cdas

b. passwd-ldap

4. Se puede configurar la misma biblioteca personalizada para dos métodos deautenticación diferentes. Por ejemplo, se puede escribir una bibliotecacompartida personalizada para procesar la autenticación del nombre deusuario/contraseña y de la cabecera HTTP. En este ejemplo, se podríanconfigurar los parámetros passwd-cdas y http-request con la misma bibliotecacompartida. 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 las siguientes condiciones:1. Un cliente sin autenticar que no pasa la comprobación de autenticación2. Un cliente de autenticación básica o de formularios que no pasa la

comprobación de autenticación

Los siguientes tipos de clientes reciben un error “403 Error”:1. Cuando falla la comprobación de autenticación:

a. Certificado de clienteb. Cookie de resolución de erroresc. CDSSOd. Dirección IPe. Cabecera HTTP

2. Cuando un cliente se autentica con un método inhabilitado por WebSEAL


Comandos de fin de sesión y de cambio de contraseñaAccess Manager proporciona los siguientes comandos para dar soporte a clientesque se autentican a través de HTTP o HTTPS.

pkmslogoutLos clientes pueden utilizar el comando pkmslogout para finalizar la sesión actualsi utilizan un método de autenticación que no proporciona datos de autenticacióncon cada petición. Por ejemplo, pkmslogout no funciona en clientes que utilizan laautenticación básica o la autenticación de dirección IP. En este caso, se debe cerrarel navegador para finalizar la sesión.

El comando pkmslogout es adecuado para la autenticación a través del certificadodel cliente, el código de paso de señal, la autenticación de formularios ydeterminadas implementaciones de la autenticació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 el archivo deconfiguración webseald.conf:[acnt-mgt]logout = logout.html

Puede modificar el archivo logout.html para que se ajuste a sus requisitos.

El programa de utilidad pkmslogout también da soporte a varias páginas derespuesta de fin de sesión cuando la arquitectura de la red requiere diversaspantallas de salida para los usuarios que finalizan la sesión en sistemas de fondodistintos.

La siguiente expresión identifica un archivo de respuesta específico:https://www.tivoli.com/pkmslogout?filename=<archivo_fin_sesión_personalizado>

donde archivo_fin_sesión_personalizado es el nombre de archivo de respuesta delfin de sesión. Este archivo debe residir en el mismo directorio lib/html/C quecontiene el archivo predeterminado logout.html y ejemplos de otros formulariosHTML de respuesta.

pkmspasswdPuede utilizar este comando para cambiar la contraseña de inicio de sesión cuandose utiliza la autenticación básica (BA) o la autenticación de formularios. Estecomando es apropiado a través de HTTP o HTTPS.

Por ejemplo:https://www.tivoli.com/pkmspasswd

Para garantizar la máxima seguridad cuando se utilice BA con WebSEAL, estecomando se comporta de la siguiente forma para un cliente 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 navegador presenta al

cliente una solicitud de BA.4. El cliente debe volver a iniciar la sesión para continuar realizando peticiones.


Este ejemplo sólo se aplica a los clientes que utilizan la autenticación básica.

Configuración de la autenticación básicaLa autenticación básica (BA) es un método estándar para proporcionar un nombrede usuario y una contraseña al mecanismo de autenticación. El protocolo HTTPdefine la BA y se puede implementar a través de HTTP y de HTTPS.

WebSEAL se configura de forma predeterminada para la autenticación a través deHTTPS mediante la autenticación básica (BA) de nombre de usuario y contraseña.

Habilitación e inhabilitación de la autenticación básicaEl parámetro ba-auth, que se encuentra en la stanza [ba] del archivo deconfiguración webseald.conf, habilita e inhabilita el método de autenticaciónbásica.v Para habilitar el método de autenticación básica, escriba “http”, “https”, o

“both” (ambos).v Para inhabilitar el método de autenticación básica, escriba “none”.

Por ejemplo:[ba]ba-auth = https

Definición del nombre de dominioEl nombre de dominio es el texto que se muestra en el cuadro de diálogo queaparece cuando el navegador solicita al usuario los datos de inicio de sesión.

El parámetro de configuración que establece el nombre de dominio se encuentra enla stanza [ba] del archivo de configuración webseald.conf.

Por ejemplo:[ba]basic-auth-realm = Access Manager

Figura 22. Solicitud de inicio de sesión de BA


Configuración del mecanismo de autenticación básicaEl parámetro passwd-ldap especifica la biblioteca compartida que se utiliza paragestionar la autenticación del nombre de usuario y la contraseña.v En UNIX, el archivo que proporciona la función de correlación incorporada es

una biblioteca compartida denominada libldapauthn.v En Windows, el archivo que proporciona la función de correlación incorporada

es una DLL denominada ldapauthn.

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 de usuario y lacontraseña especificando el parámetro passwd-ldap con el nombre específico parala plataforma del archivo de biblioteca compartida en la stanza[authentication-mechanism] del archivo de configuración webseald.conf. Porejemplo:

Solaris:[authentication-mechanisms]passwd-ldap = libldapauthn.so

Windows:[authentication-mechanisms]passwd-ldap = ldapauthn.dll

Condiciones de configuraciónSi se habilita la autenticación de formularios para un transporte determinado, seomitirá la configuración de autenticación básica para ese transporte.

Configuración de la autenticación de formulariosAccess Manager proporciona la autenticación de formularios como una alternativaal mecanismo estándar de autenticación básica. Este método produce un formulariode inicio de sesión de HTML personalizado de Access Manager en lugar de lasolicitud de inicio de sesión estándar que resulta de la tentativa de autenticaciónbásica.

Cuando se utiliza el inicio de sesión basado en formularios, el navegador noalmacena en la caché la información de nombre de usuario y contraseña, como lohace la autenticación básica.

Habilitación e inhabilitación de la autenticación de formulariosEl parámetro forms-auth, que se encuentra en la stanza [forms] del archivo deconfiguración webseald.conf, habilita e inhabilita el método de autenticación deformularios.v Para habilitar el método de Autenticación de formularios, escriba “http”, “https”

o “both”.v Para inhabilitar el método de Autenticación de formularios, escriba “none”.

Por ejemplo:


[forms]forms-auth = https

Configuración del mecanismo de autenticación de formulariosEl parámetro passwd-ldap especifica la biblioteca compartida que se utiliza paragestionar la autenticación del nombre de usuario y la contraseña.v En UNIX, el archivo que proporciona la función de correlación incorporada es

una biblioteca compartida denominada libldapauthn.v En Windows, el archivo que proporciona la función de correlación incorporada

es una DLL denominada ldapauthn.




passwd-ldap libldapauthn.so libldapauthn.a ldapauthn.dll libldapauthn.sl

Puede configurar el mecanismo de autenticación del nombre de usuario y lacontraseña especificando el parámetro passwd-ldap con el nombre específico parala plataforma del archivo de biblioteca compartida en la stanza[authentication-mechanism] del archivo de configuración webseald.conf. Porejemplo:

Solaris:[authentication-mechanisms]passwd-ldap = libldapauthn.so

Windows:[authentication-mechanisms]passwd-ldap = ldapauthn.dll

Condiciones de configuraciónSi se habilita la autenticación de formularios para un transporte determinado, seomitirá la configuración de la autenticación básica para ese transporte.

Personalización de los formularios HTML de respuestaLa autenticación de formularios requiere el uso de un formulario de inicio desesión personalizado. De forma predeterminada, el formulario login.html deejemplo se encuentra en el siguiente directorio:<directorio-instalación>/lib/html

Puede personalizar el contenido y el diseño de este formulario. Por ejemplo:


Para obtener información detallada acerca de los formularios HTML disponiblesque se pueden personalizar, consulte el apartado “Gestión de páginaspersonalizadas de gestión de cuentas” en la página 36.

Configuración de la autenticación de certificados del clienteWebSEAL da soporte a la comunicación segura con clientes mediante certificadosdigitales de cliente a través de SSL. En este método de autenticación, lainformación de certificado (como el Nombre distinguido o DN) se correlaciona conuna identidad de Access Manager.

Información general: autenticación mutua mediantecertificados

El intercambio de certificados del servidor y del cliente a través de SSL da comoresultado una relación de confianza entre el cliente y el servidor basada en loscertificados. También se establece un canal de comunicación seguro.

El protocolo de reconocimiento de certificados digitales de SSL que produce laautenticación mutua tiene lugar en dos fases:v WebSEAL se identifica ante los clientes SSL con su certificado de servidorv WebSEAL utiliza su base de datos de certificados raíz de CA (entidad emisora

de certificados) para validar los clientes que acceden con los certificados decliente

1. Un cliente solicita una conexión con un servidor WebSEAL a través de SSL.2. Como respuesta, WebSEAL envía su clave pública mediante un certificado de

cliente firmado. Una entidad emisora de certificados (CA) de terceros hafirmado previamente este certificado.

3. El cliente comprueba si el emisor del certificado es fiable y se puede aceptar.El navegador del cliente contiene habitualmente una lista de certificados raízde CA fiables. Si la firma del certificado de WebSEAL coincide con uno deestos certificados raíz, el servidor es fiable.

Figura 23. Ejemplo de formulario de inicio de sesión de WebSEAL


4. Si no hay ninguna coincidencia con esta firma, el navegador informa alusuario de que este certificado ha sido emitido por una entidad emisora decertificados desconocida. A partir de aquí, es responsabilidad del usuarioaceptar o rechazar el certificado.

5. Si la firma coincide con una entrada de la base de datos de certificados raízdel navegador, las claves de sesión se negocian de forma segura entre elcliente y el servidor WebSEAL.El resultado final de este proceso es un canal seguro.

6. Ahora el cliente envía su certificado de clave pública al servidor WebSEAL.7. WebSEAL intenta encontrar la firma del certificado de cliente en una CA

conocida. Del mismo modo que un navegador del cliente, el servidorWebSEAL mantiene una lista de certificados raíz de CA fiables en su base dedatos de claves.

8. Si no hay ninguna coincidencia con esta firma, WebSEAL generará un códigode error de SSL y lo enviará al cliente.

9. Si hay una coincidencia con la firma, el certificado es fiable.10. Access Manager autentica el cliente utilizando la biblioteca compartida

incorporada cuando el Nombre distinguido (DN) del campo Asunto delcertificado del cliente coincide exactamente con una entrada ya existente deDN en el registro de LDAP, o utilizando un CDAS personalizado para realizaruna coincidencia de identidad alternativa.El resultado de una autenticación correcta es una identidad de AccessManager que luego se utilizará para crear una credencial para ese usuario. Esla credencial lo que se necesita para que el cliente participe en el dominioseguro de Access Manager.

El certificado de prueba de WebSEALDurante la instalación, WebSEAL contiene un certificado de prueba autofirmado deservidor. Aunque este certificado de prueba permite a WebSEAL responder a unapetición de navegador habilitado para SSL, el navegador (que no contiene ningúncertificado raíz de CA apropiado) no lo puede verificar. Debido a que la claveprivada para este certificado predeterminado está incluida en cada distribución deWebSEAL, este certificado no ofrece ninguna comunicación verdaderamentesegura.

Para garantizar una comunicación segura a través de SSL, es muy importanteregistrar y obtener un certificado de servidor de sitio único desde una entidademisora de certificados (CA) fiable. Puede utilizar el programa de utilidadiKeyman de GSKit para generar una petición de certificado que se enviará a la

Figura 24. El cliente valida el certificado de WebSEAL


CA. También puede utilizar iKeyman para instalar y etiquetar el certificado desitio nuevo. Utilice el parámetro webseal-cert-keyfile-label en la stanza [ssl] delarchivo de configuración webseald.conf para designar el certificado como elcertificado de servidor WebSEAL activo (este valor anula cualquier certificadodesignado como “predeterminado” en la base de datos del archivo de claves).

Si necesita certificados diferentes para otras situaciones (por ejemplo, paraconexiones (junctions) autenticadas mutuamente), puede utilizar el programa deutilidad iKeyman para crear, instalar y etiquetar estos certificados adicionales.

Consulte el apartado “Configuración de parámetros de base de datos de claves” enla página 40.

Habilitación e inhabilitación de la autenticación decertificados

Puede especificar la forma en que WebSEAL gestionará la autenticación mediantecertificados de cliente a través de SSL especificando el parámetroaccept-client-certs, que se encuentra en la stanza [certificate] del archivo deconfiguración webseald.conf.

De forma predeterminada, WebSEAL no acepta certificados de cliente:[certificate]accept-client-certs = never

Los valores adicionales para este parámetro incluyen optional y required.

La tabla siguiente muestra una lista que describe los valores permitidos para elparámetro accept-client-certs:

Valor Descripción

never No aceptar certificados X.509 de clientes.

optional Solicitar un certificado X.509 a los clientes y utilizar laautenticación basada en certificados, si se proporciona uncertificado.

required Solicitar un certificado X.509 a los clientes y utilizar laautenticación basada en certificados. Si el cliente no presentaningún certificado, no permitir la conexión.

Configuración del mecanismo de autenticación de certificadosEl parámetro cert-ssl especifica la biblioteca compartida para la correlación deinformación de autenticación de certificados.v En UNIX, el archivo que proporciona la función de correlación incorporada es

una biblioteca compartida denominada libsslauthn.v En Windows, el archivo que proporciona la función de correlación incorporada

es una DLL denominada sslauthn.




cert-ssl libsslauthn.so libsslauthn.a sslauthn.dll libsslauthn.sl


Puede configurar el mecanismo de autenticación de certificados especificando elparámetro cert-ssl con el nombre específico para la plataforma del archivo debiblioteca compartida en la stanza [authentication-mechanism] del archivo deconfiguración webseald.conf.

Solaris:[authentication-mechanisms]cert-ssl= libsslauthn.so

Windows:[authentication-mechanisms]cert-ssl = sslauthn.dll

Durante la autenticación de certificados, la biblioteca compartida identifica alusuario de Access Manager cuando el Nombre distinguido (DN) del campo Asuntodel certificado del cliente coincide exactamente con una entrada existente de DNen el registro de LDAP.

Condiciones de configuraciónSi la gestión de certificados de cliente se define como “required”, se omitirá elresto de los valores de autenticación para los clientes HTTPS.

Configuración de la autenticación de cabeceras HTTPAccess Manager da soporte a la autenticación mediante la información de cabeceraHTTP personalizada proporcionada por el cliente o un agente proxy.

Este mecanismo requiere una función de correlación (una biblioteca compartida)que correlaciona los datos de cabecera fiables (autenticados previamente) con unaidentidad de Access Manager. WebSEAL puede tomar esta identidad y crear unacredencial para el usuario.

WebSEAL presume que los datos de cabecera HTTP personalizados se hanautenticado previamente. Por ello, es recomendable que se implemente estemétodo exclusivamente, sin ningún otro método de autenticación habilitado. Esposible imitar los datos de cabecera HTTP personalizados.

De forma predeterminada, esta biblioteca compartida se crea para correlacionardatos de cabeceras de proxy Entrust.

Habilitación e inhabilitación de la autenticación de cabecerasHTTP

El parámetro http-headers-auth, que se encuentra en la stanza [http-headers] delarchivo de configuración webseald.conf, habilita e inhabilita el método deautenticación de cabeceras HTTP.v Para habilitar el método de autenticación de cabeceras HTTP, escriba “http”,

“https”, o “both” (ambos).v Para inhabilitar 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 la stanza[auth-headers] del archivo de configuración webseald.conf.[auth-headers]header = <tipo-cabecera>

De forma predeterminada, esta biblioteca compartida incorporada está codificadade forma que no se puede modificar para dar soporte a datos de cabecera de proxyEntrust.[auth-headers]header = entrust-client

Debe personalizar este archivo para autenticar otros tipos de datos de cabeceraespeciales y, de forma opcional, correlacionar estos datos con una identidad deAccess Manager. Consulte los recursos API en la publicación IBM Tivoli AccessManager WebSEAL Developer’s Reference.

Configuración del mecanismo de autenticación de cabecerasHTTP

El parámetro http-request especifica la biblioteca compartida para la correlación deinformación de autenticación de cabeceras HTTP.v En UNIX, el archivo que proporciona la función de correlación incorporada es

una biblioteca compartida denominada libhttpauthn.v En Windows, el archivo que proporciona la función de correlación incorporada

es una DLL denominada httpauthn.




http-request libhttpauthn.so libhttpauthn.a httpauthn.dll libhttpauthn.sl

De forma predeterminada, esta biblioteca compartida incorporada está codificadade forma que no se puede modificar para correlacionar datos de cabecera de proxyEntrust con una identidad válida de Access Manager. Debe personalizar estearchivo para autenticar otros tipos de datos de cabecera especiales y, de formaopcional, correlacionar estos datos con una identidad de Access Manager. Consultelos recursos API en la publicación IBM Tivoli Access Manager WebSEAL Developer’sReference.

Puede configurar el mecanismo de autenticación de cabeceras HTTP especificandoel parámetro http-request con el nombre específico para la plataforma del archivode biblioteca compartida en la stanza [authentication-mechanism] del archivo deconfiguración webseald.conf.

Por ejemplo:

Solaris:[authentication-mechanisms]http-request = libhttpauthn.so

Windows:[authentication-mechanisms]http-request = httpauthn.dll


Condiciones de configuración1. Las cookies de ID de sesión no se utilizan para mantener el estado si

ssl-id-sessions = no. El valor de cabecera exclusiva se utiliza para mantener elestado.

2. Si el cliente encuentra un error de autorización, recibe una página de “Noautorizado” (HTTP 403).

3. Las cabeceras de cookies no se pueden pasar al mecanismo de autenticación decabeceras HTTP.

Configuración de autenticación de direcciones IPAccess Manager da soporte a la autenticación a través de una dirección IP queproporciona el cliente.

Habilitación e inhabilitación de la autenticación de direccionesIP

El parámetro ipaddr-auth, que se encuentra en la stanza [ipaddr] del archivo deconfiguración webseald.conf, habilita e inhabilita el método de autenticación dedirecciones IP.v Para habilitar el método de autenticación de direcciones IP, escriba “http”,

“https”, o “both” (ambos).v Para inhabilitar el método de autenticación de direcciones IP, escriba “none”.

Por ejemplo:[ipaddr]ipaddr-auth = https

Configuración del mecanismo de autenticación de direccionesIP

La autenticación mediante una dirección IP requiere una biblioteca compartidapersonalizada. Utilice el parámetro http-request para esta biblioteca compartida.

Configuración de la autenticación de señalesAccess Manager da soporte a la autenticación a través de un código de paso deseñal proporcionado por el cliente.

Habilitación e inhabilitación de la autenticación de señalesEl parámetro token-auth, que se encuentra en la stanza [token] del archivo deconfiguración webseald.conf, habilita e inhabilita el método de autenticación deseñales.v Para habilitar el método de autenticación de señales, escriba “http”, “https”, o

“both” (ambos).v Para inhabilitar el método de autenticación de señales, escriba “none”.

Por ejemplo:[token]token-auth = https


Configuración del mecanismo de autenticación de señalesEl parámetro token-cdas especifica la biblioteca compartida para la correlación deinformación de autenticación de códigos de paso de señales.v En UNIX, el archivo que proporciona la función de correlación incorporada es

una biblioteca compartida denominada libxtokenauthn.v En Windows, el archivo que proporciona la función de correlación incorporada

es una DLL denominada xtokenauthn.




token-cdas libxtokenauthn.so libxtokenauthn.a xtokenauthn.dll libxtokenauthn.sl

De forma predeterminada, esta biblioteca compartida incorporada está codificadade forma que no se puede modificar para correlacionar datos de código de paso deseñal SecurID. Puede personalizar este archivo para autenticar otros tipos de datosde señales especiales y, de forma opcional, correlacionar estos datos con unaidentidad de Access Manager. Consulte los recursos API en la publicación IBMTivoli Access Manager WebSEAL Developer’s Reference.

Puede configurar el mecanismo de autenticación de señales especificando elparámetro token-cdas con el nombre específico para la plataforma del archivo debiblioteca compartida en la stanza [authentication-mechanism] del archivo deconfiguración webseald.conf. La biblioteca compartida debe incluir la opción y elargumento –r <registro>. El tipo de registro debe especificarse como LDAP.

Por ejemplo:

Solaris:[authentication-mechanisms]token-cdas = libxtokenauthn.so& -r LDAP

Windows:[authentication-mechanisms]token-cdas = xtokenauthn.dll& -r LDAP

Soporte para agentes MPA (Multiplexing Proxy Agents)Access Manager proporciona soluciones para proteger las redes que utilizan unMPA (Multiplexing Proxy Agent).

Los SPA (Standard Proxy Agents) son gateways que dan soporte a sesiones porcliente entre clientes y el servidor de origen a través de SSL o HTTP. WebSEALpuede aplicar la autenticación SSL o HTTP normal a estas sesiones por cliente.

Los MPA (Multiplexing Proxy Agents) son gateways que alojan varios accesos decliente. Estos gateways se denominan gateways WAP cuando los clientes acceden através de WAP (Wireless Access Protocol). Los gateways establecen un solo canalautenticado con el servidor de origen y utilizan un “túnel” para todas laspeticiones de cliente y las respuestas a través de este canal.

Para WebSEAL, la información a través de este canal aparece inicialmente comopeticiones múltiples de un cliente. WebSEAL debe distinguir entre la autenticacióndel servidor MPA y la autenticación adicional de cada cliente individual.


Puesto que WebSEAL mantiene una sesión autenticada para el MPA, debemantener simultáneamente sesiones aparte para cada cliente. Por lo tanto, los datosde sesión y el método de autenticación que se utilizan para el MPA deben serdistintos (diferentes) de los datos de sesión y el método de autenticación queutiliza el cliente.

Tipos de datos de sesión y métodos de autenticación válidosEl tipo de datos de sesión que se utiliza de MPA a WebSEAL debe ser distinto(diferente) del tipo de datos de sesión que se utiliza de cliente a WebSEAL. En latabla siguiente se muestran los tipos de sesió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

Cookie Cookie

v El cliente no puede utilizar un ID de sesión SSL como tipo de datos de sesión.v Por ejemplo, si el MPA utiliza una cabecera BA para el tipo de datos de sesión,

las opciones del cliente para el tipo de datos de sesión sólo pueden ser lacabecera HTTP y la cookie.

v Si el MPA utiliza una cabecera HTTP para los datos de sesión, el cliente puedeutilizar un tipo de cabecera HTTP diferente.

v La cookie específica del servidor contiene sólo información sobre la sesión; nocontiene información sobre la identidad.

v Si está habilitado el soporte MPA, la función de ssl-id-sessions cambia.Normalmente, si ssl-id-sessions=yes, sólo se utiliza el ID de sesión SSL paramantener las sesiones de los clientes HTTPS. Para que el MPA pueda manteneruna sesión con un ID de sesión SSL y tener clientes manteniendo sesiones conotro método, se debe eliminar esta restricción. Consulte también el apartado“Determinación de los tipos de datos válidos de ID de sesión” en la página 114.

El método de autenticación que se utiliza de MPA a WebSEAL debe ser distinto(diferente) del método de autenticación que se utiliza de cliente a WebSEAL. En la

Figura 25. Comunicación a través de un gateway MPA


tabla siguiente se muestran los métodos de autenticación válidos para el MPA y elcliente:

Tipos de autenticación válidos

De MPA a WebSEAL De cliente a WebSEAL

Autenticación básica Autenticación básica

Formularios Formularios

Señal Señal

Cabecera HTTP Cabecera HTTP

Certificados

Dirección IP

v Por ejemplo, si el MPA utiliza la autenticación básica, las opciones del clientepara los métodos de autenticación incluyen cabeceras HTTP, de formularios y deseñales.

v Los métodos de autenticación de direcciones IP y de certificados no pueden serutilizados por el cliente.

v Normalmente, si se habilita la autenticación de formularios (o de señales) paraun transporte determinado, la autenticación básica se inhabilitaráautomáticamente para ese transporte (consulte el apartado “Configuración delmecanismo de autenticación básica” en la página 123. Si está habilitado elsoporte MPA, esta restricción se eliminará. Por ejemplo, esto permite al MPAiniciar la sesión con formularios (o señales) a los clientes iniciar la sesión conautenticación básica con autenticación básica a través del mismo transporte.

Flujo de proceso de autenticación para MPA y clientesmúltiples

1. El administrador de WebSEAL lleva a cabo las siguientes tareas deconfiguración preliminar:v Habilitar el soporte para los MPA (Multiplexing Proxy Agents)v Crear una cuenta de Access Manager para el gateway MPA específicov Agregar esta cuenta MPA al grupo webseal-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 la petición del cliente.6. El MPA se autentica en WebSEAL (utilizando un método distinto 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 grupo webseal-mpa-servers.8. Se crea una credencial para el MPA y se etiqueta como un tipo MPA especial

en la caché.Aunque esta credencial MPA acompaña a todas las futuras peticiones delcliente, no se utiliza para las comprobaciones de autorización de estaspeticiones.

9. Ahora WebSEAL necesita identificar al propietario de la petición de formaadicional.El MPA puede distinguir los distintos clientes para dirigir correctamente lasindicaciones de inicio de sesión.


10. El cliente inicia la sesión y se autentica utilizando un método distinto del tipode autenticación utilizado por el MPA.

11. WebSEAL crea una credencial a partir de los datos de autenticación del cliente.12. El tipo de datos de sesión que utiliza cada cliente debe ser distinto del tipo de

datos de sesión que utiliza el MPA.13. El servicio de autorizaciones permite o rechaza el acceso a los objetos

protegidos basándose en la credencial de usuario y los permisos ACL delobjeto.

Habilitación e inhabilitación de la autenticación de MPAEl parámetro mpa, que se encuentra en la stanza [mpa] del archivo deconfiguración webseald.conf, habilita e inhabilita el método de autenticación deMPA.v Para habilitar el método de autenticación de MPA, escriba “yes”.v Para inhabilitar el método de autenticación de MPA, escriba “no”.

Por ejemplo:[mpa]mpa = yes

Creación de una cuenta de usuario para el MPAConsulte la publicación IBM Tivoli Access Manager Base Guía del administrador paraobtener información sobre cómo crear cuentas de usuario.

Adición de la cuenta de MPA al grupo webseal-mpa-serversConsulte la publicación IBM Tivoli Access Manager Base Guía del administrador paraobtener información sobre cómo gestionar grupos.

Limitaciones de la autenticación de MPAEste release de Access Manager sólo da soporte a un MPA por servidor WebSEAL.

Configuración de la reautenticación basada en la política de seguridadAccess Manager WebSEAL puede forzar a un usuario a realizar un inicio de sesiónadicional (reautenticación) para asegurarse de que un usuario que accede a unrecurso protegido es la misma persona que inicialmente se ha autenticado alcomienzo de la sesión. La reautenticación puede activarse con una política deobjetos protegidos (POP) en el objeto protegido o a causa de la caducidad del valorde tiempo de espera de inactividad de la caché de sesión de WebSEAL.

Este apartado analiza la reautenticación basada en la política de seguridad talcomo la establece un atributo ampliado de POP.

Condiciones que afectan a la reautenticación de POPUna reautenticación forzada proporciona protección adicional para los recursossensibles en el dominio seguro. La reautenticación basada en la política deseguridad se activa mediante un atributo ampliado específico de una POP queprotege el objeto de recurso solicitado. La POP se puede asociar directamente conel objeto, o éste puede heredar de un objeto padre las condiciones de la POP.

La reautenticación está soportada por los siguientes métodos de autenticación deWebSEAL:


v Autenticación de formularios (nombre de usuario y contraseña)v Autenticación de señales

Además, se puede escribir un CDAS de nombre de usuario/contraseñapersonalizado que dé soporte a la reautenticación.

La reautenticación supone que el usuario ha iniciado la sesión inicialmente en eldominio seguro y que existe una credencial válida para el usuario. Durante lareautenticación, el usuario debe iniciar la sesión utilizando la misma identidad quegeneró la credencial existente. Access Manager preserva la información de sesiónoriginal del usuario, incluida la credencial, durante la reautenticación. Durante lareautenticación no se sustituye la credencial.

Además, durante la reautenticación, WebSEAL guarda en la caché la petición queactivó la reautenticación. Cuando la reautenticación se haya realizadocorrectamente, los datos de la caché se utilizarán para volver a crear la petición.Consulte el apartado “Configuración del almacenamiento en la caché de peticionesdel servidor WebSEAL” en la página 70.

Si falla la reautenticación, WebSEAL devuelve de nuevo la solicitud de inicio desesión. Si la reautenticación es satisfactoria, pero la comprobación de ACL fallapara ese recurso, se devuelve un error 403 “No autorizado” y se rechaza el accesodel usuario al recurso solicitado. En cualquiera de estos casos, no se finaliza nuncala sesión del usuario. Utilizando una credencial que aún sea válida, el usuariopodrá terminar anormalmente el proceso de reautenticación (solicitando otradirección URL) y participar en el dominio seguro accediendo a otros recursos queno requieran reautenticación.

Se dispone de la configuración para restablecer el temporizador de duración de lacaché de sesión de WebSEAL. Además, se puede configurar un período de graciapara permitir que haya tiempo suficiente para completar el proceso dereautenticación antes de que caduque el tiempo de espera de duración de la cachéde sesión.

Creación y aplicación de la POP de reautenticaciónLa reautenticación forzada basada en la política de seguridad se configura creandouna política de objeto protegido (POP) con un atributo ampliado especialdenominado “reauth”. Puede asociar esta POP con cualquier objeto que requiera laprotección adicional que proporciona la reautenticación forzada.

Recuerde que todos los hijos del objeto con la POP heredan también lascondiciones de la POP. Cada objeto hijo solicitado requiere una reautenticaciónindependiente.

Utilice los comandos pdadmin pop create, pdadmin pop modify y pdadmin popattach. El ejemplo siguiente muestra cómo crear una POP denominada “secure”con el atributo ampliado reauth y cómo asociarla con un objeto (budget.html):pdadmin> pop create securepdadmin> pop modify secure set attribute reauth truepdadmin> pop attach /WebSEAL/hostA/junction/budget.html secure

Cualquier usuario que intente acceder a budget.html está forzado a reautenticarseutilizando la misma identidad y el mismo método de autenticación que generaronla credencial existente.


Si el usuario que solicita el recurso no está autenticado, la POP fuerza al usuario aautenticarse. No es necesaria ninguna reautenticación para este recurso después deun inicio de sesión inicial correcto.

Los detalles acerca del programa de utilidad de línea de comandos pdadminpueden encontrarse en la publicación IBM Tivoli Access Manager Base Guía deladministrador.

Configuración del restablecimiento y ampliación de laduración de la caché de sesión

Restablecimiento del valor de duración de la caché de sesiónLa caché de sesión del usuario tiene una duración limitada, tal como especifica elparámetro timeout en la stanza [session] del archivo de configuraciónwebseald.conf. El valor predeterminado, en minutos, es de 3600 (1 hora):[session]timeout = 3600

Independientemente de la actividad o inactividad de la sesión, la caché de sesiónse elimina cuando se alcanza el valor de duración, en cuyo momento se finaliza lasesión del usuario.

No obstante, el usuario puede configurar el restablecimiento de la duración de lacaché de sesión siempre que se produzca una reautenticación. Con estaconfiguración, la sesión del usuario ya no tendrá un valor máximo único deduración. Cada vez que se produzca una reautenticación, se restablecerá el valorde duración de la caché de sesión.

Puede configurar el restablecimiento de la duración de la caché de sesión con elparámetro reauth-reset-lifetime en la stanza [reauthentication] del archivo deconfiguración webseald.conf:[reauthentication]reauth-reset-lifetime = yes


Este parámetro es también adecuado para la reautenticación debido a la caducidaddel valor de tiempo de espera de inactividad de la caché de sesión. Consulte elapartado “Configuración de la reautenticación basada en la política de inactividadde sesión” en la página 137.

Ampliación del valor de duración de la caché de sesiónEs posible que el valor de la duración de la caché de sesión caduque mientras elusuario está realizando una reautenticación. Esta situación se produce bajo lascondiciones siguientes:v El usuario solicita un recurso protegido por una POP de reautenticación.v El valor de duración de la caché de sesión del usuario está muy cerca de su

caducidad.

La duración de la caché de sesión puede caducar después de que se envíe alusuario el formulario de inicio de sesión de reautenticación y antes de que sedevuelva el formulario de inicio de sesión completado. Cuando caduque el valorde duración de la caché de sesión, se suprimirá la entrada de la caché de sesión.


Cuando se devuelva el formulario de inicio de sesión a WebSEAL, ya no habrá unasesión para ese usuario. Además, se perderán todos los datos de la petición deusuario guardada en la caché.

Puede configurar una ampliación de tiempo, o “período de gracia”, para laduración de la caché de sesión, en caso de que la duración de la caché de sesióncaduque durante la reautenticación. El parámetro reauth-extend-lifetime de lastanza [reauthentication] del archivo de configuración webseald.conf proporcionaesta ampliación de tiempo, en segundos. Por ejemplo:[reauthentication]reauth-extend-lifetime = 20

El valor predeterminado, “0”, no proporciona ninguna ampliación al valor detiempo de espera de la caché de sesión.

El parámetro reauth-extend-lifetime se aplica a los usuarios con entradas de cachéde sesión existentes y a los que se requiera reautenticación. Por ejemplo:v Los usuarios que realicen una reautenticación como resultado de la política de

seguridad POP.v Los usuarios que realicen una reautenticación como resultado de la inactividad

de la caché de sesión.v Los usuarios que realicen una autenticación incremental.

Se prevé que la opción reauth-extend-lifetime se utilice junto con la opciónreauth-reset-lifetime=yes.

Este parámetro es también adecuado para la reautenticación debido a la caducidaddel valor de tiempo de espera de inactividad de la caché de sesión. Consulte elapartado “Configuración de la reautenticación basada en la política de inactividadde sesión” en la página 137.

Configuración de la reautenticación basada en la política deinactividad de sesión

Access Manager WebSEAL puede forzar a un usuario a realizar un inicio de sesiónadicional (reautenticación) para asegurarse de que un usuario que accede a unrecurso protegido es la misma persona que inicialmente se ha autenticado alcomienzo de la sesión. La reautenticación puede activarse con una política deobjetos protegidos (POP) en el objeto protegido o a causa de la caducidad del valorde tiempo de espera de inactividad de la caché de sesión de WebSEAL.

Este apartado analiza la reautenticación basada en la caducidad del valor detiempo de espera de inactividad de la caché de sesión de WebSEAL.

Condiciones que afectan a la reautenticación por inactividadUna reautenticación forzada proporciona protección adicional para los recursossensibles en el dominio seguro. La reautenticación basada en la política deinactividad de sesión se habilita mediante un parámetro de configuración y seactiva con la caducidad del valor de tiempo de espera de inactividad de la cachéde sesión.

La reautenticación está soportada por los siguientes métodos soportados deautenticación de WebSEAL:v Autenticación de formularios (nombre de usuario y contraseña)


v Autenticación de señales

Además, se puede escribir un CDAS de nombre de usuario/contraseñapersonalizado que dé soporte a la reautenticación.

La reautenticación supone que el usuario ha iniciado la sesión inicialmente en eldominio seguro y que existe una credencial válida para el usuario. Durante lareautenticación, el usuario debe iniciar la sesión utilizando la misma identidad quegeneró la credencial existente. WebSEAL preserva la información de sesión originaldel usuario, incluida la credencial, durante la reautenticación. Durante lareautenticación no se sustituye la credencial.

Además, durante la reautenticación, WebSEAL guarda en la caché la petición queactivó la reautenticación. Cuando la reautenticación se haya realizadocorrectamente, los datos de la caché se utilizarán para volver a crear la petición.Consulte el apartado “Configuración del almacenamiento en la caché de peticionesdel servidor WebSEAL” en la página 70.

Normalmente, una sesión del usuario se regula mediante un valor de inactividadde sesión y un valor de duración de sesión. Cuando WebSEAL se configura para lareautenticación basada en la inactividad de sesión, la caché de sesión del usuariose “marca con un indicador” siempre que caduca el valor de tiempo de espera deinactividad de la sesión. La caché de la sesión (que contiene la credencial delusuario) no se elimina. El usuario puede continuar y acceder a los recursos noprotegidos. No obstante, si el usuario solicita un recurso protegido, WebSEALenvía una solicitud de inicio de sesión.

Tras realizar una reautenticación correcta, el “indicador” de la sesión inactiva seelimina y el temporizador de inactividad se restablece. No obstante, el valor deduración de la caché de sesión determina, en última instancia, la longitud máximade la sesión. Cuando caduque este valor de duración, la sesión terminaráindependientemente de la actividad que haya.

Si falla la reautenticación, WebSEAL devuelve de nuevo la solicitud de inicio desesión. La caché de sesión sigue “marcada con un indicador” y el usuario puedecontinuar como usuario no autenticado hasta que caduque el valor de duración dela caché de sesión.

Si la reautenticación es satisfactoria, pero la comprobación de ACL falla para eserecurso, se devuelve un error 403 “No autorizado” y se rechaza el acceso delusuario al recurso solicitado.

Otras dos condiciones pueden terminar una sesión de usuario: el usuario puedefinalizar la sesión de forma explícita o un administrador puede terminar unasesión de usuario. Consulte el apartado “Terminación de sesiones de usuario” en lapágina 222.

Se dispone de la configuración para restablecer el temporizador de duración de lacaché de sesión de WebSEAL. Además, se puede configurar un período de graciapara permitir que haya tiempo suficiente para completar el proceso dereautenticación antes de que caduque el tiempo de espera de duración de la cachéde sesión.


Habilitación de la reautenticación por inactividadPara configurar WebSEAL con el fin de “marcar con un indicador” las sesionesinactivas, en vez de eliminarlas de la caché de sesión, establezca el valor delparámetro reauth-for-inactive en “yes” en la stanza [reauthentication] del archivode configuración webseald.conf:[reauthentication]reauth-for-inactive = yes

El valor predeterminado para este parámetro es “no”.

Configuración del restablecimiento y ampliación de laduración de la caché de sesión

Restablecimiento del valor de duración de la caché de sesiónLa caché de sesión del usuario tiene una duración limitada, tal como especifica elparámetro timeout en la stanza [session] del archivo de configuraciónwebseald.conf. El valor predeterminado, en minutos, es de 3600 (1 hora):[session]timeout = 3600

Independientemente de la actividad o inactividad de la sesión, la caché de sesiónse elimina cuando se alcanza el valor de duración, en cuyo momento se finaliza lasesión del usuario.

No obstante, el usuario puede configurar el restablecimiento de la duración de lacaché de sesión siempre que se produzca una reautenticación. Con estaconfiguración, la sesión del usuario ya no tendrá un valor máximo único deduración. Cada vez que se produzca una reautenticación, se restablecerá el valorde duración de la caché de sesión.

Puede configurar el restablecimiento de la duración de la caché de sesión con elparámetro reauth-reset-lifetime en la stanza [reauthentication] del archivo deconfiguración webseald.conf:[reauthentication]reauth-reset-lifetime = yes


Este parámetro es también adecuado para la reautenticación debido a la política deseguridad (POP). Consulte el apartado “Configuración de la reautenticación basadaen la política de seguridad” en la página 134.

Ampliación del valor de duración de la caché de sesiónEs posible que el valor de la duración de la caché de sesión caduque mientras elusuario está realizando una reautenticación. Esta situación se produce bajo lascondiciones siguientes:v El usuario solicita un recurso protegido por una POP de reautenticación.v El valor de duración de la caché de sesión del usuario está muy cerca de su

caducidad.

La duración de la caché de sesión puede caducar después de que se envíe alusuario el formulario de inicio de sesión de reautenticación y antes de que sedevuelva el formulario de inicio de sesión completado. Cuando caduque el valorde duración de la caché de sesión, se suprimirá la entrada de la caché de sesión.


Cuando se devuelva el formulario de inicio de sesión a WebSEAL, ya no habrá unasesión para ese usuario. Además, se perderán todos los datos de la petición deusuario guardada en la caché.

Puede configurar una ampliación de tiempo, o “período de gracia”, para laduración de la caché de sesión, en caso de que la duración de la caché de sesióncaduque durante la reautenticación. El parámetro reauth-extend-lifetime de lastanza [reauthentication] del archivo de configuración webseald.conf proporcionaesta ampliación de tiempo, en segundos. Por ejemplo:[reauthentication]reauth-extend-lifetime = 20

El valor predeterminado, “0”, no proporciona ninguna ampliación al valor detiempo de espera de la caché de sesión.

El parámetro reauth-extend-lifetime se aplica a los usuarios con entradas de cachéde sesión existentes y a los que se requiera reautenticación. Por ejemplo:v Los usuarios que realicen una reautenticación como resultado de la política de

seguridad POP.v Los usuarios que realicen una reautenticación como resultado de la inactividad

de la caché de sesión.v Los usuarios que realicen una autenticación incremental.

Se prevé que la opción reauth-extend-lifetime se utilice junto con la opciónreauth-reset-lifetime=yes.

Este parámetro es también adecuado para la reautenticación debido a la política deseguridad (POP). Consulte el apartado “Configuración de la reautenticación basadaen la política de seguridad” en la página 134.


Capítulo 6. Soluciones de inicio de sesión en dominioscruzados

Cuando se implementa WebSEAL como servidor proxy para proporcionarprotección a un dominio seguro, a menudo se deben proporcionar soluciones paraun inicio de sesión único en los recursos. En este capítulo se describen dossoluciones de inicio de sesión único en dominios cruzados.

Índice de temas:v “Configuración de la autenticación de CDSSO” en la página 141v “Configuración de inicio de sesión único de comunidad electrónica” en la página

145

Configuración de la autenticación de CDSSOCDSSO (Cross-Domain Single Sign-on - Inicio de sesión único en dominioscruzados) de Access Manager proporciona un mecanismo para transferircredenciales de usuario entre múltiples dominios seguros. CDSSO permite a losusuarios web realizar un inicio de sesión único y moverse sin problemas entre dosdominios seguros separados. El mecanismo de autenticación de CDSSO no utilizaun Servidor maestro de autenticación (véase SSO de comunidad electrónica).

CDSSO da soporte a los objetivos de la arquitectura de red escalable al permitir laintegración de varios dominios seguros. Por ejemplo, se puede configurar una granextranet corporativa con dos o más dominios únicos, cada uno con sus propiosusuarios y espacio de objetos. 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 otro dominio, elmecanismo CDSSO transfiere una señal de identidad de usuario cifrada del primerdominio al segundo. El segundo dominio tendrá ahora la identidad del usuario(como autenticado en el primer dominio) y el usuario no se verá forzado a iniciarotra sesión.

Integración de una biblioteca compartida CDMF personalizadaEn muchos casos de CDSSO, es posible que la correlación unívoca predeterminadaentre los usuarios en distintos dominios no sirva para todos los requisitos dedespliegue.

CDMF (Cross-domain Domain Mapping FrameWork) es una interfaz deprogramación que permite crear una biblioteca compartida personalizada quepuede gestionar atributos de usuarios ampliados y proporcionar servicios decorrelación para la identidad del usuario.

La interfaz de programación CDMF ofrece una gran flexibilidad para personalizarla correlación de identidades de usuario y gestionar los atributos de usuario.

Flujo de proceso de autenticación para CDSSO con CDMFLa siguiente descripción del flujo de proceso se ilustra en la Figura 26.


1. Cualquier usuario que desee participar en varios dominios debe tener unacuenta de usuario válida en el dominio principal y una identidad que se puedacorrelacionar en una cuenta válida de cada uno de los dominios remotosparticipantes.Un usuario no puede invocar la funcionalidad de CDSSO sin autenticarseinicialmente en un dominio seguro inicial (A) que contenga la cuenta delusuario.

2. El usuario realiza una petición para acceder a un recurso del dominio B através de un vínculo personalizado en una página web.El vínculo contiene una expresión CDSSO especial:/pkmscdsso?<dirección-URL-destino>

Por ejemplo:/pkmscdsso?https://www.domainB.com/index.html

3. En primer lugar, el servidor WebSEAL del dominio A procesa la petición.WebSEAL crea una señal de autenticación que contiene la identidad de AccessManager del usuario (nombre corto), el dominio actual (“A”), informaciónadicional del usuario y una indicación de la hora.La información de usuario adicional se obtiene mediante una llamada a labiblioteca compartida CDMF personalizada (cdmf_get_usr_attributes). Estabiblioteca proporciona atributos de usuario que pueden ser utilizados por eldominio B durante el proceso de correlación de usuarios.WebSEAL cifra mediante DES triple estos datos de señal con la clave simétricagenerada por el programa de utilidad cdsso_key_gen. Se comparte y almacenaeste archivo de claves en la stanza [cdsso-peers] del archivo de configuraciónwebseald.conf de los servidores WebSEAL del dominio A y el dominio B.La señal contiene una indicación de la hora configurable (authtoken-lifetime)que define la duración de la señal. La indicación de la hora, cuando seconfigura correctamente, puede evitar los ataques de respuestas.

4. El servidor WebSEAL del dominio A redirige la petición más la señal cifrada devuelta al navegador y, a continuación, al servidor WebSEAL del dominio B(redirección HTTP).

5. El servidor WebSEAL del dominio B utiliza su versión del mismo archivo declaves para descifrar y validar la señal como si llegara del dominio en cuestión.

6. En estos momentos, el servidor WebSEAL del dominio B llama a una bibliotecade mecanismo de autenticación de CDSSO. Como respuesta, esta bibliotecaCDSSO llama a la biblioteca CDMF personalizada, que es la que ejecuta lacorrelación de usuarios (cdmf_map_usr).La biblioteca CDMF pasa la identidad del usuario, y opcionalmenteinformación adicional de atributos de usuarios, a la biblioteca CDSSO. Labiblioteca CDSSO utiliza esta información para crear una credencial.

7. El servicio de autorizaciones del dominio B permite o rechaza el acceso a losobjetos protegidos basándose en la credencial del usuario y los permisos ACLespecíficos asociados con los objetos solicitados.


Habilitación e inhabilitación de la autenticación de CDSSOEl parámetro cdsso-auth, que se encuentra en la stanza [cdsso] del archivo deconfiguración webseald.conf, habilita e inhabilita el método de autenticación deCDSSO.v Para habilitar el método de autenticación de CDSSO, escriba “http”, “https”, o

“both” (ambos).v Para inhabilitar el método de autenticación de CDSSO, escriba “none”.

Por ejemplo:[cdsso]cdsso-auth = https

Configuración del mecanismo de autenticación de CDSSOEl parámetro de configuración cdsso especifica la biblioteca compartida codificadade forma que no se pueda modificar para correlacionar la información deautenticación.v En UNIX, el archivo que proporciona la función de correlación incorporada es

una biblioteca compartida denominada libcdssoauthn.v En Windows, el archivo que proporciona la función de correlación incorporada

es una DLL denominada cdssoauthn.




cdsso libcdssoauthn.so libcdssoauthn.a cdssoauthn.dll libcdssoauthn.sl

Puede configurar el mecanismo de autenticación de CDSSO especificando elparámetro cdsso con el nombre específico para la plataforma del archivo debiblioteca compartida en la stanza [authentication-mechanism] del archivo deconfiguración webseald.conf.

Figura 26. Proceso de inicio de sesión único en dominios cruzados con CDMF

Capítulo 6. Soluciones de inicio de sesión en dominios cruzados 143

Por ejemplo:

Solaris:[authentication-mechanisms]cdsso = libcdssoauthn.so

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ñal mediante unaclave generada por el programa de utilidad cdsso_key_gen. Debe “sincronizar”esta clave compartiendo el archivo de claves con todos los servidores WebSEAL decada uno de los dominios participantes. Todos los servidores WebSEALparticipantes de cada dominio deben utilizar la misma clave.

Nota: La creación y distribución de archivos de claves no forma parte del procesoCDSSO de Access Manager.

El programa de utilidad cdsso_key_gen precisa que se especifique la ubicación(nombre de ruta de acceso completa) del archivo de claves cuando se ejecute elprograma de utilidad:

UNIX: # cdsso_key_gen <nombre-ruta-acceso-completa>

Windows: MSDOS> cdsso_key_gen <nombre-ruta-acceso-completa>

Especifique esta ubicación del archivo de claves en la stanza [cdsso-peers] delarchivo de configuración webseald.conf del servidor WebSEAL que participa encada dominio. El formato incluye el nombre de máquina WebSEAL y la ubicacióndel archivo de 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-acceso>/A-B.key

Ejemplo de configuración del Dominio B:[cdsso-peers]www.domainA.com = <nombre-ruta-acceso>/A-B.key

En el ejemplo anterior, el archivo A-B.key se generaría en una máquina (WebSEALA, por ejemplo) y se copiaría de una forma manual (y segura) en la otra máquina(WebSEAL B, por ejemplo).

Configuración de la indicación de la hora de señalLa señal contiene una indicación de la hora configurable que define la duración dela señal de identidad. Cuando caduca la indicación de la hora, se considera que laseñal no es válida, por lo que no se utiliza. La indicación de la hora se utiliza paraevitar los ataques de respuestas al establecer un valor lo bastante corto para evitarque se robe la señal y se responda durante su período de duración.


El parámetro authtoken-lifetime, que se encuentra en la stanza [cdsso] del archivode configuración webseald.conf, establece el valor de la duración de la señal. Elvalor se expresa en segundos. El valor predeterminado es 180:[cdsso]authtoken-lifetime = 180

Debe tener en cuenta las diferencias horarias entre los dominios participantes.

Expresión de vínculos HTML de CDSSOLos vínculos HTML a los recursos de un dominio seguro secundario debencontener una expresión CDSSO especial:/pkmscdsso?<dirección-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 de autenticación (comonombre de usuario y contraseña), no contendrá una identidad de usuario que seafiable en el dominio de recepción. La propia señal se debe proteger contra robo yrespuesta.

La señal está protegida contra robo a través del uso de SSL para proteger lascomunicaciones entre los servidores WebSEAL y los usuarios. La señal podríarobarse del historial del navegador del usuario. La indicación de la hora de laseñal debería ser lo bastante corta para que fuera poco probable que se pudierarobar la señal y reproducirla durante la duración de la señal.

Sin embargo, las señales caducadas en cuanto a su indicación de la hora siguensiendo vulnerables a los ataques criptográficos. Si se descubre la clave utilizadapara cifrar la señal o si se compromete de alguna otra forma, algún usuariomalintencionado podría crear sus propias señales.

Éstas se podrían insertar en un “flujo pseudo-CDSSO”. No se podrían distinguir delas señales de autenticación reales para los servidores WebSEAL que participan enel dominio CDSSO. Por este motivo, las claves utilizadas para proteger las señalesse deben gestionar también con cuidado y se deben modificar regularmente.

Configuración de inicio de sesión único de comunidad electrónicaEl inicio de sesión único de comunidad electrónica es otra implementación de laautenticación de dominios cruzados en un entorno de Access Manager. El objetivode la autenticación de dominios cruzados es permitir el acceso de los usuarios a losrecursos, a través de varios servidores en varios dominios, sin necesidad de repetirla autenticación.

Una “comunidad electrónica” es un grupo de dominios distintos (Access Managero DNS) que participan en una relación empresarial. Estos dominios participantes sepueden configurar como parte de una empresa (quizás utilizando nombres DNSdiferentes, por motivos geográficos), o como empresas distintas con una relacióncompartida (por ejemplo, oficinas de la compañía, una empresa de seguros o unaempresa de gestión financiera).


En cada caso, siempre hay un dominio que se designa como dominio “inicial” o“propietario”. En el caso de empresas participantes, el dominio inicial posee losacuerdos empresariales que gobiernan la comunidad electrónica.

En ambos casos, la información de autenticación sobre los usuarios que participanen la comunidad electrónica (incluidos los nombres de usuario y las contraseñasutilizados para la autenticación) se mantiene en el dominio inicial. Esta disposiciónpermite tener un único punto de referencia para cuestiones de administración,como, por ejemplo, las llamadas al escritorio de ayuda dentro de la comunidadelectrónica, que hacen todas referencia al dominio inicial.

Como alternativa, puede utilizar Web Portal Manager de Access Manager paradelegar la gestión de esta información, de manera que los dominios participantestengan responsabilidades en la administración de sus propios usuarios.

En el siguiente diagrama se muestra un ejemplo de una comunidad electrónica condos dominios participantes: dominio A (dA.com) y dominio B (dB.com). En esteejemplo, el dominio A representa el dominio inicial o propietario. El dominio B esun dominio participante o “remoto”.

El dominio inicial es “propietario” de los usuarios —esto es, controla lainformación de autenticación de los usuarios. Independientemente de dónde hagael usuario la petición de recursos, el dominio inicial siempre es el dominio dondeel usuario se tiene que autenticar.

La autenticación se produce en un servidor maestro de autenticación (MAS)—unservidor (o conjunto de servidores replicados) que se encuentra en el dominioinicial y que está configurado para autenticar todos los usuarios. El diagramarepresenta el MAS como mas.dA.com. La labor del MAS debe estar restringida aproporcionar servicios de autenticación. El MAS no debe contener recursos queestén disponibles a otros usuarios.

Figura 27. El modelo de comunidad electrónica


Después de que el usuario se ha autenticado correctamente en el MAS, el MASgenera una señal de “garantización”. Esta señal se pasa de nuevo al servidor en elque el usuario está realizando la petición. El servidor considera esta señal de“garantización” como prueba de que el usuario se ha autenticado correctamente enel MAS y puede participar en la comunidad electrónica.

La transferencia de información entre los dominios de la comunidad electrónica sedescribe en detalle en el apartado “Flujo de proceso de la comunidad electrónica”en la página 148.

Características y requisitos de comunidad electrónicav El modelo da soporte al acceso a través de direcciones URL directas

(marcadores) a los recursos. Esta característica contrasta con el modelo CDSSOque se basa en un vínculo pkmscdsso especialmente configurado (consulte elapartado “Configuración de la autenticación de CDSSO” en la página 141).

v La implementación de la comunidad electrónica requiere la configuraciónconsistente de todos los servidores WebSEAL en todos los dominios queparticipan en la comunidad electrónica.

v Todos los usuarios que participan en la comunidad electrónica se autentican enun único servidor maestro de autenticación (MAS) que se encuentra en eldominio inicial.

v La implementación de la comunidad electrónica permite la autenticación “local”en dominios remotos, si el usuario no tiene una cuenta válida con el MAS (porejemplo, los usuarios que pertenecen al dominio B pero que no participan en lacomunidad electrónica de dominio A-dominio B).Un usuario que no pasa la autenticación con el MAS al solicitar un recurso enun dominio no MAS (pero que sí participa) tiene la opción de autenticarse en elservidor local en el que se está realizando la petición.

v El MAS (y los otros servidores seleccionados finalmente en los dominiosremotos) “garantizan” la identidad autenticada del usuario.

v Se utilizan cookies específicas del dominio para identificar al servidor que puedeproporcionar servicios de “garantización”. De esta forma, los servidores de undominio remoto pueden solicitar información de “garantización” de forma local.El contenido cifrado de las cookies de la comunidad electrónica no incluyeinformación de seguridad ni de identidad de usuarios.

v Se utilizan señales especiales para pasar la identidad de usuario “garantizada”cifrada. La señal de “garantización” no contiene información de autenticacióndel usuario. La integridad viene garantizada por la clave secreta compartida(DES triple). La señal contiene un valor de tiempo de espera (de duración) paralimitar la duración de la validez de la señal.

v La implementación de la comunidad electrónica tiene soporte en HTTP yHTTPS.

v Los dominios individuales de la comunidad electrónica gestionan sus propiasidentidades de usuario y privilegios asociados. Puede utilizar la API de CDMF(Cross-domain Domain Mapping Function) para correlacionar un usuario de undominio remoto con un usuario válido en el dominio local.Si los dominios de la comunidad electrónica comparten identidades de usuarioglobales, esta función de correlación no es necesaria.

v La configuración de la comunidad electrónica se establece en el archivowebseald.conf de cada servidor WebSEAL participante.


Flujo de proceso de la comunidad electrónicaUna comunidad electrónica está formada por un servidor maestro de autenticación(MAS) WebSEAL y otros servidores WebSEAL ubicados en el dominio inicial y losdominios remotos. El MAS puede existir como instancia única de un servidorWebSEAL, o como un conjunto de servidores WebSEAL replicados ubicados detrásde un equilibrador de cargas (donde el equilibrador de cargas se identifica como elMAS).

Todos los servidores WebSEAL locales y remotos participantes tienen que estarconfigurados para utilizar el MAS del dominio inicial en la autenticación declientes inicial. Este es un requisito obligatorio para los servidores en el dominioinicial, y un requisito modificable para los servidores en los dominios remotos. Porejemplo, algunos servidores en los dominios remotos se pueden configurar paraque gestionen sus propia autenticación. Estos servidores, y los recursos queprotegen, pueden funcionar independientemente de la comunidad electrónica,incluso si se encuentran en un dominio participante de la comunidad electrónica.

La implementación de la comunidad electrónica se basa en un sistema de“garantización”. Normalmente, cuando un usuario solicita un recurso a unservidor WebSEAL en el que no ha establecido una sesión válida, WebSEAL solicitaal usuario información de autenticación. En una configuración de comunidadelectrónica, el servidor 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álida para eseusuario. Para la primera petición del usuario, el servidor de “garantización” essiempre el MAS. El MAS continúa funcionando como servidor de “garantización”para los recursos ubicados en el dominio inicial. Si el usuario continúa realizandopeticiones de recursos a través de la comunidad electrónica, un servidor individualen cada dominio remoto puede crear su propia credencial para el usuario (a partirde la información de la identidad del usuario del MAS) y asumir la función deservidor de “garantización” para los recursos de su dominio.

La verificación solicitada del servidor de “garantización” toma la forma de unaseñal de “garantización”. El servidor de “garantización” crea la señal y la devuelveal servidor WebSEAL que la ha solicitado. La información de la identidad delusuario en la señ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 la petición creacredenciales y una sesión local para ese usuario. El usuario tiene ahora acceso alrecurso solicitado, siguiendo los controles normales de autorización. El usuariotiene la ventaja de que no debe repetir la autenticación—uno de los objetivos delmodelo de comunidad electrónica.

Consulte el siguiente diagrama para seguir el flujo de proceso de la comunidadelectrónica en lo que queda de apartado. El flujo de proceso describe dos ejemplosposibles de PRIMER acceso (1 y 2). A continuación, se presentan dos ejemplosposibles de SIGUIENTE acceso (3 y 4) que siguen inmediatamente después de 2 o3. El ejemplo 5 se produce en cualquier momento después del acceso inicial.


Servidores de “garantización”

v El MAS se utiliza siempre para autenticar el usuario que accede a cualquierparte de la comunidad electrónica por primera vez.El MAS sólo se debe utilizar como servidor de autenticaciones, y no comoproveedor de recursos. El MAS no se debe configurar para funcionar comoservidor maestro de autenticaciones y, simultáneamente, proteger los recursos.Esta recomendación afecta al rendimiento, y no es un requisito de seguridad.

v El MAS es siempre el servidor de “garantización” para el dominio inicial(dominio A en este ejemplo).

v Se utiliza una cookie de comunidad electrónica específica del dominio paraidentificar el servidor de “garantización” para los otros servidores dentro de undominio dado. El servidor de “garantización” es el primer servidor en undominio que solicita una señal de “garantización” al MAS. El servidor de“garantización” proporciona información de “garantización” para el usuario deldominio. Las siguientes peticiones de servicios de “garantización” en undominio remoto dado se pueden hacer de forma local mediante este servidor, enlugar de acceder al MAS fuera 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)

v El usuario solicita un recurso protegido por WebSEAL 1 (dentro del mismodominio que MAS). El navegador no contiene ninguna cookie de comunidadelectrónica para este dominio. WebSEAL 1 no tiene credenciales almacenadas enla caché para el usuario.

v La configuración de WebSEAL 1 tiene habilitada la autenticación de lacomunidad electrónica, y especifica la ubicación del MAS. WebSEAL 1redirecciona el navegador a una dirección URL especial de “garantización” en elMAS.

v El MAS recibe la petición de “garantización” y, al no encontrar las credencialespara ese usuario, solicita al usuario que inicie la sesión.

v Si el inicio de sesión es correcto, el MAS crea una credencial para el usuario, laalmacena en la caché, y redirecciona de nuevo el navegador a la dirección URLsolicitada originalmente en WebSEAL 1 con una señal de “garantización” cifrada.

Figura 28. Flujo de proceso de la comunidad electrónica


Asimismo, se coloca una cookie de comunidad electrónica específica del dominioA en el navegador para identificar el servidor de “garantización” de estedominio (en este caso, el MAS).Si el intento de inicio de sesión no es correcto, el MAS devuelve una señal de“garantización” que indica un estado de error. Esta señal se construye para queno sea distinguible de una señal de “garantización” de estado correcto. Elservidor que realiza la petición reacciona a una señal de estado de error como siel usuario no hubiera pasado la autenticación local.

v WebSEAL 1 descifra la señal y crea su propia credencial para el usuario.

Nota: La correlación de identidades no debería ser necesaria dentro del mismodominio. Si se requiere la correlación de identidades, WebSEAL 1 debeutilizar CDMF (Cross-domain Domain Mapping Framework).

v El servicio de autorizaciones permite o rechaza la petición.

(2) PRIMER acceso a la comunidad electrónica : WebSEAL 3 (Dominio B)

v El usuario solicita un recurso protegido por WebSEAL 3 (dominio B remoto). Elnavegador no contiene ninguna cookie de comunidad electrónica para estedominio. WebSEAL 3 no tiene credenciales almacenadas en la caché para elusuario.

v La configuración de WebSEAL 3 tiene habilitada la autenticación de lacomunidad electrónica, y especifica la ubicación del MAS. WebSEAL 3redirecciona el navegador a una dirección URL especial de “garantización” en elMAS.

v El MAS recibe la petición de “garantización” y, al no encontrar las credencialespara ese usuario, solicita al usuario que inicie la sesión.

v Si el inicio de sesión es correcto, el MAS crea una credencial para el usuario, laalmacena en la caché, y redirecciona de nuevo el navegador a la dirección URLsolicitada originalmente en WebSEAL 3 con una señal de “garantización” cifrada.Asimismo, se coloca una cookie de comunidad electrónica específica del dominioA en el navegador para identificar el servidor de “garantización” de estedominio (en este caso, el MAS).Si el intento de inicio de sesión no es correcto, el MAS devuelve una señal de“garantización” que indica un estado de error. Esta señal se construye para queno sea distinguible de una señal de “garantización” de estado correcto. Elservidor que realiza la petición reacciona a una señal de estado de error como siel usuario no hubiera pasado la autenticación local.

v WebSEAL 3 descifra la señal y crea su propia credencial para el usuario.v WebSEAL 3 crea y establece una segunda cookie de comunidad electrónica

(válida para el dominio B) en el navegador, que identifica a WebSEAL 3 como elservidor de “garantización” para el dominio B.


(3) SIGUIENTE acceso a la comunidad electrónica: WebSEAL 2 (Dominio A)

v El usuario solicita un recurso protegido por WebSEAL 2 (dentro del mismodominio que MAS). El navegador contiene una cookie de comunidad electrónicadel dominio A que identifica al MAS como servidor de “garantización”.WebSEAL 2 recibe esta cookie. WebSEAL 2 no tiene credenciales almacenadas enla caché para el usuario.

v La configuración de WebSEAL 2 tiene habilitada la autenticación de lacomunidad electrónica, y especifica la ubicación del MAS. La presencia de lacookie de comunidad electrónica del dominio A anula la configuración deWebSEAL 2 para la ubicación de MAS. La cookie proporciona a WebSEAL 2 la


identidad del servidor de “garantización”. (Si se da primero el ejemplo 2,también habría una cookie de dominio B mantenida en el navegador que no seenviaría a un servidor de dominio A).

v WebSEAL 2 redirecciona el navegador a una dirección URL especial de“garantización” en el servidor de “garantización” del dominio A identificado enla cookie (es este caso, el MAS, ya que WebSEAL 2 está en el dominio A).

v El MAS recibe la petición de “garantización” y busca las credenciales para eseusuario en la caché (esto se produce en el ejemplo 1 y 2).

v El MAS redirecciona de nuevo el navegador a la dirección URL solicitadaoriginalmente en WebSEAL 2 con una señal de “garantización” cifrada.

v WebSEAL 2 descifra la señal y crea su propia credencial para el usuario.v El servicio de autorizaciones permite o rechaza la petición.

(4) SIGUIENTE acceso a la comunidad electrónica: WebSEAL 4 (Dominio B)

v El usuario solicita un recurso protegido por WebSEAL 4 (dominio B remoto). Siel ejemplo 2 se produce primero, el navegador contiene una cookie decomunidad electrónica del dominio B que identifica a WebSEAL 3 como servidorde “garantización”. WebSEAL 4 no tiene credenciales almacenadas en la cachépara el usuario.

v La configuración de WebSEAL 4 tiene habilitada la autenticación de lacomunidad electrónica, y especifica la ubicación del MAS. La presencia de unacookie de comunidad electrónica del dominio B anula la configuración deWebSEAL 4 para la ubicación de MAS. La cookie proporciona a WebSEAL 4 laidentidad del servidor de “garantización”. (Si se da primero el ejemplo 2, sólohabrá una cookie de dominio A mantenida en el navegador que no se enviaría aun servidor de dominio B. En su lugar, se utilizará la ubicación configurada delMAS. WebSEAL 4 se convertirá en el servidor de “garantización” para eldominio B.)

v Si el ejemplo 2 se produce primero, WebSEAL 4 redirecciona el navegador a unadirección URL especial de “garantización” en el servidor de “configuración” deldominio B identificado en la cookie de dominio B (en este caso WebSEAL 3).

v WebSEAL 3 recibe la petición de “garantización” y busca las credenciales paraese usuario en la caché (esto se produce en el ejemplo 2).

v WebSEAL 3 redirecciona de nuevo el navegador a la dirección URL solicitadaoriginalmente en WebSEAL 4 con una señal de “garantización” cifrada.

v WebSEAL 4 descifra la señal y crea su propia credencial para el usuario.v El servicio de autorizaciones permite o rechaza la petición.

(5) OTRO acceso a la comunidad electrónica: WebSEAL 2 (Dominio A)

v El usuario se conecta a WebSEAL 2 (dominio A) con una petición. Si se haproducido el ejemplo 3, WebSEAL 2 tiene credenciales almacenadas en la cachépara el usuario.


Fin de sesión de la comunidad electrónica

v Si el usuario finaliza la sesión cerrando el navegador, se borrarán todas lassesiones SSL y las cookies de comunidad electrónica.

v Si el usuario finaliza la sesión a través de la página /pkmslogout, se borrarán lasesión SSL y la cookie de comunidad electrónica para ese dominio.


Información de la cookie de comunidad electrónicav La cookie de comunidad electrónica es una cookie específica del dominio

establecida por un servidor WebSEAL, almacenada en la memoria del navegadordel usuario y transmitida a otros servidores WebSEAL (en el mismo dominio) enlas siguientes peticiones.

v La cookie específica del dominio contiene el nombre del servidor de“garantización”, la identidad de la comunidad electrónica, una ubicación(dirección URL) del servidor de “garantización” y la funcionalidad, y un valorde duración. La cookie no contiene información del usuario ni de seguridad.

v La cookie de comunidad electrónica permite a los servidores de los dominiosparticipantes solicitar información de “garantización” de forma local. La cookiede comunidad electrónica para el dominio en el que reside el MAS juega unpapel menos importante.

v La cookie tiene un valor de duración (tiempo de espera) que se establece en elarchivo de configuración webseald.conf. Este valor de duración especificadurante cuánto tiempo puede el servidor 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.

v La cookie se borra de la memoria cuando se cierra el navegador. Si el usuariofinaliza la sesión de un dominio específica, la cookie de comunidad electrónicase sobrescribe como vacía. Esta acció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ónica requiere unafuncionalidad dedicada, a la que se accede a través de dos direcciones URLespecialmente construidas: la petición de “garantización” y la respuesta de“garantización”. Estas direcciones URL se construyen durante las redireccionesHTTP “garantizadas” de comunidad electrónica, a partir de la información deconfiguración de webseald.conf.

La petición de “garantización”

La petición de “garantización” se desencadena cuando un usuario solicita unrecurso de un servidor de destino (configurado para la comunidad electrónica) queno contiene información de credenciales del usuario. El servidor envía unaredirección HTTP al servidor de “garantización” (el MAS o un servidoridentificado en una cookie de comunidad electrónica).

La petición de “garantización” contiene la siguiente información:https://<servidor-garantización>/pkmsvouchfor?<nombre-comunidad-electrónica>&<dirección-URL-destino>

El servidor receptor comprueba el nombre-comunidad-electrónica para validar laidentidad de la comunidad electrónica. El servidor receptor utiliza ladirección-URL-destino de la respuesta de “garantización” para redireccionar denuevo el navegador a la página solicitada originalmente.

La dirección URL de “garantización” de pkmsvouchfor se puede configurar.

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” alservidor de destino.

La respuesta de “garantización” contiene la siguiente información:https://<dirección-URL-destino>?PD-VFHOST=<servidor-garantización>&PD-VF=<señal-cifrada>

El parámetro PD-VFHOST identifica al servidor que ha realizado la operación de“garantización”. El servidor receptor (destino) utiliza esta información paraseleccionar la clave correcta necesaria para descifrar la señal de “garantización”(PD-VF). El parámetro PD-VF representa 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 el inicio de sesión único en dominios cruzados, la información deidentidad de usuario debe transmitirse entre los servidores. Esta informaciónconfidencial se gestiona utilizando una redirección que incluye la información deidentidad cifrada como parte de la dirección URL. Estos datos cifrados sedenominan señal de “autenticación”.v La señal contiene el estado de error o de éxito de “garantización”, la identidad

del usuario (si es correcto), el nombre completo del servidor que ha creado laseñal, la identidad de la comunidad electrónica y el valor de hora de creación.

v El poseedor de una señal de “garantización” válida puede utilizarla paraestablecer una sesión (y un conjunto de credenciales) en un servidor sinautenticarse explícitamente en ese servidor.

v La señal se cifra utilizando una clave secreta compartida mediante DES triple,para que se pueda verificar su autenticidad.

v La información de la señal cifrada no se almacena en el navegador.v La señal sólo se pasa una vez. El servidor receptor utiliza esta información para

crear credenciales de usuario en su propia caché. El servidor utiliza estascredenciales para futuras peticiones del usuario durante la misma sesión.

v La señal tiene un valor de duración (tiempo de espera) que se establece en elarchivo de configuración webseald.conf. Este valor puede ser muy breve(segundos) para reducir el riesgo de un ataque de respuestas.

Cifrado de la señal de “garantización”WebSEAL debe cifrar los datos de autenticación ubicados en la señal mediante unaclave generada por el programa de utilidad cdsso_key_gen. Debe “sincronizar”esta clave compartiendo el archivo de claves con todos los servidores WebSEAL decada uno de los dominios participantes. Todos los servidores WebSEALparticipantes de cada dominio deben utilizar la misma clave.

Nota: La creación y distribución de archivos de claves no forma parte del procesode comunidad electrónica de Access Manager. Debe copiar manualmente yde forma segura las claves para cada servidor participante.

El programa de utilidad cdsso_key_gen precisa que se especifique la ubicación(nombre de ruta de acceso completa) del archivo de claves cuando se ejecute elprograma de utilidad:


UNIX:# cdsso_key_gen <nombre-ruta-acceso-absoluta>

Windows:MSDOS> cdsso_key_gen <nombre-ruta-acceso-absoluta>

La ubicación de la clave utilizada para asegurar las señales enviadas entre losservidores de un mismo dominio (local y remoto) se especifica como el valor delparámetro intra-domain-key en la stanza [e-community-sso] del archivo deconfiguración webseald.conf.[e-community-sso]intra-domain-key = <nombre-ruta-acceso-completa>

La ubicación de los archivos de claves utilizados para asegurar las señalesenviadas entre el MAS y los servidores de dominios remotos se especifica en lastanza [inter-domain-keys]. Los otros servidores del mismo dominio que MAS nonecesitan inter-domain-keys. El MAS es el único servidor que debe comunicarsecon los servidores en los dominios remotos.[inter-domain-keys]<nombre-dominio> = <nombre-ruta-acceso-completa><nombre-dominio> = <nombre-ruta-acceso-completa>

Configuración de una comunidad electrónicaEste apartado repasa todos los parámetros de configuración necesarios paraimplementar una comunidad electrónica. Estos parámetros se encuentran en elarchivo webseald.conf. Debe configurar atentamente este archivo para cada uno delos servidores participantes en la comunidad electrónica.

e-community-sso-auth

Este parámetro habilita o inhabilita la autenticación de la comunidad electró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 de comunicación queutilizan los participantes de la comunidad electrónica. El valor “none” inhabilita lacomunidad electrónica para ese servidor. El valor predeterminado es “none”.

master-http-port

Si e-community-sso-auth habilita la autenticación de la comunidad electrónicaHTTP, y el servidor maestro de autenticación escucha las peticiones HTTP en unpuerto distinto del puerto HTTP estándar (puerto 80), el parámetromaster-http-port permite identificar el puerto no estándar. Este parámetro se omitesi este servidor es el servidor maestro de autenticación. De forma predeterminada,este parámetro está inhabilitado.[e-community-sso]master-http-port = <número-puerto>

master-https-port

Si e-community-sso-auth habilita la autenticación de la comunidad electrónicaHTTPS, y el servidor maestro de autenticación escucha las peticiones HTTPS en unpuerto distinto del puerto HTTP estándar (puerto 443), el parámetro


master-http-port permite identificar el puerto no estándar. Este parámetro se omitesi este servidor es el servidor maestro de autenticación. De forma predeterminada,este parámetro está inhabilitado.[e-community-sso]master-https-port = <número-puerto>

e-community-name

Este parámetro identifica el número unificado de la comunidad electrónica paratodos los servidores participantes en todos los dominios participantes. Por ejemplo:[e-community-sso]e-community-name = companyABC

El valor de e-community-name debe ser el mismo para todos los servidoresWebSEAL en todos los dominios que participan en la comunidad electrónica.

intra-domain-key

Este parámetro identifica la ubicación del archivo de claves que se utiliza paracifrar y descifrar las señales que se intercambian en el dominio de este servidor.Por ejemplo:[e-community-sso]intra-domain-key = /abc/xyz/key.file

Debe generar este archivo de claves en una ubicación y copiarlo manualmente (deforma segura) en la ubicación especificada en los otros servidores WebSEAL dentrodel dominio.

is-master-authn-server

Este parámetro identifica si este servidor es el MAS o no. Los valores posibles son“yes” o “no”. Por ejemplo:[e-community-sso]is-master-authn-server = yes

Se pueden configurar varios WebSEAL para actuar como servidores maestros deautenticación y, a continuación, colocarlos detrás de un equilibrador de carga. Eneste caso, el equilibrador de carga es “reconocido” como el MAS por lo otrosservidores WebSEAL en la comunidad electrónica.

master-authn-server

Si el parámetro is-master-authn-server se establece en “no”, este parámetro debeestar especificado y sin comentarios. El parámetro identifica el nombre de dominiocompleto 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 se comprueba comparándolo con la horade creación indicada en la cookie. El valor predeterminado es 180 segundos. Debetener en cuenta las diferencias horarias entre los servidores participantes. Porejemplo:


[e-community-sso]vf-token-lifetime = 180

vf-url

Este parámetro especifica la dirección URL de “garantización”. El valor debeempezar con una barra inclinada (/). El valor predeterminado 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 la cookie dedominio de comunidad electrónica. El valor predeterminado es 300 minutos. Porejemplo:[e-community-sso]ec-cookie-lifetime = 300

Claves entre dominios

La ubicación de los archivos de claves necesarios para cifrar y descifrar las señalesentre el MAS y los servidores participantes se especifica en la stanza[inter-domain-keys]. Debe especificar los nombres de dominio completos de losservidores y las rutas de acceso completas de las ubicaciones de los archivos declaves.

El siguiente ejemplo proporciona al MAS (dominio A) los archivos de claves paracomunicarse 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 utilizado entre eldominio A y el dominio B. key.fileC identifica el archivo de claves utilizado entreel dominio A y el dominio C.

Cada servidor remoto necesitará una copia del archivo de claves correspondienteutilizado por el MAS. Para intercambiar señales con el MAS (dominio A), todos losservidores del dominio B necesitan copias de key.fileB.[inter-domain-keys]dA.com = /efg/hij/key.fileB

Para intercambiar señales con el MAS (dominio A), todos los servidores deldominio C necesitan copias de key.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 habilite el mecanismode autenticación de cdsso. Este mecanismo es necesario cuando el servidor querealiza la petición crea credenciales de usuario a partir de la información deidentidad contenida en la señal de “garantización”. El parámetro de configuración


cdsso especifica la biblioteca compartida codificada de forma que no se puedamodificar para correlacionar la información de autenticación.v En UNIX, el archivo que proporciona la función de correlación incorporada es

una biblioteca compartida denominada libcdssoauthn.v En Windows, el archivo que proporciona la función de correlación incorporada

es una DLL denominada cdssoauthn.




cdsso libcdssoauthn.so libcdssoauthn.a cdssoauthn.dll libcdssoauthn.sl

Puede configurar el mecanismo de autenticación de CDSSO especificando elparámetro cdsso con el nombre específico para la plataforma del archivo debiblioteca compartida en la stanza [authentication-mechanism] del archivo deconfiguración webseald.conf.

Por ejemplo:

Solaris:[authentication-mechanisms]cdsso = libcdssoauthn.so

Windows:[authentication-mechanisms]cdsso = cdssoauthn.dll


Capítulo 7. Conexiones (junctions) WebSEAL

La conexión entre un servidor WebSEAL y un servidor de aplicaciones web defondo se conoce como conexión (junction) WebSEAL o conexión (junction). Unaconexión (junction) WebSEAL es una conexión de TCP/IP entre un servidorWebSEAL frontal y un servidor 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 el programa de utilidad de líneade comandos pdadmin o con Web Portal Manager. Este capítulo describe losdetalles de las distintas opciones para configurar conexiones (junctions) WebSEAL.

Índice de temas:v “Visión general de las conexiones (junctions) WebSEAL” en la página 159v “Utilización de pdadmin para crear conexiones (junctions)” en la página 161v “Configuración de una conexión (junction) WebSEAL básica” en la página 162v “Conexiones (junctions) SSL autenticadas mutuamente” en la página 165v “Creación de conexiones (junctions) de proxy TCP y SSL” en la página 168v “Conexiones (junctions) de WebSEAL a WebSEAL a través de SSL” en la página

168v “Modificación de las direcciones URL de recursos de fondo” en la página 169v “Opciones adicionales de conexión (junction)” en la página 176v “Notas técnicas para utilizar conexiones (junctions) WebSEAL” en la página 185v “Utilización de query_contents con servidores de terceros” en la página 186

Visión general de las conexiones (junctions) WebSEALPuede crear los siguientes tipos de conexión (junction) WebSEAL:v De WebSEAL a servidor de fondo a través de una conexión TCPv De WebSEAL a servidor de fondo a través de una conexión SSLv De WebSEAL a servidor de fondo a través de una conexión TCP mediante el

servidor proxy HTTPv De WebSEAL a servidor de fondo a través de una conexión SSL mediante el

servidor proxy HTTPSv 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 web en el espacio

de objetos de WebSEAL.2. Elegir el tipo de conexión (junction).

Ubicación y formato de la base de datos de conexiones(junctions)

La información de las conexiones (junctions) WebSEAL se almacena ahora en losarchivos de la base de datos en formato XML. La ubicación del directorio de labase de datos de conexiones (junctions) está definida en la stanza [junction] del


archivo de configuración webseald.conf. El directorio es relativo a la raíz delservidor WebSEAL (parámetro server-root de la stanza [server]):[junction]junction-db = jct

v Cada conexión (junction) está definida en un archivo aparte con una extensión.xml.

v Utilice el programa de utilidad pdadmin para crear y gestionar las conexiones(junctions) y las opciones.

v El formato XML permite crear, editar, duplicar y hacer copia de seguridadmanualmente de los archivos de conexión (junction).

Aplicación del control de accesos flexible: resumen1. Utilice el programa de utilidad pdadmin 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 de fondo.

Aplicación del control de accesos flexible: resumen1. Utilice el programa de utilidad pdadmin 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 un sistema dearchivos de terceros. Debe informar a WebSEAL del espacio de objetos deterceros mediante una aplicación especial denominada query_contents, quehace un inventario del espacio web de terceros e informa a WebSEAL acerca dela estructura y el contenido.

2. Copie el programa query_contents en el servidor de terceros.3. Aplique la política de ACL a los objetos apropiados del espacio de objetos

unificado.

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

Las directrices siguientes resumen las “reglas” para las conexiones (junctions):v Puede agregar una conexión (junction) en cualquier punto del espacio de objetos

de WebSEAL principalv Puede conectar varios servidores de fondo replicados al mismo punto de

montajeLos diversos servidores de fondo replicados montados en el mismo punto deconexión (junction) deben ser del mismo tipo— TCP o SSL

v Las políticas de ACL se heredan a través de las conexiones (junctions) en losservidores de terceros

v El nombre del punto de conexión (junction) debe ser exclusivo y no debecoincidir con ningún directorio del espacio web del servidor WebSEAL local. Porejemplo, si WebSEAL tiene recursos con el formato /ruta_acceso/..., no cree unpunto de conexión (junction) con el nombre /ruta_acceso.

v El punto de conexión (junction) no debe coincidir con ningún directorio delespacio web del servidor de fondo si las páginas HTML del servidor contienenprogramas (por ejemplo, Javascript o applets) con direcciones URL de esedirectorio relativas al servidor. Por ejemplo, si las páginas del servidor de fondocontienen programas con una dirección URL con el formato /ruta_acceso/...,no cree un punto de conexión (junction) con el nombre /ruta_acceso.


v No cree varias conexiones (junctions) WebSEAL que apunten al mismoservidor/puerto de aplicación de fondo. Este tipo de configuración puede causarun control imprevisible de acceso a los recursos y, por consiguiente, no es unaestrategia de configuración de Access Manager recomendada o soportada.Cada conexión (junction) WebSEAL puede protegerse mediante un conjuntoexclusivo de controles de accesos (ACL). No obstante, la política de ACL de cadaconexión (junction) recién creada se solapa sobre las políticas de las conexiones(junctions) creadas previamente y conectadas al mismo servidor defondo/puerto. Las conexiones (junctions) posteriores protegidas con unas ACLmás permisivas pueden comprometer conexiones (junctions) anteriores con unasACL menos permisivas. WebSEAL y el modelo de autorización de AccessManager no pueden garantizar un control de acceso seguro con este tipo deimplementación de conexión (junction).

v WebSEAL da soporte a HTTP 1.1 a través de conexiones (junctions).

Información de consulta adicional para conexiones (junctions)WebSEAL

Consulte el apartado “Información sobre las conexiones (junctions) WebSEAL” enla página 14 para obtener una visión general conceptual de las conexiones(junctions) WebSEAL.

Consulte el apartado Apéndice B, “Información de consulta de las conexiones(junctions) WebSEAL” en la página 247 para obtener información completa acercade las opciones de comandos de conexión (junction).

Utilización de pdadmin para crear conexiones (junctions)Antes de utilizar pdadmin, debe iniciar la sesión en un dominio seguro comousuario de administración sec_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>

Para crear conexiones (junctions) WebSEAL, utilice el comando pdadmin servertask create:pdadmin> server task <identificación-servidor> create <opciones>

El componente identificación-servidor de este comando es una combinación delservidor de Access Manager utilizado por este comando y el nombre de host delservidor de Access Manager.<servidor-Access-Manager>-<nombre-host>

Capítulo 7. Conexiones (junctions) WebSEAL 161

Sintaxis para un solo servidor WebSEAL:

Para Access Manager WebSEAL, el servidor-Access-Manager es webseald y elnombre-host es el nombre de la máquina servidor WebSEAL:pdadmin> server task webseald-<nombre-host> create <opciones>

El servidor WebSEAL inicial instalado en una máquina siempre se denomina segúnel nombre de máquina. Por ejemplo, si el nombre de la máquina es cruz, laidentificación de servidor para una sola instalación de WebSEAL es:webseald-cruz

Sintaxis para múltiples instancias de WebSEAL:

Si instala múltiples instancias de servidor WebSEAL en la misma máquina, elservidor-Access-Manager es el nombre configurado de la instancia de servidorWebSEAL, seguido de webseald y del nombre de host:<nombre-instancia>-webseald-<nombre-host>

Por ejemplo, si los nombres configurados de dos instancias adicionales deWebSEAL son webseal2 y webseal3, las identificaciones de servidor aparecencomo:webseal2-webseald-cruzwebseal3-webseald-cruz

Utilice el comando server list para verificar la identificación de servidor:pdadmin> server listwebseald-cruzwebseal2-webseald-cruzwebseal3-webseald-cruz

Configuración de una conexión (junction) WebSEAL básicaWebSEAL da soporte a las conexiones (junctions) TCP estándar (HTTP) y SSLseguras (HTTPS) entre WebSEAL y los servidores de aplicaciones web.

La conexión (junction) entre WebSEAL y el servidor de fondo es independiente deltipo de conexión (y su nivel de seguridad) entre el cliente y el servidor WebSEAL.

Las opciones de comando obligatorias que son necesarias para crear una conexión(junction) WebSEAL básica mediante pdadmin son:v Nombre de host del servidor de aplicaciones de fondo (opción –h)v Tipo de conexión (junction): tcp, ssl, tcpproxy, sslproxy, local (opción –t)v Punto de conexión (junction) (punto de montaje)pdadmin> server taskwebseald-<nombre-instancia> create–t <tipo> –h \<nombre-host> <punto-conexión>

Por ejemplo:pdadmin> server task webseald-cruz create -t tcp -h doc.tivoli.com /pubs

Nota: La recomendación de “mejor práctica” es que se utilice siempre el nombrede dominio completo del servidor de fondo al especificar el argumento en laopción –h.


Creación de conexiones (junctions) de tipo TCPUna conexión (junction) WebSEAL a través de una conexión TCP proporciona laspropiedades básicas de una conexión (junction) pero no proporcionan unacomunicación segura a través de ésta.

Para crear una conexión (junction) TCP segura y agregar un servidor inicial, utiliceel comando create con la opción –t tcp:pdadmin> server task webseald-<nombre-instancia> 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 haespecificado) es 80.

Creación de conexiones (junctions) de tipo SSLLas conexiones (junctions) SSL funcionan exactamente igual que las conexiones(junctions) TCP, con el valor añadido de que todas las comunicaciones entreWebSEAL y el servidor de fondo están cifradas.

Las conexiones (junctions) SSL permiten transacciones seguras de extremo aextremo de navegador a aplicación. Puede utilizar SSL para proteger lascomunicaciones del cliente a WebSEAL y de WebSEAL al servidor de fondo. Elservidor de fondo debe tener HTTPS habilitado al utilizar una conexión (junction)SSL.

Para crear una conexión (junction) SSL segura y agregar un servidor inicial, utiliceel comando create con la opción –t ssl:pdadmin> server task webseald-<nombre-instancia> create –t ssl –h <nombre-host> \[–p <puerto>] <punto-conexión>

Figura 29. Conexión (junction) TCP no segura (HTTP)

Figura 30. Conexión (junction) SSL segura (HTTPS)


El valor de puerto predeterminado para una conexión (junction) SSL (si no se haespecificado) es 443.

Verificación del certificado de servidor de fondoCuando un cliente realiza una petición para un recurso del servidor de fondo,WebSEAL, en su rol como servidor de seguridad, realiza la petición en nombre delcliente. El protocolo SSL especifica que cuando se realiza una petición al servidorde fondo, ese servidor debe proporcionar una prueba de identidad mediante uncertificado de servidor.

Cuando WebSEAL recibe este certificado del servidor de fondo, debe verificar suautenticidad comparándolo con una lista de certificados raíz de CA almacenadosen su base de datos de certificados.

Access Manager utiliza la implementación de SSL de IBM Global Security Kit(GSKit). Debe utilizar el programa de utilidad iKeyman de GSKit para agregar elcertificado raíz de la CA que ha firmado el certificado del servidor de fondo en elarchivo de claves de certificados de WebSEAL (pdsvr.kdb).

Ejemplos de conexiones (junctions) de SSLHost de conexión (junction) sales.tivoli.com en el punto de conexión (junction)/sales a través de SSL:pdadmin> server taskwebseald-<nombre-instancia> create –t ssl –h \sales.tivoli.com /sales

Nota: En el ejemplo anterior, la opción –t ssl establece el puerto predeterminado443.

Host de conexión (junction) travel_svr en el puerto 4443 en el punto de conexión(junction) /travel a través de SSL:pdadmin> server task webseald-<nombre-instancia> create –t ssl –p 4443 \–h travel_svr /travel

Adición de servidores de fondo adicionales a una conexión(junction)

Para aumentar la alta disponibilidad de los recursos protegidos por AccessManager, puede establecer una conexión (junction) de varios servidores de fondoreplicados al mismo punto de conexión (junction).v Varios servidores de fondo con la misma conexión (junction) en el mismo punto

deben tener versiones de WebSEAL idénticas y espacios de documentos webidénticos.

v Varios servidores de fondo con la misma conexión (junction) en el mismo puntodeben usar el mismo tipo de conexión (TCP o SSL).

v WebSEAL utiliza un algoritmo de menos ocupado para determinar cuál es laréplica de servidor de fondo que tiene un número menor de conexiones depetición y reenvía las peticiones nuevas a ese servidor.

Cree la conexión (junction) inicial. Por ejemplo:pdadmin> server task webseald-cruz create -t tcp -h server1 /sales

Agregue una réplica de servidor de fondo adicional. Por ejemplo:pdadmin> server task webseald-cruz add -h server2 /sales


Conexiones (junctions) SSL autenticadas mutuamenteWebSEAL da soporte a la autenticación mutua entre un servidor WebSEAL y unservidor de fondo a través de una conexión (junction) SSL (–t ssl o –t sslproxy). Elsiguiente esquema resume las funciones soportadas para la autenticación mutua através de SSL (se incluyen las opciones de comando en la lista donde espertinente):1. WebSEAL autentica el servidor de fondo (proceso SSL normal)v WebSEAL valida el certificado de servidor del servidor de fondo. Consulte el

apartado “WebSEAL valida el certificado de servidor de fondo”.v WebSEAL verifica el Nombre distinguido (DN) contenido en el certificado

(–D) (opcional, pero muy recomendable). Consulte el apartado “Coincidenciade Nombre distinguido (DN)”.

2. El servidor de fondo autentica WebSEAL (dos métodos)v El servidor de fondo valida el certificado de cliente de WebSEAL (–K).

Consulte el apartado “WebSEAL se autentica con un certificado de cliente” enla página 166.

v El servidor de fondo valida la información de identidad de WebSEAL en lacabecera de autenticación básica (BA) (–B, –U, –W). Consulte el apartado“WebSEAL se autentica con una cabecera de BA” en la página 166.

Las opciones de comando que controlan la autenticación mutua a través de SSLproporcionan las siguientes funciones:v Puede especificar el certificado de cliente o el método de autenticación BA.v Puede aplicar el método de autenticación según la conexión (junction).

En el apartado “Gestión de información de identidad de cliente entre conexiones(junctions)” en la página 167 encontrará consideraciones especiales para combinarlas opciones –b (para gestionar la información de BA) con la autenticación mutua através de SSL.

WebSEAL valida el certificado de servidor de fondoWebSEAL verifica un certificado de servidor de fondo según el protocolo SSLestándar. El servidor de fondo envía su certificado de servidor a WebSEAL.WebSEAL valida el certificado de servidor comparándolo con una lista predefinidade certificados raíz de CA (entidad emisora de certificados).

Los certificados de CA (entidad emisora de certificados) que forman la cadenafiable para el certificado de servidor de aplicaciones (de la CA firmante alcertificado raíz, éste incluido) deben estar incluidos en la base de datos de clavesque utiliza WebSEAL.

Utilice el programa de utilidad iKeyman para crear y gestionar la base de datos decertificados raíz de CA.

Coincidencia de Nombre distinguido (DN)Puede mejorar la verificación de certificados de servidor a través de la coincidenciadel Nombre distinguido (DN). Para habilitar la coincidencia de DN del servidor,debe especificar el DN del servidor de fondo al crear la conexión (junction) SSLcon ese servidor. Aunque la coincidencia de DN es una configuración opcional, esmuy recomendable que se implemente esta función con la autenticación mutua através de las conexiones (junctions) SSL.


Durante la verificación de certificados de servidor, el DN contenido en elcertificado se compara con el DN definido por la conexión (junction). La conexióncon el servidor de fondo falla si los dos DN no coinciden.

Para habilitar la coincidencia de DN del servidor, especifique el DN del servidorde fondo cuando cree la conexión (junction) SSL mediante la opción –D “<DN>”.Para preservar los espacios en blanco de la cadena, especifique la cadena de DNentre comillas. Por ejemplo:–D “/C=US/O=Tivoli/OU=SecureWay/CN=Access Manager”

La opción –D sólo es apropiada cuando se utiliza con la opción –K o –B.

WebSEAL se autentica con un certificado de clienteUtilice la opción –K para habilitar la autenticación de WebSEAL con el servidor defondo con conexión (junction) a través del certificado de cliente.–K “<etiqueta-clave>”

Las condiciones para este escenario son:v El servidor de fondo está configurado para que requiera la verificación de la

identidad de WebSEAL con un certificado de cliente.v WebSEAL está configurado (webseald.conf) para que utilice un certificado de

cliente específico para autenticarse en el servidor de fondo (ssl-keyfile-label).v Es muy recomendable que configure la conexión (junction) para la coincidencia

de DN (–D).

La opción –K utiliza un argumento que especifica la etiqueta de clave delcertificado requerido tal como está almacenada en la base de datos de claves deGSKit. Utilice el programa de utilidad iKeyman para agregar certificados nuevos ala base de datos de claves. Utilice el parámetro ssl-keyfile-label del archivo deconfiguración webseald.conf para configurar la etiqueta de clave.

Debe especificar el argumento de etiqueta de clave entre comillas. Por ejemplo:–K “cert1_Tiv”

Consulte el apartado “Configuración de parámetros de base de datos de claves” enla página 40.

WebSEAL se autentica con una cabecera de BAUtilice la opción –B –U “<nombre-usuario>” –W “<contraseña>” para habilitar laautenticación de WebSEAL mediante la autenticación básica.–B –U “<nombre-usuario>” –W “<contraseña>”

Las condiciones para este escenario son:v El servidor de fondo está configurado para que requiera la verificación de la

identidad de WebSEAL con una cabecera de BA.v No configure la conexión (junction) con ninguna opción –b. (Sin embargo,

internamente la opción –B utiliza –b filter.)v WebSEAL está configurado para pasar la información de identidad en una

cabecera de BA para autenticarse en el servidor de fondo.v Es muy recomendable que configure también la conexión (junction) para la

coincidencia de DN (–D).


Debe especificar los argumentos de nombre de usuario y contraseña entre comillas.Por ejemplo:–U “WS1” –W “abCde”

Gestión de información de identidad de cliente entreconexiones (junctions)

Se puede configurar una conexión (junction) para especificar la información deidentidad del cliente en cabeceras de BA. La opción –b permite cuatro argumentosposibles: filter, supply, ignore, gso. Encontrará información detallada acerca deestos argumentos en el apartado “Configuración de cabeceras de BA para lassoluciones de inicio de sesión único” en la página 191.

La opción –b tiene un impacto sobre los valores de la conexión (junction) para laautenticación mutua y debe tener en cuenta la combinación correcta de lasopciones.

Utilización de –b supplyv La autenticación de WebSEAL mediante la cabecera de BA no se permite con

esta opción. Esta opción utiliza la cabecera de BA para el nombre de usuario yuna contraseña “simulada” del cliente original.

v La autenticación de WebSEAL mediante el certificado de cliente se permite conesta opción.

Utilización de –b ignorev La autenticación de WebSEAL mediante la cabecera de BA no se permite con

esta opción. Esta opción utiliza la cabecera de BA para el nombre de usuario yuna contraseña del cliente original.


Utilización de –b gsov La autenticación de WebSEAL mediante la cabecera de BA no se permite con

esta opción. Esta opción utiliza la cabecera de BA para la información de nombrede usuario y contraseña proporcionada por el servidor GSO.


Utilización de –b filterv Internamente, la opción –b filter se utiliza cuando se establece la autenticación

de WebSEAL para utilizar la información de cabecera de BA.La cabecera de BA de WebSEAL se utiliza para todas las transacciones HTTPsubsiguientes. En el servidor de fondo, WebSEAL aparece conectado en todomomento.


v Si el servidor de fondo requiere una identidad de cliente real (del navegador), sepueden utilizar las variables de CGI HTTP_IV_USER, HTTP_IV_GROUP yHTTP_IV_CREDS. Para los scripts y servlets, utilice las cabeceras HTTPespecíficas de Access Manager correspondientes: iv-user, iv-groups e iv-creds.


Creación de conexiones (junctions) de proxy TCP y SSLPuede crear conexiones (junctions) WebSEAL que permitan la comunicación parapasar por topologías de red que utilizan servidores proxy HTTP o HTTPS. Puedeconfigurar la conexión (junction) para gestionar peticiones como comunicación TCPestándar o comunicación SSL protegida.

El comando create requiere uno de los siguientes argumentos para la opción typepara establecer una conexión (junction) basada en TCP o en SSL a través de unservidor proxy:v –t tcpproxy

v –t sslproxy

Los comandos create y add requieren que las siguientes opciones y argumentosidentifiquen el servidor proxy y el servidor web de destino:

–H <nombre-host> Nombre de host DNS o dirección IP del servidor proxy.

–P <puerto> Puerto TCP del servidor proxy.

–h <nombre-host> Nombre de host DNS o dirección IP del servidor web dedestino.

–p <puerto> Puerto TCP del servidor web de destino. El valorpredeterminado es 80 para conexiones (junctions) TCP; 443para conexiones (junctions) SSL.

Ejemplo de conexión (junction) de proxy TCP (especificado en una línea):pdadmin> server task webseald-<nombre-instancia> create –t tcpproxy \–H clipper –P 8081 –h www.ibm.com –p 80 /ibm

Ejemplo de conexión (junction) de proxy SSL (especificado en una línea):pdadmin> server task webseald-<nombre-instancia> create –t sslproxy \–H clipper –P 8081 –h www.ibm.com –p 443 /ibm

Conexiones (junctions) de WebSEAL a WebSEAL a través de SSLAccess Manager da soporte a conexiones (junctions) SSL entre un servidorWebSEAL frontal y un servidor WebSEAL de fondo. Utilice la opción –C con elcomando create para conectar los dos servidores WebSEAL a través de SSL yproporcionar autenticación mutua.

Ejemplo:pdadmin> server task webseald-<nombre-instancia> create –t ssl –C –h serverA /jctA

Figura 31. Ejemplo de conexión (junction) de proxy


La autenticación mutua se produce en las dos etapas siguientes:v El protocolo SSL permite al servidor WebSEAL de fondo autenticarse en el

servidor WebSEAL frontal a través de su certificado de servidor.v La opción –C habilita el servidor WebSEAL frontal para pasar la información de

identidad al servidor WebSEAL de fondo en una cabecera de autenticaciónbásica (BA).

Además, la opción –C habilita las funciones de la opción –c que le permite colocarla identidad de cliente específica de Access Manager y la información depertenencia a grupos en la cabecera HTTP de la petición destinada al servidorWebSEAL de fondo. Los parámetros de 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 WebSEALa WebSEAL:v La conexión (junction) sólo es apropiada con el tipo de conexión –t ssl o –t

sslproxy.v Ambos servidores WebSEAL deben compartir un registro LDAP o DCE común.

Esto permite al servidor WebSEAL de fondo autenticar la información deidentidad de servidor WebSEAL frontal.

Modificación de las direcciones URL de recursos de fondoLas páginas devueltas al cliente desde aplicaciones de fondo suelen contenervínculos de direcciones URL a recursos que están ubicados en esos servidores deaplicaciones. Es importante que estos vínculos estén construidos de manera quedirijan las peticiones de vuelta a las ubicaciones correctas de esos recursos.

Por ejemplo (en un entorno que no sea WebSEAL), la dirección URL entrada porun cliente para un recurso en un servidor de aplicaciones puede tener el siguienteaspecto:http://www.abc.com/archivo.html

WebSEAL, como proxy inverso frontal, proporciona servicios de seguridad aservidores de aplicaciones de fondo a través de la característica de conexión(junction) WebSEAL. Esta característica produce como resultado que se acceda a losrecursos a través de distintas expresiones de dirección URL.

Por ejemplo (en un entorno WebSEAL), la dirección URL entrada por un clientepara el mismo recurso en un servidor de aplicaciones de fondo con conexión(junction) debe tener el siguiente aspecto:http://webseal.abc.com/jct/archivo.html

La característica de conexión (junction) de WebSEAL cambia la información deservidor y ruta de acceso que debe utilizarse para acceder a los recursos en lossistemas de fondo con conexión (junction). Un vínculo a un recurso en un servidorde fondo con conexión (junction) sólo es válido si la dirección URL contiene laidentidad de la conexión (junction).

Para dar soporte a la característica de conexión (junction) y mantener la integridadde las direcciones URL, siempre que sea posible, WebSEAL debe realizar losiguiente:


1. Modificar las direcciones URL (vínculos) que se han encontrado en lasrespuestas enviadas a los clientes

2. Modificar las peticiones de recursos como resultado de las direcciones URL(vínculos) que WebSEAL no ha podido cambiar

Tenga en cuenta que las reglas y los mecanismos de WebSEAL para filtrar yprocesar las direcciones URL no se aplican a los vínculos que apuntan a recursosexternos al entorno con conexión (junction) de Access Manager.

El siguiente diagrama resume las soluciones disponibles en WebSEAL paramodificar las direcciones URL de los recursos de fondo con conexión (junction):

Este apartado contiene los temas siguientes:v “Información sobre los tipos de ruta de acceso utilizados en las direcciones

URL” en la página 170v “Filtrado de las direcciones URL en las respuestas” en la página 171v “Proceso de direcciones URL en las peticiones” en la página 173

Información sobre los tipos de ruta de acceso utilizados enlas direcciones URL

Es probable que cualquier página HTML contenga direcciones URL (vínculos) aotros recursos en ese servidor de fondo o a otro sitio. Pueden aparecer expresionesde dirección URL en los siguientes formatos:v relativov relativo al servidorv absoluto

Las direcciones URL expresadas en formato relativo no requieren nunca ningúntipo de manipulación por parte de WebSEAL. De forma predeterminada, elnavegador gestiona las direcciones URL relativas agregando como prefijo lainformación correcta sobre el esquema, el servidor y el directorio (incluida laconexión (junction)) a la dirección URL relativa. La información agregada comoprefijo procede de la página existente en la que reside el vínculo.

Ejemplo de expresiones de dirección URL relativas:abc.html ../abc.html./abc.html sales/abc.html

Figura 32. Resumen: modificación de las direcciones URL de recursos de fondo


No obstante, surgen dificultades con los formatos de ruta de acceso relativos alservidor y absolutos. Los vínculos a recursos de fondo expresados en formatosabsolutos o relativos al servidor sólo son válidos si WebSEAL pudo modificar laexpresión de ruta de acceso de dirección URL e incluyen información sobre laconexión (junction).

Ejemplo de expresiones de dirección URL relativas al servidor:/abc.html /accounts/abc.html

Ejemplo de expresión de dirección URL absoluta:http://www.tivoli.com/abc.html

Nota: Es recomendable que todos los programadores de scripts de web utilicenvínculos relativos (ni absolutos ni relativos al servidor) para las direccionesURL generadas dinámicamente.

Filtrado de las direcciones URL en las respuestasEn este apartado se describe cómo WebSEAL filtra las direcciones URL en lasrespuestas de los servidores de aplicaciones de fondo con conexión (junction).v “Reglas de filtrado estándar de direcciones URL para WebSEAL” en la página

171v “Modificación de las direcciones URL absolutas con filtrado de scripts” en la

página 172v “El filtrado cambia la cabecera Content-Length” en la página 173

Reglas de filtrado estándar de direcciones URL para WebSEALWebSEAL utiliza un conjunto de reglas estándar para filtrar las direcciones URLcontenidas en las páginas que son respuestas a las peticiones de los clientes. Paraaplicar un filtrado estándar de direcciones URL, WebSEAL debe poder “ver” lasdirecciones URL en una página enviada desde el servidor de fondo. WebSEAL nopuede utilizar reglas estándar de filtrado para las direcciones URL incorporadas enscripts.

De forma predeterminada, WebSEAL sólo filtra los documentos de tipo MIME“text/html” y “text/vnd.wap.wml” que se reciben de servidores con conexión(junction). Se pueden configurar tipos MIME adicionales utilizando la stanza[filter-content-types] del archivo de configuración webseald.conf.

El navegador siempre gestiona adecuadamente las direcciones URL relativas. Noobstante, WebSEAL debe agregar el nombre de conexión (junction) a la ruta deacceso de las direcciones URL absolutas o relativas al servidor que hacen referenciaa recursos ubicados en los servidores con conexión (junction).v Las direcciones URL relativas al servidor indican una posición de dirección

URL en relación con la raíz de documentos del servidor con conexión (junction),como por ejemplo:/dir/archivo.html

Estas direcciones URL se modifican para reflejar el punto de conexión (junction)del servidor con conexión (junction), como por ejemplo:/jct/dir/archivo.html

v Las direcciones URL absolutas indican una posición de dirección URL enrelación con un nombre de host o una dirección IP y un puerto de red, porejemplo:


http://<nombre-host>[:<puerto>]/archivo.html,ohttps://<nombre-host>[:<puerto>]/archivo.html

Estas direcciones URL se modifican según el siguiente conjunto de reglas:1. Si la dirección URL es HTTP y el host/puerto coincide con un servidor con

conexión (junction) TCP, la dirección URL se modifica para que sea relativa alservidor para WebSEAL y refleje el punto de conexión (junction). Por ejemplo:http://<nombre-host>[:<puerto>]/archivo.html

se convierte en:/tcpjct/archivo.html

2. Si la dirección URL es HTTPS y el host/puerto coincide con un servidor conconexión (junction) SSL, la dirección URL se modifica para que sea relativa alservidor para WebSEAL y refleje el punto de conexión (junction). Por ejemplo:https://<nombre-host>[:<puerto>]/archivo.html

se convierte en:/ssljct/archivo.html

3. Sólo se filtran las direcciones URL de tipos de contenido definidos en la stanza[filter-content-types] del archivo de configuración webseald.conf.

4. Los indicadores META se filtran siempre para peticiones de actualización, porejemplo:<META HTTP-EQUIV=”Refresh” CONTENT=”5;URL=http://server/url”>

5. Si un indicador BASE contiene un atributo HREF, el indicador se eliminará dela respuesta al cliente.

Los parámetros para filtrar direcciones URL a través de servidores con conexión(junction) se encuentran en la stanza [filter-url] del archivo de configuraciónwebseald.conf. La stanza [filter-url] contiene una lista de indicadores HTML queel servidor WebSEAL filtra o modifica para ajustar las direcciones URL absolutasque se han obtenido a través de un servidor con conexión (junction).

Todos los indicadores HTML utilizados habitualmente se configuran de formapredeterminada. Es posible que el administrador necesite agregar indicadoresHTML adicionales que contengan las direcciones URL.

Modificación de las direcciones URL absolutas con filtrado descriptsWebSEAL requiere una configuración adicional para gestionar el proceso de lasdirecciones URL absolutas incorporadas en scripts. Los lenguajes de script de webson Javascripts, VBscripts, ASP, JSP, ActiveX y otros. El archivo de configuraciónwebseald.conf contiene un parámetro que habilita o inhabilita el filtrado de lasdirecciones URL absolutas incorporadas:[script-filtering]script-filter = no

El filtro de scripts está inhabilitado de manera predeterminada. Para habilitarlo,establezca:script-filter = yes

Nota: También debe utilizar la opción –j para crear la conexión (junction) con elservidor de fondo.


El mecanismo script-filter espera direcciones URL absolutas con un esquema,servidor y formato de recurso estándar:http://server/resource

El mecanismo script-filter sustituye las partes de esquema y servidor del vínculopor la información de conexión (junction) correcta./nombre-conexión/recurso

Esta solución analiza el script incorporado en el código HTML y, por consiguiente,requiere una actividad general de proceso adicional que puede tener una influencianegativa en el rendimiento. Limite el uso del parámetro script-filter únicamente alas conexiones (junctions) que requieran soporte para el filtrado de direccionesURL absolutas incorporadas.

El diagrama siguiente muestra esta solución de filtro de dirección URL:

El filtrado cambia la cabecera Content-LengthNormalmente, la cabecera Content-Length de una respuesta de un servidor defondo indica el tamaño del contenido que se devuelve. Cuando WebSEAL filtradirecciones URL y agrega información sobre la conexión (junction) a la ruta deacceso de las direcciones URL que contiene la página, el tamaño real de la páginase hace mayor que el indicado en Content-Header.

WebSEAL no puede saber cuál es la nueva longitud del contenido hasta queescriba la secuencia de datos en el cliente. En ese momento ya será demasiadotarde para insertar una nueva cabecera Content-Length. WebSEAL responde a estasituación de la manera siguiente:1. WebSEAL coloca el valor de la cabecera Content-Length original en una nueva

cabecera denominada X-Old-Content-Length.Cualquier applet o aplicación escrita para buscar esta cabecera puede teneracceso al valor original (previo al filtro) de Content-Length.

2. WebSEAL registra el valor modificado (posterior al filtro) de Content-Length enel archivo request.log.

3. Ya no aparecerá la cabecera Content-Length.

Proceso de direcciones URL en las peticionesHay dificultades cuando las direcciones URL se generan dinámicamente poraplicaciones del cliente (applets) o se incorporan en scripts dentro del códigoHTML. Los lenguajes de script de web son Javascripts, VBscripts, ASP, JSP, ActiveXy otros. Estas applets y scripts se ejecutan en cuanto ha llegado la página al

Figura 33. Filtrado de direcciones URL absolutas


navegador del cliente. WebSEAL no tiene nunca la oportunidad de aplicar susreglas de filtrado estándar a estas direcciones URL generadas dinámicamente.

En este apartado se describe cómo WebSEAL procesa los vínculos del clienterelativos al servidor generados dinámicamente que se han encontrado en laspeticiones de recursos en los servidores de fondo con conexión (junction).v “Gestión de direcciones URL relativas al servidor con cookies de conexión

(junction) (-j)” en la página 174v “Gestión de direcciones URL relativas al servidor con correlación de conexiones

(junctions)” en la página 175

Nota: No hay soluciones disponibles para gestionar las direcciones URL absolutasgeneradas en el cliente.

Gestión de direcciones URL relativas al servidor con cookies deconexión (junction) (-j)Las direcciones URL relativas al servidor que las applets y los scripts han generadoen el cliente carecen inicialmente de conocimiento del punto de conexión(junction). WebSEAL no puede filtrar la dirección URL porque se genera en elcliente. Durante una petición de un recurso por el cliente utilizando esta direcciónURL, WebSEAL puede intentar reprocesar la dirección URL relativa al servidorutilizando cookies de conexión (junction).

En el siguiente escenario, un script ubicado en la página solicitada generadinámicamente una expresión de dirección URL relativa al servidor al llegar alnavegador. Si el cliente solicita el recurso especificado por este vínculo, WebSEALrecibe una petición de una página local. Cuando no encuentre la página, devolveráel error “No encontrado” al cliente.

La opción –j proporciona una solución basa en cookies para gestionar direccionesURL relativa al servidor que se generan dinámicamente mediante un script que seejecuta en la máquina del cliente.

Sintaxis general:pdadmin> server task <nombre-servidor> create ... –j ...

Para cada página solicitada, se envía al cliente una cookie de ”conexión-identificador”. La cookie contiene la siguiente variable y valor:IV_JCT_<nombre-servidor-fondo> = </nombre-conexión>

Cuando el cliente efectúa una petición desde esta página utilizando una direcciónURL relativa al servidor generada dinámicamente, WebSEAL (como antes) recibeuna petición de un recurso local. Al no encontrar el recurso, WebSEAL vuelve aintentar inmediatamente la petición mediante la información de conexión (junction)proporcionada por la cookie. Con la información de conexión (junction) correcta enla expresión de dirección URL, el recurso se localiza correctamente.

El diagrama siguiente muestra esta solución para filtrar direcciones URL relativasal servidor:


WebSEAL proporciona una solución alternativa no basada en cookies paragestionar las direcciones URL relativas al servidor generadas dinámicamente.Consulte el apartado “Gestión de direcciones URL relativas al servidor concorrelación de conexiones (junctions)” en la página 175.

Gestión de direcciones URL relativas al servidor con correlaciónde conexiones (junctions)Las direcciones URL relativas al servidor que las applets y los scripts han generadoen el cliente carecen inicialmente de conocimiento del punto de conexión(junction). WebSEAL no puede filtrar la dirección URL porque se genera en elcliente. Durante una petición de un recurso por el cliente utilizando esta direcciónURL, WebSEAL puede intentar reprocesar la dirección URL relativa al servidorutilizando la correlación de conexiones (junctions).

Access Manager proporciona una alternativa a la solución basada en cookies parafiltrar direcciones URL relativas al servidor generadas dinámicamente. Puede creary activar una tabla de correlaciones de conexiones (junctions) que asigne recursosde destino específicos a los nombres de conexión (junction).

WebSEAL comprueba la información de ubicación en la dirección URL relativa alservidor con los datos contenidos en la tabla de correlaciones de conexiones(junctions). Si la información de ruta de acceso de la dirección URL coincide conuna entrada de la tabla, WebSEAL dirige la petición a la conexión (junction)asociada con esa ubicación.

La tabla es un archivo de texto ASCII denominado jmt.conf. La ubicación de estearchivo se especifica en la stanza [junction] del archivo de configuraciónwebseald.conf:jmt-map = lib/jmt.conf

El formato para la entrada de datos en la tabla consta del nombre de conexión, unespacio y el patrón de ubicación del recurso. También se pueden utilizar caracterescomodín para expresar el patrón de ubicación del recurso.

En el ejemplo siguiente del archivo de configuración de correlaciones de conexión,dos servidores de fondo están conectados a 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

Figura 34. Proceso de direcciones URL relativas al servidor


La tabla de correlaciones jmt.conf original es un archivo vacío. Cuando hayaagregado datos en el archivo, deberá utilizar el comando jmt load para “cargar”los datos y que WebSEAL conozca la 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 de correlaciones deconexiones (junctions):v Esta solución no requiere la opción – -j ni la cookie de conexión (junction).v La tabla de correlaciones requiere la configuración y activación por parte de un

administrador de seguridad.v Esta solución no gestiona los vínculos creados con direcciones URL absolutas.v La coincidencia del patrón de ubicación del recurso debe ser exclusiva en el

espacio web local y los servidores de aplicaciones web con conexión (junction).v Si hay una entrada de patrón duplicada en el archivo, la tabla de correlaciones

no se cargará. Sin embargo WebSEAL seguirá ejecutándose.v Si se produce algún error al cargar la tabla de correlaciones, ésta no estará

disponible. Sin embargo WebSEAL seguirá ejecutándose.v Si la tabla de correlaciones está vacía o hay algún error en las entradas de la

tabla, ésta no se cargará. Sin embargo WebSEAL seguirá ejecutándose.v Cualquier error que se produzca al cargar la tabla de correlaciones producirá

entradas de servicio en el archivo de registro del servidor WebSEAL(webseald.log).

Opciones adicionales de conexión (junction)Puede proporcionar las siguientes funciones de conexión (junction) WebSEAL conopciones adicionales:v “Cómo forzar una nueva conexión (junction) (–f)” en la página 176v “Especificación de la identidad del cliente en cabeceras HTTP (–c)” en la página

177v “Especificación de las direcciones IP de cliente en cabeceras HTTP (–r)” en la

página 179v “Limitación del tamaño de cabeceras HTTP generadas por WebSEAL” en la

página 179v “Transferencia de cookies de sesión a servidores de portal con conexión

(junction) (–k)” en la página 180v “Soporte para direcciones URL no sensibles a mayúsculas y minúsculas (–i)” en

la página 180v “Soporte para conexión (junction) con información de estado (–s, –u)” en la

página 181v “Especificación de UUID de servidor de fondo para conexiones (junctions) con

información de estado (–u)” en la página 182v “Conexión (junction) con sistemas de archivos de Windows (–w)” en la página

184

Cómo forzar una nueva conexión (junction) (–f)Debe utilizar la opción –f si desea forzar una nueva conexión (junction) quesobrescriba una conexión (junction) existente.


El siguiente ejemplo (nombre de instancia de servidor = cruz) muestra esteprocedimiento:1. Inicie la sesión en pdadmin:

# pdadminpdadmin> loginEscriba el ID de usuario: sec_masterEscriba la contraseña:pdadmin>

2. Utilice el comando server task list para mostrar todos los puntos de conexión(junction) actuales:pdadmin> server task webseald-cruz list/

3. Utilice el comando server task show para mostrar los detalles de la conexión(junction):pdadmin> server task webseald-cruz show /Punto de conexión (junction): /Tipo: LocalLímite fijo de conexión (junction): 0 - se utilizará el valor globalLímite dinámico 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 punto de conexión(junction) actual (la opción -f es necesaria para que se fuerce una nuevaconexión (junction) que sobrescriba la conexión (junction) existente):pdadmin> server task webseald-cruz 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 webseald-cruz list/

6. Visualice los detalles de esta conexión (junction):pdadmin> server task webseald-cruz show /Punto de conexión (junction): /Tipo: LocalLímite fijo de conexión (junction): 0 - se utilizará el valor globalLímite dinámico de conexión (junction): 0 - se utilizará el valor globalThreads de trabajo activos: 0Directorio raíz: /tmp/docs

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

La opción –c le permite insertar información de pertenencia a grupos e identidadde cliente específica de Access Manager en las cabeceras HTTP de las peticionesdestinadas a los servidores de terceros con conexión (junction). La información decabecera HTTP habilita las aplicaciones de servidores de terceros con conexión(junction) para realizar acciones específicas del usuario basadas en la identidad deAccess Manager del cliente.

El servidor de fondo debe convertir la información de cabecera HTTP en unformato de variable de entorno para que lo utilice un servicio del servidor defondo. La información de cabecera se transforma en un formato de variable deentorno de CGI sustituyendo todos los guiones (-) por caracteres de subrayado (_)y agregando “HTTP” al inicio de la cadena. El valor de la cabecera HTTP setransforma en el valor de la nueva variable de entorno.


Campos de cabeceraHTTP específicos de PD

Equivalentes de variable deentorno de CGI

Descripción

iv-user = HTTP_IV_USER = Nombre corto o largo del cliente. El valorpredeterminado es “Unauthenticated” si el cliente noestá autenticado (desconocido).

iv-groups = HTTP_IV_GROUPS = Lista de grupos a los que pertenece el cliente. Constade entradas entre comillas separadas por comas.

iv-creds = HTTP_IV_CREDS = Estructura de datos opacos codificados querepresentan una credencial de Access Manager.Proporciona credenciales para servidores remotospara que las aplicaciones de medio nivel puedanutilizar la API de autorización para llamar al serviciode autorizaciones. Consulte la publicación IBM TivoliAccess Manager Authorization C API Developer’sReference.

Las entradas de cabecera HTTP específicas de Access Manager están disponiblespara los programas CGI como las variables de entorno HTTP_IV_USER,HTTP_IV_GROUPS y HTTP_IV_CREDS. Si desea información sobre otrosproductos de entornos de aplicaciones, consulte la documentación del productopara obtener instrucciones acerca de la extracción de cabeceras de peticiones HTTP.

Sintaxis de –cLa opción –c especifica qué datos de cabecera HTTP específica de Access Managerse envían al servidor de aplicaciones de fondo.–c <tipos-cabecera>

Los argumentos tipos-cabecera son: all, iv_user, iv_user_l, iv_groups e iv_creds.


iv_user Proporciona el nombre de usuario (forma corta) como campoiv-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 la petición.

iv_groups Proporciona la lista de grupos del usuario como campo iv-groupsde la cabecera HTTP de la petición.

iv_creds Proporciona la información de credencial del usuario como campoiv-creds de la cabecera HTTP de la petició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 en la cabeceraHTTP (en este caso se utiliza el formato de nombre corto (iv_user)).

Nota: Separe los argumentos múltiples sólo con comas. No inserte espacios.

Ejemplos:–c all

–c iv_creds

–c iv_user,iv_groups

–c iv_user_l,iv_groups,iv_creds


Especificación de las direcciones IP de cliente en cabecerasHTTP (–r)

La opción –r permite insertar información de dirección IP de cliente en lascabeceras HTTP de las peticiones destinadas a los servidores de aplicaciones conconexión (junction). La información de cabecera HTTP habilita las aplicaciones deservidores de terceros 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 cabecera HTTP en unformato de variable de entorno para que lo utilice un servicio del servidor defondo. La información de cabecera se transforma en un formato de variable deentorno de CGI sustituyendo todos los guiones (-) por caracteres de subrayado (_)y agregando “HTTP” al inicio de la cadena. El valor de la cabecera HTTP setransforma en el valor de la nueva variable de entorno.

Nota: El valor de la dirección IP no representa siempre la dirección de la máquinacliente de origen. El valor de la dirección IP puede representar la direcciónde un servidor proxy o un traductor de direcciones de red (NAT).

Campo de cabeceraHTTP específico de

PD

Equivalente de variable de entornode CGI

Descripción

iv-remote-address HTTP_IV_REMOTE_ADDRESS Dirección IP del cliente. Este valor puede representarla dirección IP de un servidor proxy o un traductorde direcciones de red (NAT).

La opción –r especifica que se envíe la dirección IP de la petición entrante alservidor de aplicaciones de fondo. Esta opción se expresa sin argumentos.

Limitación del tamaño de cabeceras HTTP generadas porWebSEAL

Puede limitar el tamaño de las cabeceras HTTP generadas por WebSEAL que seinsertan en peticiones realizadas a servidores de fondo con conexión (junction). Elparámetro max-webseal-header-size de la stanza [junction] del archivo deconfiguración webseald.conf especifica el tamaño máximo, en bytes, de cabecerasHTTP generadas por WebSEAL. Con el valor “0” se inhabilita esta función:[junction]max-webseal-header-size = 0

Este parámetro puede ser útil si un servidor de aplicaciones de fondo rechaza lascabeceras HTTP generadas por WebSEAL porque son demasiado grandes. Porejemplo, una cabecera iv-creds para un usuario que pertenece a muchos grupospuede ser demasiado grande.

Este parámetro, al configurarse, hace que las cabeceras generadas por WebSEALque sobrepasen el valor máximo se dividan en varias cabeceras. La salida delejemplo siguiente de una aplicación CGI muestra el efecto de las cabecerasdivididas:HTTP_IV_CREDS_1=Version=1, BAKs3DCCBnMMADCCBm0wggZpAgIDkDCCAYUwKzAHTTP_IV_CREDS_2=+0+8eAgI8iAICEdYCAgCkAgFUBAaSVNCJqncMOWNuPXNlY21==HTTP_IV_CREDS_SEGMENTS=2


Si habilita esta función, debe modificar la aplicación de fondo para reconocercabeceras divididas, en lugar de las cabeceras HTTP estándar específicas deWebSEAL.

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

Un portal web es un servidor que ofrece una amplia gama de recursos y serviciospersonalizados. La opción –k permite enviar la cookie de sesión de AccessManager (establecida originalmente entre el cliente y WebSEAL) a un servidor deportal de fondo. Esta opción existe actualmente para dar soporte directamente a laintegración de WebSEAL con la solución Plumtree Corporate Portal.

Cuando un cliente solicita una lista de recursos personales desde el servidor deportal, el servidor de portal crea la lista accediendo a los recursos que seencuentran en otros servidores de aplicaciones de soporte, que están tambiénprotegidos por WebSEAL. La cookie de sesión permite al servidor de portalejecutar un inicio de sesión único sin problemas en estos servidores deaplicaciones, en nombre del 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 del servidor deportal:v Para acceder mediante nombre de usuario y contraseña, se necesita la

autenticación de formularios. No se debe utilizar la autenticación básica (BA).v El parámetro ssl-id-sessions en la stanza [session] del archivo de configuración

webseald.conf debe estar establecido en “no”. En la comunicación HTTPS, estevalor exige el uso de una cookie de sesión, en lugar del ID de sesión SSL, paramantener el estado de la sesión.

v Si el servidor de portal tiene delante un clúster WebSEAL, habilite la cookie detipo resolución de errores. La cookie de resolución de errores contieneinformación cifrada de credenciales que permite realizar con éxito laautenticación con cualquier servidor WebSEAL replicado que procese la petición.

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

De forma predeterminada, Access Manager trata las direcciones URL comosensibles a mayúsculas y minúsculas al realizar comprobaciones sobre los controlesde acceso. La opción –i se utiliza para especificar que WebSEAL trate lasdirecciones URL como no sensibles a mayúsculas y minúsculas al realizarcomprobaciones de autorización sobre una petición a un servidor de fondo conconexión (junction).

Cuando establezca esta opción en la conexión (junction), WebSEAL no distinguiráentre los caracteres en mayúsculas y minúsculas al analizar las direcciones URL.De forma predeterminada, se espera que los servidores web sean sensibles amayúsculas y minúsculas.

Aunque la mayoría de los servidores HTTP dan soporte a la especificación deHTTP que define la dirección URL como sensible a mayúsculas y minúsculas,algunos servidores HTTP tratan las direcciones URL como no sensibles.


Por ejemplo, en los servidores no sensibles a mayúsculas y minúsculas, estas dosdirecciones URL:http://server/sales/index.htm

http://server/SALES/index.HTM

se consideran la misma. Este comportamiento requiere que un administradordefina los mismos controles de acceso (ACL) en ambas direcciones URL.

Al conectarse a un servidor de terceros con la opción –i, WebSEAL trata lasdirecciones URL dirigidas a ese servidor como no sensibles a mayúsculas yminúsculas.

Soporte para conexión (junction) con información de estado(–s, –u)

La mayoría de las aplicaciones preparadas para web mantienen un “estado” parauna secuencia de peticiones HTTP de un cliente. Este estado se utiliza, porejemplo, para:v Seguir el progreso de un usuario a través de los campos de un formulario de

entrada de datos generado por un programa CGIv Mantener el contexto de un usuario al realizar una serie de consultas en la base

de datosv Mantener una lista de elementos en una aplicación de compra en línea donde un

usuario navega de manera aleatoria y selecciona artículos para comprar

Los servidores que ejecutan aplicaciones preparadas para web se pueden replicarpara mejorar el rendimiento a través del compartimento de cargas. Cuando elservidor WebSEAL proporciona una conexión (junction) con esos servidores defondo replicados, debe asegurarse de que todas las peticiones contenidas en lasesión del cliente se reenvían al servidor correcto y no se distribuyen entreservidores de fondo replicados según las reglas de equilibrio de carga.

De forma predeterminada, Access Manager equilibra la carga del servidor de fondoal distribuir peticiones entre todos los servidores replicados disponibles. AccessManager utiliza un algoritmo de “menos ocupado”. Este algoritmo dirige cadapetición nueva al servidor con menos conexiones en curso.

El indicador –s del comando create sobrescribe esta regla de equilibrio de carga ycrea una “conexión (junction) con información de estado” que garantiza que laspeticiones del cliente se reenvíen al mismo servidor durante toda la sesión. Cuandose produce la petición inicial del cliente, WebSEAL coloca una cookie en el sistemadel cliente que contiene el UUID del servidor de fondo designado. Cuando elcliente realiza peticiones futuras al mismo recurso, la información de UUID de lacookie garantiza que las peticiones se dirijan de forma coherente al mismo servidorde fondo.

La opción –s es apropiada para un solo servidor WebSEAL frontal con múltiplesservidores de fondo conectados al mismo punto de conexión (junction). Observeque una vez creada la conexión (junction) inicial con información de estado, seutiliza el comando add sin la opción –s para conectar los servidores de fondoreplicados restantes al mismo punto de conexión (junction).

Si el caso incluye varios servidores WebSEAL frontales, todos conectados a losmismos servidores de fondo, debe utilizar la opción –u para especificarcorrectamente cada UUID de servidor de fondo para cada servidor WebSEAL


frontal. Consulte el apartado “Especificación de UUID de servidor de fondo paraconexiones (junctions) con información de estado (–u)”.

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

Cuando se crea una conexión (junction) nueva con un servidor de aplicaciones webde fondo, WebSEAL suele generar un identificador universal único (UUID) paraidentificar el servidor de fondo. Este UUID se utiliza internamente y también paramantener conexiones (junctions) con información de estado (create –s).

Cuando se produce la petición inicial del cliente, WebSEAL coloca una cookie en elsistema del cliente que contiene el UUID del servidor de fondo designado. Cuandoel cliente realiza peticiones futuras al mismo recurso, la información de UUID de lacookie garantiza que las peticiones se dirijan de forma coherente al mismo servidorde fondo.

La gestión de conexiones (junctions) con información de estado pasa a ser máscompleja cuando hay varios servidores WebSEAL frontales conectados a variosservidores de fondo. Normalmente, cada conexión (junction) entre un servidorWebSEAL frontal y un servidor de fondo genera un UUID exclusivo para elservidor de fondo. 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 de equilibrio de cargapara distribuir la carga entre los dos servidores. Por ejemplo, se podría establecerun “estado” inicial en un servidor de fondo a través del servidor WebSEAL 1mediante un UUID específico.

Sin embargo, si el mecanismo de equilibrio de carga dirige una futura petición delmismo cliente a través del servidor WebSEAL 2, el “estado” dejará de existir, amenos que el servidor WebSEAL 2 utilice el mismo UUID para identificar elmismo servidor de fondo. Normalmente, no sucede así.

La opción –u le permite proporcionar el mismo UUID para un servidor de fondoespecífico en cada servidor WebSEAL frontal.

Por ejemplo, tenemos dos servidores WebSEAL frontales, replicados, cada uno conuna conexión (junction) con información de estado con dos servidores de fondo. Alcrear la conexión (junction) con información de estado entre el servidor WebSEAL1 y el servidor de fondo 2, se genera un UUID exclusivo (UUID A) para identificarel servidor de fondo 2. Sin embargo, cuando se crea una conexión (junction) con

Figura 35. Las conexiones (junctions) con información de estado utilizan los UUID deservidor de fondo


información de estado entre el servidor WebSEAL 2 y el servidor de fondo 2, segenera un UUID (UUID B) nuevo y distinto para identificar el servidor de fondo 2.

Se producirá un error en el “estado” establecido entre un cliente y el servidor defondo 2, mediante el servidor WebSEAL 1 si se dirige una petición posterior delcliente a través del servidor WebSEAL 2.

Aplique el siguiente proceso para especificar un UUID durante la creación de unaconexión (junction):1. Cree una conexión (junction) del servidor WebSEAL 1 con cada servidor de

fondo.Utilice create –s y add.

2. Visualice el UUID generado para cada servidor de fondo durante el paso 1.Utilice show.

3. Cree una conexión (junction) del servidor WebSEAL 2 con cada servidor defondo y especifique los UUID identificados en el paso 2.Utilice create –s –u y add –u.

En la figura siguiente, tanto WebSEAL-1 como WebSEAL-2 conocen el servidor defondo 1 como UUID 1. Y tanto WebSEAL-1 como WebSEAL-2 conocen el servidorde fondo 2 como UUID 2.

Figura 36. UUID distintos

Figura 37. Especificación de los UUID de servidor de fondo para conexiones (junctions) coninformación de estado


Ejemplo:En el siguiente ejemplo,v WebSEAL-1 se denomina WS1v WebSEAL-2 se denomina WS2v El servidor de fondo 1 se denomina APP1v 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)pdadmin> server task webseald-WS2 create –t tcp –h APP1 –u <UUID1> –s /mntpdadmin> server task webseald-WS2 add –h APP2 –u <UUID2> /mnt

Cuando un cliente establece una conexión con información de estado con elservidor de fondo 2, recibe una cookie que contiene UUID2. El ejemplo anteriorgarantiza que el cliente se conectará siempre al servidor de fondo 2,independientemente de si las peticiones posteriores se dirigen a través deWebSEAL-1 o de WebSEAL-2.

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

WebSEAL realiza comprobaciones de seguridad en las peticiones de clientes a losservidores de fondo con conexión (junction) basadas en las rutas de acceso de losarchivos especificadas en la dirección URL. Se puede producir un compromiso enesta comprobación de seguridad porque los sistemas de archivos de Win32permiten dos métodos distintos para acceder a los nombres de archivo largos.

El primer método reconoce el nombre de archivo entero. Por ejemplo:abcdefghijkl.txt

El segundo método reconoce el antiguo formato de nombre de archivos 8.3 paraque exista compatibilidad inversa. Por ejemplo:abcdef~1.txt

Al crear conexiones (junctions) en entornos Windows, es importante restringir elcontrol de acceso a una sola representación de objeto y no permitir la posibilidadde “puertas traseras” que eludan el mecanismo de seguridad.

La opción –w en una conexión (junction) proporciona las siguientes medidas deprotección:1. Impide el uso del formato de nombre de archivos 8.3

Cuando la conexión (junction) se configura con la opción –w, un usuario nopuede evitar una ACL explícita en un nombre de archivo largo utilizando elformato corto (8.3) del nombre de archivo. El servidor devuelve un error “403No autorizado” en cualquier nombre de archivo de formato corto especificado.

2. Prohíbe los puntos de cola en los nombres de directorio y de archivoSi un archivo o un directorio contiene puntos de cola, se devuelve un error 403“No autorizado”.

3. Aplica la no sensibilidad a mayúsculas y minúsculas estableciendo la opción –i

La opción –w invoca automáticamente la opción –i. Esta opción especifica queWebSEAL trate las direcciones URL como no sensibles a mayúsculas y


minúsculas al realizar comprobaciones de autorización en una petición a unservidor de fondo con conexión (junction). Después de una comprobación deACL correcta, el uso original de mayúsculas o minúsculas en la dirección URLse restaura cuando se envía la petición al servidor de fondo.

Nota: Si sólo necesita controlar la no sensibilidad de mayúsculas y minúsculaspara los nombres de archivo, utilice sólo la opción –i en la conexión(junction) en lugar de la opción –w.

Ejemplo:En un entorno Windows, también se puede acceder al archivo:\Archivos de programa\Company Inc\Release.Notes

a través de las rutas de acceso siguientes:1. \archiv~1\compan~2\releas~3.not

2. \Archivos de programa\Company Inc.\Release.Notes

3. \archivos de programa\company inc\release.notes

El ejemplo 1 muestra cómo Windows puede crear un alias (para la compatibilidadcon DOS) que no contiene espacios en el nombre de archivo y se ajusta al formato8.3. La opción –w hace que WebSEAL rechace este formato para lascomprobaciones de ACL.

El ejemplo 2 muestra cómo Windows puede incluir puntos de cola de extensión. Laopción –w hace que WebSEAL rechace este formato para las comprobaciones deACL.

El ejemplo 3 muestra cómo Windows permite la no sensibilidad a mayúsculas yminúsculas en el nombre de archivo. La opción –w invoca la opción –i paraasegurar una comprobación de ACL no sensible a mayúsculas y minúsculas.

Notas técnicas para utilizar conexiones (junctions) WebSEALv “Montaje de varios servidores en la misma conexión (junction)” en la página 185v “Excepciones a la aplicación de permisos entre conexiones (junctions)” en la

página 186v “Certificación de autenticación entre conexiones (junctions)” en la página 186

Montaje de varios servidores en la misma conexión (junction)Puede montar varios servidores replicados en el mismo punto de conexión(junction). Puede haber cualquier cantidad de servidores montados en el mismopunto.

Todos los servidores montados en un punto de conexión (junction) deben serréplicas (espacios web duplicados) y deben utilizar el mismo protocolo: HTTP oHTTPS. No monte servidores diferentes en el mismo punto de conexión (junction).

Desde el espacio web del servidor principal de Access Manager, acceda a laspáginas que pertenecen al servidor o servidores con conexión (junction). Debepoder acceder a estas páginas (dependiendo, evidentemente, de los permisos) y laspáginas deben aparecer de forma coherente. Si no se encuentra alguna página, o siésta se modifica ocasionalmente, significa que la página no se ha replicado demanera correcta.


Compruebe que exista el documento y que sea idéntico en el árbol de documentosde los dos servidores replicados.

Excepciones a la aplicación de permisos entre conexiones(junctions)

Algunos permisos de Access Manager no se pueden aplicar a través de unaconexión (junction). No puede controlar, por ejemplo, la ejecución de un script CGIcon el permiso x o un listado de directorios con el permiso l. WebSEAL no tieneninguna forma de determinar con precisión si un objeto solicitado de un servidorde fondo es, por ejemplo, un archivo de programa CGI, un listado de directoriosdinámico o un objeto HTTP normal.

El acceso a los objetos a través de conexiones (junctions), incluidos los programasCGI y los listados de directorios, sólo se controla mediante el permiso r.

Certificación de autenticación entre conexiones (junctions)Durante la instalación, WebSEAL se configura con un certificado de prueba nopredeterminado. El certificado de prueba se designa como el certificado activo deservidor mediante el parámetro webseal-cert-keyfile-label en la stanza [ssl] delarchivo de configuración webseald.conf.

Si un servidor de aplicaciones de fondo con conexión (junction) requiere queWebSEAL se identifique con un certificado de cliente, deberá crear, instalar yetiquetar primero este certificado utilizando el programa de utilidad iKeyman. Acontinuación, configure la conexión (junction) con la opción –K <etiqueta-clave>.Consulte el apartado “Conexiones (junctions) SSL autenticadas mutuamente” en lapágina 165.

Si la conexión (junction) no se configura con –K, GSKit gestiona una petición parala autenticación mutua, enviando automáticamente el certificado “predeterminado”contenido en la base de datos del archivo de claves. Si esta no es la respuestaadecuada, deberá asegurarse de que no haya certificados marcados como“predeterminado” (una marca de asterisco) en la base de datos del archivo declaves (pdsrv.kdb).

En resumen:v Identifique todos los certificados necesarios por el nombre de etiqueta.v No marque ningún certificado en la base de datos del archivo de claves como

“predeterminado”.v Controle la respuesta del certificado de servidor de WebSEAL con el parámetro

webseal-cert-keyfile-label.v Controle la respuesta del certificado de cliente de WebSEAL mediante la opción

de conexión (junction) –K.

Utilización de query_contents con servidores de tercerosSi desea proteger los recursos del espacio web de aplicaciones de terceros medianteel servicio de seguridad de Access Manager, debe proporcionar a WebSEALinformación acerca del contenido del espacio web de terceros.

Un programa CGI denominado query_contents proporciona esta información. Elprograma query_contents busca el contenido del espacio web de terceros yproporciona esta información de inventario a Web Portal Manager en WebSEAL. Elprograma está incluido en la instalación de WebSEAL, pero se debe instalar


manualmente en el servidor de terceros. Hay distintos tipos de archivos deprograma disponibles, dependiendo de si el servidor de terceros se ejecuta enUNIX o Windows.

El gestor del espacio de objetos de Web Portal Manager ejecuta automáticamentequery_contents en cualquier momento en que el fragmento del espacio de objetosprotegidos que representa la conexión (junction) se amplía en el panel de gestióndel espacio de objetos. Ahora que Web Portal Manager conoce el contenido delespacio de aplicaciones de terceros, puede ver esta información y aplicar lasplantillas de política a los objetos apropiados.

Instalación de los componentes de query_contentsLa instalación de query_contents suele ser muy fácil. La instalación implica copiaruno o dos archivos del servidor de Access Manager en el servidor de terceros yeditar un archivo de configuración.

El siguiente directorio de Access Manager contiene una plantilla del programa:

UNIX: <ruta-acceso-instalación>/www/lib/query_contents

Windows: <ruta-acceso-instalación>\www\lib\query_contents

El contenido del directorio incluye:

Archivo Descripción

query_contents.exe Programa ejecutable principal para sistemas Win32. Debeinstalarse en el directorio cgi-bin del servidor web deterceros.

query_contents.sh Programa ejecutable principal para sistemas UNIX. Debeinstalarse en el directorio cgi-bin del servidor web deterceros.

query_contents.c Código fuente. Se incluye el código fuente por si esnecesario 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 que identifica la raízde documentos para el servidor web.

Instalación de query_contents en servidores UNIX de tercerosLocalice el script de shell denominado query_contents.sh en el siguientedirectorio:<ruta-acceso-instalación>/www/lib/query_contents

1. Copie query_contents.sh en un directorio /cgi-bin en funcionamiento en elservidor web de terceros.

2. Elimine la extensión .sh.3. Establezca el bit de ejecución de UNIX para la cuenta de administración del

servidor web.

Instalación de query_contents en servidores Win32 deterceros

Opción especial de conexión (junction) para Windows:


Cuando se necesite y se instale el programa query_contents en un servidor defondo de aplicaciones web de Windows con conexión (junction), se debe utilizar laopción –q al crear la conexión (junction) con ese servidor.

El motivo de este requisito es que, de forma predeterminada, WebSEAL busca elprograma query_contents en el directorio cgi-bin:/cgi-bin/query_contents

Si cambia el nombre del programa query_contents o cambia su ubicación dedirectorio, debe utilizar la opción –q <ubicación> al crear la conexión (junction). Elargumento de ubicación especifica la nueva ubicación y nombre del programa.

El nombre del programa query_contents utilizado en la plataforma Windows esquery_contents.exe. La presencia de la extensión .exe hace que el nombre delprograma sea diferente. Por lo tanto, WebSEAL no puede encontrar el nombre deprograma predeterminado. Debe utilizar la opción y argumento –q <ubicación>para indicar a WebSEAL dónde puede encontrar el archivo. Por ejemplo:create -t tcp -h <nombre-host> ... -q /cgi-bin/query_contents.exe /<nombre-conexión>

La opción –q no es necesaria para un servidor UNIX porque el nombre y laubicación del programa query_contents coinciden con la condiciónpredeterminada.

Procedimiento:

Localice el programa ejecutable denominado query_contents.exe y el archivo deconfiguración denominado query_contents.cfg en el siguiente directorio:

Windows: <ruta-acceso-instalación>\www\lib\query_contents

1. Asegúrese de que el servidor web de terceros tenga el directorio CGIconfigurado correctamente.

2. Para las comprobaciones, asegúrese de que exista un documento válido en laraíz de documentos del servidor web de terceros.

3. Copie query_contents.exe en el directorio CGI del servidor web de terceros.4. Copie query_contents.cfg en el directorio Windows.

En la tabla siguiente aparecen los valores predeterminados de este directorio:

Sistema operativo Directorio Windows

Windows 95 y 98 c:\windows

Windows NT 4.x y 2000 c:\winnt

5. Edite el archivo query_contents.cfg para especificar correctamente el directorioraíz de documentos para el servidor web de terceros.Actualmente, el archivo contiene ejemplos de entradas para los servidoresMicrosoft Internet Information Server y Netscape FastTrack. Las líneas de estearchivo que empiecen con un punto y coma (;) son comentarios y el programaquery_contents las omitirá.

6. Cree una conexión (junction) con el servidor Windows de fondo y utilice laopción –q para especificar que query_contents.exe es el archivo correcto. Porejemplo:pdadmin> server task webseald-<nombre-instancia> create -t tcp -h <nombre-host> ... \-q /cgi-bin/query_contents.exe /<nombre-conexión>


Prueba de la configuración1. Desde un indicador de MS-DOS de la máquina Win32, ejecute el programa

query_contents del directorio CGI de la siguiente forma:MSDOS> query_contents dirlist=/

Aparecerá algo similar a la siguiente salida:100index.htmlcgi-bin//pics//

El número 100 es un estado de retorno que indica el éxito de la operación. Esimportante ver el número 100 al menos como el primer valor (y tal vez elúnico).

Si, por lo contrario, ve un código de error, ello indica que el archivo deconfiguración no se encuentra en la ubicación correcta o bien no contiene unaentrada de raíz de documentos válida. Compruebe la configuración del archivoquery_contents.cfg y asegú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. Si no es así, laconfiguración de CGI del servidor web no es correcta. Consulte ladocumentación del servidor para corregir el problema.

Personalización de query_contentsLa tarea de query_contents es devolver el contenido de los directorios incluidos enuna petición de dirección URL.

Por ejemplo, para obtener el contenido del directorio raíz del espacio web de unservidor, el navegador ejecuta query_contents en una dirección URL, como porejemplo:http://servidor-de-terceros/cgi-bin/query_contents?dirlist=/

El script query_contents lleva a cabo las acciones siguientes:1. Lee $SERVER_SOFTWARE, una variable de entorno de CGI estándar, para

determinar el tipo de servidor.Según el tipo de servidor web, la variable $DOCROOTDIR se establece en unaubicación raíz de documentos típica.

2. Lee la variable de entorno $QUERY_STRING de la dirección URL solicitadapara obtener la operación solicitada y obtener la ruta de acceso de objetos.El valor de la operación se almacena en la variable $OPERATION y la ruta deacceso de objetos en $OBJPATH. En el ejemplo anterior, $OPERATION esdirlist y $OBJPATH es “/”.

3. Crea una lista de directorios (ls) en la ruta de acceso del objeto y coloca losresultados en la salida estándar para que lo utilice el servidor de AccessManager. Las entradas que indican subdirectorios tienen una barra inclinadadoble (//) 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 la operación.

Personalización del directorio raíz de documentosUNIX:

Para personalizar query_contents.sh para el servidor UNIX, es posible que debamodificar el valor del directorio raíz de documentos.

Si query_contents devuelve un estado de error (un número distinto de 100) y noincluye ningún archivo en la lista, examine el script y modifique la variable$DOCROOTDIR, si es necesario, para que coincida con la configuración delservidor.

Si el directorio raíz de documentos está especificado correctamente y se sigueproduciendo un error en el script, es posible que la especificación de la ubicaciónde cgi-bin sea incorrecta. Examine la variable $FULLOBJPATH y modifique el valorasignado a ésta para que refleje la ubicación correcta de cgi-bin.

Windows:

Para personalizar query_contents.exe para el servidor Windows, modifique elarchivo query_contents.cfg.

Funcionalidad adicionalEl código fuente del programa query_contents (query_contents.c) se distribuyecon Access Manager sin necesidad de pagar ningún derecho.

Se pueden agregar funciones adicionales a este programa para dar soporte a lascaracterísticas especiales de algunos servidores web de terceros. Estascaracterísticas son:1. Correlación de directorios, cuando un subdirectorio que no esté por debajo del

directorio raíz de documentos se correlacione en el espacio web.2. Generación de un espacio web que no esté basado en el sistema de archivos.

Puede tratarse de un servidor web que aloje una base de datos.

Protección de query_contentsAccess Manager utiliza el programa CGI query_contents para visualizar losespacios de objetos del servidor web con conexión (junction) en Web PortalManager. Es muy importante proteger este archivo para que no sea ejecutado porusuarios no autorizados.

Debe establecer una política de seguridad que sólo permita a la identidad dePolicy Server (pdmgrd) tener acceso al programa query_contents. La siguienteACL de ejemplo (query_contents_acl) cumple estos requisitos:group ivmgrd-servers Tl

user sec_master dbxTrlcam

Utilice el programa de utilidad pdadmin para asociar esta ACL con el objeto dequery_contents.sh (UNIX) o query_contents.exe (Windows) en los servidores conconexión (junction). Por ejemplo (UNIX):pdadmin> acl attach /WebSEAL/<host>/<nombre-conexión>/query_contents.sh \query_contents_acl


Capítulo 8. Soluciones de inicio de sesión único de web

Cuando se implementa WebSEAL como servidor proxy para proporcionarprotección a un dominio seguro, a menudo se deben proporcionar soluciones paraun inicio de sesión único en los recursos web. En este capítulo se describen lassoluciones de inicio de sesión único para el espacio web de una configuraciónproxy de WebSEAL. Algunos ejemplos son las conexiones (junction) especialmenteconfiguradas, el inicio de sesión global y LTPA.

Índice de temas:v “Configuración de cabeceras de BA para las soluciones de inicio de sesión

único” en la página 191v “Utilización de Global Sign-on (GSO)” en la página 196v “Configuración del inicio de sesión único en IBM WebSphere (LTPA)” en la

página 199v “Configuración de la autenticación de formularios de inicio de sesión único” en

la página 201

Configuración de cabeceras de BA para las soluciones de inicio desesión único

Este apartado trata las posibles soluciones para crear configuraciones de inicio desesión único a través de conexiones (junctions) WebSEAL mediante las opciones–b.v “Conceptos de inicio de sesión único (SSO)” en la página 191v “Especificación de la identidad de cliente en cabeceras de BA” en la página 192v “Especificación de la identidad del cliente y la contraseña genérica” en la página

193v “Reenvío de la información de cabecera de BA del cliente original” en la página

194v “Eliminación de la información de cabecera de BA de cliente” en la página 195v “Especificación de los nombres de usuario y las contraseñas de GSO” en la

página 195

Conceptos de inicio de sesión único (SSO)Cuando se encuentra un recurso protegido en un servidor de aplicaciones web defondo, se puede requerir a los clientes que solicitan ese recurso que realicen iniciosde sesión múltiples: uno para el servidor WebSEAL y uno para el servidor defondo. Cada inicio de sesión probablemente requerirá distintas identidades deinicio de sesión.


El problema de administrar y mantener identidades de inicios de sesión múltiplespuede resolverse habitualmente con un mecanismo de inicio de sesión único (SSO).Una solución de inicio de sesión único permite al usuario acceder a un recurso,con independencia de la ubicación del recurso, utilizando sólo un inicio de sesióninicial. Los requisitos de inicio de sesión posteriores de los servidores de fondo segestionan de una forma transparente para el usuario.

Especificación de la identidad de cliente en cabeceras de BAPuede configurar conexiones (junctions) WebSEAL para proporcionar al servidorde fondo información de identidad de cliente original o modificada. El conjunto deopciones –b le permite proporcionar información de identidad de cliente específicaen cabeceras de autenticación básica (BA) HTTP.

Como administrador, debe analizar la arquitectura de la red y los requisitos deseguridad y determinar las respuestas a las preguntas siguientes:1. ¿El servidor de fondo requiere información de autenticación?

(WebSEAL utiliza la cabecera de autenticación básica HTTP para transferir lainformación de autenticación.)

2. Si el servidor de fondo requiere información de autenticación, ¿de dóndeproviene esa información?(¿Qué información coloca WebSEAL en la cabecera HTTP?)

3. ¿La conexión entre WebSEAL y el servidor de fondo debe ser segura?(¿Conexión (junction) TCP o SSL?)

Después de la autenticación inicial entre el cliente y WebSEAL, WebSEAL puedecrear una cabecera de autenticación básica. La petición utiliza esta cabecera nuevamientras sigue por la conexión (junction) hasta el servidor de fondo. Utilice lasopciones –b para indicar la información de autenticación específica que seproporciona en esta cabecera nueva.

Figura 38. Inicios de sesión múltiples

Figura 39. Especificación de la información de autenticación a los servidores de fondo


Especificación de la identidad del cliente y la contraseñagenérica

–b supply

La opción –b supply indica a WebSEAL que proporcione el nombre de usuarioautenticado de Access Manager (la identidad original del cliente) con unacontraseña estática y genérica (“simulada”). La contraseña de cliente original no seutiliza en este escenario.

Una contraseña genérica elimina la administración de contraseñas y da soporte a laaplicación en base al usuario. La contraseña “simulada” está establecida en elparámetro basicauth-dummy-passwd del archivo de configuración webseald.conf:[junction]basicauth-dummy-passwd = <contraseña>

En este escenario se supone que el servidor de fondo necesita la autenticación deuna identidad de Access Manager. Al correlacionar un usuario de cliente con unusuario de Access Manager conocido, WebSEAL gestiona la autenticación para elservidor de fondo y proporciona una sencilla solución de inicio de sesión único entodo el dominio.

Existen las siguientes condiciones para esta solución:v WebSEAL está configurado para que proporcione al servidor de fondo el nombre

de usuario contenido en la petición de cliente original más una contraseñagenérica (“simulada”).

v La contraseña “simulada” está configurada en el archivo de configuraciónwebseald.conf.

v El registro del servidor de fondo debe reconocer la identidad de Access Managerproporcionada en la cabecera de BA HTTP.

v Debido a que se pasa información de autenticación confidencial (nombre deusuario y contraseña) a través de la conexión (junction), la seguridad de laconexión es importante. Es muy recomendable una conexión (junction) SSL.

LimitacionesSe utiliza la misma contraseña “simulada” de Access Manager para todas laspeticiones; todos los usuarios tienen la misma contraseña en el registro del servidor

Figura 40. La cabecera de BA contiene la identidad y una contraseña ″simulada″

Capítulo 8. Soluciones de inicio de sesión único de web 193

de fondo. El uso de la contraseña “simulada” común no ofrece ninguna base paraque el servidor de aplicaciones compruebe la legitimidad del inicio de sesión delcliente con ese nombre de usuario.

Si los clientes pasan siempre a través de WebSEAL para acceder al servidor defondo, esta solución no presenta ningún problema de seguridad. Sin embargo, esimportante proteger físicamente el servidor de fondo de otras posibles formas deacceso.

Puesto que este escenario no tiene ninguna seguridad de nivel de contraseñas, elservidor de fondo debe fiarse implícitamente de WebSEAL para verificar lalegitimidad del cliente.

El registro del servidor de fondo debe reconocer también la identidad de AccessManager para aceptarla.

Reenvío de la información de cabecera de BA del clienteoriginal

–b ignore

La opción –b ignore indica a WebSEAL que debe pasar la cabecera deautenticación básica (BA) de cliente original directamente al servidor de fondo sinninguna interferencia. WebSEAL puede configurarse para que autentique estainformación de cliente de BA o omita la cabecera de BA que proporciona el clientey la reenvíe, sin modificarla, al servidor de fondo.

Nota: No es un mecanismo de inicio de sesión único verdadero, sino un inicio desesión directo al servidor de terceros, transparente para WebSEAL.

Existen las siguientes condiciones para esta solución:v El servidor de fondo requiere información de identidad de cliente mediante BA.

El servidor de fondo enviará una tentativa de autenticación básica al cliente. Elcliente responde con la información de nombre de usuario y contraseña que elservidor WebSEAL pasa sin ninguna modificación.

v El servidor de fondo mantiene sus propias contraseñas proporcionadas por elcliente.

v WebSEAL está configurado para que proporcione al servidor de fondo el nombrede usuario y la contraseña contenidos en la petición de cliente original.

v Debido a que se pasa información de autenticación confidencial (nombre deusuario y contraseña) a través de la conexión (junction), la seguridad de laconexión es importante. Es muy recomendable una conexión (junction) SSL.


Eliminación de la información de cabecera de BA de cliente–b filter

La opción –b filter indica a WebSEAL que elimine toda la información de cabecerade autenticación básica de las peticiones de cliente antes de reenviar las peticionesal servidor de fondo. En este escenario, WebSEAL es el único proveedor deseguridad.

Existen las siguientes condiciones para esta solución:v La autenticación básica está configurada entre el cliente y WebSEALv El servidor de fondo no requiere la autenticación básicav Sólo se puede acceder al servidor de fondo a través de WebSEALv WebSEAL gestiona la autenticación en nombre del servidor de fondo

Si necesita proporcionar al servidor de fondo alguna información de cliente, puedecombinar esta opción con la opción –c para insertar la información de identidad decliente de Access Manager en campos de cabecera HTTP. Consulte el apartado“Especificación de la identidad del cliente en cabeceras HTTP (–c)” en la página177.

Especificación de los nombres de usuario y las contraseñasde GSO

–b gso

Figura 41. WebSEAL reenvía información de identidad del cliente original

Figura 42. Eliminación de la información de cabecera de BA de cliente


La opción –b gso indica a WebSEAL que debe proporcionar al servidor de fondo lainformación de autenticación (nombre de usuario y contraseña) obtenida de laconfiguración de un servidor para gestionar el inicio de sesión global (GSO).

Existen las siguientes condiciones para esta solución:v Las aplicaciones de servidor de fondo requieren distintos nombres de usuario y

contraseñas que no están contenidos en el registro de WebSEAL.v La seguridad es importante para WebSEAL y el servidor de fondo.

Debido a que se pasa información de autenticación confidencial (nombre deusuario y contraseña) a través de la conexión (junction), la seguridad de laconexión es importante. Es muy recomendable una conexión (junction) SSL.

Este mecanismo se describe detalladamente en el apartado “Utilización de GlobalSign-on (GSO)”.

Utilización de Global Sign-on (GSO)Access Manager da soporte a una solución de inicio de sesión único flexible quepresenta la posibilidad de proporcionar nombres de usuario y contraseñasalternativos al servidor de aplicaciones web de fondo.

Global Sign-on otorga a los usuarios el acceso a los recursos de sistemas que estánautorizados a utilizar, a través de un inicio de sesión único. Concebido paragrandes empresas que constan de varios sistemas y aplicaciones dentro deentornos de sistemas distribuidos heterogéneos, GSO elimina la necesidad de losusuarios finales 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 de fondo. En primer lugar, los recursos GSOy los grupos de recursos GSO deben crearse utilizando Web Portal Manager o elprograma de utilidad pdadmin.

Cuando WebSEAL recibe una petición para un recurso ubicado en el servidor conconexión (junction), WebSEAL pide al servidor del registro de usuarios lainformación de autenticación adecuada. El servidor de registro de usuarioscontiene una base de datos de correlaciones —para cada usuario registrado— queproporciona nombres de usuario y contraseñas alternativos para determinadosrecursos y aplicaciones.

La siguiente figura muestra cómo se utiliza el mecanismo GSO para recuperarnombres de usuario y contraseñas para recursos de aplicaciones de fondo.1. El cliente se autentica en WebSEAL con una petición para acceder a un recurso

de aplicación en un servidor de fondo. Se obtiene una identidad de AccessManager.

Nota: El proceso de inicio de sesión único es independiente del método deautenticación inicial.

2. WebSEAL pasa la identidad de Access Manager al servidor de registro deusuarios.

3. El registro devuelve un nombre de usuario y una contraseña que sonadecuados para el usuario y para el recurso de aplicación solicitado.


4. WebSEAL inserta la información de nombre de usuario y contraseña en lacabecera de autenticación básica HTTP de la petición que se envía a través dela conexión (junction) con el servidor de fondo.

Correlación de la información de autenticaciónEl ejemplo siguiente muestra cómo el registro de usuarios proporciona informaciónde autenticación a WebSEAL. Si el usuario Michael desea ejecutar el recurso deaplicación travel-app (consulte la Figura 43), WebSEAL pide al servidor de registrode usuarios la información de autenticación para Michael.

El servidor de registro de usuarios mantiene una base de datos completa deinformación de autenticación en forma de correlaciones de recursos coninformación de autenticación específica. La información de autenticación es unacombinación de nombre de usuario / contraseña conocida como credencial derecurso. Sólo se pueden crear credenciales de recursos para los usuariosregistrados.

El registro contiene una base de datos para Michael que correlaciona el recurso:travel-app con una credencial de recurso específica.

La siguiente tabla muestra la estructura de la base de datos de credenciales derecursos de GSO:

Michael Paul

resource: travel-appusername=mikepassword=123

resource: travel-appusername=bundypassword=abc

resource: payroll-appusername=powellpassword=456

resource: payroll-appusername=jensenpassword=xyz

En este ejemplo, el registro devuelve el nombre de usuario “mike” y la contraseña“123” a WebSEAL. WebSEAL utiliza esta información cuando construye la cabecerade autenticación básica en la petición enviada a través de la conexión (junction) alservidor de fondo.

Figura 43. Mecanismo de Global Sign-on


Configuración de una conexión (junction) WebSEAL habilitadapara GSO

El soporte para GSO se configura en la conexión (junction) entre WebSEAL y unservidor de fondo.

Para crear una conexión (junction) que habilite GSO, utilice el comando create conla opción –b gso. El ejemplo siguiente muestra la sintaxis para el comando create:create –t tcp –h <nombre-host> –b gso –T <recurso> <punto-conexión>

A continuación se muestra una lista de opciones para configurar conexiones(junctions) GSO:

Opciones Descripción

–b gso Especifica que GSO debe proporcionar información deautenticación para todas las peticiones que pasan poresta conexión (junction).

–T <recurso/grupo-recursos> Especifica el recurso o grupo de recursos de GSO. Elnombre de recurso utilizado como argumento paraesta opción debe coincidir exactamente con el nombrede recursos tal como se lista en la base de datos deGSO. Necesario para conexiones (junctions) gso.

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 ssl al crear laconexión.

Es recomendable que utilice siempre conexiones (junctions) SSL con GSO paragarantizar el cifrado de credenciales y todos los datos.

Ejemplos de conexiones (junctions) WebSEAL habilitadas paraGSOPara conectar el recurso de aplicaciones travel-app del host sales_svr con el puntode conexión (junction) /sales:create –t tcp –b gso –T travel-app –h sales_svr /sales

Para conectar el recurso de aplicaciones payroll-app del host adm_svr con el puntode conexión (junction) /admin y proteger la conexió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 establece el puerto predeterminado443.

Configuración de la caché de GSOLa funcionalidad de la caché de Global Sign-on (GSO) permite mejorar elrendimiento de las conexiones (junctions) GSO en un entorno de carga elevada. Deforma predeterminada, la caché de GSO está inhabilitada. Sin la mejora de lacaché, se necesita una llamada al servidor de registro de usuarios para cadarecuperación de información de destino de GSO (nombre de usuario de GSO ycontraseña de GSO).

Los parámetros para configurar la caché de GSO se encuentran en la stanza[gso-cache] del archivo de configuración webseald.conf. Debe habilitar primero lacaché. El resto de parámetros configuran el tamaño de la caché y los valores detiempo de espera para las entradas de la caché. Unos valores de tiempo de espera


de inactividad y de duración más altos aumentan el rendimiento, pero también elriesgo de exposición de la información en la memoria de WebSEAL. No habilite lacaché de GSO si no se utilizan las conexiones (junctions) GSO en su solución dered.


gso-cache-enabled Habilita e inhabilita la funcionalidad de la cachéde GSO. Los valores posibles son “yes” y “no”.El valor predeterminado es “no”.

gso-cache-size Establece el número máximo de entradaspermitidas en la tabla hash de la caché.Establezca este valor para que se aproxime alvalor máximo de sesiones de usuario simultáneasque acceden a una aplicación a través de unaconexión (junction) GSO. Un valor alto utilizamás memoria pero permite un acceso a lainformación más rápido. Cada entrada de cachéconsume aproximadamente 50 bytes.

gso-cache-entry-lifetime Tiempo máximo (en segundos) que puedepermanecer en la caché una entrada de caché,independientemente de la actividad. Cuando unaentrada de caché caduca, la siguiente petición delmismo usuario requerirá una nueva llamada alservidor de registro de usuarios.

gso-cache-entry-idle-timeout Tiempo máximo (en segundos) que puedepermanecer en la caché una entrada de cachéinactiva.

Configuración del inicio de sesión único en IBM WebSphere (LTPA)WebSEAL puede proporcionar servicios de autenticación, autorización y protecciónen un entorno IBM WebSphere. Si WebSEAL se coloca como frente de protecciónde WebSphere, los clientes que accedan se encontrarán con dos puntos potencialesde inicio de sesión. Por lo tanto, WebSEAL da soporte a una solución de inicio desesión único para uno o más servidores IBM WebSphere a través de las conexiones(junctions) WebSEAL.

WebSphere proporciona un mecanismo ligero de autenticación de terceros (LTPA)basado en cookies. Las conexiones (junctions) WebSEAL se pueden configurar paradar soporte a LTPA y proporcionar soluciones de inicio de sesión único a losclientes.

Cuando un usuario realiza la petición de un recurso de WebSphere, el usuariodebe autenticarse primero en WebSEAL. Si la autenticación es correcta, WebSEALgenera una cookie LTPA en nombre del usuario. La cookie LTPA, que sirve comoseñal de autenticación para WebSphere, contiene información sobre la identidaddel usuario, clave y datos de señal, longitud de búfer y caducidad. Estainformación se cifra utilizando una clave secreta protegida por contraseña quecomparten WebSEAL y el servidor WebSphere.

WebSEAL inserta la cookie en la cabecera HTTP de la petición que se envía através de la conexión (junction) a WebSphere. El servidor WebSphere de fondorecibe la petición, descifra la cookie y autentica al usuario a partir de lainformación de identidad suministrada en la cookie.


Para aumentar el rendimiento, WebSEAL puede almacenar la cookie LTPA en lacaché, y utilizar la cookie LTPA almacenada en la caché para futuras peticionesdurante la misma sesión de usuario. Puede configurar los valores de tiempo deespera de duración y de inactividad (desocupado) para la cookie almacenada en lacaché.

Configuración de una conexión (junction) LTPAEl inicio de sesión único en WebSphere a través de una cookie LTPA requiere lossiguientes elementos de configuración:1. Habilitar el mecanismo LTPA.2. Proporcionar la ubicación del archivo de claves que se utiliza para 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 opciones adicionalespara el comando create de conexión (junction).v La opción –A habilita las cookies LPTA.v La opción y el argumento –F <“archivo-claves”> especifican el nombre completo

de la ruta de acceso de la ubicación (en el servidor WebSEAL) del archivo declaves utilizado para descifrar la información de identidad contenida en lacookie. La clave compartida se crea originalmente en el servidor WebSphere y secopia de forma segura en el servidor WebSEAL. Consulte la documentación deWebSphere correspondiente para obtener información más detallada sobre estatarea.

v –Z <“contraseña-archivo-claves”> especifica la contraseña necesaria para abrir elarchivo de claves.La contraseña aparece como texto cifrado en el archivo XML de conexión(junction).

Utilice estas opciones, además de las otras opciones de conexión (junction)necesarias, cuando cree la conexión (junction) entre WebSEAL y el servidorWebSphere 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 introduce una carga deproceso adicional. La funcionalidad de la caché de LTPA permite mejorar elrendimiento de las conexiones (junctions) LTPA en un entorno de carga elevada.Sin la mejora de la caché, se crea y se cifra una nueva cookie LTPA para cada unade las siguientes peticiones de usuario. De forma predeterminada, la caché deLTPA está habilitada.

Los parámetros para configurar la caché de LTPA se encuentran en la stanza[ltpa-cache] del archivo de configuración webseald.conf. Los parámetrosespecifican el tamaño de la caché y los valores de tiempo de espera para lasentradas de la caché. Unos valores de tiempo de espera de inactividad y deduración más altos aumentan el rendimiento, pero también el riesgo de exposiciónde la información en la memoria de WebSEAL.


ltpa-cache-enabled Habilita e inhabilita la funcionalidad de la cachéde LTPA. Los valores posibles son “yes” y “no”.El valor predeterminado es “yes”.



ltpa-cache-size Establece el número máximo de entradaspermitidas en la tabla hash de la caché.Establezca este valor para que se aproxime alvalor máximo de sesiones de usuario simultáneasque acceden a una aplicación a través de unaconexión (junction) LTPA. Un valor alto utilizamás memoria pero permite un acceso a lainformación más rápido. Cada entrada de cachéconsume aproximadamente 50 bytes. El valorpredeterminado es 4096 entradas.

ltpa-cache-entry-lifetime Tiempo máximo (en segundos) que puedepermanecer en la caché una entrada de caché,independientemente de la actividad. Cuando laentrada de caché caduca, la siguiente petición delmismo usuario requerirá la creación de unanueva cookie LTPA. El valor predeterminado es3600 segundos.

ltpa-cache-entry-idle-timeout Tiempo máximo (en segundos) que puedepermanecer en la caché una entrada de cachéinactiva. El valor predeterminado es 600segundos.

Notas técnicas para el inicio de sesión único de LTPAv El archivo de claves contiene información sobre un servidor WebSphere

específico. Cada conexión (junction) LTPA es específica para un servidorWebSphere. Si agrega más de un servidor al mismo punto de conexión(junction), todos los servidores compartirán el mismo archivo de claves.

v Para que el inicio de sesión único sea correcto, WebSEAL y el servidorWebSphere deben compartir la misma información de registro.

v El servidor WebSphere es el responsable de configurar LTPA y crear la clavesecreta compartida. La participación de WebSEAL engloba la configuración de laconexión (junction) y la caché.

Configuración de la autenticación de formularios de inicio de sesiónúnico

La autenticación de los formularios de inicio de sesión único permite a WebSEALiniciar la sesión, de forma transparente, de un usuario de Access Managerautenticado a un servidor de aplicaciones de fondo con conexión (junction) querequiere autenticación a través de un formulario HTML.

Contexto y objetivosLa autenticación de formularios de inicio de sesión único da soporte a lasaplicaciones existentes que utilizan formularios HTML para efectuar laautenticación y no se puede modificar para confiar directamente en laautenticación realizada por WebSEAL. La habilitación de la autenticación deformularios de inicio de sesión único produce los resultados siguientes:v WebSEAL interrumpe el proceso de autenticación iniciado por la aplicación de

fondo.v WebSEAL proporciona los datos que necesita el formulario de inicio de sesión y

somete el formulario de inicio de sesión en nombre del usuario.


v WebSEAL guarda y restaura todas las cookies y las cabecerasv El usuario no sabe que se está realizando un segundo inicio de sesión.v La aplicación de fondo no sabe que el formulario de inicio de sesión no procede

directamente del usuario.

WebSEAL debe configurarse para:v Reconocer e interceptar el formulario de inicio de sesiónv Rellenar los datos de autenticación adecuados

El administrador habilita el inicio de sesión único con formularios al realizar losiguiente:v Crear un archivo de configuración para especificar cómo se debe reconocer,

completar y procesar el formulario de inicio de sesiónv Habilitar el inicio de sesión único con formularios configurando la conexión

(junction) adecuada con la opción –S (que especifica la ubicación del archivo deconfiguración)

Flujo de proceso de inicio de sesión único con formulariosEn el siguiente escenario se supone que WebSEAL ya ha autenticado al usuario.

1. El navegador del cliente solicita la siguiente página:https://webseal/formsso/content.html

2. WebSEAL pasa la petición a la conexión (junction).3. Dado que la aplicación de fondo requiere la autenticación del usuario, la

redirección de la página de inicio de sesión de la aplicación (login.html) sedevuelve a través de la conexión (junction).

Figura 44. Flujo de proceso de inicio de sesión único con formularios


4. WebSEAL pasa la redirección al navegador.5. El navegador sigue la redirección y solicita:

https://webseal/formsso/login.html

Nota: Hasta este punto, todos los elementos del flujo de proceso correspondena la funcionalidad estándar de WebSEAL.

6. WebSEAL se ha configurado para el inicio de sesión único con formularios(opción –S en la conexión (junction)). WebSEAL reconoce la petición como unapetición de página de inicio de sesión, basándose en la información quecontiene el archivo de configuración SSO de formularios. La petición se pasa ala conexión (junction). WebSEAL guarda todas las cookies enviadas por elnavegador para utilizarlas en el paso 8.

7. La aplicación devuelve la página de inicio de sesión y, posiblemente, lascookies específicas de la aplicación.WebSEAL analiza el código HTML devuelto para identificar el formulario deinicio de sesión. Cuando WebSEAL encuentra un formulario HTML en eldocumento, compara el URI de acción del formulario con el valor delparámetro login-form-action del archivo de configuración personalizado. Sihay una coincidencia, WebSEAL utiliza el formulario que ha encontrado. De locontrario, WebSEAL sigue buscando otros formularios. Si ninguno de losformularios de la página coincide con el patrón de URI de acción del archivode configuración, WebSEAL anula el proceso de inicio de sesión único conformularios y devuelve un error al navegador.WebSEAL analiza la página HTML para identificar el método de petición, elURI de acción y cualquier otro campo de entrada del formulario, y los guardapara utilizarlos en el paso 8.

8. WebSEAL genera la petición de autenticación (completa el formulario de iniciode sesión) y la envía a la aplicación de fondo.

9. La aplicación efectúa la autenticación utilizando los datos de autenticaciónproporcionados por WebSEAL en el formulario. La aplicación devuelve laredirección a content.html.

10. WebSEAL combina las cookies guardadas de las respuestas de los pasos 7 y 9y devuelve dichas cookies con la redirección al navegador.

Nota: Así se completa la funcionalidad específica de SSO de formularios.11. El navegador sigue la redirección y solicita:

https://webseal/formsso/content.html

12. WebSEAL pasa la petición a la aplicación de fondo a través de la conexión(junction).

Durante este proceso, el navegador efectúa tres peticiones a WebSEAL. Desde laperspectiva del usuario, sólo se efectúa una sola petición dehttps://webseal/formsso/content.html. Las otras peticiones se producenautomáticamente a través de redirecciones HTTP.

Requisitos para el soporte de aplicacionesEl inicio de sesión único para la autenticación de formularios está soportado en lasaplicaciones que cumplen los requisitos siguientes:1. La página o páginas de inicio de sesión de la aplicación deben identificarse de

manera exclusiva a través de una sola expresión regular o de varias expresionesregulares.


2. La página de inicio de sesión puede incluir más de un formulario HTML. Noobstante, el formulario de inicio de sesión debe identificarse aplicando unaexpresión regular a los URI de acción de cada uno de los formularios de iniciode sesión, o el formulario de inicio de sesión es el primero de la página deinicio de sesión. Tenga en cuenta que si se utiliza el atributo “action” paraidentificar el formulario de inicio de sesión, el atributo “action” no se habrápasado a través del filtrado HTML de WebSEAL. La expresión regular debecoincidir con el URI de acción antes de aplicar el filtro.

3. Puede utilizarse un script del cliente para validar los datos de entrada, pero nodebe modificar dichos datos. Esto incluye el uso de Javascript para establecercookies en el navegador del usuario.

4. Los datos de inicio de sesión sólo se someten en un punto del proceso deautenticación.

5. La conexión (junction) a la que se dirige la petición de autenticación debe ser lamisma conexión (junction) en la que se devuelve la página de inicio de sesión.

Creación del archivo de configuración para el inicio de sesiónúnico con formularios

El administrador crea de forma personalizada el archivo de configuración de iniciode sesión único con formularios y lo guarda en cualquier ubicación. La opción –Sen la conexión (junction) habilita la funcionalidad de inicio de sesión único conformularios y especifica la ubicación del archivo de configuración. Consulte elapartado “Habilitación del inicio de sesión único con formularios” en la página208. Un archivo de configuración de ejemplo (que contiene instruccionescomentadas) se proporciona con la instalación de WebSEAL y se ubica en eldirectorio siguiente:

UNIX:/opt/pdweb/etc/fsso.conf.template

Windows:C:\Archivos de programa\Tivoli\PDWeb\etc\fsso.conf.template

El archivo de configuración debe empezar con la stanza [forms-sso-login-pages] ytiene el formato siguiente[forms-sso-login-pages]login-page-stanza = <xxxxx>#login-page-stanza = <aaaaa>#login-page-stanza = <bbbbb>

[<xxxxx>]login-page = <coinc-página-expresión-regular>login-form-action = <coinc-formulario-expresión-regular>gso-resource = <destino-gso>argument-stanza = <yyyyy>

[<yyyyy>]<nombre> = <método>:<valor>

La stanza [forms-sso-login-pages]El archivo de configuración de inicio de sesión único con formularios debeempezar siempre con la stanza [forms-sso-login-pages]. La stanza contiene una omás entradas login-page-stanza que apuntan a otras stanzas con denominaciónpersonalizada que contienen información de configuración para las páginas deinicio de sesión que se encuentran en el servidor de aplicaciones de fondo.


La capacidad de dar soporte a múltiples páginas de inicio de sesión en una solaconexión (junction) es importante porque un solo servidor de fondo puede alojarvarias aplicaciones y cada una de éstas utiliza un método de autenticacióndiferente.

Por ejemplo:[forms-sso-login-pages]login-page-stanza = loginpage1login-page-stanza = loginpage2

La stanza de página de inicio de sesión personalizadaCada stanza de página de inicio de sesión personalizada se utiliza para interceptarun patrón de dirección URL determinado. La stanza puede contener los siguientesparámetros:


login-page Este parámetro especifica un patrón, utilizando una expresiónregular, que identifica de forma exclusiva las peticiones de unapágina de inicio de sesión de una aplicación. WebSEAL interceptaestas páginas e inicia el proceso de inicio de sesión único conformularios. La expresión regular se compara con el URI depetición y es relativa al punto de conexión (junction) (sin incluirlo)donde está montado el servidor.

login-form-action Este parámetro especifica un patrón, utilizando una expresiónregular, que identifica qué formulario incluido en la páginainterceptada es el formulario de inicio de sesión de la aplicación. Sisólo hay un formulario en la página, o si el formulario de inicio desesión es el primero del documento, la expresión puede ser “*”. Delo contrario, la expresión regular debe coincidir con el atributo“action” del formulario de inicio de sesión.

gso-resource Este parámetro especifica el recurso GSO que se ha de utilizar alrecuperar el nombre de usuario y la contraseña de GSO de unabase de datos de GSO. Deje en blanco este parámetro si no seutiliza GSO para almacenar un nombre de usuario y contraseña deGSO.

argument-stanza Este parámetro apunta a otra stanza personalizada que lista loscampos y los datos necesarios para completar el formulario deinicio de sesión.

Por ejemplo:[loginpage1]login-page = /cgi-bin/getloginpage*login-form-action = *gso-resource =argument-stanza = form1-data

Acerca del parámetro login-page:

El valor del parámetro login-page es una expresión regular que WebSEAL utilizapara determinar si una petición entrante es en realidad una petición de una páginade inicio de sesión. En caso afirmativo, WebSEAL intercepta esta petición e inicia elproceso de inicio de sesión único con formularios.

Sólo se permite un parámetro login-page en cada stanza de página de inicio desesión personalizada. Debe crear una stanza de página de inicio de sesiónpersonalizada para cada parámetro login-page adicional.


La expresión regular login-page se compara con el URI de petición, que es relativoa la conexión (junction). En el ejemplo siguiente, el URI de una petición a unservidor WebSEAL denominado “websealA” para un recurso en una conexión(junction) denominada “junctionX” puede tener el siguiente aspecto:https://websealA.ibm.com/junctionX/auth/login.html

La parte de esta dirección URL que se compara con la expresión regularlogin-page es:/auth/login.html

Acerca del parámetro login-form-action:

El parámetro login-form-action se utiliza para identificar el formulario de inicio desesión en la página interceptada. Sólo se permite un parámetro login-form-actionen cada stanza.

El valor del parámetro login-form-action es una expresión regular que se comparacon el contenido del atributo “action” del indicador “form” de HTML. El atributo“action” es un URI expresado como una ruta de acceso relativa, relativa alservidor, o absoluta. El parámetro login-form-action debe coincidir con esta rutade acceso cuando proviene del servidor de fondo, aunque en circunstanciasnormales WebSEAL no lo modificaría antes de reenviarlo al cliente.

Si varios atributos “action” en la página coinciden con la expresión regular, sólo seacepta la primera coincidencia en el formulario de inicio de sesión.

Si la expresión regular no coincide con ningún formulario en la página, sedevuelve un error al navegador en el que se informa que no se ha encontrado elformulario.

Puede establecer login-form-action = * como una manera sencilla de coincidir conel formulario de inicio de sesión cuando la página sólo incluye un formulario deinicio de sesión.

Utilización de expresiones regularesLa tabla siguiente contiene una lista de los caracteres especiales permitidos en lasexpresiones regulares que se utilizan en el archivo de configuración de inicio desesión único con formularios.

* Coinciden cero o más caracteres

? Coincide un carácter cualquiera

\ Carácter de escape (por ejemplo, \? coincide con ?)

[acd] Coincide el carácter a, c o d (sensible a mayúsculas y minúsculas)

[^acd] Coincide cualquier carácter excepto a, c o d (sensible a mayúsculasy minúsculas)

[a-z] Coincide cualquier carácter entre a y z (letras minúsculas)

[^0-9] Coincide cualquier carácter que no esté entre 0 y 9 (que no sea unnúmero)

[a-zA-Z] Coincide cualquier carácter entre a y z (letras minúsculas) o A y Z(letras mayúsculas)

En la mayoría de los casos, no son necesarios los caracteres especiales porque lapetición de la página de inicio de sesión es un URI único identificable. En algunos


casos se puede utilizar “*” al final de la expresión para que cualquier dato deconsulta situado al final del URI no impida la coincidencia de la página de iniciode sesión.

La stanza de argumentoLa stanza de argumento personalizada contiene una o más entradas en el formatosiguiente:<nombre> =<método>:<valor>

name

El valor del parámetro name se define como igual al valor del atributo “name” delindicador “input” de HTML. Por ejemplo:<input name=uid type=text>Nombreusuario</input>

Este parámetro también puede utilizar el valor del atributo “name “ de losindicadores “select” o “textarea” de HTML.

method:value

Esta combinación de parámetros recupera los datos de autenticación que necesita elformulario. Los datos de autenticación pueden incluir los siguientes:v Datos de cadena de literales

cadena:<texto>

La entrada utilizada es la cadena de texto.v Nombre de usuario y contraseña de GSO

gso:nombreusuariogso:contraseña

La entrada es el nombre de usuario y contraseña de GSO del usuario actual (deldestino especificado en la stanza de página de inicio de sesión personalizada).

v Valor de un atributo en la credencial del usuariocred:<nombre-atr-ext-cred>

De forma predeterminada, la credencial incluye información como el nombre deusuario y DN de Access Manager. Para utilizar el nombre de usuario de AccessManager del usuario como valor de entrada, especifique el valor como:cred:azn_cred_principal_name

Se puede acceder al DN del usuario como:cred:azn_cred_authzn_id

También pueden utilizarse atributos de credencial personalizados (se agreganmediante el mecanismo tag/value).

No es necesario especificar campos de entrada ocultos en esta stanza. Estos camposse recuperan automáticamente del formulario HTML y se someten con la peticiónde autenticación.

Por ejemplo:[form1-data]uid = string:brian


Habilitación del inicio de sesión único con formulariosDespués de completar el archivo de configuración de inicio de sesión único conformularios y localizar el archivo en el directorio adecuado, debe configurar laconexión (junction) adecuada para dar soporte al inicio de sesión único conformularios. Utilice la opción de conexión (junction) –S con el comando pdadmincreate:-S <ruta-acceso-archivo-config>

El argumento ruta-acceso-archivo-config especifica la ubicación del archivopersonalizado de configuración de inicio de sesión único con formularios. Laopción –S en la conexión (junction) habilita la funcionalidad de inicio de sesiónúnico con formularios en la conexión (junction).

Por ejemplo:pdadmin> server task webseald-<instancia> -t tcp -h websvrA \-S /opt/pdweb/fsso/fsso.conf /jctX

El archivo de configuración se lee cuando se crea la conexión (junction) y cada vezque se inicia WebSEAL. Los errores en el archivo de configuración puedenprovocar que WebSEAL falle durante el inicio.

Ejemplo de archivo de configuración para IBM HelpNowEl sitio IBM HelpNow invoca su propio inicio de sesión basado en formularios y,por consiguiente, es un ejemplo de cómo una solución de inicio de sesión únicocon formularios puede proporcionar un acceso sin fisuras al sitio para sus usuariosinscritos.

Esta sección contiene:v Una sección de formularios, similar al formulario enviado en la página de inicio

de sesión HTML devuelta por la aplicación HelpNowv El archivo personalizado de configuración de inicio de sesión único con

formularios que se utiliza para procesar este formulario

El formulario que se ha encontrado en la página HTML interceptada:<form name="confirm" method="post" action="../files/wcls_hnb_welcomePage2.cgi"><p>Número de serie de empleado: <input name="data" size="10" maxlength="6"><p>Nombre de país:<select name="Cntselect" size="1"><OPTION value="notselected" selected>Seleccionar país</OPTION><OPTION value=675>Emiratos Árabes Unidos - IBM</OPTION><OPTION value=866>Reino Unido</OPTION><OPTION value=897>Estados Unidos</OPTION><OPTION value=869>Uruguay</OPTION><OPTION value=871>Venezuela</OPTION><OPTION value=852>Vietnam</OPTION><OPTION value=707>Yugoslavia</OPTION><OPTION value=825>Zimbabwe</OPTION></select><p><input type=submit value=Enviar></form>

El archivo de configuración personalizado que se ha utilizado para procesar esteformulario:


Configuración FSSO de helpnow:

[forms-sso-login-pages]login-page-stanza = helpnow

[helpnow]# El sitio HelpNow le redirige a esta página en# la que tiene que iniciar la sesión.login-page = /bluebase/bin/files/wcls_hnb_welcomePage1.cgi

# El formulario de inicio de sesión es el primero de la página,# de modo que podemos llamarlo simplemente# ’*’.login-form-action = *

# El recurso GSO, helpnow, contiene el número de serie de los empleados.gso-resource = helpnow

# Siguen los argumentos de autenticación.argument-stanza = auth-data

[auth-data]# El campo ’data’ contiene el número de serie de los empleados.data = gso:username

# El campo Cntselect contiene un número que corresponde al# país de origen del empleado. La cadena “897” corresponde a Estados Unidos.Cntselect = string:897


Capítulo 9. Integración de aplicaciones

WebSEAL da soporte a la integración de aplicaciones de terceros a través de lasvariables de entorno y a la posibilidad de direcciones URL dinámicas. WebSEALamplía el rango de variables de entorno y cabeceras HTTP para hacer posible quelas aplicaciones de terceros realicen operaciones basadas en la identidad de uncliente. Además, WebSEAL puede proporcionar el control de acceso en lasdirecciones URL dinámicas, como las que contienen el texto de la consulta.

Índice de temas:v “Soporte para la programación de CGI” en la página 211v “Soporte para aplicaciones del servidor de fondo” en la página 213v “Mejores prácticas de conexión (junction) para la integración de aplicaciones” en

la página 213v “Creación de un servicio de personalización personalizado” en la página 215v “Habilitación de autorizaciones empresariales dinámicas (señal/valor)” en la

página 217v “Mantenimiento del estado de la sesión entre las aplicaciones clientes y de

fondo” en la página 220v “Especificación del control de acceso a las direcciones URL dinámicas” en la

página 223v “Ejemplo de dirección URL dinámica: Travel Kingdom” en la página 229

Soporte para la programación de CGIPara dar soporte a la programación de CGI, WebSEAL agrega tres variables deentorno adicionales al conjunto de variables CGI estándar. Las aplicaciones CGIque se ejecuten en el servidor WebSEAL local o bien en un servidor de fondo conconexión (junction) pueden utilizar estas variables de entorno. Las variablesproporcionan información de usuario, grupo y credencial específica de AccessManager para la aplicación CGI.

En un servidor WebSEAL local, estas variables de entorno están disponiblesautomáticamente para los programas CGI.

Las variables de entorno utilizadas por una aplicación CGI que se ejecute en unservidor de terceros con conexión (junction) se producen desde la información decabecera HTTP pasada al servidor desde WebSEAL. Debe utilizar la opción –c paracrear una conexión (junction) que dé soporte a la información de cabeceraespecífica de Access Manager en las peticiones HTTP destinadas a un servidor defondo.

Consulte también el apartado “Especificación de la identidad del cliente encabeceras HTTP (–c)” en la página 177.

Variables de entorno adicionales específicas de Access Manager:

Variables de entorno de CGI Descripción

HTTP_IV_USER Nombre de cuenta de usuario de Access Manager delsolicitante.


Variables de entorno de CGI Descripción

HTTP_IV_GROUPS Grupos de Access Manager a los que pertenece elsolicitante. Especificados como lista de grupos separadospor comas, cada grupo se especifica entre comillas.

HTTP_IV_CREDS Estructura de datos opacos codificados que representanuna credencial de Access Manager. Proporcionacredenciales para servidores remotos para que lasaplicaciones de medio nivel puedan utilizar la API deautorización para llamar al servicio de autorizaciones.Consulte la publicación IBM Tivoli Access ManagerAuthorization C API Developer’s Reference.

Variable REMOTE_USER en un servidor WebSEAL local:

En un entorno de servidor local controlado por WebSEAL, el valor de la variableHTTP_IV_USER listado anteriormente se incluye como valor para la variableREMOTE_USER estándar. Observe que la variable REMOTE_USER puede estartambién presente en el entorno de una aplicación CGI que se ejecute en unservidor de fondo con conexión (junction). Sin embargo, en esta situación,WebSEAL no controla su valor.

Variable de entorno deCGI

Descripción

REMOTE_USER Contiene el mismo valor que el campo HTTP_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 entorno del sistema adisposición de procesos como las aplicaciones CGI. Habitualmente, las variables deentorno del sistema necesarias estarán presentes.

Sin embargo, si no se encuentra alguna de las variables de entorno del sistema deWindows que necesite en el entorno de CGI, puede ponerlas explícitamente adisposición de los programas CGI a través del archivo de configuraciónwebseald.conf. (Observe que las variables de entorno de Access Managermencionadas en el apartado anterior están disponibles automáticamente en todaslas plataformas).

Agregue las variables de entorno del sistema de Windows necesarias en la stanza[cgi-environment-variables] del archivo de configuración webseald.conf. Utilice elsiguiente 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 un entorno de CGI.

Soporte para aplicaciones del servidor de fondoWebSEAL proporciona también soporte para el código ejecutable que se ejecutacomo componente incrustado de un servidor web de fondo. Entre los ejemplos decódigo ejecutable de servidor se incluyen:v Servlets Javav Cartuchos para Oracle Web Listenerv Plug-ins de servidor

Al crear una conexión (junction) con un servidor de fondo que utilice la opción –c,WebSEAL inserta información específica de pertenencia a grupos y de identidad decliente de Access Manager en las cabeceras HTTP de las peticiones destinadas a eseservidor.

La información de cabecera HTTP específica para Access Manager habilita lasaplicaciones de servidores de terceros con conexión (junction) para realizaracciones específicas del usuario basadas en la identidad de Access Manager delcliente.

WebSEAL proporciona las siguientes cabeceras HTTP específicas para AccessManager:

Campos de cabeceraHTTP específicos de

PD

Descripción

iv-user = Nombre corto o largo del cliente. El valor predeterminado es“Unauthenticated” si el cliente no está autenticado (desconocido).

iv-groups = Lista de grupos a los que pertenece el cliente. Especificada comolista separada por comas de grupos especificados entre comillas.

iv-creds = Estructura de datos opacos codificados que representan unacredencial de Access Manager. Proporciona credenciales paraservidores remotos para que las aplicaciones de medio nivelpuedan utilizar la API de autorización para llamar al servicio deautorizaciones. Consulte la publicación IBM Tivoli Access ManagerAuthorization C API Developer’s Reference.

Estas cabeceras HTTP están disponibles para las aplicaciones CGI como variablesde entorno HTTP_IV_USER, HTTP_IV_GROUPS y HTTP_IV_CREDS. Si deseainformación sobre otros entornos de aplicaciones que no son CGI, consulte ladocumentación asociada al producto para obtener instrucciones acerca de laextracción de cabeceras de peticiones HTTP.

Consulte también el apartado “Especificación de la identidad del cliente encabeceras HTTP (–c)” en la página 177.

Mejores prácticas de conexión (junction) para la integración deaplicaciones

Este apartado contiene recomendaciones de “mejores prácticas” al utilizarconexiones (junctions) WebSEAL.v “Información completa de cabecera HOST con -v” en la página 214

Capítulo 9. Integración de aplicaciones 213

v “Soporte para el filtrado de las direcciones URL absolutas estándar” en la página214

Información completa de cabecera HOST con -vLas configuraciones de host virtual y las aplicaciones de portal requieren que seproporcione información correcta de dirección IP para las conexiones de socketadecuadas e información completa de nombre de servidor para realizar undireccionamiento correcto.

Estos servicios especiales de aplicaciones de fondo requieren de los navegadoresuna información completa de nombre de servidor y de designación de puerto. Lacabecera HOST de una petición contiene esta información y hace que estédisponible para la aplicación. Al utilizar conexiones (junctions) WebSEAL, estainformación se proporciona a la cabecera HOST a través del uso de la opción deconexión (junction) –v.

Si falta la información de nombre de servidor y puerto, o es insuficiente,empeorará el rendimiento de las aplicaciones de host virtual y de portal. Además,es posible que las cookies de dominio establecidas por estas aplicaciones nocontengan información suficiente.

Para proporcionar la información más completa en la cabecera HOST, larecomendación de “,mejor práctica” es que se utilice siempre el nombre dedominio completo del servidor con conexión (junction) y el número de puerto deconexión en la opción –v al crear o agregar la conexión (junction).

La opción –v utiliza la siguiente sintaxis:-v <nombre-host-completo>[:<puerto>]

Por ejemplo:-v xyz.ibm.com:7001

Nota: La designación de puerto sólo debe proporcionarse si se utiliza un númerode puerto no estándar.

Soporte para el filtrado de las direcciones URL absolutasestándar

WebSEAL, como proxy inverso frontal, proporciona servicios de seguridad a losservidores de aplicación con conexión (junction) de fondo. Las páginas devueltas alcliente desde aplicaciones de fondo suelen contener vínculos de direcciones URL arecursos que están situados en el servidor con conexión (junction) de fondo.

Es importante que estos vínculos incluyan el nombre de conexión (junction) paradirigir correctamente las peticiones de vuelta a las ubicaciones correctas de losrecursos. WebSEAL utiliza un conjunto de reglas estándar para filtrar lasdirecciones URL estáticas y proporcionar esta información de conexión (junction).Se necesita realizar una configuración adicional para filtrar las direcciones URL enlos scripts y en las direcciones URL generadas dinámicamente. Para obtenerinformación detallada sobre el filtrado de direcciones URL, consulte “Modificaciónde las direcciones URL de recursos de fondo” en la página 169.

La capacidad de WebSEAL de filtrar correctamente las direcciones URL absolutasde páginas HTML estáticas requiere información acerca del nombre de servidor,que se proporciona en la opción de conexión (junction) –h. Esta opción proporciona


a WebSEAL el nombre del servidor con conexión (junction) de fondo. Entre losargumentos de esta opción pueden estar los siguientes:v Nombre de dominio completo del servidorv Nombre corto del servidorv Dirección IP del servidor

WebSEAL identifica las direcciones URL absolutas para filtrarlos según suinformación del nombre de servidor con conexión (junction) de fondo.Dependiendo del entorno de red del usuario, es posible que la configuración–h<nombre-corto> no proporcione información suficiente a WebSEAL.

En el ejemplo siguiente se crea una conexión (junction) utilizando la opción y elargumento siguientes para un servidor de fondo que se encuentra en la redibm.com, con el nombre corto “xyz”:-h xyz

Un vínculo en una página HTML de este servidor tiene el aspecto siguiente:http://xyz.ibm.com/doc/release-notes.html

Cuando esta página pasa al cliente durante una petición, es posible que WebSEALno filtre esta dirección URL porque, según la información proporcionada por –hnoha podido reconocer “xyz.ibm.com” como nombre del servidor. Sin el nombre deconexión (junction) en la ruta de acceso, las peticiones del documento de notas delrelease fallarán.

Para dar soporte al filtrado correcto de las direcciones URL absolutas estáticas, larecomendación de “,mejor práctica” es que se utilice siempre el nombre dedominio completo del servidor con conexión (junction) en la opción –h al crear oagregar la conexión (junction).

Creación de un servicio de personalización personalizadoUn portal web, o página de inicio, es un servicio de sitio web integrado queproduce de forma dinámica una lista personalizada de los recursos webdisponibles para un usuario determinado. Los recursos pueden incluir contenidoscorporativos, servicios de soporte y herramientas de aprendizaje. La salida delportal representa una lista personalizada de recursos a partir de los permisos deacceso del usuario concreto. La página de inicio presenta sólo aquellos recursosque tengan los permisos de acceso correctos para dicho usuario.

Puede utilizar las opciones de configuración de WebSEAL y el servicio deautorizaciones de API de autorización para crear una solución de portalpersonalizada en un entorno Access Manager.

El flujo de proceso para crear un servicio de portal WebSEAL personalizadoincluye los siguientes elementos:1. Se crea una región específica del espacio de objetos protegidos para localizar el

conjunto de objetos de recursos de portal.2. Las ACL explícitas correspondientes se asocian con cada uno de estos objetos

de recursos.3. Se edita el archivo de configuración de WebSEAL para incluir la dirección URL

del servicio del portal, la ruta de acceso del espacio de objetos que contiene losrecursos del portal y el bit de permiso que necesita el usuario para acceder aestos recursos.


4. Para cada petición de usuario a la dirección URL del portal, WebSEAL utiliza elServicio de derechos de autorización para buscar este espacio de objetos yproducir una lista de recursos que cumplan las condiciones de autorización deeste usuario.

5. WebSEAL coloca esta información enuna cabecera HTTP PD_PORTAL que seenvía al servidor de fondo del portal con conexión (junction).

6. El servicio de portal personalizado (por ejemplo, un CGI o un servlet) que seencuentra en el servidor de fondo lee el contenido de la cabecera PD_PORTALy, por ejemplo, correlaciona el contenido con descripciones y vínculos dedirecciones URL que se muestran al usuario en la página web. Esta informaciónrepresenta la lista personalizada de recursos disponibles para el usuario, apartir de los 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 de personalización.Por ejemplo:pdadmin>server task <nombre-servidor> create -t tcp -hportalhost.abc.com \/portal-jct

2. Edite el archivo de configuración webseald.conf para agregar una nueva stanza[portal-map]:[portal-map]

3. La entrada en esta stanza identifica la dirección URL relativa al servidor delprograma de servicios del portal y la región del espacio de objetos donde sebuscan los recursos de portal protegidos disponibles, seguido del permisonecesario para el acceso. 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 de recurso con ACLdefinidas explícitamente que contengan el permiso correspondiente paraeste usuario.

4. Después de agregar la stanza y las entradas de correlación adecuadas, se debereiniciar WebSEAL (webseald).

Ejemplo de servicio de personalizaciónv Cree una conexión (junction) en el servidor de portal:

pdadmin> server task webseald-WS1 -t ssl -h PORTAL1 /portal

v Defina la región del espacio de objetos protegidos de WebSEAL que contiene losrecursos disponibles para el servicio de personalización:pdadmin> objectspace create /Resources “Portal Object Hierarchy” 10pdadmin> object create /Resources/Content ““ 10 ispolicyattachable yespdadmin> object create /Resources/Support ““ 10 ispolicyattachable yespdadmin> object create /Resources/Content/CGI ““ 11 ispolicyattachable yespdadmin> object create /Resources/Support/Servlet ““ 11 ispolicyattachable yes

Nota: El argumento “ispolicyattachable” debe definirse como “yes” para cadauno de los recursos. El mecanismo de búsqueda sólo selecciona objetos derecursos cualificados con ACL definidas explícitamente.

v Configuración de WebSEAL (webseald.conf):


[portal-map]/portal/servlet/PortalServlet = /Resources:r

v Dirección URL del portal que utiliza el usuario:https://WS1/portal/servlet/PortalServlet

Habilitación de autorizaciones empresariales dinámicas (señal/valor)Las empresas y sus socios a menudo deben compartir derechos comunes como, porejemplo, datos de socios (en las relaciones de empresa a empresa) o datos declientes (en las relaciones de empresa a cliente).v Los Derechos genéricos son atributos que describen la información que

necesitan las aplicaciones proveedoras de servicios. Por ejemplo, la informaciónde la cuenta de cliente y los datos de facturación del cliente.

v Los Derechos de seguridad son atributos que proporcionan condiciones muydetalladas que se utilizan en la autorización de las peticiones de recursos.Ejemplos de estas condiciones son las reglas empresariales de los usuarios, lasrestricciones del control de accesos y las reglas empresariales que definen uncontrato comercial entre socios.

Mediante una extensión del Servicio de autenticaciones en dominios cruzados(CDAS), Access Manager proporciona un mecanismo flexible que le permite incluirinformación de autorizaciones en credenciales de usuario en el punto deautenticación. Las aplicaciones pueden extraer estos datos directamente de lacredencial utilizando la API de autorización. Para obtener más información sobre laimplementación de esta extensión CDAS, consulte la publicación IBM Tivoli AccessManager WebSEAL Developer’s Reference.

Creación de autorizaciones empresariales a partir de datosLDAP

WebSEAL incorpora un mecanismo de autorizaciones específico que permiteinsertar información LDAP suplementaria definida por el usuario en unacredencial de usuario como datos de atributos ampliados. A continuación, losvalores de estos atributos de credencial ampliados se pueden colocar en la cabeceraHTTP de una petición enviada a un servidor de aplicaciones de fondo a través dela conexión (junction).

El siguiente flujo de proceso describe la secuencia de eventos:v Los datos suplementarios, definidos por el usuario, de cualquier campo de una

cuenta de registro LDAP de usuario se agregan como datos de atributosampliados a la credencial de Access Manager del usuario.

v WebSEAL está configurado para extraer estos datos de la credencial y colocarlosen una cabecera HTTP de la petición que va al servidor de fondo.

v La aplicación de fondo puede extraer los datos de la cabecera sin necesidad deningún código especial ni la API de autorización.

La configuración de WebSEAL para insertar información LDAP suplementaria enuna cabecera HTTP implica dos pasos:1. Recuperar los datos suplementarios del registro LDAP e insertarlos en la

credencial de usuario en el inicio de sesión.2. Basado en el conjunto de atributos ampliados en la conexión (junction)

(HTTP-Tag-Value), extraer los datos adecuados de la credencial e insertarlos enla cabecera HTTP de la petición que se envía a través de la conexión (junction).


Inserción de datos LDAP suplementarios en una credencialHay dos métodos para colocar datos de usuario LDAP suplementarios en unacredencial:1. Crear entradas en la stanza [ldap-ext-cred-tags] del archivo de configuración

pd.conf que correlaciona datos LDAP específicos con atributos ampliados de lacredencial.Este método se describe en este apartado.

2. Escribir un módulo CDAS personalizado que correlacione los datos definidospor el usuario con los atributos ampliados de la credencial.Consulte la publicación IBM Tivoli Access Manager WebSEAL Developer’sReference para obtener información sobre cómo implementar esta ampliación deCDAS.

La stanza [ldap-ext-cred-tags] del archivo de configuración pd.conf se utiliza paracorrelacionar datos específicos de la clase de objeto LDAP inetOrgPerson con unatributo ampliado definido por el usuario de la credencial del usuario. Losparámetros de esta stanza tienen el siguiente formato:<nombre-atr-ampl-cred> =<nombre-inetOrgPerson>

En la misma credencial, cada entrada de nombre-atr-ampl-cred definida en el archivode configuración pd.conf tiene un prefijo con la expresión “tagvalue_”. Este prefijoimpide que haya conflictos con la otra información existente en la credencial. Porejemplo:

Nombre y valor de laclase de objeto inetOrgPerson:

employeeNumber:09876

Nombre del atributo ampliado de lacredencial:

ldap-employee-number

Asocia el nombre de atributo conel nombre de datos LDAP de lastanza [ldap-ext-cred-tags]:

ldap-employee-number = employeeNumber

Nombre y valor de atributo tal comoaparecen en la credencial de usuario:

tagvalue_ldap-employee-number:09876

v Esta funcionalidad requiere que el usuario se autentique mediante un nombre deusuario y una contraseña de LDAP. El mecanismo de autenticación passwd-ldapdebe estar habilitado. La biblioteca compartida libldapauthn (ldapauthn) estácodificada para realizar búsquedas en la stanza [ldap-ext-cred-tags] del archivode configuración pd.conf, para obtener información suplementaria de lacredencial definida por el usuario.

v Los datos LDAP pueden provenir de un campo estándar o personalizado en laclase de objeto inetOrgPerson.

v Pueden colocarse varias entradas en la stanza [ldap-ext-cred-tags].v Todos los atributos ampliados especificados en las entradas de la stanza se

colocan en la credencial durante el inicio de sesión del usuario.v Los nombres de los datos LDAP no son sensibles a mayúsculas y minúsculas.v Los nombres de los atributos ampliados de credencial son sensibles a

mayúsculas y minúsculas.


Inserción de datos de credenciales en la cabecera HTTPLa información de credencial definida por el usuario que se ha creado en elapartado anterior se puede colocar en una cabecera HTTP de la petición que seenvía a través de una conexión (junction) a un servidor de fondo.

Debe configurar la conexión (junction) para extraer los datos de atributosampliados de la credencial e insertarlos en la cabecera HTTP de la petición. Estafunción se consigue definiendo un atributo ampliado de conexión (junction),denominado HTTP-Tag-Value, en el objeto de conexión (junction) del espacio deobjetos protegidos de WebSEAL.

Utilice el comando pdadmin object modify set attribute para definir atributosampliados en un objeto de conexión (junction) del espacio de objetos protegidos deWebSEAL.pdadmin> object modify <nombre-obj> set attribute <nombre-atr> <valor-atr>

Un atributo ampliado (“nombre-atr”) habilita la conexión (junction) para realizar untipo específico de función. El atributo ampliado HTTP-Tag-Value indica a laconexión (junction) que extraiga un valor determinado de una credencial deusuario y envíe el valor al servidor de fondo en una cabecera HTTP. El valor delatributo ampliado HTTP-Tag-Value utiliza el siguiente formato:<nombre-atr-ampl-cred>=<nombre-cabecera-http>

La entrada nombre-atr-ampl-cred aparece exactamente tal como lo hace en la stanza[ldap-ext-cred-tags] del archivo de configuración pd.conf. El prefijo “tagvalue_”,que aparece en la credencial, no se utiliza. La entrada es sensible a mayúsculas yminúsculas. La entrada nombre-cabecera-http especifica el nombre de la cabeceraHTTP que se ha utilizado para transmitir los datos a través de la conexión(junction).

Por ejemplo:pdadmin> object modify /WebSEAL/WS1/junctionA set attribute \HTTP-Tag-Value ldap-employee-number=employee-id

Cuando WebSEAL procesa una petición de usuario para un servidor deaplicaciones de fondo, busca si hay algún atributo HTTP-Tag-Value configurado enel objeto de conexión (junction).

En este ejemplo, la conexión (junction) configurada busca la credencial del usuarioque ha efectuado la petición, extrae el valor del atributo ampliado de credencialtagvalue_ldap-employee-number y lo coloca en una cabecera HTTP como:employee-id:09876

En resumen:

Valor del atributo HTTP-Tag-Valuedefinido en el objeto de conexión (junction):

ldap-employee-number=employee-id


tagvalue_ldap-employee-number:09876

Nombre y valor de la cabecera HTTP: employee-id:09876

Si la aplicación de fondo es una aplicación CGI, la especificación CGI establece quelas cabeceras HTTP estén disponibles para los programas CGI como variables deentorno con el formato:


HTTP_<nombre-cabecera-http>

Por ejemplo:HTTP_employee-id=09876

Se pueden pasar múltiples datos de atributos de usuario al servidor con conexión(junction) utilizando varios comandos pdadmin object modify set attribute paraespecificar múltiples atributos de conexión (junction) HTTP-Tag-Value (seespecifica un atributo por comando).

Mantenimiento del estado de la sesión entre las aplicaciones clientesy de fondo

WebSEAL puede mantener el estado de la sesión con los clientes a través de HTTPy HTTPS. Además, puede configurar WebSEAL para proporcionar información desesión de usuario a los servidores de aplicación con conexión (junction) de fondo.Con esta información de la sesión de usuario, las aplicaciones de fondo puedenmantener el estado de la sesión con los clientes.

Información sobre la gestión de la sesión de usuarioUna conexión o sesión segura entre un cliente y un servidor requiere que elservidor tenga la posibilidad de recordar, a través de numerosas peticiones, conquién está hablando. El servidor debe tener algún tipo de información de estadode la sesión que identifique al cliente asociado con cada petición.

Sin un estado de la sesión establecido entre el cliente y el servidor, la comunicaciónentre el cliente y el servidor se debe renegociar para cada petición posterior. Lainformación sobre el estado de la sesión mejora el rendimiento, ya que evita tenerque cerrar y volver a abrir repetidamente las conexiones entre cliente y servidor. Elcliente puede iniciar la sesión una vez y realizar numerosas peticiones sin realizarun inicio de sesión distinto para cada petición.

WebSEAL mantiene información del estado de la sesión a través de la caché de IDde sesión SSL de GSKit y la caché de sesión/credenciales de WebSEAL. La cachéde sesión de GSKit da soporte a la comunicación HTTPS (SSL) cuando se utiliza elID de sesión SSL para mantener el estado de la sesión. La caché de credenciales deWebSEAL almacena un ID de sesión de WebSEAL para cada cliente, más cualquierinformación de credencial que sea específica de cada cliente.

Puede configurar WebSEAL para almacenar un ID de sesión de usuario exclusivopara cada cliente que efectúa la autenticación como un atributo ampliado de lacredencial de cada cliente. Utilizando atributos ampliados para objetos de AccessManager, puede configurar una conexión (junction) para proporcionar estainformación de ID de sesión de usuario al servidor de fondo. Una aplicación eneste servidor de fondo puede aprovechar la información de sesión de usuario paragestionar la interacción cliente-servidor, tal como el seguimiento de la actividad delos usuarios.

Habilitación de la gestión de ID de sesión de usuarioEl parámetro user-session-ids de la stanza [session] del archivo de configuraciónwebseald.conf permite habilitar e inhabilitar la creación de un ID de sesión deusuario exclusivo en la credencial de cada cliente que efectúa una petición. El valorpredeterminado es “yes” (habilitado):


[session]user-session-ids = yes

El ID de sesión de usuario exclusivo se almacena en una credencial de usuariocomo un atributo ampliado con un nombre y un valor:tagvalue_user_session_id = <id-sesión-usuario>

En la misma credencial, el nombre de atributo ampliado de credencial(user_session_id) aparece con el prefijo “tagvalue_” para evitar cualquier conflictocon otras informaciones existentes en la credencial.

El valor del ID de sesión de usuario es una cadena que identifica de formaexclusiva una sesión específica para un usuario autenticado. El ID de sesión deusuario es una cadena codificada MIME-64 que incluye el nombre de la instanciade WebSEAL (para dar soporte a múltiples instancias de WebSEAL) y el ID desesión estándar de WebSEAL para el usuario.

Un solo usuario que inicie una sesión varias veces (por ejemplo, desde máquinasdistintas) tiene múltiples ID de sesión de WebSEAL. Dado que el ID de sesión deusuario se basa en el ID de sesión de WebSEAL, hay una correlación de uno a unoentre ambos. El ID de sesión de usuario exclusivo se almacena en la credencial deusuario como un atributo. Esto permite que se pase el valor a través de unaconexión (junction) como una cabecera HTTP (utilizando la funcionalidad de valorde señal) y que quede disponible para una aplicación de fondo.

Inserción de datos de credenciales en la cabecera HTTPEl objetivo de la gestión de sesiones de usuario consiste en proporcionar el ID desesión de usuario exclusivo al servidor de aplicaciones de fondo. Este objetivo seconsigue configurando el atributo ampliado HTTP-Tag-Value en la conexión(junction).

Utilice el comando pdadmin object modify set attribute para definir un atributoampliado en un objeto de conexión (junction) del espacio de objetos protegidos deWebSEAL.pdadmin> object modify <nombre-obj> set attribute <nombre-atr> <valor-atr>

Un atributo (“nombre-atr”) habilita la conexión (junction) para realizar un tipoespecífico de función. El atributo HTTP-Tag-Value habilita la conexión (junction)para extraer un valor ampliado de credencial y enviar el valor al servidor de fondoen una cabecera HTTP.

El valor del atributo ampliado HTTP-Tag-Value utiliza el formato siguiente:<nombre-atr-ampl-cred>=<nombre-cabecera-http>

Para los datos de ID de sesión de usuario, la entrada cred-ext-attr-name es elnombre del atributo ampliado user_session_id en la credencial del usuario. Elprefijo “tagvalue_”, que sólo aparece en la credencial, no se utiliza. La entrada essensible a mayúsculas y minúsculas. El valor de este atributo ampliado contiene elID de sesión de usuario exclusivo.

La entrada nombre-cabecera-http especifica el nombre de la cabecera HTTP que se hautilizado para transmitir los datos a través de la conexión (junction).En esteejemplo, se utiliza una cabecera denominada PD-USER-SESSION-ID:pdadmin> object modify /WebSEAL/WS1/junctionA set attribute \HTTP-Tag-Value user_session_id=PD-USER-SESSION-ID


Cuando WebSEAL procesa una petición de usuario a un servidor de aplicacionesde fondo, busca cualquier atributo ampliado HTTP-Tag-Value que estéconfigurado en el objeto de conexión (junction).

En este ejemplo, la conexión (junction) configurada busca la credencial del usuarioque ha efectuado la petición, extrae el valor de ID de sesión de usuario delatributo ampliado tagvalue_user de la credencial y lo coloca en una cabeceraHTTP como:PD-USER-SESSION-ID:<id-sesión-usuario>

En resumen:

Valor del atributo HTTP-Tag-Valuedefinido en el objeto de conexión(junction):

user_session_id=PD-USER-SESSION-ID


tagvalue_user_session_id:<id-sesión-usuario>

Nombre y valor de la cabeceraHTTP:

PD-USER-SESSION-ID:<id-sesión-usuario>

Si la aplicación de fondo es una aplicación CGI, la especificación CGI establece quelas cabeceras HTTP estén disponibles para los programas CGI como variables deentorno con el formato:HTTP_<nombre-cabecera-http>

Por ejemplo:HTTP_PD-USER-SESSION-ID=<id-sesión-usuario>

Para obtener información detallada sobre las funciones de señal/valor, consulte“Habilitación de autorizaciones empresariales dinámicas (señal/valor)” en lapágina 217.

Terminación de sesiones de usuarioUn usuario puede iniciar la terminación de la sesión actual mediante el comandopkmslogout. Además, la información del ID de sesión de usuario permite a losadministradores y a las aplicaciones de fondo rastrear y gestionar usuarios. En esteapartado se describen dos métodos de terminar la sesión de usuario a nivel deadministración:v “Utilización de la API de Administración para terminar sesiones de usuario

únicas” en la página 222v “Utilización de pdadmin para terminar todas las sesiones de usuario” en la

página 223

Utilización de la API de Administración para terminar sesionesde usuario únicasUna aplicación de fondo puede utilizar la API de Administración de AccessManager para terminar una sesión de usuario específica, basándose en el ID desesión de usuario que se ha pasado a través de la conexión (junction). Laaplicación invoca la función ivadmin_server_performtask() dentro de su código determinación. La instancia de servidor WebSEAL y el ID de sesión de usuario seincluyen como parámetros de esta función.

WebSEAL verifica que el servidor de fondo que inicia la operación de terminacióntenga los permisos adecuados antes de terminar la sesión de usuario.


Consulte la publicación IBM Tivoli Access Manager Administration C API Developer’sReference para obtener más información.

Utilización de pdadmin para terminar todas las sesiones deusuarioUn administrador puede utilizar el programa de utilidad pdadmin para terminartodas las sesiones correspondientes a un usuario específico, según el ID de usuario.pdadmin> server task webseald-<nombre-instancia> terminate all_sessions <id-usuario>

La caché de credenciales de WebSEAL se organiza para realizar una referenciacruzada de ID de usuario, ID de sesión de WebSEAL e información de entrada decaché. Un usuario tiene siempre un ID de usuario exclusivo en varias sesiones. Encambio, cada ID de sesión de WebSEAL es exclusivo. El comando terminateall_sessions elimina todas las entradas de caché que pertenezcan a id-usuario.

WebSEAL comprueba que haya los permisos adecuados para el administrador queinicia el comando antes de terminar las sesiones de usuario.

Especificación del control de acceso a las direcciones URL dinámicasEl entorno web actual proporciona a los usuarios acceso inmediato a unainformación que cambia rápidamente. Muchas aplicaciones web generandinámicamente direcciones URL (Uniform Resource Locator) como respuesta a lapetición de cada usuario. Estas direcciones URL dinámicas pueden existir sólodurante un tiempo corto. A pesar de su naturaleza temporal, las direcciones URLdinámicas necesitan una gran protección contra el uso o acceso no deseado.

Componentes de dirección URL dinámicaAlgunas herramientas de aplicaciones web sofisticadas utilizan navegadores webestándar para comunicarse con servidores de aplicaciones a través de la interfazCGI de un servidor web.

Figura 45. Terminar todas las sesiones de usuarioA


Todas estas herramientas utilizan direcciones URL dinámicas como elementos deformulario ocultos para comunicar la operación solicitada (con su valor deparámetro) al servidor de aplicaciones. Una dirección URL dinámica amplía ladirección URL estándar con información acerca de la operación específica y susvalores de parámetros. El fragmento de la cadena de caracteres de consulta de ladirección URL proporciona operaciones, parámetros y valores para la interfaz deaplicaciones web.

Correlación de objetos ACL y POP con direcciones URLdinámicas

WebSEAL utiliza el modelo de espacio de objetos protegidos, las listas de controlde acceso (ACL) y las políticas de objetos protegidos (POP) para proteger lasdirecciones URL generadas dinámicamente, como los generados por las peticionesde base de datos. Cada petición a WebSEAL se resuelve en un objeto específicocomo primer paso en el proceso de autorización. Una ACL/POP aplicada al objetoestablece la protección necesaria en cualquier dirección URL dinámicacorrelacionada con ese objeto.

Puesto que las direcciones URL dinámicas sólo existen temporalmente, no esposible tener entradas para éstas en una base de datos de políticas deautorizaciones configuradas previamente. Access Manager resuelve este problemaproporcionando un mecanismo 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 archivo de texto sinformato:/opt/pdweb/www/lib/dynurl.conf

La ubicación de este archivo (relativa a la raíz de servidor) está definida por elparámetro dynurl-map en la stanza [server] del archivo de configuraciónwebseald.conf:[server]dynurl-map = lib/dynurl.conf

Debe crear este archivo, ya que no existe de forma predeterminada. La existenciade este archivo (con entradas) ofrece la posibilidad de direcciones URL dinámicas.

Edite este archivo para modificar las correlaciones. Las entradas del archivo tienenel formato:<objeto> <plantilla>

Access Manager utiliza un subconjunto de valores que cumplen patronesespecíficos de shell de UNIX (incluidos los caracteres comodín) para definir el

Figura 46. Transferencia de datos a un gateway CGI mediante una dirección URL


conjunto de parámetros que constituyen un objeto en el espacio de objetos.Cualquier dirección URL que coincida con esos parámetros se correlaciona con eseobjeto.

Access Manager da soporte a los siguientes caracteres que cumplen patronesespecíficos de shell de UNIX:

Carácter Descripción

\ El carácter que sigue a la barra inclinada invertida forma parte deuna secuencia especial. Por ejemplo, \t es el carácter TAB. Tambiénpuede actuar como carácter de escape.

? Carácter comodín que coincide con un solo carácter. Por ejemplo, lacadena de caracteres “abcde” coincide con la expresión “ab?de”

* Carácter comodín que coincide con cero o más caracteres.

[] Define un conjunto de caracteres del cual puede coincidir cualquierade los caracteres. Por ejemplo, la cadena “abcde” coincide con laexpresión regular “ab[cty]de”.

^ Indica una negación. Por ejemplo, la expresión [^ab] coincide concualquier carácter excepto los caracteres ‘a’ o ‘b’.

El ejemplo siguiente muestra el formato de una dirección URL dinámica querealiza 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 de la siguienteforma:http://<nombre-servidor>/home-bank/owa/acct.bal?acc=*

Si observamos la dirección URL dinámica de este ejemplo veremos que describe unnúmero de cuenta específico. El objeto de los balances de cuentas de home-bankmuestra que los permisos ACL y POP se aplican a cualquier cuenta, puesto que elúltimo fragmento de la entrada (acc=*) utiliza el carácter comodín asterisco, quecoincide con todos los caracteres.

La siguiente figura muestra un ejemplo completo de dirección URL dinámicaespecífica correlacionada con un objeto protegido específico:


Actualización de WebSEAL para direcciones URL dinámicasUtilice el comando dynurl update para actualizar el espacio de objetos protegidosde WebSEAL con entradas realizadas en el archivo de configuración dynurl.conf.1. Cree, modifique o elimine una entrada de dirección URL dinámica en el archivo

de configuración dynurl.conf.2. Después de efectuar los cambios, use el comando dynurl update para

actualizar el servidor:pdadmin> server task webseald-<nombre-servidor> dynurl update

El argumento nombre-servidor representa el nombre de host no cualificado de lamáquina WebSEAL.

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

La resolución de una dirección URL dinámica en un objeto depende del orden delas entradas en el archivo de configuración dynurl.conf.

Al intentar correlacionar una dirección URL dinámica con una entrada de objeto, seexplora la lista de correlaciones del archivo dynurl.conf de principio a fin hastaque se encuentra el primer patrón que coincide. Cuando se encuentra la primeracoincidencia, la entrada de objeto correspondiente se utiliza para la comprobaciónposterior de autorizaciones.

Si no se encuentra ninguna coincidencia, WebSEAL utiliza la propia dirección URL,menos el fragmento http://<servidor> de la ruta de acceso.

Mantenga las correlaciones que corresponden con las ACL más restrictivas en laparte superior de la lista. Por ejemplo, si el procedimiento book.sales de unaaplicación de pedidos de ventas se tiene que restringir a un solo grupo del club dereservas, pero todos los usuarios pueden acceder al resto de la aplicación depedidos de ventas, las correspondencias deben encontrarse en la tabla que semuestra a continuación:

Figura 47. Autorización en una dirección URL dinámica


Entrada de espacio de objetos Plantilla de dirección URL

/ows/sales/bksale /ows/db-apps/owa/book.sales*

/ows/sales/general /ows/db-apps/owa/*

Observe que si las entradas de correlaciones estuvieran en orden inverso, todos losprocedimientos almacenados en el directorio /ows/db-apps/owa se correlacionaríancon 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 con una entradade espacio de objetos, el formato de la dirección URL debería tomar el formato talcomo se produce con el método GET, independientemente de si se utiliza elmétodo POST o GET.

En el método GET de transmisión de datos, los datos dinámicos (como losproporcionados por un usuario en un formulario) se agregan a la dirección URL.

En el método POST de transmisión de datos, los datos dinámicos se incluyen en eltexto de la petición.

Evaluación de ACL y POPUna vez resuelta la dirección URL dinámica en una entrada de espacio de objetos,se utiliza el modelo de herencia de ACL/POP estándar para determinar si lapetición se debería procesar o prohibir (debido a privilegios insuficientes).

Configuración de limitaciones en las peticiones POSTEl contenido de una petición POST está incluido en el cuerpo de la petición.Además, una petición POST contiene la longitud determinada por el navegador deeste contenido y muestra el valor en bytes.

request-body-max-read

El parámetro request-body-max-read de la stanza [server] del archivo deconfiguración webseald.conf limita el impacto de peticiones POST de gran tamañoen WebSEAL, ya que especifica el número máximo de bytes que se pueden leercomo contenido en el cuerpo de las peticiones POST. El contenido que se lee enWebSEAL está sujeto a comprobaciones de autorización, tal y como se ha descritoanteriormente en este apartado.

El valor del parámetro request-body-max-read se tiene en cuenta cuando lapetición POST se utiliza en el procesamiento de direcciones URL dinámicas o laautenticación de formularios. El valor predeterminado es 4096 bytes:[server]request-body-max-read = 4096

Observe que este parámetro no limita el tamaño máximo de contenido POST (quees ilimitado). El parámetro protege a WebSEAL para que no procese una peticiónPOST de tamaño excesivo.

dynurl-allow-large-posts

Aunque el parámetro request-body-max-read limita la cantidad de contenido dePOST que WebSEAL puede leer y procesar, no impide que la petición se paseíntegramente a través del servidor de aplicaciones. En este caso, se pasa un


contenido que no se ha validado a través del servidor de aplicaciones. Si elservidor de aplicaciones no tiene sus propias posibilidades de autorización, lasituación puede suponer un riesgo de seguridad.

El parámetro dynurl-allow-large-posts permite controlar la forma en la queWebSEAL maneja las peticiones POST que tienen una longitud de contenido mayorque la especificada en request-body-max-read. Si el valor del parámetro se definecomo “no” (predeterminado), WebSEAL rechaza totalmente cualquier peticiónPOST con una longitud de contenido mayor que la especificada porrequest-body-max-read.[server]dynurl-allow-large-posts = no

Si el valor del parámetro se define como “yes”, WebSEAL acepta la petición POSTcompleta, pero sólo valida la cantidad de contenido equivalente al valorrequest-body-max-read.[server]dynurl-allow-large-posts = yes

Ejemplo 1:

v Se recibe una petición POST de gran tamaño (mayor que el valorrequest-body-max-read).

v dynurl-allow-large-posts = no

v Las direcciones URL dinámicas están habilitadas.v Resultado: 500 “Error de servidor”

Ejemplo 2:

v Se recibe una petición POST de gran tamaño (mayor que el valorpost-request-body-max-read).

v dynurl-allow-large-posts = yes

v Las direcciones URL dinámicas están habilitadas.v Resultado: WebSEAL compara la cantidad de contenido hasta el valor

request-body-max-read con cada una de las expresiones regulares del archivo deconfiguración dynurl.conf y realiza una comprobación de configuración en elobjeto correspondiente si se encuentra una coincidencia. De lo contrario, lacomprobación de autorización se realiza en el objeto que corresponde a ladirección URL recibida, como siempre. La parte del cuerpo de la peticiónpost-request-body-max-read no se valida.

v La siguiente plantilla contiene el tipo de disposición de coincidencia de patronesque crea dificultades debido a una petición POST de gran tamaño:/rtpi153/webapp/examples/HitCount\?*action=reset*

Resumen y notas técnicasResumen:

v Para configurar WebSEAL para que maneje de forma segura las direcciones URLdinámicas, se debe crear el siguiente archivo:/opt/pdweb/www/lib/dynurl.conf

v El archivo debe contener una o más líneas con el siguiente formato:<objeto> <plantilla>

v Si el archivo no existe, o está vacío, no se habilita la posibilidad de direccionesURL dinámicas.


v Después de procesarse el archivo, el nombre de objeto aparece como recurso hijoen el espacio de objetos de WebSEAL.

v La plantilla puede contener un subconjunto de los caracteres de coincidencia depatrones estándares. La plantilla también puede ser una cadena exacta sincaracteres de coincidencia de patrones.

El siguiente archivo de ejemplo dynurl.conf define tres objetos que representanalgunas de las aplicaciones web de ejemplo que forman parte del producto IBMWebSphere:

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:

v Se pueden correlacionar varias plantillas de dirección URL con el mismo objeto(por ejemplo, app_snoop se correlaciona con direcciones URL en dos servidoresdiferentes).

v Los objetos se pueden anidar (por ejemplo, app_hitcount y app_hitcount/ejb).v Una petición de dirección URL entrante se compara con las plantillas en orden,

de arriba a abajo. Cuando se encuentra una coincidencia, el proceso se detiene.Por lo tanto, las plantillas más restrictivas se colocan en la parte superior delarchivo.

v Para activar las definiciones en el archivo dynurl.conf, emita el comando dynurlupdate (utilice pdadmin server task).La actualización se produce inmediatamente y el objeto aparece en Web PortalManager cuando se renueva la vista del espacio de objetos protegidos.

v Evite el uso de mayúsculas en el nombre de objeto. Utilice sólo caracteres enminúsculas.

v No utilice un nombre de objeto que ya exista en el espacio de objetos protegidos.v Antes de suprimir un objeto en el archivo dynurl.conf, elimine las ACL

asociadas con el objeto.

Ejemplo de dirección URL dinámica: Travel KingdomEl siguiente ejemplo muestra cómo una intranet corporativa puede proteger lasdirecciones URL generadas por un Oracle Web Listener.

El servidor web de direcciones URL dinámicas utilizado en este ejemplo es OracleWeb Listener. Esta tecnología se puede aplicar igualmente a otros servidores webde direcciones URL dinámicas.

La aplicaciónTravel Kingdom es una empresa que ofrece a los clientes un servicio de reserva deviajes a través de Internet. La empresa quiere utilizar dos aplicaciones de bases dedatos de Oracle en su servidor web — accesible desde el cortafuegos corporativo ya través de Internet.1. Sistema de reserva de viajes


Los clientes autorizados pueden efectuar reservas de forma remota y consultarsus reservas actuales. El personal de Travel Kingdom también puede efectuarreservas para los clientes que llaman por teléfono, procesar cambios y realizarotras muchas transacciones. Puesto que los clientes externos pagan por losservicios con tarjeta de crédito, la transmisión de esa información debe estaraltamente protegida.

2. Gestor de administración

Como muchas otras empresas, Travel Kingdom mantiene una base de datos deadministración que contiene salarios, posición e información sobre laexperiencia. Estos datos van también acompañados de una foto de cadamiembro del personal.

La interfazSe configura un servidor web de Oracle para proporcionar acceso a los siguientesprocedimientos almacenados en la base de datos:

/db-apps/owa/tr.browse Ofrece a todos los usuarios la posibilidad derealizar consultas acerca de los destinos de viajes,precios, etc.

/db-apps/owa/tr.book Se utiliza para efectuar una reserva (personal de laagencia de viajes o clientes autenticados).

/db-apps/owa/tr.change Se utiliza para revisar o cambiar las reservasactuales.

/db-apps/owa/admin.browse Los miembros del personal lo utilizan para verinformación no restringida acerca de éste, como elnúmero de extensión, la dirección de correoelectrónico o la fotografía.

/db-apps/owa/admin.resume Proporciona a un miembro del personal laposibilidad de ver o cambiar la información de susdatos personales en la base de datos deadministración.

/db-apps/owa/admin.update El personal de administración lo utiliza paraactualizar la información acerca del personal.

Estructura de espacio webSe utiliza un servidor WebSEAL para proporcionar una interfaz segura al espacioweb unificado de Travel Kingdom.v Se realiza una conexión (junction) (/ows) con el servidor web de Oracle

ejecutando la aplicación de reserva de viajes y la aplicación de administración.

La política de seguridadPara proporcionar la seguridad apropiada a los recursos web, al mismo tiempo quese mantiene un sistema fácil de usar, la empresa ha establecido los siguientesobjetivos de seguridad:1. El personal de la agencia de viajes tiene un control total sobre todas las

reservas.2. Los clientes autenticados pueden efectuar y cambiar sus propias reservas, pero

no pueden interferir con los datos de reservas de otros clientes autenticados.3. El personal de administración tiene acceso completo a toda la información de

administración.


4. El personal de Travel Kingdom que no es del departamento de administraciónpuede cambiar la información de sus propios datos personales y ver una partede la información de otros miembros del personal.

Correlaciones de direcciones URL dinámicas con el espacio deobjetosPara alcanzar los objetivos de seguridad descritos anteriormente, las correlacionesde las direcciones URL dinámicas con las entradas de objetos de ACL se debenconfigurar tal como aparece en la siguiente tabla.

Recuerde que el orden de esas correlaciones es una parte importante de alcanzarlos objetivos de seguridad tratados anteriormente.

Entrada de espacio de objetos 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 segurosEl cliente se autentica en WebSEAL a través de un canal seguro cifrado.

Los clientes que deseen utilizar la interfaz web deben registrarse también con eladministrador de web de Travel Kingdom para recibir una cuenta.

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 de Travel Kingdom.Observe que los miembros del personal de administración seencuentran también en el grupo de personal.

Customer (Cliente)Clientes de Travel Kingdom que desean efectuar sus reservas através de Internet.

Se da a cada usuario una cuenta en el dominio seguro para que el servidorWebSEAL pueda identificarlos individualmente. La identidad del usuario se pasatambién a los servidores web de Oracle para proporcionar una solución de iniciode sesión único para todos los recursos web.

Control de accesoLa tabla siguiente muestra una lista de los controles de acceso derivados de laaplicación de la información anterior:


/ows/tr/browse unauthenticated Trany_authenticated Tr

/ows/tr/auth unauthenticated -any_authenticated -group TKStaff Trgroup Customer PTr

/ows/admin/forall unauthenticated -any_authenticated -group Staff Tr

/ows/admin/auth unauthenticated -any_authenticated -group AdminStaff Tr

Los grupos Customer (Clientes) y TKStaff (PersonalTK) tienen los mismosprivilegios en los objetos de mantenimiento de reservas y planificación de viajes,con la excepción de que los clientes deben cifrar la información (permiso deprivacidad) para proporcionar una mayor 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 un sistema capaz de:v Proteger la información confidencialv Autenticar usuariosv Autorizar el acceso a la información confidencial

Además, los servidores web de WebSEAL y de Oracle conocen las identidades delos usuarios autenticados del sistema y están habituados a proporcionar unasolución de inicio de sesión único con registro.


Apéndice A. Consulta de webseald.conf

Archivo de configuración webseald.conf

Categorías y stanzas:v GENERAL DE WEBSEAL

[server]v LDAP

[ldap]v ACTIVE DIRECTORY

[uraf-ad]v DOMINO

[uraf-domino]v SSL

[ssl]v CONEXIÓN (JUNCTION)

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

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


[ssl-qop-mgmt-default]v SESIÓN

[session]v CONTENIDO

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

v INICIO DE SESIÓN[logging]

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

v POLICY DIRECTOR[policy-director]

GENERAL DE WEBSEAL


stanza [server]

SISTEMA

unix-user Cuenta de usuario de UNIX para el servidorWebSEAL.

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 servidor WebSEAL.

THREADS Y CONEXIONES

worker-threads Número de threads de trabajo de WebSEAL.

client-connect-timeout Tiempo de espera de conexión inicial del cliente.

persistent-con-timeout Tiempo de espera de conexión persistente HTTP/1.1

CLIENTE HTTPS

https Permite el acceso HTTPS.

https-port Puerto que se debe utilizar en las peticiones HTTPSseguras.

CLIENTE HTTP

http Permite el acceso HTTP (TCP) no seguro.

http-port Puerto que se debe utilizar en las peticiones HTTPno seguras.


GENERAL DE WEBSEAL


CUERPOS Y COLOCACIÓN EN ANTEMEMORIA DE PETICIÓN

request-body-max-read Número máximo de bytes que se pueden leer comocontenido en el cuerpo de las peticiones POST.

request-max-cache Cantidad máxima de datos guardados en caché porpetición.

DYNURL

dynurl-map Ubicación del archivo de correlación de objetos dedirección URL a protegidos

dynurl-allow-large-posts Limita la capacidad de WebSEAL de leer peticionesPOST mayores de lo especificado en post-max-read.

Gestión de URI

utf8-url-support-enabled Controla cómo WebSEAL interpreta las direccionesURL enviadas desde los navegadores.

SUPPRESSING SERVER IDENTITY

suppress-server-identity Suprime la identidad del servidor WebSEAL en lasrespuestas de servidor HTTP.

LDAP


stanza [ldap]

ldap-server-config Ubicación del archivo de configuración ldap.conf(establecido durante la configuración).

cache-enabled Habilita e inhabilita la caché local de LDAP.

prefer-readwrite-server Permite la selección de un servidor LDAP en el quese pueda escribir, cuando esté disponible.

auth-using-compare Permite comprobaciones de autenticación másrápidas utilizando una operación de comparación decontraseña, en lugar de un enlace LDAP.

default-policy-override-support Comprueba la política predeterminada o la políticaespecífica del usuario.

user-and-group-in-same-suffix Búsquedas de rendimiento. Indica que los gruposestán definidos en el mismo sufijo LDAP que elusuario.

ssl-enabled Habilita e inhabilita SSL para la comunicación deWebSEAL a LDAP.

ssl-keyfile Ubicación del archivo de claves SSL.

ssl-keyfile-dn Etiqueta de certificados en el archivo de claves SSL,si existe.

ssl-keyfile-pwd Contraseña del archivo de claves SSL.

bind-dn Nombre distinguido del daemon de WebSEAL(establecido durante la configuración).

bind-pwd Contraseña para el daemon de WebSEAL(establecida durante la configuración).

Apéndice A. Consulta de webseald.conf 235

ACTIVE DIRECTORY


stanza [uraf-ad]

ad-server-config Ubicación del archivo de configuración de ActiveDirectory (definida durante la configuración).

bind-id Identidad del servidor actual.

bind-pwd Contraseña del servidor actual.

DOMINO


stanza [uraf-domino]

domino-server-config Ubicación del archivo de configuración de Domino(definida durante la configuración).

bind-id Identidad del servidor actual.

bind-pwd Contraseña del servidor actual.

SSL


stanza [ssl]

webseal-cert-keyfile Ubicación del archivo de claves que contiene elcertificado del servidor enviado a los navegadorespor WebSEAL al negociar las sesiones SSL.

webseal-cert-keyfile-pwd Contraseña de claves privadas de certificados deWebSEAL.

webseal-cert-keyfile-stash Ubicación del archivo stash de contraseñas de clavesprivadas de WebSEAL.

webseal-cert-keyfile-label Nombre del certificado de WebSEAL para utilizar enlugar del predeterminado.

ssl-keyfile Ubicación del archivo de claves del certificado deWebSEAL utilizado en la comunicación interna.

ssl-keyfile-pwd Contraseña de claves privadas de certificados deWebSEAL (para la comunicación interna).

ssl-keyfile-stash Ubicación del archivo stash de contraseñas de clavesprivadas de WebSEAL (para la comunicacióninterna).

ssl-keyfile-label Nombre de certificado para utilizar en lugar delpredeterminado (para la comunicación interna).

disable-ssl-v2 Inhabilita selectivamente el soporte SSL V2.

disable-ssl-v3 Inhabilita selectivamente el soporte SSL V3.

disable-tls-v1 Inhabilita selectivamente el soporte TLS V1.

ssl-v2-timeout Tiempo de espera del ID de sesión de la caché deGSKit para las conexiones V2 de SSL.

ssl-v3-timeout Tiempo de espera del ID de sesión de la caché deGSKit para las conexiones V3 de SSL.

ssl-max-entries Número máximo de entradas simultáneas en lacaché del ID de sesión SSL de GSKit.


SSL


gsk-crl-cache-size Configuración de la caché CRL. Número máximo deentradas simultáneas en la caché CRL de GSKit.

gsk-crl-cache-entry-lifetime Configuración de la caché CRL. Tiempo de espera deduración de las entradas individuales en la cachéCRL de GSKit.

ssl-ldap-server Servidor LDAP utilizado para la comprobación deCRL.

ssl-ldap-server-port Número de puerto de escucha de este servidorLDAP para la comprobación de CRL.

ssl-ldap-user Usuario de administración para el servidor LDAP.

ssl-ldap-user-password Contraseña del usuario de administración para elservidor LDAP.

CONEXIÓN (JUNCTION)


stanza [junction]

junction-db Ubicación de la base de datos de conexiones(junctions).

jmt-map Ubicación de la tabla de correlaciones deconexiones (junctions) y peticiones.

http-timeout Tiempo de espera para el envío a una conexión(junction) basada en TCP y para la lectura desdeesa conexión.

https-timeout Tiempo de espera para el envío a una conexión(junction) basada en SSL y para la lectura desdeesa conexión.

ping-time Intervalo para la rutina de ping de WebSEAL aservidores con conexión (junction).

basicauth-dummy-passwd Contraseña global cuando se suministran datos deautenticación básica a través de conexiones(junctions) “-b supply”.

worker-thread-hard-limit Porcentaje del total de threads de trabajo queprocesan peticiones para una conexión (junction)particular.

worker-thread-soft-limit Porcentaje del total de threads de trabajo queprocesan peticiones para una conexión (junction)particular.

io-buffer-size Tamaño del búfer para leer y escribir en unaconexión (junction).

max-webseal-header-size Tamaño máximo, en bytes, de cabeceras HTTPgeneradas por WebSEAL.

FILTRADO DE DOCUMENTOS

stanza [filter-url]

<indicador> = <atributo> Atributos de dirección URL que WebSEAL filtraen las respuestas de los servidores con conexión(junction).


CONEXIÓN (JUNCTION)


stanza [filter-schemes]

scheme = <nombre-esquema> Lista de esquemas de direcciones URL queWebSEAL filtra en las respuestas de los servidorescon conexión (junction).

stanza [filter-content-types]

type = text/html> Tipo de contenido de documento que WebSEALfiltra como respuestas de servidores con conexión(junction).

type = text/vnd.wap.wml Tipo de contenido de documento que WebSEALfiltra como respuestas de servidores con conexión(junction).

stanza [script-filtering]

script-filter Habilita e inhabilita el filtro de direcciones URLabsolutas de scripts en servidores con conexión(junction).

CACHÉ DE GSO

stanza [gso-cache]

gso-cache-enabled Habilita e inhabilita la caché de GSO.

gso-cache-size Número de entradas en la caché de GSO.

gso-cache-entry-lifetime Duración máxima de una entrada de caché deGSO.

gso-cache-entry-idle-timeout Duración máxima de una entrada de caché deGSO inactiva.

CACHÉ DE LTPA

stanza [ltpa-cache]

ltpa-cache-enabled Habilita e inhabilita la caché de LTPA.

ltpa-cache-size Número de entradas en la caché de LTPA.

ltpa-cache-entry-lifetime Duración máxima de una entrada de caché deLTPA.

ltpa-cache-entry-idle-timeout Duración máxima de una entrada de caché deLTAPA inactiva.

AUTENTICACIÓN


AUTENTICACIÓN BÁSICA

stanza [ba]

ba-auth Habilita e inhabilita el mecanismo de autenticaciónbásica.

basic-auth-realm Nombre de dominio que aparece en la solicitud deinicio de sesión BA del navegador.

FORMULARIOS

stanza [forms]

forms-auth Habilita e inhabilita la autenticación utilizandoformularios.


AUTENTICACIÓN


SEÑAL

stanza [token]

token-auth Habilita e inhabilita la autenticación utilizandocódigos de paso de señal.

CERTIFICADO

stanza [certificate]

accept-client-certs Configura la gestión de certificados de cliente deWebSEAL.

CABECERAS HTTP

stanza [http-headers]

http-headers-auth Habilita e inhabilita la autenticación utilizandocabeceras HTTP.

stanza [auth-headers]

header Cabeceras HTTP específicas utilizadas para laautenticación.

DIRECCIÓN IP

stanza [ipaddr]

ipaddr-auth Habilita e inhabilita la autenticación utilizandoinformación de direcciones IP.

INCREMENTAL

stanza [authentication-levels]

level = unauthenticatedlevel = password

Configuración de la autenticación incremental.

MULTIPLEXING PROXY AGENTS

stanza [mpa]

mpa Habilita e inhabilita el soporte para la autenticacióna través de multiplexing proxy agents.

CDSSO

stanza [cdsso]

cdsso-auth Habilita e inhabilita la autenticación utilizandoseñales CDSSO.

authtoken-lifetime Valor de duración máxima de una señal deautenticación de CDSSO.

stanza [cdsso-peers]

<nombre-máquina> =<ubicación-archivo-claves>

Pares de dominio que participan en el CDSSO.

RECUPERACIÓN TRAS ERROR

stanza [failover]

failover-auth Habilita e inhabilita la aceptación de las cookies deresolución de errores.

failover-cookies-keyfile Ubicación (nombre de ruta de acceso completa) de laclave de cifrado de cookies generada porcdsso_key_gen.


AUTENTICACIÓN


failover-cookie-lifetime Límite de tiempo para la validez del contenido de lacookie de recuperación.

enable-failover-cookie-for-domain Cambia el tipo de cookie de resolución de errores decookie específica del servidor a cookie específica dedominio.

SSO DE COMUNIDAD ELECTRÓNICA

stanza [e-community-sso]

e-community-sso-auth Habilita e inhabilita el SSO de la comunidadelectrónica.

e-community-name Nombre de la comunidad electrónica que aparece enlas peticiones y las señales de “garantización”.

intra-domain-key Ubicación del archivo de claves utilizado paraasegurar la comunicación entre las instancias deWebSEAL en un dominio DNS.

is-master-authn-server Designa la máquina local como servidor maestro deautenticación WebSEAL.

master-authn-server Nombre del servidor maestro de autenticaciónWebSEAL (si no es la máquina local).

master-http-port Puerto HTTP no estándar para la escucha delservidor maestro de autenticación.

master-https-port Puerto HTTPS no estándar para la escucha delservidor 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 la comunidadelectrónica.

stanza [inter-domain-keys]

<nombre-dominio> =<archivo-claves>

Los archivos de claves para otros dominiosparticipantes en la comunidad electrónica.

REAUTENTICACIÓN

stanza [reauthentication]

reauth-for-inactive Habilita la reautenticación a causa del tiempo deespera de inactividad de entrada de caché de sesión.

reauth-reset-lifetime Restablece el temporizador de duración de entradade caché de sesión después de una reautenticacióncorrecta

reauth-extend-lifetime Amplía el temporizador de duración de entrada decaché de sesión para completar el proceso dereautenticación.


AUTENTICACIÓN


BIBLIOTECAS Y MECANISMOS DE AUTENTICACIÓN

stanza [authentication-mechanisms]

passwd-cdaspasswd-ldappasswd-uraftoken-cdascert-sslcert-cdashttp-requestcdssopasswd-strengthcred-ext-attrssu-passwordsu-token-cardsu-certificatesu-http-requestsu-cdssofailover-passwordfailover-token-cardfailover-certificatefailover-http-requestfailover-cdsso

Lista de mecanismos de autenticación soportados ylas bibliotecas compartidas asociadas.

GESTIÓN DE LA CALIDAD SSL DE PROTECCIÓN

stanza [ssl-qop]

ssl-qop-mgmt Habilita e inhabilita la gestión de la calidad deprotección.

stanza [ssl-qop-mgmt-hosts]

<dirección-ip> Nivel de cifrado QOP para los hosts individuales.

stanza [ssl-qop-mgmt-networks]

<dirección-ip/máscara> Nivel de cifrado QOP para las redes individuales.

stanza [ssl-qop-mgmt-default]

default Nivel de cifrado QOP predeterminado para las otrasdirecciones IP sin correlación.

SESIÓN


stanza [session]

max-entries Número máximo de entradas simultáneas en lacaché de credenciales/sesión de WebSEAL.

timeout Duración máxima de una entrada en la caché decredenciales/sesión de WebSEAL.

inactive-timeout Duración de las entradas inactivas en la caché decredenciales de WebSEAL.

SESIONES DE CLIENTE SSL

ssl-id-sessions Utiliza el ID de SSL para mantener los inicios desesión HTTPS.

SESIONES COMPARTIDAS

use-same-session Utiliza el mismo ID de sesión para los clientes quecambian entre HTTP y HTTPS.


SESIÓN


ENVÍO DE COOKIES DE SESIÓN

resend-webseal-cookies Envía todas las cookies configuradas de resoluciónde errores y de sesión al cliente con cada respuesta.

ID DE SESIÓN DE USUARIO

user-session-ids Habilita/inhabilita la creación y el manejo de los IDde sesión de usuario para la gestión de sesiones.

CONTENIDO


stanza [content]

DIRECTORIOS Y ARCHIVOS LOCALES

doc-root Directorio raíz del árbol de documentos web.

directory-index Nombre del archivo de índice de directorios.

delete-trash-dir Directorio de eliminación temporal para archivossuprimidos por el administrador.

DIRECTORIOS DE USUARIOS LOCALES

user-dir El directorio es el árbol inicial del usuario quecontiene documentos HTML públicos.

PÁGINAS DE ERROR

error-dir Directorio que contiene los archivos de descripciónde 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ón estándar.

login-success Nombre del formulario de inicio de sesión correcto.

logout Nombre de la página que aparece después definalizar la sesión correctamente.

account-locked Nombre de la página que aparece si falla laautenticación debido a una cuenta bloqueada.

passwd-expired Nombre de la página que aparece si falla laautenticación debido a una contraseña caducada.

passwd-change Nombre del formulario de cambio de contraseña.

passwd-change-success Nombre de la página que aparece si la petición decambio de contraseña se ha ejecutado correctamente.

passwd-change-failure Nombre de la página que aparece si la petición decambio de contraseña no se ha ejecutadocorrectamente.

help Nombre de la página que contiene vínculos apáginas de administración válidas.

token-login Nombre del formulario de inicio de sesión deseñales.

next-token Nombre del formulario de las siguientes señales.


CONTENIDO


stepup-login Nombre del formulario de inicio de sesión deautenticación incremental.

switch-user Nombre del formulario de gestión de cambio deusuario.

CGI LOCAL

stanza [cgi]

cgi-timeout Valor de tiempo de espera para leer y escribir enprocesos CGI hijos.

stanza [cgi-types]

bat = cmdcmd = cmdpl = perlsh = shtcl = tclsh76

Designa, para los servidores Win32, el programa quese debe ejecutar para una extensión de archivo CGIdeterminada.

stanza [cgi-environment-variables]

ENV = <nombre-variable> Variables de entorno que heredarán los programasCGI.

ICONOS

stanza [content-index-icons]

image/*video/*audio/*text/htmltext/*application/x-tarapplication/*

Especifica los iconos gráficos que se deben utilizarcuando WebSEAL genera un índice de directorios(esto sucede cuando no existe index.html).

stanza [icons]

diricon Icono utilizado para subdirectorios.

backicon Icono utilizado para el directorio principal.

unknownicon Icono utilizado para tipos de archivo desconocidos.

CACHÉ DE DOCUMENTOS

stanza [content-cache]

text/htmlimage/**/*

Define el tipo y tamaño de la caché para tipos MIMEde documentos específicos que WebSEAL almacenaen la memoria.

TIPOS MIME

stanza [content-mime-types]

<extensión> = <tipo> Define el tipo MIME para extensiones de documentoespecíficas.

deftype Tipo MIME predeterminado que se debe utilizarcuando el tipo de documento no se encuentra en lalista de la tabla de correlaciones.


CONTENIDO


CODIFICACIÓN DE CONTENIDOS

stanza [content-encodings]

gzZ

Correlaciona la extensión del documento con un tipode codificación para navegadores que dan soporte ala codificación del contenido.

INICIO DE SESIÓN


stanza [logging]

server-log Ubicación del archivo de registro de errores delservidor.

max-size Umbral de creación de un nuevo archivo de registropara registros HTTP.

flush-time Frecuencia de vaciado de los búferes de archivos deregistro HTTP.

requests Habilita e inhabilita el registro de peticiones HTTP.

requests-file Ubicación del registro de peticiones HTTP.

referers Habilita e inhabilita el registro de referentes HTTP.

referers-file Ubicación del registro de referentes HTTP.

agents Habilita e inhabilita el registro de agentes HTTP.

agents-file Ubicación del registro de agentes HTTP.

gmt-time Registra peticiones con la hora GMT en lugar de lafranja horaria local.

API DE AUTORIZACIÓN


stanza [aznapi-configuration]

db-file Ubicación del archivo de caché de la base de datosde políticas del cliente local.

cache-refresh-interval Define el intervalo entre las comprobaciones deactualizaciones (sondeos) en el servidor maestro deautorizaciones.

listen-flags Habilita e inhabilita los indicadores para la recepciónde las modificaciones de actualización de la caché depolíticas.

REGISTRO DE API DE AUTORIZACIÓN

logclientid=webseald

logsize Umbral de creación de un nuevo archivo de registropara el registro de auditoría de gestión.

logflush Frecuencia de vaciado de los búferes de archivos deregistro de auditoría de gestión.

logaudit Habilita e inhabilita la auditoría.

auditlog Ubicación del registro de auditoría.

auditcfg = azn Captura de los eventos de autorización.


API DE AUTORIZACIÓN


auditcfg = authn Captura de los eventos de autenticación.

auditcfg = http Captura de los eventos de WebSEAL.

DEFINICIONES DE SERVICIOS API DE AUTORIZACIÓN

<id-servicio>

stanza [aznapi-entitlement-services]

AZN_ENT_EXT_ATTR

POLICY DIRECTOR


stanza [policy-director]

config-file Ubicación del archivo de configuración pd.conf.


Apéndice B. Información de consulta de las conexiones(junctions) WebSEAL

El programa de 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:v “Utilización de pdadmin para crear conexiones (junctions)” en la página 247v “Comandos de conexión (junction)” en la página 248v “Creación de una nueva conexión (junction) para un servidor inicial” en la

página 249v “Adición de un servidor adicional a una conexión (junction) existente” en la

página 251

Utilización de pdadmin para crear conexiones (junctions)Antes de utilizar pdadmin, debe iniciar la sesión en un dominio seguro comousuario de administración sec_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>

Para crear conexiones (junctions) WebSEAL, utilice el comando pdadmin servertask create:pdadmin> server task <identificación-servidor> create <opciones>

El componente identificación-servidor de este comando es una combinación delservidor de Access Manager utilizado por este comando y el nombre de host delservidor de Access Manager.<servidor-Access-Manager>-<nombre-host>

Sintaxis para un solo servidor WebSEAL:

Para Access Manager WebSEAL, el servidor-Access-Manager es webseald y elnombre-host es el nombre de la máquina servidor WebSEAL:pdadmin> server task webseald-<nombre-host> create <opciones>


El servidor WebSEAL inicial instalado en una máquina siempre se denomina segúnel nombre de máquina. Por ejemplo, si el nombre de la máquina es cruz, laidentificación de servidor para una sola instalación de WebSEAL es:webseald-cruz

Sintaxis para múltiples instancias de WebSEAL:

Si instala múltiples instancias de servidor WebSEAL en la misma máquina, elservidor-Access-Manager es el nombre configurado de la instancia de servidorWebSEAL, seguido de webseald y del nombre de host:<nombre-instancia>-webseald-<nombre-host>

Por ejemplo, si los nombres configurados de dos instancias adicionales deWebSEAL son webseal2 y webseal3, las identificaciones de servidor aparecencomo:webseal2-webseald-cruzwebseal3-webseald-cruz

Utilice el comando server list para verificar la identificación de servidor:pdadmin> server listwebseald-cruzwebseal2-webseald-cruzwebseal3-webseald-cruz

Opciones obligatorias de comandos de conexión (junction):

Las opciones de comando obligatorias necesarias para crear una conexión(junction) WebSEAL básica son:v Nombre de host del servidor de aplicaciones de fondo (opción –h)v Tipo de conexión (junction) — tcp, ssl, tcpproxy, sslproxy, local (opción –t)v Punto de conexión (junction) (punto de montaje)pdadmin> server task webseald-<nombre-host> create –t <tipo>–h <nombre-servidor> <punto-conexión>

Comandos de conexión (junction)Los siguientes comandos de conexión (junction) están disponibles con pdadminserver task:


create Crea una conexión (junction) nueva para un servidor inicial.

add Agrega servidores adicionales a un punto de conexión(junction) existente.

remove Elimina un servidor de un punto de conexión (junction).

Sintaxis: remove –i <id-servidor> <punto-conexión>

Utilice el comando show para determinar el ID de un servidorconcreto.

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>

jmt load jmt clear El comando jmt load proporciona a WebSEAL los datos de latabla de correlaciones de conexiones (junctions) (jmt.conf)para gestionar el proceso de las direcciones URL relativas alservidor generadas dinámicamente.

El comando jmt clear elimina los datos de la tabla decorrelaciones 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 de conexión(junction) específico.

exit Sale del programa de utilidad pdadmin.

Sintaxis: exit

Estos comandos, y las opciones asociadas, se describen en los siguientes apartados.

Creación de una nueva conexión (junction) para un servidor inicialOperación: crea un punto de conexión (junction) nuevo y conecta un servidorinicial.

Sintaxis:create –t <tipo> –h <nombre-host> [<opciones>] <punto-conexión>

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 es 80. El puertopredeterminado para –t ssl es 443.

Nombre de host

–h <nombre-host> **Obligatorio**

Nombre de host DNS o dirección IP del servidor defondo de destino.

Opciones

Autenticación mutua a través de SSL

–K <etiqueta-clave> WebSEAL utiliza el certificado de cliente paraautenticarse en el servidor de fondo.

–B WebSEAL utiliza la información de cabecera de BApara autenticarse en el servidor de fondo. Requierelas opciones –U, –W y –b filter.

Apéndice B. Información de consulta de las conexiones (junctions) WebSEAL 249

–U <“nombre-usuario”> Nombre de usuario de WebSEAL. Utilícelo con –Bpara enviar información de cabecera de BA alservidor de fondo.

–W <“contraseña”> Contraseña de WebSEAL. Utilícelo con –B para enviarinformación de cabecera de BA al servidor de fondo.

–D <“DN”> Especifica el Nombre distinguido del certificado deservidor de fondo. Este valor, que coincide con el DNde certificado real, mejora la autenticación.

Opciones de conexión (junction) de proxy (requiere –t tcpproxy o –t sslproxy)

–H <nombre-host> Nombre de host DNS o dirección IP del servidorproxy.


Especificación de la información de cabecera de BA

–b <valor-BA> Define cómo el servidor WebSEAL transfiere lainformación de autenticación BA HTTP al servidor defondo. Puede ser:

filter (valor predeterminado), ignore, supply, gso

Opciones generales de conexión (junction) TCP y SSL

–c <tipos-id> Inserta la identidad de cliente de Access Manager enlas cabeceras HTTP a través de la conexión (junction).El argumento id-types puede incluir cualquiercombinación de los tipos siguientes de cabecera HTTPde Access Manager: iv-user, iv-user-l, iv-groups,iv-creds, all.

–i El servidor WebSEAL trata las direcciones URL comono sensibles a mayúsculas y minúsculas.

–j Proporciona la identificación de conexión (junction) enuna cookie para gestionar direcciones URL relativas alservidor generadas por script.

–k Enviar cookie de sesión al servidor de portal defondo.

–p <puerto> Puerto TCP del servidor de fondo de terceros. Elvalor predeterminado es 80 para conexiones(junctions) TCP; 443 para conexiones (junctions) SSL.

–q <ubicación> Ruta de acceso relativa para el script query_contents.De forma predeterminada, Access Manager buscaquery_contents en /cgi_bin/. Si este directorio esdistinto o si el nombre del archivo query_contents esdistinto, utilice esta opción para indicar a WebSEAL lanueva dirección URL para el archivo. Es necesariopara los servidores Windows de fondo.

–r Insertar dirección IP entrante en la cabecera HTTP através de la conexión (junction).

–s Especifica que la conexión (junction) debe dar soportea aplicaciones con información de estado. De formapredeterminada, las conexiones (junctions) no tieneninformación de estado.

–T <recurso/grupo-recursos>

Nombre de recurso o grupo de recursos de GSO.Obligatorio y utilizado sólo con la opción –b gso.


–u <UUID> Especifica el UUID de un servidor de fondoconectado a WebSEAL a través de una conexión(junction) con información de estado (–s).

–v <nombre-host-virtual>[:<puerto>]

Nombre de host virtual representado en el servidorde fondo. Esta opción da soporte a una configuraciónde host virtual del servidor de fondo.

Utilice –v cuando el servidor con conexión (junction)de fondo espera una cabecera de nombre de hostporque se conecta a una instancia virtual de eseservidor. La petición de cabecera HTTPpredeterminada del navegador no sabe que elservidor de fondo tiene varios nombres y variosservidores virtuales. Debe configurar WebSEAL paraque proporcione esa información de cabeceraadicional en las peticiones destinadas a unaconfiguración de servidor de fondo como host virtual.

–w Soporte para el sistema de archivos Win32.

Imparcialidad de conexión (junction)

–l <valor-porcentaje> Define el límite dinámico de consumo de threads detrabajo.

–L <valor-porcentaje> Define el límite fijo de consumo de threads de trabajo.

Conexiones (junctions) LTPA

–A Habilitar e inhabilitar las conexiones (junctions) LTPA.

–F <“archivo-claves”> Ubicación del archivo de claves utilizado para cifrarla cookie LTPA.

–Z <“contraseña-archivo-claves”>

Contraseña del archivo de claves

Conexiones (junctions) SSL de WebSEAL a WebSEAL

–C Autenticación mutua entre un servidor WebSEALfrontal y un servidor WebSEAL de fondo a través deSSL. Requiere el tipo –t ssl o –t sslproxy.

Inicio de sesión único de formularios

–S <archivo-config> Ubicación del archivo de configuración de inicio desesión único de formularios.

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 la conexión(junction).

Adición de un servidor adicional a una conexión (junction) existenteOperación: agrega un servidor adicional a un punto de conexión (junction)existente.

Sintaxis:add –h <nombre-host> [<opciones>] <punto-conexión>

Apéndice B. Información de consulta de las conexiones (junctions) WebSEAL 251

Nombre de host

–h <nombre-host> **Obligatorio**

Nombre de host DNS o dirección IP del servidor defondo de destino.

Opciones

Autenticación mutua a través de SSL

–D <“DN”> Especifica el Nombre distinguido del certificado deservidor de fondo. Este valor, que coincide con el DNde certificado real, mejora la autenticación.

Opciones de conexión (junction) de proxy (obligatorio con –t tcpproxy y –tsslproxy)

–H <nombre-host> Nombre de host DNS o dirección IP del servidorproxy.


Opciones generales de conexión (junction) TCP y SSL

–i El servidor WebSEAL trata las direcciones URL comono sensibles a mayúsculas y minúsculas.

–p <puerto> Puerto TCP del servidor de fondo de terceros. Elvalor predeterminado es 80 para conexiones(junctions) TCP; 443 para conexiones (junctions) SSL.

–q <url> Dirección URL relativa para el script query_contents.Access busca query_contents en /cgi_bin/. Si estedirectorio es distinto o si se ha cambiado el nombredel archivo query_contents, utilice esta opción paraindicar a WebSEAL la dirección URL nueva para elarchivo.

–u <UUID> Especifica el UUID de un servidor de fondoconectado a WebSEAL a través de una conexión(junction) con información de estado (–s).

–v <nombre-host-virt> Nombre de host virtual representado en el servidorde fondo. Esta opción da soporte a una configuraciónde host virtual del servidor de fondo.

Utilice –v cuando el servidor con conexión (junction)de fondo espera una cabecera de nombre de hostporque se conecta a una instancia virtual de eseservidor. La petición de cabecera HTTPpredeterminada del navegador no sabe que elservidor de fondo tiene varios nombres y variosservidores virtuales. Debe configurar WebSEAL paraque proporcione esa información de cabeceraadicional en las peticiones destinadas a unaconfiguración de servidor de 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.


Apéndice C. Avisos

Esta información se ha desarrollado para productos y servicios que se ofrecen enEstados Unidos.

Es posible que en otros países IBM no ofrezca los productos, los servicios o lascaracterísticas que se describen en este documento. Póngase en contacto con elrepresentante local de IBM para obtener información sobre los productos yservicios disponibles actualmente en su área. Las referencias a programas,productos o servicios de IBM no pretenden indicar ni implicar que sólo puedanutilizarse los productos, programas o servicios de IBM. En su lugar, se puedeutilizar cualquier producto, programa o servicio funcionalmente equivalente queno infrinja ninguno de los derechos de propiedad intelectual de IBM. No obstante,es responsabilidad del usuario evaluar y comprobar el funcionamiento de cualquierproducto, programa o servicio que no sea de IBM.

IBM puede tener patentes o solicitudes de patentes en trámite que afecten a lostemas tratados en este documento. La posesión de este documento no otorga alusuario ninguna licencia sobre esas patentes. Puede enviar consultas sobrelicencias, por escrito, a:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785Estados Unidos

Para consultas sobre licencias en las que se solicite información sobre el juego decaracteres de doble byte (DBCS), póngase en contacto con el departamento depropiedad intelectual de IBM de su país o envíe directamente las consultas porescrito a:

IBM World Trade Asia CorporationLicensing2-31 Roppongi 3-chomeMinato-kuTokio 106Japón

El siguiente párrafo no se aplica al Reino Unido ni a ningún otro país donde estasdisposiciones sean incompatibles con la legislación vigente: INTERNATIONALBUSINESS MACHINES CORPORATION FACILITA ESTA PUBLICACIÓN ″TALCUAL″, SIN GARANTÍAS DE NINGÚN TIPO, NI EXPLÍCITAS NI IMPLÍCITAS,INCLUYENDO, PERO SIN LIMITARSE A, LAS GARANTÍAS IMPLÍCITAS DE NOINFRACCIÓN, COMERCIALIZACIÓN O ADECUACIÓN A UN FIN CONCRETO.Algunos estados o países no permiten la renuncia a las garantías explícitas oimplícitas en ciertas transacciones; por tanto, es posible que esta declaración noresulte aplicable a su caso.

Este documento puede contener imprecisiones técnicas o errores tipográficos.Periódicamente se efectúan cambios en la información aquí contenida; dichoscambios se incorporarán en nuevas ediciones de la publicación. IBM se reserva el


derecho a realizar, si lo considera oportuno, cualquier modificación en losproductos o programas que se describen en esta información y sin notificarlopreviamente.

Las referencias en este documento a sitios web que no sean de IBM seproporcionan únicamente como ayuda y no se consideran en modo alguno sitiosweb aprobados por IBM. Los materiales de dichos sitios web no forman parte deeste producto de IBM y la utilización de los mismos será por cuenta y riesgo delusuario.

IBM puede utilizar o distribuir la información que se le suministre de cualquiermodo que considere adecuado sin incurrir por ello en ninguna obligación con elremitente.

Los titulares de licencias de este programa que deseen información sobre el mismocon el fin de permitir: (i) el intercambio de información entre programas creadosindependientemente y otros programas (incluido éste) y (ii) la utilización mutua dela información intercambiada, deben ponerse en contacto con:

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758Estados Unidos

Dicha información puede estar disponible, sujeta a los términos y condicionesadecuados, incluido, en algunos casos, el pago de una tasa.

El programa bajo licencia que se describe en este documento, y todos losmateriales bajo licencia disponibles para el mismo, los proporciona IBM bajo lostérminos del Acuerdo con el Cliente IBM, del Acuerdo Internacional de Licenciaspara Programas IBM o de cualquier acuerdo equivalente entre el cliente e IBM.

Todos los datos de rendimiento contenidos en el presente documento se handeterminado en un entorno controlado. Por consiguiente, los resultados obtenidosen otros entornos operativos pueden ofrecer variaciones importantes. Algunasmediciones se pueden haber realizado en sistemas de nivel de desarrollo, por loque no existe ninguna garantía de que dichas mediciones sean iguales en lossistemas disponibles generalmente. Además, alguna medición se puede haberestimado mediante extrapolación. Los resultados reales pueden variar. Los usuariosde este documento deben verificar los datos aplicables para su entorno específico.

La información relacionada con productos que no son de IBM se ha obtenido delos proveedores de dichos productos, sus anuncios publicados o de otras fuentesdisponibles públicamente. IBM no ha probado estos productos y no puedeconfirmar la precisión de su rendimiento, compatibilidad o cualquier otrareclamación relacionada con los productos que no son de IBM. Las preguntasrelacionadas con las posibilidades de los productos que no son de IBM se debendirigir a los proveedores de dichos productos.

Todas las declaraciones relacionadas con la orientación o los propósitos futuros deIBM se pueden cambiar o retirar sin previo aviso y únicamente representan metasy objetivos.

Esta información contiene ejemplos de datos e informes utilizados en operacionesempresariales diarias. Para ilustrarlos lo más claramente posible, los ejemplos


incluyen nombres de individuos, empresas, marcas y productos. Todos estosnombres son ficticios y cualquier similitud con los nombres y direcciones utilizadosen empresas reales es coincidencia.

LICENCIA DE COPYRIGHT:

Esta información contiene programas de aplicación de ejemplo en lenguaje fuenteque ilustran técnicas de programación en diferentes plataformas operativas. Puedecopiar, modificar y distribuir estos programas de ejemplo en cualquier formato sinabonar ninguna cantidad a IBM con el propósito de desarrollo, uso,comercialización o distribución de dichos programas de aplicación en conformidadcon la interfaz de programación de aplicaciones que corresponde a la plataformaoperativa para la que se han escrito dichos programas de ejemplo. Éstos no hansido probados en su totalidad en todas las situaciones posibles. IBM, por tanto, nopuede garantizar la fiabilidad, servicio o funcionalidad de estos programas. Puedecopiar, modificar y distribuir estos programas de ejemplo en cualquier formato sinabonar ninguna cantidad a IBM con el propósito de desarrollo, uso,comercialización o distribución de dichos programas de aplicación en conformidadcon las interfaces de programación de aplicaciones de IBM.

Cada copia o cualquier fragmento de estos programas de ejemplo o cualquiertrabajo que derive de ellos debe incluir un aviso de copyright como el siguiente:

© (el nombre de su empresa) (año). Partes de este código se derivan de Programasde ejemplo de IBM Corp. © Copyright IBM Corp. _escriba el año o años_.Reservados todos los derechos.

Marcas registradasLos siguientes términos son marcas registradas de International Business MachinesCorporation en Estados Unidos, en otros países o en ambos:

AIXDB2IBMLogotipo de IBMSecureWayTivoliLogotipo de TivoliWebSphere

Microsoft, Windows, Windows NT y el logotipo de Windows son marcasregistradas de Microsoft Corporation en Estados Unidos y/o en otros países.

Java y todos los logotipos y marcas registradas basados en Java son marcasregistradas de Sun Microsystems, Inc. en Estados Unidos y en otros países.

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

Otros nombres de empresas, productos y servicios pueden ser marcas registradas omarcas de servicios de terceros.

Apéndice C. Avisos 255

Índice

Aaccept-client-certs 127account-locked 36acct_locked.html 37ACL 5ACL, políticas

caracteres válidos para nombres de ACL 90definición 4específicas de WebSEAL 89explícita 6heredada 6

actualizaciones y sondeo de la base de datos deautorizaciones 51

agent.log 43ejemplo 45formato de registro de eventos 47

agents 43agents-file 43agrupación de eventos

http 46http.agent 46http.clf 46http.cof 46http.ref 46

agrupación de eventos http 46almacenamiento en la caché de peticiones 70almacenamiento en la caché de peticiones del servidor 70almacenamiento en la caché de peticiones POST 70aplicador de políticas 7archivo de direccionamiento 47archivo de registro, WebSEAL 23argument-stanza 205atributos ampliados

document-cache-control (POP) 32en credenciales de usuario 218HTTP-Tag-Value, conexión (junction) 218, 221reauth (POP) 135

autenticaciónacceso autenticado a los recursos 11acceso no autenticado a los recursos 11autenticación básica 122Cabecera HTTP 128cambio de usuario 62CDSSO 141certificado 125comunidad electrónica 145configuración de varios métodos de autenticación 120configuración predeterminada 119dirección IP 130formularios 123información sobre el proceso 107inicio de sesión único con formularios 201métodos soportados 108Multiplexing Proxy Agents (MPA) 131objetivos 10parámetro locales 119parámetros de CDAS externo 119reautenticación 134, 137señal 130solicitud de inicio de sesión 120tipos de datos de sesión soportados 108

autenticación (continuación)visión general 10visión general de la configuración 118

autenticación básicaconfiguración 122

autenticación de CDSSO 141autenticación de certificados 125autenticación de comunidad electrónica 145

características 147cifrado de la señal de ″garantización″ 153configuración 154cookie de comunidad electrónica 152flujo de proceso 148petición y respuesta de garantización 152señal de garantización 153

autenticación de direcciones IP 130autenticación de formularios 123

solución de inicio de sesión único 201autenticación de múltiples factores 100autenticación de señales 130autenticación incremental 95autenticación MPA 131authentication-levels, stanza 95, 101authentication-mechanisms, stanza 67authtoken-lifetime 144autorizaciones empresariales (dinámicas) 217

Bba-auth 122backicon 29basic-auth-realm 122basicauth-dummy-passwd 193biblioteca compartida CDMF 141biblioteca compartida libfailoverauthn 117

Ccabecera 129cabecera HOST, mejores prácticas para conexiones

(junctions) 214Cabecera HTTP

límite de tamaño 179PD-USER-SESSION-ID 221

cabecera PD_PORTAL 216caché

GSKit (SSL) 109WebSEAL, credenciales 109

caché CRL, configuración 42gsk-crl-cache-entry-lifetime 42gsk-crl-cache-size 42

caché de credenciales 109configuración 111máximo de entradas 111tiempo de espera de duración 111tiempo de espera de inactividad 112visión general y estructura 12

caché de documentos 31document-cache-control POP 32vaciar cachés 32


caché de GSO, configurar 198caché de LTPA, configurar 200caché de sesión

configuración 110, 111GSKit (SSL) 109tiempo de espera de duración 111tiempo de espera de inactividad 112visión general y estructura 12WebSEAL, credenciales 109

cache-refresh-interval 52calidad de protección

hosts 50nivel predeterminado 49POP, política 103redes 50

cambio de usuario 62biblioteca compartida CDAS 68biblioteca compartida incorporada 67exclusión de usuarios 66flujo de proceso 63habilitación 64influencia en funciones de WebSEAL 69mecanismo de autenticación 67métodos de autenticación válidos 66securitygroup 63su-admin, atributo ampliado 70su-admins, grupo 63su-excluded, grupo 63

caracteres codificados UTF-8 73cdsso 119, 143cdsso-auth 143cdsso_key_gen 117, 144, 153cdsso-peers, stanza 144cdssoauthn 143cert-cdas 119cert-ssl 119, 127certificados

gestión 38GSKit 38iKeyman 38tipos de archivos de base de datos de claves 39

cgi-timeout 27client-connect-timeout 26conectividad SSL 26conectividad TLS 26conexiones

escalabilidad 16visión general 14

conexiones (junctions)-b filter 195-b gso 195-b ignore 194-b supply 193aplicar permisos 186asignación de threads de trabajo (-l) 54asignación de threads de trabajo (-L) 54autenticación de certificados 186autenticadas mutuamente (-D, -K, -B, -U, -W) 165autenticar con cabecera de BA (-B, -U, -W) 166certificado de cliente (WebSEAL) (-K) 166certificado de cliente de WebSEAL (-K) 166coincidencia de Nombre distinguido (DN) (-D) 165conexiones (junctions) de proxy (-H, -P) 168consulta de comandos 247cookie de sesión al servidor de portal (-k) 180de WebSEAL a WebSEAL (-C) 168

conexiones (junctions) (continuación)direcciones URL no sensibles a mayúsculas y minúsculas

(-i) 180directrices para la creación 160especificar dirección IP en cabeceras HTTP (-r) 179especificar identidad del cliente en cabeceras HTTP

(-c) 177especificar UUID de fondo (-u) 182filtrar direcciones URL absolutas con filtrado de

scripts 172filtrar direcciones URL en las respuestas 171forzar una nueva conexión (junction) (-f) 29, 176global sign-on (GSO) 196HTTP/1.0 y 1.1, respuestas 22HTTP-Tag-Value, atributo 221impacto de las opciones -b en las conexiones (junctions)

autenticadas mutuamente 167inicio de sesión único con formularios (-S) 208LTPA (-A, -F, -Z) 200mejores prácticas 213mejores prácticas de cabecera HOST (-v) 214modificación de direcciones URL en aplicaciones de

fondo 169montaje de varios servidores 185nombre de host virtual (-v) 214opción de host (-h) 162opción de tipo (-t) 162opciones gso (-b gso, -T) 198opciones necesarias 162pdadmin server task 161procesar direcciones URL relativas al servidor con

cookies 174procesar direcciones URL relativas al servidor con

correlación de conexiones (junctions) 175proceso de direcciones URL en las peticiones 173query_contents 186sistemas de archivos Windows (-w) 184soporte para conexiones (junctions) con información de

estado (-s, -u) 181tabla de correlaciones de conexiones 175visión general 159

conexiones (junctions) autenticadas mutuamente 165conexiones (junctions) con información de estado 181, 182conexiones (junctions) WebSEAL, véase junctions 159Content-Length, cabecera 173cookie de comunidad electrónica 152cookies

conexión (junction) 174sesión 112, 180

cookies de conexión (junction) 174cookies de resolución de errores

cifrado/descifrado de datos de cookie 117configuración 115configuración de la duración de cookie 118habilitación 116habilitar cookies de dominio 118

cookies de sesión 112habilitación 113

cred-ext-attrs 119credenciales

atributos ampliados 217, 221inserción de ID de sesión de usuario en cabecera

HTTP 221insertar datos en cabeceras HTTP 218insertar datos LDAP 217visión general 13

CRL, comprobación 42


Ddatos de LDAP en cabeceras HTTP 217db-file 51derechos empresariales dinámicos 217detención de WebSEAL 22dinámicos, derechos empresariales 217direcciones URL dinámicas

actualizar, dynurl update 226colocar limitaciones en peticiones POST 227correlacionar objetos ACL 224dynurl-allow-large-posts 227dynurl-map 224ejemplo 229métodos GET y POST 227proporcionar control de acceso 223request-body-max-read 227resolver 226resumen y notas técnicas 228visión general 223

directorio raíz de documentoscambiar ubicación 28

directorio raíz de instalación de WebSEAL. 21directorio raíz de servidor 25directory-index 29diricon 29disable-ssl-v2 26disable-ssl-v3 26disable-tls-v1 26doc-root 28document-cache-control, atributo ampliado de POP 32dynurl-allow-large-posts 227dynurl.conf 224dynurl-map 224dynurl update 226

Ee-community-name 155e-community-sso-auth 154ec-cookie-lifetime 156enable-failover-cookie-for-domain 118entrust-client 129error.log 47escalabilidad 16

servidores de fondo replicados 18servidores frontales replicados 16

escucha de notificaciones de actualizaciones 51espacio de objetos protegidos 4

objeto protegido 4objetos de gestión 4objetos definidos por el usuario 4objetos web 4recurso del sistema 4server-name WebSEAL 22

estadísticas 77comandos de estadísticas 77componentes 80habilitación mediante el registro de eventos 85habilitar (stats on) 77inhabilitar (stats off) 79listar (stats list) 80logcfg, parámetro 85mostrar (stats show) 79pdweb.authn 80pdweb.authz 81pdweb.doccache 83

estadísticas (continuación)pdweb.http 81pdweb.https 81pdweb.jct.# 85pdweb.jmt 82pdweb.sescache 83pdweb.threads 82restablecer (stats reset) 80sintaxis de comando stats 77stats, parámetro 85tipos de actividad 80visualizar (stats get) 79

estado de la sesiónconfiguración de caché de credenciales de WebSEAL 111configuración de caché de ID de sesión SSL de GSKit 110cookies de resolución de errores 115cookies de sesión 112entre cliente y de fondo 220gestión 109gestión de ID de sesión de usuario 220habilitar cookies de sesión 113terminar sesión de usuario única 222terminar todas las sesiones de usuario 223tipos de datos de ID de sesión válidos 114

expresiones regulareslista de 206para direcciones URL dinámicas 225para inicio de sesión único con formularios 206

Ffailover-auth 116failover-cdsso 117failover-certificate 117failover-cookie-lifetime 118failover-cookies-keyfile 117failover-http-request 117failover-password 117failover-token-card 117fatal.log 47filter-content-types, stanza 33filter-schemes, stanza 33filtrado

Content-Length, cabeceraX-Old-Content-Length 173

direcciones URL absolutas 171direcciones URL relativas al servidor 171documentos estáticos 171filtrar direcciones URL absolutas con filtrado de

scripts 172mejores prácticas para las direcciones URL absolutas 214proceso de direcciones URL en las peticiones 173reglas de filtrado de direcciones URL estándar para

WebSEAL 171text/html 171text/vnd.wap.wml 171tipos MIME de documento 33

filtrado de documentos 33filtrado de las direcciones URL absolutas, mejores

prácticas 214filtrar direcciones URL

Content-Length, cabecera 173filtrado de scripts para direcciones URL absolutas 172proceso de direcciones URL en las peticiones 173reglas de filtrado estándar 171

fin de sesión 121flush-time 44

Índice 259

fondo, soporte para aplicaciones de 213formato combinado NCSA 46formato de registro común (request.log) 45formato de registro HTTP común 45forms-auth 123forms-sso-login-pages, stanza 204fsso.conf.template 204

Ggestión de ID de sesión 220gestión de ID de sesión de usuario 220

tagvalue_user_session_id 220user-session-ids 220

gestor de recursos 7global sign-on (GSO) 196gmt-time 44gsk-crl-cache-entry-lifetime 42gsk-crl-cache-size 42GSKit 38

caché CRL 42tipos de archivos 39

GSKit (SSL), caché de sesión de 109configuración 110

GSO 196configurar caché de GSO 198

gso-cache-enabled 199gso-cache-entry-idle-timeout 199gso-cache-lifetime 199gso-cache-size 199gso-resource 205

Hhelp 36help.html 37HTML, páginas personalizadas 36http 26HTTP, autenticación de cabeceras 128HTTP, mensajes de error 33

soporte para macros 36HTTP, registro

utilización del registro de eventos 46valor predeterminado 43

HTTP/1.1, respuestas 22http.agent, agrupación de eventos 46http.clf, agrupación de eventos 46http.cof, agrupación de eventos (NCSA) 46http-headers-auth 128HTTP_IV_CREDS 177, 211, 213HTTP_IV_GROUPS 177, 211, 213HTTP_IV_REMOTE_ADDRESS 179HTTP_IV_USER 177, 211, 213HTTP_PD_USER_SESSION_ID 220HTTP_PD-USER-SESSION-ID 222http-port 26http.ref, agrupación de eventos 46http-request 119, 129HTTP-Tag-Value, atributo de conexión (junction) 219, 221http-timeout (junctions) 27httpauthn 129https 26https-port 26https-timeout (junctions) 27

Iiconos de índice de directorios 29ID de sesión SSL 113identidad de servidor (HTTP), supresión 76identidad de servidor HTTP, supresión 76iKeyman 40

certificado de prueba de WebSEAL 126conexiones (junctions) SSL autenticadas mutuamente 165SSL, conexiones (junctions) de tipo 164visión general 41

illegal-url-substrings, stanza 76imparcialidad de conexiones (junction) 53inactive-timeout 112inicio de sesión

condiciones de solicitud 120inicio de sesión en dominios cruzados

CDSSO 141comunidad electrónica 145

inicio de sesión único-b filter 195-b gso 195-b ignore 194-b supply 193autenticación de formularios 201CDSSO 141comunidad electrónica 145conceptos 191configurar caché de GSO 198especificar identidad del cliente en cabeceras de BA 192global sign-on (GSO) 196LTPA (WebSphere) 199

inicio de WebSEAL 22intra-domain-key 153, 155ipaddr-auth 130is-master-authn-server 155iv-creds 177, 213iv-groups 177, 213iv-remote-address 179iv-user 177, 213ivweb_setup 59ivweb_uninst 61

Jjmt.conf 175jmt load 175jmt-map 175junction, stanza 53junction-db 159

Lldapauthn 123, 124libcdssoauthn 143libhttpauthn 129libldapauthn 123, 124libsslauthn 127libsuauthn 67libtokenauthn 131lista de control de accesos (ACL) 5listen-flags 51logcfg 46, 85login 36login-form-action 205login.html 37, 124login-page 205


login-page-stanza 204login_success.html 37logout 36logout.html 37LTPA (WebSphere) 199

configurar caché de LTPA 200configurar conexión (junction) 200

ltpa-cache-enabled 200ltpa-cache-entry-idle-timeout 200ltpa-cache-entry-lifetime 200ltpa-cache-size 200

Mmaster-authn-server 155master-http-port 154master-https-port 154max-entries 111max-size 44max-webseal-header-size 179mejores prácticas

filtrado de las direcciones URL absolutas 214información de cabecera HOST (-v) 214

mensajes 47archivo de direccionamiento 47error.log 47fatal.log 47notice.log 47warning.log 47

mensajes de errorHTTP 33servicios 47soporte para macros para HTTP 36

mensajes de servicios 47archivo de direccionamiento 47error.log 47fatal.log 47notice.log 47warning.log 47

método GET 227método POST 227

configurar limitaciones 227métodos de autenticación, resumen 108mgt-pages-root 36, 65mpa 134múltiples instancias de WebSEAL

comandos de inicio, detención, reinicio y estado delservidor 61

configuración en UNIX 56configuración en Windows 59desconfiguración 61sintaxis en comandos pdadmin 162, 248visión general de la configuración 56

Multiplexing Proxy Agents (autenticación) 131

Nnet command (Windows) 62next-token 36nexttoken.html 37notice.log 47

Oobjeto protegido 4objetos de gestión 4

objetos definidos por el usuario 4objetos web 4

Ppáginas de gestión de cuentas 36páginas de gestión de cuentas HTML

soporte para macros 37parámetros de tiempo de espera

HTTP y HTTPS 26SSL de GSKit caché de sesión de 110WebSEAL, caché de credenciales/sesión de 111

passwd-cdas 119passwd-change 36passwd-change-failure 36passwd-change-success 36passwd_exp.html 37passwd-expired 36passwd.html 37passwd-ldap 119, 123, 124passwd_rep.html 37pd.conf 218pd_start, comando de estado 61PD-USER-SESSION-ID HTTP, cabecera 221pdadmin server task

terminate all_sessions 223pdadmin server task (junctions) 161pdweb, comando 22, 61pdweb.authn, estadísticas 80pdweb.authz, estadísticas 81PDWeb_config 56pdweb.debug (trace) 87pdweb.doccache, estadísticas 83pdweb.http, estadísticas 81pdweb.https, estadísticas 81pdweb.jct.#, estadísticas 85pdweb.jmt, estadísticas 82pdweb.sescache, estadísticas 83pdweb.threads, estadísticas 82PDWeb_unconfig 61persistent-con-timeout 26petición y respuesta de garantización 152ping-time (junctions) 27pkmscdsso 145pkmslogout 121pkmspasswd 121pkmsvouchfor 152, 156política de ACL default-webseal 90política de ACL explícita 6política de ACL heredada 6política de inicio de sesión en tres intentos 91política de intensidad de contraseñas 92política de pdadmin

disable-time-interval 91max-login-failures 91max-password-repeated-chars 92min-password-alphas 92min-password-length 92min-password-non-alphas 92password-spaces 92

política de seguridadidentificación de tipos de contenido 9niveles de protección 9planificación e implementación 8

política POP de autenticación basada en la red 101política POP de intensidad de autenticación 95, 101políticas de objetos protegidos 5

Índice 261

POP 5POP, política

autenticación basada en la red 101calidad de protección 103definición 4document-cache-control, atributo ampliado 32intensidad de autenticación (incremental) 95reauth, atributo ampliado 135

portal-map, stanza 216programa de utilidad de rastreo (trace) 86

pdweb.debug, componente 87trace list 87trace set 87trace show 87

programación de CGIsoporte 211soporte para variables de entorno WIN32 212

Qquery_contents 186

instalar 187personalizar 189proteger 190

query_contents.c 187query_contents.cfg 187query_contents.exe 187query_contents.html 187query_contents.sh 187

Rreautenticación

basada en inactividad de sesión 137política basada en la seguridad (POP) 134reauth, atributo ampliado de POP 135reauth-extend-lifetime 137, 140reauth-for-inactive, parámetro 139reauth-reset-lifetime 136, 139

reauth, atributo ampliado de POP 135reauth-extend-lifetime 137, 140reauth-for-inactive 139reauth-reset-lifetime 136, 139recurso del sistema 4referer.log 43

ejemplo 45formato de registro de eventos 47

referers 43referers-file 43registro

HTTP (registro de eventos) 46HTTP predeterminado 43

registro de eventosestadísticas 85HTTP, registro 46

REMOTE_USER 211replicar servidores WebSEAL frontales 55request-body-max-read 72, 227request.log 43

ejemplo 45formato de registro de eventos 46

request-max-cache 72requests 43requests-file 43resend-webseal-cookies 113

Sscript-filter 172scripts de sitios cruzados

illegal-url-substrings, stanza 76prevención de vulnerabilidad 75

securitygroup 63, 65, 66server-log 23server-name 22, 55server-root 25, 65servicio de autorizaciones 7servicio de personalización

configuración de WebSEAL 216ejemplo 216visión general 215

servidores WebSEAL frontalesreplicar 55

solicitud de inicio de sesióncondiciones 120

sondeo 51sondeo de la base de datos de autorizaciones 52soporte para aplicaciones de fondo 213soporte para aplicaciones del servidor 213soporte para macros

HTTP, mensajes de error 36páginas de gestión de cuentas HTML 37

ssl-id-sessions 113ssl-keyfile 41ssl-keyfile-label 41ssl-keyfile-pwd 41ssl-keyfile-stash 41ssl-ldap-server 42ssl-ldap-server-port 42ssl-ldap-user 42ssl-ldap-user-password 42ssl-max-entries 111ssl-qop-mgmt 49ssl-v2-timeout 110ssl-v3-timeout 110sslauthn 127stanza acnt-mgt 36, 65stanza aznapi-configuration 46, 51, 85stanza cgi-environment-variables 212stanza cgi-types 30stanza content-caches 31stanza filter-url 172stanza inter-domain-keys 153, 156stanza ldap-ext-cred-tags 218, 219stanza logging 23stanza ltpa-cache 200stanza script-filtering 172stanza ssl-qop-mgmt-default 49stanza ssl-qop-mgmt-hosts 50stanza ssl-qop-mgmt-networks 50stats 85stats, comandos 77stepup-login 36, 97stepuplogin.html 37, 97su-admin, atributo ampliado 70su-admins, grupo 63, 65, 66su-excluded, grupo 63, 65, 66suauthn 67suppress-server-identity 76switch-user 65


Ttabla de correlaciones de conexiones 175tagvalue_user_session_id 221tcp-port 51terminar sesión de usuario única 222terminar todas las sesiones de usuario 223threads de trabajo

asignación global 53asignación por conexión (junction) 54conexiones (junctions) 53gestión 52imparcialidad de conexiones (junction) 53WebSEAL 52

timeout 111, 136, 139tipo, MIME 33tipos de archivos de base de datos de claves 39tipos de datos de ID de sesión 114tipos de datos de sesión 108token-auth 130token-cdas 119, 131token-login 36tokenauthn 131tokenlogin.html 37Transport Layer Security (TLS) 26

Uubicación de bases de datos de autorizaciones replicadas 51ubicación de réplicas de base de datos de autorizaciones 51udp-port 51unknownicon 29URL

acerca de las rutas de acceso absolutas 170acerca de las rutas de acceso relativas 170acerca de las rutas de acceso relativas del servidor 170gestión de UTF-8 73información sobre tipos de ruta de acceso 170modificación de direcciones URL en recursos de

fondo 169opciones de filtrado 171tabla de correlaciones de conexiones (junctions) 175uso de cookies de conexión (junction) 174

use-same-session 113user-session-ids 220usuarios no autenticados, controlar 104utf8-url-support-enabled 74

Vvaciar cachés 32valor de indicador 217, 221variables de entorno de, soporte 212vf-token-lifetime 155vf-url 156

Wwarning.log 47Web Portal Manager 6WebSEAL

archivo de registro 23configuración de múltiples instancias 56directorio raíz de instalación 21directorio raíz de servidor 25directorio raíz del árbol de documentos 28

WebSEAL (continuación)en espacio de objetos 22estadísticas 77HTTP/1.1, respuestas 22iniciar y detener el servidor 22server-name 22visión general 1webseald.conf, archivo de configuración 23

WebSEAL, caché de credenciales/sesión deconfiguración 111visión general 109visión general y estructura 12

webseal-cert-keyfile 40webseal-cert-keyfile-label 40, 126, 186webseal-cert-keyfile-pwd 40webseal-cert-keyfile-stash 40webseal-mpa-servers, grupo 133, 134webseald.conf

consulta 233ubicación 23visión general 23

WebSphere LTPA 199worker-thread-hard-limit 53worker-thread-soft-limit 53worker-threads 52, 53

Índice 263

Printed in Denmark by IBM Danmark A/S

GC10-3839-00

IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/es_ES/PDF/ws... ·...

Documents

Transcript of IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4682-00/es_ES/PDF/ws... ·...