Correlación de identidades para la autorización entre servidores de reinos diferentes

La correlación de identidades es la correlación unívoca de una identidad de usuario entre dos servidores para que los servidores puedan tomar las decisiones de autorización correctas en sentido descendente. La correlación de identidades es necesaria cuando se requiere la integración de servidores, pero los registros de usuarios son distintos y no están compartidos entre los sistemas.

Acerca de esta tarea

En la mayoría de los casos, las solicitudes fluyen en sentido descendente entre dos servidores que forman parte del mismo dominio de seguridad. En WebSphere Application Server, dos servidores que son miembros de la misma célula también son miembros del mismo dominio de seguridad. En la misma célula, los dos servidores tienen el mismo registro de usuarios y las mismas claves LTPA (Lightweight Third Party Authentication) para el cifrado de señales. Estos elementos comunes garantizan que la señal LTPA, entre otros atributos de usuario, que fluye entre los dos servidores, no sólo se pueda descifrar y validar, sino que la identidad de usuario también se pueda correlacionar con los atributos reconocidos por el motor de autorizaciones.

La configuración más fiable y recomendada implica dos servidores dentro de la misma célula. No obstante, a veces es necesario integrar varios sistemas que no pueden utilizar el mismo registro de usuarios. Cuando los recursos de usuarios son diferentes entre dos servidores, el dominio de seguridad o el reino del servidor de destino no coincide con el dominio de seguridad del servidor remitente.

WebSphere Application Server permite realizar la correlación antes de enviar fuera la solicitud o antes de permitir que las credenciales de seguridad existentes fluyan al servidor de destino. Las credenciales se correlacionan a la entrada con la especificación de que el reino de destino es de confianza.

Una alternativa a la correlación es enviar la identidad de usuario sin la señal o la contraseña a un servidor de destino sin correlacionar realmente la identidad. El uso de una identidad de usuario se basa en la confianza entre dos servidores. Utilice la aserción de identidad CSIv2 (Common Secure Interoperability Versión 2). Cuando se habilita, el servidor sólo envía el certificado X.509, el nombre de principal o el nombre distinguido (DN), según lo que haya utilizado el cliente original para realizar la autenticación inicial. Durante la aserción de identidad CSIv2, se establece la confianza entre los WebSphere Application Server.

La identidad de usuario debe existir en el registro de usuarios de destino para que la aserción de identidad funcione. Este proceso también permite la interoperatividad entre otros servidores de aplicaciones compatibles con J2EE (Java™ 2 Platform, Enterprise Edition) Versión 1.4 y posteriores. Si el servidor remitente y los servidores de destino tienen configurada la aserción de identidad, WebSphere Application Server siempre utilizará este método de autenticación, aunque los dos servidores estén en el mismo dominio de seguridad. Si desea obtener más información sobre la aserción de identidad CSIv2, consulte Aserción de identidad en el servidor en sentido descendente.

Cuando la identidad de usuario no está presente en el registro de usuarios del servidor de destino, la correlación de identidades se debe producir antes de enviar fuera la solicitud o cuando la solicitud entra. Esta decisión depende del entorno y los requisitos. No obstante, normalmente es más fácil correlacionar la identidad de usuario antes de enviar fuera la solicitud debido a los siguientes motivos:
  • Conoce la identidad de usuario de la credencial existente ya que proviene del registro de usuarios del servidor remitente.
  • No tiene que preocuparse de compartir claves LTPA (Lightweight Third Party Authentication) con el otro reino de destino, ya que no está correlacionando la identidad con credenciales LTPA. Normalmente, la identidad se correlaciona con un ID de usuario y una contraseña que existen en el registro de usuarios del reino de destino.
En la mayoría de los casos, cuando se realiza la correlación de salida, se recomienda utilizar SSL (Secure Sockets Layer) para proteger la integridad y la confidencialidad de la información de seguridad que se envía a través de la red. Si las claves LTPA no se comparten entre servidores, no se puede validar una señal LTPA en el servidor de entrada. En este caso, la correlación de salida es necesaria porque la identidad de usuario no se puede determinar en el servidor de entrada para realizar una correlación de entrada. Para obtener más información, consulte Configuración de la correlación de identidad de salida con un reino de destino.

Cuando se necesita la correlación de entrada, posiblemente debido a las posibilidades de correlación del servidor de entrada, debe asegurarse de que los dos servidores tengan las mismas claves LTPA para poder obtener acceso a la identidad de usuario. Normalmente, en las comunicaciones seguras entre servidores, se pasa una señal LTPA al devolución de llamada WSCredTokenCallback de la configuración de inicio de sesión JAAS para poder realizar la autenticación del cliente. Existe un método que permite abrir la señal LTPA, si es válida, y obtener acceso al ID exclusivo del usuario para que se pueda realizar la correlación. Para obtener más información, consulte Configuración de la correlación de identidad de entrada. En los demás casos, por ejemplo, en la aserción de identidad, recibirá un nombre de usuario en la devolución de llamada NameCallback de la configuración de inicio de sesión de entrada que permite correlacionar la identidad.

Los temas siguientes están cubiertos en esta sección:

Procedimiento


Icon that indicates the type of topic Task topic



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