La nueva era de la autentificación: Claims

En noviembre de 2005 con la llegada de ASP.NET 2.0 aparece el primer sistema que unifica la autentificación y autorización de los usuarios, ASP.NET Membership. En él se proporciona un servicio integrado a través de la autentificación de formularios, Form Authentification, y el uso de una base de datos SQL para validar y almacenar las credenciales del usuario y los datos del perfil. Las desventajas principales de este servicio eran que el esquema de base de datos fue diseñado para SQL Server y no se podía cambiar y, además, estaba basado solo en la autenticación de formularios, no dando soporte para inicios de sesión que utilizan proveedores externos como cuentas de Microsoft, Facebook, etc. Microsoft realizó varios avances para mejorar este sistema como fueron ASP.NET Simple Membership o ASP.NET Universal Providers. Pero la mejora más importante vino con el framework ASP.NET 4.5, el sistema ASP.NET Identity.

Identity

ASP.NET Identity permite la autenticación basada en notificaciones o claims (claims based authentication), donde la identidad del usuario se representa como un conjunto de notificaciones.

.NET utiliza las interfaces IIdentity e IPrincipal como base para la autenticación y autorización. La interfaz IIdentity representa la identidad de un usuario en .NET. Los métodos que contiene son Name, para almacenar el nombre del usuario, IsAuthenticated, para identificar si el usuario ha sido autenticado, y AuthenticationType, que almacena la descripción del mecanismo de autenticación del usuario. La interfaz IPrincipal se ocupa del control de acceso basado en roles y contiene la propiedad de tipo IIdentity, junto con un único método para comprobar si el usuario posee un rol particular o no.

Las dos novedades principales que se introdujeron con fueron ASP.NET Identity  fueron las clases ClaimsIdentity y ClaimsPrincipal dentro del namespace System.Security.Claims. ClaimsIdentity es la clase derivada de la interfaz IIdentity, donde esta nueva versión añade una colección de Claims de identidad del usuario. ClaimsPrincipal deriva de la interfaz IPrincipal, donde incluye la colección de ClaimsIdentity.

Identity-2

Para crear nuestro conjunto de claims, utilizamos la clase ClaimsIdentity, donde estarán encapsulados todos los claims del usuario.

Identity-3

Cada claim es un fragmento de información sobre el usuario, como pueden ser, nombre de usuario, correo electrónico, rol, localidad a la que pertenece, etc. La forma más sencilla de crear un Claim es proporcionando un tipo y un valor en el constructor del Claim. El valor del claim se representa con un valor string. Para representar el tipo del claim tenemos la clase ClaimTypes, donde se representan los tipos predefinidos de claims más comunes. Normalmente son en formato URI, por ejemplo el tipo de email es http://schemas.microsoft.com/ws/2008/06/identity/claims/email.

Identity-4

La representación de los claims se nos figura en la siguiente tabla:

Identity-5

También podemos crear nuestro propio tipo de claim que no esté representado en el objeto ClaimTypes. La forma más sencilla es crearnos una clase de constantes donde tengamos representados nuestros tipos de claims y luego asociarlos al Claim correspondiente.

Identity-6

Para acceder a los claims de la identidad del usuario, utilizamos la clase de Thread.CurrentPrincipal. En este ejemplo accederemos al valor del email.

Identity-7

También podemos crear la excepción de credenciales fallidas del usuario:

Identity-8

Otra de las novedades que nos trae este sistema es que podemos crear un ClaimsIdentity para un usuario que todavía no está autenticado. Es un importante cambio, ya que en las versiones previas a ASP.NET Identity, cuando la clase Identity poseía un nombre en la propiedad Name, se consideraba al usuario autenticado. Pero con la clase ClaimsIdentity, es posible añadir una colección de claims a un usuario anónimo.

Por último, destacar que la compatibilidad de ASP.NET Identity con el sistema basado en OWIN. OWIN incluye componentes de middleware para la autentificación, donde podemos autenticar al usuario de manera local con el uso de la credenciales en nuestra aplicación, o utilizar sistemas externos como cuentas de Microsoft, Google, Twitter, Facebook… y nombres de usuarios que utilizan cuentas de organización como Active Directory o Windows Azure Active Directory.

Con OWIN Authentication además podemos generar la cookie utilizando OWIN CookieAuthentication. Anteriormente se utilizaba la autenticación de formularios y su trabajo consistía en generar una cookie para representar al usuario conectado actual. ClaimsIdentity contiene la información acerca de todas los claims del usuario. Para guardar en la cookie los claims del usuario, en el método SignIn agregamos los claims del usuario.

Identity-9

Para finalizar, el cierre de sesión con OWIN authentication manager se implementa llamado al método SignOut, el cual elimina la cookie generada:

Identity-11

Gracias a la integración de OWIN, al utilizar proveedores externos para la autentificación, son los propios proveedores externos lo que nos deben devolver los Claims del usuario, permitiéndonos aplicar a nivel de negocio las restricciones necesarias para decidir qué funcionalidad se le ofrece al usuario. Para poder utilizar este sistema, necesitaremos que nuestra aplicación soporte el sistema OWIN.

Referencias:

Descubre aquí todas las soluciones tecnológicas que Microsoft pone a tu alcance.

AmaiaAmaia Baigorri es Ingeniera Informática por la Universidad Pública de Navarra. Desde el 2011 trabaja dentro del mundo de la informática y en 2014 se incorpora a Sogeti España como programadora junior. Actualmente desarrolla funciones de programadora senior dentro de la Unidad de Soluciones Microsoft de Sogeti España.

 

 

2 thoughts

  1. Me ha gustado bastante el articulo.

    Como puedo activar las cuentas generadas, es decir; me gustaría que los usuarios registrados recibieran una liga (link) en su bandeja de entrada para activar su cuenta, y para tener el ejercicio mas completo quisiera que el usuario pueda recuperar su contraseña, ¿Como se puede hacer eso con ASP. Identity?

    Gracias

    Me gusta

    1. Hola,
      estos dos requisitos presentados son dos características clásicas que ya están descrita en el mismo sitio de Asp.Net Identity: https://www.asp.net/identity .
      Abriendo VisualStudio 2013 o superior (o Code) y creando una aplicación web (No Core!) eligiendo en autorización la modalidad ‘Individual user account ’ ya tienes cubierto el segundo requisito, veras que se crea un manager para la gestión de las cuentas usuario (el cambio de contraseña es algo ya asumido por la comunidad de desarrollo). Igualmente un buen artículo que explica come crear esta funcionalidad de forma segura es: https://coding.abel.nu/2015/05/secure-account-activation-with-asp-net-identity/
      El primer requisito es un poco más complejo, ya que debes ocuparte de proteger adecuadamente tus llamadas (el link de activación), pero en la v2.o de Asp.Net Identity ya está implementado: https://stackoverflow.com/questions/19295236/email-confirmation-with-mvc-5-and-asp-net-identity
      En cualquier caso, utiliza solamente https para estas operaciones, o la entera seguridad de tu sitio estará totalmente comprometida.
      Como último consejo, no grabes la contraseña, graba su hash, primero, tendrás mejor prestaciones, segundo, tu sistema será más seguro. Utiliza SHA256, ya que anteriores algoritmos han sido ya comprometidos.
      saludos

      Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s