許可權設計
1. 前言：
許可權管理往往是乙個極其複雜的問題，但也可簡單表述為這樣的邏輯表示式：判斷「who對what(which)進行how的操作」的邏輯表示式是否為真。針對不同的應用，需要根據專案的實際情況和具體
架構，在維護性、靈活性、完整性等n多個方案之間比較權衡，選擇符合的方案。
2. 目標：
直觀，因為系統最終會由終端使用者來維護，許可權分配的直觀和容易理解，顯得比較重要簡單，包括概念數量上的簡單和意義上的簡單還有功能上的簡單。想用乙個許可權系統解決所有的許可權問題是不現實的。設計中將常常變化的「定製」特點比較強的部分判斷為業務邏輯，而將常常相同的「通用」特點比較強的部分判斷為許可權邏輯就是基於這樣的思路。
3. 現狀：
對於在企業環境中的訪問控制方法，一般有三種：
1.自主型訪問控制方法：目前在我國的大多數的資訊系統中的訪問控制模組中基本是借助於自主型訪問控制方法中的訪問控制列表(acls)。
2.強制型訪問控制方法：用於多層次安全級別的軍事應用。
3.基於角色的訪問控制方法（rbac）：是目前公認的解決大型企業的統一資源訪問控制的有效方法。其顯著的兩大特徵是：1.減小授權管理的複雜性，降低管理開銷。2.靈活地支援企業的安全策略，並對企業的變化有很大的伸縮性。
4. 名詞：
粗粒度：表示類別級，即僅考慮物件的類別(the type of object)，不考慮物件的某個特定例項。比如，使用者管理中，建立、刪除，對所有的使用者都一視同仁，並不區分操作的具體物件例項。
細粒度：表示例項級，即需要考慮具體物件的例項(the instance of object)，當然，細粒度是在考慮粗粒度的物件類別之後才再考慮特定例項。比如，合同管理中，列表、刪除，需要區分該合同例項是否為當前使用者所建立。
5. 原則：
許可權邏輯配合業務邏輯。即許可權系統以為業務邏輯提供服務為目標。相當多細粒度的許可權問題因其極其獨特而不具通用意義，它們也能被理解為是「業務邏輯」的一部分。比如，要求：「合同資源只能被它的建立者刪除，與建立者同組的使用者可以修改，所有的使用者能夠瀏覽」。這既可以認為是乙個細粒度的許可權問題，也可以認為是乙個業務邏輯問題。在這裡它是業務邏輯問題，在整個許可權系統的架構設計之中不予過多考慮。當然，許可權系統的架構也必須要能支援這樣的控制判斷。或者說，系統提供足夠多但不是完全的控制能力。即，設計原則歸結為：「系統只提供粗粒度的許可權，細粒度的許可權被認為是業務邏輯的職責」。
許可權公式：who+what(which)+how 的問題，在這裡我們實現what和部分which的許可權問題(粗粒度和細粒度相合，到一定的程度)，其他的許可權問題留給業務邏輯解決
6. 概念：
who：許可權的擁用者或主體（principal(負責人)、user、group、role、actor等等）
what：許可權針對的物件或資源（resource、class）。
how：具體的許可權（privilege, 正向授權與負向授權）。
role：是角色，擁有一定數量的許可權。
operator：操作。表明對what的how 操作。
7. 解釋：
user：與 role 相關，使用者僅僅是純粹的使用者，許可權是被分離出去了的。user是不能與 privilege 直接相關的，user 要擁有對某種資源的許可權，必須通過role去關聯。解決 who 的問題。
通用的許可權管理系統設計
一般的企業應用系統，最重要的兩個模型是資料模型和許可權模型。資料模型根據不同的行業有所不同，而許可權模型跟行業關係不大，但是每個應用系統所必不可少的，也常常令設計者大為頭疼。如何設計乙個通用的許可權管理系統呢，如何 使這個許可權系統能夠足夠靈活，而又能適應企業不斷變化的業務呢？遵循如下原則就可以基本...
OA系統許可權管理設計 上
任何系統都離不開許可權的管理 有乙個好的許可權管理模組 不僅使我們的系統操作自如 管理方便 也為系統新增亮點。l不同職責的人員，對於系統操作的許可權應該是不同的。優秀的業務系統，這是最基本的功能。l 可以對 組 進行許可權分配。對於乙個大企業的業務系統來說，如果要求管理員為其下員工逐一分配系統操作許...
許可權管理系統（二） 許可權管理系統介紹
1 安全性 誤操作 人為破壞 資料洩露等 2 資料隔離 不同的許可權能看到及操作不同的資料 3 明確職責 運營 客服等不同角色，leader和dev等不同級別 1 使用者 許可權 人員少，功能固定，或者特別簡單的系統 2 rbac role based access control 使用者 角色 許...