Asociaciones de confianza

La asociación de confianza permite la integración de la seguridad de IBM® WebSphere Application Server y los servidores de seguridad de terceros. En concreto, un servidor proxy inverso puede actuar como servidor de autenticación frontal mientras el producto aplica su propia política de autorización a las credenciales resultantes que pasa el servidor proxy.

La demanda de este tipo de configuración integrada es muy alta, especialmente cuando un solo producto no puede dar respuesta a todas las necesidades del cliente o cuando la migración no es una solución viable.

En esta configuración, se utiliza WebSphere Application Server como servidor de programa de fondo para explotar al máximo su control de acceso de gran precisión. El servidor proxy inverso pasa la petición HTTP a WebSphere Application Server, que incluye las credenciales del usuario autenticado. A continuación, WebSphere Application Server utiliza estas credenciales para autorizar la solicitud.

Modelo de asociación de confianza

El concepto de que WebSphere Application Server puede dar soporte a las asociaciones de confianza implica que la seguridad de las aplicaciones del producto reconoce y procesa las peticiones HTTP que se reciben desde el servidor proxy inverso. WebSphere Application Server y el servidor proxy se comprometen en un contrato por el que el producto confía plenamente en el servidor proxy y éste aplica sus políticas de autenticación a cada solicitud web asignada a WebSphere Application Server. Esta confianza es validada por los interceptores que residen en el entorno del producto para cada petición recibida. El método de validación se acuerda entre el servidor proxy y el interceptor.

La ejecución en modalidad de asociación de confianza no impide a WebSphere Application Server aceptar peticiones que no pasen por el servidor proxy. En este caso, no se necesita ningún interceptor para validar la confianza.

WebSphere Application Server da soporte a la siguiente interfaz TAI (Interceptor de asociación de confianza):
com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus
Esta implementación del interceptor TAI que implementa la nueva interfaz de WebSphere Application Server da soporte a WebSphere Application Server Versión 5.1.1 y posteriores. La interfaz da soporte a WebSEAL Versión 5.1, pero no da soporte a WebSEAL Versión 4.1. Si desea obtener más información sobre la propagación de atributos de seguridad, consulte Propagación de atributos de seguridad.
[z/OS]Nota: La implementación del interceptor de TAI también da soporte a WebSphere Application Server Versión 5.1.0.2 para z/OS.
com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl
Este interceptor es nuevo es este release. SPNEGO ha sustituido el TAI de SPNEGO como autenticador web para WebSphere Application Server.
La idea de que WebSphere Application Server puede soportar la asociación de confianza implica que la seguridad de aplicación de producto reconoce y procesa las solicitudes HTTP que se reciben de un servidor proxy inverso. WebSphere Application Server y el servidor proxy se comprometen en un contrato en el que el producto confía plenamente en el servidor proxy y el servidor proxy aplica las políticas de autenticación en cada solicitud Web que se asigna a WebSphere Application Server. Esta confianza la validan los interceptores que residen en el entorno de producto para cada solicitud recibida. El método de validación lo acuerdan el servidor proxy y el interceptor.

IBM WebSphere Application Server: Integración de WebSEAL

La integración de la seguridad de WebSEAL y WebSphere Application Server se consigue colocando WebSEAL al frente como servidor proxy inverso. Desde el punto de vista de la gestión de WebSEAL, el enlace se ha creado con WebSEAL en un extremo y el servidor web del producto en el otro. Un enlace es una conexión lógica que se crea para establecer una ruta desde WebSEAL a otro servidor.

En esta configuración, la petición de recursos web almacenados en un dominio protegido del producto se entrega al servidor WebSEAL, donde se autenticará utilizando el reino de seguridad de WebSEAL. Si el usuario de la petición tiene acceso al enlace, la petición se transmitirá al servidor HTTP de WebSphere Application Server a través del enlace, y después al servidor de aplicaciones.

Mientras tanto, WebSphere Application Server valida todas las peticiones que provengan del enlace, para garantizar que el origen es de confianza. Este proceso se conoce como validación de la confianza y es realizado por un interceptor designado por el producto de WebSEAL. Si la validación es satisfactoria, WebSphere Application Server autoriza la petición comprobando si el usuario cliente tiene los permisos necesarios para acceder al recurso web. Si es así, el recurso web se entrega al servidor WebSEAL a través del servidor web, que a su vez entrega el recurso al usuario cliente.

Servidor WebSEAL

El director de políticas delega todas las peticiones web a su componente web, el servidor WebSEAL. Una de las principales funciones del servidor es realizar la autenticación del usuario de la solicitud. El servidor WebSEAL consulta un directorio Lightweight Directory Access Protocol (LDAP). También puede correlacionar el ID de usuario original con otro ID de usuario, por ejemplo, cuando se utiliza el inicio de sesión único global (GSO).

El director de política delega todas las solicitudes web al componente web, el servidor WebSEAL. Una de las funciones principales del servidor es realizar la autenticación del usuario solicitante. El servidor WebSEAL consulta un directorio Lightweight Directory Access Protocol (LDAP). También se puede correlacionar el ID de usuario original con otro ID de usuario, por ejemplo cuando se utiliza el inicio de sesión único global (GSO).

Para que la autenticación sea satisfactoria, el servidor toma el rol de un cliente de WebSphere Application Server cuando canaliza la petición. El servidor necesita su propio ID de usuario y una contraseña para identificarse en WebSphere Application Server. Esta identidad debe ser válida en el reino de seguridad de WebSphere Application Server. El servidor WebSEAL sustituye la información de autenticación básica en la petición HTTP por sus propios ID de usuario y contraseña. Asimismo, WebSphere Application Server debe determinar las credenciales del cliente de la petición, para que el servidor de aplicaciones tenga una identidad que utilizar como base en las decisiones de autorización. Esta información se transmite a través de la solicitud HTTP creando una cabecera denominada iv-creds, con las credenciales de usuario de Tivoli Access Manager como su valor.

Servidor HTTP

El enlace que se crea en el servidor WebSEAL debe llevar al servidor HTTP que actúa como programa frontal del producto. No obstante, el servidor HTTP está apantallado y no puede saber que se está utilizando la asociación de confianza. Para él, el producto WebSEAL es sólo otro cliente HTTP, y como parte de su rutina habitual, envía la solicitud HTTP al producto. El único requisito en el servidor HTTP es una configuración SSL (Secure Sockets Layer) que utiliza sólo la autenticación de servidor. Este requisito protege las solicitudes que fluyen por el enlace.
El cruce que se crea en el servidor WebSEAL debe llegar al servidor HTTP que sirve como programa frontal de producto. Sin embargo, se impide que el servidor HTTP sepa que se utiliza esa asociación de confianza. En lo que respecta al producto WebSEAL, éste es sólo otro cliente HTTP y, como parte de las rutinas normales, envía la solicitud HTTP al producto. El único requisito del servidor HTTP es una configuración SSL (Secure Sockets Layer - Capa de sockets seguros) que sólo utiliza la autenticación de servidor. Este requisito protege las solicitudes que fluyen en el cruce.

Colaborador Web

Cuando está habilitada la asociación de confianza, el colaborador web gestiona los interceptores configurados en el sistema. El colaborador web carga e inicializa estos interceptores cuando se reinician los servidores. Cuando el servidor Web pasa una petición a WebSphere Application Server, el colaborador web recibe al final la petición para comprobar la seguridad. Se deben realizar dos acciones:
  1. Se debe autenticar la solicitud.
  2. Se debe autorizar la solicitud.
Se llama al autenticador web para autenticar la petición pasándole la petición HTTP. Si la autenticación es satisfactoria, el autenticador devuelve un registro de credenciales correctas, que utiliza el colaborador web para basar su autorización para el recurso solicitado. Si la autorización es satisfactoria, el colaborador web indica a WebSphere Application Server que la comprobación de seguridad ha sido correcta y que se puede servir el recurso solicitado.

Autenticador Web

El colaborador web pide al autenticador web que autentique una petición HTTP determinada. Sabiendo que la asociación de confianza está habilitada, la tarea del autenticador web es buscar el interceptor de asociación de confianza adecuado para dirigir la solicitud de proceso. El autenticador web consulta todos los interceptores disponibles. Si no se encuentra ningún interceptor de destino, el autenticador web procesa la petición como si la asociación de confianza no estuviera habilitada.

Nota:

WebSphere Application Server Versión 4 a WebSphere Application Server Versión 6.x dan soporte a la interfaz com.ibm.websphere.security.TrustAssociationInterceptor.java. La versión 7.0.x y posteriores de WebSphere Application Server dan soporte a la interfaz com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl.

Interfaz de interceptor de asociación de confianza

El objetivo de la interfaz de interceptor de asociación de confianza es que los servidores de seguridad proxy inverso (RPSS) existan como puntos de entrada expuestos para realizar la autenticación y la autorización más general, mientras WebSphere Application Server fuerza un control de acceso más preciso. Las asociaciones de confianza mejoran la seguridad ya que disminuyen el ámbito y el riesgo de que los datos confidenciales se vean expuestos.

En una infraestructura típica de e-business, el entorno distribuido de la compañía está formado por servidores de aplicaciones web, servidores web, sistemas existentes, y uno o varios servidores RPSS, como el producto Tivoli WebSEAL. Estos servidores proxy inversos, los servidores frontales de seguridad o los plug-ins de seguridad registrados dentro de los servidores web protegen las peticiones de acceso HTTP a los servidores web y los servidores de aplicaciones web. Al proteger el acceso a los URI (Uniform Resource Identifier), estos RPSS realizan la autenticación, la autorización más general y el direccionamiento de la solicitud al servidor de aplicaciones de destino.

Cuando un servidor web, como un IBM HTTP Server, utiliza un TAI para establecer comunicación con WebSphere Application Server, a veces es imprescindible que el TAI sepa si una solicitud procedía de un servidor web o llegó directamente a WebSphere Application Server. Por lo tanto, el contenedor Web de WebSphere Application Server utiliza tres atributos HttpServletRequest para proporcionar el TAI con la información del certificado para una solicitud:
  • El atributo com.ibm.websphere.ssl.direct_connection_peer_certificates contiene un objeto X509Certificate[] del certificado para un igual directo.
  • El atributo com.ibm.websphere.ssl.direct_connection_cipher_suite contiene un objeto de serie para una suite de cifrado directa.
  • El atributo com.ibm.websphere.webcontainer.is_direct_connection contiene un objeto booleano que indica si la conexión se ha realizado a través de un servidor web o se ha realizado directamente con WebSphere Application Server.

Consulte el tema Atributos de solicitud de contenedor web para obtener más información sobre estos atributos.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_trust
File name: csec_trust.html