Claims Series 1: Una introducción a claims para profanos, como yo :-)

Desde hace varios años venimos escuchando que la "nueva tendencia" para seguridad (autenticación y autorización) está basada en claims.

¿Qué son los claims (o demandas /reclamaciones)?
¿Qué relación tienen con otros conceptos como SAML, proveedores de tokens, federación, etc...?

A todo esto voy a tratar de contestar en varios post (espero no se demoren demasiado).
Empecemos por el principio:

Como se ha manejado la seguridad tradicionalmente (en entornos .NET)

Desde los inicios del Framework, hemos venido trabajado con 2 conceptos: Identidad y Principal

La identidad, representada con clases que implementan IIdentity, nos dice quien: El usuario es Efraín
El principal, representado con clases que implementan IPrincipal, nos dice quien y que puede hacer: El usuario es Efraín y es un vendedor.

Todo lo que puede hacer un usuario se ha encapsulado en diversos roles: Vendedor es un rol, administrador otro... y en el código, se ha preguntado por los roles para permitir a un usuario realizar una acción o no.

Pues bien, parece que esto ha funcionado razonablemente bien durante años, pero hoy en día, la granularidad de permisos que requieren las aplicaciones modernas ha hecho que el trabajo con roles se haya vuelto muy tedioso:

• Aparecen multitud de roles a mantener
• En nuestras aplicaciones aparecen eternos if/then/else del siguiente tipo:

   1:  static void Main(string[] args)

   2:  {

   3:        IPrincipal currentPrincipal = Thread.CurrentPrincipal;

   4:   

   5:        if (currentPrincipal.IsInRole("ADM"))

   6:        {

   7:           //Habilitar todos los botones

   8:        }

   9:        else if (currentPrincipal.IsInRole("Ventas"))

  10:        {

  11:           //Habilitar los botones rfelativos a ventas

  12:        }

  13:        else if (currentPrincipal.IsInRole("opoeraciones"))

  14:        {

  15:           //Lo que sea

  16:        }

  17:  }

• Las gran cantidad de roles nos lleva a crear un rol de administrador... y lo que es peor, a veces no es suficiente y creamos al superadministrador.

Deshaciendo el entuerto: claims al rescate

Parece lógico huir de los roles...  vamos a expresar la información acerca de un usuario (quien es y qué puede hacer) en base a sencillas afirmaciones:

• Evaristo es un administrador.
• Evaristo vive en Villarriba.
• Liborio puede ver las estadísticas de venta.
• Tobías también, pero solo las del último año.

Como veis, estas afirmaciones expresan mucho más que simplemente poner a un usuario en un rol... ¡parece que así salimos ganando!

Por otro lado, queda algo con contestar: ¿Quién emite estas afirmaciones? Normalmente un tercero, en el que se confía, y que llamaremos issuer. Ejemplo: El active directory de mi compañía dice que Pedro es un vendedor.

Ya tenemos los 3 elementos que necesitamos para definir un claim:

• Tipo (type)
• Valor (value)
• Emisor (issuer)

Algunos ejemplos:

Type	Value	Issuer
Nombre	Tobias	serginet.com
email	Tobias@serginet.com	serginet.com
Visibilidad de ventas	Total	serginet.com

Además de granularidad ganamos en compatibilidad: diferentes sistemas pueden compartir claims. No parece muy "inmediato" enviar  una identidad Windows desde una aplicación .NET a otra SAP... sin embargo si pensamos en claims, todo se nos antoja más sencillo



Espero haber aclarado el concepto... continuaremos por lo que nos gusta: algo de código, pero en la siguiente entrega.