ACL /角色管理：管理具有多個角色和衝突的允許的用戶

邏輯卡住點。我正在構建一個簡單的ACL，我只是感到困惑。我只是想以正確的方式做到這一點。ACL /角色管理：管理具有多個角色和衝突的允許的用戶

舉一個簡單的基於模型的ACL的例子。

管理用戶tbl_user

id | userid | 
------------- 
1 | nabin | 
2 | suman |

另一個表的管理組tbl_group

id | groupname | 
----------------- 
1 | admin  | 
2 | member | 
3 | editor | 
4 | moderator |

另一臺用於維護組和用戶的表。 tbl_roles

id | userid | groupid 
----------------------- 
1 | 1  | 1 
2 | 1  | 2 
3 | 2  | 2 
4 | 2  | 3 
5 | 2  | 4

現在管理tbl_acl

id | groupid | appresourceid 
---------------------------- 
1 | 3  | 1

訪問在該表的表，我將存儲拒絕列表中，引起拒絕列表中肯定會比訪問列表短。

現在，根據示例groupid:3 (editor)已拒絕資源1（假設這是管理區域）。

但是，如果你拿userid: 2(suman)，那麼他是editor和moderator。根據tbl_acl的規則，editor應該被拒絕，其中moderator應該被允許。

他應該被允許訪問資源還是應該被拒絕？允許 FIRST或拒絕第一。哪個應該優先考慮？

尋找到這個

雖然拒絕用戶的編輯從某種角度來說，他作爲主持人被允許訪問該地區。
儘管主持人被允許訪問資源，但所有編輯者都受到限制。
不要忘記用戶也是member。所以如果我們優先考慮允許拒絕。會員將可以作爲主持人訪問。除非，成員也被屏蔽

_{P.S. 我很清楚這個話題是有爭議的。所以，事實將不勝感激（不說）超過意見和猜測。}

來源

2012-01-02 Starx

您遇到了這個困境，因爲您採用了默認允許訪問資源的非標準方法。更爲標準的方法是默認阻止訪問，通過一個或多個「允許」ACL條目授予訪問權限，甚至可以通過單個「拒絕」條目覆蓋任何「允許」條目。在這種方法下，任何給定的「拒絕」條目勝過所有「允許」條目。（即：應用程序應該首先查找否認，如果發現任何，它甚至不需要檢查允許）。

如果您需要說服「默認防止」是比「在默認情況下允許」，這裏有幾個主要區別：

它通常是一個更適合的權限大多數權限管理員舉行管理的心智模式，無論是 IT人員或業務角色的應用管理員。（當然，這是至少部分是由於這樣的事實，大多數其他系統，他們將有管理使用這種模式，但這並不能使它不太相關。）
人爲錯誤是不太可能導致不適當授予權限。（即：如果管理員忘記添加一個「允許」下防止按默認項，沒有用戶最終能夠訪問資源，他不應該已經能夠觸及。）
當新的權限被添加到系統中，沒有人沒有特殊的管理員權限可以訪問目標資源，直到明確的「允許」條目被添加。

＃3特別引人注目。想象一下，您可以使用新的「查看工資」權限部署新版HR應用程序。你會發現允許所有用戶被授予此權限是可以接受的，直到有人開始爲ACL添加「拒絕」項嗎？

來源

2012-01-03 15:56:41

我只關注創建一個默認的允許，是，將有更少的表上的條目。但你提出了一個很好的觀點......我需要更多的迴應來明確這個話題。（+1） – Starx 2012-01-04 03:15:33

好吧，我要防止默認情況下，但應'允許'覆蓋'拒絕'？你有什麼話要說？ – Starx 2012-01-04 10:57:52

如果您在默認情況下阻止，權限的默認狀態是「軟」拒絕。這通過明確的「允許」授予來覆蓋。明確拒絕必須重寫允許才能在這種情況下始終如此有用。另外，請記住，默認情況下未授予權限時，顯式拒絕使用往往會相對較少。明確否認的最常見用法之一是列入黑名單，如果拒絕被允許超過，這是不可能的。 – 2012-01-04 12:45:12

對於我來說'允許'應該在有衝突的權限時從'拒絕'中獲勝。一般而言，您將角色跨越廣泛的功能集，但權限有限（例如，訪客）角色的責任心更大。只有當您允許覆蓋「拒絕」時，您才能重新使用常規角色。

示例權限：

1。

deny members all 
allow members to view articles

允許推翻拒絕。

蘇曼編輯。編輯可以做一些事情，並且拒絕其他一些事情，例如權限X.現在，如果拒絕優先於允許Suman不允許執行X.爲非常特定的特權創建角色是很重要的，修改一些常規角色（客人，成員），否則它會雙向切割（無法否認蘇曼通過角色給予他的特權）。

來源

2012-01-02 08:41:28 koen

檢查我的更新，我做了一個真實的場景 – Starx 2012-01-02 09:03:42

@Starx希望我的更新使它更清晰。 – koen 2012-01-02 17:17:47

在我看來，默認應該是拒絕訪問，除非他們被允許作爲一個組的成員訪問它（在tbl_acl中）。

來源

2012-01-02 08:46:11 redmoon7777

這是一個值得商榷的問題，儘管他被拒絕爲編輯，但他被允許成爲會員。 – Starx 2012-01-02 08:51:05

我認爲允許應該覆蓋拒絕（這只是一個意見）。因爲您可以將其視爲正在晉升爲編輯的成員，因此可以獲得更多訪問權限。 – redmoon7777 2012-01-02 08:54:34

檢查我的更新，我做了一個真實的場景 – Starx 2012-01-02 09:04:09

我認爲建築的心理形象是適當的。2情景的：

的「默認允許」的情景：

建築物的入口是開放
大樓的房間是開放
在房間的任何衣櫃是開放

如果在這種情況下拒絕訪問它將看起來像這樣：

約翰是不允許進入房間A
約翰是接近室A
總得有人來檢查它是否是約翰
有人必須拒絕約翰進入房間
管理局某人關閉在約翰面前的門

這正好與在每個房間等衣櫃這是每一個想進入房間，應該是比較黑名單要麼拒絕或允許的人做同樣的。

這是如何實用？

的「默認拒絕」的情景：

建築物的入口關閉並上鎖
建築的房間都關閉並鎖定
在房間的任何衣櫃被關閉，鎖定

如果在這種情況下，允許訪問它應該是這樣的：

爲建築物以及人員需要訪問的每個房間和壁櫥提供一把鑰匙。

這是否實用？甚至有可能給每個人一個獨特的鑰匙。是的，這是很多管理和管理的關鍵。但勝利？它將提供粒度和靈活性，同時提高安全性。

來源

2016-02-02 09:33:43

ACL /角色管理：管理具有多個角色和衝突的允許的用戶

回答

相關問題