Servicios de autenticación

Los servicios de autenticación sólo están soportados entre aplicaciones cliente que utilizan WebSphere MQ Real-time Transport y nodos Real-timeInput y Real-timeOptimizedFlow de WebSphere Message Broker.

Los servicios de autenticación de WebSphere Message Broker verifican que un intermediario y una aplicación cliente son quien dicen ser y pueden, por tanto, participar en una sesión de publicación/suscripción.

Cada participante en la sesión utiliza un protocolo de autenticación para demostrar al otro que es quien dice ser, y que no es un intruso que se hace pasar por un participante válido.

El producto WebSphere Message Broker tiene soporte para los cuatro protocolos que se indican a continuación:

Los dos primeros protocolos y sus requisitos de infraestructura están descritos en los apartados Autenticación de contraseña simple de tipo telnet y Autenticación de contraseña mediante identificación-respuesta recíproca respectivamente. Los protocolos de SSL simétrica y asimétrica se describen en el apartado Autenticación SSL.

Los protocolos varían en cuanto a rigor, en términos de protección contra participantes que no sean participantes válidos para la sesión; P es el menos enérgico y R el más enérgico.

Configuración de protocolos de autenticación

El conjunto de protocolos que puede soportar un intermediario específico en el dominio de intermediarios puede configurarse utilizando el entorno de trabajo. Para cada intermediario se pueden especificar uno o más protocolos. Utilice el entorno de trabajo para habilitar o inhabilitar la autenticación en cada nodo Real-timeInput que se haya definido para un intermediario específico. Cuando la autenticación está habilitada en un nodo Real-timeInput, dicho nodo soportará el conjunto completo de protocolos especificado para el intermediario que le corresponda. Las opciones de configuración se ilustran en los siguientes diagramas:

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

Visión general de la configuración de autenticación
Proceso de autenticación de ejecución en dos etapas

Este diagrama muestra la etapa 1 del proceso de autenticación de ejecución; se determina el protocolo para la sesión.

Este diagrama muestra la etapa 2 del proceso de autenticación de ejecución; se otorga o se deniega permiso a la aplicación para acceder a la sesión.

Autenticación de contraseña simple de tipo telnet

Este protocolo también puede describirse como contraseña sin cifrado puesto que la contraseña pasa por la red sin estar cifrada. La aplicación cliente se conecta con el nodo Real-timeInput utilizando TCP/IP. El nodo de entrada solicita que el cliente se identifique. El cliente envía su "idusuario" y su contraseña.

Este sencillo protocolo se base en que tanto el cliente como el intermediario conocen la contraseña asociada a un ID de usuario. En particular, el intermediario necesita tener acceso a un depósito que contenga información sobre usuarios y contraseñas. La información de ID de usuarios y de contraseñas se distribuye mediante el Servidor de nombres de usuario a todos los intermediarios de un dominio de productos WebSphere Message Broker. El Servidor de nombres de usuario extrae la información sobre el usuario y la contraseña de un archivo del sistema operativo.

El método del Servidor de nombres de usuario permite un mantenimiento centralizado del origen de usuarios y contraseñas, con distribución automática de la información a intermediarios y renovaciones automáticas de la información, si corresponde. También tiene ventajas en la disponibilidad, puesto que la información de usuarios y contraseñas se mantiene persistentemente en cada intermediario.

Cada aplicación cliente ha de conocer su propio ID de usuario y conservar la contraseña en secreto. Cuando se crea una conexión, un cliente especifica sus credenciales como una combinación de nombre/contraseña.

Este protocolo proporciona una seguridad relativamente poco enérgica. No calcula una clave de sesión y sólo debería utilizarse en entornos donde no haya personas no autorizadas ni intermediarios no fiables.

Cuando el usuario y la contraseña están almacenados en un archivo plano en el sistema del servidor de nombres de usuario, las contraseñas se almacenan y distribuyen "sin cifrado".

La carga de cálculo en el cliente y el servidor es muy ligera.

Autenticación de contraseña mediante identificación-respuesta recíproca

Existe un protocolo más seguro y complicado que implica la generación de una clave de sesión secreta. Tanto el cliente como el servidor calculan dicha clave utilizando la contraseña del cliente. Se prueban el uno al otro que conocen el secreto mediante un protocolo de identificación y respuesta.

El cliente ha de realizar su identificación ante el servidor antes de que el servidor realice la suya ante el cliente. Esto significa que un atacante que se haga pasar por un cliente no podrá reunir la información necesaria y montar un ataque para adivinar la contraseña "fuera de línea". Tanto el cliente como el servidor se prueban el uno al otro que conocen la contraseña, por lo que este protocolo no es vulnerable mediante ataques con "suplantación".

Como con el protocolo de contraseña simple de tipo telnet, el intermediario ha de tener acceso a la información de usuario y contraseña. La información de ID de usuario y de contraseña la distribuye el servidor de nombres de usuario a todos los intermediarios del dominio. El servidor de nombres de usuario extrae la información del usuario y la contraseña de un archivo del sistema operativo.

Cada aplicación cliente ha de conocer su propio ID de usuario y conservar la contraseña en secreto. Cuando se crea una conexión, un cliente especifica sus credenciales como una combinación de nombre/contraseña.

Las demandas de cálculo en el cliente y el servidor son bastante modestas.

Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
aq01206_