繁體中文(台灣)
  • ciam
  • auth
  • authorization

CIAM 102: 授權與基於角色的存取控制

組織和租戶對於群組身份來說是很棒的,但它們導致了一種絕對民主狀態:每個人在這個系統中都可以做任何事。雖然烏托邦仍然是個謎,我們來看看存取治理:授權(AuthZ)。

Gao
Gao
Founder

背景

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

組織和租戶對於群組身份來說是很棒的,但它們導致了一種絕對民主狀態:每個人在這個系統中都可以做任何事。雖然烏托邦仍然是個謎,我們來看看存取治理:授權(AuthZ)。

為什麼我們需要授權?

Notion 是一個很好的例子。對於你擁有的每個頁面,你可以選擇只讓自己看到、與朋友共享,甚至公開共享。

或者,對於一家線上書店,你希望每個人都可以看到所有書籍,但客戶只能看到自己的訂單,而賣家只能管理自己店鋪中的書籍。

AuthZ 和 AuthN 是複雜商業模式的基本組成部分。它們經常一起運作;AuthZ 驗證用戶的存取,而 AuthN 認證身份。兩者對於系統安全都很必要。

基本授權模型

這是最常見的 AuthZ 模型之一:如果 IDENTITYRESOURCE 上執行 ACTION,則 ACCEPTDENY

在 Notion 的例子中,模型為 PERSONPAGE 上執行 VIEW

如果頁面是私密的:

  • 當你在你的 PAGE 上執行 VIEW 時,你會收到 ACCEPT
  • 其他人在你的 PAGE 上執行 VIEW 時應該收到 DENY

基於共識,業界開發了各種授權技術,如基於角色的存取控制(RBAC)、基於屬性的存取控制(ABAC)。今天,我們會專注於 NIST RBAC 模型 的第一級:扁平 RBAC。

基於角色的存取控制

讓我們擴展書店的例子。假設我們有很多顧客,但只有一個賣家:

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

定義資源

在 Logto 中,資源(即 API 資源)通常表示一組實體或項目,因為需要使用有效的 URL 作為指標。因此我們定義了兩個資源:

  • 書籍:https://api.bookstore.io/books
  • 訂單:https://api.bookstore.io/orders

強制使用 URL 格式的一個優點是,它可以映射到你的 API 服務的實際地址,這在與系統中其他組件集成時提高了可讀性和辨識性。

定義權限

由於我們引入了資源的概念,在 Logto 中,我們還強制權限必須屬於資源,相反地,資源可以有權限。

讓我們為資源添加一些權限:

  • 書籍:readcreatedelete
  • 訂單:readread:selfcreate:selfdelete

雖然權限名稱沒有要求,但我們有以下慣例:

<action> 是必需用來描述權限時,:<target> 可以忽略以描述一般目標,即資源中的所有實體或項目。例如:

  • 權限 read 在資源書籍中意味著可以閱讀任意書籍的動作。
  • 權限 create:self 在資源訂單中意味著可以創建屬於當前用戶的訂單的動作。

定義角色

簡而言之,角色是一組權限。讓我們創建兩個角色 customerseller 並為它們分配權限如下:

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

將角色分配給用戶

就像角色-權限分配一樣,用戶-角色分配也是多對多關係。因此,你可以為一個用戶分配多個角色,一個角色也可以分配給多個用戶。

連接點

這是 Logto 中第一級 RBAC 模型的完整關係圖:

在 RBAC 模型中,權限總是 "正向" 的,意味著授權判斷很簡單:如果用戶擁有權限,則接受;否則拒絕。

我們假設 Alice 有角色 seller,Bob 和 Carol 有角色 customer。我們將首先用自然語言描述動作,並將它們翻譯成標準授權格式:IDENTITYRESOURCE 上執行 ACTION,最終得出結論。

  • Alice 想要添加一個新書進行銷售:
    • 用戶 Alice 在資源書籍(https://api.bookstore.io/books)上執行 create
    • 由於 Alice 根據她的角色 seller 被分配了書籍的 create 權限,結果是 ✅ 接受
  • Alice 想要查看所有訂單以確定銷售是否符合預期:
    • 用戶 Alice 在資源訂單(https://api.bookstore.io/orders)上執行 read
    • 由於 Alice 根據她的角色 seller 被分配了訂單的 read 權限,結果是 ✅ 接受
  • Bob 想要瀏覽書籍列表以查看是否有他想購買的書籍。
    • 用戶 Bob 在資源書籍(https://api.bookstore.io/books)上執行 read
    • 由於 Bob 根據他的角色 customer 被分配了書籍的 read 權限,結果是 ✅ 接受
  • Bob 想查看 Carol 的訂單。
    • 由於這是別人的訂單,訂單的 read:self 權限在這裡不起作用。
    • 用戶 Bob 在資源訂單(https://api.bookstore.io/order)上執行 read
    • 由於 Bob 沒有訂單的 read 權限,結果是 ❌ 拒絕

其他 RBAC 級別

NIST RBAC 模型有四個級別:

  • 扁平 RBAC
  • 層次化 RBAC
  • 受限 RBAC
  • 對稱 RBAC

如果你感興趣,請參閱 論文 以了解更多詳情。

Logto 現在已有第一級實現,將根據社群反饋來進展到更高級別。如果更高級別符合你的需求,請隨時告訴我們!

實踐中

除了理論,我們仍然需要大量技術工作以確保模型按預期運作:

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

不要驚慌。我們已考慮到這一點,並增加了開箱即用的支持來涵蓋以上所有事項。 查看 🔐 RBAC 食譜 以了解如何在 Logto 中使用 RBAC。

結語

對於大多數案例來說,RBAC 是一種強大的存取管理模型,但並不是萬能解決方案。我們仍然有一些問題:

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