MASA Auth - SSO與Identity設計
AAAA
AAAA即認證、授權、審計、賬號（Authentication、Authorization、Audit、Account）。在安全領域我們繞不開的兩個問題：
-
授權過程可靠：讓第三方程式能夠訪問所需資源又不洩露使用者資料，常用的多方授權協議主要有 OAuth2 和 SAML 2.0
-
授權結果可控：授權結果用於功能或資源的訪問控制。常見的許可權控制模型：DAC、MAC、RBAC、ABAC
想了解許可權控制模型的話可以參照上一篇的許可權設計
OpenId（Authentication）
OpenID 是一個以使用者為中心的數字身份識別框架，它具有開放、分散性。OpenID 的建立基於這樣一個概念：我們可以通過 URI （又叫
對於支援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，歡迎聯絡我們