Windows Azure Appfabric Access Control Service ACS (3/3)

 

Este es el tercer y último post de una serie relacionada con un evento que tuvimos con el Grupo de usuarios de Valencia, puedes encontrar el primero en Windows Azure AppFabric Access Control Service ACS (1/3) y el segundo en Windows Azure AppFabric Access Control Service (2/3)

 

En este post vamos a ver cómo personalizar la experiencia de login para los visitantes del sitio web y cómo gestionar los errores que puedan producirse durante la autenticación en el servicio de Access Control.

 

Personalizar la página de login

 

Al arrancar nuestra aplicación vemos que la página inicial a la que se accede no pertenece a nuestra aplicación, por defecto se está mostrando un formulario alojado en nuestro namespace de Access Control Service.

image

 

Si preferimos personalizar la experiencia de logIn (imagen, logos, apariencia corporativa…) es muy sencillo. Empezaremos por volver al portal de administración de nuestra suscripción de Windows Azure, en concreto a la configuración del namespace que hemos creado para servicio de Access Control. Hacemos click en Application Integration y exacto!! click en Login Pages

image

Dentro del apartado de login pages tendremos solo nuestra aplicación de ejemplo, hacemos click sobre ella y vemos que se nos presentan dos opciones.

Option 1 – Link to an ACS-hosted page. Básicamente, nos dan el enlace donde reside el formulario de login para que lo incorporemos en la parte que queramos de nuestra web. Cuando se haga click en ese enlace, el usuario será redirigido a la página que ya conocemos.

Option 2 – Host the login page as part of your application Esta es la opción que nos interesa, nos permite descargarnos una página de ejemplo que podremos editar y que se encarga de la parte de autenticación.

Nos descargamos la página de ejemplo, la situamos en el directorio de nuestra aplicación (la renombramos a algo más intuitivo, por ejemplo LoginPage) y nos aseguramos de incluirla en el Proyecto de Visual Studio (Add Existing Item)

 

image

 

Ahora está en nuestro poder, de modo que podemos editarla al gusto… en mi caso, me voy a conformar con cambiar un par de textos para que se vea que la página que se ejecuta es la que tengo en local, dejo los cambios de estilos y logos a los que sepan, o se atrevan con esas cosas 🙂

 

Una vez editada, tenemos que modificar un par de secciones en el web.config para estar listos. Primero la autorización, añadimos el bloque location relativo al LoginPage.html recién añadido

 

image

y segundo, el apartado microsoft.identitymodel/service/federatedAuthentication/wsFederation para que apunte a la página recién añadida al proyecto como issuer

image

¿Fácil verdad?

Ejecutamos la aplicación para verificar que no nos hemos confundido y ahora tenemos control sobre la página de login, como no he cambiado el diseño, simplemente resalto la URL O=)

image

 

 

Gestión de… ¿Errores?

 

Para finalizar, vamos a añadir una página para gestionar los posibles errores encontrados en el servicio de ACS. ¿Recordáis cuando dimos d e alta la aplicación en el primer post? Había un campo para registrar una URL en caso de error =)

Vamos al portal de administración de windows azure, entramos en app Fabric y entramos en la configuración del namespace que hemos dado de alta para el ejemplo de ACS.

En la sección de Relaying Party Applications, hacemos click sobre nuestra aplicación, buscamos en el formulario la entrada de Error URL y damos de alta una URL de nuestra aplicación apuntando a una página de error (que crearemos en el siguiente paso) y guardamos la modificación.

image

ACS le va a enviar a la página que hemos indicado un código de error y unos detalles sobre el mismo a través de la URL, la forma más fácil para capturarlo es crearnos un par de clases que encapsulen la información al serializarla:

public class ErrorDetails
{
     public string context { get; set; }
     public int httpReturnCode { get; set; }
     public string identityProvider { get; set; }
     public Error [ ] errors { get; set; }
}

public class Error
{
     public string errorCode { get; set; }
     public string errorMessage { get; set; }
}

Como supuestamente esta página sólo se va a llamar en caso de error, podemos directamente añadir el código para interceptar y deserializar el mensaje en el Page_Load. En el código estamos deserializando el mensaje a una estructura de clases ErrorDetails y Errors y concatenándolas para mostrarlas en una label que hemos añadido a la página (lblErrorMessage)

protected void Page_Load (object sender, EventArgs e)
{
   JavaScriptSerializer serializer = new JavaScriptSerializer();
   ErrorDetails errors = serializer.Deserialize<ErrorDetails>( Request["ErrorDetails"] );

   var messages = from e in errors.errors
   select string.Format("Error Code {0}: {1}", e.errorCode, e.errorMessage);

   lblErrorMessage.Text = string.Join("<br/>",messages.ToArray<string>());

}

 

Una vez tenemos la página, tenemos que modificar el web.config para permitir el acceso anónimo y que todo el mundo pueda acceder a ella. Porque, imaginad… si solo pudiesen entrar los usuarios autenticados… y es una página para mostrar los errores de autenticación… vamos listos, no? 😛

image

Ahora.. estamos listos para probar. Pero para que el servicio de Access Control devuelva un error, tiene que producirse un error dentro del mismo servicio, como por ejemplo… que no haya reglas con las que contrastar la autenticación una vez esta se produzca. De modo que la forma más rápida de probar si nuestro código funciona es ir al portal de Windows Azure y borrar las reglas de la aplicación de la configuración de Access Control.

Si lo hacemos…

image

Vemos como la página de intercepción se comporta de la forma que esperábamos 🙂

 

 

Conclusión

A lo largo de estos tres posts hemos experimentado lo sencillo que resulta externalizar la autenticación de la aplicación mediante el servicio de Access Control de AppFabric y cómo nos permite incorporar de forma sencilla otros proveedores, también hemos visto que podemos definir nuestras propias reglas, trabajar con los tokens que nos envía el servicio, e incluso personalizar la experiencia, espero que estos posts puedan resultar de ayuda a l@s que empiecen a trastear con Access Control. Sé que hay un par de libros en castellano cociéndose sobre el tema y en cuanto estén acabados editaré el post para agregarlos.

 

Por el momento, os dejo con este sitio web, que es el mejor repositorio de recursos que he encontrado sobre ACS

Access Control Service 2.0 – http://msdn.microsoft.com/en-us/library/gg429786.aspx

 

 

 

Happy Hacking!!

 

David Salgado ( @davidsb )

Windows Azure Appfabric Access Control Service ACS (2/3)

 

Este post es el segundo de una serie relacionada con un evento que tuvimos con el Grupo de usuarios de Valencia, puedes encontrar el primero en Windows Azure AppFabric Access Control Service ACS (1/3)

En el primer post vimos como realizar una autenticación básica en ACS con los proveedores de Google y Live ID, en este post vamos a ver cómo complementar la aplicación utilizando el API de Winfdows Identity Foundation para explorar la información que nos envía el servicio de ACS.

 

Ver información extendida de los claims

Llegados a este punto, ya hemos conseguido tener un sitio web con la autenticación delegada, no hay que preocuparse de validar, de que se creen usuario y contraseña nuevo, recordar contraseñas, políticas, blah blah blah… pero… tampoco tenemos ningún dato de los usuarios que pasan por nuestra web.

En esta segunda parte del ejercicio, vamos a mostrar la información que nos devuelve el servicio de ACS en el ticket que nos envía una vez el usuario se ha autenticado contra el Identity Provider (IP) preferido.

Podemos extraer información relativa a la autenticación del perfil que se ha cargado en el proceso.

var claimsppal = (Microsoft.IdentityModel.Claims.IClaimsPrincipal) HttpContext.Current.User;

var identity = (Microsoft.IdentityModel.Claims.IClaimsIdentity)claimsPpal.Identity;

y una vez tenemos la interfaz (como he echado de menos Razor en estas líneas) podemos obtener la información que nos envían fácilmente

%>
        
        <p>Authentication type: <%:identity.AuthenticationType %></p>
        <p>Name: <%:identity.Name %></p>

        <%   
       
        var claims = identity.Claims;
        gv.DataSource = claims;
        gv.DataBind();      
        
    %>   

<asp:GridView ID="gv" runat="server" />

Por ejemplo, con éste código, hemos obtenido 4 tipos de Claims diferentes

claims/nameidentifier: El ID único de cuenta

claims/name: El nombre de usuario (David Salgado)

claims/emailaddress: El mail  (XXXX@gmail.com )

claims/identityprovider: Cómo se ha autenticado. Google, Live…

Con estos datos ya podemos empezar a construir Base de Datos de nuestros usuarios… o al menos a saludarles cuando entren al sitio!!

 

Creando una regla sencilla

Determinados usuarios pueden tener un rol específico dentro de la aplicación, por ejemplo administradores, redactores, editores,… con las reglas de Access Control Service podemos, por ejemplo, incluir un claim role en la respuesta. Vamos a quedarnos con el nameidentifier de un usuario autenticado en el paso anterior, por ejemplo… (obviamente lo he editado, pero será algo parecido)

Value: https://www.google.com/accounts/o8/id?id=WEWEEWEWEWEWEWEWEWEWE

Volvemos al portal de Access Control, a la parte de los namespaces y entramos en la configuración del namespace que habíamos creado anteriormente SitioACS.

Hacemos click en la opción Rule Groups del menú de navegación

image

Y entramos en la configuración específica. Además de las que se habían creado automáticamente, vamos a crear (Add) una nueva regla

IF  Identity Provider: Google

AND Input Claim Type : (Select) nameidentifier

AND Input Claim Value: (Enter) https://www.google.com/accounts/o8/id?id=WEWEEWEWEWEWEWEWEWEWE

THEN Output Claim Type: (Select)  role

Output Claim Value Enter: Editores

Rule Information. Regla de editor

Con lo que tenemos lo siguiente

image

Ahora vamos a modificar la aplicación, para que si se conecta un usuario que forme parte del rol Editores, muestre información diferente

if (claimsPpal.IsInRole("Editores"))
{
    %> <h2>Información importante para Editores </h2><%
}

Para probarlo, no tenemos más que volver a entrar a la aplicación con esa identidad

image

 

Próximo post

Para el tercer y último post de la serie, dejaremos la explicación de cómo personalizar la experiencia de logIn.

 

 

Happy Hacking!

 

David Salgado – @davidsb

Windows Azure Appfabric Access Control Service ACS (1/3)

 

Por lo que veo en eventos, artículos y lo que me charlamos , he visto que algunos de los servicios de Azure, aun no son demasiado conocidos, específicamente los de AppFabric. Es verdad que tal vez sean los más complicados de entender sin un buen ejemplo, de modo que voy a intentar hacer una pequeña introducción con algunos ejercicios prácticos :)  Primero tengo una serie de 4 posts de ACS, luego pasaremos al resto. Espero que os resulte de interés

 

Herramientas

Para poder seguir el paso a paso, vamos a necesitar unas cuantas descargas

Windows Identity Foundation WIF SDK

Windows Azure AppFabric SDK

Visual Studio Tools for Windows Azure & SDK

…además de una suscripción de Windows Azure

Intro para cualquier persona

Para suscriptores MSDN

Miembros de la red de Partners

y ofertas para Emprendedores

Bloques de la Plataforma Windows Azure

Situemos AppFabric dentor de la plataforma. Sabeís que la plataforma Windows Azure esta formada por diferentes bloques de servicios.

Tenemos el bloque de Windows Azure donde están los servicios de alojamiento de aplicaciones (Compute), almacenamiento no relacional (Storage) y la red de distribución de contenidos (CDN).

SQL Azure, como servicio de almacenamiento relacional. Y no nos confundamos, SQL Azure NO es SQL Server, podríamos considerarlo equivalente en funcionalidad a una parte de SQL server, en concreto… el motor relacional. Aunque SQL Azure esta preparado para ofrecer alta disponibilidad en un entorno cloud.

AppFabric es conjunto de servicios de infraestructura para aplicaciones (servicios Middleware). A día de este post tiene 3 grandes servicios. Access Control, Service Bus y Caching

Los servicios que componen estos tres grandes bloques se pueden usar tanto de forma conjunta como por separado, y son accesibles desde diferentes tecnologías. La Plataforma Windows Azure no es sólo para .NET ;)  En la página oficial de Windows Azure hay una buena descripción de cada uno de los servicios y herramientas.

Breve explicación de AppFabric Access Control Service

Los servicios que se encuentran bajo el paraguas de AppFabric (Service Bus, Access Control y Caching) podemos decir que son servicios de infraestructura para aplicaciones (mensajería, workflow, autenticación, autorización y cache) vamos a poder externalizar ciertas responsabilidades que hasta ahora formaban parte de la aplicación a estos servicios.

El servicio de Access Control ACS pone a disposición de los desarrolladores un sistema de identidad y control de acceso a las aplicaciones y servicios. Esta integrado con los proveedores de identidad estándares, tanto a nivel enterprise (directorio activo), así como web (Yahoo, Live Id, Google, facebook)

En pocas palabras… permite sacar de la aplicación las decisiones de autorización y basarlas en reglas declarativas. ACS actuará como una capa de abstración para lidiar con los diferentes Identity Providers y ofrecer a la aplicación un único formato de intercambio de tokens.

Por mi experiencia dando sesiones, cada vez que llegamos a un tema de identidad/autorización, la cosa se pone, digamos… tensa. Ya hace años cuando contábamos temas de membership, roles… en ASP.NET podía haber cierto lenguaje de nicho que hacía que el tema fuese duro.

Ni que decir tiene que cuando empezamos con ADFS, WS-Trust y la historia de la federación.. se volvió tan de nicho que a penas se comentaba fuera de los círculos de expertos en el área de seguridad.

Pues hay una buena noticia. Si bien ACS hace uso de todas estas especificaciones, APIs, herramientas… No es necesario que el desarrollador se vuelva un experto en seguridad para entender y utilizar el Access Control Serviceque no haya miedo!! No hay que aprender WS-Federation, WS-Trust, …. para el 90% de escenarios de uso de Access Control Service no será necesario bucear en estas especificaciones/herramientas/SDKs, simplemente consumiremos una serie de servicios.

 

Crear el sitio web base

Bien, soy adorador declarado de ASP.NET MVC, pero soy consciente de que todavía no todo el mundo ha visto la luz 😛 Como el lab tiene ya la complejidad de Azure y ACS no quiero incluir la de MVC, así que las demos las vamos a basar en un esqueleto de webforms para que no haya complicaciones añadidas.

Creando el esqueleto

Arrancamos Visual Studio como administradores y creamos un nuevo sitio web ASP.NET vacío en en http://localhost/siteACS. Le añadimos un web form default.aspx e introducimos algún texto para que se vea cuando se cargue la página

imageimage

 

Access Control Service Namespace

Una vez tenemos un sitio web listo, tenemos que hacer ciertas tareas de configuración en el portal de Windows Azure. Entramos en el portal con las credenciales de nuestra suscripción y nos dirigimos a la sección de AppFabric en el menú lateral.

image

Tenemos que crear un nuevo namespace para la aplicación, el namespace funciona como url de referencia donde tendremos disponible el servicio de ACS para nuestra aplicación, así que creamos uno nuevo

image

e introducimos un nombre único que se nos ocurra

image

Tendremos que esperar unos minutos hasta que pase de Activating… a Active

image

Cuando este activo, podemos pasar a configurarlo, encontraremos el acceso a la configuración del namespace en la parte superior de la pantalla

image

 

Configurando los Identity Providers

Dentro de la configuración del namespace, tenemos que dar de alta los proveedores con los que queremos trabajar, en nuestro caso, daremos de alta (Add)… LiveID y Google, por ejemplo. Al añadirlos nos pedirá si queremos un logo o texto descriptivo, como es opcional, el que quiera que lo especifique.

image

También tendremos que ir a la parte de Relying Party Applications, para incluir la información de la aplicación que hemos desarrollado y que va a hacer uso del servicio de autenticación 

Name Ejemplo ACS
Mode Enter Setting Manually
Realm http://localhost/siteacs
Return URL http://localhost/siteacs/default.aspx
Error URL (optional) en blanco
Token Format SAML 1.1
Token Encryption Policy None
Token Lifetime 600
Identity Providers Google y Windows Live Id
Rule groups Create New
Token Signing Service Namespace Certificate
   

Una vez configurado, vamos a Rule Groups para autogenerar las reglas de transformación de los tokens de los proveedores, a los tokens para la aplicación. Aunque en el paso previo hemos especificado que queremos un nuevo Rule Group, si no generamos las reglas no nos habrá valido para nada 😉

Entramos en la aplicación específica y hacemos click en Generate (asegurarnos de que tenemos seleccionados los 2 proveedores)

image

y guardamos.

Ya solo nos falta obtener en el apartado de Application integration la URL que especifica los metadatos de Federación, el WS-Federation metadata, en mi caso:

https://sitioacs.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml

 

Integrando la aplicación web con ACS

 

Ahora volvemos a Visual Studio y si tenemos correctamente instaladas todas las herramientas que indicábamos al principio del post, tendremos una opción Add STS Reference en el menú de contexto del proyecto en el Explorador de Soluciones

image

Al hacer click nos va a aparecer un Wizard donde ir introduciendo información. En la primera pantalla no tenemos nada que modificar

image

En la segunda tenemos que indicar que vamos a utilizar un STS (Security Token Service) existente y damos la url que hemos copiado anteriormente del portal de administración de appfabric

image

En la siguiente aceptamos sin más (no nos hace falta entrar en asuntos de CAs)

image

sin cifrado…

image

… en la siguiente nos muestra los claims que nos va a ofrecer el servicio

image

con lo que solo nos queda revisar la información y aceptar en la pantalla final. Al aceptar, se nos generarán una serie de elementos en el proyecto y se modificará el archivo de configuración.

Probando, ¿problemas?

 

¡ya está! A que no ha sido tan dificil?, dependiendo la configuración de los IIS puede ser que ya hayamos acabado, así que vamos a probarlo… pulsamos F5 y ¿?

Opcion A: Error!?

This may have been caused by not having the user profile loaded for the current thread’s user context, which may be the case when the thread is impersonating.

Por defecto en IIS7 (en otros no lo sé ni lo puedo verificar fácilmente) el application Pool bajo el que corre las aplicaciones no carga la información del perfil del usuario en el proceso. Aquí tenéis una respuesta de los foros con el paso a paso para cambiarlo

image

 

Opción B: Error!?

HTTP Error 500.22 – Internal Server Error. An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode

Se resuelve con un un poco de trabajo de web.config. Aquí tenéis como solventarlo, en el blog en geeks de Sergio Tarrillo 🙂

 

Opcion C: Funciona!!

El navegador arranca pidiendo al usuario que se autentique en uno de los servicios que hemos especificado, al registrarse nos deja pasar al default.aspx

image image

 

Próximo post

 

En el próximo post veremos cómo sacar información de los claims que envía ACS a la aplicación y cómo poder asociar usuarios a grupos.

 

Happy Hacking!

David Salgado ( @davidsb )

PD 1- Durante este post he recordado cómo me gustaba trastear con las cabeceras SOAP cuando salieron los servicios web y los cabezazos contra el Web Services Enhancements para trabajar con seguridad (WS-Security. WS-Routing, DIME…) q tiempos aquellos, eh?

PD 2 – Si te acuerdas de lo que pone en PD1… para un rato y tómate una cerveza (o lo que quieras), eres de la vieja guardia de .NET.. has pasado por asp.net 1.0, por los datasets, J#, la soluciones con vb.net y C# mezclado, cotillear el IL… te lo mereces 😉

PD3 – Azure Fabric Controller, Windows Azure AppFabric, y Windows Server AppFabric son 3 cosas diferentes. Parece que hacían descuento por nombre si lo usábamos en 3 productos 😛