ASP.NET Core 聲明是否旨在指定用戶可以做什么

Question

賞金將在 14 小時后到期。 這個問題的答案有資格獲得+50聲望獎勵。 弗拉多·潘季奇( Vlado Pandžić)正在尋找信譽良好的消息來源的答案。

ASP.NET Identity 創建了像 UserClaims、UserRoleClaims 這樣的表，這正是我所需要的。 我在應用程序中設置了用戶可以或不能訪問的功能，例如預訂頁面、圖像頁面。 目前，所有這些權限都附加到角色，而不是用戶，例如，如果我說所有具有 admin 角色的用戶都可以訪問保留頁面，所有具有 admin 角色的用戶都可以訪問它。

在 UserClaims 中，我將指定多行“訪問圖像”、“訪問預訂頁面”，在 UserRoleClaims 中，我將指定每個角色具有哪些“聲明”。

另一種方法是創建類似的表，如 Permissions 和 RolePermissions，它們在結構上與 ASP.NET Identity 創建的表非常相似。

將我的權限放在聲明中似乎有些奇怪，但好在一切都已准備就緒。 ASP.NET Identity UserClaims 應該處理這個權限問題還是它們只是“描述”用戶的簡單鍵值對？

Answer 1

聲明是一個主體（例如個人或組織）對其自身或另一個主體所做的陳述。 根據我的經驗，它不應該是特定的“CanReadReport”、“CanWriteToCustomerDatabase”。 相反，為了獲得更大的靈活性，我更喜歡在以下聲明時：

InManagement：是/否 InEconomny：是/否 銷售：是/否 員工：是/否 顧問：是/否 會計師：是/否

然后由應用程序通過策略來評估誰應該訪問什么。

這篇博文可能對您有所幫助： 身份與權限

Answer 2

解決這個問題的一種方法是將資源/動作對存儲在聲明中並實現一些基礎設施（特殊屬性等）以在控制器動作上聲明性地要求這些聲明。

在你的情況下，這些對可能看起來像

資源	行動
圖片	使用權
圖片	上傳
預訂頁面	使用權

Answer 3

在大多數情況下，實際上將索賠視為群體。 基本上，它是關於用戶是什么或可以做什么的聲明 - 如果您更習慣於這些術語，那么在邏輯上可以很容易地將其視為組成員資格。 然后，您可以（通過表格）從這些列表中編寫特定操作（即權限組具有）的列表，並在控制器中測試這些操作。

Answer 4

是的，所以索賠？！ 將聲明視為與 ASP.Net Identity 框架實現非常不同的東西，您可以選擇在默認項目中獲取，其中包括您詢問的表。

當然識別框架會生成表來處理這種情況，但最終它並不是它的全部內容，整個聲明或令牌事物，這是聲明變得有趣的時候 - 它只是它的一個實現，另一個可能是為了實例通常是一個 Json Web 令牌 (JWT)，用作帶有 REST API 的不記名令牌，無論您在這兩種情況下得到什么？

你會得到一堆加密和防篡改的數據，因為它已經從你自己的服務器上獲得了內容證明，並且你有一個 (key, valuebag) 類型的數據，如果你只是曾經提供過一個。

然后是 asp.net 支持策略，它基本上使您能夠說該策略要求所述數據塊包含以下內容，然后……然后可以將其用於方法和控制器。

也可以通過編程方式輕松訪問這些聲明，因此當請求從經過身份驗證的用戶傳入 api 時，任何 api 實例都假定您有許多負載平衡設置，並且請求已經攜帶諸如用戶 ID、某些控制器或 ui 含義_full_name 之類的東西值 ["view", "edit", "add", ... ] 例如

帶有聲明的不記名令牌確實是一種您可以避免對每個請求進行身份驗證和授權的方法，並且如果您願意，您都可以立即使令牌過期並讓它們持續多久，這對於網絡應用程序非常有用，如果您選擇JWT 版本，因為在所有 Web MVVM 框架（如 Angular、React、.. 等）中，在 ui 中訪問相同的訪問是非常直接的 令牌解密成 Json 在 javascript 中幾乎是原始的 JavaScriptObjectNotation 一等公民對象......非常容易使用與任何不是的東西相反。 現在任何編程語言都會反序列化 json，因此您可以快速填充模型。

所以索賠解決了幾個問題：

1. 對后端的請求進行身份驗證和授權
2. 向 ui 提供權限集（如果像這樣使用）和功能/部件的激活停用
3. 發布獲取登錄/令牌生成流程之外的任何內容的資格
4. 撤銷權限的簡單方法

那么你可以提出什么索賠？ 隨便！ 您可以將對象序列化為一個值，只要您使用 base 64 編碼或類似編碼，如果您願意，但大多數情況下您不應該這樣做。 為什么你想要支持 JavaScript 對象的對象部分，Json 中的 JSO，因為它是我們所擁有的是，每個聲明本質上都是一個成員屬性，它可以是單個值或數組，並且總是只有字符串才能確保層之間的最大合規性。 顯然，您可以將任何內容放入字符串中並在讀取和讀取時相應地對其進行處理，但為了提高效率，重要的收獲是它是一個扁平結構而不是嵌套層次結構（鍵，值）的列表，其中值有點特殊，具體取決於如果有 0、1 或 seral 值

我敢打賭它會在你身上成長，為了方便你可以從包含的數據庫中提供這樣的內容，如果你在 VS 的新項目指南中搭建一些東西並免費獲得很多處理，那么你為什么不應該，除了必須處理許多不是自己編寫的代碼之外 - 通常采用這種簡單的方法，然后這意味着您將為下一個可以以相同方式構建的作業做准備:)

Answer 5

聲明是用戶身份的一部分。 它描述了用戶是什么，而不是它可以做什么。

聲明提供比角色更多的粒度和靈活性。 考慮一個示例，其中只有 18 歲以上的人才能訪問您的應用程序中的某個功能。 您可能為此有一個角色，但這很笨拙，因為您需要確保用戶在成年后被添加到這個角色中。

使用基於聲明的授權，用戶將擁有聲明DateOfBirth ，當用戶嘗試訪問年齡限制內容時，您將根據該聲明執行安全檢查。

identity.AddClaim(new Claim("DateOfBirth", user.DateOfBirth));

進行聲明檢查的一個好方法是使用策略（也可以與角色一起使用）：

services.AddAuthorization(options =>
{
    options.AddPolicy("MustBe18", policy => 
    {
        policy.Requirements.Add(new MinimumAgeRequirement(18));
    });
    options.AddPolicy("MustBeAdmin", policy => policy.RequireRole("Admin");
});

您可以將這些策略應用於具有以下屬性的控制器：

[Authorize(Policy = "MustBe18")]
public class AdultController : Controller
{
    // Age restricted content
}

[Authorize(Policy = "MustBeAdmin")]
public class AdminController : Controller
{
    // Administration panel
}

ASP.NET Identity 為您提供了通過 UserClaims 表擴展您的用戶的方法。

值得注意的是，至少根據我讀過的一些關於該主題的 博客和SO 帖子，角色被認為是遺留功能，主要是為了向后兼容。 我還沒有找到這種說法的來源，而且在某些情況下，角色對我來說似乎仍然有用，因此請從中獲取您想要的內容。