天天看點
傳回

asp.net core 3.x 授權預設流程

一、前言

接上一篇《asp.net core 3.x 授權中的概念》，本篇看看asp.net core預設授權的流程。從兩個方面來看整個授權系統是怎麼運作的：啟動階段的配置、請求階段中間件的處理流程。

由于asp.net core 3.x目前使用終結點路由，是以授權架構可以用于所有asp.net web項目類型，比如：webapi mvc razorpages...。但本篇隻以MVC為例

回到頂部

二、核心概念關系圖

asp.net core 3.x 授權預設流程

三、啟動階段的配置

主要展現為3點

  1. 注冊相關服務
  2. 配置授權選項對象AuthorizationOptions
  3. 注冊授權中間件

3.1、注冊相關服務和選項配置

在mvc項目Startup.ConfigreServices中services.AddControllersWithViews(); （MvcServiceCollectionExtensions）用來向依賴注入架構注冊各種mvc相關服務。其中會調用services.AddAuthorization(選項)擴充方法（PolicyServiceCollectionExtensions）注冊授權相關服務，此擴充方法内部還會調用兩個擴充方法，這裡不再深入。

這裡主要需要搞懂2個問題：

  1. 方法傳入的選項
  2. 具體注冊了哪些服務

3.1.1、授權選項AuthorizationOptions

AddAuthorization擴充方法的參數是Action<AuthorizationOptions>類型的，這是asp.net core中典型的選項模型，将來某個地方需要時，直接注入此選項對象，那時依賴注入容器會使用此委托對這個選項對象指派。是以我們在啟動時可以通過此對象來對授權架構進行配置。

最最重要的是我們可以在這裡配置全局授權政策清單，參考上圖的右側中間部分，源碼不多，注意注釋。

//代表授權系統的全局選項對象，裡面最最核心的就是存儲着全局授權政策
public class AuthorizationOptions
{
    //存儲全局授權政策（AuthorizationPolicy），key是政策唯一名，友善将來擷取
    private IDictionary<string, AuthorizationPolicy> PolicyMap { get; } = new Dictionary<string, AuthorizationPolicy>(StringComparer.OrdinalIgnoreCase);
    //授權驗證時，将周遊所有授權處理器（Authorization）逐個進行驗證，若某個發生錯誤是否立即終止後續的授權處理器的執行
    public bool InvokeHandlersAfterFailure { get; set; } = true;
    //預設授權政策，拒絕匿名通路
    public AuthorizationPolicy DefaultPolicy { get; set; } = new AuthorizationPolicyBuilder().RequireAuthenticatedUser().Build();
    //若将來授權檢查時沒有找到合适的授權政策，預設授權政策也是空的情況下會回退使用此政策
    public AuthorizationPolicy FallbackPolicy { get; set; }
    //添加全局政策
    public void AddPolicy(string name, AuthorizationPolicy policy)
    {
        if (name == null)
        {
            throw new ArgumentNullException(nameof(name));
        }

        if (policy == null)
        {
            throw new ArgumentNullException(nameof(policy));
        }

        PolicyMap[name] = policy;
    }
    //添加全局政策，同時可以對此政策進行配置
    public void AddPolicy(string name, Action<AuthorizationPolicyBuilder> configurePolicy)
    {
        if (name == null)
        {
            throw new ArgumentNullException(nameof(name));
        }

        if (configurePolicy == null)
        {
            throw new ArgumentNullException(nameof(configurePolicy));
        }

        var policyBuilder = new AuthorizationPolicyBuilder();
        configurePolicy(policyBuilder);
        PolicyMap[name] = policyBuilder.Build();
    }
    //擷取指定名稱的政策
    public AuthorizationPolicy GetPolicy(string name)
    {
        if (name == null)
        {
            throw new ArgumentNullException(nameof(name));
        }

        return PolicyMap.ContainsKey(name) ? PolicyMap[name] : null;
    }
}

AuthorizationOptions

複制

舉個栗子：

services.AddControllersWithViews();
services.AddRazorPages();
services.AddAuthorization(opt =>
{
    opt.AddPolicy("授權政策1", builer => {
        builer.RequireRole("admin", "manager");
        builer.AddAuthenticationSchemes("cookie", "google");
        //繼續配置....
    });
    opt.AddPolicy("授權政策2", builer => {
        builer.RequireRole("teacher");
        builer.AddAuthenticationSchemes("wechat", "qq");
        //繼續配置....
    });
});

複制

3.1.2、具體注冊了哪些服務：

  • 政策評估器IPolicyEvaluator：名字有點詭異。預設實作PolicyEvaluator，授權中間件委托它來實作身份驗證和授權處理，它内部會調用AuthorizationService，進而執行所有授權處理器AuthorizationHandler
  • 授權服務IAuthorizationService：上一篇有說，不詳述了，預設實作DefaultAuthorizationService，除了授權中間件會調用它來進行授權處理，我們業務代碼中也可以調用它來做授權驗證，比如：針對資源的特殊授權
  • 授權政策提供器IAuthorizationPolicyProvider：預設實作DefaultAuthorizationPolicyProvider，可以通過它來擷取指定名稱的授權，它就是從全局授權政策清單裡去找，也就是上面說的AuthorizationOptions中
  • 授權處理器提供器IAuthorizationHandlerProvider：預設實作DefaultAuthorizationHandlerProvider，通過它來擷取系統中所有的授權處理器，其實就是從IOC容器中擷取
  • 授權評估器IAuthorizationEvaluator：預設實作DefaultAuthorizationEvaluator，授權處理器AuthorizationHandler在執行完授權後，結果是存儲在AuthorizationHandlerContext中的，這裡的評估器隻是根據AuthorizationHandlerContext建立一個授權結果AuthorizationResult，給了我們一個機會來加入自己的代碼而已
  • 授權處理器上下文對象的工廠IAuthorizationHandlerContextFactory：預設實作DefaultAuthorizationHandlerContextFactory，授權處理器AuthorizationHandler在授權時需要傳入AuthorizationHandlerContext（上面說了授權完成後的結果也存儲在裡面）。是以在執行授權處理器之前需要建構這個上下文對象，就是通過這個工廠建構的，主要的資料來源就是 目前 或者 指定的 授權政策AuthorizationPolicy
  • 授權處理器IAuthorizationHandler：預設實作PassThroughAuthorizationHandler。授權的主要邏輯在授權處理器中定義，授權服務在做授權時會周遊系統所有的授權處理器逐一驗證，而驗證往往需要用到授權依據，PassThroughAuthorizationHandler比較特殊，它會看授權依據是否已經實作了IAuthorizationHandler，如過是，則直接把授權依據作為授權處理器進行執行。因為多數情況下一個授權處理器類型是專門針對某種授權依據定義的。

這些接口都是擴充點，就問你怕不怕？當然絕大部分時候我們不用管，預設的就足夠用了。

3.2、注冊授權中間件

主要注意的位置的為題，必須在路由和身份驗證之後。

1 app.UseRouting();
2 app.UseAuthentication();
3 app.UseAuthorization();

複制

擴充方法内部注冊了AuthorizationMiddleware

四、請求階段的處理流程

如果你對mvc稍有經驗，就曉得在一個Action上使用[Authorize]就可以實施授權，現在我們假設我們在預設mvc項目中的HomeController定義如下Action，并應用授權标簽

[Authorize(Policy = "p1")]//使用全局授權政策中的"p1"進行授權判斷
        [Authorize(AuthenticationSchemes = "google")]//隻允許使用google身份驗證登入的使用者通路
        [Authorize(Roles = "manager")]//隻允許角色為manager的通路
        public IActionResult Privacy()
        {
            return View();
        }

複制

4.1、授權中間件AuthorizationMiddleware

核心步驟如下：

  1. 從目前請求拿到終結點
  2. 通過終結點拿到其關聯的IAuthorizeData集合
  3. 調用AuthorizationPolicy.CombineAsync根據IAuthorizeData集合建立一個複合型政策，此政策就是本次用來做授權檢查的政策，也就是文章中多次提到的目前這略
  4. 從IOC容器中擷取政策評估器對上面得到的政策進行身份驗證，多種身份驗證得到的使用者證件資訊會合并進HttpContext.User
  5. 若Action上應用了IAllowAnonymous，則放棄授權檢查（為毛不早點做這步？）
  6. 通過政策評估器對政策進行授權檢查，注意這裡的參數，傳入身份驗證評估結果和将終結點作為資源
  7. 若授權評估要求質詢，則周遊政策所有的身份驗證方案，進行質詢，若政策裡木有身份驗證方案則使用預設身份驗證方案進行質詢
  8. 若授權評估拒絕就直接調用身份驗證方案進行拒絕

步驟1、2得益于asp.net core 3.x的終結點路由，我們可以在進入MVC架構前就拿到Action及其之上應用的各種Atrribute，進而得到我們對目前授權政策定制所需要的資料

步驟3會根據得到IAuthorizeData集合（AuthorizeAttribute實作了IAuthorizeData，它不再是一個過濾器）建立目前準備用來做授權的政策。授權政策中 “身份驗證方案清單” 和 “授權依據清單”，就是通過這裡的标簽來的。具體來說：

  • [Authorize(Policy = "p1")]：會通過“p1”去全局授權政策（AuthorizationOptions對象中）拿到對應的政策，然後與目前政策合并，也就是把“p1”政策中的身份驗證方案清單、授權依據清單與目前政策合并。
  • [Authorize(AuthenticationSchemes = "google")]：用來定制目前政策的“身份驗證方案清單”，當然最終和上面說的合并，
  • [Authorize(Roles = "manager")]：會建立一個RolesAuthorizationRequirement類型的授權依據加入到目前政策中

這些Attribute可以應用多次，最終都是來定制目前授權政策的。後續步驟都會依賴此授權政策。

步驟4中，若發現本次授權政策中定義了多個身份驗證方案，則會注意進行身份驗證，得到的多張證件會合并到目前使用者HttpContext.User中，當然預設身份驗證得到的使用者資訊也在其中。

上面步驟4、6是委托政策評估器PolicyEvaluator來完成的，往下看..

4.2、政策評估器PolicyEvaluator

核心任務就兩個，身份驗證、進行授權

4.2.1、AuthenticateAsync

若政策沒有設定AuthenticationSchemes，則隻判斷下目前請求是否已做身份驗證，若做了就傳回成功

若政策設定了AuthenticationSchemes，則周遊身份驗證方案逐個進行身份驗證處理 context.AuthenticateAsync(scheme); ，将所有得到的使用者辨別重組成一個複合的使用者辨別。

4.2.2、AuthorizeAsync

調用IAuthorizationService進行權限判斷，若成功則傳回成功。

否則 若身份驗證通過則 PolicyAuthorizationResult.Forbid() 直接通知身份驗證方案，做拒絕通路處理；否則傳回質詢

是以授權檢查的任務又交給了授權服務AuthorizationService

4.3、授權服務AuthorizationService

核心步驟如下：

  1. 通過IAuthorizationHandlerContextFactory建立AuthorizationHandlerContext，此上下文包含：授權依據（來源與目前授權政策） 目前使用者（httpContext.User）和資源（目前終結點）
  2. 周遊所有授權處理器AuthorizationHandler，這些授權處理器是通過IAuthorizationHandlerProvider擷取的，預設情況下是從IOC容器中擷取的。逐個調用每個授權處理器執行授權檢查
  3. 所有授權處理器執行驗證後的結果還是存儲在上面說的這個上下文對象AuthorizationHandlerContext中。回調授權評估器IAuthorizationEvaluator将這個上下文對象轉換為授權結果AuthorizationResult

步驟2還會判斷AuthorizationOptios.InvokeHandlersAfterFailure，來決定當某個處理器發生錯誤時，是否停止執行後續的授權處理器。

4.4、授權處理器AuthorizationHandler

前面講過，預設隻注冊了一個PassThroughAuthorizationHandler授權處理器，它會周遊目前授權政策中實作了IAuthorizationHandler的授權依據（意思說這些對象既是授權處理器，也是授權依據）。直接執行它們。

public class PassThroughAuthorizationHandler : IAuthorizationHandler
{
    public async Task HandleAsync(AuthorizationHandlerContext context)
    {
        foreach (var handler in context.Requirements.OfType<IAuthorizationHandler>())
        {
            await handler.HandleAsync(context);
        }
    }
}

複制

以基于角色的授權依據RolesAuthorizationRequirement為例，它繼承于AuthorizationHandler<RolesAuthorizationRequirement>，且實作IAuthorizationRequirement

public class RolesAuthorizationRequirement : AuthorizationHandler<RolesAuthorizationRequirement>, IAuthorizationRequirement
{
    //省略部分代碼...
    public IEnumerable<string> AllowedRoles { get; }
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, RolesAuthorizationRequirement requirement)
    {
        if (context.User != null)
        {
            bool found = false;
            if (requirement.AllowedRoles == null || !requirement.AllowedRoles.Any())
            {
                // Review: What do we want to do here?  No roles requested is auto success?
            }
            else
            {
                found = requirement.AllowedRoles.Any(r => context.User.IsInRole(r));
            }
            if (found)
            {
                context.Succeed(requirement);
            }
        }
        return Task.CompletedTask;
    }
}

複制

五、最後

可以感受到asp.net core 3.x目前的權限設計棒棒哒，預設的處理方式已經能滿足大部分需求，即使有特殊需求擴充起來也非常簡單，前面注冊部分看到注冊了各種服務，且都有預設實作，這些服務在授權檢查的不同階段被使用，如果有必要我們可以自定義實作某些接口來實作擴充。本篇按預設流程走了一波，最好先看前一篇。這時候再去看官方文檔或源碼應該更容易。日常開發使用其實參考官方文檔就足夠了，無非就是功能權限和資料權限，看情況也許不會寫後續的應用或擴充篇了。

上一篇: Screwdriver 開源持續傳遞平台體驗之旅
下一篇: linux 升核心 bbr,Linux 更新核心開啟 TCP BBR 實作高效單邊加速