繁體中文（香港）

ciam
auth
authorization

CIAM 102: 授權 & 基於角色的訪問控制

組織和租戶對於分組身份來說很不錯，但它們導致了一個絕對的民主：每個人在這個系統中都可以做任何事情。當烏托邦仍然是一個謎時，我們來看看訪問的治理：授權 (AuthZ)。

Gao

Founder

2/5/2023

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

背景

在上一篇文章中，我們介紹了身份驗證 (AuthN) 和授權 (AuthZ) 的概念，以及一些令人頭疼的術語：身份、組織、租戶等。

我們為什麼需要授權？

Notion 是一個很好的例子。對於每個你擁有的頁面，你可以選擇將其設為私有，僅你可訪問，或者與朋友甚至公眾分享。

或者，對於一個在線書店，你希望每個人都能查看所有書籍，但客戶只能查看他們自己的訂單，賣家只能管理他們商店中的書籍。

AuthZ 和 AuthN 是複雜業務模型的基本組成部分。它們通常齊頭並進；AuthZ 驗證用戶的訪問，而 AuthN 驗證身份。兩者都是安全系統所必需的。

基本授權模型

這是最常見的 AuthZ 模型之一：如果 IDENTITY 對 RESOURCE 執行 ACTION，則 ACCEPT 或 DENY。

在 Notion 示例中，模型是 PERSON 對 PAGE 執行 VIEW。

如果該頁面是私有的：

當你對你的 PAGE 執行 VIEW 時，你會收到 ACCEPT。
其他人進行對你的 PAGE 執行 VIEW 時應收到 DENY。

基於共識，行業發展出了各種授權技術，例如基於角色的訪問控制 (RBAC)，基於屬性的訪問控制 (ABAC)。今天，我們將關注 NIST RBAC 模型第1級：平面RBAC。

基於角色的訪問控制

讓我們擴展書店示例。假設我們有很多顧客，只有一個賣家：

顧客可以查看和訂購書籍，並查看他們自己的訂單。
賣家可以查看、創建和刪除書籍，並管理客戶訂單。

定義資源

在 Logto 中，資源（即API資源）通常代表一組實體或項目，因為它要求使用有效的URL作為指示器。因此，我們定義了兩個資源：

圖書：https://api.bookstore.io/books
訂單：https://api.bookstore.io/orders

強制執行URL格式的一個優勢是它可以映射到你的API服務的真實地址，這可以改善與系統中其他組件集成時的可讀性和可識別性。

定義許可權

由於我們引入了資源的概念，在 Logto 中，我們也強調許可權必須屬於資源，相反，資源可以擁有許可權。

讓我們為資源添加一些許可權：

圖書：read, create, delete
訂單：read, read:self, create:self, delete

雖然對許可權的名稱沒有要求，但我們有如下約定：

雖然 <action> 是描述許可權所需的，但 :<target> 可以被忽略來描述一般目標，即資源中的所有實體或項目。例如：

資源 Books 中的許可權 read 意味著閱讀任意圖書的操作。
資源 Orders 中的許可權 create:self 意味著創建屬於當前用戶的訂單的操作。

定義角色

簡而言之，角色就是一組許可權。讓我們創建兩個角色 customer 和 seller，並為其分配如下許可權：

你可能注意到許可權-角色分配是多對多的關係。

將角色賦予用戶

就像角色-許可權分配一樣，用戶-角色分配也是多對多的關係。因此，你可以將多個角色分配給單個用戶，也可以將單個角色分配給多個用戶。

連接點

這是 Logto 中第1級RBAC模型的完整關係圖：

在 RBAC 模型中，許可權總是“肯定的”，這意味著授權判斷很簡單：如果用戶擁有許可權，則接受；否則，拒絕。

假設 Alice 擁有 seller 角色，Bob 和 Carol 擁有 customer 角色。我們將先用自然語言描述操作，然後將它們轉譯為標準授權格式：IDENTITY 對 RESOURCE 執行 ACTION，最終得出結論。

Alice 想要新增一本出售的書：
- 用戶 Alice 對資源 Books（https://api.bookstore.io/books）執行 create。
- 由於 Alice 根據他們的 seller 角色被分配了 Books 的 create 許可權，結果是 ✅ ACCEPT。
Alice 想查看所有訂單以查看銷售是否達到預期：
- 用戶 Alice 對資源 Orders（https://api.bookstore.io/orders）執行 read。
- 由於 Alice 根據他們的 seller 角色被分配了 Orders 的 read 許可權，結果是 ✅ ACCEPT。
Bob 想瀏覽書單以查看是否有他想購買的書。
- 用戶 Bob 對資源 Books（https://api.bookstore.io/books）執行 read。
- 由於 Bob 根據他們的 customer 角色被分配了 Books 的 read 許可權，結果是 ✅ ACCEPT。
Bob 想查看 Carol 的訂單。
- 由於這是別人的訂單，Orders 的 read:self 許可權在這裡不起作用。
- 用戶 Bob 對資源 Orders（https://api.bookstore.io/order）執行 read。
- 由於 Bob 沒有 Orders 的 read 許可權，結果是 ❌ DENY。

其他RBAC級別

NIST RBAC模型共有四個級別：

平面RBAC
分層RBAC
約束RBAC
對稱RBAC

如果你感興趣，請查看論文以獲取詳細信息。

Logto 現在擁有第 1 級的實施，將根據社區反饋逐步升級到更高級別。如果更高級別適合你的需求，請隨時告訴我們！

實踐中

除理論之外，我們仍有大量技術工作需要完成，以便使模型按預期運行：

客戶端和身份驗證服務器的開發
RBAC的數據庫設計
不同服務之間的驗證
安全性和開放標準合規性
角色、許可權、資源管理和分配

不要驚慌。我們已經考慮到這一點，並添加了開箱即用的支持來涵蓋以上所有內容。查看 🔐 RBAC 配方以了解如何在 Logto 中使用 RBAC。

結尾筆記

RBAC 是大多數情況下的一個強大的訪問管理模型，但它並不是萬能的。我們仍然有一些問題：

我需要高等級的RBAC嗎？
RBAC與其他授權模型相比如何？
如何在不同的組織之間定義授權模型？

背景#

我們為什麼需要授權？#

基本授權模型#

基於角色的訪問控制#

定義資源#

定義許可權#

定義角色#

將角色賦予用戶#

連接點#

其他RBAC級別#

實踐中#

結尾筆記#

背景#

我們為什麼需要授權？#

基本授權模型#

基於角色的訪問控制#

定義資源#

定義許可權#

定義角色#

將角色賦予用戶#

連接點#

其他RBAC級別#

實踐中#

結尾筆記#

背景

我們為什麼需要授權？

基本授權模型

基於角色的訪問控制

定義資源

定義許可權

定義角色

將角色賦予用戶

連接點

其他RBAC級別

實踐中

結尾筆記

背景

我們為什麼需要授權？

基本授權模型

基於角色的訪問控制

定義資源

定義許可權

定義角色

將角色賦予用戶

連接點

其他RBAC級別

實踐中

結尾筆記