這里的權(quán)限系統(tǒng)要區(qū)分2個概念：
粗粒度：表示類（model）別級，即僅考慮對象的類別(the type of object)，不考慮對象的某個特定的實例。比如，對合同這個類別(contract)的管理中，創(chuàng)建、刪除等操作，對所有的用戶都一視同仁，并不區(qū)分具體的對象實例（銷售合同，生產(chǎn)合同）。
細粒度：表示實例(instance)級別，即需要考慮具體對象的實例(the instance of object)，當(dāng)然，細粒度是在考慮粗粒度的對象類別之后才再考慮特定實例。比如，銷售合同管理中，合同所有者擁有查看、修改、刪除等權(quán)限，其他用戶只有合同的查看權(quán)限。
權(quán)限系統(tǒng)的設(shè)計原則：權(quán)限邏輯配合業(yè)務(wù)邏輯。即權(quán)限系統(tǒng)以為業(yè)務(wù)邏輯提供服務(wù)為目標。
細粒度的權(quán)限問題因為其業(yè)務(wù)相關(guān)性而不具通用意義，它們被理解為是“業(yè)務(wù)邏輯”的一部分。比如，要求：“某個合同只能被它的創(chuàng)建者刪除，與創(chuàng)建者同組的用戶可以修改，所有的用戶能夠瀏覽”。這既是一個細粒度的權(quán)限問題，也是一個業(yè)務(wù)邏輯問題。在這里它是業(yè)務(wù)邏輯問題，在整個權(quán)限系統(tǒng)的架構(gòu)設(shè)計之中不予考慮。當(dāng)然，權(quán)限系統(tǒng)的構(gòu)架設(shè)計也必須要能支持這樣的業(yè)務(wù)邏輯。或者說，系統(tǒng)提供足夠多但不是完全的控制能力。即，設(shè)計原則歸結(jié)為：“系統(tǒng)只提供粗粒度的權(quán)限，細粒度的權(quán)限被認為是業(yè)務(wù)邏輯的職責(zé)”。
權(quán)限邏輯 ?à 粗粒度
業(yè)務(wù)邏輯 ?à 細粒度
概念：
Object: 指系統(tǒng)中各種功能模塊，業(yè)務(wù)模型（Model），業(yè)務(wù)對象(Object)，界面元素等，它是主體能訪問到的所有對象。由于對象的類型不同，被訪問的權(quán)限也不同。
（1） 系統(tǒng)功能模塊：系統(tǒng)中除了公用的界面，公用的模塊外，其他均為業(yè)務(wù)功能模塊，業(yè)務(wù)操作在設(shè)計階段完成，因此不存在實例的概念。可以直接針對角色進行授權(quán)。
（2） 界面元素：除了功能菜單受到控制外，如要控制功能模塊的界面元素其功能模塊界面元素也需定義，大部分界面元素均包含有相關(guān)的業(yè)務(wù)功能操作，因此可以與數(shù)據(jù)模型統(tǒng)一來處理。
（3） 業(yè)務(wù)模型，業(yè)務(wù)對象：業(yè)務(wù)模型是我們的Domain Model，開發(fā)人員在設(shè)計開發(fā)階段就已經(jīng)定義好了相關(guān)的業(yè)務(wù)操作，也就是相應(yīng)的權(quán)限。 業(yè)務(wù)對象是我們業(yè)務(wù)模型的實例化Domain Object。是用戶在系統(tǒng)運行時創(chuàng)建的，因此它的權(quán)限也是用戶在系統(tǒng)運行時創(chuàng)建的。
|
粗粒度
|
|
細粒度
|
|
|
Domain Model |
業(yè)務(wù)模型，比如合同（Contract Model）
|
Domain Object
|
業(yè)務(wù)模型的某個實例話對象，比如銷售合同（Sell Contract Object）
|
Privilege(Operative, Permission) : 是Object Related的操作。就是指，這個權(quán)限是綁定在特定的對象上的。比如說部門新聞的發(fā)布權(quán)限，叫做"部門新聞發(fā)布權(quán)限"。這就表明，該Privilege是一個發(fā)布權(quán)限，而且是針對部門新聞這種資源的一種發(fā)布權(quán)限。權(quán)限，包括系統(tǒng)定義權(quán)限和用戶自定義權(quán)限，用戶自定義權(quán)限之間可以指定排斥和包含關(guān)系(如：讀取，修改，管理三個權(quán)限，管理 權(quán)限 包含 前兩種權(quán)限)。
Role: 是權(quán)限的集合，是粗粒度和細粒度(業(yè)務(wù)邏輯)的接口。一個基于粗粒度控制的權(quán)限框架軟件，對外的接口應(yīng)該是Role，具體業(yè)務(wù)實現(xiàn)可以直接繼承或拓展豐富Role的內(nèi)容，Role不是如同User或Group的具體實體，它是接口概念，抽象的通稱。Role的繼承通過Group來體現(xiàn)，所以不考慮Role的繼承關(guān)系。但是Role可以與相關(guān)的Group相關(guān)聯(lián)，便于授權(quán)。
Group: 用戶組，權(quán)限分配的單位與載體，直接映射組織關(guān)系。權(quán)限不考慮分配給特定的用戶。組可以包括組(以實現(xiàn)權(quán)限的繼承)。組可以包含用戶，組內(nèi)用戶繼承組的權(quán)限。Group要實現(xiàn)繼承。即在創(chuàng)建時必須要指定該Group的Parent是什么Group。在粗粒度控制上，可以認為，只要某用戶直接或者間接的屬于某個Group那么它就具備這個Group的所有操作許可。細粒度控制上，在業(yè)務(wù)邏輯的判斷中，User僅應(yīng)關(guān)注其直接屬于的Group，用來判斷是否“同組” 。
但是Group的繼承導(dǎo)致的權(quán)限繼承和組織關(guān)系正好相反，組織關(guān)系的上層相應(yīng)的權(quán)限更大，所以是一種逆向繼承。
User: 純粹的用戶，與權(quán)限(operative?permission?privilege)分離,只能通過Role去關(guān)聯(lián)相應(yīng)的權(quán)限。
關(guān)系：
Privilege ? n : 1 à Resource
Role ? n : n à Privilege
Group ? n : n à User
Group ? n : n à Role
User ? n : n à Role
權(quán)限系統(tǒng)的操作模式：
(1): 創(chuàng)造資源，權(quán)限: 這里要從粗，細粒度2方面來考慮
粗粒度：開發(fā)人員設(shè)計DomainModel的時候就定義好相關(guān)的操作。比如ContractModel
這個DomainModel,開發(fā)人員設(shè)計的時候就已經(jīng)定義好了模型的相關(guān)操作，比如查看，修改等等。默認的情況下對所有的Role都是相同的。
細粒度： 用戶創(chuàng)建一個DomainModel的實例DomainObject的時候指定相關(guān)的權(quán)
限以及權(quán)限分配。比如銷售合同只能創(chuàng)建者有修改的權(quán)限，同Group的人員只能擁有查看的權(quán)限。
(2): 分配權(quán)限: Administrator指定相關(guān)DomainModel的權(quán)限分配,創(chuàng)建Role，創(chuàng)建Group，給
Group分配User，給Group賦予某個Role等等。
(3): 使用權(quán)限: User 使用 Administrator分配的角色去使用相應(yīng)的系統(tǒng)功能。
模塊劃分：
1) 對象管理模塊。此模塊主要負責(zé)從粗細粒度對于系統(tǒng)中可提供的資源或資源實例進行管理。
2) 權(quán)限管理模塊。此模塊主要負責(zé)對資源權(quán)限進行管理。管理員可以在粗細粒度下對資源權(quán)限進行管理。用戶可以對創(chuàng)建的資源實例進行權(quán)限的管理。
3) 角色管理模塊。此模塊主要負責(zé)對角色進行相應(yīng)的管理（包括添加、刪除、修改）；對角色所擁有的權(quán)限進行相應(yīng)的管理（包括授予、刪除所擁有的權(quán)限）；對用戶和組賦予相應(yīng)的角色等等
4) 用戶管理模塊。此模塊主要負責(zé)對用戶進行管理（包括添加、刪除、修改）；對用戶所屬的角色進行管理（包括添加、刪除）；對用戶所屬的組進行管理。
5) 組管理模塊。組映射組織機構(gòu)，提供對于部門組織機構(gòu)維護(添加、修改、刪除)；對組的成員進行維護；對組所擁有的角色進行管理。
方向:分布式系統(tǒng)設(shè)計