AAAA
AAAA即認證、授權、審計、賬號（Authentication、Authorization、Audit、Account），在安全領域我們繞不開的兩個問題：
-
授權程序可靠：讓第三方程式能夠訪問所需資源又不泄露用戶資料，常用的多方授權協議主要有 OAuth2 和 SAML 2.0
-
授權結果可控：授權結果用于功能或資源的訪問控制，常見的權限控制模型：DAC、MAC、RBAC、ABAC
想了解權限控制模型的話可以參照上一篇的權限設計
OpenId（Authentication）
OpenID 是一個以用戶為中心的數字身份識別框架，它具有開放、分散性，OpenID 的創建基于這樣一個概念：我們可以通過 URI （又叫 URL 或網站地址）來認證一個網站的唯一身份，同理，我們也可以通過這種方式來作為用戶的身份認證
對于支持OpenID的網站，用戶不需要記住像用戶名和密碼這樣的傳統驗證標記，取而代之的是，他們只需要預先在一個作為OpenID身份提供者（Identity Provider, IDP）的網站上注冊，
OAuth2（Authorization）
舉個例子：MASA.Contrib使用codecov來分析單元測驗覆寫率，OAuth2幫我解決了幾個安全問題：
- 密碼泄露：不需要把賬號密碼告訴
codecov - 訪問范圍：只開放讀取原始碼的能力
- 權限回收：在Github上撤回授權即可關閉
codecov的訪問能力
那OAuth2是如何解決的呢
我們來看一張圖
OIDC（Authentication & Authorization）
OpenID Connect 1.0是OAuth 2.0協議之上的一個簡單的身份層， 它允許客戶端基于授權服務器執行的身份驗證來驗證終端用戶的身份，并以一種可互操作的、類似rest的方式獲取關于終端用戶的基本概要資訊，
OIDC常用術語
-
EU：End User：終端用戶
-
RP：Relying Party，用來代指OAuth2中的受信任的客戶端，身份認證和授權資訊的消費方
-
OP：OpenID Provider，有能力提供EU認證的服務（比如OAuth2中的授權服務），用來為RP提供EU的身份認證資訊
-
ID Token：JWT格式的資料，包含EU身份認證的資訊
-
UserInfo Endpoint：用戶資訊介面（受OAuth2保護），當RP使用Access Token訪問時，回傳授權用戶的資訊，此介面必須使用HTTPS
OIDC作業流
- RP發送一個認證請求給OP
- OP對EU進行身份認證，然后提供授權
- OP把ID Token和Access Token（需要的話）回傳給RP
- RP使用Access Token發送一個請求UserInfo EndPoint
- UserInfo EndPoint回傳EU的Claims
JWT
JWT（JSON Web token）是一個開放的、行業標準的RFC 7519方法，用于在雙方之間安全地表示宣告，
JWT由3部分組成：標頭(Header)、有效載荷(Payload)和簽名(Signature)，在傳輸的時候，會將JWT的3部分分別進行Base64編碼后用.進行連接形成最終傳輸的字串
JWT=Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)
Header
JWT頭是一個描述JWT元資料的JSON物件，alg屬性表示簽名使用的演算法，默認為HMAC SHA256（寫為HS256）；typ屬性表示令牌的型別，JWT令牌統一寫為JWT，最后，使用Base64 URL演算法將上述JSON物件轉換為字串保存
{
"alg": "HS256",
"typ": "JWT"
}
Payload
有效載荷部分，是JWT的主體內容部分，也是一個JSON物件，包含需要傳遞的資料（允許自定義），
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
Signature
簽名哈希部分是對上面兩部分資料簽名，需要使用base64編碼后的header和payload資料，通過指定的演算法生成哈希，以確保資料不會被篡改
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
your-256-bit-secret
)
Identity Server 4常用術語
-
Client：一個從 IdentityServer 請求令牌的軟體——用于驗證用戶（請求身份令牌）或訪問資源（請求訪問令牌），客戶端必須先向 IdentityServer 注冊，然后才能請求令牌
- Allowed Scopes：即可以是Identity Resource，也可以是Api Scopes和Api Resources
-
Resource：您希望使用 IdentityServer 保護的東西，如用戶的身份資料或 API，資源名稱唯一
-
API Scope：API作用域
可以當做是Permission來用，示例見：https://docs.duendesoftware.com/identityserver/v6/fundamentals/resources/api_scopes/
-
Identity Resource：關于用戶的身份資訊（又名宣告），例如姓名或電子郵件地址
- User Claims：身份宣告，例如sub，name，amr，auth_time等
- Identity Properties：身份資源本身的一些屬性，例如session_id，issued，expired等
- Identity Grants：被授予的身份資訊
-
API Resource：一組API Scope
-
User Claims：需要包含在Access Token中的用戶宣告串列
-
API Resource Scope：API資源包含的作用域
-
API Properties：API本身的一些屬性，例如name, display name, description等
-
API Grants：被授權的API串列
-
-
-
Identity Token：身份令牌代表身份驗證程序的結果，它至少包含用戶的識別符號以及有關用戶如何以及何時進行身份驗證的資訊，它可以包含額外的身份資料
-
Access Token：訪問令牌允許訪問 API 資源，客戶端請求訪問令牌并將其轉發到 API，訪問令牌包含有關客戶端和用戶（如果存在）的資訊， API 使用該資訊來授權訪問其資料
-
Grant Types：授權型別（其實還有Resource owner password，不推薦使用，就不過多介紹了）
參考自：https://docs.duendesoftware.com/identityserver/v6/overview/terminology/
-
Machine/Robot：Client Credentials
-
Web Applications：Authorization Code With PKCE（Proof Key for Code Exchange）
通常我們會選擇
id_token token作為response type還有一個選擇，就是Implicit，但在隱式流程中，所有令牌都通過瀏覽器傳輸，因此不允許重繪令牌等高級功能，作用范圍就是僅用于用戶身份驗證（服務器端和 JavaScript 應用程式），或身份驗證和訪問令牌請求（JavaScript 應用程式）
-
SPA：Authorization Code With PKCE
-
Native/Mobile Apps：Authorization Code With PKCE
-
TV/Limited Input Device：Device Flow RFC 8628
-
ASP.Net Core Identity常用術語
-
User：用戶
- Action：操作，包括增刪改查
- User Role：用戶角色
- User Claim：用戶宣告
-
Role：角色
- Action：操作，包括增刪改查
- Role Claim：角色宣告
-
Claim： 宣告是一個名稱值對，表示使用者是什么，而不是使用者可以做什么， 基于宣告的授權檢查宣告的值并允許基于該值的資源訪問
-
Policy：策略
- Require Role：要求角色
- Require Claim：要求宣告
- Require Assertion：更復雜的可以通過要求斷言來解決，它支持兩個多載的Func（實際是一個，因為有一個是Task）
- Requirements：基于
IAuthorizationRequirement介面定義一個要求，判斷要求要基于AuthorizationHandler<T>來實作對應的邏輯- 默認策略
- 回退策略
- 自定義授權屬性
-
Resource：資源
- Imperative：官方翻譯是命令式，可以對特定的資源進行授權策略處理
依賴模型
集成RBAC
通過.Net Core Identity的User Claimns將User Role與Api Resource、Api Scope、Identity Resource相關聯，可以在不同業務維度下獲取到用戶的角色
再配合ASP.Net Core Identity的Role或Policy進行資源授權判斷來達到SSO與RBAC的業務落地
總結
本章節涉及到OIDC、ASP.Net Core Identity和RBAC三部分內容，首先OIDC的知識體系就比較龐大，需要根據比較完善的檔案把概念都搞清楚以及為什么這么設計的原因，其次還要進行一些微調把OIDC、RBAC與ASP.Net Core Identity三者結合，可以看出依賴模型其實是個很粗的把各個環節串了起來，但實際落地程序中還免不了對依賴模型進行二次調整來滿足不同業務的需求，后續等MASA Auth落地后會再出第三篇文章來回顧和還原實際落地程序，
（本文章不代表最終設計）
開源地址
MASA.BuildingBlocks：https://github.com/masastack/MASA.BuildingBlocks
MASA.Contrib：https://github.com/masastack/MASA.Contrib
MASA.Utils：https://github.com/masastack/MASA.Utils
MASA.EShop：https://github.com/masalabs/MASA.EShop
MASA.Blazor：https://github.com/BlazorComponent/MASA.Blazor
如果你對我們的 MASA Framework 感興趣，無論是代碼貢獻、使用、提 Issue，歡迎聯系我們
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/487007.html
標籤：C#