El documento habla sobre autorización en .NET Core. Explica que la autorización determina qué información y acciones puede realizar un usuario basado en sus claims (datos de identidad), y posiblemente el estado del recurso. Luego describe que la autorización en .NET Core se basa en políticas de autorización compuestas por requisitos y manejadores, los cuales determinan si se concede o no el acceso. Finalmente, cubre temas como políticas simples y basadas en código, autorización imperativa y basada en recursos, y el uso de diferentes esque
3. Agenda
• De dónde venimos
• Authorization Policies
• Requerimientos sencillos basados en información del usuario
• Requerimientos basados en código
• Autorización en función del estado del recurso
• Uso de diferentes esquemas
https://github.com/hbiarge/Authorization-Workshop
4. Authentication vs Authorization
Autenticación
Identificar elementos de autenticación en la petición, interpretarlos y
crear instancia de ClaimsPrincipal con los claims del usuario
Autorización
En base a los claims del usuario (y del estado del recurso al que
accede), que información puede obtener y/o qué acciones puede
realizar
5. De dónde venimos
• [Authorize] y [AllowAnonymous] en WebApi y MVC de full
Framework
• Único mecanismo existente “out of the box”
• Soporte de roles y usuarios
• Implementado como un filtro de Autenticación
• Determina el momento del procesamiento de la petición en el que el código se ejecuta
6. ClaimsPrincipal and ClaimsIdentity
• ClaimsPrincipal agrega los Claims de una o varias identidades con las
que se puede haber autenticado la petición
• Cada ClaimsIdentity contiene el conjunto de Claims de un esquema
de autenticación
• Un Claim es una estructura que define:
• Name: Clave (puede haber duplicados)
• Value: Valor
• Issuer: Quién lo ha emitido
7. Setup de los ejemplos
• TestHost
• Acheve.TestHost.Security
8. Pero… en .Net Core es igual, no?
• [Authorize] y [AllowAnonymous] también existen en .Net Core
• Hace que el uso básico de los atributos tenga el mismo resultado que en
versions anteriores
• La infraestructura subyacente es completamente nueva
• Soporta solo Roles (por motivos de compatibilidad) y Policies
9. Políticas de autorización
• Compuestas por uno o más Requirements
• Un Requirement es gestionado por uno o más Handlers
• Una Política será satisfecha (autorizada) si TODOS los Requirements
son autorizados
• Un Requirement está autorizado si por lo menos uno de sus Handlers lo
autoriza
• Por defecto, se evalúan todos los Handlers registrados para un
Requirement aunque alguno falle
10. Infraestructura de autorización
• Requirements y Handlers
• IAuthorizationRequirement
• AuthorizationHandler<IAuthorizationRequirement>
• AuthorizationHandler<IAuthorizationRequirement, Resource>
• El Requirement define el contexto de autorización
• Proporciona el estado
• El Handler define la lógica de autorización teniendo en cuenta:
• Contexto de autorización
• Requirement
• (opcionalmente) El recurso a autorizar
11. Lógica de autorización (Handlers)
• Si la autorización es correcta -> context.Succeed(requirement)
• Si la autorización NO es correcta -> no hacer nada!
• Puede haber otros Handlers para el mismo Requirement
• Sólo en casos extremos -> context.Fail()
13. Políticas como código
public class MinimumAgeRequirement
: AuthorizationHandler<MinimumAgeRequirement>, IAuthorizationRequirement
{
protected override void Handle(
AuthorizationContext context, MinimumAgeRequirement requirement)
{
// Logic to validate requirement
context.Succeed(requirement);
}
}
// In Startup ConfigureServices
options.AddPolicy("Over18Only", policy =>
{
policy.Requirements.Add(new MinimumAgeRequirement(18));
});
14. Autorización imperativa
IAuthorizationService en Controladores o Vistas
public async Task<IActionResult> Index()
{
if (await _authorizationService.AuthorizeAsync(User, Policies.Over21))
{
// User is authorized here.
}
else
{
return new ChallengeResult();
}
}
15. Autorización basada en recursos
• AuthorizationHandler<Requirement, Resource>
• En el método Handle tenemos acceso al recurso de forma tipada
public class ProductAuthorizationHandler
: AuthorizationHandler<OperationAuthorizationRequirement, Product>
{
protected override void Handle(
AuthorizationContext context,
OperationAuthorizationRequirement requirement,
Product resource)
{ // Logic to validate requirement }
}
16. Diferentes esquemas de autorización
• Podemos definirlos tanto en las políticas como en el atributo
[Authorize]
• Mezcla en el ClaimsPrincipal una ClaimsIdentity por cada esquema
requerido
• El ClaimsPrincipal expone todos los claims agregados de todos los
ClaimsIdentity definidos
• Redefine el esquema de autenticación predefinido