之前,我們已經了解了ASP.NET Core中的身份認證,現在,我們來聊一下授權。
老規矩,示例程序源碼XXTk.Auth.Samples已經提交了,需要的請自取。
概述
ASP.NET Core中的授權方式有很多,我們一起了解一下其中三種較為常見的方式:
- 基于角色的授權
- 基于聲明的授權
- 基于策略的授權
其中,基于策略的授權是我們要了解的重點。
在進入正文之前,我們要先認識一個很重要的特性——AuthorizeAttribute,通過它,我們可以很方便的針對Controller、Action等維度進行權限控制:
csharp
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true, Inherited = true)]
public class AuthorizeAttribute : Attribute, IAuthorizeData
{
public AuthorizeAttribute() { }
public AuthorizeAttribute(string policy)
{
Policy = policy;
}
// 策略
public string? Policy { get; set; }
// 角色,可以通過英文逗號將多個角色分隔開,從而形成一個列表
public string? Roles { get; set; }
// 身份認證方案,可以通過英文逗號將多個身份認證方案分隔開,從而形成一個列表
public string? AuthenticationSchemes { get; set; }
}
另外,為了方便測試,我們先添加一下基于Cookie的身份認證:
csharp
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
.AddCookie(options =>
{
options.Cookie.Name = "auth";
// 用戶未登錄時返回401
options.Events.OnRedirectToLogin = context =>
{
context.Response.StatusCode = StatusCodes.Status401Unauthorized;
return Task.CompletedTask;
};
// 用戶無權限訪問時返回403
options.Events.OnRedirectToAccessDenied = context =>
{
context.Response.StatusCode = StatusCodes.Status403Forbidden;
return Task.CompletedTask;
};
});
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
});
}
}
在Configure中,通過app.UseAuthorization()將授權中間件AuthorizationMiddleware添加到了請求管道。
基于角色的授權
實例程序請參考:XXTk.Auth.Samples.RoleBased.HttpApi
顧名思義,基于角色的授權就是檢查用戶是否擁有指定角色,如果是則授權通過,否則不通過。
我們先看一個簡單的例子:
csharp
[Authorize(Roles = "Admin")]
public string GetForAdmin()
{
return "Admin only";
}
這里,我們將AuthorizeAttribute特性的Roles屬性設置為了Admin,也就是說,如果用戶想要訪問GetForAdmin接口,則必須擁有角色Admin。
如果某個接口想要允許多個角色訪問,該怎么做呢?很簡單,通過英文逗號(,)分隔多個角色即可:
csharp
[Authorize(Roles = "Developer,Tester")]
public string GetForDeveloperOrTester()
{
return "Developer || Tester";
}
就像上面這樣,通過逗號將Developer和Tester分隔開來,當接到請求時,若用戶擁有角色Developer和Tester其一,就允許訪問該接口。
最后,如果某個接口要求用戶必須同時擁有多個角色時才允許訪問,那我們可以通過添加多個AuthorizeAttribute特性來達到目的:
csharp
[Authorize(Roles = "Developer")]
[Authorize(Roles = "Tester")]
public string GetForDeveloperAndTester()
{
return "Developer && Tester";
}
只有當用戶同時擁有角色Developer和Tester時,才允許訪問該接口。
你現在可能已經迫不及待要親自驗證一下了,不過你還記得如何設置用戶的角色嗎?我們在身份認證的文章中介紹過,在頒發身份票據時,可以通過聲明添加角色,例如:
csharp
public async Task<IActionResult> LoginForAdmin()
{
var identity = new ClaimsIdentity(CookieAuthenticationDefaults.AuthenticationScheme);
identity.AddClaims(new[]
{
new Claim(ClaimTypes.NameIdentifier, Guid.NewGuid().ToString("N")),
new Claim(ClaimTypes.Name, "AdminOnly"),
// 添加角色Admin
new Claim(ClaimTypes.Role, "Admin")
});
var principal = new ClaimsPrincipal(identity);
await HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, principal);
return Ok();
}
由于篇幅限制,其他的登錄代碼就不貼了,可以在示例程序中找到。
基于聲明的授權
實例程序請參考:XXTk.Auth.Samples.ClaimsBased.HttpApi
上面介紹的基于角色的授權,實際上就是基于聲明中的“角色”來實現的,而基于聲明的授權,則將范圍擴展到了所有聲明(而不僅僅是角色)。
基于聲明的授權,是在基于策略的授權基礎上實現的。為什么這么說呢?因為我們需要通過添加策略來使用聲明:
csharp
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddAuthorization(options =>
{
// ... 可以在此處添加策略
});
}
}
一個簡單的聲明策略如下:
csharp
options.AddPolicy("RankClaim", policy => policy.RequireClaim("Rank"));
該策略名稱為RankClaim,要求用戶具有聲明Rank,具體Rank對應的值是多少,不關心,只要有這個聲明就好了。
當然,我們也可以將Rank的值限定一下:
csharp
options.AddPolicy("RankClaimP3", policy => policy.RequireClaim("Rank", "P3"));
options.AddPolicy("RankClaimM3", policy => policy.RequireClaim("Rank", "M3"));
我們添加了兩條策略:RankClaimP3和RankClaimM3,除了要求用戶具有聲明Rank外,還分別要求Rank的值為P3和M3。
類似于基于角色的聲明,我們也可以添加“Or”、“And”邏輯的策略:
csharp
options.AddPolicy("RankClaimP3OrM3", policy => policy.RequireClaim("Rank", "P3", "M3"));
options.AddPolicy("RankClaimP3AndM3", policy => policy.RequireClaim("Rank", "P3").RequireClaim("Rank", "M3"));
策略RankClaimP3OrM3要求用戶具有聲明Rank,且值為P3或M3即可;而策略RankClaimP3AndM3要求用戶具有聲明Rank,且值必須同時包含P3和M3。
策略的用法與之前的類似(注意策略不能像角色一樣通過逗號分隔):
csharp
// 僅要求用戶具有聲明“Rank”,不關心值是多少
[Authorize(Policy = "RankClaim")]
public string GetForRankClaim()
{
return "Rank claim only";
}
// 要求用戶具有聲明“Rank”,且值為“M3”
[HttpGet("GetForRankClaimP3")]
[Authorize(Policy = "RankClaimP3")]
public string GetForRankClaimP3()
{
return "Rank claim P3";
}
// 要求用戶具有聲明“Rank”,且值為“P3” 或 “M3”
[Authorize(Policy = "RankClaimP3OrM3")]
public string GetForRankClaimP3OrM3()
{
return "Rank claim P3 || M3";
}
表示“And”邏輯的策略可以有兩種寫法:
csharp
// 要求用戶具有聲明“Rank”,且值為“P3” 和 “M3”
[Authorize(Policy = "RankClaimP3AndM3")]
public string GetForRankClaimP3AndM3V1()
{
return "Rank claim P3 && M3";
}
// 要求用戶具有聲明“Rank”,且值為“P3” 和 “M3”
[Authorize(Policy = "RankClaimP3")]
[Authorize(Policy = "RankClaimM3")]
public string GetForRankClaimP3AndM3V2()
{
return "Rank claim P3 && M3";
}
另外,有時候聲明策略略微有些復雜,可以使用RequireAssertion來實現:
csharp
options.AddPolicy("ComplexClaim", policy => policy.RequireAssertion(context =>
context.User.HasClaim(c => (c.Type == "Rank" || c.Type == "Name") && c.Issuer == "Issuer")));
基于策略的授權
實例程序請參考:XXTk.Auth.Samples.PolicyBased.HttpApi
通常來說,以上兩種授權方式僅適用于較為簡單的業務場景,而當業務場景比較復雜時,它倆就顯得無能為力了。因此,我們必須能夠設計更加自由的策略,也就是基于策略的授權。
基于策略的授權,我打算將其分成兩種類型來介紹:簡單策略和動態策略。
簡單策略
在上面,我們制定策略時,使用了大量的RequireXXX,我們也希望能夠將自定義策略封裝一下,當然,你可以寫一些擴展方法,不過我更加推薦使用IAuthorizationRequirement和IAuthorizationHandler。
現在,我們虛構一個場景:網吧管理,未滿18歲的人員不準入內,只允許年滿18歲的成年人進入。為此,我們需要一個限定最小年齡的要求:
csharp
public class MinimumAgeRequirement : IAuthorizationRequirement
{
public MinimumAgeRequirement(int minimumAge) =>
MinimumAge = minimumAge;
public int MinimumAge { get; }
}
現在,要求有了,我們還需要一個授權處理器,來校驗用戶是否真的達到了指定年齡:
csharp
public class MinimumAgeAuthorizationHandler : AuthorizationHandler<MinimumAgeRequirement>
{
protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, MinimumAgeRequirement requirement)
{
// 這里生日信息可以從其他地方獲取,如數據庫,不限于聲明
var dateOfBirthClaim = context.User.FindFirst(c => c.Type == ClaimTypes.DateOfBirth);
if (dateOfBirthClaim is null)
{
return Task.CompletedTask;
}
var today = DateTime.Today;
var dateOfBirth = Convert.ToDateTime(dateOfBirthClaim.Value);
int calculatedAge = today.Year - dateOfBirth.Year;
if (dateOfBirth > today.AddYears(-calculatedAge))
{
calculatedAge--;
}
// 若年齡達到最小年齡要求,則授權通過
if (calculatedAge >= requirement.MinimumAge)
{
context.Succeed(requirement);
}
return Task.CompletedTask;
}
}
當校驗通過時,調用context.Succeed來指示授權通過。當校驗不通過時,我們有兩種處理方式:
- 一種是直接返回Task.CompletedTask,這將允許后續的Handler繼續進行校驗,這些Handler中任意一個認證通過,都視為該用戶授權通過。
- 另一種是通過調用context.Fail來指示授權不通過,并且后續的Handler仍會執行(即使后續的Handler有授權通過的,也視為授權不通過)。如果你想在調用context.Fail后,立即返回而不再執行后續的Handler,可以將選項AuthorizationOptions的屬性InvokeHandlersAfterFailure設置為false來達到目的,默認為true。
現在,我們給虛構的場景增加一個授權邏輯:當用戶未滿18歲,但是其角色為網吧老板時,也允許其入內。
為了實現這個邏輯,我們再增加一個授權處理器:
csharp
public class MinimumAgeAnotherAuthorizationHandler : AuthorizationHandler<MinimumAgeRequirement>
{
protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, MinimumAgeRequirement requirement)
{
var isBoss = context.User.IsInRole("InternetBarBoss");
if (isBoss)
{
context.Succeed(requirement);
}
return Task.CompletedTask;
}
}
授權要求和授權處理器我們都已經實現了,接下來就是添加策略了,不過在這之前,不要忘了注入我們的要求和授權處理器:
csharp
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.TryAddEnumerable(ServiceDescriptor.Transient<IAuthorizationHandler, MinimumAgeAuthorizationHandler>());
services.TryAddEnumerable(ServiceDescriptor.Transient<IAuthorizationHandler, MinimumAgeAnotherAuthorizationHandler>());
services.AddAuthorization(options =>
{
options.AddPolicy("AtLeast18Age", policy => policy.Requirements.Add(new MinimumAgeRequirement(18)));
});
}
}
需要注意的是,我們可以將Handler注冊為任意的生命周期,不過,當Handler中依賴其他服務時,一定要注意生命周期提升的問題。
我們添加了一個名為AtLeast18Age的策略,該策略創建了一個MinimumAgeRequirement實例,要求最低年齡為18歲,并將其添加到了policy的Requirements屬性中。
你可以寫一個類似的接口進行測試:
csharp
[Authorize(Policy = "AtLeast18Age")]
public string GetForAtLeast18Age()
{
return "At least 18 age";
}
最后,多說一句,如果你想讓一個Handler可以同時處理多個Requirement,可以這樣做:
csharp
public class MultiRequirementsAuthorizationHandler : IAuthorizationHandler
{
public Task HandleAsync(AuthorizationHandlerContext context)
{
var pendingRequirements = context.PendingRequirements;
foreach (var requirement in pendingRequirements)
{
if (requirement is Custom1Requirement)
{
// ... 一些校驗
context.Succeed(requirement);
}
else if (requirement is Custom2Requirement)
{
// ... 一些校驗
context.Succeed(requirement);
}
}
return Task.CompletedTask;
}
}
public class Custom1Requirement : IAuthorizationRequirement
{
}
public class Custom2Requirement : IAuthorizationRequirement
{
}
動態策略
現在,問題又來了,如果我們的場景有多種年齡限制,比如有的要求18歲,有的要求20,還有的只要求10歲,我們總不能一個個的把這些策略都提前創建好吧,要搞死人...如果能夠動態地創建策略就好了!
下面我們嘗試動態地創建多種最小年齡策略:
首先,繼承AuthorizeAttribute來實現一個自定義授權特性MinimumAgeAuthorizeAttribute:
csharp
public class MinimumAgeAuthorizeAttribute : AuthorizeAttribute
{
// 策略名前綴
public const string PolicyPrefix = "MinimumAge";
// 通過構造函數傳入最小年齡
public MinimumAgeAuthorizeAttribute(int minimumAge) =>
MinimumAge = minimumAge;
public int MinimumAge
{
get
{
// 從策略名中解析出最小年齡
if (int.TryParse(Policy[PolicyPrefix.Length..], out var age))
{
return age;
}
return default;
}
set
{
// 生成動態的策略名,如 MinimumAge18 表示最小年齡為18的策略
Policy = $"{PolicyPrefix}{value}";
}
}
}
邏輯很簡單,就是將策略名前綴+傳入的最小年齡參數動態地拼接為一個策略名,并且還可以通過策略名反向解析出最小年齡。
好了,現在策略名可以動態創建了,那下一步就是根據策略名動態創建出策略實例了,可以通過替換接口IAuthorizationPolicyProvider的默認實現來達到目的:
csharp
public class AppAuthorizationPolicyProvider : IAuthorizationPolicyProvider
{
// 引用自第三方庫 Nito.AsyncEx
private static readonly AsyncLock _mutex = new();
private readonly AuthorizationOptions _authorizationOptions;
public AppAuthorizationPolicyProvider(IOptions<AuthorizationOptions> options)
{
BackupPolicyProvider = new DefaultAuthorizationPolicyProvider(options);
_authorizationOptions = options.Value;
}
// 若不需要自定義實現,則均使用默認的
private DefaultAuthorizationPolicyProvider BackupPolicyProvider { get; }
public async Task<AuthorizationPolicy> GetPolicyAsync(string policyName)
{
if(policyName is null) throw new ArgumentNullException(nameof(policyName));
// 若策略實例已存在,則直接返回
var policy = await BackupPolicyProvider.GetPolicyAsync(policyName);
if(policy is not null)
{
return policy;
}
using (await _mutex.LockAsync())
{
var policy = await BackupPolicyProvider.GetPolicyAsync(policyName);
if(policy is not null)
{
return policy;
}
if (policyName.StartsWith(MinimumAgeAuthorizeAttribute.PolicyPrefix, StringComparison.OrdinalIgnoreCase)
&& int.TryParse(policyName[MinimumAgeAuthorizeAttribute.PolicyPrefix.Length..], out var age))
{
// 動態創建策略
var builder = new AuthorizationPolicyBuilder();
// 添加 Requirement
builder.AddRequirements(new MinimumAgeRequirement(age));
policy = builder.Build();
// 將策略添加到選項
_authorizationOptions.AddPolicy(policyName, policy);
return policy;
}
}
return null;
}
public Task<AuthorizationPolicy> GetDefaultPolicyAsync()
{
return BackupPolicyProvider.GetDefaultPolicyAsync();
}
public Task<AuthorizationPolicy> GetFallbackPolicyAsync()
{
return BackupPolicyProvider.GetFallbackPolicyAsync();
}
}
最后,只需要注入一下服務就好啦:
csharp
services.AddTransient<IAuthorizationPolicyProvider, AppAuthorizationPolicyProvider>();
現在你就可以使用MinimumAgeAuthorizeAttribute進行授權了,比如限制最小年齡20歲:
csharp
[MinimumAgeAuthorize(20)]
public string GetForAtLeast20Age()
{
return "At least 20 age";
}
設計原理
現在,基礎用法我們已經了解了,接下來就一起學習一下它背后的原理吧。
鑒于涉及到的源碼較多,所以為了控制文章長度,下面只列舉核心代碼。
首先,我們再熟悉一下AuthorizeAttribute:
csharp
public interface IAuthorizeData
{
// 策略
string? Policy { get; set; }
// 角色,可以通過英文逗號將多個角色分隔開,從而形成一個列表
string? Roles { get; set; }
// 身份認證方案,可以通過英文逗號將多個身份認證方案分隔開,從而形成一個列表
string? AuthenticationSchemes { get; set; }
}
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true, Inherited = true)]
public class AuthorizeAttribute : Attribute, IAuthorizeData
{
public AuthorizeAttribute() { }
public AuthorizeAttribute(string policy)
{
Policy = policy;
}
public string? Policy { get; set; }
public string? Roles { get; set; }
public string? AuthenticationSchemes { get; set; }
}
Attribute自然不必多說,我們要注意的是AuthorizeAttribute實現的接口為IAuthorizeData。
接下來我們從services.AddAuthorization入手,看看針對授權都注冊了哪些服務:
你可能會疑問,即使我沒有顯式的添加services.AddAuthorization這行代碼,程序也不會報錯,其實這個我們在前文 Startup 中就提到過,services.AddControllers()中會默認調用AddAuthorization。
csharp
public static IServiceCollection AddAuthorization(this IServiceCollection services)
{
services.AddAuthorizationCore();
services.AddAuthorizationPolicyEvaluator();
return services;
}
public static IServiceCollection AddAuthorizationCore(this IServiceCollection services)
{
services.AddOptions();
services.TryAdd(ServiceDescriptor.Transient<IAuthorizationService, DefaultAuthorizationService>());
services.TryAdd(ServiceDescriptor.Transient<IAuthorizationPolicyProvider, DefaultAuthorizationPolicyProvider>());
services.TryAdd(ServiceDescriptor.Transient<IAuthorizationHandlerProvider, DefaultAuthorizationHandlerProvider>());
services.TryAdd(ServiceDescriptor.Transient<IAuthorizationEvaluator, DefaultAuthorizationEvaluator>());
services.TryAdd(ServiceDescriptor.Transient<IAuthorizationHandlerContextFactory, DefaultAuthorizationHandlerContextFactory>());
services.TryAddEnumerable(ServiceDescriptor.Transient<IAuthorizationHandler, PassThroughAuthorizationHandler>());
return services;
}
public static IServiceCollection AddAuthorizationPolicyEvaluator(this IServiceCollection services)
{
services.TryAddSingleton<AuthorizationPolicyMarkerService>();
services.TryAddTransient<IPolicyEvaluator, PolicyEvaluator>();
services.TryAddTransient<IAuthorizationMiddlewareResultHandler, AuthorizationMiddlewareResultHandler>();
return services;
}
我們整理下這里注冊了哪些接口:
- IAuthorizationService
- IAuthorizationPolicyProvider
- IAuthorizationHandlerProvider
- IAuthorizationEvaluator
- IAuthorizationHandlerContextFactory
- IAuthorizationHandler
- AuthorizationPolicyMarkerService
- IPolicyEvaluator
- IAuthorizationMiddlewareResultHandler
這里面有幾個接口是我們之前見過的,比如IAuthorizationPolicyProvider、IAuthorizationHandler。不著急研究其他幾個接口的作用,咱們接著看下AuthorizationOptions:
csharp
public class AuthorizationOptions
{
// 存放添加的策略,策略名不分區大小寫
private Dictionary<string, AuthorizationPolicy> PolicyMap { get; } = new Dictionary<string, AuthorizationPolicy>(StringComparer.OrdinalIgnoreCase);
// 授權失敗后,后續的 IAuthorizationHandler 是否還繼續執行
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)
{
PolicyMap[name] = policy;
}
public void AddPolicy(string name, Action<AuthorizationPolicyBuilder> configurePolicy)
{
var policyBuilder = new AuthorizationPolicyBuilder();
configurePolicy(policyBuilder);
PolicyMap[name] = policyBuilder.Build();
}
public AuthorizationPolicy? GetPolicy(string name)
{
if (PolicyMap.TryGetValue(name, out var value))
{
return value;
}
return null;
}
}
默認策略與回退策略不同:
- 默認策略,是指當接口標注了Authorize,但是未明確指定策略時,應使用的策略
- 回退策略,是指當某個接口未標注Authorize時,應使用的策略,且該值是可以為空的
接下來看中間件的注冊app.UseAuthorization():
csharp
public static class AuthorizationAppBuilderExtensions
{
public static IApplicationBuilder UseAuthorization(this IApplicationBuilder app)
{
VerifyServicesRegistered(app);
return app.UseMiddleware<AuthorizationMiddleware>();
}
private static void VerifyServicesRegistered(IApplicationBuilder app)
{
if (app.ApplicationServices.GetService(typeof(AuthorizationPolicyMarkerService)) == null)
{
throw new InvalidOperationException(...);
}
}
}
internal class AuthorizationPolicyMarkerService
{
}
從這里,我們得知了AuthorizationPolicyMarkerService的作用,就是為了確保在注冊授權中間件之前,我們已經調用過了UseAuthorization,注冊了全部所需要的服務。
接下來,深入AuthorizationMiddleware的實現:
csharp
public class AuthorizationMiddleware
{
private const string SuppressUseHttpContextAsAuthorizationResource = "Microsoft.AspNetCore.Authorization.SuppressUseHttpContextAsAuthorizationResource";
private readonly RequestDelegate _next;
private readonly IAuthorizationPolicyProvider _policyProvider;
public AuthorizationMiddleware(RequestDelegate next, IAuthorizationPolicyProvider policyProvider)
{
_next = next ?? throw new ArgumentNullException(nameof(next));
_policyProvider = policyProvider ?? throw new ArgumentNullException(nameof(policyProvider));
}
public async Task Invoke(HttpContext context)
{
var endpoint = context.GetEndpoint();
// ... 省略部分代碼
// AuthorizeAttribute 就實現了接口 IAuthorizeData,從這里也就可以得到我們的授權數據
var authorizeData = endpoint?.Metadata.GetOrderedMetadata<IAuthorizeData>() ?? Array.Empty<IAuthorizeData>();
// 1. 將所有授權要求組裝到一個策略實例中
var policy = await AuthorizationPolicy.CombineAsync(_policyProvider, authorizeData);
// 無授權策略,則無需進行授權校驗
if (policy == null)
{
await _next(context);
return;
}
// IPolicyEvaluator 的默認聲明周期是 Transient,而該中間件的生命周期是 Singleton,
// 所以該服務不建議注入到構造函數
var policyEvaluator = context.RequestServices.GetRequiredService<IPolicyEvaluator>();
// 2. 認證
var authenticateResult = await policyEvaluator.AuthenticateAsync(policy, context);
// 3. 如果標記了 AllowAnonymousAttribute 特性,則跳過授權校驗
if (endpoint?.Metadata.GetMetadata<IAllowAnonymous>() != null)
{
await _next(context);
return;
}
object? resource;
if (AppContext.TryGetSwitch(SuppressUseHttpContextAsAuthorizationResource, out var useEndpointAsResource) && useEndpointAsResource)
{
resource = endpoint;
}
else
{
resource = context;
}
// 4. 授權
var authorizeResult = await policyEvaluator.AuthorizeAsync(policy, authenticateResult, context, resource);
// 5. 針對授權結果,進行不同的響應處理
var authorizationMiddlewareResultHandler = context.RequestServices.GetRequiredService<IAuthorizationMiddlewareResultHandler>();
await authorizationMiddlewareResultHandler.HandleAsync(_next, context, policy, authorizeResult);
}
}
從這里可以看出,授權的所有方式,都是基于策略來實現的。
下面我們一步步來分析它。先看第1步,了解它是如何將多種授權要求組裝為一個策略的:
csharp
public class AuthorizationPolicy
{
public static async Task<AuthorizationPolicy?> CombineAsync(IAuthorizationPolicyProvider policyProvider, IEnumerable<IAuthorizeData> authorizeData)
{
// ... 省略部分代碼
AuthorizationPolicyBuilder? policyBuilder = null;
foreach (var authorizeDatum in authorizeData)
{
if (policyBuilder == null)
{
policyBuilder = new AuthorizationPolicyBuilder();
}
// 先處理策略
var useDefaultPolicy = true;
if (!string.IsNullOrWhiteSpace(authorizeDatum.Policy))
{
// 通過指定的策略名獲取策略實例
var policy = await policyProvider.GetPolicyAsync(authorizeDatum.Policy);
if (policy == null)
{
throw new InvalidOperationException(...);
}
policyBuilder.Combine(policy);
useDefaultPolicy = false;
}
// 再處理角色
var rolesSplit = authorizeDatum.Roles?.Split(',');
if (rolesSplit?.Length > 0)
{
var trimmedRolesSplit = rolesSplit.Where(r => !string.IsNullOrWhiteSpace(r)).Select(r => r.Trim());
// 將角色要求添加到策略
policyBuilder.RequireRole(trimmedRolesSplit);
useDefaultPolicy = false;
}
// 最后處理認證方案
var authTypesSplit = authorizeDatum.AuthenticationSchemes?.Split(',');
if (authTypesSplit?.Length > 0)
{
foreach (var authType in authTypesSplit)
{
if (!string.IsNullOrWhiteSpace(authType))
{
// 將認證方案要求添加到策略
policyBuilder.AuthenticationSchemes.Add(authType.Trim());
}
}
}
if (useDefaultPolicy)
{
// 添加默認策略
policyBuilder.Combine(await policyProvider.GetDefaultPolicyAsync());
}
}
// 如果此時還沒有策略,則查看是否存在回退策略,如果有,則返回
if (policyBuilder == null)
{
var fallbackPolicy = await policyProvider.GetFallbackPolicyAsync();
if (fallbackPolicy != null)
{
return fallbackPolicy;
}
}
// 返回當前組裝的策略實例
return policyBuilder?.Build();
}
}
整體邏輯已經通過注釋給出了,就不多做解釋了。我們來看一下IAuthorizationPolicyProvider,在之前我們就已經認識它了,這里也用到了:
csharp
public interface IAuthorizationPolicyProvider
{
Task<AuthorizationPolicy?> GetPolicyAsync(string policyName);
Task<AuthorizationPolicy> GetDefaultPolicyAsync();
Task<AuthorizationPolicy?> GetFallbackPolicyAsync();
}
從名字我們可以看出,該接口用于提供授權策略實例。
該接口有三個方法:
- GetPolicyAsync:根據策略名獲取策略實例
- GetDefaultPolicyAsync:獲取默認策略,當我們指明了要進行授權校驗,但沒有設定任何授權要求(如策略名、角色、身份認證方案等)時,會使用默認策略。
- GetFallbackPolicyAsync:獲取回退策略,當我們沒有指定任何授權校驗時,會使用回退策略。如果回退策略為null,則跳過授權校驗。
下面就看下該接口的默認實現DefaultAuthorizationPolicyProvider:
csharp
public class DefaultAuthorizationPolicyProvider : IAuthorizationPolicyProvider
{
private readonly AuthorizationOptions _options;
private Task<AuthorizationPolicy>? _cachedDefaultPolicy;
private Task<AuthorizationPolicy?>? _cachedFallbackPolicy;
public DefaultAuthorizationPolicyProvider(IOptions<AuthorizationOptions> options)
{
_options = options.Value;
}
public virtual Task<AuthorizationPolicy?> GetPolicyAsync(string policyName)
{
// 從 AuthorizationOptions 中查找已添加的策略實例
return Task.FromResult(_options.GetPolicy(policyName));
}
public Task<AuthorizationPolicy> GetDefaultPolicyAsync()
{
// 取 AuthorizationOptions 中配置的 DefaultPolicy
if (_cachedDefaultPolicy == null || _cachedDefaultPolicy.Result != _options.DefaultPolicy)
{
_cachedDefaultPolicy = Task.FromResult(_options.DefaultPolicy);
}
return _cachedDefaultPolicy;
}
public Task<AuthorizationPolicy?> GetFallbackPolicyAsync()
{
// 取 AuthorizationOptions 中配置的 FallbackPolicy
if (_cachedFallbackPolicy == null || _cachedFallbackPolicy.Result != _options.FallbackPolicy)
{
_cachedFallbackPolicy = Task.FromResult(_options.FallbackPolicy);
}
return _cachedFallbackPolicy;
}
}
OK,IAuthorizationPolicyProvider我們就看到這。
下面,我們回到AuthorizationMiddleware,繼續往下來到第2步,出現了新接口IPolicyEvaluator:
csharp
public interface IPolicyEvaluator
{
Task<AuthenticateResult> AuthenticateAsync(AuthorizationPolicy policy, HttpContext context);
Task<PolicyAuthorizationResult> AuthorizeAsync(AuthorizationPolicy policy, AuthenticateResult authenticationResult, HttpContext context, object? resource);
}
該接口用于評估身份認證和授權結果,分別產出AuthenticateResult和PolicyAuthorizationResult。
該接口有兩個方法:
- AuthenticateAsync:根據策略中提供的方案進行身份認證,生成認證結果
- AuthorizeAsync:根據策略和認證結果進行授權,生成授權結果
該接口的默認實現類為PolicyEvaluator:
csharp
public class PolicyEvaluator : IPolicyEvaluator
{
private readonly IAuthorizationService _authorization;
public PolicyEvaluator(IAuthorizationService authorization)
{
_authorization = authorization;
}
public virtual async Task<AuthenticateResult> AuthenticateAsync(AuthorizationPolicy policy, HttpContext context)
{
// 策略中指定了身份認證方案
if (policy.AuthenticationSchemes != null && policy.AuthenticationSchemes.Count > 0)
{
// 將多個身份認證方案的結果進行合并
ClaimsPrincipal? newPrincipal = null;
foreach (var scheme in policy.AuthenticationSchemes)
{
var result = await context.AuthenticateAsync(scheme);
if (result != null && result.Succeeded)
{
newPrincipal = SecurityHelper.MergeUserPrincipal(newPrincipal, result.Principal);
}
}
if (newPrincipal != null)
{
context.User = newPrincipal;
return AuthenticateResult.Success(new AuthenticationTicket(newPrincipal, string.Join(";", policy.AuthenticationSchemes)));
}
else
{
context.User = new ClaimsPrincipal(new ClaimsIdentity());
return AuthenticateResult.NoResult();
}
}
// 是否通過了默認的身份認證方案
return (context.User?.Identity?.IsAuthenticated ?? false)
? AuthenticateResult.Success(new AuthenticationTicket(context.User, "context.User"))
: AuthenticateResult.NoResult();
}
public virtual async Task<PolicyAuthorizationResult> AuthorizeAsync(AuthorizationPolicy policy, AuthenticateResult authenticationResult, HttpContext context, object? resource)
{
var result = await _authorization.AuthorizeAsync(context.User, resource, policy);
if (result.Succeeded)
{
return PolicyAuthorizationResult.Success();
}
// 授權失敗時:
// 若身份認證通過,則返回Forbid
// 若身份認證未通過,則發出質詢
return (authenticationResult.Succeeded)
? PolicyAuthorizationResult.Forbid(result.Failure)
: PolicyAuthorizationResult.Challenge();
}
}
從這里,我們可以看出,如果默認的身份認證方案無法提供完整的身份認證,可以在IAuthorizeData中指定AuthenticationSchemes,通過它來重新進行身份認證。
這里面使用到了新的接口IAuthorizationService,從名字也可以看出它是專門用來做授權的服務接口,真正的授權邏輯代碼被封裝到了該接口的實現類中,我們看下它的定義:
csharp
public interface IAuthorizationService
{
Task<AuthorizationResult> AuthorizeAsync(ClaimsPrincipal user, object? resource, IEnumerable<IAuthorizationRequirement> requirements);
Task<AuthorizationResult> AuthorizeAsync(ClaimsPrincipal user, object? resource, string policyName);
}
該接口具有一個方法AuthorizeAsync的兩種重載:
- 檢查用戶是否滿足指定資源(resource)的特定要求(requirements)
- 檢查用戶是否滿足特定的授權策略
如果你足夠細心,你會發現這兩個重載并不能滿足上方代碼的調用,因為調用時第三個參數我們傳遞的是AuthorizationPolicy類型,其實啊,它是被放到了擴展方法中。
reasonml
public static class AuthorizationServiceExtensions
{
public static Task<AuthorizationResult> AuthorizeAsync(this IAuthorizationService service, ClaimsPrincipal user, object? resource, AuthorizationPolicy policy)
{
return service.AuthorizeAsync(user, resource, policy.Requirements);
}
}
所以,從這里我們就知道了,它調用的實際上是第一個重載。
該接口的默認實現為DefaultAuthorizationService:
csharp
public class DefaultAuthorizationService : IAuthorizationService
{
// 以下字段均為構造函數注入
private readonly AuthorizationOptions _options;
private readonly IAuthorizationHandlerContextFactory _contextFactory;
private readonly IAuthorizationHandlerProvider _handlers;
private readonly IAuthorizationEvaluator _evaluator;
private readonly IAuthorizationPolicyProvider _policyProvider;
public virtual async Task<AuthorizationResult> AuthorizeAsync(ClaimsPrincipal user, object? resource, IEnumerable<IAuthorizationRequirement> requirements)
{
var authContext = _contextFactory.CreateContext(requirements, user, resource);
var handlers = await _handlers.GetHandlersAsync(authContext);
foreach (var handler in handlers)
{
await handler.HandleAsync(authContext);
// 若配置為授權失敗后不在調用后續Handlers
if (!_options.InvokeHandlersAfterFailure && authContext.HasFailed)
{
break;
}
}
var result = _evaluator.Evaluate(authContext);
// 省略一些代碼...
return result;
}
public virtual async Task<AuthorizationResult> AuthorizeAsync(ClaimsPrincipal user, object? resource, string policyName)
{
var policy = await _policyProvider.GetPolicyAsync(policyName);
if (policy == null)
{
throw new InvalidOperationException($"No policy found: {policyName}.");
}
return await this.AuthorizeAsync(user, resource, policy);
}
}
首先,這里用到了IAuthorizationHandlerContextFactory,它用來創建授權處理器上下文:
csharp
public interface IAuthorizationHandlerContextFactory
{
AuthorizationHandlerContext CreateContext(IEnumerable<IAuthorizationRequirement> requirements, ClaimsPrincipal user, object? resource);
}
public class DefaultAuthorizationHandlerContextFactory : IAuthorizationHandlerContextFactory
{
public virtual AuthorizationHandlerContext CreateContext(IEnumerable<IAuthorizationRequirement> requirements, ClaimsPrincipal user, object? resource)
{
return new AuthorizationHandlerContext(requirements, user, resource);
}
}
然后,下面用到了IAuthorizationHandlerProvider,它用來提供Handler,這些Handler包括我們之前實現的MinimumAgeAuthorizationHandler等。
csharp
public interface IAuthorizationHandlerProvider
{
Task<IEnumerable<IAuthorizationHandler>> GetHandlersAsync(AuthorizationHandlerContext context);
}
public class DefaultAuthorizationHandlerProvider : IAuthorizationHandlerProvider
{
private readonly IEnumerable<IAuthorizationHandler> _handlers;
public DefaultAuthorizationHandlerProvider(IEnumerable<IAuthorizationHandler> handlers)
{
_handlers = handlers;
}
public Task<IEnumerable<IAuthorizationHandler>> GetHandlersAsync(AuthorizationHandlerContext context)
=> Task.FromResult(_handlers);
}
另外,這里還用到了IAuthorizationEvaluator,該接口用于評估授權結果是成功還是失敗,并將結果構造為AuthorizationResult實例。
csharp
public interface IAuthorizationEvaluator
{
AuthorizationResult Evaluate(AuthorizationHandlerContext context);
}
public class DefaultAuthorizationEvaluator : IAuthorizationEvaluator
{
public AuthorizationResult Evaluate(AuthorizationHandlerContext context)
=> context.HasSucceeded
? AuthorizationResult.Success()
: AuthorizationResult.Failed(context.HasFailed
? AuthorizationFailure.ExplicitFail()
: AuthorizationFailure.Failed(context.PendingRequirements));
}
最后,獲取到授權結果AuthorizationResult后,我們就來到了第5步,由IAuthorizationMiddlewareResultHandler針對不同的授權結果進行響應處理。
csharp
public interface IAuthorizationMiddlewareResultHandler
{
Task HandleAsync(RequestDelegate next, HttpContext context, AuthorizationPolicy policy, PolicyAuthorizationResult authorizeResult);
}
public class AuthorizationMiddlewareResultHandler : IAuthorizationMiddlewareResultHandler
{
public async Task HandleAsync(RequestDelegate next, HttpContext context, AuthorizationPolicy policy, PolicyAuthorizationResult authorizeResult)
{
// 需要發出質詢
if (authorizeResult.Challenged)
{
if (policy.AuthenticationSchemes.Count > 0)
{
foreach (var scheme in policy.AuthenticationSchemes)
{
await context.ChallengeAsync(scheme);
}
}
else
{
await context.ChallengeAsync();
}
return;
}
// 需要響應403
else if (authorizeResult.Forbidden)
{
if (policy.AuthenticationSchemes.Count > 0)
{
foreach (var scheme in policy.AuthenticationSchemes)
{
await context.ForbidAsync(scheme);
}
}
else
{
await context.ForbidAsync();
}
return;
}
// 授權通過,繼續執行管道
await next(context);
}
}
至此,容器中注冊的幾個服務均涉及到了,我們再來總結一下:
- AuthorizationPolicyMarkerService:用于標志已經調用過了UseAuthorization,注冊了授權所需要的全部服務。
- IAuthorizationService:默認實現為DefaultAuthorizationService,用于對用戶進行授權(Authorize)。
- IAuthorizationHandlerContextFactory:默認實現為DefaultAuthorizationHandlerContextFactory,用于創建授權處理器上下文。
- IAuthorizationHandlerProvider:默認實現為DefaultAuthorizationHandlerProvider,用于提供用戶授權的處理器(IAuthorizationHandler)
- IAuthorizationHandler:默認實現為PassThroughAuthorizationHandler(處理自身既是Requirement,又是Handler的類),用于提供Requirement的處理邏輯。
- IAuthorizationPolicyProvider:默認實現為DefaultAuthorizationPolicyProvider,用于提供授權策略實例(AuthorizationPolicy)。
- IAuthorizationEvaluator:默認實現為DefaultAuthorizationEvaluator,用于評估授權結果是成功還是失敗,并將結果構造為AuthorizationResult實例。
- IPolicyEvaluator:默認實現為PolicyEvaluator,用于評估身份認證和授權結果
- IAuthorizationMiddlewareResultHandler:默認實現為AuthorizationMiddlewareResultHandler,用于針對授權結果,進行不同的響應處理。
這下,當你要實現自定義操作時,只需要重寫對應接口的實現就好啦。
為了方便大家理解,我將各個接口的調用關系畫了一張圖:
最后,大家肯定知道還有一個可以控制權限的地方,就是IAuthorizationFilter過濾器。不過,如果沒有必要,我并不推薦你使用它。因為它是mvc時代的舊產物,而且你要自己來實現一套完整的授權框架。
原文地址:
https://www.cnblogs.com/xiaoxiaotank/p/16157344.html