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.
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.
- 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.
- El servidor en sentido descendente valida la información de autenticación del servidor intermediario.
- 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.
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>:
|
LTPA | LTPA exige <wsse:BinarySecurityToken> con una señal LTPA. |
<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"/>
<loginConfig xmi:id="LoginConfig_1051555852697">
<authMethods xmi:id="AuthMethod_1051555852698" text="IDAssertion"/>
</loginConfig>
<idAssertion xmi:id="IDAssertion_1051555852697" idType="Username" trustMode="Signature"/>

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.