權(quán)限管理設(shè)計(jì)說(shuō)明

1、對(duì)EMS權(quán)限管理模塊設(shè)計(jì)1.權(quán)限設(shè)計(jì)概述引言隨著亞6匕服務(wù)的復(fù)雜度增加以及用戶數(shù)量和種類(lèi)的增多，安全問(wèn)題在理論及工程上都 是一個(gè)必須考慮的問(wèn)題，而權(quán)限管理是安全問(wèn)題中一個(gè)很重要的方面。因此本文針對(duì)權(quán)限做 了 一個(gè)分析。權(quán)限可簡(jiǎn)單表述為這樣的邏輯表達(dá)式：判斷“Who對(duì)What(Which)進(jìn)行How的操作”的 邏輯表達(dá)式是否為真。意義用戶管理及權(quán)限管理一直是應(yīng)用系統(tǒng)中不可缺少的一個(gè)部分系統(tǒng)用戶很多，系統(tǒng)功能也很多不同用戶對(duì)系統(tǒng)功能的需求不同出于安全等考慮，關(guān)鍵的、重要的系統(tǒng)功能需限制部分用戶的使用出于方便性考慮，系統(tǒng)功能需要根據(jù)不同的用戶而定制目標(biāo)直觀，因?yàn)橄到y(tǒng)最終會(huì)由最終用戶來(lái)維護(hù)，權(quán)限分配的

2、直觀和容易理解，顯得比較重要， 除了功能的必須，更主要的就是因?yàn)樗銐蛑庇^。簡(jiǎn)單，包括概念數(shù)量上的簡(jiǎn)單和意義上的簡(jiǎn)單還有功能上的簡(jiǎn)單。想用一個(gè)權(quán)限系統(tǒng)解 決所有的權(quán)限問(wèn)題是不現(xiàn)實(shí)的。設(shè)計(jì)中將變化的“定制”特點(diǎn)比較強(qiáng)的部分判斷為業(yè)務(wù)邏輯， 而將相同的“通用”特點(diǎn)比較強(qiáng)的部分判斷為權(quán)限邏輯就是基于這樣的思路。擴(kuò)展，采用可繼承的方式解決了權(quán)限在擴(kuò)展上的困難。引進(jìn)Group概念在支持權(quán)限以組 方式定義的同時(shí)有效避免了權(quán)限的重復(fù)定義。2.基于角色的權(quán)限管理設(shè)計(jì)(Role-BasedAccessControl ,RBAC)2.1權(quán)限管理用例圖拜戶管期泵拚惶映管理前色智理聘用;系比就電箱堪苦理增州段直用戶儲(chǔ)

3、 息,分配刖色噌惻故直角色臉 息.摟于板限睡蝮首理員對(duì)搦有枚限附功能進(jìn)行捧作普述用戶2.2用例圖描述超級(jí)管理員：系統(tǒng)中默認(rèn)的角色，它是系統(tǒng)中擁有最高權(quán)限的角色，它不僅能夠管理其 他的管理員和用戶，而且還可以對(duì)系統(tǒng)中每個(gè)模塊的任一功能進(jìn)行操作、維護(hù)。普通管理員：它是由超級(jí)管理員創(chuàng)建的，并授予權(quán)限，它能夠管理系統(tǒng)部分的功能，它 可以查看所有普通管理員、普通用戶的信息，它只能對(duì)由它自己創(chuàng)建的用戶進(jìn)行編輯、刪除 操作，和管理?yè)碛袡?quán)限的模塊。普通用戶：它是系統(tǒng)中最低權(quán)限的角色，它只能對(duì)自己擁有的權(quán)限進(jìn)行操作，一般情況 下，它的權(quán)限是對(duì)信息的瀏覽和對(duì)自己信息的錄入，修改。登陸系統(tǒng)：根據(jù)用戶擁有的權(quán)限不同，

4、用戶所能操作的功能多少就不同，所以在登陸系 統(tǒng)的時(shí)候就要對(duì)用戶的權(quán)限進(jìn)行判斷。用戶管理：這里對(duì)本系統(tǒng)的登錄用戶進(jìn)行維護(hù)。包括，新建、刪除、編輯、注銷(xiāo)等；系 統(tǒng)初始化的時(shí)候，用戶管理中默認(rèn)只有一個(gè)擁有超級(jí)管理員角色的用戶，因此在初始化登陸 的時(shí)候，只能用這個(gè)用戶登陸，其他的用戶由這個(gè)用戶創(chuàng)建并授予角色。角色管理：角色是賦予系統(tǒng)用戶的職權(quán)名稱(chēng)。包括，新建、刪除、編輯、注銷(xiāo)等；系統(tǒng) 初始化的時(shí)候，角色管理中默認(rèn)只擁有一個(gè)超級(jí)管理員的角色，其他角色由擁有這個(gè)角色的 用戶創(chuàng)建并授權(quán)。其他模塊：其他模塊的每個(gè)功能都擁有一個(gè)唯一Id,根據(jù)用戶登陸的權(quán)限，再確定這 些功能是否對(duì)用戶開(kāi)放。3.權(quán)限設(shè)計(jì)思路基于角

5、色的訪問(wèn)控制RBACRBAC的主要思想是:權(quán)限（Permissions）是和角色（Roles）相聯(lián)系的，而用戶（Users） 則被指定到相應(yīng)的角色作為其成員。這樣就使權(quán)限的管理大大簡(jiǎn)化了。系統(tǒng)的權(quán)限控制主要是采用基于角色的訪問(wèn)控制,把權(quán)限綁定到角色上,當(dāng)用戶要操作 權(quán)限時(shí),就把角色賦給用戶。而且在需要撤回權(quán)限時(shí),只需把角色上的權(quán)限撤回就行了。思路為了設(shè)計(jì)一套具有較強(qiáng)可擴(kuò)展性的權(quán)限管理,需要建立用戶、角色和權(quán)限等數(shù)據(jù)庫(kù)表, 并且建立之間的關(guān)系,具體實(shí)現(xiàn)如下用戶用戶僅僅是純粹的用戶,用來(lái)記錄用戶相關(guān)信息,如用戶名、密碼等,權(quán)限是被分離 出去了的。用戶（User）要擁有對(duì)某種資源的權(quán)限，必須通過(guò)角色

6、（Role）去關(guān)聯(lián)。用戶 通常具有以下屬性：編號(hào),在系統(tǒng)中唯一。名稱(chēng),在系統(tǒng)中唯一。用戶口令。注釋,描述用戶或角色的信息。角色角色是使用權(quán)限的基本單位,擁有一定數(shù)量的權(quán)限,通過(guò)角色賦予用戶權(quán)限,通常具有 以下屬性：編號(hào),在系統(tǒng)中唯一。名稱(chēng),在系統(tǒng)中唯一 （監(jiān)控人員 ）注釋?zhuān)枋鼋巧畔?3（在線監(jiān)控人員）權(quán)限權(quán)限指用戶根據(jù)角色獲得對(duì)程序某些功能的操作，例如對(duì)文件的讀、寫(xiě)、修改和刪除功能，通常具有以下屬性：編號(hào)，在系統(tǒng)中唯一。名稱(chēng)，在系統(tǒng)中唯一3（添,刪,改,查）注釋?zhuān)枋鰴?quán)限信息 .3允許增加監(jiān)控對(duì)象用戶與角色的關(guān)系一個(gè)用戶（User）對(duì)應(yīng)一個(gè)角色（Role）,一j角色可以被多個(gè)用戶使用，用戶

7、角色 就是用來(lái)描述他們之間隸屬關(guān)系的對(duì)象。用戶（User）通過(guò)角色80良）關(guān)聯(lián)所擁有對(duì)某種 資源的權(quán)限，例如用戶（User）：UserIDUserNameUserPwdxxxxxx1三xxx2四xxx角色小。）：RoleID（角色編號(hào)）RoleName（角色名稱(chēng)）RoleNote（角色注釋?zhuān)?1員監(jiān)控系統(tǒng)維護(hù)管理員02員在線監(jiān)控人員03員調(diào)度工作人員04工作人員系統(tǒng)管理監(jiān)控人調(diào)度人一般工作人員用戶角色（User_Role）：UserRoleIDUserIDUserRoleNote（用戶角色注釋?zhuān)?02202員”RoleID1用戶“三”被分配到角色“監(jiān)控人員”2用戶“四”被分配到角色“監(jiān)控人從該

8、關(guān)系表可以看出，用戶所擁有的特定資源可以通過(guò)用戶角色來(lái)關(guān)聯(lián)。3.7 權(quán)限與角色的關(guān)系一個(gè)角色（Role）可以擁有多個(gè)權(quán)限（Permission）,同樣一個(gè)權(quán)限可分配給多個(gè)角 色。例如：角色（Role）：RoleUUID （角色 UUID）RoleName （角色名稱(chēng)）01 員02員03員04 工作人員RoleRemark（角色注釋?zhuān)┍O(jiān)控系統(tǒng)維護(hù)管理員在線監(jiān)控人員調(diào)度工作人員系統(tǒng)管理監(jiān)控人調(diào)度人一般工作人員權(quán)限(Privilege)：PrivilegeUUID (權(quán)限 UUID)PrivilegeName(權(quán)限名稱(chēng)）PrivilegeRemark（權(quán)限注釋?zhuān)?001控0002控0003控0004

9、息允許察看監(jiān)控對(duì)象增加監(jiān)允許增加監(jiān)控對(duì)象修改監(jiān)允許修改監(jiān)控對(duì)象刪除監(jiān)允許刪除監(jiān)控對(duì)象察看監(jiān)控信注釋?zhuān)?0001角色“系統(tǒng)管理員01”具有權(quán)限“增加監(jiān)控”20002角色“系統(tǒng)管理員01”具有權(quán)限“修改監(jiān)控”30003角色“系統(tǒng)管理員01”具有權(quán)限“刪除監(jiān)控”40004角色“系統(tǒng)管理員01”具有權(quán)限“察看監(jiān)控”50001角色“監(jiān)控人員”02具有權(quán)限“增加監(jiān)控”60004角色“監(jiān)控人員”02具有權(quán)限“察看監(jiān)控”角色權(quán)限(Role_ Privilege)：RolePermissionID RoleUUID PrivilegeUUID Role_PrivilegeRemark(角色權(quán)限由以上例子中的角色

10、權(quán)限關(guān)系可以看出，角色權(quán)限可以建立角色和權(quán)限之間的對(duì)應(yīng)關(guān)系。3.8 建立用戶權(quán)限用戶權(quán)限系統(tǒng)的核心由以下三部分構(gòu)成：創(chuàng)造權(quán)限、分配權(quán)限和使用權(quán)限。第一步由Creator創(chuàng)造權(quán)限(Permission), Creator在設(shè)計(jì)和實(shí)現(xiàn)系統(tǒng)時(shí)會(huì)劃分，指 定系統(tǒng)模塊具有哪些權(quán)限。第二步由系統(tǒng)管理員(Administrator)創(chuàng)建用戶和角色，并且指定用戶角色(User 一 Role)和角色權(quán)限(Role-Permission)的關(guān)聯(lián)關(guān)系。第三步用戶(User)登陸系統(tǒng)，對(duì)自己擁有的權(quán)限進(jìn)行管理、使用。4.權(quán)限的具體實(shí)現(xiàn)模式模式一：用戶-角色-權(quán)限(最通用的方法)4.1 數(shù)據(jù)庫(kù)結(jié)構(gòu)4.1.1用戶表：表名

11、：user_control_tab含義：用戶表字段 名稱(chēng)字段 類(lèi)型字段 長(zhǎng)度是否是 關(guān)鍵字是否為 空字段 含義字段 說(shuō)明idbigint8是否編號(hào)主鍵，自增uuidbinary16否UUID唯一role_uuidbinary16否角色UUID對(duì)應(yīng)角色表的UUIDuser_namevarchar16否用戶名只能是數(shù)字，字母，下劃線組成user_pwdvarchar16否密碼密碼的長(zhǎng)度在6-16個(gè)字符之間real_namevarchar6否真實(shí)要求填寫(xiě)用戶真實(shí)sexint2否性別0：男1：女phonebigint11否移動(dòng)用戶的手機(jī)emailvarchar100否用戶的remarkvarchar1

12、00是備注4.1.2角色表：表名：role_tab含義：角色表字段字段字段是否是是否為字段字段名稱(chēng)類(lèi)型長(zhǎng)度關(guān)鍵字空含義說(shuō)明idbigint8是否編號(hào)主鍵，自增uuidbinary16否UUID唯一role_namevarchar16否角色名稱(chēng)只能是數(shù)字，字母，下劃線組成remarkvarchar100備注4.1.3權(quán)限表：表名：privilege_tab含義：權(quán)限表字段 名稱(chēng)字段 類(lèi)型字段 長(zhǎng)度是否是 關(guān)鍵字是否 為空字段 含義字段 說(shuō)明idbigint8是否編號(hào)主鍵，自增uuidbinary16否UUID唯一pri_namevarchar16否權(quán)限名稱(chēng)只能是數(shù)字，字母，下劃線組成ext_id

13、varchar100否功能id頁(yè)面功能的id，唯一remarkvarchar100備注4.1.4角色權(quán)限表：表名：role_privilege_tab含義：角色權(quán)限表表字段 名稱(chēng)字段 類(lèi)型字段 長(zhǎng)度是否是 關(guān)鍵字是否 為空字段 含義字段 說(shuō)明idbigint8是否編號(hào)主鍵，自增role_uuidbinary16否角色UUID引用角色表的UUID，唯一pri_uuidbinary16否權(quán)限UUID引用權(quán)限表的UUID，唯一remarkvarchar100備注4.2在控制層寫(xiě)if/else判斷條件用戶登入系統(tǒng)后，就通過(guò)其角色加載所有可以訪問(wèn)的頁(yè)面，保存到 Session, 一直到 用戶退出系統(tǒng)或者

14、 session 過(guò)期。用戶訪問(wèn)頁(yè)面時(shí)，添加一個(gè) Dispatcher （ tape stry5 方式），在這個(gè) Dispatcher中解析出頁(yè)面地址如 /cs/deposit ，和用戶保存 在 Session 里的可訪問(wèn)頁(yè)面作比較，如果存在則繼續(xù)，不存在則跳到登入頁(yè)面。模式二：Ralasafe第三方組件（圖形界面的形式，簡(jiǎn)單易用）安裝、配置與使用手冊(cè)： 耦合，采用全景式、圖形化管理方式，無(wú)需大量Java和XML開(kāi)發(fā)配置。Ralasafe將權(quán)限分為兩大類(lèi)查詢(xún)權(quán)限：用戶從系統(tǒng)獲取數(shù)據(jù)，此時(shí)系統(tǒng)根據(jù)用戶不同，返回該用戶具有權(quán)限查詢(xún)的數(shù)據(jù) 決策權(quán)限：用戶向系統(tǒng)提交操作數(shù)據(jù)(如：修改、添加或者刪除某訂

15、單)，此時(shí)系統(tǒng)根據(jù)用 戶和被操作數(shù)據(jù)，判斷是否允許操作權(quán)限層級(jí)分為兩大類(lèi)功能級(jí)權(quán)限，又稱(chēng)操作權(quán)限，使用角色模型足夠數(shù)據(jù)級(jí)權(quán)限，支持?jǐn)?shù)據(jù)行級(jí)、列級(jí)，又稱(chēng)容權(quán)限，細(xì)粒度權(quán)限Ralasafe專(zhuān)注于數(shù)據(jù)級(jí)權(quán)限，使用策略機(jī)制進(jìn)行管理。Ralasafe也提供了功能級(jí)權(quán)限實(shí)現(xiàn)， 該功能可選，并不耦合。Ralasafe系統(tǒng)架構(gòu)安全引擎，該引擎解析授權(quán)策略，對(duì)所有訪問(wèn)進(jìn)行過(guò)濾。從2個(gè)方向進(jìn)行控制： 從系統(tǒng)獲取數(shù)據(jù)，比如查詢(xún)訂單，查詢(xún)客戶資料向系統(tǒng)提交數(shù)據(jù)，比如修改某訂單，刪除某客戶資料管理界面，通過(guò)管理界面皿管理員可以輕松管理、設(shè)計(jì)授權(quán)策略，并在線仿真測(cè)試。Ralasafe是服務(wù)，而不是框架。對(duì)應(yīng)用程序沒(méi)有要求

16、，也不需要修改業(yè)務(wù)數(shù)據(jù)庫(kù)。Ralasafe的結(jié)構(gòu)性數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)獨(dú)立保存在數(shù)據(jù)庫(kù)，非結(jié)構(gòu)性數(shù)據(jù)保存在文件系統(tǒng)，方 便移植。模式三：注解和攔截器實(shí)現(xiàn)權(quán)限通用模型的設(shè)計(jì)使用這種設(shè)計(jì)方案，可以很好地分離權(quán)限與系統(tǒng)本身的功能，讓開(kāi)發(fā)過(guò)程更加關(guān)注系 統(tǒng)的核心功能，同時(shí)可以很容易做到開(kāi)發(fā)時(shí)的任務(wù)劃分，同時(shí)使項(xiàng)目代碼的可讀性大大提 升。權(quán)限模型的常量定義：一個(gè)系統(tǒng)里最常見(jiàn)的需求莫過(guò)于權(quán)限、角色，我們需要兩個(gè)類(lèi)，一個(gè)表明都有什么權(quán)限(例 如：刪除帖子權(quán)限、編輯帖子權(quán)限，等等);另一個(gè)類(lèi)表明，各個(gè)角色都有什么權(quán)限。這樣 子相當(dāng)于定義了一個(gè)權(quán)限和角色模型。攔截器與注解：攔截器(Invocation)在在流行的開(kāi)源

17、框架中很常見(jiàn)，依賴(lài)的技術(shù)就是Java的動(dòng)態(tài)代理。 許多流行的框架都提供實(shí)現(xiàn)攔截器的接口，可以很簡(jiǎn)單就實(shí)現(xiàn)一個(gè)攔截器，此文不表如何實(shí) 現(xiàn)。注解(Annotations)是JAVA在5.0后引入的特性，它引入的目的是為了替代一些簡(jiǎn)單 的配置到j(luò)ava代碼里，而不用原來(lái)的xml。注解請(qǐng)求示例：一般的框架，都會(huì)有一個(gè)controller類(lèi)，以下用偽代碼表示：public class ThreadsControllerPriCheckRequired(MemberPrivilegeIdentity.CREATE_THREAD)public String createThread()return crea

18、teThread;如代碼中所示，一個(gè)controller里的一個(gè)method對(duì)應(yīng)一個(gè)URL請(qǐng)求(例中所示為創(chuàng)建帖子)。 我們只需要在其方法上標(biāo)注 PriCheckRequired(MemberPrivilegeIdentity.CREATE_THREA D)， PriCheckRequired 就是注解，其傳遞了 一個(gè)信息 MemberPrivilegeIdentity.CREATE_ THREAD，這也就是前文說(shuō)的權(quán)限類(lèi)中的創(chuàng)建帖子權(quán)限?？梢韵胂裨跀r截器里要做的事情： 攔截器一般都是實(shí)現(xiàn)一個(gè)框架提供的接口來(lái)實(shí)現(xiàn)，常用框架都支持。.根據(jù)規(guī)定好的request請(qǐng)求的參數(shù)，取到用戶屬于哪個(gè)角色。.

19、根據(jù)controller中注解，取到當(dāng)前要判斷的權(quán)限。.對(duì)比用戶角色是否有注解中的權(quán)限，如果有，放行，反之?dāng)r截。具體的實(shí)現(xiàn)過(guò)程：攔截器的代碼實(shí)現(xiàn)與框架有關(guān):rose框架如何實(shí)現(xiàn)攔截器請(qǐng)看 code.google./p/paoding-rose/wiki/Rose_Code_Fragment_Interceptor模式四：基于webwork和過(guò)濾器實(shí)現(xiàn)無(wú)代碼侵入的原子級(jí)界面權(quán)限修改webwork的基類(lèi)UIBean來(lái)實(shí)現(xiàn)頁(yè)面的權(quán)限控制：1、首先將頁(yè)面的權(quán)限定義保存到數(shù)據(jù)庫(kù)或xml的配置文件中；2、編寫(xiě)一個(gè)監(jiān)聽(tīng)器LoadPagePermissionListener來(lái)從權(quán)限的描述文件中，加載權(quán)限信息 到緩存；3、編寫(xiě)頁(yè)面權(quán)限過(guò)濾器，例如PagePermissionFilter，實(shí)現(xiàn)對(duì)頁(yè)面請(qǐng)求的過(guò)濾；4、當(dāng)用戶請(qǐng)求一個(gè)web表單時(shí)，首先通過(guò).action去請(qǐng)求，此時(shí).action被 PagePermissionFilter過(guò)濾器攔截到，此過(guò)濾器中從用戶所請(qǐng)求的web表單對(duì)應(yīng)的XML權(quán) 限描述文件或