訪問控制：具有附加組成員身份而不是對象屬性的RBAC

Question

給定根據某些用戶權限顯示對象（例如電影）的應用程序。

一般顯示或創建對象的權限實現爲具有角色和權限的RBAC。

特定訪問具有某些屬性的對象（例如，具有「戲劇」屬性的電影）的權限應使用成員資格實施。這意味着對象沒有屬性「戲劇」，它是組「戲劇」的成員。如果用戶和對象是同一組中的成員，則用戶具有訪問此對象的特定權限。可以有不同的組顯示，創建或刪除對象，如簡單的查看器組或某種編輯組。此外還有一個表格，指定哪些組類型與特定對象上的某些操作相關。例如，對象「電影」上的「顯示」動作的相關組可以是「流派」和「年齡」（電影對某些觀衆的適合性）。

以所述方式實現它的原因是在不觸摸代碼的情況下具有很大的靈活性。可以在數據庫中處理對組的更改。

常規數據庫設計：

示例：電影 「亡魂」 是的基團的成員 「體裁：戲劇」 和 「年齡：18」。如果用戶也是這些組的成員，則用戶可以訪問它。

這聽起來像一個好方法嗎？有沒有類似於這種方法的現有解決方案？它是否有主要的缺點（例如太多的數據庫查詢 - 每天可能有幾百個用戶）？

請與我分享你對這個問題的看法 - 選擇「戲劇」作爲範例的類別並不是巧合;）我只是不知道這是死路一條，還是我正朝着正確的方向前進。我堅持了很長一段時間。

Answer 1

至少你有良好的幽默感:-)

你的方法聽起來不錯。只要您保持較低的參數數量，您就可以利用基於角色的訪問控制（RBAC）和一些附加參數（例如，組會員資格。

但是，從長遠來看，如果你想實現業務驅動授權（訪問控制），您需要一種方法來獨立做你的代碼這樣的：你不希望重寫你的應用程序代碼，每次有是需求變更。

爲此，有一種稱爲基於屬性的訪問控制（ABAC）的訪問控制模型，可以讓您獨立於代碼定義授權策略。

在ABAC，您有以下概念：

• 它定義了一個策略執行點（PEP）和策略決策點（PDP）的架構。 PEP位於您的應用程序的前面（或內部）。它攔截業務請求（例如查看電影的請求）並向PDP發送授權請求。PDP配置有策略。根據請求，PDP將做出決定：或者是，許可或否，Deny。
• 策略語言：策略語言是基於屬性的（因此名稱爲ABAC）。這意味着您可以使用任意數量的屬性（例如，用戶角色，用戶ID，用戶組成員身份，但也包括用戶年齡，用戶位置，用戶訂閱以及電影評級，電影類別，電影價格等資源屬性... ）
• 請求/響應方案：這是您如何請求授權。它本質上是一個是/否的流程。 「用戶可以做X嗎？」，「是的，他們可以。」

ABAC有幾種實現方式 - 其中一些是框架專用的，例如， CanCanCan。 XACML和ALFA是兩種與任何特定框架無關的方法。您可以從開源和兩種語言例如商業實現選擇：

• 開源：SunXACML，ATT XACML
• 商業：公理化策略服務器