Visión general de los métodos de autenticación

La implementación de seguridad de servicios web de WebSphere Application Server da soporte a los siguientes métodos de autenticación: BasicAuth, LTPA (Lightweight Third Party Authentication), firma digital y aserción de identidad.

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.

Cuando se configura WebSphere Application Server para que utilice el método de autenticación BasicAuth, el remitente conecta la señal LTPA (Lightweight Third Party Authentication) como un BinarySecurityToken desde el contexto de seguridad actual o desde la configuración de datos de autenticación básica en el archivo de enlaces de la cabecera del mensaje SOAP. El receptor del mensaje de seguridad de servicios web autentica al remitente validando el nombre de usuario y la contraseña en el registro de usuarios configurado. Con el método LTPA, el remitente conecta el BinarySecurityToken de LTPA que recibió anteriormente en la cabecera del mensaje SOAP. El receptor autentica al remitente validando la señal LTPA y la fecha de caducidad de la señal. Con el método de autenticación de firma digital, el remitente conecta un BinarySecurityToken de un certificado X509 a la cabecera del mensaje de seguridad de servicios web junto con una firma digital del cuerpo del mensaje, la indicación de la hora, la señal de seguridad, o una combinación de estos tres. El receptor autentica al remitente verificando la validez del certificado X.509 y la firma digital utilizando la clave pública del certificado verificado.

El método de autenticación de aserción de identidad es diferente de los otros tres métodos de autenticación. Este método establece la credencial de seguridad del remitente basándose en la relación de confianza. Por ejemplo, puede utilizar el método de autenticación de aserción de identidad cuando un servidor intermediario tenga que invocar un servicio de un servidor en sentido descendente en nombre del cliente pero no disponga de la información de autenticación del cliente. El servidor intermediario podrá establecer una relación de confianza con el servidor en sentido descendente y comprobar la identidad del cliente en el mismo servidor en sentido descendente.

La seguridad de servicios web da soporte a las siguientes modalidades de confianza:
  • BasicAuth
  • Firma digital
  • Confianza asumida previamente

Cuando se utilizan las modalidades de confianza BasicAuth y de firma digital, el servidor intermediario pasa su propia información de autenticación al servidor en sentido descendente para realizar la autenticación. La modalidad de confianza asumida previamente establece una relación de confianza utilizando algún mecanismo externo. Por ejemplo, el servidor intermediario puede pasar mensajes SOAP a través de una conexión SSL (Secure Sockets Layer) con el servidor en sentido descendente y autenticación de certificados de cliente de la capa de transporte.

La implementación de seguridad de servicios web de WebSphere Application Server valida la relación de confianza siguiendo este procedimiento:
  1. El servidor en sentido descendente valida la información de autenticación del servidor intermediario.
  2. El servidor en sentido descendente verifica si el servidor intermediario autenticado está autorizado para la aserción de identidad. Por ejemplo, el servidor intermediario tiene que estar en la lista de confianza del servidor en sentido descendente.

La identidad del cliente puede estar representada por una serie de nombre, un nombre distinguido (DN) o un certificado X.509. La identidad del cliente se adjunta en el mensaje de seguridad de servicios web en un UsernameToken con un nombre de usuario, DN o en un BinarySecurityToken de un certificado. En la tabla siguiente se resumen los tipos de señales de seguridad necesarios para cada método de autenticación.

Tabla 1. Métodos de autenticación y las señales de seguridad correspondientes. Utilice los métodos para autenticar el remitente de un mensaje.
Método de autenticación Señal de seguridad
BasicAuth BasicAuth exige <wsse:UsernameToken> con <wsse:Username> y <wsse:Password>.
Signature Signature exige <ds:Signature> y <wsse:BinarySecurityToken>.
IDAssertion IDAssertion exige <wsse:UsernameToken> con <wsse:Username> o <wsse:BinarySecurityToken> con un certificado de X.509 para la identidad de cliente en función de <idType>. Este método también exige otras señales de seguridad según <trustMode>:
  • If the <trustMode> is BasicAuth, IDAssertion requires <wsse:UsernameToken> with <wsse:Username> and <wsse:Password>.
  • Si <trustMode> es Signature, IDAssertion exige <wsse:BinarySecurityToken>.
LTPA LTPA exige <wsse:BinarySecurityToken> con una señal LTPA.
Un servicio web puede dar soporte a varios métodos de autenticación simultáneamente. El lado del receptor del descriptor de despliegue de servicios web puede especificar todos los métodos de autenticación soportados en el archivo XML ibm-webservices-ext.xmi. El lado del receptor de los servicios web, tal como se muestra en el ejemplo siguiente, está configurado para aceptar todos los métodos de autenticación descritos anteriormente:
<loginConfig xmi:id="LoginConfig_1052760331326">
      <authMethods xmi:id="AuthMethod_1052760331326" text="BasicAuth"/>
      <authMethods xmi:id="AuthMethod_1052760331327" text="IDAssertion"/>
      <authMethods xmi:id="AuthMethod_1052760331336" text="Signature"/>
      <authMethods xmi:id="AuthMethod_1052760331337" text="LTPA"/>
</loginConfig>
<idAssertion xmi:id="IDAssertion_1052760331336" idType="Username" trustMode="Signature"/>
Puede definir sólo un método de autenticación en el descriptor de despliegue de servicios web del lado del remitente. Un cliente de servicios web puede utilizar cualquiera de los métodos de autenticación soportados por la aplicación de servicios web que se trate. En el ejemplo siguiente se muestra la configuración del método de autenticación de aserción de identidad en la extensión del descriptor de despliegue ibm-webservicesclient-ext.xmi del cliente de servicios web:
<loginConfig xmi:id="LoginConfig_1051555852697">
      <authMethods xmi:id="AuthMethod_1051555852698" text="IDAssertion"/>
</loginConfig>
<idAssertion xmi:id="IDAssertion_1051555852697" idType="Username" trustMode="Signature"/>
Tal como se muestra en el ejemplo anterior, el tipo de identidad del cliente es Username y la modalidad de confianza es la firma digital.
Figura 1. Generación y validación de señales de seguridad Generación y validación de señales de seguridad

El manejador de seguridad del remitente invoca el método handle() de una implementación de la interfaz javax.security.auth.callback.CallbackHandler. La interfaz javax.security.auth.callback.CallbackHandler 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 y la inserta en la cabecera del mensaje de seguridad de servicios web.

El manejador de seguridad del receptor compara el tipo de señal de la cabecera del mensaje con los tipos de señales esperados que hay configurados en el descriptor de despliegue. 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 una excepción de 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 (Java™ Authentication and Authorization Service) 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 una excepción de error de SOAP.


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_authmeth
File name: cwbs_authmeth.html