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。資源名稱唯一
User Claims:需要包含在Access Token中的用戶聲明列表
API Resource Scope:API資源包含的作用域
API Properties:API本身的一些屬性,例如name, display name, description等
API Grants:被授權的API列表
User Claims:身份聲明,例如sub,name,amr,auth_time等
Identity Properties:身份資源本身的一些屬性,例如session_id,issued,expired等
Identity Grants:被授予的身份信息
API Scope:API作用域
可以當做是Permission來用,示例見:https://docs.duendesoftware.com/identityserver/v6/fundamentals/resources/api_scopes/
Identity Resource:關于用戶的身份信息(又名聲明),例如姓名或電子郵件地址
API Resource:一組API Scope
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,歡迎聯系我們