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.
- 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.
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
- Configuración de la correlación de identidad de entrada Para la correlación de identidades de entrada, puede escribir un módulo de inicio de sesión personalizado y configurar WebSphere Application Server para ejecutar primero el módulo de inicio de sesión en las configuraciones de inicio de sesión del sistema. Tenga en cuenta los siguientes pasos cuando escriba el módulo de inicio de sesión personalizado: Configuración de la correlación de identidad de entrada.
- Configuración de la correlación de identidad de salida con un reino de destino De manera predeterminada, cuando WebSphere Application Server realiza una solicitud de salida de un servidor a otro en un reino de seguridad distinto, se rechaza la solicitud. Este tema describe las alternativas para habilitar un servidor para que envíe solicitudes de salida a un servidor de destino de un reino distinto. Para obtener más información, consulte Configuración de la correlación de identidad de salida con un reino de destino