Autenticación entre servicios

LIBP-0282 (Libro de pautas)

Utilizar firmas digitales para comprobar la identidad de los remitentes

Se debe controlar que cada mensaje que se envía, desde un servicio web hacia otros, incluya su clave secreta para demostrar su identidad.

De la misma manera, las respuestas recibidas deben incluir algún mecanismo que permita reconocer la autoría de las mismas. Se pueden emplear, por ejemplo, firmas digitales, de tal manera que si parte del mensaje se encuentra firmado digitalmente, se podría comprobar la identidad del remitente por parte del servicio web.

Se pueden emplear mecanismos basados en el protocolo de transporte como SSL/TLS X509 Certificate. Este mecanismo sólo es válido cuando existe una conexión directa entre el consumidor y el proveedor de servicio.

También se pueden emplear mecanismos basados en tokens que se incluyen dentro del mensaje. El estándar WS-Security incorpora un gran número de tokens que pueden ser empleados en este caso; Username Token, X509 Certificate, SAML assertions, etc. Este mecanismo de autenticación no tiene los problemas de los mecanismos basados en el transporte, ya que las credenciales pueden viajar aunque no exista una conexión directa entre el consumidor y el proveedor.

Cuando se emplean tokens, es necesario que estos sean transmitidos de forma segura para evitar ataques de replay. Esto puede se consigue mediante la firma del token dentro del mensaje SOAP, junto a un TimeStamp o IDMessage, por lo que se recomenienda incluir en la firma la cabecera de WS-Addressing

Pautas

TítuloCarácter
WS-SecurityRecomendada
Elemento SecurityRecomendada
Protección del mensajeObligatoria
Token de seguridadRecomendada
Codificación de tokens de seguridad binariosRecomendada
Http AutenticationNo Recomendada
XML tokensRecomendada

WS-Security

Utilizar WS-Security para la autenticación entre servicios

El estándar WS-Security define una especificación que implementa una serie de mejoras al marco de trabajo de mensajería SOAP con el objetivo de mejorar la protección de los mensajes.

Para ello, se basa en dos mecanismos esenciales:

  • La integridad y confidencialidad de los mensajes.
  • Autenticación de un mensaje individual.

WS-Security especifica un procedimiento que permite añadir tokens de seguridad a los mensajes en los intercambios de información. Un token de seguridad está compuesto por varias declaraciones de seguridad. No se especifica ningún tipo de token de seguridad a aplicar con WS-Security dado el carácter extensible del estándar y soportar varios formatos actualmente.

Elemento Security

Anteponer los elementos que se añaden a la cabecera Security a los elementos existentes

De esta forma, el bloque de cabecera Security representa los pasos de firmado y cifrado que el emisor realizó para crear el mensaje. Esta regla de anteposición asegura que la aplicación receptora pueda procesar los sub-elementos en el orden en el que aparecen en el bloque de cabecera Security y, de esta forma, no encontrarse más adelante con dependencias entre los subelementos. La especificación no obliga a seguir ningún orden específico a la hora de procesar los subelementos pudiendo utilizar la aplicación receptora cualquier política que crea necesaria

Protección del mensaje

Rechazar el mensaje WS-Security si no se puede confirmar su validez

Cuando un receptor de un mensaje WS-Security no puede verificar la firma, el token de seguridad recibido no contiene las afirmaciones suficientes o algunas de ellas no contiene los valores esperados, la especificación recomienda que el mensaje sea rechazado.

Token de seguridad

Cualquier token de seguridad que se desee transmitir debe ser un elemento hijo del elemento Security

Un token de seguridad es una colección de afirmaciones hechas por una entidad. Para transmitir tokens de seguridad (es decir afirmaciones de seguridad realizadas por un interlocutor) la especificación propone el elemento Security de forma que cualquier token de seguridad que se desee transmitir sea un elemento hijo de éste.

Por su diseño, el elemento Security es extensible para soportar muchos tipos de información relativos con la seguridad. Esta especificación, además de definir ciertos tokens de seguridad, define las reglas de procesamiento para utilizar los elementos definidos en la especificación W3C XML Digital Signature y XML Encryption. Si se utiliza cifrado o firma digital en combinación con tokens de seguridad, éstos últimos deberán ser utilizados de forma que se respeten las reglas de procesamiento definidas por esta especificación

Codificación de tokens de seguridad binarios

Utilizar X509 Certificates cuando el formato del token es binario u otro que no sea XML. Además, se recomienda incluir en la firma la cabecera WS-Addressing.

Cualquier token de seguridad basado en XML puede ser especificado en la cabecera Security. Sin embargo, cuando el formato del token es binario u otro que no sea XML (certificados X.509 o tickets de Kerberos) se requiere un formato de codificación especial para que pueda ser incluido.

Un token de seguridad binario tiene dos atributos que son utilizados para poder interpretarlo. El atributo ValueType indica de qué tipo es el token de seguridad, por ejemplo, un ticket de Kerberos.

No se recomienda el uso de Kerberos.

Http Autentication

No utilizar mecanismos de autenticación basados en HTTP Basic Autentication

Los procesos de autenticación entre un consumidor y un proveedor de Servicio Web pueden ser realizados por una gran variedad de mecanismos. No se recomienda el uso de mecanismos basados en el protocolo de transporte HTTP Autentication

XML tokens

Se recomienda el uso de SAML assertions

Se recomienda el uso de SAML assertions. Además, en estos casos, también se recomienda firmar el Token junto con la cabecera WS-Addressing.

Contenidos relacionados

Recursos
Área: Desarrollo » Seguridad » Servicios Web
Código Título Tipo Carácter
RECU-0217 WS-Security Especificación Recomendado
RECU-0211 Conceptos de seguridad en los servicios WEB Especificación Recomendado
RECU-0598 WS-Addressing Especificación Recomendado