Seguridad en WCF – Mensaje VS Transporte

Hola!


Este artículo tratará de describir las diferentes alternativas que podemos utilizar para aprovechar la seguridad en servicios que nos provee Windows Communication Foundation.


Cuando una aplicación está distribuida, es importante proteger los datos que transmitimos entre los diversos componentes de la aplicación, y las interacciones entre ellos. Es decir, nos interesa que los datos no puedan ser interceptados, modificados, y también el poder controlar quién tiene acceso a la funcionalidad de nuestra aplicación.


Lo que se pretende obtener utilizando seguridad WCF es lo siguiente:



  • Autenticación en el servidor (Service Endpoint Authentication)

  • Autenticación en el cliente (Client Principal Authentication)

  • Integridad de los mensajes

  • Confidencialidad de los mensajes

  • Detección de ataques por repetición (Replay detection): Los ataques por repetición se basan en que un tercero intercepta un mensaje enviado por el cliente al servidor, y vuelve a enviarlo varias veces. (Por ejemplo, peticiones de compra)

WCF trata de obtener dicha seguridad en dos niveles distintos:



  • A nivel de transporte: Es decir, que nos basamos las capas inferiores para proveernos de la seguridad. Esto quiere decir que utilizamos la infraestructura existente para proteger los mensajes. Por ejemplo, utilizar SSL para comunicaciones HTTP, o bien utilizar Kerberos para comunicaciones TCP. WCF se desentiende de proveer confidencialidad, integridad y autenticación. La seguridad empleada depende del transporte que utilicemos, y no está soportado por todos los bindings.

  • A nivel de mensaje: En este nivel, la confidencialidad, integridad y autenticación son provistas directamente por WCF, ya que se incluyen en los mensajes. Para ello, WCF se basa en los estándares WS-Security.

La elección que hagamos en este sentido nos puede impactar en los diferentes bindings que podemos utilizar, ya que no todos soportan uno u otro.


Lo más interesante es que WCF nos permite tomar una alternativa mixta, es decir, utilizar seguridad tanto a nivel de mensaje como de transporte, siempre y cuando el binding que hayamos elegido lo soporte, claro 😉 Si elegimos este escenario, la seguridad a nivel de transporte se encargará de la confidencialidad, integridad y autenticación de las peticiones, mientras que la seguridad a nivel de mensaje se encargará de la autorización. Es decir, en la seguridad a nivel de mensaje es donde especificaremos las credenciales de la manera que más se ajuste a nuestras necesidades utilizando WS-Security, y especificaremos qué operaciones puede realizar un usuario en concreto.


Los tipos de credenciales que se pueden utilizar son los siguientes: 



  • Basic: Se corresponde con la autenticación básica de IIS. Se basa en enviar el par usuario/password al servidor, pero se envía ¡¡¡en texto plano!!!. Cuando se usa este modo, la aplicación deberá estar configurada con una cuenta de usuario concreta que tenga los permisos necesarios para realizar sus tareas.

  • Certificate: El cliente debe utilizar un certificado para autenticarse contra el servidor. Debe establecerse un mapeo entre certificados de cliente y usuarios de Windows en el servidor (se puede hacer con IIS).

  • Digest: Similar a Basic, pero lo que se envía desde el cliente es un Hash de las credenciales. Sigue siendo un sistema débil.

  • Windows: Es similar a la autenticación integrada de Windows que podemos utilizar en IIS. Cuando se utiliza este valor, se supone que el servidor está integrado en un domino que utiliza Kerberos como controlador de dominio. Si el servidor no está basado en Kerberos, o Kerberos falla, se utilizará NTLM.

  • IssuedToken: La autenticación está basada en ADFS. Usa tokens SAML.

Las diferencias más importantes entre ambos tipos de seguridad son los siguientes:



  • La seguridad basada en transporte se lleva a cabo entre cada punto de la conexión. Si la seguridad está basada en mensajes, la seguridad es de extremo a extremo. Es decir, si usamos HTTPS, el mensaje será cifrado y descifrado en cada máquina por la que pase nuestro mensaje, con lo que deberemos confiar en todos los puntos intermedios por los que pasa. Si usamos seguridad basada en mensajes, los únicos que cifrarán o descifrarán el mensaje serán el emisor (que lo cifrará) y el destinatario (que lo descifrará).

  • HTTPS es un protocolo que está implementado en tarjetas, con lo que se puede acelerar por hardware, mientras que la seguridad basada en mensajes puede incurrir en penalizaciones del rendimiento.

  • Desde el punto de vista de la interoperabilidad, la mejor opción a día de hoy sigue siendo usar Web Services «tradicionales» (usando el binding basicHttpBinding) sobre SSL. La razón es sencilla, existen muchas más plataformas que implementan Web Services que plataformas que implementen el estandar WS-Security 😉

  • La seguridad basada en mensajes es muy flexible. Se puede utilizar el tipo de credenciales que se desee, siempre y cuando el cliente y el servidor se pongan de acuerdo.

Pues esto es todo por hoy…


Un saludo!

6 comentarios sobre “Seguridad en WCF – Mensaje VS Transporte”

  1. Hola,

    muy buenartículo.

    ¿algunos buenos ejemplos completos de seguridad en WCF en este caso?

    Conexión de cliente a WCF service a través de internet (HTTP)

    Saludos.

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *