Con el soporte de inicio de sesión único (SSO), los usuarios web pueden autenticarse una vez cuando accede a recursos web entre varios servidores WebSphere Application Server. Los mecanismos de inicio de sesión de formulario para aplicaciones web requieren que SSL esté habilitado. Utilice este tema para
configurar el inicio de sesión único la primera vez.
Antes de empezar
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
SSO sólo recibe soporte
cuando LTPA (Lightweight Third Party Authentication) es el mecanismo de
autenticación.
SSO sólo recibe soporte
cuando LTPA (Lightweight Third Party Authentication) es el mecanismo de
autenticación.
Cuando SSO está habilitado, se crea una cookie que contenga la
señal LTPA y se inserta en la respuesta HTTP.
Cuando el usuario accede a otro recurso web en cualquier otro proceso de WebSphere Application Server del
mismo dominio DNS (servicio de nombre de dominio), se envía la cookie en la petición.
A continuación, se extrae la señal LTPA de la cookie y se valida. Si la petición se realiza entre distintas células de WebSphere Application Server, es necesario compartir las
claves LTPA y el registro de usuario entre las células para que SSO funcione.
Los nombres de reino de cada sistema del dominio SSO son sensibles a las
mayúsculas y minúsculas y deben ser idénticos.
Para el sistema operativo local, el nombre de reino es el nombre de
dominio, si el dominio está en uso. Si no se utiliza el dominio, el nombre
de reino es el nombre de la máquina.
![[Linux]](../images/linux.gif)
![[AIX HP-UX Solaris]](../images/unix.gif)
El nombre del reino
es el mismo que el nombre de host.
Para LDAP
(Lightweight Directory Access Protocol), el nombre de reino es el host:reino
de puerto del servidor LDAP. El mecanismo de autenticación LTPA requiere que habilite SSO, si alguna de las
aplicaciones web tiene el inicio de sesión de formulario como método de autenticación.
Debido a que
el inicio de sesión único es un subconjunto de LTPA, se recomienda que consulte LTPA (Lightweight Third Party Authentication) si desea más información.
Al habilitar la propagación de atributos de seguridad, la cookie
siguiente se añade siempre a la respuesta:
- LtpaToken2
- LtpaToken2 contiene cifrado más complejo y permite añadir varios atributos
a la señal. Esta señal contiene la identidad de autenticación e información
adicional como, por ejemplo, los atributos utilizados para ponerse en
contacto con el servidor de inicio de sesión original y la clave de
memoria caché exclusiva para buscar el Subject al tener en cuenta algo más
que la identidad para determinar la exclusividad.
Nota: La siguiente cookie se añade opcionalmente a la respuesta cuando
el distintivo Modalidad interoperativa está habilitado:
- LtpaToken
- LtpaToken se utiliza para interoperar con releases anteriores de
WebSphere Application Server. Esta señal sólo contiene el atributo de identidad de
autenticación.
Nota: LtpaToken se genera para releases anteriores a
WebSphere Application Server Versión 5.1.0.2.
LtpaToken2 se genera para
WebSphere Application Server Versión 5.1.0.2 y posteriores.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Nota: LtpaToken se genera para releases anteriores a
WebSphere Application Server
Versión 5.1.1.
LtpaToken2 se genera para
WebSphere Application Server Versión 5.1.1 y posteriores.
Tabla 1. Tipos de seña LTPA. En esta tabla se describen los tipos de señal LTPA. Tipo de señal |
Finalidad |
Cómo se especifica |
Sólo LtpaToken2 |
Éste es el tipo de señal por omisión. Utiliza la
potencia de cifrado de relleno AES-CBC-PKCS5 (tamaño de clave de 128
bits). Esta señal es más potente que el LtpaToken anterior utilizado en releases anteriores a WebSphere Application Server
Versión 6.02.
Esta es la opción recomendada cuando la interoperabilidad con releases
anteriores no es necesaria. |
Inhabilite la opción Modalidad de interoperatividad del panel de
configuración SSO en la consola administrativa.
Para acceder a este panel, siga estos pasos:- Pulse Seguridad > Seguridad global.
- En Seguridad Web, pulse Inicio de sesión único (SSO).
|
LtpaToken y LtpaToken2 |
Se utiliza para interactuar con releases anteriores a WebSphere Application Server Versión 5.1.1.
La cookie
LtpaToken anterior está presente junto con la nueva cookie LtpaToken2. Si
las claves LTPA se comparten correctamente, deberá poder
interactuar con cualquier versión de WebSphere utilizando esta opción. |
Habilite la opción Modalidad de interoperatividad del panel de
configuración SSO en la consola administrativa.
Para acceder a este panel, siga estos pasos:- Pulse Seguridad > Seguridad global.
- En Seguridad Web, pulse Inicio de sesión único (SSO).
|
Acerca de esta tarea
Los pasos siguientes son necesarios para configurar SSO por primera vez.
Procedimiento
- Abra la consola administrativa.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Escriba http://host_local:número_puerto/ibm/console para acceder a la
consola administrativa en un navegador web.
Escriba http://nombre_servidor:número_puerto/ibm/console para acceder a la consola administrativa del navegador web.
El puerto 9060 es el número de puerto por omisión para
acceder a la consola administrativa.
Durante la instalación, sin embargo, puede
que haya especificado otro número de puerto. Utilice el número de puerto
adecuado.
- Pulse Seguridad > Seguridad global.
- En Seguridad Web, pulse Inicio de sesión único (SSO).
- Pulse la opción Habilitado si la opción SSO está
inhabilitada. Tras pulsar la opción Habilitado, complete los pasos restantes para habilitar la seguridad.
- Pulse Requiere SSL si todas las solicitudes van a utilizar HTTPS.
- Entre los nombres de dominio plenamente cualificados en el
campo Nombre de dominio donde el SSO esté en vigor. Si especifica nombres de dominio, deben estar totalmente
calificados. Si el nombre de dominio no está plenamente cualificado, WebSphere Application Server no
establece un valor de nombre de dominio para la cookie LtpaToken y SSO sólo es válido para el servidor que ha
creado la cookie.
Cuando especifique varios dominios, puede utilizar los delimitadores siguientes: un punto y coma (;), un espacio
( ), una coma (,) o una barra vertical (|). WebSphere Application Server busca los dominios
especificados en orden de izquierda a derecha. Todos los dominios se comparan con el nombre
de host de la petición HTTP hasta que se encuentra la primera
coincidencia.
Por ejemplo, si especifica
ibm.com;
austin.ibm.com y se encuentra primero una coincidencia en el dominio
ibm.com,
WebSphere Application Server no continuará la búsqueda
de coincidencias en el dominio austin.ibm.com. No obstante, si no se encuentra una coincidencia en los
dominios ibm.com o
austin.ibm.com, WebSphere Application Server no establece un dominio para la cookie LtpaToken.
Tabla 2. Valores para configurar el campo Nombre de dominio. En esta tabla se describen los valores para configurar el campo Nombre de dominio.
Tipo de valor de nombre de dominio |
Ejemplo |
Finalidad |
En blanco |
|
El dominio no se ha establecido. Esto provoca que el navegador establezca el dominio en el nombre de host de la solicitud. El inicio de sesión es válido sólo en dicho host único. |
Nombre de dominio único |
austin.ibm.com |
Si la solicitud se realiza a un host del dominio configurado, el inicio de sesión es válido para todos los
hosts de dicho dominio. De lo contrario, es válido sólo en el nombre de host de la solicitud. |
UseDomainFromURL |
UseDomainFromURL |
Si la solicitud se realiza a un host del dominio configurado, el inicio de sesión es válido para todos los
hosts de dicho dominio. De lo contrario, es válido sólo en el nombre de host de la solicitud. |
Varios nombres de dominios |
austin.ibm.com;raleigh.ibm.com |
El inicio de sesión es válido para todos los hosts del dominio del nombre de host de solicitud. Atención: El inicio de sesión único entre dominios no se soporta. Por ejemplo, chicago.xxx.com y cleveland.yyy.com , donde los dominios DNS son diferentes.
|
Varios nombres de dominio y UseDomainFromURL |
austin.ibm.com;raleigh.ibm.com; UseDomainFromURL |
El inicio de sesión es válido para todos los hosts del dominio del nombre de host de solicitud. Atención: El inicio de sesión único entre dominios no se soporta. Por ejemplo, chicago.xxx.com y cleveland.yyy.com , donde los dominios DNS son diferentes.
|
Si especifica UseDomainFromURL,
WebSphere Application Server establece el valor de nombre de dominio SSO
en el dominio del host que efectúa la petición. Por ejemplo, si una petición HTTP viene de
server1.raleigh.ibm.com,
WebSphere Application Server establece el valor de nombre de dominio SSO en
raleigh.ibm.com.
Consejo: El valor UseDomainFromURL no es sensible a las mayúsculas y
minúsculas. Puede escribir usedomainfromurl para utilizar este valor.
Para obtener más información, consulte Valores de inicio de sesión único.
- Opcional: Habilite la opción Modalidad de interoperatividad si desea dar soporte a las conexiones SSO en
WebSphere Application Server versión 5.1.1 o posteriores para que puedan interactuar con versiones anteriores
del servidor de aplicaciones.
Esta opción establece la señal LtpaToken antigua en la respuesta
para que se pueda enviar a otros servidores que sólo funcionan con este
tipo de señal. De lo contrario, sólo se añade la señal LtpaToken2 a la
respuesta.
Si se tiene en cuenta el rendimiento, y sólo se va a conectar a servidores de la
Versión 6.1 o posterior y no va a ejecutar productos que dependan de LtpaToken, no
habilite la modalidad interoperativa. Si no se habilita la modalidad interoperativa, no
se devuelve LtpaToken como respuesta.
- Opcional: Habilite la opción
Propagación de atributos de seguridad de entrada Web si desea que se
añada información durante el inicio de sesión en un servidor frontal específico
para propagarse a otros servidores frontales. La señal SSO no contiene atributos sensibles, pero entiende dónde
existe el servidor de inicio de sesión original en los casos en que necesita
ponerse en contacto con ese servidor para recuperar la información serializada. También contiene el valor de búsqueda de memoria caché para buscar la
información serializada en DynaCache, si ambos servidores frontales están
configurados en el mismo dominio de réplica DRS. Para obtener más información, consulte Propagación de atributos de seguridad.
Importante: Si las sentencias siguientes son
verdaderas, se recomienda que inhabilite la opción
Propagación de atributos
de seguridad de entrada Web por motivos de rendimiento:
- No se añade información específica al Sujeto durante un inicio de sesión
que no se pueda obtener en un servidor frontal diferente.
- No ha añadido atributos personalizados a la señal PropagationToken
utilizando interfaces de programación de aplicaciones (API)
WSSecurityHelper.
Si descubre que le falta información personalizada en el Sujeto,
vuelva a habilitar la opción
Propagación de atributos de seguridad de
entrada Web para comprobar si la información se propaga
satisfactoriamente a otros servidores de aplicaciones frontales.
Las dos propiedades personalizadas siguientes pueden ayudar a
mejorar el rendimiento cuando la propagación de atributos de seguridad
está habilitada:
- com.ibm.CSI.propagateFirstCallerOnly
El valor predeterminado de esta propiedad es true. Si esta
propiedad personalizada se establece en true, el primer
emisor de la señal de propagación que permanece en la
hebra se registra cuando la propagación de atributos de
seguridad está habilitada. Cuando se establece esta propiedad como false, se registran todos los conmutadores del llamador, lo que podría afectar al rendimiento.
- com.ibm.CSI.disablePropagationCallerList
Si esta
propiedad personalizada se establece en true, la
posibilidad de añadir una lista de emisores o hosts a la señal de
propagación está completamente inhabilitada. Esta función es
beneficiosa cuando la lista de emisores o hosts de la señal de
propagación no es necesaria en el entorno.
- Pulse Aceptar.
Qué hacer a continuación
Para que los cambios entren en vigor, guarde, detenga y reinicie todos los gestores, nodos y servidores del despliegue del producto.