Identity & .NET 4.5 – IV

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.

 

 

Capture1

cap2

 

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.

 

 

Capture3

 

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

EF 6–Async support

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

Identity & .NET 4.5 – III

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

Identity & .NET 4.5 – II

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:

 


 

Si observa, en lineas generales, con un poquito más de amor, hemos hecho el mismo trabajo que anteriormente, asignar al hilo ( y en el caso de la web al HttpContext ) el principal obtenido de la transformación. Por supuesto, una vez creado tenemos que registrar este módulo dentro de nuestro sitio, adicionalmente, también tenemos que hacer el registro del móduglo SessionAuthenticationModule, ahora veremos para que..

 


Bien, supongamos que ya hemos hecho todo el trabajo. Si navegamos un poco por el sitio, nos daremos cuenta de que el método Authenticate es llamado de forma continua, si, por ejemplo, hacemos lo que comentamos anteriormente de buscar en nuestro repositorio claims adicionales el impacto de rendimiento sería alto. Para evitarlo, podemos guardar en sesión este principal de tal forma que no sea ejecutado tan frecuentemente. Para ello, modificaremos nuestro ClaimsAuthenticationManager para incluir lo siguiente

 


 

Como podrá observar se hace uso del modulo SessionAuthenticationModule para emitir una cookie que será posteriormente utilizada para evitar el proceso de transformación de nuevo.

 

Bueno, hasta aquí llegaremos por hoy, espero que os esté resultando interesante..

 

Saludos

Unai

Entity Framework y OSS

Bueno, si estais leyendo esto es porque el equipo de EF ( englobado ahora mismo dentro de Scott Gutrie y Azure ) ha publicado el movimiento de Entity Framework en la misma dirección que ASP.NET MVC, Web API o Web-Pages, con respecto al desarrollo del producto en modo Open Source. Seguro que este movimiento os habrá llenado la cabeza de preguntas, las mismas que pude hacerme yo en su momento cuando me enteré, llevan bastante tiempo haciendo posible esto. ¿Porqué este movimiento? ¿Cuales son las consecuencias? ¿Cómo puede esto afectar a mis clientes? Aunque durante la escritura de este post no está publicada la entrada del equipo de EF me imagino que habrán hecho el ejercicio de explicar el movimiento de una forma concisa y precisa, no obstante os pongo algunas de las respuestas que he podido conseguir con respecto a mis inquietudes, arriesgándome a repetir algo de lo expuesto en la entrada del equipo.

 

¿Como afecta a mis clientes?

Estemos de acuerdo o no, una de las razones de selección de EF como producto es por la presencia de Microsoft como respaldo al mismo, la integración con el resto de sus herramientas y por supuesto por algo extramadamente importante como es el soporte. Pues bien, la entrada de EF en OSS NO restará un ápice en este camino de respaldo y soporte puesto que sigue siendo el equipo actual el responsable del desarrollo de EF y de asegurarse de que las contribuciones ( si las hay ) al producto mantengan la calidad y estandares del grupo. Además, microsoft seguirá sacando ‘blessed’ builds con un testeo completo, firmadas por Microsoft y con el mismo grado de soporte que tenemos actualmente en EF.  Por lo tanto, si algo afecta a nuestros clientes será la capacidad de tener un equipo mucho más agil puesto que no estará atado a .NET FXy podrá sacar versiones de una forma más temprana.

 

¿Por qué?

Yo no soy nadie para contestar esta pregunta, la verdad, lo único que puedo hacer es dar mis elucubraciones al respecto pero si hay un porqué oficial debería de darlo el grupo de producto. Dentro de mis pensamientos acerca del porque de este moviento se encuentran los siguientes argumentos.

  • Es otro paso más allá del dado con EF Design Blog en el que el equipo de producto de forma temprana exponía sus diseños de nuevas funcionalidades para ser discutidas con la comunidad. El ejemplo con Migrations y las aportaciones de la comunidad han sido una buena prueba de ello.
  • Apartarse del ciclo de vida de .NET Fx es un alivio por toda el sobrecoste que tiene en ALM
  • Tener un modelo OSS no solamente nos aportará features & fix sino también un “heads up” de los elementos en los que están trabajando, pudiendo leer los tests y aportar ideas y sugerencias en el diseño.

¿Cuáles son las consecuencias?

Pues no lo sé, habrá que esperar… aunque yo tengo muchas esperanzas en que la comunidad contribuya(mos) en EF de la misma forma que en ASP.NET MVC, producto que por ejemplo, tendrá cerca de de 10 contribuciones de la comunidad en su RTM..

 NOTA: Recursos esenciales si te interesa contribuir en el blog de Arthur

Saludos

Unai

Identity & .NET 4.5 – I

No han sido pocos los post que tengo en este blog referidos a la gestión de la identidad, desde Zermatt hasta WIF, la identidad y su gestión es uno de los temas que me apasiona y sobre los que siempre me gusta escribir. Este post es una entrada de una serie, que no tengo ni idea de cuanto se extenderá, acerca de los cambios con respecto a este tema en .NET 4.5 y Visual Studio 2012, que espero os resulten tan interesantes como a mi y, sino, por lo menos que os ayuden a entender un poco que hay de nuevo en este tema.

 

Generic Identity / Principal, de hermanos a padres

La primera nota importante que haremos notar es que todo el trabajo avanzado con Windows Identity Foundation pasa a estar incorporado dentro de .NETer Framework, de tal forma que los conceptos de Claims y todo lo relacionado con ello, iremos poco  a poco, lo tendremos ahora en los namespaces System.Security y System.IdentityModel. Por supuesto, este trabajo no ha estado fuera de un necesario rediseño de ciertos elementos del API de .NET Framework. Uno de estos elementos tiene que ver con la jerarquía de IIdentity y IPrincipal. Hasta ahora, las distintas implementaciones que teníamos, Generic Identity/Principal, Windows Identity / Principal y Claims Identity / Principal eran hermandos. En la nueva versión del framework, con todo el sentido del mundo, esto ya no es así, puesto que tanto Generic Identity / Principal como Windows Identity / Principal son hijos de Claims Identity / Principal, es decir, todo en la gestión de la identidad en .NET son Claims.  Con el fin de poner un ejemplo podríamos ejecutar las siguientes pieza de código, que funcionarían perfectamente en .NET 4.5 y gracias a la cuales podríamos ver cuales son las claims de una identidad windows o  una identidad genérica.

 


 

Cada uno de los atributos de una identidad Windows ha sido traducido a sus correspondientes claims, cuyos tipos podemos ver en las constantes definidas por el tipo ClaimTypes. Este mismo código, funcionaría también perfectamente si trabajaramos con Generic Identity / Principal como puede ver a continuación.

 


 

Los mecanismos de comprobación de identidad y rol tradicionales como IIdentity.Name y IIdentity.IsInRole seguirán funcionando correctamente, aunque en este caso, se basarán en la búsqueda y tratamiento de los claims de cada una de las identidades, por ello IClaimsIdentity define las constantes de los tipos de claims en los que se basará la búsqueda del nombre y/o comprobación del rol.

 


Una cosa chula y curiosa es que cuando creamos nuestra identidad basándonos en ClaimsIdentity podemos decidir que tipos de claims serán los utilizados para estas comprobaciones, tal y como podemos ver en el siguiente ejemplo con la sobrecarga del constructor  ClaimsIdentity

 


 

No obstante, ahora que sabemos que todo son Claims, realmente el código tipo Name/IsInRole ya no es necesario (solamente por compatibilidad hacia atrás que es por lo que se ha dejado) puesto que lo único que tenemos que hacer es preguntarnos si alguna claim existe gracias a los distintos métodos que ClaimsPrincipal nos da como HasClaim, FindFirst o FindAll.

 

Bueno, hasta aquí hemos llegado con la primera entrada para abrir un poco el hambre de saber más, en la siguiente entrada trataremos la gestión de la identidad en un entorno web, hablando sobre los cambios en .NET 4.5 y algunos elementos que teneos que tener claros.

 

 

Saludos

Unai