建立一個更好的訪問控制系統

我正在建設一個訪問控制系統，作爲我正在開發的Web框架的一部分。我想讓它變得超級靈活，真棒。你能通過提供對我設計的意見和見解來幫助我嗎？這裏是我的工作至今（我的具體問題是在底部）：建立一個更好的訪問控制系統

用戶

用戶有一個用戶名（32個字符，無空格）和密碼
用戶具有一個或多個必須驗證
用戶可以登錄使用無論是他們的用戶名或任何他們的電子郵件地址
用戶可能被關聯到零個或多個賬戶

賬戶

帳戶代表一個或多個用戶
每個用戶可以擁有一個帳戶特定權限或角色（例如，帳戶所有者或「可以添加新用戶」）
所有賬戶綁定到一個帳戶類型

賬戶類型

種

帳戶類型具有零級或多個帳戶類型的角色
帳戶類型具有零個或多個帳戶類型特點

帳戶類型角色

例如，「所有者」，「管理員」，「超級用戶」，「訪客」等。
帳戶類型角色是帳戶類型權限的集合

帳戶類型權限

帳戶類型權限是在系統具體行動應用程序邏輯將驗證對
他們可能會引用一個父類，所以它們可以分層次進行分組
例如：
- 「用戶管理」
  - 「添加用戶」
  - 「刪除用戶」
這些權限可以爲一個帳戶類型的特徵

是特別

賬戶類型特點層

帳戶類型的功能可以在一個賬戶被激活給它更多的權限
例如，「標準賬戶」或「優利賬戶」
這些功能，如果一個帳戶被激活，就會給對系統帳戶擁有者更多的機會
當它們被激活或停用，對定期或按需計費他們跟蹤

任務離子

對用戶操作進行應用程序邏輯檢查的最佳方法是什麼？我正在考慮將所有用戶的權限存儲在會話的對象中（這需要註銷/登錄才能刷新權限，我不喜歡 - 實時權限管理的任何想法？）：

{ 
    "All Permissions": { 
    "User Management": { 
     "Add User", 
     "Delete User" 
    }, 
    "Premium Account": { 
     "Download Files", 
     "Upload Files" 
    }, 
    } 
}

然後我會聲明系統中特定操作所需的權限。可能是這樣的：

Permission::require('Add User');

如果聲明的權限不在用戶權限對象中，請求將失敗。這似乎對每個用戶的行動激烈，雖然。另外，如果另一個權限子集具有字符串「添加用戶」？

在此先感謝您的幫助！

來源

2010-08-13 Kirk Ouimet

我看到我喜歡的一種方式是一種「級聯」權限。您擁有一組核心權限 - 比如讀取，寫入，刪除 - 並且可以將其分配給組或用戶。

READ USER1 
READ USER2 
WRITE USER2 
READ USER3 
WRITE USER3 
DELETE USER3

或者，您可以指定「組」而不是用戶名。

READ SUBSCRIBER 
READ EDITOR 
READ ADMIN 
WRITE EDITOR 
WRITE ADMIN 
DELETE ADMIN 
USER1 SUBSCRIBER 
USER2 EDITOR 
USER3 ADMIN

然後，您可以簡單地使用表中的值來排序和查找記錄。這允許靈活地成爲具有互斥權限的多個組的成員等。

來源

2010-08-13 21:25:11 funwhilelost

查看您的賬戶類型權限，看起來您有一個訪問控制列表（ACL）樣式的系統設計。

如果你想讓它變得超級靈活和超棒，那麼我建議這是而不是一個很好的設計。ACL系統的簡單權限工作 - 也許在你的場景中確實可行 - 但是一旦授予權限的規則變得更加動態一點 - 也就是說，依賴超出用戶身份或角色的任何上下文數據，ACL的下降平坦快速。

This video對ACL的缺陷進行了一些細節，並討論了實現訪問控制的替代方法，該方法考慮了現實世界的情況。另外，這已經在之前完成了（儘管我們可以看到的實現方式出乎意料地少了一些）;但是，也許看看Rhino Security。原鏈接http://ayende.com/Blog/category/548.aspx已損壞，請保留互聯網存檔鏈接以供參考。

來源

2010-08-13 21:57:30

我沒有任何具體的建議，但我熟悉的系統有非常好的靈活訪問/許可系統是Drupal和Plone。你可能會做得比複製其中任何一個工作更糟糕。他們已經進行了多年的真實世界測試。

來源

2010-08-13 22:09:24

我想看看Java系統的權限：

http://download.oracle.com/javase/6/docs/api/java/security/Permission.html

它採用「涵義的邏輯」;也就是說，權限對象是決定是否允許給定操作（即權限是否「暗含」對資源的訪問）。我也會檢查出BasicPermission，因爲它有一個非常直接的命名空間規範的權限。在您的例子將是（繼CRUD命名）

user.create
user.delete
file.read
file.create

在我們的web應用程序，我們爲每個可請求的資源或過程分配權限，併爲每個用戶分配一組權限。然後我們做一個

boolean isAuthorized = user.permissions.implies（requestedResource.permission）; （隱含標準封裝）

確定用戶是否被允許訪問。

來源

2010-08-14 04:13:34 Nathan

Zed Shaw對ACL和他們的侷限性有一些有趣的說法。絕對值得一看，然後再沿着這條路走下去。

http://vimeo.com/2723800

來源

2010-08-14 23:27:30 mjackson

這是視頻我也鏈接到我的回答 – 2010-08-18 21:28:19

是的非常限制我需要更多的控制。 – 2016-05-27 15:09:43

您正在使用的語義是有點混亂。例如，「所有者」，「管理員」，「高級用戶」，「客人」的賬戶類型看起來更像「用戶類型」。

此外，也許你可以讓你所稱的「AccountPermissions」成爲Account的子類。這種方式取決於帳戶的類型，將應用不同的權限。

來源

2010-08-17 20:37:44

這是我的兩個意義，它的價值。

首先我會說，當你開始設計這個時，想想OOP以及它如何應用到系統中的實體。用戶，User_Role，角色，Role_Permissions，帳戶，Account_Types，Account_Type_Features等

USERS： - 應該被允許使用OpenID的，因爲它是獲得牽引力 - 該選項進行數據庫的ID或UUID之間進行選擇便攜

用戶角色：（不帳戶類型角色）我會鼓勵你在這裏非常具體。例如，您在哪裏繪製高級用戶和管理員之間的界限？ ADMIN和OWNER有什麼區別？只要這些明確定義（而不是模糊），那麼它將起作用。如果你的用戶羣中有任何問題，很快你會有一組複雜的角色和權限。我會盡量保持清潔。用戶將弄清楚如何處理他們給出的內容。另外，我會將其更改爲用戶類型角色。角色應該適用於用戶，而不是帳戶。

角色權限：（不是帳戶類型權限）這應該更改爲角色權限。權限擴展到用戶角色，而不是帳戶或用戶。根據我的經驗，設計越清晰，路上的混淆空間就越小。另外，避免像瘟疫一樣的ACL。讓它成爲一個簡單的一對一關係。對於任何基於Web的系統，我還沒有找到實施ACL 的理由。其他基於許可的系統更容易理解，維護和使用。沒有任何意義使事情複雜化。

賬戶類型功能： 注意不要模糊賬戶類型權限和賬戶類型功能。您的第一個項目符號使用單詞權限。將其更改爲功能。帳戶類型將激活更多高級/高級功能（不是權限）。

權限管理： 對於在Web上運行的無狀態應用程序，會話是要走的路。好處是沒有往返數據庫，不斷向檢查用戶是否被授權。

Permission::require()應該遵循與Sessions相同的參數定義。這將防止其他子集的權限重疊。所以這個電話會像Permission::require('User Management', 'Add User'); 這意味着它會尋找$_SESSION['All Permissions']['User Management']['Add User'] 這將防止歧義。

記得SIMPLE更好。

來源

2010-08-18 03:54:53