|
前言：
權限往往是一個極其複雜的問題，但也可簡單表述爲這樣的邏輯表達式：判斷“Who對What(Which)進行How的操作”的邏輯表達式是否爲真。針對不同的應用，需要根據項目的實際情況和具體架構，在維護性、靈活性、完整性等N多個方案之間比較權衡，選擇符合的方案。
目標：
直觀，因爲系統最終會由最終用戶來維護，權限分配的直觀和容易理解，顯得比較重要，系統不辭勞苦的實現了組的繼承，除了功能的必須，更主要的就是因爲它足夠直觀。
簡單，包括概念數量上的簡單和意義上的簡單還有功能上的簡單。想用一個權限系統解決所有的權限問題是不現實的。設計中將常常變化的“定製”特點比較強的部分判斷爲業務邏輯，而將常常相同的“通用”特點比較強的部分判斷爲權限邏輯就是基於這樣的思路。
擴展，採用可繼承在擴展上的困難。的Group概念在支持權限以組方式定義的同時有效避免了重定義時
現狀：
對於在企業環境中的訪問控制方法，一般有三種：
1.自主型訪問控制方法。目前在我國的大多數的信息系統中的訪問控制模塊中基本是藉助於自主型訪問控制方法中的訪問控制列表(ACLs)。
2.強制型訪問控制方法。用於多層次安全級別的軍事應用。
3.基於角色的訪問控制方法（RBAC）。是目前公認的解決大型企業的統一資源訪問控制的有效方法。其顯著的兩大特徵是：1.減小授權管理的複雜性，降低管理開銷。2.靈活地支持企業的安全策略，並對企業的變化有很大的伸縮性。
名詞：
粗粒度：表示類別級，即僅考慮對象的類別(the type of object)，不考慮對象的某個特
定實例。比如，用戶管理中，創建、刪除，對所有的用戶都一視同仁，並不區分操作的具體對象實例。
細粒度：表示實例級，即需要考慮具體對象的實例(the instance of object)，當然，細
粒度是在考慮粗粒度的對象類別之後纔再考慮特定實例。比如，合同管理中，列表、刪除，需要區分該合同實例是否爲當前用戶所創建。
原則：
權限邏輯配合業務邏輯。即權限系統以爲業務邏輯提供服務爲目標。相當多細粒度的權限問題因其極其獨特而不具通用意義，它們也能被理解爲是“業務邏輯”的一部分。比如，要求：“合同資源只能被它的創建者刪除，與創建者同組的用戶可以修改，所有的用戶能夠瀏覽”。這既可以認爲是一個細粒度的權限問題，也可以認爲是一個業務邏輯問題。在這裏它是業務邏輯問題，在整個權限系統的架構設計之中不予過多考慮。當然，權限系統的架構也必須要能支持這樣的控制判斷。或者說，系統提供足夠多但不是完全的控制能力。即，設計原則歸結爲：“系統只提供粗粒度的權限，細粒度的權限被認爲是業務邏輯的職責”。
需要再次強調的是，這裏表述的權限系統僅是一個“不完全”的權限系統，即，它不提供所有關於權限的問題的解決方法。它提供一個基礎，並解決那些具有“共性”的(或者說粗粒度的)部分。在這個基礎之上，根據“業務邏輯”的獨特權限需求，編碼實現剩餘部分(或者說細粒度的)部分，纔算完整。回到權限的問題公式，通用的設計僅解決了Who+What+How 的問題，其他的權限問題留給業務邏輯解決。
概念：
Who：權限的擁用者或主體（Principal、User、Group、Role、Actor等等）
What：權限針對的對象或資源（Resource、Class）。
How：具體的權限（Privilege, 正向授權與負向授權）。
Role：是角色，擁有一定數量的權限。
Operator：操作。表明對What的How 操作。
說明：
User：與 Role 相關，用戶僅僅是純粹的用戶，權限是被分離出去了的。User是不能與 Privilege 直接相關的，User 要擁有對某種資源的權限，必須通過Role去關聯。解決 Who 的問題。
Resource：就是系統的資源，比如部門新聞，文檔等各種可以被提供給用戶訪問的對象。資源可以反向包含自身，即樹狀結構，每一個資源節點可以與若干指定權限類別相關可定義是否將其權限應用於子節點。
Privilege：是Resource Related的權限。就是指，這個權限是綁定在特定的資源實例上的。比如說部門新聞的發佈權限，叫做"部門新聞發佈權限"。這就表明，該Privilege是一個發佈權限，而且是針對部門新聞這種資源的一種發佈權限。Privilege是由Creator在做開發時就確定的。權限，包括系統定義權限和用戶自定義權限用戶自定義權限之間可以指定排斥和包含關係(如：讀取，修改，管理三個權限，管理 權限 包含 前兩種權限)。Privilege 如"刪除" 是一個抽象的名詞，當它不與任何具體的 Object 或 Resource 綁定在一起時是沒有任何意義的。拿新聞發佈來說，發佈是一種權限，但是隻說發佈它是毫無意義的。因爲不知道發佈可以操作的對象是什麼。只有當發佈與新聞結合在一起時，纔會產生真正的 Privilege。這就是 Privilege Instance。權限系統根據需求的不同可以延伸生很多不同的版本。
Role：是粗粒度和細粒度(業務邏輯)的接口，一個基於粗粒度控制的權限框架軟件，對外的接口應該是Role，具體業務實現可以直接繼承或拓展豐富Role的內容，Role不是如同User或Group的具體實體，它是接口概念，抽象的通稱。
Group：用戶組，權限分配的單位與載體。權限不考慮分配給特定的用戶。組可以包括組(以實現權限的繼承)。組可以包含用戶，組內用戶繼承組的權限。Group要實現繼承。即在創建時必須要指定該Group的Parent是什麼Group。在粗粒度控制上，可以認爲，只要某用戶直接或者間接的屬於某個Group那麼它就具備這個Group的所有操作許可。細粒度控制上，在業務邏輯的判斷中，User僅應關注其直接屬於的Group，用來判斷是否“同組” 。Group是可繼承的，對於一個分級的權限實現，某個Group通過“繼承”就已經直接獲得了其父Group所擁有的所有“權限集合”，對這個Group而言，需要與權限建立直接關聯的，僅是它比起其父Group需要“擴展”的那部分權限。子組繼承父組的所有權限，規則來得更簡單，同時意味着管理更容易。爲了更進一步實現權限的繼承，最直接的就是在Group上引入“父子關係”。
User與Group是多對多的關係。即一個User可以屬於多個Group之中，一個Group可以包括多個User。子Group與父Group是多對一的關係。Operator某種意義上類似於Resource + Privilege概念，但這裏的Resource僅包括Resource Type不表示Resource Instance。Group 可以直接映射組織結構，Role 可以直接映射組織結構中的業務角色，比較直觀，而且也足夠靈活。Role對系統的貢獻實質上就是提供了一個比較粗顆粒的分配單位。
Group與Operator是多對多的關係。各概念的關係圖示如下：
解釋：
Operator的定義包括了Resource Type和Method概念。即，What和How的概念。之所以將What和How綁定在一起作爲一個Operator概念而不是分開建模再建立關聯，這是因爲很多的How對於某What纔有意義。比如，發佈操作對新聞對象纔有意義，對用戶對象則沒有意義。
How本身的意義也有所不同，具體來說，對於每一個What可以定義N種操作。比如，對於合同這類對象，可以定義創建操作、提交操作、檢查衝突操作等。可以認爲，How概念對應於每一個商業方法。其中，與具體用戶身份相關的操作既可以定義在操作的業務邏輯之中，也可以定義在操作級別。比如，創建者的瀏覽視圖與普通用戶的瀏覽視圖要求內容不同。既可以在外部定義兩個操作方法，也可以在一個操作方法的內部根據具體邏輯進行處理。具體應用哪一種方式應依據實際情況進行處理。
這樣的架構，應能在易於理解和管理的情況下，滿足絕大部分粗粒度權限控制的功能需要。但是除了粗粒度權限，系統中必然還會包括無數對具體Instance的細粒度權限。這些問題，被留給業務邏輯來解決，這樣的考慮基於以下兩點：
一方面，細粒度的權限判斷必須要在資源上建模權限分配的支持信息纔可能得以實現。比如，如果要求創建者和普通用戶看到不同的信息內容，那麼，資源本身應該有其創建者的信息。另一方面，細粒度的權限常常具有相當大的業務邏輯相關性。對不同的業務邏輯，常常意味着完全不同的權限判定原則和策略。相比之下，粗粒度的權限更具通用性，將其實現爲一個架構，更有重用價值；而將細粒度的權限判斷實現爲一個架構級別的東西就顯得繁瑣，而且不是那麼的有必要，用定製的代碼來實現就更簡潔，更靈活。
所以細粒度控制應該在底層解決，Resource在實例化的時候，必需指定Owner和GroupPrivilege在對Resource進行操作時也必然會確定約束類型：究竟是OwnerOK還是GroupOK還是AllOK。Group應和Role嚴格分離User和Group是多對多的關係，Group只用於對用戶分類，不包含任何Role的意義；Role只授予User，而不是Group。如果用戶需要還沒有的多種Privilege的組合，必須新增Role。Privilege必須能夠訪問Resource，同時帶User參數，這樣權限控制就完備了。
思想：
權限系統的核心由以下三部分構成：1.創造權限，2.分配權限，3.使用權限，然後，系統各部分的主要參與者對照如下：1.創造權限 - Creator創造，2.分配權限 - Administrator 分配，3.使用權限 - User：
1. Creator 創造 Privilege， Creator 在設計和實現系統時會劃分，一個子系統或稱爲模塊，應該有哪些權限。這裏完成的是 Privilege 與 Resource 的對象聲明，並沒有真正將 Privilege 與具體Resource 實例聯繫在一起，形成Operator。
2. Administrator 指定 Privilege 與 Resource Instance 的關聯。在這一步， 權限真正與資源實例聯繫到了一起， 產生了Operator（Privilege Instance）。Administrator利用Operator這個基本元素，來創造他理想中的權限模型。如，創建角色，創建用戶組，給用戶組分配用戶，將用戶組與角色關聯等等...這些操作都是由 Administrator 來完成的。
3. User 使用 Administrator 分配給的權限去使用各個子系統。Administrator 是用戶，在他的心目中有一個比較適合他管理和維護的權限模型。於是，程序員只要回答一個問題，就是什麼權限可以訪問什麼資源，也就是前面說的 Operator。程序員提供 Operator 就意味着給系統穿上了盔甲。Administrator 就可以按照他的意願來建立他所希望的權限框架可以自行增加，刪除，管理Resource和Privilege之間關係。可以自行設定用戶User和角色Role的對應關係。(如果將 Creator看作是 Basic 的發明者， Administrator 就是 Basic 的使用者，他可以做一些腳本式的編程) Operator是這個系統中最關鍵的部分，它是一個紐帶，一個系在Programmer，Administrator，User之間的紐帶。
用一個功能模塊來舉例子。
一．建立角色功能並做分配：
1．如果現在要做一個員工管理的模塊(即Resources)，這個模塊有三個功能，分別是：增加，修改，刪除。給這三個功能各自分配一個ID，這個ID叫做功能代號：
Emp_addEmp，Emp_deleteEmp，Emp_updateEmp。
2．建立一個角色(Role)，把上面的功能代碼加到這個角色擁有的權限中，並保存到數據庫中。角色包括系統管理員，測試人員等。
3．建立一個員工的賬號，並把一種或幾種角色賦給這個員工。比如說這個員工既可以是公司管理人員，也可以是測試人員等。這樣他登錄到系統中將會只看到他擁有權限的那些模塊。
二．把身份信息加到Session中。
登錄時，先到數據庫中查找是否存在這個員工，如果存在，再根據員工的sn查找員工的權限信息，把員工所有的權限信息都入到一個Hashmap中，比如就把上面的Emp_addEmp等放到這個Hashmap中。然後把Hashmap保存在一個UserInfoBean中。最後把這個UserInfoBean放到Session中，這樣在整個程序的運行過程中，系統隨時都可以取得這個用戶的身份信息。
三．根據用戶的權限做出不同的顯示。
可以對比當前員工的權限和給這個菜單分配的“功能ID”判斷當前用戶是否有打開這個菜單的權限。例如：如果保存員工權限的Hashmap中沒有這三個ID的任何一個，那這個菜單就不會顯示，如果員工的Hashmap中有任何一個ID，那這個菜單都會顯示。
對於一個新聞系統(Resouce)，假設它有這樣的功能(Privilege)：查看，發佈，刪除，修改；假設對於刪除，有"新聞系統管理者只能刪除一月前發佈的，而超級管理員可刪除所有的這樣的限制，這屬於業務邏輯(Business logic)，而不屬於用戶權限範圍。也就是說權限負責有沒有刪除的Permission，至於能刪除哪些內容應該根據UserRole or UserGroup來決定(當然給UserRole or UserGroup分配權限時就應該包含上面兩條業務邏輯)。
一個用戶可以擁有多種角色，但同一時刻用戶只能用一種角色進入系統。角色的劃分方法可以根據實際情況劃分，按部門或機構進行劃分的，至於角色擁有多少權限，這就看系統管理員賦給他多少的權限了。用戶—角色—權限的關鍵是角色。用戶登錄時是以用戶和角色兩種屬性進行登錄的（因爲一個用戶可以擁有多種角色，但同一時刻只能扮演一種角色），根據角色得到用戶的權限，登錄後進行初始化。這其中的技巧是同一時刻某一用戶只能用一種角色進行登錄。
針對不同的“角色”動態的建立不同的組，每個項目建立一個單獨的Group，對於新的項目，建立新的 Group 即可。在權限判斷部分，應在商業方法上予以控制。比如：不同用戶的“操作能力”是不同的(粗粒度的控制應能滿足要求)，不同用戶的“可視區域”是不同的(體現在對被操作的對象的權限數據，是否允許當前用戶訪問，這需要對業務數據建模的時候考慮權限控制需要)。
擴展性：
有了用戶/權限管理的基本框架，Who(User/Group)的概念是不會經常需要擴展的。變化的可能是系統中引入新的 What (新的Resource類型)或者新的How(新的操作方式)。那在三個基本概念中，僅在Permission上進行擴展是不夠的。這樣的設計中Permission實質上解決了How 的問題，即表示了“怎樣”的操作。那麼這個“怎樣”是在哪一個層次上的定義呢？將Permission定義在“商業方法”級別比較合適。比如，發佈、購買、取消。每一個商業方法可以意味着用戶進行的一個“動作”。定義在商業邏輯的層次上，一方面保證了數據訪問代碼的“純潔性”，另一方面在功能上也是“足夠”的。也就是說，對更低層次，能自由的訪問數據，對更高層次，也能比較精細的控制權限。
確定了Permission定義的合適層次，更進一步，能夠發現Permission實際上還隱含了What的概念。也就是說，對於What的How操作纔會是一個完整的Operator。比如，“發佈”操作，隱含了“信息”的“發佈”概念，而對於“商品”而言發佈操作是沒有意義的。同樣的，“購買”操作，隱含了“商品”的“購買”概念。這裏的綁定還體現在大量通用的同名的操作上，比如，需要區分“商品的刪除”與“信息的刪除”這兩個同名爲“刪除”的不同操作。
提供權限系統的擴展能力是在Operator (Resource + Permission)的概念上進行擴展。Proxy 模式是一個非常合適的實現方式。實現大致如下：在業務邏輯層(EJB Session Facade [Stateful SessionBean]中)，取得該商業方法的Methodname，再根據Classname和 Methodname 檢索Operator 數據，然後依據這個Operator信息和Stateful中保存的User信息判斷當前用戶是否具備該方法的操作權限。
應用在 EJB 模式下，可以定義一個很明確的 Business層次，而一個Business 可能意味着不同的視圖，當多個視圖都對應於一個業務邏輯的時候，比如，Swing Client以及 Jsp Client 訪問的是同一個 EJB 實現的 Business。在 Business 層上應用權限較能提供集中的控制能力。實際上，如果權限系統提供了查詢能力，那麼會發現，在視圖層次已經可以不去理解權限，它只需要根據查詢結果控制界面就可以了。
靈活性：
Group和Role，只是一種輔助實現的手段，不是必需的。如果系統的Role很多，逐個授權違背了“簡單，方便”的目的，那就引入Group，將權限相同的Role組成一個Group進行集中授權。Role也一樣，是某一類Operator的集合，是爲了簡化針對多個Operator的操作。
Role把具體的用戶和組從權限中解放出來。一個用戶可以承擔不同的角色，從而實現授權的靈活性。當然，Group也可以實現類似的功能。但實際業務中，Group劃分多以行政組織結構或業務功能劃分；如果爲了權限管理強行將一個用戶加入不同的組，會導致管理的複雜性。
Domain的應用。爲了授權更靈活，可以將Where或者Scope抽象出來，稱之爲Domain，真正的授權是在Domain的範圍內進行，具體的Resource將分屬於不同的Domain。比如：一個新聞機構有國內與國外兩大分支，兩大分支內又都有不同的資源（體育類、生活類、時事政治類）。假如所有國內新聞的權限規則都是一樣的，所有國外新聞的權限規則也相同。則可以建立兩個域，分別授權，然後只要將各類新聞與不同的域關聯，受域上的權限控制，從而使之簡化。
權限系統還應該考慮將功能性的授權與資源性的授權分開。很多系統都只有對系統中的數據（資源）的維護有權限控制，但沒有對系統功能的權限控制。
權限系統最好是可以分層管理而不是集中管理。大多客戶希望不同的部門能且僅能管理其部門內部的事務，而不是什麼都需要一個集中的Administrator或Administrators組來管理。雖然你可以將不同部門的人都加入Administrators組，但他們的權限過大，可以管理整個系統資源而不是該部門資源。
正向授權與負向授權：正向授權在開始時假定主體沒有任何權限，然後根據需要授予權限，適合於權限要求嚴格的系統。負向授權在開始時假定主體有所有權限，然後將某些特殊權限收回。
權限計算策略：系統中User，Group，Role都可以授權，權限可以有正負向之分，在計算用戶的淨權限時定義一套策略。
系統中應該有一個集中管理權限的AccessService，負責權限的維護（業務管理員、安全管理模塊）與使用（最終用戶、各功能模塊），該AccessService在實現時要同時考慮一般權限與特殊權限。雖然在具體實現上可以有很多，比如用Proxy模式，但應該使這些Proxy依賴於AccessService。各模塊功能中調用AccessService來檢查是否有相應的權限。所以說，權限管理不是安全管理模塊自己一個人的事情，而是與系統各功能模塊都有關係。每個功能模塊的開發人員都應該熟悉安全管理模塊，當然，也要從業務上熟悉本模塊的安全規則。
技術實現：
1．表單式認證，這是常用的，但用戶到達一個不被授權訪問的資源時，Web容器就發
出一個html頁面，要求輸入用戶名和密碼。
2．一個基於Servlet Sign in/Sign out來集中處理所有的Request，缺點是必須由應用程序自己來處理。
3．用Filter防止用戶訪問一些未被授權的資源，Filter會截取所有Request/Response，
然後放置一個驗證通過的標識在用戶的Session中，然後Filter每次依靠這個標識來決定是否放行Response。
這個模式分爲：
Gatekeeper ：採取Filter或統一Servlet的方式。
Authenticator： 在Web中使用JAAS自己來實現。
用戶資格存儲LDAP或數據庫：
1. Gatekeeper攔截檢查每個到達受保護的資源。首先檢查這個用戶是否有已經創建
好的Login Session，如果沒有，Gatekeeper 檢查是否有一個全局的和Authenticator相關的session？
2. 如果沒有全局的session，這個用戶被導向到Authenticator的Sign-on 頁面，
要求提供用戶名和密碼。
3. Authenticator接受用戶名和密碼，通過用戶的資格系統驗證用戶。
4. 如果驗證成功，Authenticator將創建一個全局Login session，並且導向Gatekeeper
來爲這個用戶在他的web應用中創建一個Login Session。
5. Authenticator和Gatekeepers聯合分享Cookie，或者使用Tokens在Query字符裏。
因爲我在上一個的項目中負責有關權限控制這一塊，所以Linkin把權限系統方面的設計工作交給我了。但是，我不想沿用以前我們設計的權限系統，因爲我們以前的權限系統有一些缺陷。並且在做以前的權限系統的時候也積累了一些我的想法，希望能在這次的系統中把我以前的一些想法應用上去，設計出一個更好的權限系統，因爲這個權限系統是爲大中型企業應用框架服務的，所以會比較全面，但是又絕對不會像某些變態的ERP系統對數據表中的每個字段都作CRUD權限控制。我設計的原則是“夠用，好用”。權限系統只負責粗粒度上的控制，細粒度的權限控制，交與子業務系統自己負責。
說到權限控制，從應用系統誕生那天起，他就跟隨着出現了。說白了所謂權限控制就是你只能訪問和操作特定的系統資源。就像正常情況下你只能從銀行裏取出屬於你自己的錢一樣。同樣你也只能查詢你自己的帳戶裏面的餘額。似乎是老生常談了，那就讓我們直奔主題吧。
如何在我們自己的系統中設計一套安全，易用，能夠適應以後企業級應用擴展的權限控制機制。經過權衡和我們自己以往的經驗，認爲基於角色的訪問控制方法（RBAC）。是目前公認的解決大型企業的統一資源訪問控制的有效方法。其顯著的兩大特徵是：
1.減小授權管理的複雜性，降低管理開銷。
2.靈活地支持企業的安全策略，並對企業的變化有很大的伸縮性。
首先讓我們來認識一下，在角色（Role）控制訪問中需要用到的幾個概念：
1.User（用戶）。一個具有系統唯一標識（一般是賬號Account）的純粹用戶，他和Role和Group有關聯。本身他的權限是被分離出去的，User也不能與任何權限有任何的聯繫。他的權限通過Role去關聯。
2.Role（角色）。角色的作用就是和衆多的權限相連，然後一個User或是一個Group必須和一個Role關聯，才具有與該Role相連的所有的權限。呵呵不知道，我表達清楚了沒有。舉一個例子，比如系統中有一個“招聘信息發佈員”角色，一個賬號“MyAccount”。這個“招聘信息發佈員”的角色具有“添加”、“編輯”、“刪除”招聘信息的權限。我就只需要把“MyAccount”這個賬號加入到“招聘信息發佈員”的角色中去，“MyAccount”就具有了相應的權限。如果到後面還有“MyAccount2”“MyAccount3”.也需要同樣的權限，和前面一樣。我們把他們加入到“招聘信息發佈員”角色中去就好了。大大降低了授權管理的複雜度。(在我的想法裏，還有一種特殊的Role，這種Role可以和機構有所聯繫，可以爲加入該Role的User指定相應的業務機構，比如“招聘管理員”這個角色，很有可能出現總公司的招聘人員負責幾家子公司的招聘工作，那麼有了這樣的Role,我們那個把招聘人員加入的同時，指定他所管理的機構就可以達到目的。類似的還有一個文祕管理幾個公司的情況。這種Role爲業務系統的擴展提供了很大的便利。)
再進一步，我們試着想象如果角色之間可以繼承權限，那麼權限的設置是不是就更加的簡單了呢。角色A只要繼承角色B，角色A的權限就是角色A和角色B的權限的合集。這我們這個醫療信息系統中，我決定嘗試一下角色可單繼承的權限控制。儘可能的簡化授權操作。
3.Group（用戶組），似乎這個概念和Role和有雷同之處，感覺都是一些個用戶的組合。從本質上說兩者確實都是對某些特定用戶的抽象和提取。比如說Role（角色）就是對User的操作權限共性的提取。舉個例子上面我們提到的“招聘信息發佈員”，他理所當然的具有管理本部門招聘信息的權限，這是系統中所有招聘管理員的權限共性。所以就產生了“招聘信息發佈員”這個角色。區別於Role,Group提取更多的是User的部門共性和職位共性，Group中的User可以是一個部門中的所有員工，也可以是公司中所有的文祕，甚至可以就是幾個人的組合。當然在我們的系統中絕大多數的組都是和機構一一對應的，並且這樣的組通過所屬機構的層次關係表現出包含關係，子機構的組必然包含於父機構的組。我把這種組稱爲“Organ Group”——機構組。同時可以添加一些自定義的組,把你想歸納的User加入到該組中，這樣的組我把它叫做“User defined Group”——自定義組。 爲什麼要這麼設計呢？把人員劃成這麼多組。這裏有幾個優點
（1）可以簡化授權。直接把一個組裏面的人員全部加入一個角色，省的一個一個的去加。
（2）方便的資源管理。在現實的環境中，個個業務部門所屬的資源是不一樣的。比如一個文件發佈的功能，需要選定瀏覽範圍，這樣只要把公文賦給幾個特定的組就可以了。這幾個組裏面的人自動獲得了瀏覽該公文的權限。
（3）業務的靈活體現。因爲有自定義組的存在，當出現新的業務，比如有一個臨時項目組，需要拉幾個人，只需要新建一個自定義組，便可以對其進行各種業務操作。
4.Permission（權限許可）。在這裏先要說說Resource(資源)和 Operation(操作)的概念。Resource就是系統裏面可用的功能模塊，比如“人員信息管理”。而操作就是在管理模塊裏的添加，刪除和修改等等。Permission就是（Resource + Operation），而Permission就是和Role緊密相連的權限了。Administrator也就是將這些Permission賦給Role，那麼Role中的User便具有相應的權限了。
5.Organ（機構）。這個倒是無需多言。機構是整個信息系統的骨架，最直接的Organ Group就是建立在機構之上的。
6.Position(職務)。這個概念好像離權限系統的設計有點遠，我也一直在猶豫要不要把這個和人事系統更有血緣關係的東東弄到權限系統中來，來回思考了我們框架的目標——“一個高可擴展性，高可靠性，支持快速構建業務的企業級應用基礎框架”，並且現在企業數據都希望能夠“大集中”、“大統一”，未來的人事系統可以完全的構建在我們的框架之上，作爲一個子系統而存在。所以我最終還是決定，將這個概念引到我們的權限系統中來，並且成爲不可或缺一部分，任何User必須具有在某個Organ下的Position才能進入到系統。
Linkin這裏指出這樣做似乎有過度設計之嫌，不符合XP的精神。我也有這麼一點點感覺，因爲我感到現在的設計已經基本能解決所有的權限問題了，甚至考慮到了未來的業務系統的權限實現方式。同時，這個權限設計確實有點趨於複雜（當然還不至於變態），會對今後系統管理員的素質提出更高的要求。有點不好把握，還是大家討論討論吧。
|
