acl（access control list）:訪問許可權列表 如：
user1-->ac1
user1-->ac2
user2-->ac1 此時許可權彙總成乙個列表
這種設計最常見的應用就是檔案系統的許可權設計，如微軟的ntfs
對許可權控制比較分散，不便於管理，比如無法簡單地將一組檔案設定統一的許可權開放給指定的一群使用者
rbac(role base access control):基於角色的許可權控制
與acl 對比 rbac不用給使用者單個分配許可權，只用指向對應的角色就會有對應的許可權，而且分配許可權和收回許可權都很方便
如選單許可權的設計：使用者與角色關聯，角色與選單關聯
abac（attribute base access control）基於屬性的許可權控制
不同於常見的將使用者通過某種方式關聯到許可權的方式，abac則是通過動態計算乙個或一組屬性來是否滿足某種條件來進行授權判斷（可以編寫簡單的邏輯）。屬性通常來說分為四類：使用者屬性（如使用者年齡），環境屬性（如當前時間），操作屬性（如讀取）和物件屬性（如一篇文章，又稱資源屬性），所以理論上能夠實現非常靈活的許可權控制，幾乎能滿足所有型別的需求。
例如規則：「允許所有班主任在上課時間自由進出校門」這條規則，其中，「班主任」是使用者的角色屬性，「上課時間」是環境屬性，「進出」是操作屬性，而「校門」就是物件屬性了。為了實現便捷的規則設定和規則判斷執行，abac通常有配置檔案（xml、yaml等）或dsl配合規則解析引擎使用。xacml（extensible access control markup language）是abac的乙個實現，但是該設計過於複雜，我還沒有完全理解，故不做介紹。
總結一下，abac有如下特點：
集中化管理
可以按需實現不同顆粒度的許可權控制
不需要預定義判斷邏輯，減輕了許可權系統的維護成本，特別是在需求經常變化的系統中
定義許可權時，不能直**出使用者和物件間的關係
規則如果稍微複雜一點，或者設計混亂，會給管理者維護和追查帶來麻煩
許可權判斷需要實時執行，規則過多會導致效能問題
既然abac這麼好，那最流行的為什麼還是rbac呢？
我認為主要還是因為大部分系統對許可權控制並沒有過多的需求，而且abac的管理相對來說太複雜了。kubernetes便因為abac太難用，在1.8版本裡引入了rbac的方案。
abac有時也被稱為pbac（policy-based access control）或cbac（claims-based access control）。
許可權系統設計
許可權系統 2 operation 許可權控制可以看作乙個filter模式的應用,這也符合aop思想的應用條件。在乙個簡化的圖象中，我們只需要將乙個判別函式 isallowed subject,operation,resource 插入到所有安全敏感的函式呼叫之前就可以了。雖然概念上很完美，具體實現...
系統設計 許可權模型設計
該許可權資料模型設計依據spring security框架，針對賬號 角色 許可權 資源 模組 選單 等物件做了簡單設計 指系統登陸賬號，系統使用者物件身份標識。只使用者的身份象徵標識，乙個登陸賬號，可同時擁有多個系統使用角色 身份 比如在網購 當中，使用者同時擁有a資源管理員角色 b資源管理員角色...
許可權系統的實體設計
此許可權系統設計的目標是既可以直接對角色進行授權，又可以直接對使用者授權。實體類modue，用來封裝模組資訊，自關聯，樹形結構。實體類role，用來封裝角色資訊。實體類user，用來封裝使用者資訊。實體類usersroles,包含user，role兩個成員變數以及乙個整型的成員變數，整型變數用來標識...