Windows Communication Foundation (en lo sucesivo, WCF) es, tecnologa para desarrollar servicios Web XML nos basbamos

requerimientos avanzados de las aplicaciones empresariales, que simplemente una comunicacin entre cliente y servicio (como hacen Los siguientes puntos/necesidades por los que "dar el salto":

en definitiva, una nueva en ASMX (ASP.NET). Los necesitan ms cosas que los servicios Web bsicos).

Seguridad avanzada orientada a mensajes en las comunicaciones con los servicios, incluyendo diferentes tipos de autenticacin, autorizacin, cifrado, no tampering, firma, etc. Mensajera estable y confiable. Soporte de transacciones distribuidas entre diferentes servicios. Mecanismos de direccionamiento y enrutado. Metadatos para definir requerimientos como polticas. Soporte para adjuntar grandes cantidades de datos binarios en llamadas/respuestas a servicios (imgenes y/o adjuntos de cualquier tipo). Una de las principales razones por las que utilizar WCF sea concretamente la seguridad, tanto por su importancia en el mundo de las comunicaciones remotas como por sus amplias posibilidades en WCF (es probablemente uno de los aspectos con ms variantes de WCF). En el mundo de las comunicaciones, "no debemos fiarnos de nadie"; cada extremo de las comunicaciones debe poder identificarse con el otro extremo, y debemos poder establecer lmites de qu es lo que el otro puede o debe hacer para consumir mi servicio. Adems, especialmente en las comunicaciones sobre entornos pblicos (como Internet), debemos proteger la informacin, ofreciendo confidencialidad e integridad de los datos enviados. Las posibilidades que nos ofrece WCF sobre diferentes aspectos de la seguridad en las comunicaciones de nuestros servicios. Una vez centrados en la seguridad, vamos a ver entonces qu reas pueden ser interesantes e importantes en las comunicaciones. Probablemente no hablemos de todas, pero por lo menos vamos a poner un poco de luz sobre las reas de seguridad que me parecen ms importantes para el diseo y desarrollo de una aplicacin distribuida y/o de un servicio-SOA. Son las siguientes reas: Autenticacin. Requiere al llamador identificarse con una prueba de identidad. Autorizacin. Confirmar que el llamador est autorizado para acceder a un recurso. Integridad de mensajes. Asegurarnos de que un mensaje y sus datos no han sido cambiados "durante el viaje". Confidencialidad de los mensajes. Nos aseguramos de que solamente el destinatario de un mensaje puede ver y entender el mensaje en su forma original.

A nivel de implementacin tecnolgica, WCF nos ofrece un conjunto de caractersticas para asegurar la transferencia de datos (en forma de mensajes) en las comunicaciones y tambin el acceso a los recursos (componentes de negocio, fuentes de datos, etc.). La transferencia de los mensajes se puede asegurar bsicamente de dos formas: Seguridad basada en el transporte (SSL/HTTPS). Seguridad basada en los mensajes SOAP. La seguridad basada en el transporte la proporciona precisamente dicho transporte, normalmente HTTPS, y es algo que ya se poda utilizar con los servicios Web bsicos. El problema es que este tipo de seguridad "nos deja atados" a un protocolo (HTTPS) y a un tipo de seriacin (XML) de los datos de la comunicacin. Sin embargo, la seguridad a nivel de mensajes SOAP es completamente independiente del protocolo de transporte que elijamos. Incluso podramos cambiarlo en el futuro de forma muy sencilla, un ejemplo claro del gran desacoplamiento que ofrece WCF (desacoplamiento del protocolo de transporte, desacoplamiento de los procesos de hosting, desacoplamiento del servicio y desacoplamiento del comportamiento). Por ltimo, el aseguramiento del acceso a los recursos se realiza basndonos en identidades del llamador y en autorizaciones aplicadas en los recursos. Microsoft dice que "WCF es seguro por defecto". Esto es as porque exceptuando el enlace (binding) bsico basicHttpBinding, el resto de enlaces proporcionados por Microsoft tienen habilitada la seguridad. Adems, el binding especificado por defecto en un proyecto creado con el asistente de Visual Studio es el wsHttpBinding, que soporta los estndares de seguridad de WS-Security; por eso se puede afirmar lo anterior. Hasta ahora he hecho una presentacin de diferentes aspectos relacionados con la seguridad en WCF. Sin embargo, debido a lo amplio de cada uno de los temas introducidos, en este artculo vamos a limitarnos a dos de los aspectos principales que he introducido: la autenticacin y la autorizacin, dejando para un prximo artculo una discusin ms profunda sobre la integridad y confidencialidad de los mensajes. Autenticacin con WCF El proceso de autenticacin permite a un cliente o incluso a otro servicio identificarse y que el servicio pueda confirmar si la otra parte es quien dice ser que es. La autenticacin busca responder a la pregunta Eres quien dices que eres? Esto lo entiende todo el mundo. Por ejemplo, si en una tienda cuando voy a pagar con una tarjeta de crdito me dicen que demuestre quin soy, me piden autenticarme o identificarme con el DNI o pasaporte. El DNI es, en definitiva, una credencial de mi identidad personal en el mundo real. En el mundo del software, la credencial ms comn es un nombre de usuario acompaado de una clave. Hay muchos ms tipos de credenciales en el mundo del software, adems de usuario/password, como los certificados X.509 con claves privadas, credenciales Kerberos, tokens SAML (Security Access Markup Language), etc. Cuando las credenciales se comunican, entonces se llaman testigos

(tokens) de seguridad. Los tipos de credenciales soportados directamente por WCF son: Acceso annimo La primera opcin de credenciales posibles es "Ninguna", es decir, que el cliente sea annimo. Sin embargo, en el servidor, si la comunicacin se quiere asegurar (cifrar), an en el caso de que el cliente sea annimo, el servicio hace uso de un certificado de servidor para que el cliente pueda asegurarse y determinar la identidad del servicio. Adems, el cifrado se basar en las claves del certificado de servidor. Esto es muy similar a como funciona SSL (un sitio Web con acceso HTTPS que permite acceso annimo). Actualmente WCF no tiene implementadas las polticas, atributos y por lo tanto un proveedor WCF nativo de autorizacin para AzMan (Windows Authorization Manager). Es algo que podra implementarse mediante custom behaviors e inspectors, o por supuesto mediante cdigo propio in-line en la implementacin de cada mtodo de un servicio. Por supuesto, no estoy teniendo en cuenta que siempre se puede utilizar AzMan por debajo de los ASP.NET Role Providers, puesto que existe un proveedor de roles de ASP.NET para AzMan llamado AuthorizationStoreRoleProvider (disponible en .NET 2.0), pero es un proveedor que simplemente mapea roles de AzMan para que se puedan tratar como roles ASP.NET, por lo que se pierde toda la potencia y desacoplamiento de los permisos de AzMan (tasks y operations), que son los que se deberan poder aplicar a los recursos a autorizar (mtodos del servicio), y no simplemente aplicar a los recursos autorizacin basada en pertenencia a roles. Vamos a ver cmo realizar autorizaciones en WCF con cada uno de los otros dos mtodos anteriormente mencionados (grupos Windows y roles ASP.NET). Autorizacin con grupos de Windows/AD En WCF, el sistema ms cmodo (y adems orientado a aspectos J) para realizar autorizaciones de acceso a usuarios Windows/AD comprobando si pertenecen a ciertos grupos Windows requeridos, es basndonos en el atributo PrincipalPermissionAttribute, el cual se puede utilizar para diferentes tipos de autorizacin y tokens de seguridad, por lo que normalmente es necesario una configuracin del tipo de seguridad a utilizar en la autorizacin. En este caso, como queremos utilizar grupos de Windows/AD, tenemos que realizar la siguiente configuracin declarativa en el fichero .config (listado 10). Cuando se utiliza un certificado como credencial de cliente, lo que hace WCF es concatenar el asunto y la huella digital separndolos con un punto y coma, y crea as un valor nico para la identidad del cliente (el llamador del servicio WCF). Cuando se establece UseAspNetRoles como sistema de autorizacin en el comportamiento de nuestro servicio, la identidad del cliente (llamador) se compara automticamente con la propiedad Name y se determina entonces si el usuario llamador (cliente) tiene o no tiene autorizacin para acceder. Pero vamos, como deca, es una pena que no haya otro literal especfico para autorizaciones con certificados, porque aunque funciona correctamente como hemos dicho, no queda muy elegante que estemos autorizando con certificados y en cambio el literal sea UseAspNetRoles Pero en fin, el hecho es que los literales posibles hoy por hoy son solamente estos: None, UseWindowsGroups, UseAspNetRoles y Custom. Lo ms importante a destacar de WCF tanto en la seguridad como en cualquier otro aspecto son, como deca, el desacoplamiento y la modularidad de WCF, en la mayora de los casos siguiendo

adems el "patrn proveedor". Por ejemplo, hoy podemos desarrollar un servicio y configurarlo declarativamente para que utilice un tipo de seguridad, protocolo, formato de datos, etc. y en el futuro cambiarlo declarativamente y utilizar otra seguridad y otro protocolo, y en muchos casos no ser necesario ni siquiera el recompilar el servicio! Cuanto ms se conoce a Indigo (WCF), ms se aprecian el desacoplamiento y modularidad en todos los sentidos, as que os animo a dar el salto y pasar de los bsicos XML Web Services (de tipo ASMX) a los nuevos servicios de WCF.