Puede crear su propia implementación de señal de inicio de sesión único.
La implementación de la señal de inicio de sesión único
se establece en el sujeto de inicio de sesión y se añade a la respuesta HTTP como una cookie HTTP.
Acerca de esta tarea
El nombre de
cookie es la concatenación de las API (Application Programming Interface)
SingleSignonToken.getName y SingleSignonToken.getVersion. No hay delimitadores. Cuando añada una señal de
inicio de sesión único al sujeto, también se propaga horizontalmente y en sentido descendente, si el sujeto
se utiliza para otras peticiones web. Debe deserializar la señal de inicio de sesión único
cuando lo reciba desde el inicio de sesión de la propagación. Escriba su
propia implementación si desea lograr cualquiera de las acciones
siguientes tareas:
- Aislar los atributos en su propia implementación.
- Serializar la información utilizando la serialización personalizada. Cifre la información, ya que sale con la respuesta HTTP y está disponible
en Internet. Debe deserializar o
descifrar los bytes en el destino y añadir dicha información al
Subject de nuevo.
- Afectar a la exclusividad general del Subject utilizando la API getUniqueID.
Para implementar una señal de inicio de sesión único personalizada, complete los pasos siguientes:
- Escriba una implementación personalizada de la interfaz SingleSignonToken.
Hay varios métodos distintos para implementar la interfaz
SingleSignonToken. No obstante, asegúrese de que los métodos necesarios
para la interfaz SingleSignonToken y la interfaz de señales estén
completamente implementados.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Después de
implementar esta interfaz, puede colocarla en el directorio raíz_servidor_apl/classes.
Alternativamente,
puede ubicar la clase en cualquier directorio privado. Sin embargo,
asegúrese de que el cargador de clases de
WebSphere
Application Server pueda localizar la clase y que se le otorguen los
permisos adecuados. Puede añadir el archivo JAR
(Java™
Archive) o directorio que contiene esta clase en el archivo
server.policy para que tenga los permisos que necesita el
código de servidor.
Tras implementar esta interfaz, puede colocarla en el directorio raíz_perfil/classes.
Si desea más información
sobre las clases, consulte Creación de un subdirectorio de clases en el perfil para clases personalizadas.
Consejo: Todos los tipos de
señales definidas por la infraestructura de propagación tienen
interfaces similares. Básicamente, los tipos de señales son
interfaces de marcador que implementan la interfaz
com.ibm.wsspi.security.token.Token. Esta interfaz define la mayoría de los
métodos. Si tiene pensado implementar más de un tipo de señal, piense en
crear una clase abstracta que implemente la interfaz
com.ibm.wsspi.security.token.Token.
Todas las implementaciones de señales,
incluida la señal de inicio de sesión único, podrían ampliar la clase abstracta y, con ello, la mayoría del trabajo habrá finalizado.
Para ver una implementación de la señal de inicio de sesión único, consulte Ejemplo: implementación de com.ibm.wsspi.security.token.SingleSignonToken
- Añada y reciba la señal de inicio de sesión único
personalizado durante los inicios de sesión de
WebSphere
Application Server. Esta tarea concluye generalmente
con la adición de un módulo de inicio de sesión personalizado a las
distintas configuraciones de inicio de sesión del sistema y aplicaciones.
No obstante, para deserializar la información, debe conectar un módulo de inicio de sesión personalizado, que se describe en un paso
posterior. Después de crear una instancia del objeto en el módulo de inicio de
sesión, puede añadirlo al Subject durante el método commit.
El ejemplo
de código que aparece en
Ejemplo: Módulo de inicio de sesión de señal de inicio de sesión individual personalizado
muestra cómo determinar si el inicio de sesión es inicial o de propagación
. La diferencia consiste en si el retorno de llamada WSTokenHolderCallback
contiene datos de propagación o no. Si el retorno de llamada no contiene
datos de propagación, inicialice una nueva implementación de señal de
inicio de sesión único personalizada y establézcala en el Subject. Asimismo, busque la cookie
de HTTP cookie de la solicitud HTTP, si el objeto de solicitud HTTP está
disponible en el retorno de llamada.
Puede obtener la señal de inicio de
sesión único personalizada de un inicio de sesión de propagación vertical
y de la solicitud HTTP. No obstante, se recomienda que haga que la señal
esté disponible en ambos lugares, ya que entonces la información llega a
cualquier servidor de aplicaciones frontal, incluido si dicho servidor no
da soporte a la propagación.
Puede hacer que la señal de inicio de
sesión único sea de sólo lectura en la fase de compromiso del módulo de inicio
de sesión. Si hace que la señal sea de sólo lectura, los atributos adicionales
no se pueden añadir a las aplicaciones.
Restricción: - Las cookies HTTP tienen una limitación de tamaño. Las restricciones de tamaño deben incluirse en la documentación del navegador específico.
- El tiempo de ejecución de
WebSphere
Application Server no maneja las cookies que no ha generado, por lo
tanto, el tiempo de ejecución no utiliza esta cookie.
- El objeto SingleSignonToken, cuando está en el Subject, no afecta a la
búsqueda de memoria caché del Subject, si devuelve algo en el método
getUniqueID.
- Obtenga la cookie de HTTP del objeto de
solicitud de HTTP durante el inicio de sesión o bien de una aplicación. El código de ejemplo que se encuentra en Ejemplo: recuperación de cookies HTTP muestra cómo puede recuperar la cookie de HTTP de la solicitud
HTTP, decodificar la cookie para que se devuelva a los bytes originales y crear el objeto
SingleSignonToken personalizado de los bytes.
- Añada el módulo de inicio de sesión personalizado a las
configuraciones de inicio de sesión del sistema
WebSphere
Application Server que ya contengan el módulo
com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule para
recibir versiones serializadas de la señal de propagación personalizada. Como este módulo de inicio de sesión se basa en la información del
sharedState añadido por el módulo de inicio de sesión
com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule, añádalo
después del módulo de inicio de sesión com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule.
Para obtener
más información sobre como añadir el módulo de inicio de sesión personalizado a las
configuraciones de inicio de sesión existentes, consulte Desarrollo de módulos de inicio de sesión personalizados para una configuración de inicio de sesión del sistema para JAAS.