權(quán)限設(shè)計原理

《權(quán)限設(shè)計原理》一、權(quán)限設(shè)計概要21.1前言21.2目標(biāo)21.3現(xiàn)狀2二、權(quán)限設(shè)計原那么22.1原那么簡述22.2相關(guān)名詞解釋32.3權(quán)限設(shè)計思想52.4權(quán)限設(shè)計例如52.5權(quán)限設(shè)計的擴(kuò)展的思路62.5需要注意的幾個問題7三、RBAC〔Role-BasedAccessControl〕模型介紹83.1RBAC開展歷史83.1RBAC模型初探83.1一個RBAC模型的實(shí)現(xiàn)11四、ACL〔AccessControlList〕介紹124.1ACL〔AccessControlList〕概述12權(quán)限設(shè)計概要1.1前言權(quán)限往往是一個極其復(fù)雜的問題，但也可簡單表述為這樣的邏輯表達(dá)式：判斷“Who對What(Which)進(jìn)行How的操作”的邏輯表達(dá)式是否為真。針對不同的應(yīng)用，需要根據(jù)工程的實(shí)際情況和具體架構(gòu)，在維護(hù)性、靈活性、完整性等N多個方案之間比擬權(quán)衡，1.2目標(biāo)直觀，因?yàn)橄到y(tǒng)最終會由最終用戶來維護(hù)，權(quán)限分配的直觀和容易理解，顯得比擬重要，系統(tǒng)不辭勞苦的實(shí)現(xiàn)了組的繼承，除了功能的必須，更主要的就是因?yàn)樗銐蛑庇^。簡單，包括概念數(shù)量上的簡單和意義上的簡單還有功能上的簡單。想用一個權(quán)限系統(tǒng)解決所有的權(quán)限問題是不現(xiàn)實(shí)的。設(shè)計中將常常變化的“定制”特點(diǎn)比擬強(qiáng)的局部判斷為業(yè)務(wù)邏輯，而將常常相同的“通用”特點(diǎn)比擬強(qiáng)的局部判斷為權(quán)限邏輯就是基于這樣的思路。擴(kuò)展，采用可繼承的方式解決了權(quán)限在擴(kuò)展上的困難。引進(jìn)Group概念在支持權(quán)限以組方式定義的同時有效防止了權(quán)限的重復(fù)定義。1.3現(xiàn)狀對于在企業(yè)環(huán)境中的訪問控制方法，一般有三種：1.自主型訪問控制方法〔DAC/授權(quán)Authorization〕。目前在我國的大多數(shù)的信息系統(tǒng)中的訪問控制模塊中根本是借助于自主型訪問控制方法中的訪問控制列表(ACLs)。2.強(qiáng)制型訪問控制方法〔多級平安/MultilevelSecurity〕。用于多層次平安級別的軍事應(yīng)用。3.基于角色的訪問控制方法〔RBAC-Role-BasedAccessControl〕。是目前公認(rèn)的解決大型企業(yè)的統(tǒng)一資源訪問控制的有效方法。其顯著的兩大特征是：1.減小授權(quán)管理的復(fù)雜性，降低管理開銷。2.靈活地支持企業(yè)的平安策略，并對企業(yè)的變化有很大的伸縮性。權(quán)限設(shè)計原那么2.1原那么簡述權(quán)限邏輯配合業(yè)務(wù)邏輯。即權(quán)限系統(tǒng)以為業(yè)務(wù)邏輯提供效勞為目標(biāo)。相當(dāng)多細(xì)粒度的權(quán)限問題因其極其獨(dú)特而不具通用意義，它們也能被理解為是"業(yè)務(wù)邏輯"的一局部。比方，要求："合同資源只能被它的創(chuàng)立者刪除，與創(chuàng)立者同組的用戶可以修改，所有的用戶能夠?yàn)g覽"。這既可以認(rèn)為是一個細(xì)粒度的權(quán)限問題，也可以認(rèn)為是一個業(yè)務(wù)邏輯問題。在這里它是業(yè)務(wù)邏輯問題，在整個權(quán)限系統(tǒng)的架構(gòu)設(shè)計之中不予過多考慮。當(dāng)然，權(quán)限系統(tǒng)的架構(gòu)也必須要能支持這樣的控制判斷?；蛘哒f，系統(tǒng)提供足夠多但不是完全的控制能力。即，設(shè)計原那么歸結(jié)為："系統(tǒng)只提供粗粒度的權(quán)限，細(xì)粒度的權(quán)限被認(rèn)為是業(yè)務(wù)邏輯的職責(zé)"。需要再次強(qiáng)調(diào)的是，這里表述的權(quán)限系統(tǒng)僅是一個"不完全"的權(quán)限系統(tǒng)，即，它不提供所有關(guān)于權(quán)限的問題的解決方法。它提供一個根底，并解決那些具有"共性"的(或者說粗粒度的)局部。在這個根底之上，根據(jù)"業(yè)務(wù)邏輯"的獨(dú)特權(quán)限需求，編碼實(shí)現(xiàn)剩余局部(或者說細(xì)粒度的)局部，才算完整?；氐綑?quán)限的問題公式，通用的設(shè)計僅解決了Who+What+How的問題，其他的權(quán)限問題留給業(yè)務(wù)邏輯解決。2.2相關(guān)名詞解釋粗粒度：表示類別級，即僅考慮對象的類別(thetypeofobject)，不考慮對象的某個特定實(shí)例。比方，用戶管理中，創(chuàng)立、刪除，對所有的用戶都一視同仁，并不區(qū)分操作的具體對象實(shí)例。細(xì)粒度：表示實(shí)例級或數(shù)據(jù)級，即需要考慮具體對象的實(shí)例(theinstanceofobject)或?qū)ο蟮膶傩?，?dāng)然，細(xì)粒度是在考慮粗粒度的對象類別之后才再考慮特定實(shí)例。比方，合同管理中，列表、刪除，需要區(qū)分該合同實(shí)例是否為當(dāng)前用戶所創(chuàng)立。Who：權(quán)限的擁用者或主體〔Principal、User、Group、Role、Actor等等〕What：權(quán)限針對的對象或資源〔Resource、Class〕。How：具體的權(quán)限〔Privilege,正向授權(quán)與負(fù)向授權(quán)〕。User：與Role相關(guān)，用戶僅僅是純粹的用戶，權(quán)限是被別離出去了的。User是不能與Privilege直接相關(guān)的，User要擁有對某種資源的權(quán)限，必須通過Role去關(guān)聯(lián)。(注：在如blog中的細(xì)粒度權(quán)限的解決，控制應(yīng)該在底層解決。Resource在實(shí)例化的時候，必需指定Owner和GroupPrivilege。)解決Who的問題。Role：是角色，擁有一定數(shù)量的權(quán)限。是粗粒度和細(xì)粒度(業(yè)務(wù)邏輯)的接口，一個基于粗粒度控制的權(quán)限框架軟件，對外的接口應(yīng)該是Role，具體業(yè)務(wù)實(shí)現(xiàn)可以直接繼承或拓展豐富Role的內(nèi)容，Role不是如同User或Group的具體實(shí)體，它是接口概念，抽象的通稱。有關(guān)role和group的定義有需要補(bǔ)充的地方：根據(jù)模型的不同〔有關(guān)role和group的定義有需要補(bǔ)充的地方：根據(jù)模型的不同〔如RBAC和GBAC等等〕role和group的概念是有很容易混淆的。下面的對Group的定義實(shí)際上也是有針對性的〔似乎是基于RGAC模型的定義〕。把權(quán)限分配給組還是分配給角色應(yīng)該根據(jù)實(shí)際情況和權(quán)限模型具體分析。在rbac中，權(quán)限只賦予role，通過role的分層繼承概念和強(qiáng)制性約束條件從而達(dá)成了權(quán)限的控制。但對于細(xì)粒度的控制〔如不同部門的相同角色，他們的操作相同，但資源客體不同〕上實(shí)現(xiàn)就比擬復(fù)雜。我大致了解了一下，gbac出發(fā)點(diǎn)似乎更注重將相同權(quán)限進(jìn)行抽象集合〔相同的權(quán)限規(guī)定為一個組〕，并通過繼承等概念賦予不同用戶的操作授權(quán)。舉個簡單的例子：一個公司中如果只一個部門，從這個部門中再劃分不同的職務(wù)。這樣的話role和group所起的作用是重合的，我們只需引入其一即可；但如果有了多個部門，我們可以同時引入角色和組〔一個部門一個組〕，組里又有相同的role〔此時role擁有相同的權(quán)利，但部門不同，職能范圍不同〕。這樣一來，將權(quán)限分配給組還是分配和role、是對role進(jìn)行約束還是對組進(jìn)行約束是需要我們根據(jù)具體情況進(jìn)行分析和選型的。這里給出的概念只是網(wǎng)上比擬經(jīng)典的一些論述，整理出來有助于大家學(xué)習(xí)。所以在后面介紹RBAC時給出的概念可能和現(xiàn)在給出的概念有所區(qū)別。Group：用戶組，權(quán)限分配的單位與載體。權(quán)限不考慮分配給特定的用戶。組可以包括組(以實(shí)現(xiàn)權(quán)限的繼承)。組可以包含用戶，組內(nèi)用戶繼承組的權(quán)限。Group要實(shí)現(xiàn)繼承。即在創(chuàng)立時必須要指定該Group的Parent是什么Group。在粗粒度控制上，可以認(rèn)為，只要某用戶直接或者間接的屬于某個Group那么它就具備這個Group的所有操作許可。細(xì)粒度控制上，在業(yè)務(wù)邏輯的判斷中，User僅應(yīng)關(guān)注其直接屬于的Group，用來判斷是否"同組"。Group是可繼承的，對于一個分級的權(quán)限實(shí)現(xiàn)，某個Group通過"繼承"就已經(jīng)直接獲得了其父Group所擁有的所有"權(quán)限集合"，對這個Group而言，需要與權(quán)限建立直接關(guān)聯(lián)的，僅是它比起其父Group需要"擴(kuò)展"的那局部權(quán)限。子組繼承父組的所有權(quán)限，規(guī)那么來得更簡單，同時意味著管理更容易。User與Group是多對多的關(guān)系。即一個User可以屬于多個Group之中，一個Group可以包括多個User。子Group與父Group是多對一的關(guān)系。Resource：[注：應(yīng)等同于object]就是系統(tǒng)的資源，比方部門新聞，文檔等各種可以被提供應(yīng)用戶訪問的對象。資源可以反向包含自身，即樹狀結(jié)構(gòu)，每一個資源節(jié)點(diǎn)可以與假設(shè)干指定權(quán)限類別相關(guān)可定義是否將其權(quán)限應(yīng)用于子節(jié)點(diǎn)。Privilege：[注：應(yīng)等同于permission]是ResourceRelated的權(quán)限。就是指，這個權(quán)限是綁定在特定的資源實(shí)例上的。比方說部門新聞的發(fā)布權(quán)限，叫做"部門新聞發(fā)布權(quán)限"。這就說明，該P(yáng)rivilege是一個發(fā)布權(quán)限，而且是針對部門新聞這種資源的一種發(fā)布權(quán)限。Privilege是由Creator在做開發(fā)時就確定的。權(quán)限，包括系統(tǒng)定義權(quán)限和用戶自定義權(quán)限用戶自定義。權(quán)限之間可以指定排斥和包含關(guān)系(如：讀取，修改，管理三個權(quán)限，管理權(quán)限包含前兩種權(quán)限)。Privilege如"刪除"是一個抽象的名詞，當(dāng)它不與任何具體的Object或Resource綁定在一起時是沒有任何意義的。拿新聞發(fā)布來說，發(fā)布是一種權(quán)限，但是只說發(fā)布它是毫無意義的，只有當(dāng)發(fā)布與新聞結(jié)合在一起才會產(chǎn)生真正的Privilege。Operator：操作。說明對What的How操作。Operator的定義包括了ResourceType和Method概念。即，What和How的概念。之所以將What和How綁定在一起作為一個Operator概念而不是分開建模再建立關(guān)聯(lián)，這是因?yàn)楹芏嗟腍ow對于某What才有意義。比方，發(fā)布操作對新聞對象才有意義，對用戶對象那么沒有意義。How本身的意義也有所不同，具體來說，對于每一個What可以定義N種操作。比方，對于合同這類對象，可以定義創(chuàng)立操作、提交操作、檢查沖突操作等?？梢哉J(rèn)為，How概念對應(yīng)于每一個商業(yè)方法。其中，與具體用戶身份相關(guān)的操作既可以定義在操作的業(yè)務(wù)邏輯之中，也可以定義在操作級別。比方，創(chuàng)立者的瀏覽視圖與普通用戶的瀏覽視圖要求內(nèi)容不同。既可以在外部定義兩個操作方法，也可以在一個操作方法的內(nèi)部根據(jù)具體邏輯進(jìn)行處理。具體應(yīng)用哪一種方式應(yīng)依據(jù)實(shí)際情況進(jìn)行處理。這樣的架構(gòu)，應(yīng)能在易于理解和管理的情況下，滿足絕大局部粗粒度權(quán)限控制的功能需要。但是除了粗粒度權(quán)限，系統(tǒng)中必然還會包括無數(shù)對具體Instance的細(xì)粒度權(quán)限。這些問題，被留給業(yè)務(wù)邏輯來解決，這樣的考慮基于以下兩點(diǎn)：一方面，細(xì)粒度的權(quán)限判斷必須要在資源上建模權(quán)限分配的支持信息才可能得以實(shí)現(xiàn)。比方，如果要求創(chuàng)立者和普通用戶看到不同的信息內(nèi)容，那么，資源本身應(yīng)該有其創(chuàng)立者的信息。另一方面，細(xì)粒度的權(quán)限常常具有相當(dāng)大的業(yè)務(wù)邏輯相關(guān)性。對不同的業(yè)務(wù)邏輯，常常意味著完全不同的權(quán)限判定原那么和策略。相比之下，粗粒度的權(quán)限更具通用性，將其實(shí)現(xiàn)為一個架構(gòu)，更有重用價值；而將細(xì)粒度的權(quán)限判斷實(shí)現(xiàn)為一個架構(gòu)級別的東西就顯得繁瑣，而且不是那么的有必要，用定制的代碼來實(shí)現(xiàn)就更簡潔，更靈活。所以細(xì)粒度控制應(yīng)該在底層解決，Resource在實(shí)例化的時候，必需指定Owner和GroupPrivilege。在對Resource進(jìn)行操作時也必然會確定約束類型：究竟是OwnerOK還是GroupOK還是AllOK。Group應(yīng)和Role嚴(yán)格別離，User和Group是多對多的關(guān)系，Group只用于對用戶分類，不包含任何Role的意義；Role只授予User，而不是Group。如果用戶需要還沒有的多種Privilege的組合，必須新增Role。Privilege必須能夠訪問Resource，同時帶User參數(shù)，這樣權(quán)限控制就完備了。Domain：為了授權(quán)更靈活，可以將Where或者Scope抽象出來，稱之為Domain，真正的授權(quán)是在Domain的范圍內(nèi)進(jìn)行，具體的Resource將分屬于不同的Domain。比方：一個新聞機(jī)構(gòu)有國內(nèi)與國外兩大分支，兩大分支內(nèi)又都有不同的資源〔體育類、生活類、時事政治類〕。假設(shè)所有國內(nèi)新聞的權(quán)限規(guī)那么都是一樣的，所有國外新聞的權(quán)限規(guī)那么也相同。那么可以建立兩個域，分別授權(quán)，然后只要將各類新聞與不同的域關(guān)聯(lián)，受域上的權(quán)限控制，從而使之簡化。正向授權(quán)與負(fù)向授權(quán)：正向授權(quán)在開始時假定主體沒有任何權(quán)限，然后根據(jù)需要授予權(quán)限，適合要求嚴(yán)格的系統(tǒng)。負(fù)向授權(quán)在開始時假定主體有所有權(quán)限，然后將某些特殊權(quán)限收回。2.3權(quán)限設(shè)計思想權(quán)限系統(tǒng)的核心由以下三局部構(gòu)成：創(chuàng)造權(quán)限-Creator創(chuàng)造，分配權(quán)限-Administrator分配，使用權(quán)限-User：1.Creator創(chuàng)造Privilege，Creator在設(shè)計和實(shí)現(xiàn)系統(tǒng)時會劃分，一個子系統(tǒng)或稱為模塊，應(yīng)該有哪些權(quán)限。這里完成的是Privilege與Resource的對象聲明，并沒有真正將Privilege與具體Resource實(shí)例聯(lián)系在一起，使之形成Operator。2.Administrator指定Privilege與ResourceInstance的關(guān)聯(lián)。在這一步，權(quán)限真正與資源實(shí)例聯(lián)系到了一起，產(chǎn)生了Operator〔PrivilegeInstance〕。Administrator利用Operator這個根本元素，來創(chuàng)造他理想中的權(quán)限模型。如，創(chuàng)立角色，創(chuàng)立用戶組，給用戶組分配用戶，將用戶組與角色關(guān)聯(lián)等等...這些操作都是由Administrator來完成的。3.User使用Administrator分配給的權(quán)限去使用各個子系統(tǒng)。Administrator是用戶，在他的心目中有一個比擬適合他管理和維護(hù)的權(quán)限模型。于是，程序員只要答復(fù)一個問題，就是什么權(quán)限可以訪問什么資源，也就是前面說的Operator。程序員提供Operator就意味著給系統(tǒng)穿上了盔甲。Administrator就可以按照他的意愿來建立他所希望的權(quán)限框架可以自行增加，刪除，管理Resource和Privilege之間關(guān)系?？梢宰孕性O(shè)定用戶User和角色Role的對應(yīng)關(guān)系。(如果將Creator看作是Basic的創(chuàng)造者，Administrator就是Basic的使用者，他可以做一些腳本式的編程)Operator是這個系統(tǒng)中最關(guān)鍵的局部，它是一個紐帶，一個系在Programmer，Administrator，User之間的紐帶。2.4權(quán)限設(shè)計例如A、建立角色功能并做分配1．如果現(xiàn)在要做一個員工管理的模塊(即Resources)，這個模塊有三個功能，分別是：增加，修改，刪除。給這三個功能各自分配一個ID，這個ID叫做功能代號：Emp_addEmp，Emp_deleteEmp，Emp_updateEmp2．建立一個角色(Role)，把上面的功能代碼加到這個角色擁有的權(quán)限中，并保存到數(shù)據(jù)庫中。角色包括系統(tǒng)管理員，測試人員等。3．建立一個員工的賬號，并把一種或幾種角色賦給這個員工。比方說這個員工既可以是公司管理人員，也可以是測試人員等。這樣他登錄到系統(tǒng)中將會只看到他擁有權(quán)限的那些模塊。B、把身份信息加到Session中登錄時，先到數(shù)據(jù)庫中查找是否存在這個員工，如果存在，再根據(jù)員工的sn查找員工的權(quán)限信息，把員工所有的權(quán)限信息都入到一個Hashmap中，比方就把上面的Emp_addEmp等放到這個Hashmap中。然后把Hashmap保存在一個UserInfoBean中。最后把這個UserInfoBean放到Session中，這樣在整個程序的運(yùn)行過程中，系統(tǒng)隨時都可以取得這個用戶的身份信息。C、根據(jù)用戶的權(quán)限做出不同的顯示可以比照當(dāng)前員工的權(quán)限和給這個菜單分配的"功能ID"判斷當(dāng)前用戶是否有翻開這個菜單的權(quán)限。例如：如果保存員工權(quán)限的Hashmap中沒有這三個ID的任何一個，那這個菜單就不會顯示，如果員工的Hashmap中有任何一個ID，那這個菜單都會顯示。對于一個新聞系統(tǒng)(Resouce)，假設(shè)它有這樣的功能(Privilege)：查看，發(fā)布，刪除，修改；假設(shè)對于刪除，有"新聞系統(tǒng)管理者只能刪除一月前發(fā)布的，而超級管理員可刪除所有的這樣的限制，這屬于業(yè)務(wù)邏輯(Businesslogic)，而不屬于用戶權(quán)限范圍。也就是說權(quán)限負(fù)責(zé)有沒有刪除的Permission，至于能刪除哪些內(nèi)容應(yīng)該根據(jù)UserRoleorUserGroup來決定(當(dāng)然給UserRoleorUserGroup分配權(quán)限時就應(yīng)該包含上面兩條業(yè)務(wù)邏輯)。一個用戶可以擁有多種角色，但同一時刻用戶只能用一種角色進(jìn)入系統(tǒng)〔？？？〕。角色的劃分方法可以根據(jù)實(shí)際情況劃分，按部門或機(jī)構(gòu)進(jìn)行劃分的，至于角色擁有多少權(quán)限，這就看系統(tǒng)管理員賦給他多少的權(quán)限了。用戶—角色—權(quán)限的關(guān)鍵是角色。用戶登錄時是以用戶和角色兩種屬性進(jìn)行登錄的〔因?yàn)橐粋€用戶可以擁有多種角色，但同一時刻只能扮演一種角色〕，根據(jù)角色得到用戶的權(quán)限，登錄后進(jìn)行初始化。這其中的技巧是同一時刻某一用戶只能用一種角色進(jìn)行登錄。針對不同的"角色"動態(tài)的建立不同的組，每個工程建立一個單獨(dú)的Group，對于新的工程，建立新的Group即可。在權(quán)限判斷局部，應(yīng)在商業(yè)方法上予以控制。比方：不同用戶的"操作能力"是不同的(粗粒度的控制應(yīng)能滿足要求)，不同用戶的"可視區(qū)域"是不同的(表達(dá)在對被操作的對象的權(quán)限數(shù)據(jù)，是否允許當(dāng)前用戶訪問，這需要對業(yè)務(wù)數(shù)據(jù)建模的時候考慮權(quán)限控制需要)。登陸：檢查員工是否存在登陸：檢查員工是否存在是根據(jù)員工sn查找員工權(quán)限信息根據(jù)用戶的權(quán)限做出不同的顯示2.5權(quán)限設(shè)計的擴(kuò)展的思路有了用戶/權(quán)限管理的根本框架，Who(User/Group)的概念是不會經(jīng)常需要擴(kuò)展的。變化的可能是系統(tǒng)中引入新的What(新的Resource類型)或者新的How(新的操作方式)。在三個根本概念中，僅在Permission上進(jìn)行擴(kuò)展是不夠的。這樣的設(shè)計中Permission實(shí)質(zhì)上解決了How的問題，即表示了"怎樣"的操作。那么這個"怎樣"是在哪一個層次上的定義呢？將Permission定義在"商業(yè)方法"級別比擬適宜。比方，發(fā)布、購置、取消。每一個商業(yè)方法可以意味著用戶進(jìn)行的一個"動作"。定義在商業(yè)邏輯的層次上，一方面保證了數(shù)據(jù)訪問代碼的"純潔性"，另一方面在功能上也是"足夠"的。也就是說，對更低層次，能自由的訪問數(shù)據(jù)，對更高層次，也能比擬精細(xì)的控制權(quán)限。確定了Permission定義的適宜層次，更進(jìn)一步，能夠發(fā)現(xiàn)Permission實(shí)際上還隱含了What的概念。也就是說，對于What的How操作才會是一個完整的Operator。比方，"發(fā)布"操作，隱含了"信息"的"發(fā)布"概念，而對于"商品"而言發(fā)布操作是沒有意義的。同樣的，"購置"操作，隱含了"商品"的"購置"概念。這里的綁定還表達(dá)在大量通用的同名的操作上，比方，需要區(qū)分"商品的刪除"與"信息的刪除"這兩個同名為"刪除"的不同操作。提供權(quán)限系統(tǒng)的擴(kuò)展能力是在Operator(Resource+Permission)的概念上進(jìn)行擴(kuò)展。Proxy模式是一個非常適宜的實(shí)現(xiàn)方式。實(shí)現(xiàn)大致如下：在業(yè)務(wù)邏輯層(EJBSessionFacade[StatefulSessionBean]中)，取得該商業(yè)方法的Methodname，再根據(jù)Classname和Methodname檢索Operator數(shù)據(jù)，然后依據(jù)這個Operator信息和Stateful中保存的User信息判斷當(dāng)前用戶是否具備該方法的操作權(quán)限。應(yīng)用在EJB模式下，可以定義一個很明確的Business層次，而一個Business可能意味著不同的視圖，當(dāng)多個視圖都對應(yīng)于一個業(yè)務(wù)邏輯的時候，比方，SwingClient以及JspClient訪問的是同一個EJB實(shí)現(xiàn)的Business。在Business層上應(yīng)用權(quán)限較能提供集中的控制能力。實(shí)際上，如果權(quán)限系統(tǒng)提供了查詢能力，那么會發(fā)現(xiàn)，在視圖層次已經(jīng)可以不去理解權(quán)限，它只需要根據(jù)查詢結(jié)果控制界面就可以了。2.5需要注意的幾個問題1、Group和Role，只是一種輔助實(shí)現(xiàn)的手段，不是必需的。如果系統(tǒng)的Role很多，逐個授權(quán)違背了"簡單，方便"的目的，那就引入Group，將權(quán)限相同的Role組成一個Group進(jìn)行集中授權(quán)。Role也一樣，是某一類Operator的集合，是為了簡化針對多個Operator的操作?！沧ⅲ豪鐔T工、財務(wù)員工、測試、管理員他們之間有很多共同的權(quán)限也有屬于自己的特殊的權(quán)限，此時可以將相同的權(quán)限規(guī)劃到一個組，不同的權(quán)限另外規(guī)劃組。其思想就是將通用的東西盡量集中管理并通過組的繼承的概念盡量簡化授權(quán)規(guī)劃。〕注：由于rbac只是提供一個授權(quán)模型，在實(shí)際應(yīng)用中很多人的設(shè)計都走了型只保存了概念而已，如果參考rbac的文檔會發(fā)現(xiàn)上述觀點(diǎn)也是一種混淆。個人觀點(diǎn)：對于角色不同但權(quán)限相同的情況也可以通過？？？？？？注：由于rbac只是提供一個授權(quán)模型，在實(shí)際應(yīng)用中很多人的設(shè)計都走了型只保存了概念而已，如果參考rbac的文檔會發(fā)現(xiàn)上述觀點(diǎn)也是一種混淆。個人觀點(diǎn)：對于角色不同但權(quán)限相同的情況也可以通過？？？？？？2、Role把具體的用戶和組從權(quán)限中解放出來。一個用戶可以承當(dāng)不同的角色，從而實(shí)現(xiàn)授權(quán)的靈活性。當(dāng)然，Group也可以實(shí)現(xiàn)類似的功能。但實(shí)際業(yè)務(wù)中，Group劃分多以行政組織結(jié)構(gòu)或業(yè)務(wù)功能劃分；如果為了權(quán)限管理強(qiáng)行將一個用戶參加不同的組，會導(dǎo)致管理的復(fù)雜性。3、權(quán)限系統(tǒng)還應(yīng)該考慮將功能性的授權(quán)與資源性的授權(quán)分開。很多系統(tǒng)都只有對系統(tǒng)中的數(shù)據(jù)〔資源〕的維護(hù)有權(quán)限控制，但沒有對系統(tǒng)功能的權(quán)限控制。4、權(quán)限系統(tǒng)最好是可以分層管理而不是集中管理。大多客戶希望不同的部門能且僅能管理其部門內(nèi)部的事務(wù)，而不是什么都需要一個集中的Administrator或Administrators組來管理。雖然你可以將不同部門的人都參加Administrators組，但他們的權(quán)限過大，可以管理整個系統(tǒng)資源而不是該部門資源。5、權(quán)限計算策略：系統(tǒng)中User，Group，Role都可以授權(quán)〔？？？前面說User只能通過組來和授權(quán)相聯(lián)系〕，權(quán)限可以有正負(fù)向之分，在計算用戶的凈權(quán)限時定義一套策略。系統(tǒng)中應(yīng)該有一個集中管理權(quán)限的AccessService，負(fù)責(zé)權(quán)限的維護(hù)〔業(yè)務(wù)管理員、平安管理模塊〕與使用〔最終用戶、各功能模塊〕，該AccessService在實(shí)現(xiàn)時要同時考慮一般權(quán)限與特殊權(quán)限。雖然在具體實(shí)現(xiàn)上可以有很多，比方用Proxy模式，但應(yīng)該使這些Proxy依賴于AccessService。各模塊功能中調(diào)用AccessService來檢查是否有相應(yīng)的權(quán)限。所以說，權(quán)限管理不是平安管理模塊自己一個人的事情，而是與系統(tǒng)各功能模塊都有關(guān)系。每個功能模塊的開發(fā)人員都應(yīng)該熟悉平安管理模塊，當(dāng)然，也要從業(yè)務(wù)上熟悉本模塊的平安規(guī)那么。RBAC〔Role-BasedAccessControl〕模型介紹3.1 RBAC開展歷史訪問控制技術(shù)是由美國國防部〔DepartmentofDefense,DoD〕資助的研究和開發(fā)成果演變而來的。這一研究導(dǎo)致兩種根本類型訪問控制的產(chǎn)生：自主訪問控制〔DiscretionaryAccessControl,DAC〕和強(qiáng)制訪問控制〔MandatoryAccessControl,MAC〕。〔兩者區(qū)別請參考附錄《an_introduction_to_rbac.pdf》〕它們最初的研究和應(yīng)用主要是為了防止機(jī)密信息被未經(jīng)授權(quán)者訪問，近期的應(yīng)用主要是把這些策略應(yīng)用到為商業(yè)領(lǐng)域。由于DAC和MAC的特殊背景，人們越來越發(fā)現(xiàn)在實(shí)際情況中并不適合商用，在1992年，由DavidFerraiolo和RickKuhn合作提出了RBAC〔Role-BasedAccessControl〕模型，在RBAC模型中，在用戶〔user〕和訪問權(quán)限〔permission〕之間引入了角色〔role〕的概念，用戶于特定的一個或多個角色相聯(lián)系，而角色與一個或多個訪問許可權(quán)相聯(lián)系，角色可以根據(jù)實(shí)際的工作需要生成或取消。由于RBAC在管理大型網(wǎng)絡(luò)應(yīng)用平安時所表現(xiàn)出的靈活性和經(jīng)濟(jì)性，使得RBAC迅速成為最具有影響的高級訪問控制模型。3.1 RBAC模型初探RBAC為了將人和權(quán)限解耦引入了ROLE的概念，整個RBAC參考模型都是圍繞Role來建立的。其根本思想是通過分配和取消角色來完成用戶權(quán)限的授予和取消，根據(jù)不同的職能崗位劃分角色，資源訪問許可被封裝在角色中，用戶通過賦予的角色間接地訪問系統(tǒng)資源和對系統(tǒng)資源可進(jìn)行的操作。授權(quán)者根據(jù)需要定義各種角色，并設(shè)置適宜的訪問權(quán)限，而部門或個人根據(jù)其工作性質(zhì)和職責(zé)再被指派為不同的角色，完成權(quán)限授予。這樣，整個訪問控制過程就分成兩個局部，即訪問權(quán)限與角色相關(guān)聯(lián)，角色再與部門或個人關(guān)聯(lián)，從而實(shí)現(xiàn)了部門或個人與訪問權(quán)限的邏輯別離。標(biāo)準(zhǔn)的RBAC模型由4個部件模型組成，下面分別介紹。A：模型1：CoreRBACCroeRBAC定義了5個根本元素集合〔USERS、ROLES、OBS、OPS、PRMS〕，RBAC模型的本質(zhì)其實(shí)就是基于這幾個根本集合的一系列關(guān)系〔如圖〕。包括：角色授權(quán)關(guān)系(PA)、用戶的角色授權(quán)關(guān)系(UA)和角色的層次關(guān)系(RH)等；一些函數(shù)，包括：會話到用戶的映射()、會話到角色集合的映射()等；以及一些相關(guān)約束。用戶(Users)：一個用戶被定義成一個人。雖然它的概念可以擴(kuò)展成一個機(jī)器、網(wǎng)絡(luò)、以及智能代理等，但我們?yōu)榱撕唵纹鹨?，在這個文檔中我們將用戶定義成一個人的概念。角色(Role)：在一個組織機(jī)構(gòu)的關(guān)系中，Role表示一個工作職責(zé)。如果將用戶指派到角色上，那么Role暗含關(guān)聯(lián)權(quán)限和職責(zé)的語義。權(quán)限(Permission)：一個許可，是對一個或多個Object執(zhí)行operation的許可?！操Y源客體objects〔OBS〕〕、操作〔operations〔OPS〕〕會話(Session)：會話在RBAC標(biāo)準(zhǔn)草案中似乎沒有給出具體定義，它跟web應(yīng)用中session的概念有些不同。根據(jù)標(biāo)準(zhǔn)發(fā)布的內(nèi)容可以看出session在rbac中是一個關(guān)系映射的概念。具體來說是一個user和一〔多〕個role之間關(guān)系的映射；在一個RBAC模型的系統(tǒng)中，每個用戶進(jìn)入系統(tǒng)得到自己的控制時，就得到了一個session。每個session是動態(tài)產(chǎn)生的，附屬于一個用戶。只要靜態(tài)定義過這些角色與該用戶的關(guān)系，會話根據(jù)用戶的要求負(fù)責(zé)將它所代表的用戶映射到多個角色中去。一個session可能激活的角色是用戶的全部角色的一個子集，對于用戶而言，在一個session內(nèi)可獲得全部被激活的角色所代表的訪問許可權(quán)。角色和會話的設(shè)置帶來的好處是容易實(shí)施最小特權(quán)原那么〔Least-PrivilegePrinciple〕。所謂最小特權(quán)原那么是將超級用戶的所有特權(quán)分解成一組細(xì)粒度的特權(quán)子集，定義成不同的“角色”，分別賦予不同的用戶，每個用戶僅擁有完成其工作所必須的最小特權(quán)，防止了超級用戶的誤操作或其身份被假冒后而產(chǎn)生的平安隱患。一個session只能關(guān)聯(lián)一個user，一個user可以關(guān)聯(lián)多個sessions；上面的圖例中有兩個函數(shù)：user_sessions給出了和用戶關(guān)聯(lián)的session集合；session_roles給出了rolesactivated〔激活的角色〕。session由用戶控制，允許動態(tài)激活/取消角色，實(shí)現(xiàn)最小特權(quán)。應(yīng)防止同時激活所有角色；session和user別離可以解決同一用戶多賬號帶來的問題，如審計、計賬等實(shí)現(xiàn)核心RBAC必須具備的功能管理方面的功能：增加及刪除使用者、增加及刪除角色、分配角色給使用者及移除原先分配給使用者的角色、分配權(quán)利給角色及移除原先分配給角色的權(quán)利系統(tǒng)支持方面的功能：產(chǎn)生或刪除一個會話期、在一個會話期參加或刪除角色，既能在一個會話期啟動或停止局部角色、檢查一個會話期是否具有某個權(quán)利。核查〔Review〕功能：查詢所有擁有某一角色的使用者、查詢一個使用者所擁有的全部角色。增強(qiáng)型核查功能：查詢一個角色所有的權(quán)利、查詢一個使用者所擁有的權(quán)利、查詢一個會話期所啟用的角色、查詢一個會話期所具有的權(quán)利、查詢一個角色對某一個物件所能行使的操作、查詢一個使用者對某一個物件所能行使的操作B：模型1：HierarchicalRBACHierarchicalRBAC在coreRBAC的根底上引入了角色繼承的概念。如下圖：Hierarchical是反映一個組織結(jié)構(gòu)層次的授權(quán)和責(zé)任的自然方式，它定義了角色的繼承關(guān)系。如：Roler1“繼承”Roler2,那么角色r2的權(quán)限同樣是r1的權(quán)限。相比擬coreRBAC，角色分層帶來的好處就是解決了重復(fù)授權(quán)的問題。例如：在沒有引入角色分層概念時，經(jīng)理和高級經(jīng)理的權(quán)限可能有80％都是重合的。這樣一來管理員具體實(shí)施時對角色授權(quán)的重復(fù)操作度就很高。而且隨著組織結(jié)構(gòu)層次復(fù)雜度的提高，這種授權(quán)操作的復(fù)雜度成線性增加；在引入了rolehierarchy后高級經(jīng)理自動獲取經(jīng)理的所有權(quán)限，然后管理員在分配其特有的權(quán)限即可。見過類似的公式推導(dǎo)，以一個全國性跨地區(qū)的公司，角色分層的實(shí)現(xiàn)和不實(shí)現(xiàn)相比其賦權(quán)的復(fù)雜度降低了約十倍。C：模型2：StaticSeparationofDutyRelationsSSD定義了一個用戶角色分配的約束關(guān)系，一個用戶不可能同時分配SSD中的兩個角色。它的作用就是防止了角色的沖突。舉個簡單的例子：在一個公司，一個員工不應(yīng)該既是會計又是出納〔注意：一個財務(wù)經(jīng)理，如果她既繼承了會計的角色又繼承了財務(wù)的角色。這種特殊的情況沒有很好的解決方法。應(yīng)盡力防止〕。在UserAssignment中引入SSD，這樣在系統(tǒng)初始化的時候，當(dāng)角色授權(quán)給用戶時來判斷是否將沖突的角色給了一個用戶。在StaticSeparationofDutyRelations模型中沖突的角色用一個二元關(guān)系定義，任何一個用戶只能擁有其中的一個角色。D：模型1：DynamicSeparationofDutyRelations動態(tài)別離的概念是指兩個或多個沖突的角色可以賦給一個用戶。它的特點(diǎn)不是在系統(tǒng)初始化時將責(zé)任進(jìn)行別離，而是在一個用戶會話過程進(jìn)行約束。雖然用戶可以同時啟用這兩種角色，但同一會話期只能選擇其一。一個RBAC模型的實(shí)現(xiàn)ACL〔AccessControlList〕介紹4.1ACL〔AccessControlList〕概述不好意思，查了N久也沒看到ACL名稱的歷史和起源。目前大家能看到ACL使用最多的地方根本都是在網(wǎng)絡(luò)平安配置和UNIX系統(tǒng)平安配置中。簡單的總結(jié)一下：所謂的ACL就是指訪問控制列表，是存儲在計算機(jī)中的一張表。它記錄了用戶和設(shè)備可以訪問哪些現(xiàn)有資源〔文件目錄、單個文件、數(shù)據(jù)等等〕，是用來保證系統(tǒng)平安性的一種手段。4.2 ACL在web應(yīng)用中描述1.Javaacl開始第一步是建立一個主體Principal，其中SecurityOwner是主體的擁有者：privatestaticfinalPrincipal_securityOwner=newPrincipalImpl("SecurityOwner");補(bǔ)上：主體的定義。主體表示一個實(shí)體，如單獨(dú)用戶或一個用戶組2.當(dāng)用戶login進(jìn)來時，他帶有兩個根本數(shù)據(jù)：訪問密碼和他要訪問的對象ApplicationName。首先驗(yàn)證用戶名和密碼，然后從數(shù)據(jù)庫中取出其權(quán)限數(shù)據(jù)，建立Permission,這里使用Feature繼承了Permission，在Feature中定義了有關(guān)權(quán)限的細(xì)節(jié)數(shù)據(jù)〔如讀寫刪〕。//取出用戶和被訪問對象之間的權(quán)限關(guān)系,這種權(quán)限關(guān)系可能不只一個，也就是說，用戶//可能對被訪問對象擁有讀寫刪等多個權(quán)限，將其打包在Hasbtable中。Hashtablefeatures=loadFeaturesForUser(sApplicationName,sUserID);3.創(chuàng)立一個用戶對象Useruser=newUserImpl(sUserID,newHashtable());4.為這個用戶創(chuàng)立一個活動的aclentryaddAclEntry(user,features);其中最關(guān)鍵的是第四步addAclEntry,我們看看其如何實(shí)現(xiàn)的：//為這個用戶創(chuàng)立一個新的AclentryAclEntrynewAclEntry=newAclEntryImpl(user);//遍歷Hashtablefeatures，將其中多種權(quán)限參加:feature=(Feature)hFeatures.get(keyName);newAclEntry.addPermission(feature);最后也要參加主體擁有者SecurityOwner，這樣一個平安體系就已經(jīng)建立完成。當(dāng)你在系統(tǒng)中要檢驗(yàn)?zāi)硞€用戶使用擁有某個權(quán)限，如讀的權(quán)利時，只要acl.checkPermission(user,feature)就可以,acl是ACL的一個實(shí)例，這樣權(quán)限檢查就交給java.security.acl.ACL去處理了。當(dāng)一個用戶login后，我們就要在內(nèi)存中為其建立相應(yīng)的授權(quán)訪問機(jī)制，使用java.security.acl可以很方便的建立這樣一個平安系統(tǒng)。An—introduction－to－rbac：7頁、Grbc中權(quán)限和group相連。實(shí)際上rbac也借鑒了gbac的概念，group和user都和組織機(jī)構(gòu)有關(guān)，但不是組織機(jī)構(gòu)。二者在概念上是不同的我個人理解group組一般按企業(yè)的組織結(jié)構(gòu)來，分部門。role角色一般按職能來，它是對組的細(xì)化和補(bǔ)充，role分為全局role和局部roleActor作為一個通用的接口與Role通訊。Role作為一個用戶與權(quán)限的代理層，解耦了權(quán)限和用戶的關(guān)系，所有的授權(quán)應(yīng)該給予Role而不是直接給User或Group。PrivilegeManager〔名字不好聽〕就是用來進(jìn)行R-P之間的關(guān)系操作的。例如getRoleByPrivilege()之類的。SecurityManager作為系統(tǒng)對外的接口，接受Actor,Resource,Operation作為參數(shù)，并判斷Actor中的Role是否有操作Privilege(Resource,Operation)的權(quán)限?！矀€人理解：這兩個函數(shù)的作用是：當(dāng)一個用戶做某些操作時，user_sessions給出了和這個用戶關(guān)聯(lián)的sessions，而session_roles又給出和用戶關(guān)聯(lián)的可用roles，這樣就完成了用戶和角色的關(guān)聯(lián)――暫時標(biāo)注〕增加代碼增加代碼id：mp_addEmp建立角色功能并做分配詳細(xì)步驟見jive手冊賬號2賬號1〔role〕管理員員工測試人員修改代碼id：建立角色功能并做分配詳細(xì)步驟見jive手冊賬號2賬號1〔role〕管理員員工測試人員修改代碼id：mp_updateEmp刪除代碼刪除代碼id：mp_deleteEmp把身份信息加把身份信息加進(jìn)Session中登陸：檢查員工是否存在登陸：檢查員工是否存在是根據(jù)員工sn查找員工權(quán)限信息根據(jù)用戶的權(quán)限做出不同的顯示比照當(dāng)前員工的權(quán)限和給這個菜單分配的“功能ID”比照當(dāng)前員工的權(quán)限和給這個菜單分配的“功能ID”判斷當(dāng)前用戶是否有翻開這個菜單的權(quán)限所有權(quán)限信息放到Hashmap中如上面的Emp_addEmp等然后把Hashmap保存在一個UserInfoBean中。最后把這個UserInfoBean放到Session中例如：如果保存員工權(quán)限的Hashmap中沒有這三個ID的任何一個，那這個菜單就不會顯示，如果員工的Hashmap中有任何一個ID，那這個菜單都會顯示。

對于一個新聞系統(tǒng)(Resouce)，假設(shè)它有這樣的功能(Privilege)：查看，發(fā)布，刪除，修改；假設(shè)對于刪除，有\(zhòng)"新聞系統(tǒng)管理者只能刪除一月前發(fā)布的，而超級管理員可刪除所有的這樣的限制，這屬于業(yè)務(wù)邏輯(Businesslogic)，而不屬于用戶權(quán)限范圍。也就是說權(quán)限負(fù)責(zé)有沒有刪除的Permission，至于能刪除哪些內(nèi)容應(yīng)該根據(jù)UserRoleorUserGroup來決定(當(dāng)然給UserRoleorUserGroup分配權(quán)限時就應(yīng)該包含上面兩條業(yè)務(wù)邏輯)。例如：如果保存員工權(quán)限的Hashmap中沒有這三個ID的任何一個，那這個菜單就不會顯示，如果員工的Hashmap中有任何一個ID，那這個菜單都會顯示。

對于一個新聞系統(tǒng)(Resouce)，假設(shè)它有這樣的功能(Privilege)：查看，發(fā)布，刪除，修改；假設(shè)對于刪除，有\(zhòng)"新聞系統(tǒng)管理者只能刪除一月前發(fā)布的，而超級管理員可刪除所有的這樣的限制，這屬于業(yè)務(wù)邏輯(Businesslogic)，而不屬于用戶權(quán)限范圍。也就是說權(quán)限負(fù)責(zé)有沒有刪除的Permission，至于能刪除哪些內(nèi)容應(yīng)該根據(jù)UserRoleorUserGroup來決定(當(dāng)然給UserRoleorUserGroup分配權(quán)限時就應(yīng)該包含上面兩條業(yè)務(wù)邏輯)。一個用戶可以擁有多種角色，但同一時刻用戶只能用一種角色進(jìn)入系統(tǒng)。角色的劃分方法可以根據(jù)實(shí)際情況劃分，按部門或機(jī)構(gòu)進(jìn)行劃分的，至于角色擁有多少權(quán)限，這就看系統(tǒng)管理員賦給他多少的權(quán)限了。用戶—角色—權(quán)限的關(guān)鍵是角色。用戶登錄時是以用戶和角色兩種屬性進(jìn)行登錄的〔因?yàn)橐粋€用戶可以擁有多種角色，但同一時刻只能扮演一種角色〕，根據(jù)角色得到用戶的權(quán)限，登錄后進(jìn)行初始化。這其中的技巧是同一時刻某一用戶只能用一種角色進(jìn)行登錄。

針對不同的“角色”動態(tài)的建立不同的組，每個工程建立一個單獨(dú)的Group，對于新的工程，建立新的Group即可。在權(quán)限判斷局部，應(yīng)在商業(yè)方法上予以控制。比方：不同用戶的“操作能力”是不同的(粗粒度的控制應(yīng)能滿足要求)，不同用戶的“可視區(qū)域”是不同的(表達(dá)在對被操作的對象的權(quán)限數(shù)據(jù)，是否允許當(dāng)前用戶訪問，這需要對業(yè)務(wù)數(shù)據(jù)建模的時候考慮權(quán)限控制需要)。另一個word文檔通用權(quán)限管理系統(tǒng)設(shè)計篇〔三〕——概要設(shè)計說明書在前兩篇文章中，不少朋友對我的設(shè)計提出了異議，認(rèn)為過于復(fù)雜，當(dāng)然在實(shí)際的各種系統(tǒng)的權(quán)限管理模塊中，并不像這里設(shè)計得那么復(fù)雜，我以前所做的系統(tǒng)中，由只有用戶和權(quán)限的，有只有用戶、權(quán)限和角色的，還有一個系統(tǒng)用到了用戶、權(quán)限、角色、組概念，這個系統(tǒng)是我在思考以前所做系統(tǒng)的權(quán)限管理局部中找到的一些共性而想到的一個設(shè)計方案，當(dāng)然還會有不少設(shè)計不到位的地方，在設(shè)計開發(fā)過程中會慢慢改良，這個系統(tǒng)權(quán)當(dāng)學(xué)習(xí)只用，各位朋友的好的建議我都會考慮到設(shè)計中，感謝各位朋友的支持。

今天抽時間整了一份概念設(shè)計出來，還有一些地方尚未考慮清楚，貼出1.0版，希望各位朋友提出珍貴建議。

大家也可以點(diǎn)擊此處《通用權(quán)限管理概要設(shè)計說明書》自行下載，這是1.0版本，有些地方可能還會進(jìn)行局部修改，有興趣的朋友請關(guān)注我的blog。

1.引言1.1編寫目的本文檔對通用權(quán)限管理系統(tǒng)的總體設(shè)計、接口設(shè)計、界面總體設(shè)計、數(shù)據(jù)結(jié)構(gòu)設(shè)計、系統(tǒng)出錯處理設(shè)計以及系統(tǒng)平安數(shù)據(jù)進(jìn)行了說明。1.2背景a、軟件系統(tǒng)的名稱：通用權(quán)限管理系統(tǒng)；b、任務(wù)提出者、開發(fā)者：謝星星；c、在J2EE的web系統(tǒng)中需要使用權(quán)限管理的系統(tǒng)。1.3術(shù)語本系統(tǒng)：通用權(quán)限管理系統(tǒng)；SSH：英文全稱是SecureShell。1.4預(yù)期讀者與閱讀建議預(yù)期讀者閱讀重點(diǎn)開發(fā)人員總體設(shè)計、接口設(shè)計、數(shù)據(jù)結(jié)構(gòu)設(shè)計、界面總體設(shè)計、系統(tǒng)出錯處理設(shè)計設(shè)計人員總體設(shè)計、接口設(shè)計、數(shù)據(jù)結(jié)構(gòu)設(shè)計、系統(tǒng)平安設(shè)計1.5參考資料《通用權(quán)限管理系統(tǒng)需求規(guī)格說明書》《通用權(quán)限管理系統(tǒng)數(shù)據(jù)庫設(shè)計說明書》2.總體設(shè)計2.1設(shè)計目標(biāo)權(quán)限系統(tǒng)一直以來是我們應(yīng)用系統(tǒng)不可缺少的一個局部，假設(shè)每個應(yīng)用系統(tǒng)都重新對系統(tǒng)的權(quán)限進(jìn)行設(shè)計，以滿足不同系統(tǒng)用戶的需求，將會浪費(fèi)我們不少珍貴時間，所以花時間來設(shè)計一個相對通用的權(quán)限系統(tǒng)是很有意義的。本系統(tǒng)的設(shè)計目標(biāo)是對應(yīng)用系統(tǒng)的所有資源進(jìn)行權(quán)限控制，比方應(yīng)用系統(tǒng)的功能菜單、各個界面的按鈕控件等進(jìn)行權(quán)限的操控。2.2運(yùn)行環(huán)境操作系統(tǒng)：Windows系統(tǒng)操作系統(tǒng)和Linux系列操作系統(tǒng)。2.3網(wǎng)絡(luò)結(jié)構(gòu)通用權(quán)限管理系統(tǒng)可采用JavaSwing實(shí)現(xiàn)，可以在桌面應(yīng)用和Web應(yīng)用系統(tǒng)中進(jìn)行調(diào)用。如果需要要適應(yīng)所有開發(fā)語言，可以將其API發(fā)布到WEBService上。暫時用JavaSwing實(shí)現(xiàn)。2.4總體設(shè)計思路和處理流程在說明總體設(shè)計思路前，我們先說明本系統(tǒng)的相關(guān)概念：1.權(quán)限資源系統(tǒng)的所有權(quán)限信息。權(quán)限具有上下級關(guān)系，是一個樹狀的結(jié)構(gòu)。下面來看一個例子系統(tǒng)管理用戶管理查看用戶新增用戶修改用戶刪除用戶對于上面的每個權(quán)限，又存在兩種情況，一個是只是可訪問，另一種是可授權(quán)，例如對于“查看用戶”這個權(quán)限，如果用戶只被授予“可訪問”，那么他就不能將他所具有的這個權(quán)限分配給其他人。2.用戶應(yīng)用系統(tǒng)的具體操作者，用戶可以自己擁有權(quán)限信息，可以歸屬于0～n個角色，可屬于0～n個組。他的權(quán)限集是自身具有的權(quán)限、所屬的各角色具有的權(quán)限、所屬的各組具有的權(quán)限的合集。它與權(quán)限、角色、組之間的關(guān)系都是n對n的關(guān)系。3.角色為了對許多擁有相似權(quán)限的用戶進(jìn)行分類管理，定義了角色的概念，例如系統(tǒng)管理員、管理員、用戶、訪客等角色。角色具有上下級關(guān)系，可以形成樹狀視圖，父級角色的權(quán)限是自身及它的所有子角色的權(quán)限的綜合。父級角色的用戶、父級角色的組同理可推。4.組為了更好地管理用戶，對用戶進(jìn)行分組歸類，簡稱為用戶分組。組也具有上下級關(guān)系，可以形成樹狀視圖。在實(shí)際情況中，我們知道，組也可以具有自己的角色信息、權(quán)限信息。這讓我想到我們的QQ用戶群，一個群可以有多個用戶，一個用戶也可以參加多個群。每個群具有自己的權(quán)限信息。例如查看群共享。QQ群也可以具有自己的角色信息，例如普通群、高級群等。針對如上提出的四種對象，我們可以整理得出它們之間的關(guān)系圖，如下所示：

總體設(shè)計思路是將系統(tǒng)分為組權(quán)限管理、角色權(quán)限管理、用戶權(quán)限管理、組織管理和操作日志管理五局部。其中組權(quán)限管理包括包含用戶、所屬角色、組權(quán)限資源和組總權(quán)限資源四局部，某個組的權(quán)限信息可用公式表示：組權(quán)限=所屬角色的權(quán)限合集+組自身的權(quán)限。角色權(quán)限管理包括包含用戶、包含組和角色權(quán)限三局部，某個角色的權(quán)限的計算公式為：角色權(quán)限=角色自身權(quán)限。用戶權(quán)限管理包括所屬角色、所屬組、用戶權(quán)限、用戶總權(quán)限資源和組織管理五局部。某個用戶總的權(quán)限信息存在如下計算公式：用戶權(quán)限=所屬角色權(quán)限合集+所屬組權(quán)限合集+用戶自身權(quán)限。組織管理即對用戶所屬的組織進(jìn)行管理，組織以樹形結(jié)構(gòu)展示，組織管理具有組織的增、刪、改、查功能。操作日志管理用于管理本系統(tǒng)的操作日志。注意：因?yàn)榻M和角色都具有上下級關(guān)系，所以下級的組或角色的權(quán)限只能在自己的直屬上級的權(quán)限中選擇，下級的組或者角色的總的權(quán)限都不能大于直屬上級的總權(quán)限。2.5模塊結(jié)構(gòu)設(shè)計本系統(tǒng)的具有的功能模塊結(jié)構(gòu)如下列圖所示：

2.6尚未解決的問題無。3.接口設(shè)計〔暫略〕3.1用戶接口〔暫略〕3.2外部接口〔暫略〕3.3內(nèi)部接口〔暫略〕4.界面總體設(shè)計本節(jié)將闡述用戶界面的實(shí)現(xiàn)，在此之前對頁面元素做如下約定：序號頁面元素約定1按鈕未選中時：[按鈕名稱]選中時：[按鈕名稱]2單項(xiàng)選擇框○選項(xiàng)3復(fù)選框□選項(xiàng)4下拉框

[選項(xiàng),…,]▽5文本框

|________|6TextArea

|…………|7頁簽未選中時：選項(xiàng)名稱

選中時：選項(xiàng)名稱8未選中鏈接鏈接文字9選中鏈接鏈接文字10說明信息說明信息4.1組權(quán)限管理包含用戶組信息

組1

組11

組12

組…

組2

組21

組22

組…

所選擇組：組1[包含用戶][所屬角色][組權(quán)限][總權(quán)限][修改]用戶名

姓名

號

最近登錄時間

登錄次數(shù)阿蜜果

謝星星

2007-10-8

66sterningxxx

2007-10-8

10

……當(dāng)用戶選擇“修改”按鈕時，彈出用戶列表，操作人可以通過勾選或取消勾選來修改該組所包含的用戶。所屬角色組信息

組1

組11

組12

組…

組2

組21

組22

組…

所選擇組：組1[包含用戶][所屬角色][組權(quán)限][總權(quán)限][修改]角色I(xiàn)D

角色名稱

角色描述1

訪客

--

2

初級用戶

--

當(dāng)用戶選擇“修改”按鈕時，彈出角色樹形結(jié)構(gòu)，操作人可以通過勾選或取消勾選來修改該組所屬的角色。組權(quán)限組信息

組1

組11

組12

組…

組2

組21

組22

組…

所選擇組：組1[包含用戶][所屬角色][組權(quán)限][總權(quán)限]

[保存][取消]總權(quán)限組信息

組1

組11

組12

組…

組2

組21

組22

組…

所選擇組：組1[包含用戶][所屬角色][組權(quán)限][總權(quán)限]

[保存][取消]通過對已具有的權(quán)限取消勾選，或?yàn)槟硻?quán)限添加勾選，來修改組的權(quán)限信息，點(diǎn)擊“保存”按鈕保存修改信息。組管理在下列圖中，選中組1的時候，右鍵點(diǎn)擊可彈出組的操作列表，包括添加、刪除和修改按鈕，從而完成在該組下添加子組，刪除該組以及修改該組的功能。組信息

組1

組11

組12

組…

組2

組21

組22

組…

所選擇組：組1[包含用戶][所屬角色][組權(quán)限][總權(quán)限][修改]用戶名

姓名

號

最近登錄時間

登錄次數(shù)阿蜜果

謝星星

2007-10-8

66sterningxxx

2007-10-8

10

……4.2角色權(quán)限管理包含用戶角色信息

角色1

角色11

角色12

角色…

角色2

角色21

角色22

角色…

所選擇角色：角色1[包含用戶][包含組][角色權(quán)限][修改]用戶名

姓名

號

最近登錄時間

登錄次數(shù)阿蜜果

謝星星

2007-10-8

66sterningxxx

2007-10-8

10

……當(dāng)用戶選擇“修改”按鈕時，彈出用戶列表，操作人可以通過勾選或取消勾選來修改該角色所包含的用戶。包含組角色信息

角色1

角色11

角色12

角色…

角色2

角色21

角色22

角色…

所選擇角色：角色1[包含用戶][包含組][角色權(quán)限][修改]組ID

組名稱

組描述1

xxx1

--2

xxx2

--

……當(dāng)用戶選擇“修改”按鈕時，彈出用戶列表，操作人可以通過勾選或取消勾選來修改該角色所包含的組。角色權(quán)限角色信息

角色1

角色11

角色12

角色…

角色2

角色21

角色22

角色…

所選擇角色：角色1[包含用戶][包含組][角色權(quán)限]

[保存][取消]通過對已具有的權(quán)限取消勾選，或?yàn)槟硻?quán)限添加勾選，來修改角色的權(quán)限信息，點(diǎn)擊“保存”按鈕保存修改信息。管理角色在下列圖中，選中組1的時候，右鍵點(diǎn)擊可彈出組的操作列表，包括添加、刪除和修改按鈕，從而完成在該組下添加子組，刪除該組以及修改該組的功能。角色信息

角色1

角色11

角色12

角色…

角色2

角色21

角色22

角色…

所選擇角色：角色1[包含用戶][包含組][角色權(quán)限][修改]用戶名

姓名

號

最近登錄時間

登錄次數(shù)阿蜜果

謝星星

2007-10-8

66sterningxxx

2007-10-8

10

……4.3用戶權(quán)限管理所屬角色用戶權(quán)限信息xx公司

廣州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…

所選擇用戶：阿蜜果[所屬角色][所屬組][用戶權(quán)限][總權(quán)限][修改]角色I(xiàn)D

角色名稱

角色描述1

訪客

--

2

初級用戶

--…當(dāng)用戶選擇“修改”按鈕時，彈出角色樹形結(jié)構(gòu)，操作人可以通過勾選或取消勾選來修改該用戶所屬的角色。所屬組用戶信息xx公司

廣州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…

所選擇用戶：阿蜜果[所屬角色][所屬組][用戶權(quán)限][總權(quán)限][修改]組ID

組名稱

組描述1

組1

--

2

組2

--…當(dāng)用戶選擇“修改”按鈕時，彈出組的樹形結(jié)構(gòu)，操作人可以通過勾選或取消勾選來修改該用戶所屬的組。用戶權(quán)限用戶信息xx公司

廣州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…

所選擇用戶：阿蜜果[所屬角色][所屬組][用戶權(quán)限][總權(quán)限]

[保存][取消]通過對已具有的權(quán)限取消勾選，或?yàn)槟硻?quán)限添加勾選，來修改用戶的權(quán)限信息，點(diǎn)擊“保存”按鈕保存修改信息?？倷?quán)限用戶信息xx公司

廣州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…

所選擇用戶：阿蜜果[所屬角色][所屬組][用戶權(quán)限][總權(quán)限]

[保存][取消]通過對已具有的權(quán)限取消勾選，或?yàn)槟硻?quán)限添加勾選，來修改用戶的權(quán)限信息，點(diǎn)擊“保存”按鈕保存修改信息。用戶管理中選擇了某用戶時，點(diǎn)擊右鍵，彈出菜單列表：修改、刪除、取消，點(diǎn)擊修改和刪除按鈕可以實(shí)現(xiàn)用戶的刪除和修改功能。選擇某個組織，例如下表中的“廣州分公司”，彈出菜單列表：添加子組織、刪除組織、修改組織、添加用戶、取消，點(diǎn)擊添加用戶按鈕可以實(shí)現(xiàn)用戶的添加功能。用戶權(quán)限信息xx公司

廣州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…

所選擇用戶：阿蜜果[所屬角色][所屬組][用戶權(quán)限][總權(quán)限][修改]角色I(xiàn)D

角色名稱

角色描述1

訪客

--

2

初級用戶

--…組織管理選擇某個組織，例如下表中的“廣州分公司”，彈出菜單列表：添加子組織、刪除組織、修改組織、添加用戶、取消，點(diǎn)擊添加子組織、刪除組織、修改組織按鈕可以實(shí)現(xiàn)組織的添加、刪除和修改功能。用戶權(quán)限信息xx公司

廣州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…

所選擇用戶：阿蜜果[所屬角色][所屬組][用戶權(quán)限][總權(quán)限][修改]角色I(xiàn)D

角色名稱

角色描述1

訪客

--

2

初級用戶

--…4.4操作日志管理查詢操作日志操作名稱：|________|

操作人：|________|操作時間從

|________|到|________|

[查詢][重置][刪除]編號

操作名稱

操作內(nèi)容

操作人

操作時間1

xx1

--

Amigo

2007-10-82

xx2

--

xxyy

2007-10-8…輸入上圖表單中的查詢信息后，點(diǎn)擊“查詢”按鈕，可查詢出符合條件的信息。刪除操作日志操作名稱：|________|

操作人：|________|操作時間從

|________|到|________|

[查詢][重置][刪除]編號

操作名稱

操作內(nèi)容

操作人

操作時間1

xx1

--

Amigo

2007-10-82

xx2

--

xxyy

2007-10-8…輸入上圖表單中的查詢信息后，點(diǎn)擊“查詢”按鈕，可查詢出符合條件的信息。而后點(diǎn)擊“刪除”按鈕，可刪除符合查詢條件的操作日志。5.數(shù)據(jù)結(jié)構(gòu)設(shè)計數(shù)據(jù)庫設(shè)計的模型請參見《通用權(quán)限管理系統(tǒng)_數(shù)據(jù)庫模型.pdm》。表的說明請參見《通用權(quán)限管理系統(tǒng)數(shù)據(jù)庫設(shè)計說明書》。5.1設(shè)計原那么命名的標(biāo)準(zhǔn)數(shù)據(jù)庫中表、主鍵、外鍵、索引的命名都以統(tǒng)一的規(guī)那么，采用大小寫敏感的形式，各種對象命名長度不要超過30個字符，這樣便于應(yīng)用系統(tǒng)適應(yīng)不同的數(shù)據(jù)庫平臺。數(shù)據(jù)的一致性和完整性為了保證數(shù)據(jù)庫的一致性和完整性，往往通過表間關(guān)聯(lián)的方式來盡可能的降低數(shù)據(jù)的冗余。表間關(guān)聯(lián)是一種強(qiáng)制性措施，建立后，對父表〔ParentTable〕和子表(ChildTable)的插入、更新、刪除操作均要占用系統(tǒng)的開銷。如果數(shù)據(jù)冗余低，數(shù)據(jù)的完整性容易得到保證，但增加了表間連接查詢的操作，為了提高系統(tǒng)的響應(yīng)時間，合理的數(shù)據(jù)冗余也是必要的。使用規(guī)那么〔Rule〕和約束〔Check〕來防止系統(tǒng)操作人員誤輸入造成數(shù)據(jù)的錯誤是設(shè)計人員的另一種常用手段，但是，不必要的規(guī)那么和約束也會占用系統(tǒng)的不必要開銷，需要注意的是，約束對數(shù)據(jù)的有效性驗(yàn)證要比規(guī)那么快。所有這些，需要在設(shè)計階段應(yīng)根據(jù)系統(tǒng)操作的類型、頻度加以均衡考慮。5.2數(shù)據(jù)庫環(huán)境說明數(shù)據(jù)庫：MySql5.0設(shè)計庫建模工具：PowerDesigner12.05.3數(shù)據(jù)庫命名規(guī)那么表名以T開頭，外鍵以FK開頭，索引以INDEX開頭。5.4邏輯結(jié)構(gòu)pdm文件的名稱為：《通用權(quán)限管理系統(tǒng)_數(shù)據(jù)庫模型》。5.5物理存儲通過數(shù)據(jù)庫建模工具PowerDesigner12可以將pdm導(dǎo)出為文本文件，將數(shù)據(jù)庫腳本放入文本文件中保存。5.6數(shù)據(jù)備份和恢復(fù)數(shù)據(jù)庫需定期備份〔每天備份一次〕，備份文件格式為backup_yyyyMMdd，數(shù)據(jù)庫被破壞時，利用最新的備份文件進(jìn)行恢復(fù)。6.系統(tǒng)出錯處理設(shè)計6.1出錯信息錯誤分類子項(xiàng)及其編碼錯誤名稱錯誤代碼備注數(shù)據(jù)庫錯誤連接連接超時100001001

連接斷開100001002

數(shù)據(jù)庫本身錯誤代碼數(shù)據(jù)庫本身錯誤代碼100002+數(shù)據(jù)庫錯誤代碼

TCP連接錯誤連接連接超時101001001

連接斷開101001002

其它TCP連接錯誤(socket自身錯誤代碼)

101002+socket錯誤代碼

配置信息錯誤未配置輸入?yún)?shù)

102001

未配置輸出參數(shù)

102002

組管理局部自定義錯誤

103001——103999

角色管理局部自定義錯誤

104001——104999

用戶管理局部自定義錯誤

105001——105999

操作日志管理

106001——106999

6.2補(bǔ)救措施為了當(dāng)某些故障發(fā)生時，對系統(tǒng)進(jìn)行及時的補(bǔ)救，提供如下補(bǔ)救措施：a．后備技術(shù)定期對數(shù)據(jù)庫信息進(jìn)行備份〔每天一次〕，當(dāng)數(shù)據(jù)庫因某種原因被破壞時，以最新的數(shù)據(jù)庫腳本進(jìn)行恢復(fù)；。7.系統(tǒng)平安設(shè)計7.1數(shù)據(jù)傳輸平安性設(shè)計SSH可以通過將聯(lián)機(jī)的封包加密的技術(shù)進(jìn)行資料的傳遞;使用SSH可以把傳輸?shù)乃袛?shù)據(jù)進(jìn)行加密，即使有人截獲到數(shù)據(jù)也無法得到有用的信息。同時數(shù)據(jù)經(jīng)過壓縮，大大地加快了傳輸?shù)乃俣?。通過SSH的使用，可以確保資料傳輸比擬平安并且傳輸效率較高。7.2應(yīng)用系統(tǒng)平安性設(shè)計操作人的操作信息需要提供操作記錄。對系統(tǒng)的異常信息需進(jìn)行記錄，已備以后查看。只有授權(quán)用戶才能登錄系統(tǒng)，對于某個操作，需要具有相應(yīng)權(quán)限才能進(jìn)行操作。7.3數(shù)據(jù)存儲平安性設(shè)計對于用戶的密碼等敏感信息采用MD5進(jìn)行加密。另一個文檔理清了對象關(guān)系之后，讓我們接著來進(jìn)行數(shù)據(jù)庫的設(shè)計。在數(shù)據(jù)庫建模時，對于N對N的關(guān)系，一般需要參加一個關(guān)聯(lián)表來表示關(guān)聯(lián)的兩者的關(guān)系。初步估計一下，本系統(tǒng)至少需要十張表，分別為：權(quán)限表、用戶表、角色表、組表、用戶權(quán)限關(guān)聯(lián)表、用戶角色關(guān)聯(lián)表、角色權(quán)限關(guān)聯(lián)表、組權(quán)限關(guān)聯(lián)表、組角色關(guān)聯(lián)表、用戶屬組關(guān)聯(lián)表。當(dāng)然還可能引出一些相關(guān)的表。下面讓我們在PowerDesigner中畫出各表吧。各表及其關(guān)系如下：1.用戶表用戶表〔TUser〕字段名稱字段類型備注記錄標(biāo)識tu_idbigintpk,notnull所屬組織to_idbigintfk,notnull登錄帳號login_namevarchar(64)notnull用戶密碼passwordvarchar(64)notnull用戶姓名vsernamevarchar(64)notnull號mobilevarchar(20)電子郵箱emailvarchar(64)創(chuàng)立時間gen_timedatetimenotnull登錄時間login_timedatetime上次登錄時間last_login_timedatetime登錄次數(shù)countbigintnotnull2.角色表角色表〔TRole〕字段名稱字段類型備注角色I(xiàn)Dtr_idbigintpk,notnull父級角色I(xiàn)Dparent_tr_idbigintnotnull角色名稱role_namevarchar(64)notnull創(chuàng)立時間gen_timedatetimenotnull角色描述descriptionvarchar(200)3.權(quán)限表權(quán)限表〔TRight〕字段名稱字段類型備注權(quán)限IDtr_idbigintpk,notnull父權(quán)限parent_tr_idbigintnotnull權(quán)限名稱right_namevarchar(64)notnull權(quán)限描述descriptionvarchar(200)4.組表組表〔TGroup〕字段名稱字段類型備注組IDtg_idbigintpk,notnull組名稱group_namevarchar(64)notnull父組parent_tg_idbigintnotnull創(chuàng)立時間gen_timedatetimenotnull組描述descriptionvarchar(200)5.角色權(quán)限表角色權(quán)限表〔TRoleRightRelation〕字段名稱字段類型備注記錄標(biāo)識trr_idbigintpk,notnull角色Role_idbigintfk,notnull權(quán)限r(nóng)ight_idbigintfk,notnull權(quán)限類型right_notnull〔0:可訪問，1:可授權(quán)〕6.組權(quán)限表組權(quán)限表〔TGroupRightRelation〕字段名稱字段類型備注記錄標(biāo)識tgr_idbigintpk,notnull組tg_idbigintfk,notnull權(quán)限tr_idbigintfk,notnull權(quán)限類型right_notnull〔0:可訪問，1:可授權(quán)〕7.組角色表組角色表〔TGroupRoleRelation〕字段名稱字段類型備注記錄標(biāo)識tgr_idbigintpk,notnull組tg_idbigintfk,notnull角色tr_idbigintpk,notnull8.用戶權(quán)限表用戶權(quán)限表〔TUserRightRelation〕字段名稱字段類型備注記錄標(biāo)識tur_idbigintpk,notnull用戶tu_idbigintfk,notnull權(quán)限tr_idbigintfk,notnull權(quán)限類型right_notnull〔0:可訪問，1:可授權(quán)〕9.用戶角色表用戶角色表〔TUserRoleRelation〕字段名稱字段類型備注記錄標(biāo)識tur_idbigintpk,notnull用戶tu_idbigintfk,notnull角色tr_idbigintfk,notnull10.用戶組表用戶組表〔TUserGroupRelation〕字段名稱字段類型備注記錄標(biāo)識tug_idbigintpk,notnull用戶tu_idbigintfk,notnull組tg_idbigintfk,notnull11.組織表組織表〔TOrganization〕字段名稱字段類型備注組織idto_idbigintpk,notnull父組parent_to_idbigintnotnull組織名稱org_namevarchar(64)notnull創(chuàng)立時間gen_timedatetimenotnull組織描述descriptionvarchar(200)12.操作日志表操作日志表〔TLog〕字段名稱字段類型備注日志IDlog_idbigintpk,notnull操作類型op_notnull操作內(nèi)容contentvarchar(200)notnull操作人tu_idbigintfk,notnull操作時間gen_timedatetimenotnull另一個文檔權(quán)限管理設(shè)計方案 andy加深理解::用戶是:某個人,角色:某個職位,權(quán)限是:添加,刪除,修改,查詢權(quán)力用戶和角色的關(guān)聯(lián):一個用戶可以有多個職位,一個職位可以有多個用戶角色和權(quán)限的關(guān)聯(lián):一個職位可以有多個權(quán)力一個權(quán)力可以是多個職位權(quán)限是被別離出去了的1設(shè)計思路為了設(shè)計一套具有較強(qiáng)可擴(kuò)展性的權(quán)限管理，需要建立用戶、角色和權(quán)限等數(shù)據(jù)庫表，并且建立之間的關(guān)系，具體實(shí)現(xiàn)如下。1.1用戶用戶僅僅是純粹的用戶，用來記錄用戶相關(guān)信息，如用戶名、密碼等，權(quán)限是被別離出去了的。用戶〔User〕要擁有對某種資源的權(quán)限，必須通過角色〔Role〕去關(guān)聯(lián)。用戶通常具有以下屬性：ü編號，在系統(tǒng)中唯一。ü名稱，在系統(tǒng)中唯一。ü用戶口令。ü注釋，描述用戶或角色的信息。1.2角色角色是使用權(quán)限的根本單位，擁有一定數(shù)量的權(quán)限，通過角色賦予用戶權(quán)限，通常具有以下屬性：ü編號，在系統(tǒng)中唯一。ü名稱，在系統(tǒng)中唯一(監(jiān)控人員)ü注釋，描述角色信息.(在線監(jiān)控人員)1.3權(quán)限權(quán)限指用戶根據(jù)角色獲得對程序某些功能的操作，例如對文件的讀、寫、修改和刪除功能，通常具有以下屬性：ü編號，在系統(tǒng)中唯一。ü名稱，在系統(tǒng)中唯一(添,刪,改,查)ü注釋，描述權(quán)限信息

.允許增加監(jiān)控對象1.4用戶與角色的關(guān)系一個用戶〔User〕可以隸屬于多個角色〔Role〕，一個角色組也可擁有多個用戶，用戶角色就是用來描述他們之間隸屬關(guān)系的對象。用戶〔User〕通過角色〔Role〕關(guān)聯(lián)所擁有對某種資源的權(quán)限，例如l用戶〔User〕：UserID

UserName

UserPwd1

張三

xxxxxx2

李四

xxxxxx

……l角色〔Role〕：RoleID(角色編號)

RoleName(角色名稱)

RoleNote(角色注釋)

01