Identity & .NET 4.5 VI

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.

VI-1

 

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.

 

 

 

 

 

 

VI-3

 

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.

 

VI-4VI-6

 

 

Saludos

Unai

Identity & .NET 4.5 – V

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 STSv-1

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.

 


 

 


 

Bien, ahora que ya tenemos todo configurado, sin más, podemos iniciar nuestro proyecto y observar las claims del usuario authenticado, para ellov-2 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.

 

v-3

 

 

Saludos

Unai