技術文章 » MASA Auth

MASA Auth

2022-06-06 15:00:17

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工作流

  1. RP傳送一個認證請求給OP
  2. OP對EU進行身份認證，然後提供授權
  3. OP把ID Token和Access Token（需要的話）返回給RP
  4. RP使用Access Token傳送一個請求UserInfo EndPoint
  5. 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)

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，歡迎聯絡我們