【文章內(nèi)容簡(jiǎn)介】 模日益增大的基于 MVC 架構(gòu)的商務(wù)信息管理系統(tǒng)來(lái)說(shuō)，采用RBAC 訪問(wèn)控制模型的訪問(wèn)控制模塊將會(huì)起到越來(lái)越大的作用。綜上分析，控制訪問(wèn)角色的運(yùn)用是一種開(kāi)發(fā)和加強(qiáng)企業(yè)特殊安全策略，進(jìn)行安全管理過(guò)程流程化的有效手段。運(yùn)用 RBAC 模型可以很好的解決 Web 系統(tǒng)中提出的訪問(wèn)控制要求，而 DAC、MAC 等等訪問(wèn)控制技術(shù)由于各種各樣的局限性和特性，都不是 WEB 系統(tǒng)下實(shí)現(xiàn)訪問(wèn)控制的最好選擇。從目前的應(yīng)用現(xiàn)狀來(lái)看，以 MVC 為架構(gòu)而建成的 WEB 網(wǎng)站特別是商務(wù)網(wǎng)站的數(shù)量較為龐大，而由于其自身的管理特性，對(duì)安全措施的要求也越來(lái)越高，這就要求我們找到一種更為有效的權(quán)限管理方法去適應(yīng)網(wǎng)站對(duì)訪問(wèn)控制技術(shù)的要求。而 RBAC 作為一種科學(xué)、合理、靈活、成熟的訪問(wèn)控制技術(shù)，最適合于在WEB 環(huán)境下使用，所以如何使它應(yīng)用到那些基于 MVC 架構(gòu)的網(wǎng)站中去，會(huì)是一個(gè)具有相當(dāng)研究?jī)r(jià)值的課題。9第二章 系統(tǒng)框架分析與設(shè)計(jì) 基于 MVC架構(gòu)的 Web系統(tǒng)在當(dāng)前開(kāi)發(fā)的商務(wù)系統(tǒng)中，一般都會(huì)包括部門管理功能模塊，員工管理功能模塊，工程項(xiàng)目管理功能模塊和員工薪水管理功能模塊，以及包括針對(duì)員工使用的信息查看模塊。先下面給出一個(gè)已經(jīng)設(shè)計(jì)完善的基于 MVC 架構(gòu)的 WEB 網(wǎng)站，系統(tǒng)的功能模塊圖如圖 21 所示。系統(tǒng)的功能模塊部門管理模塊員工管理模塊工程項(xiàng)目管理模塊員工工資管理模塊信息查看模塊系統(tǒng)功能管理模塊系統(tǒng)用戶管理模塊系統(tǒng)角色管理模塊圖 21 系統(tǒng)功能模塊圖部門管理模塊：針對(duì)公司內(nèi)部的所有的部門進(jìn)行管理，用戶可以方便地添加部門、修改部門信息、刪除某一部門和查詢某一部門的信息。員工管理模塊：針對(duì)公司內(nèi)部的所有的員工進(jìn)行管理，用戶可以方便地添加員工信息、修改員工信息、刪除某一員工信息和查詢某一部門的所有員工信息。工程項(xiàng)目管理模塊：針對(duì)公司的工程項(xiàng)目進(jìn)行管理，用戶可以方便地添加工程項(xiàng)目信息、修改某一工程項(xiàng)目的信息、刪除某工程項(xiàng)目的信息和查詢某一工程項(xiàng)目信息。員工工資管理模塊：針對(duì)公司內(nèi)部的所有的員工的薪酬進(jìn)行管理，用戶可以方便地添加工資信息、修改工資信息、刪除工資信息和查詢某一員工在某段時(shí)間內(nèi)的所有工資信息。信息查看模塊：針對(duì)公司員工設(shè)計(jì)的功能模塊，通過(guò)該模塊員工可以方便10的查看自己的基本信息，工資信息以及所負(fù)責(zé)的工程項(xiàng)目信息。系統(tǒng)功能管理模塊：用戶可以通過(guò)該模塊管理系統(tǒng)中涉及到的所有功能，可以添加、刪除和修改。系統(tǒng)用戶管理模塊：用戶可以通過(guò)該模塊管理系統(tǒng)中涉及到的所有用戶，可以添加、刪除和修改。系統(tǒng)角色管理模塊：用戶可以通過(guò)該模塊為系統(tǒng)中的不同的用戶設(shè)置不同的權(quán)限，并能夠修改某一用戶所賦予的權(quán)限。在上述的商務(wù)系統(tǒng)中，在安全性上一般會(huì)有如下的要求：能夠很好的實(shí)現(xiàn)訪問(wèn)控制。在一個(gè)企業(yè)中，存在著很多種不同的用戶，如經(jīng)理、董事長(zhǎng)、一般職工，系統(tǒng)維護(hù)人員等。當(dāng)所有的用戶面對(duì)同一個(gè)系統(tǒng)時(shí)，就應(yīng)該做到用戶之間要有區(qū)分，即進(jìn)入系統(tǒng)后不同的用戶只能實(shí)行自身?yè)碛械臋?quán)限，不可以越權(quán)。部分信息的保密。公司中存在著一些決定企業(yè)利益的信息，這些信息只能由公司的管理人員來(lái)查看和管理，任何非法的侵入都有可能造成不良的后果?，F(xiàn)代主流的 Web 系統(tǒng)的體系架構(gòu)設(shè)計(jì)基于 J2EE 平臺(tái)上的 MVC 設(shè)計(jì)模式，應(yīng)用 Struts 框架，采用 B/S 模式，具體的架構(gòu)設(shè)計(jì)如圖 22 所示。ActionActionActionHTMLJSPs Struts Tags(JSTL)Style SheetActionServletRequestProcessorWeb ContainerController ModelPresentationLayerHttp ResponseHttp RequestBusinessManagement_MessagerResources.propertiesViewJavaBeanBusinessObjectsDatabase LayerBusiness LayerClientLayer圖 22 商務(wù)管理系統(tǒng)架構(gòu)圖在圖 22 中，系統(tǒng)架構(gòu)可以細(xì)分為以下 4 個(gè)層次：客戶層（Client Layer）：運(yùn)行在用戶機(jī)器的瀏覽器中，處理與用戶的交互。表現(xiàn)層（Presentation Layer）：運(yùn)行在 J2EE Web 容器中，產(chǎn)生系統(tǒng)的表現(xiàn)邏輯，處理用戶的請(qǐng)求并做出響應(yīng)；整個(gè) Web 層建立在 Struts 框架基礎(chǔ)上，其中 View 由 HTML 和 JSP 頁(yè)面組成，其數(shù)據(jù)表示是 ActionForm Oracle 9iBrowser11Bean；Controller 由 ActionServlet 組合 和 Action 類組成；而 Model 則交由業(yè)務(wù)邏輯層來(lái)實(shí)現(xiàn)。業(yè)務(wù)邏輯層（Business Layer）：運(yùn)行在 J2EE Web 容器中，完成系統(tǒng)的業(yè)務(wù)需求，為 Web 層提供所需的業(yè)務(wù)方法，由 JavaBean 構(gòu)成系統(tǒng)的 Business Objects（BO） ，并使用 DAO 模式把數(shù)據(jù)訪問(wèn)封裝起來(lái)，以供在其他應(yīng)用層中統(tǒng)一調(diào)用。數(shù)據(jù)源層（Database Layer）：即數(shù)據(jù)庫(kù)層，存放系統(tǒng)的應(yīng)用數(shù)據(jù)，系統(tǒng)采用 Oracle9i 作為數(shù)據(jù)庫(kù)服務(wù)器。系統(tǒng)的架構(gòu)可以表示為 JSP+Struts+Database。使用這種架構(gòu)一方面便于系統(tǒng)的開(kāi)發(fā)和管理；另一方面，層與層之間的開(kāi)發(fā)幾乎是完全獨(dú)立的，從而降低了數(shù)據(jù)在各層之間的耦合性，提高了系統(tǒng)的可維護(hù)性和可擴(kuò)展性。此外，系統(tǒng)是由 Java 來(lái)開(kāi)發(fā)實(shí)現(xiàn)的，Java 的跨平臺(tái)特性實(shí)現(xiàn)了系統(tǒng)的可移植性。 RBAC模型的建立根據(jù)上述商務(wù)系統(tǒng)對(duì)安全性的需求，通過(guò)在 Web 系統(tǒng)中使用 RBAC 模型可以很好的滿足各項(xiàng)需求。RBAC 的核心思想就是：根據(jù)用戶需求，給用戶分派各種角色，為不同的角色分配各種權(quán)限，用戶通過(guò)自己所屬的角色獲得操作權(quán)限許可。其核心模型如圖 23 所示。圖 23 RBAC 模型核心 RBAC 模型的組成部分是：Users：用戶集{u1，u2，u3…… ，un}；Roles：角色集{r1，r2，r3，…… ，rn}；OPS：操作集{op1，op2，op3，……，opn}12OBJ：客體集{obj1，obj2，obj3，……，objn}P= OPS X 0BJ：權(quán)限集是不同客體上不同操作的描述{pl，p2，p3，.? ，pn} RolesUsrA*?：用戶—角色分配關(guān)系：多對(duì)多；Assignedusers： ，角色與用戶的映射，將一個(gè)角色與一組用戶相映射；：權(quán)限角色分配關(guān)系，多對(duì)多；Assigned privileges ： ，角色與權(quán)限的映射，將一個(gè)角色與一組權(quán)限相映射；Session ：會(huì)話集{s1，s2，s3，……，sn }User_sessions ： ，用戶與會(huì)話的映射，將一個(gè)用戶與一個(gè)會(huì)話相映射；Session_roles ： ，會(huì)話與角色的映射，將一個(gè)會(huì)話與一組角色相映射；Avail_session_privilege ： ，在一次會(huì)話中一個(gè)用戶允許的權(quán)限；用戶：不僅指人，也可以指機(jī)器，網(wǎng)絡(luò)或智能代理。角色：管理員依據(jù)安全策略劃分出來(lái)的操作集合，表示該角色成員所授予的職權(quán)和責(zé)任?？腕w：指系統(tǒng)需要保護(hù)的資源。權(quán)限：對(duì)系統(tǒng)中的客體進(jìn)行特定存取的許可。權(quán)限是與客體緊密相關(guān)的，不同的系統(tǒng)，其權(quán)限規(guī)定是不同的，既可以指網(wǎng)絡(luò)的應(yīng)用，如對(duì)某個(gè)子網(wǎng)的訪問(wèn)權(quán)限，也可以指對(duì)數(shù)據(jù)庫(kù)的表單等的訪問(wèn)。權(quán)限的粒度大小取決于實(shí)際系統(tǒng)的定義。會(huì)話：為了對(duì)系統(tǒng)資源進(jìn)行操作，用戶需要建立會(huì)話，每個(gè)會(huì)話將一個(gè)用戶與他所對(duì)應(yīng)的角色集中的一部分建立映射關(guān)系，這一角色子集成為被會(huì)話激活的角色，在這次會(huì)話中，用戶可以執(zhí)行的操作就是該會(huì)話激活的角色對(duì)應(yīng)的權(quán)限所允許的操作。上述 RBAC 模型是 RBAC 核心模型，此模型保留了 RBAC 的最小特征集，是每個(gè) RBAC 系統(tǒng)都需要的元素。13 RBAC模型在 MVC網(wǎng)站中的應(yīng)用由需求分析可知，需要為企業(yè)內(nèi)部網(wǎng)管理系統(tǒng)設(shè)計(jì)一個(gè)用戶權(quán)限管理的功能模塊，從而達(dá)到對(duì)用戶權(quán)限進(jìn)行管理的目的。當(dāng)今的大型的信息管理系統(tǒng)都具有功能復(fù)雜，用戶眾多的特點(diǎn)，如果仍采用傳統(tǒng)的權(quán)限管理方式，直接將權(quán)限分配給用戶，對(duì)具有相同權(quán)限的一類用戶同樣的授權(quán)操作將被重復(fù)很多遍，一旦用戶工作崗位有變化，則對(duì)其權(quán)限的調(diào)整將非常復(fù)雜，而基于 RBAC 模型的權(quán)限控制方法則大大簡(jiǎn)化了這種授權(quán)管理的復(fù)雜度，降低了系統(tǒng)管理的開(kāi)銷。RBAC 模型描述了一種良好的訪問(wèn)控制方法和原理。通過(guò)在商務(wù) Web 系統(tǒng)中使用 RBAC 模型可以方便、科學(xué)、合理地進(jìn)行訪問(wèn)控制，有了良好的訪問(wèn)控制，不同的用戶在使用系統(tǒng)的時(shí)候僅能訪問(wèn)自身被賦予的權(quán)限，用戶之間不能越權(quán)訪問(wèn)，從而保證了信息的安全性和一致性，從而提高了系統(tǒng)的安全性。通過(guò)以下幾個(gè)步驟，可以將 RBAC 模型應(yīng)用在 MVC 網(wǎng)站中。（1）建立功能的概念。功能，即操作。在系統(tǒng)中，如對(duì)員工的添加、刪除和修改的操作，都可以描述為一個(gè)功能。（2）建立權(quán)限節(jié)點(diǎn)的概念。權(quán)限節(jié)點(diǎn)，顧名思義，它對(duì)應(yīng)著一個(gè)或一組功能操作菜單，表示了該節(jié)點(diǎn)可以進(jìn)行系統(tǒng)操作的范圍。（3）建立角色的概念。將角色與節(jié)點(diǎn)對(duì)應(yīng)起來(lái)，一個(gè)角色可以對(duì)應(yīng)多個(gè)節(jié)點(diǎn)，一個(gè)節(jié)點(diǎn)也可以對(duì)應(yīng)多個(gè)角色，這是一個(gè)多對(duì)多的關(guān)系。角色與節(jié)點(diǎn)對(duì)應(yīng)好之后，也就意味著角色與某一個(gè)或某一組功能操作菜單建立了關(guān)聯(lián)。系統(tǒng)中存在不同類型的用戶，也即不同的用戶隸屬于不同的角色。（4）將系統(tǒng)的用戶和角色關(guān)聯(lián)起來(lái)。一旦一個(gè)用戶被設(shè)置了某個(gè)角色，那么也就意味著該用戶具有了某些權(quán)限。具有了某些權(quán)限，也就意味著擁有了某些功能（對(duì)系統(tǒng)的操作和管理） 。舉例來(lái)說(shuō)，假設(shè)系統(tǒng)中存在兩個(gè)權(quán)限節(jié)點(diǎn) 1 和 2，兩個(gè)角色 A 和 B，用戶有甲（經(jīng)理）和乙（部門經(jīng)理） ，很顯然甲和乙在登陸系統(tǒng)后應(yīng)該具有不同的權(quán)限，甲可以管理整個(gè)公司的信息，而乙僅能管理所在部門的信息。這時(shí)，設(shè)定權(quán)限節(jié)點(diǎn) 1 下包含了管理整個(gè)公司信息的所有功能，權(quán)限節(jié)點(diǎn) 2 下包含了管理某個(gè)部門信息的所有功能；將角色 A 與節(jié)點(diǎn) 1 進(jìn)行關(guān)聯(lián)，將角色 B 與節(jié)點(diǎn) 2 進(jìn)行關(guān)聯(lián)。最后，將用戶甲的角色設(shè)定為角色 A，用戶乙的角色設(shè)定為角色 B。在用戶甲和乙登陸系統(tǒng)后，就會(huì)看到自己所具有的功能菜單，其他用戶的功能菜單是非可見(jiàn)的，從而實(shí)現(xiàn)了訪問(wèn)控制。簡(jiǎn)言之，通過(guò)在系統(tǒng)中設(shè)置功能、權(quán)限和角色的概念，就可以在系統(tǒng)中實(shí)現(xiàn) RBAC 模型，并讓它很好地為 Web 系統(tǒng)提供訪問(wèn)控制功能。14第三章 設(shè)計(jì)實(shí)現(xiàn) RBAC框架實(shí)現(xiàn)數(shù)據(jù)存儲(chǔ)是個(gè)非常重要的功能需求。系統(tǒng)中很多的地方都要存儲(chǔ)數(shù)據(jù)，并且其格式要求也不相同，數(shù)據(jù)量也差別較大。良好的設(shè)計(jì)不但能減少因數(shù)據(jù)保存不當(dāng)造成的對(duì)系統(tǒng)的損害，而且能顯著地提高系統(tǒng)的性能。在考慮數(shù)據(jù)存儲(chǔ)方案時(shí)，有三種可行的選擇，分別是文件方式、數(shù)據(jù)庫(kù)方式、LDAP 方式，這三種方式都有各自的優(yōu)缺點(diǎn)。文件方式的好處在于簡(jiǎn)單直觀，存取速度最快，但不夠安全，在 RBAC 的早期版本中，我們采用的就是文件方式。LDAP 方式可以保證數(shù)據(jù)的安全和完整性，但使用不方便，普及程度也不高；數(shù)據(jù)庫(kù)方式是業(yè)界比較認(rèn)可的主流存儲(chǔ)方案，而且現(xiàn)在的數(shù)據(jù)庫(kù)技術(shù)也比較成熟，是較為理想的選擇。有鑒于此，我們?cè)谙到y(tǒng)中采用了數(shù)據(jù)庫(kù)方式作為本系統(tǒng)數(shù)據(jù)存儲(chǔ)方案。以下為數(shù)據(jù)存儲(chǔ)的表結(jié)構(gòu)：P_YHB 用戶表用于記錄用戶基本信息。如表 31 所示。表 31 用戶表編號(hào) 列名 類型 長(zhǎng)度 說(shuō)明 約束1 *YHID VARCHAR 8 用戶 ID2 YHMC VARCHAR 20 用戶名稱3 YHMM VARCHAR 25 用戶密碼4 SSBM VARCHAR 5 用戶所屬部門5 YHMS VARCHAR 500 用戶描述P_JSB 角色表記錄和角色相關(guān)和信息。如表 32 所示。表 32 角色表編號(hào) 列名 類型 長(zhǎng)度 說(shuō)明 約束1 *JSID VARCHAR 5 角色 ID2 JSMC VARCHAR 50 角色名稱3 JSMS VARCHAR 200 角色描述 可為空154 JSXYHZDS NUMBER 10 此角色下的用戶最大數(shù) 可為空5 JSLX VARCHAR 1 角色類型P_YHJSB 用戶角色表用于記錄用戶角色指派的內(nèi)容，即記錄每個(gè)角色被賦予了哪些用戶。如表33 所示。表 33 用戶角色表編號(hào) 列名 類型 長(zhǎng)度 說(shuō)明 約束1 *YHID VARCHAR 8 用戶 ID 2 *JSID VARCHAR 5 角色 ID P_GNB 功能表存放權(quán)限，一條記錄就是一個(gè)權(quán)限，一個(gè)權(quán)限指的是一個(gè)用戶可以使用的一個(gè)功能項(xiàng)，在表中記錄了該權(quán)限對(duì)應(yīng)的主 URL。如表 34 所示。表 34 功能表編號(hào) 列名 類型 長(zhǎng)度 說(shuō)明 約束1 *GNID VARCHAR 5 功能 ID2 GNMC VARCHAR 50 功能名稱3 GNMS VARCHAR 500 功能描述 可為空4 ZURL VARCHAR 200 主 URL5CZ VARCHAR1操作（只讀、讀寫、執(zhí)行）P_JSJDB 角色節(jié)點(diǎn)表記錄權(quán)限角色指派的內(nèi)容，即記錄每個(gè)角