Autor: unai

Antes o después, siempre nos encontramos con la necesidad de ‘clusterizar’ nuestras aplicaciones Web. Para esto, sin dudad ninguna, tenemos mucha documentación en la MSDN y demás portales de ayuda a desarroladores. aunque para el caso de aplicaciones haciendo uso de Windows Identity Foundation esta cantidad de ayuda no es tan grande, ni mucho menos. Por ello, a lo largo de la siguiente entrada intentaremos ver como preparar nuestras aplicaciones para que los módulos de WIF soporten WebFarms.

WIF 3.5

El principal escollo con el que nos encontramos para mover una aplicación a una Web Farm consiste en la encriptación de la cookie, con su consiguiente token de wif,  usando DPAPI. Como sabrá, DPAPI es dependiente de la máquina y por lo tanto, si una petición de un usuario se dirigiera hasta otro nodo del cluster este no sería capaz de realizar la desencriptación y el consiguiente tratamiento de la cookie. Por suerte, WIF nos permite modificar los módulos encargados de realizar estas tareas, para, poder decirle que use algún mecanismo de encriptado no dependiente de la máquina, como por ejemplo podría ser un RSA. La única pega, es que esto no lo podemos hacer mediante configuración y por lo tanto, tendremos que tocar nuestro código actual para mover una aplicación a una Web Farm. Los pasos a realizar son los siguientes:

Subscribirnos a la creación de la configuración en nuestro punto de inició de la aplicación

Crear nuestro CookieTransform que haga uso de RSA en vez de DPAPI

Establecer un SessionSecurityTokenHandler que haga uso de este mecanismo de transformación:

WIF 4.5

Por suerte, en WIF 4.5 todo este trabajo es realmente mucho más sencillo gracias a nuestra herramienta “Identity and Access Tool” de la que ya hablamos en otras ocasiones. Si nos fijamos en la misma, dentro de la pestaña de configuración tenemos un simple check que nos permite poner nuestra aplicación válida para una Web Farm.

Con este sencillo paso, sin tener que poner una sola linea de código ya tenemos el trabajo anterior resuelto. ¿ Como es posible esto? Pues bien, la respuesta está en que WIF ya tiene ahora, en esta nueva versión, un security token handler con las transformaciones adecuadas para que funcionen en una WebFarm, basta con ver los cambios realizados en nuestra sección IdentityModel para ver que ha pasado.

Si observa el elemento XML anterior verá como, tal y como comentábamos, se ha cambiado el SessionSecurityTokenHandler por defecto por un MachineKeySessionSecurityTokenHandler capaz de funcionar en una WebFarm.

Ha sido una entrada corta, pero espero que os resulte de interés…

Un saludo

Unai

Trabajando con Windows Azure ACS

En la anterior entrada vimos como la nueva herramienta de gestión de la identidad nos proporcionaba la posibilidad de usar un Local STS para nuestro tiempo de desarrollo. Lógicamente, en algún momento tenemos que pasarnos a utilizar un STS real y, seguramente, tal y como está el panorama hoy en dia, muchas aplicaciones querrán que la autenticación se realize  utilizando algunos de los muchos proveedores de identidad que tenemos, como por ejemplo Facebook, Google, Yahoo, Live Id o  Active Directory. Por suerte, esta nueva herramienta nos permite configurar nuestra aplicación para usar Windows Azure ACS 2, el cual, nos proporcionará out-of-box un STS con gestión de claims para distintos proveedores de identidad, como los mencionado anteriormente.

En este post no entraremos con la configuración de Azure, puesto que ya en otras ocasiones hemos nombrado las capacidades de Azure y ACS con respecto a la gestión de proveedores de identidad, páginas de login personalizadas e incluso transformación de claims. Es decir, en esta entrada solamente nos centraremos en la parte de cliente y de como configurar una aplicación para hacer uso de las capacidades de ACS 2.

Empezaremos por lo tanto, como en el caso anterior con una aplicación MVC 4 sobre la que arrancaremos la herramienta de gesión de la identidad. En esta ocasión, en vez de seleccionar Local STS seleccionaremos el uso de Windows Azure Access Control Service, servicio que, lógicamente tendremos que configurar, para ello, en el enlace Configure podemos establecer tanto el namespace como la clave de administración del servicio ( la clave no es necesario que esté almacenada, simplemente es para obtener los diferentes identity providers que podemos establecer ).

En nuestro caso, tenemos un namespace llamado identity45 que tiene configurados los proveedores de identidad de Windows Live Id, Google Id y Azure AD, por supuesto usted puede poner o quitar en el portal de administración más proveedores, como Facebook o Yahoo por poner algunos ejemplos.

En la imagen de la izquierda, puede ver como la herramienta nos permite, de los proveedores de identidad posibles, seleccionar con aquellos que querramos trabajar. Lógicamente, al igual para el caso anterior, tambíén nos permite establecer el REALM de nuestro RP y la url de redirección que tiene que utilizar ACS 2 una vez que un usuario esté autenticado.

Una vez terminado el trabajo de configuración, que como habrá podido ver son dos sencillos paso, ya podemos ver en nuestro archivo de configuración web.config la información relativa al proceso anterior, estableciendo en las secciones System.IdentityModel y System.IdentityModel.Services los elementos necesarios

La prueba…

Dos pasos, eso es lo que hemos realizado en nuestra herramienta de configuración,y con estos sencillos 2 pasos ya tenemos nuestra aplicación funcionando con múltiples proveedores de identidad, sin tocar ni una linea de código, pero.. vamos a verlo. Hacemos un F5  y ya podemos observar como nuestra aplicación ha hecho una redirección automática a nuestro servicio de Windows Azure ACS 2 el cual nos presenta la página de selección de proveedores de identidad por defecto. Una vez seleccionado uno y autenticado, se produce otra vez la redirección a nuestro sitio, en el cual, ya podemos acceder a la lista de claims del token autenticado.

Saludos

Unai

En la anterior entrada hablamos sobre las nuevas herramientas de la plataforma de Identity disponibles para .NET 4.5 y como estas nuevas herramientas nos aportaban nuevas mejoras y funcionalidades. De la primera de esas funcionalidades que hablaremos es del Local STS.

Local STS

Cuando decidimos desarrollar un proyecto y delegar la gestión de la identidad a un tercero, en nuestra terminología a un Security Token Service, siempre tenemos la posibilidad de que esa pieza no esté disponible o quizás que no tengamos acceso a la misma. Por ejemplo, si vamos a desplegar el producto en una organización, es casi seguro que la misma disponga de un ADFS sobre el que podamos trabajar, sin embargo, en tiempo de desarrollo probablemente no lo podamos ni tocar. Conscientes de esto, el equipo de Identity, pone a nuestra disposición la posibilidad de que desarrollemos una RP usando un STS local o simulado, que nos permita trabajar como si de un ADFS ( u otro bussiness STS ) se tratara.

Con el fin de mostrar un ejemplo de esto crearemos un nuevo proyecto de MVC 4 en nuestro Visual Studio 2012 al que configuraremos con las herramientas de Identity, vistas en la entrada anterior. Si se fija en la figura 1, en las distintas ‘tabs’ que tenemos en la ventana podemos seleccionar la dedicada a configurar como funcionará nuestro Local STS, desde el protocolo por defecto SAML 1.1 o SAML 2.0 hasta el puerto de nuestro Local STS en la máquina.

Por supuesto a mayores de esto, también podemos configurar las claims que serán devueltas por cualquier petición de un token, WS-Trust, para  cualquier usuario. Esta información de claims es guardada a nivel de proyecto en un archivo llamado LocalSTS.exe.config que contendría algo similar a lo siguiente:

Seguramente, si está desarrollando una solución empresarial, dentro de los distintos escenarios que tendrá, existirán aquellos en los que haga una validación de las claims para algún mecanismo de authorización. Para hacer más agil esto a los desarrolladores, en vez de modificar a mano este archivo para dar soporte a distintos perfiles sería conveniente realizar algún script de power shell que nos facilitara la vida. [Es probable que esto sea una de esas miles de cosas que uno tiene como propósito para hacer en vacaciones]

Una vez que hemos terminado de configurar nuestro Local STS podemos ver como la configuración de nuestro proyecto MVC ha cambiado, para verlo nos iremos a nuestro web.config y observaremos los siguientes elementos.

• Nuevas secciones de configuración: Lo primero que hace es agregarnos las secciones de configuración relativas a System.IdentityModel.

• Agrega los módulos de System.IdentityModel, el de establecimiento de la sessión que ya vimos anteriormente y el de WS-Federation que conocemos de WIF

• Agregamos la configuración de System.IdentityModel, apuntando a nuestro STS local

Bien, ahora que ya tenemos todo configurado, sin más, podemos iniciar nuestro proyecto y observar las claims del usuario authenticado, para ello podemos poner el siguiente código en Home/Index y observar el resultado.

Más configuración…

Si se fija en la configuración, hay más elementos que podemos configurar, el valor del issuer, la audiencia, la redirección pasiva o si queremos https y cookies validas para una web farm. Por suerte, estos valores no tenemos que tocarlos en nuestro XML directamente sino que támbién son modifcables en la herramienta de gestión de la identidad en la pestaña de Configuración, tal y como podemos ver en la siguiente imagen.

Saludos

Unai

Por fin, ya hemos llegado a lo bueno, a la chicha vamos. Una de las cosas que ya comentamos a lo largo de las tres entradas anteriores es que Claims es ya el ciudadano de primer nivel y que todo el trabajo avanzado con WIF está de una forma u otra incluido dentro de .NET en System.IdentityModel. Si recuerda de entradas anteriores, con WIF teníamos a nuestra disposición una serie de herramientas que nos facilitaban el trabajo en cuanto a la federación y el trabajo con STS, internos u externos. Por suerte, el equipo de Identity ha seguido trabajando en estas herramientas mejorándolas mucho y de una forma muy bien pensada. Además, por suerte, este tooling ya no está aislado y puede incluirse en nuestro Visual Studio por medio del Extension Manager como un VSPackage como otro cualquiera. A lo largo de esta entrada veremos la instalación y puesta en marcha de esta herramienta así como los primeros pasos, en siguientes post profundizaremos en algunos elementos importantes como por ejemplo el uso de ACS 2 para nuestros despliegues en Windows Azure.

Tooling, instalación y puesta en marcha…

Tal y como ya comentamos, miestra que con WIF teníamos una intalación stadalone del runtime y el SDK ahora en Visual Studio 2012 ya lo tenemos todo integrado, aunque para la parte de tooling tengamos que hacer uso del Extension Manager. En concreto, para empezar a trabajar con federación instalaremos el paquete “Identity and Access Tool”, tal y como se puede ver en las siguientes figuras.

Una vez instalada la herramienta, ya tendremos en los proyectos de visual studio  una nueva entrada en el menu contextual del proyecto llamada “Identity and Access” que nos permitirá acceder a la herramienta de configuración.

Un vistazo inicial

Una vez instalado, ya podremos empezar a jugar un poco con la herramienta, lo primero, como es lógico es ejecutarla. Con este simple gesto, ya podremos ver todo lo que ha cambiado con respecto a versiones anteriores, ahora es mucho más limpia y capaz, de hecho, és mucho más facil trabajar con una configuración inicial que con la version anterior de la herramienta, que estaba siempre pensando en crear y no le gustaba nada el modificar una configuración existente.

Lo primero que vemos es las distintas funcionalidades que la herramienta nos proporciona, resumidas en los siguientes puntos:

• Uso de un STS simulado para facilitar el desarrollo cuando el STS no está disponible o ni siquiera está construído.
• Trabajo y configuración con ADFS o bien un STS bussiness-ready.
• Uso de Windows Azure ACS 2 como STS, esto es muy chulo, hablaremos más adelante sobre esto.

A mayores y de forma independiente del STS seleccionado podemos configurar aspectos como el transporte, el uso de cookies y otros aspectos importantes que iremos viendo..

Recursos

Vittorio, como siempre tiene recursos excelentes sobre el tema…..

Vittorio Vertoci

http://blogs.msdn.com/b/vbertocci/archive/2012/03/15/windows-identity-foundation-in-the-net-framework-4-5-beta-tools-samples-claims-everywhere.aspx

Saludos

Unai

Una de los elementos positivos con respecto al movimiento de EF 6 en situarse como OSS es que podemos ver de forma temprana las distintas decisiones de diseño que están tomando y como será finalmente el API con el que trabajemos. Uno de estos ejemplos es una de las últimas entradas en el sitio de EF en Codeplex dónde podemos ver como será el uso del API de asincronía introducido en VS 2012 con el que podremos ver reducidos nuestro ‘memory footprint’ en el servidor.

El siguiente tip de código, que está extraido de la entrada nombrada anteriormente, nos da un ejemplo de por dónde van a ir los tiros en el diseño del API

Recursos

http://entityframework.codeplex.com/

http://entityframework.codeplex.com/wikipage?title=Task-based%20Asynchronous%20Pattern%20support%20in%20EF.

http://lorgonblog.wordpress.com/2010/03/28/f-async-on-the-server-side/

Saludos

Unai

En la anterior entrega de esta serie vimos como extender el mecanismo de claims para hacer uso de un ClaimsAuthenticationManager, gracias al cual, podríamos modificar, agregar o eliminar claims de la identidad con la que se authenticara un usuario. Vimos además, como dependiendo del tipo de cliente el uso de esta pieza es diferente. A lo largo de esta entrega, veremos otro de los elementos fundamentales de la plataforma de identidad representado por la clase ClaimsAuthorizationManager, pieza que tal como se puede entender por su nombre se encarga de realizar autorización de credenciales. La autorización de credenciales nos permite restringir el acceso a un recurso dado, tanto de forma declarativa como imperativa gracias a ClaimsPrincipalPermission y ClaimsPrincipalPermissionAttribute.

ClaimsAuthorizationManager

Como lo primero es lo primero empezaremos por crear y configurar un ClaimsAuthorizationManager simple, para ello, como hacíamos en la entrada anterior solamente tenemos que crear nuestra implementación y registrarla dentro de la sección de configuración del sistema de identidad nuevo System.identityModel.

Una vez registrado nuestra implementación y configurada, ya podremos revisar su funcionamiento, para ello, podemos simplemente hacer uso de ClaimsPrincipalPermissionAttribute como se ve a continuación.

Si se fija, el código es idéntico al usado en versiones anteriores del framework con PrincipalPermission, si acaso, la diferencia está en que ahora no hablamos de usuarios/roles sino recursos y operaciones. Pues bien, antes de cualquier llamada a este método se proceder´´a a verificar el acceso de la identidad actual en el método CheckAccess, el cual tomará como parámetro un contexto con la información de la identidad actual y el[los] recurso[s] y operación[es] que se quieren autorizar.

En un entorno web, como MVC tenemos la pega de que el atributo Authorize no está preparado para trabajar con claims, aún sigue pidiendo usuario / roles, sin embargo, no tardaríamos mucho en realizar una implementación que se adaptara a nuestro gusto y necesidades. Mientras tanto, lógicamente podemos solicitar la autorización de forma imperativa como se ve en esta trivial acción de un controlador.

Nota: Revisando un poco las implementaciones he visto una implementación  de un atributo de autorización basado en claims para MVC de Dominick Baier que prodría utilizarse sin problemas,  el ejemplo y la descarga pueden obtenerse desde aquí.

Aunque ha sido corta, espero que esta entrada os haya resultado de vuestro agrado

Un saludo

Unai

En la anterior entrega hablamos sobre como Claims Identity / Principal pasaban a ser elementos fundamentales de .NET 4.5. Junto con esta entrada también vimos como los mecanismos de autorización legacy seguían funcionando, aunque ahora interpretando claims. Pues bien, a lo largo de esta entrada trataremos de hablar de dos elementos fundamentales en nuestros RP, ClaimsAuthenticationManager y ClaimsAuthorizationManager.

ClaimsAuthenticationManager

Tal y como se puede leer en la documentación de esta clase, la idea de esta pieza es la de poder dar soporte a la transformación, modificación y agregación de las claims obtenidas en el proceso de autenticación de un usuario. Un ejemplo podría ser en un sitio web con un carrito en el que querramos agregar a cualquier usuario autenticado alguna claim procedente de nuestro sistema y no del repositorio/pieza de autenticación. Su uso, como puede verse a continuación es tremendamente sencillo.

Si observa, lo único que hemos hecho es sobreescribir el método Authenticate, para, si el usuario está autenticado trabajar sobre la colección de Claims de la identidad obtenida por el método seleccionado. Para establecer esta implementación como el ClaimsAuthenticationManager por defecto solamente tendremos que agregar la siguiente sección de configuración dentro de nuestro programa.

Una vez establecida la configuración, tendremos que indicar que se utilize el sistema de transformación de claims, para ello, dependiendo  del tipo de aplicación lo haremos de forma diferente. Por ejemplo, para una aplicación de escritorio solamente tendríamos que cambiar el sitio en el que hagamos la asignación de nuestro principal al hilo de ejecución, incorporando el siguiente código:

En el caso de la web, es un poco diferente, sobre todo, porque generalmente no intervenimos en este proceso de asignación del principal al HttpContext. Para resolver esto, podemos crear un sencillo módulo Http que nos haga este trabajo, un código de ejemplo podría ser el siguiente: