Correlaciones de inicio de sesión

Las correlaciones de inicio de sesión que se encuentran en el archivo XML (Extended Markup Language) ibm-webservices-bnd.xmi contienen una configuración de correlación. Esta configuración de correlación define cómo el manejador de seguridad de servicios web correlaciona el elemento <ValueType> de la señal, contenido en la señal de seguridad que se extrae de la cabecera del mensaje, con el método de autenticación correspondiente. El elemento <ValueType> de la señal está dentro de la señal de seguridad que se extrae de una cabecera de mensaje SOAP.

Importante: Hay una diferencia importante entre las aplicaciones de la versión 5.x y la versión 6 y posteriores. La información sólo da soporte a aplicaciones de la versión 5.x que se utilizan con WebSphere Application Server Versión 6.0.x y posteriores. La información no se aplica a las aplicaciones de la Versión 6 y posteriores.

El manejador de seguridad de servicios web del lado del remitente genera y adjunta señales de seguridad basándose en el elemento <AuthMethods> que se ha especificado en el descriptor de despliegue. Por ejemplo, si el método de autenticación es BasicAuth, el manejador de seguridad del lado del remitente genera y adjunta UsernameToken (con nombre de usuario y contraseña) a la cabecera del mensaje SOAP. El tiempo de ejecución de seguridad de servicios web utiliza la interfaz javax.security.auth.callback.CallbackHandler de JAAS (Java™ Authentication and Authorization Service) como proveedor de seguridad para generar señales de seguridad en el lado del cliente (o cuando los servicios web actúan como un cliente).

El manejador de seguridad del remitente invoca el método handle() de una implementación de la interfaz javax.security.auth.callback.CallbackHandler. Esta implementación crea la señal de seguridad y la pasa de nuevo al manejador de seguridad del remitente. El manejador de seguridad del remitente construye la señal de seguridad a partir de la información de autenticación de la matriz de retorno de llamada. A continuación, el manejador de seguridad inserta la señal de seguridad en la cabecera del mensaje de seguridad de servicios web.

La implementación de la interfaz CallbackHandler que se utiliza para generar la señal de seguridad necesaria se define en el elemento <loginBinding> en el archivo de enlaces de seguridad de servicios web ibm-webservicesclient-bnd.xmi. Por ejemplo,
<loginBinding xmi:id="LoginBinding_1052760331526" authMethod="BasicAuth"
      callbackHandler="com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler"/>
El elemento <loginBinding> asocia la interfaz com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler con el método de autenticación BasicAuth. WebSphere Application Server proporciona el conjunto siguiente de implementaciones de la interfaz CallbackHandler que se puede utilizar para crear distintos tipos de señales de seguridad:
com.ibm.wsspi.wssecurity.auth.callback.GUIPromptCallbackHandler
Si no hay datos de autenticación básica definidos en la información de enlace de inicio de sesión (esta información no es la misma que la información de autenticación básica HTTP), el tipo de señal anterior solicita el nombre de usuario y la contraseña en un panel de inicio de sesión. La implementación utiliza los datos de autenticación básica definidos en el enlace de inicio de sesión. Utilice CallbackHandler con el método de autenticación BasicAuth. No utilice esta implementación CallbackHandler en el servidor porque solicitará información de enlace de inicio de sesión.
com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler
Si no hay datos de autenticación básica definidos en el enlace de inicio de sesión (esta información no es la misma que la información de autenticación básica HTTP), la implementación solicita el nombre de usuario y la contraseña utilizando stdin (standard in). La implementación utiliza los datos de autenticación básica definidos en el enlace de inicio de sesión. Utilice esta implementación CallbackHandler con el método de autenticación BasicAuth. No utilice esta implementación CallbackHandler en el servidor porque solicitará información de enlace de inicio de sesión.
Restricción: Si tiene un cliente multihebra y varias hebras intentan leer en la entrada estándar al mismo tiempo, todas las hebras no obtendrán de manera satisfactoria la información de nombre de usuario y contraseña. Por consiguiente, no puede utilizar la implementación com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler con un cliente de varias hebras donde varias hebras pueden intentar obtener datos de standard in simultáneamente.
com.ibm.wsspi.wssecurity.auth.callback.NonPromptCallbackHandler
Esta implementación CallbackHandler no realiza ninguna solicitud. En su lugar, utiliza los datos de autenticación básica definidos en el enlace de inicio de sesión (esta información no es la misma que la información de autenticación básica HTTP). Esta implementación CallbackHandler está concebida para su uso con el método de autenticación BasicAuth. Debe definir los datos de autenticación básica en la información de enlace de inicio de sesión de esta implementación CallbackHandler. Puede utilizar esta implementación cuando los servicios web se ejecuten como un cliente y se tenga que enviar la autenticación básica (<wsse:UsernameToken>) a la llamada en sentido descendente.
com.ibm.wsspi.wssecurity.auth.callback.LTPATokenCallbackHandler
CallbackHandler genera señales LTPA (Lightweight Third Party Authentication) a partir del sujeto JAAS (sujeto de invocación) run as del contexto de seguridad actual de WebSphere Application Server. No obstante, si hay datos de autenticación básica definidos en la información de enlace de inicio de sesión (no en la información de autenticación básica HTTP), la implementación utiliza los datos de autenticación básica y la señal LTPA generada. Los valores URI de tipo de señal y Nombre local de tipo de señal se deben definir en la información de enlace de inicio de sesión de esta implementación CallbackHandler. El tipo de valor de señal se utiliza para validar la señal en la configuración de enlace del remitente de solicitudes y del receptor de solicitudes. El tiempo de ejecución de seguridad de servicios web inserta la señal LTPA como una señal de seguridad binaria (<wsse:BinarySecurityToken>) en la cabecera del mensaje SOAP. El tipo de valor es obligatorio. (Consulte LTPA para obtener más información). Utilice esta implementación CallbackHandler con el método de autenticación LTPA.
En la Figura 1 se muestra el manejador de seguridad del remitente en el proceso del mensaje del remitente de solicitudes.
Figura 1. Proceso del mensaje SOAP del remitente de solicitudesProceso de mensaje SOAP de remitente de solicitud
Puede configurar el servidor de seguridad del lado del remitente para dar soporte a varios métodos de autenticación y varios tipos de señales de seguridad. En los pasos siguientes se describe el proceso del mensaje SOAP del remitente de solicitudes:
  1. Después de recibir un mensaje, el manejador de seguridad de servicios web del receptor compara el tipo de señal (en la cabecera del mensaje) con los tipos de señales esperados que hay configurados en el descriptor de despliegue.
  2. El manejador de seguridad de servicios web extrae la señal de seguridad de la cabecera del mensaje y correlaciona el elemento <ValueType> de la señal con el método de autenticación correspondiente. La configuración de correlación se define en el elemento <loginMappings> del archivo XML ibm-webservices-bnd.xmi. Por ejemplo:
    <loginMappings xmi:id="LoginMapping_1051977980074" authMethod="LTPA"
          configName="WSLogin">
         <callbackHandlerFactory xmi:id="CallbackHandlerFactory_1051977980081"
         classname="com.ibm.wsspi.wssecurity.auth.callback.WSCallbackHandlerFactoryImpl"/>
          <tokenValueType xmi:id="TokenValueType_1051977980081"
          uri="http://www.ibm.com/websphere/appserver/tokentype/5.0.2" localName="LTPA"/>
    </loginMappings>

    La interfaz com.ibm.wsspi.wssecurity.auth.callback.CallbackHandlerFactory es una fábrica para javax.security.auth.callback.CallbackHandler.

  3. El tiempo de ejecución de seguridad de servicios web inicia la clase de implementación de la fábrica y pasa la información de autenticación de la cabecera de seguridad de servicios web a la clase de fábrica mediante los métodos set.
  4. El tiempo de ejecución de seguridad de servicios web invoca el método newCallbackHandler() para obtener el objeto javax.security.auth.CallbackHandler, que genera la señal de seguridad necesaria.
  5. Cuando el manejador de seguridad recibe un BinarySecurityToken de LTPA, utiliza la configuración de inicio de sesión JAAS WSLogin y el método newCallbackHandler() para validar la señal de seguridad. Si no se encuentra ninguno de los tipos de señales esperados en la cabecera de seguridad de servicios web del mensaje SOAP, la solicitud se rechaza con un error de SOAP. En el caso contrario, se utiliza el tipo de señal para correlacionarse con una configuración de inicio de sesión JAAS para validar la señal. Si la autenticación es satisfactoria, se crea un sujeto JAAS y se asocia con la hebra de ejecución. Si no es satisfactoria, se rechaza la solicitud con un error de SOAP.
    En la tabla siguiente se muestran los métodos de autenticación y las configuraciones de inicio de sesión JAAS.
    Tabla 1. Métodos de autenticación y configuraciones de inicio de sesión JAAS. Los métodos de autenticación se correlacionan con la configuración de inicio de sesión JAAS para validar la señal.
    Método de autenticación Configuración de inicio de sesión JAAS
    Autenticación básica WSLogin
    Firma system.wssecurity.Signature
    LTPA WSLogin
    IDAssertion system.wssecurity.IDAssertion
    En la Figura 2 se muestra el manejador de seguridad del receptor en el proceso del mensaje del receptor de solicitudes.
    Figura 2. Proceso del mensaje SOAP del receptor de solicitudesProceso de mensaje SOAP de destinatario de solicitud
    El elemento <LoginMapping> predeterminado se define en los siguientes archivos:
    • Archivos ws-security.xml de nivel de célula y ws-security.xml de nivel de servidor
    Si no se define nada en la información del archivo de enlace, se utiliza el archivo ws-security.xml predeterminado. No obstante, un administrador puede alterar temporalmente el valor predeterminado definiendo un nuevo elemento <LoginMapping> en el archivo de enlaces.
  6. El cliente lee la información de enlace predeterminado en el archivo ${dir_instalación}/properties/ws-security.xml.
  7. El componente de tiempo de ejecución de servidor carga los siguientes archivos si existen:
    • Archivo ws-security.xml de nivel de célula y archivo ws-security.xml de nivel de servidor. Los dos archivos se fusionan en el tiempo de ejecución para formar un conjunto eficaz de información de enlace predeterminado.

    En un servidor de aplicaciones base, el componente de tiempo de ejecución del servidor sólo carga el archivo ws-security.xml a nivel de servidor. El archivo ws-security.xml a nivel de servidor y la información de enlace de seguridad de servicios web de las aplicaciones se gestionan utilizando la consola administrativa. Puede especificar la información de enlace durante el despliegue de las aplicaciones mediante la consola administrativa. La política de seguridad de servicios web se define en la extensión del descriptor de despliegue (ibm-webservicesclient-ext.xmi) y los enlaces se almacenan en la extensión del enlace de IBM® (ibm-webservicesclient-bnd.xmi). No obstante, el archivo ${dir_instalación}/properties/ws-security.xml define el valor de enlace predeterminado del cliente. Si no se especifica información de enlace en el archivo de enlaces, el tiempo de ejecución lee la información de enlace en el archivo ${dir_instalación}/properties/ws-security.xml predeterminado.


Icon that indicates the type of topic Concept topic



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