Compartir a través de


Introducción a la identidad basada en Claims

El modelo de seguridad basado en Claims permite disponer de las funcionalidades habituales de autenticación y autorización en una aplicación, centralizando todo el proceso en servicios externos a la propia aplicación, servicios desarrollados y mantenidos por expertos en seguridad.

Access Control es un servicio ofrecido por la plataforma Windows Azure que provee de la funcionalidad que se acaba de mencionar. En lugar de tener que escribir en cada aplicación que se desarrolle la lógica de autenticación y autorización, se puede usar Access Control para delegar estas dos funcionalidades en este servicio.

Access Control permite configurar diferentes proveedores de identidad, para poder realizar las labores de autenticación y autorización. Por ejemplo, permite que las empresas puedan realizar las validaciones empleando las cuentas de Active Directory, empleando ADFS v2. Del mismo modo permite otros proveedores de identidad, como puede ser Facebook, Google o Windows Live ID.

El código necesario a implementar en las aplicaciones cliente y servidor resulta muy sencillo, ya que la lógica realmente importante recae en Access Control.

Cuando se utiliza Access Control dentro de un servicio, el usuario que quiera conectarse al servidor  debe obtener primero un token de seguridad del Access Control para poder conectarse. Un token de seguridad está compuesto por un conjunto de claims. Un claim puede definirse como un atributo nombre-valor, que aporta información sobre la identidad del usuario que intenta realizar la conexión.


Figura 1.- Ejemplo de Claims

Cuando un usuario solicita el token de seguridad al Access Control, éste deberá comprobar previamente la identidad del usuario que los solicita. El usuario debe poder demostrar su identidad. Access Control validará la identidad contra el proveedor configurado; Active Directory, Windows Live ID...

Una vez validado el usuario, el Access Control devolverá el token de seguridad al usuario. El usuario obtendrá el token y realizará la llamada al servicio, pasando en la petición el token devuelto por Access Control.


Figura 2.- Proceso de conexión

Access Control permite un sencillo modelo declarativo de reglas por el cuál pueden configurarse el token a devolver en función del usuario que realizar la solicitud.

Beneficios de la seguridad basada en Claims

Bajo este modelo es más fácil de conseguir escenario de single sing-on y los servicios que se implementan se pueden olvidar de las siguientes responsabilidades:

  • Autenticación de usuarios.
  • Guardar usuarios y contraseñas.
  • Llamar a entidades externas, como Active Directory, para validar las identidades.
  • Integración con proveedores de identidades externos.

Este modelo permite a un servicio tomar las decisiones sobre la identidad de un usuario en base a los claims que el envía el usuario, pero con la confianza de que estos claims ha sido obtenido previamente a través de una comunicación con Access Control.

Descripción del proceso

En la Figura 2 puede verse el diagrama general que describe el proceso a seguir por una aplicación cliente que desea conectarse a un servicio REST.

El primer paso que debe realizar siempre el cliente es conectarse con el Access Control, para obtener un token de seguridad que le permita conectarse al servicio.

Para poder obtener el token el cliente realizar una petición por HTTP POST al Access Control incluyendo el nombre de usuario y contraseña y la URI a la que desea conectarse, la URI dónde se encuentra el servicio.

Access Control deberá validar la identidad del usuario. En primera instancia validará el usuario y la contraseña con el proveedor que tenga configurado. Si la validación es correcta, devolverá el token de seguridad, que está compuesto por un conjunto de claims. Los claims que se incluyen dentro del token de seguridad dependen de las reglas configuradas en el Access Control, reglas que pueden personalizarse.

Una vez que el cliente dispone del token de seguridad deberá incluirlo dentro de las cabeceras HTTP de la petición. El servicio web leerá las cabeceras HTTP, validará el contenido de la cabecera y obtendrá los claims que en ésta se incluyen. La aplicación podrá disponer de la lógica necesaria para actuar en función de los claims recibidos.

En el siguiente fragmento de código se muestra un ejemplo de cómo interactuar con Access Control para solicitar un token de seguridad. Access Control permite recibir solicitudes a través de un protocolo llamado WRAP (Web Resource Authorization Protocol), basado en REST.

private static string GetTokenFromACS(string issuerKeySuppliedByCaller) 
{
// request a token from ACS
WebClient client = new WebClient();
client.BaseAddress = string.Format("https://{0}.{1}",
serviceNamespace, acsHostName);  
NameValueCollection values = new NameValueCollection();
values.Add("wrap_name", "my-issuer");
values. Add("wrap_password", issuerKeySuppliedByCaller);
values.Add("wrap_scope", "https://localhost/ACSGettingStarted");
byte[] responseBytes= client.UploadValues("WRAPv0.9", "POST",values);
 string response = Encoding.UTF8.GetString(responseBytes);  
return response .Split('&').Single(value => value.StartsWith
("wrap_access_token=",StringComparison.OrdinalIgnoreCase)).Split('=')[1];
}

Una vez recuperado el token, éste debe ser incluido en las cabeceras HTTP.

private static string SendMessageToService(string token,string valueToReverse)  
{
WebClient client = new WebClient();
client.BaseAddress = "https://localhost/ACSGettingStarted/Default.aspx";  
string headerValue = string.Format("WRAP access_token=\"{0}\""
,HttpUtility.UrlDecode(token));   client.Headers.
Add("Authorization", headerValue);  
NameValueCollection values = new NameValueCollection();
values = new NameValueCollection();
values.Add ("string_to_reverse", valueToReverse);  
byte[] serviceResponseBytes = client.UploadValues(string.Empty, values);
return Encoding.UTF8.GetString(serviceResponseBytes);
}