Identity – Authorize

前言

Authorize 授权和 Identity Framework 关系不是很大. 虽然 Framework 有帮忙处理 Role, Claims 这些, 但这些只是整个 Authorize 小部分而已.

所以接下来我会用 Without Identity Framework 的方式来介绍 ASP.NET Core 如何实现 Authorize.

Simple Authorize

最常见的权限保护就是阻止页面访问和执行操作

由于 Razor Page 比较难 protect handler, 所以我用 MVC 来做示范 (虽然我的项目更多是防 Web API)

[Authorize]
public class AboutController : Controller
{
    public ActionResult Index()
    {
        return View("~/Controllers/About.cshtml");
    }

    [AllowAnonymous]
    public ActionResult Detail()
    {
        return View("~/Controllers/AboutDetail.cshtml");
    }
}

要 protect 整个 Controller 就加上 [Authorize], 要 protect Action 就在 Action 上加 [Authorize]

如果有例外就加上 [AllowAnonymous], 这样就可以了. 简单明了.

需要注意的是, [Authorize] 在 Controller, [AllowAnonymous] 在 Action 是可以的, 这个叫有例外要 by pass.

但是反过来就不可以, 比如 [AllowAnonymous] 在 Controller, [Authorize] 在 Action, 全部 bypass 但有一个例外要 protect, 这个表达是不 ok 的. (当然通常也不会出现这种情况, 因为默认都是不 protect 的丫, 怎么会要在 Controller 上加 AllowAnonymous 呢)

Role-Based

RBAC 是最常用的一种权限机制. Identity Framework 有提供这个封装.

先看看 protect 的时候如何声明需要的 Role

[Authorize(Roles = "Teacher")]
[Authorize(Roles = "Admin, Trainer")]
public ActionResult Index()
{
    return View("~/Controllers/About.cshtml");
}

在原本的 Authorize 标签里, 加上指定的 Role. 

"Admin, Trainer" 的意思是, 只要满足其中一个就可以了. 这是 " or " 的概念

上下 2 个 Authorize 标签则表示同时需要满足 2 个条件. 这是 " and " 的概念

所以上面整体的意思是 

Roles.Contains("Teacher") && (Roles.Contains("Admin") || Roles.Contains("Trainer"))

那这个 Role 是怎样 set 进去 cookie 的呢? 其实它就是一个 claim 而已.

public async Task OnPost()
{
    var claimsIdentity = new ClaimsIdentity(new List<Claim> {
        new Claim(ClaimTypes.Name, "UserName"),
        new Claim(ClaimTypes.Role, "Teacher"), // 这里
        new Claim(ClaimTypes.Role, "Trainer") // 这里
    }, CookieAuthenticationDefaults.AuthenticationScheme);

    await HttpContext.SignInAsync(
        CookieAuthenticationDefaults.AuthenticationScheme,
        new ClaimsPrincipal(claimsIdentity),
        new AuthenticationProperties()
    );
}

Identity Framework 在用户登入的时候, 会依据数据库设定好的 Role, Claims 生成 ClaimsPrincipal. 然后就接上 Authorize 的机制了.

要在 Identity Framework 使用 Role 需要额外添加.

Claims-Based

如果 Role 只是一种 Claim, 那么我们当然可以搞出其它的 Claim 验证.

假设需求是: 某些 Action 只有创始人能执行. 创始人不一定非要搞一个 Role 叫创始人

它可以是拥有 EmployeeNumber 1,2,3,4 或 5 的就代表是创始人.

那么我们就做一个 Policy 政策来表示这个逻辑

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("Founders", policy => policy.RequireClaim("EmployeeNumber", "1", "2", "3", "4", "5"));
});

Founders 是政策的名字, 后续的它的验证机制, 要求访问者持有 Claim, Key = EmployeeNumber, Value = 1, 2, 3, 4 或 5

这整套就叫 Claims-Based, 它的底层则是 Policy Based

所以在 ASP.NET Core 可以这么理解: Roled Based 是一种 Claims-Based 是一种 Policy-Based.

[Authorize(Policy = "Founders")]
public ActionResult Index()
{
    return View("~/Controllers/About.cshtml");
}

Policy Based

竟然 Policy Based 是老大, 那我们就好好聊聊它的机制.

What is Policy?

首先, Policy 是一个政策, 非常抽象, 你甚至可以认为它就是一个命名而已.

比如我有一个登入要权限管理, 那我就可以叫它 Login Policy. 我也可以把一些条件加入进去, 比如 Working Hour Login Policy.

它是很贴近业务管理的了.

What is Requirement?

如果 Policy 是抽象的命名, 那么具体是什么? 就是 Requirement 条件了.

权限管理就是在讲 “能不能”, 条件自然就是 "能" 的条件咯.

What is Handler?

条件只是一种声明, 具体还需要一个 “人” 来负责执行判断, 这个人就是 handler.

关系图

1 个 Policy 包含多个 requirements, 必须所有的 requirements 都满足才算通过.

1 个 requirement 可以被 1 个或多个 handler 了处理, 同样 1 个 handler 也可以处理多个 requirement.

在处理的过程中, 只要其中一个 handler 说这个 requirement 通过了, 那这个 requirement 就 pass 了, 不需要所有的 handler 都 pass.

这就是 ASP.NET Core Policy Based 的基本机制.

Why so complicated?

可能开始接触会搞不懂为什么它这样设计. Policy 很好理解. 

Requirement 和 Handler 拆开主要的目的是为了复用, 它可以多对多搭配来验证, 这样复用性就很高.

记得 Requirement 的职责是表达条件需求, Handler 是具体执行验证.

 

Policy Based 实战 

Requirements

它就是一个很普通的 class implement IAuthorizationRequirement 就可以了, IAuthorizationRequirement 其实是空的, 所以这里的 implement 只是为了声明而已.

里面有什么 property 就看需求咯, 比如 AgeRequirement 里面就可以有 property MinAge

public class MyRequirementA: IAuthorizationRequirement
{
    public string WhateverYouWant { get; set; } = "";
}
public class MyRequirementB : IAuthorizationRequirement
{
}
public class MyRequirementC : IAuthorizationRequirement
{
}

Policy with Requirements

在创建 Policy 的时候, 为其添加 Requirements

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy(
        "MyPolicy", 
        policy => {
            policy.Requirements.Add(new MyRequirementA());
            policy.Requirements.Add(new MyRequirementB());
            policy.Requirements.Add(new MyRequirementC());
        }
    );
});

Handlers

For 1 requirement 继承 AuthorizationHandler<TheRequirement> 

public class MyHandlerA : AuthorizationHandler<MyRequirementA>
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, MyRequirementA requirement)
    {
        context.Succeed(requirement);
        return Task.CompletedTask;
    }
}

通过 contextSucceed(requirement) 表示这个 requirement 通过了. 如果不通过的话就不要处理. 留给其它 handler.

For multiple requirements implement IAuthorizationHandler

public class MyHandlerABC : IAuthorizationHandler
{
    public Task HandleAsync(AuthorizationHandlerContext context)
    {
        var pendingRequirements = context.PendingRequirements.ToList();

        foreach (var requirement in pendingRequirements)
        {
            if (requirement is MyRequirementB)
            {
                context.Succeed(requirement);
            }
            if (requirement is MyRequirementC)
            {
                context.Succeed(requirement);
            }
        }
        return Task.CompletedTask;
    }
}

里面可以获取到还没有 succeed 的 requirements, 然后就可以遍历验证了.

Dependency Injection, 所有 Handlers 都需要提供给依赖注入

builder.Services.AddScoped<IAuthorizationHandler, MyHandlerA>();
builder.Services.AddScoped<IAuthorizationHandler, MyHandlerB>();
builder.Services.AddScoped<IAuthorizationHandler, MyHandlerABC>();

Scope Variable in handler process

在验证过程中, handler 可以使用 requirement 中的信息, User 信息, Resource 信息做一个逻辑判断

比如, User 有没有 Claim.Age.Value 小于 AgeRequirement.MinAge, 

context.Resource 是一个 object, 如果使用的地方是 Controller 那么它就是 HttpContext.

还有一种使用 policy 的方式是 manual 调用, 这种时候 Resource 就是由调用者负责的, 通常用于 Resource-Based 和 View-Based

public async Task<ActionResult> IndexAsync([FromServices] IAuthorizationService authorizationService)
{
    var result = await authorizationService.AuthorizeAsync(
        user: User, 
        resource: HttpContext, // 要传什么都可以
        policyName: "MyPolicy"
    );

    return View("~/Controllers/About.cshtml");
}

这种情况, Handler 可以通过泛型声明 Resource 类型

public class MyHandlerA : AuthorizationHandler<MyRequirementA, DefaultHttpContext>
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, MyRequirementA requirement, DefaultHttpContext resource)
    {
        context.Succeed(requirement);
        return Task.CompletedTask;
    }
}

总结

Role-Based, Claims-Based 说到底还是 Policy-Based 来的.

也有人把它叫成 ABAC Attribute-Based, 其实概念都差不多.

任何一种权限验证不外乎就是 

在一个环境 Enviroment (时间, 地点, 网络等)

一个主体 Subject (User, Claims)

想对一个客体 Object (Controller, Entity, File)

做一个操作 Action (访问, CRUD)

然后检查看是否符合所有条件. 最后能不能通过.

在 ASP.NET Core, 1 个 Policy 就表示一套上面的规则, Subject 就是 User, 里面很多 Claims

Action 一般上是访问 Controller, CRUD Entity.

Object 和 Enviroment 就是 context.Resource. 可以是 HttpContext, 也可以传入一个 Entity 等等.

然后 Handler 依据 requirement 来做判断, 得出结果能不能. 

额外小知识

当 Controller 返回 ForbinResult 的时候, 会自动跳转到 Account/AccessDenied 页面, 但在 Web API 的情况通常不希望跳转.

解决方法是不要返回 ForbinResult, 取而代之的是返回 StatusCode 403

return StatusCode(StatusCodes.Status403Forbidden)