domingo, 20 de octubre de 2013

Claims Series 3: Herencia y compatibilidad

Continuamos el estudio de todo lo relacionado a las claims respondiendo una pregunta clave: Si en .NET 4.5 todo el modelo de seguridad se ha movido hacia un esquema basado en claims, ¿Qué pasa con mis viejas aplicaciones que hacían uso de Identity y Principal?

Para responder una imagen vale más que mil palabras. Así está la jerarquía de clases del Framework relativa a identidades (como veis he añadido una clase de mi cosecha, hablamos de ella luego):




¿Qué quiere decir todo esto? Pues que efectivamente todo son claims, como veis, un GenericIdentity de los de antes ahora a pasado a heredar de ClaimsIdentity, mientras que en versiones previas del framework, esta clase implementaba directamente IIdentity.

Si instanciamos una identidad genérica, por debajo estamos instanciando una identidad basada en claims. ¿Cuál será la salida del siguiente código?
   1:  static void Main(string[] args)
   2:  {
   3:     var oldIdentity = new GenericIdentity("Sergio");
   4:   
   5:     foreach(var cl in oldIdentity.Claims)
   6:     {
   7:         Console.WriteLine("Tipo:{0} Valor:{1}", cl.Type, cl.Value);
   8:     }
   9:  }

Aquí la teneis, la identidad almacena un único claim, cuyo tipo es http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name



Parece claro que la compatibilidad hacia atrás está garantizada, ya que este esquema que os acabo de presentar se sigue también para los objetos tipo principal.

 

Generando nuestra propias identidades


En la entrada anterior (Claims Series 2: Un poco de código por favor) veíamos como podíamos crear identidades generando una colección de claims. Es sencillo, pero desde luego no es muy elegante:

   1:  var cl1=new Claim("http://serginet.com/categoria","senior");
   2:  var cl2=new Claim("http://serginet.com/edad","36");
   3:  var cl3=new Claim("http://serginet.com/ciudad","Arroyomolinos");
   4:   
   5:  var identidad = new ClaimsIdentity(new List<Claim>() { cl1, cl2, cl3 });

Vemos que en el Framework han usado herencia... ¿por que no usarla nosotros también?
Creemos nuestra propia identidad, heredando de ClaimsIdentity y aprovechemos a exponer propiedades para las claims almacenadas.

   1:  public class SerginetIdentity: ClaimsIdentity
   2:  {
   3:      public const string CTE_CategoriaProfesional = "http://serginet.com/categoriaProfesional";
   4:      public const string CTE_Edad = "http://serginet.com/edad";
   5:      public const string CTE_AccesoDocumentosSecretos = "http://serginet.com/accesoDocumentosSecretos";
   6:   
   7:      public SerginetIdentity(string categoriaProfesional, int edad, bool accesoDocumentosSecretos)
   8:      {
   9:          var cl1=new Claim(CTE_CategoriaProfesional,categoriaProfesional);
  10:          var cl2=new Claim(CTE_Edad,edad.ToString());
  11:          var cl3=new Claim(CTE_AccesoDocumentosSecretos,accesoDocumentosSecretos.ToString());
  12:   
  13:   
  14:          this.AddClaims(new List<Claim>() { cl1, cl2, cl3 });
  15:      }
  16:   
  17:      public string CategoriaProfesional
  18:      {
  19:          get
  20:          {
  21:              return this.FindFirst(CTE_CategoriaProfesional).Value;
  22:          }
  23:      }
  24:   
  25:      public int Edad
  26:      {
  27:          get
  28:          {
  29:              return int.Parse(this.FindFirst(CTE_Edad).Value);
  30:          }
  31:      }
  32:          
  33:      public bool AccesoDocumentosSecretos
  34:      {
  35:          get
  36:          {
  37:              return Boolean.Parse(this.FindFirst(CTE_AccesoDocumentosSecretos).Value);
  38:          }
  39:      }
  40:   
  41:  }

Como veis es sencillo, fácil de usar desde fuera, y será la base de la próxima entrada: Transformando claims.

Como siempre os dejo el código

Posts publicados en Claims Series:


viernes, 18 de octubre de 2013

Claims Series 2: Un poco de código por favor

Continuando la serie de post sobre claims... vamos al grano! Empecemos con algo de código:

Creando claims


¿Cómo creamos claims? Muy sencillo, como veíamos en el primer post sólo necesitamos un tipo y un valor

var primerClaim = new Claim("Nombre", "Tobías");

¿No parece muy elegante trabajar con cadenas "hardcodeadas"? Pues disponemos de enumerados que nos echarán una mano con tipos de claim prefedinidos:

var segundoClaim = new Claim(ClaimTypes.Country, "Antigua y Barbuda")

Si echamos un ojo a los valores disponibles, vemos que hay bastantes, y que todos están determinados con namespaces completos (buena práctica para evitar colisiones).



En cualquier caso, si lo predefinido no basta, definiremos nuestros propios tipos, siempre utilizando namespaces (y constantes o enumerados por favor):

var tercerClaim = new Claim("http://serginet.com/AficionPrincipal", "Tecnología");

Lo normal es que un usuario disponga de más de un claim, así que lo habitual será crear colecciones de claims:

IList<Claim> coleccionClaims = new List<Claim>
{
primerClaim, segundoClaim, tercerClaim
};

Identidades y principals


Una vez que disponemos de una colecciónd de claims, podemos crear una identidad:


var identidad = new ClaimsIdentity(coleccionClaims);

Y comprobar si dicha entidad está o no autenticada:

Console.WriteLine("Identidad autenticada:" + identidad.IsAuthenticated);

Si lo ejecutas verás que no... para hacerlo, tan solo tenemos que crear la identidad estableciendo un tipo de autenticación:

var identidadAutenticada = new ClaimsIdentity(coleccionClaims,"Autenticacion basica serginet.com");

Y finalmente con una identidad podemos crear un principal (el contexto de seguridad bajo el que se ejecuta nuestra código) y asignarlo a nuestro thread de ejecución::

var principal = new ClaimsPrincipal(identidadAutenticada);
Thread.CurrentPrincipal = principal;

Como veis todo parece bastante sencillo... continuaremos en la siguiente entrega haciendo uso de todos estos conceptos para lo que realmente importa: Hacer uso en nuestra aplicación de los claims para tareas de autenticación y autorización.

Aquí os dejo el código

Post publicados en Claims Series:



jueves, 17 de octubre de 2013

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.

sábado, 5 de octubre de 2013

Cobertura de código en Visual Studio 2012. Como excluir el assembly de test de los resultados

Por defecto, en Visual Studio 2012, nos encontramos que tras la ejecución de nuestros test, al analizar la cobertura de código,  ésta tiene en cuenta el código de los propios tests unitarios. Mirad:





Esto provoca que el dato este desvirtuado. El código que estoy testando esta cubierto al 100%... pero el resultado global de cobertura es inferior ¿No es eso lo que queremos verdad?


Evitarlo es muy sencillo: tan solo hay que decorar nuestras clases de test con el atributo ExcludeFromCodeCoverage. ¿Fácil no?

Si lo hacemos veremos lo que buscábamos: Nuestro código cubierto al 100%