WIF es sencillo, úsalo #3-1

En las anteriores entregas #1 y #2 empezamos por exponer las motivaciones de esta nueva tecnología salida de la factoria de Microsoft así como de conceptos fundamentales que deberemos entender, tanto concrétamente de WIF como conceptos generales que aplican a otras tecnologías de seguridad. A lo largo de esta tercera entrega, y de las posteriores que seguiran a esta, intentaremos mostrar pequeños ejemplos de uso que nos permitan ver como integrar WIF dentro de nuestras aplicaciones no tiene porque ser traumático y como realmente ganaremos muchas ventajas con respecto a sistemas  más tradicionales.

Cliente WCF Activo

En este primer ejemplo intentaremos mostrar como incluir un STS dentro de un servicio expuesto por Windows Communication Foundation y como hacer uso de el. Posteriormente interemos modificar configuración/código para obtener nuevas funcionalidades o cambiar la parametrización de funcionamiento.

 

1º Paso – Definicion del servicio

El primer paso a realizar será el de disponer de un servicio de WCF, en nuestro caso, usaremos un sencillo ejemplo de un servicio definido tal y como sigue en los siguientes fragmentos de código. Este servicio, por comodidad se ha expuesto en una aplicación de consola, pero lo mismo aplica si fuera un servicio de windows o bien un sitio web.

 

2º Utilizando Federation Utility

Una vez que tenemos nuestro contrato implementado y el servicio configurado (todo lo relativo a hosting y configuracion de WCF es algo que daremos por sentado, sino estos posts se alargarían demasiado), podemos hacer uso de las herramientas de Windows Identity Foundation de una forma muy sencilla. En el menu contextual de nuestro proyecto, veremos una entrada con un texto similar a “Add STS Reference”, esta entrada del menu contextual nos permitirá lanzar la herramienta “Federation Utility” ( incluida con el SDK de WIF) gracias a la cual podremos configurar el servicio para trabajar con un nuevo STS o bien un STS existente.

 

 

 

 

 

 

 

Este asistente nos pedirá los datos relativos al path del archivo de configuración de nuestro servicio wcf ( un web.config si es un sitio web ) y la URI del mismo. Esta uri es importante puesto que la misma servirá como valor de AudienceUri, es decir, como indicador de “para quien será el token generado por el STS”. Una vez configurado estos elementos el asistente nos preguntará si quieremos trabajar con un nuevo STS o un STS existente. Para  nuestro caso, seleccionaremos la opción crear un nuevo STS, tal y como se puede ver na la siguiente figura ( en el caso de disponer ya de un STS podemos establecer la direccion de su metadata).

 

 

3º Revisión de la configuración

 

El trabajo del asistente anteriormente ejecutado se traduce, como se puede ver en la ultima pantalla de resumen, en una serie de cambios a la configuración de nuestro servicio WCF, asi como a la inclusión de una serie de certificados a nivel de máquina ( estos certificados están pensados para el entorno de desarrollo y como veremos más adelante se usarán internamente por el STS para el cifrado y la encriptación de los tokens).

En cuanto a los cambios en la configuración, podemos ver la inclusión de un nuevo endpoint incluyendo un binding compatible con la federación de credenciales:

A mayores del endpoint, dentro de la configuración también se incluye un comportamiento nuevo ( no existente por defecto en WCF pero incluido con una extensión ) llamada FederatedServiceHostConfiguration.

Este comportamiento tiene como objetivo permitirnos especificar la configuración de WIF que vamos a utilizar. Esta configuración, se establece con una nueva sección personalizada por WIF llamada microsoft.identitymodel.

4º Revisión del STS creado

Ahora, en nuestra solución, dispondremos de un nuevo proyecto, por defecto generado como un sitio web, que contiene el código de un STS personalizado, cuyo código está contenido dentro de la carpeta especial de ASP.NET App_Code. Este código, contiene un helper para trabajar con los certificados, por defecto con los generados con la herramienta aunque los mismos pueden ser modificados cambiando en las appsettings de nuestro sitio web las claves:

Junto con este helper, también tenemos la definición de nuestro SecurityTokenService personalizado, en forma de la clase:

 

Este STS personalizado dispone de un método especial GetOutputClaimsIdentity cuyo objetivo es la de ofrecer el conjunto de Claims que hay que otorgar al usuario que se ha autenticado en el STS, el código por defecto de este método, que podremos ver en el siguiente fragmento de código, nos ofrece, para cualquier usuario, dos claims, una claim de tipo nombre y una claim de tipo rol.

 

4º Probando el escenario

Ahora, para probar nuestro escenario, solamente tenemos que crear un cliente cualquiera que ataque a nuestros servicios y si, no hemos comentido ningun error, podremos ver como la llamada al servicio funciona correctamente y la validación y obtención de claims se realiza correctamente. Con el fin de mostrar en el servicio las claims de ejecución en cada uno de los métodos utilizaremos en ellos una llamada a un método llamado CheckSecurity, que por ahora, solamente tendrá el propósito de enseñarnos por pantalla los claims del usuario autenticado.

 

En el siguiente post veremos como modificar la parametrización del servicio para utilizar otro tipo de autenticación y alguna carcterística a mayores que pueden ser interesantes como desarrolladores.

 

El código de ejemplo correspondiente a esta entrada puede descargarse desde aquí.

 

Espero que os sirva de interés

Unai Zorrilla Castro