【正文】 測(cè)試方案 為了驗(yàn)證 RBAC 模型在具體系統(tǒng)中的訪問控制效果，進(jìn)行了如下的測(cè)試。 /** * 獲得用戶的權(quán)限樹 */ public ArrayList getUserTree(String userId) { ArrayList array = new ArrayList()； String sql = select p_jdb.* from (select * from ( select * 27 from p_yhjsb where yhid=39。 + yhid[i] + 39。 + )； try { Statement insert_stmt = (,READ_ONLY)； (sql)； b = true； ()； } catch (SQLException e) { ()； } return b； } ?? //其他業(yè)務(wù)函數(shù) } 系統(tǒng)權(quán)限模塊的實(shí)現(xiàn) 為了方便的進(jìn)行權(quán)限的設(shè)置和角色的管理，借助 SWT Designer（ Eclipse的一個(gè)插件，專門用來(lái)有界面的 Java 應(yīng)用程序）開發(fā)了一個(gè)專門用于管理權(quán)限節(jié)點(diǎn)和系統(tǒng)角色的應(yīng)用程序。,39。在相應(yīng)的 JavaBean 中，完成與數(shù)據(jù)庫(kù)的交互，實(shí)現(xiàn)對(duì)數(shù)據(jù)的添加。如表 310 所示。如表 36所示。如表 32 所示。良好的設(shè)計(jì)不但能減少因數(shù)據(jù)保存不當(dāng)造成的對(duì)系統(tǒng)的損害，而且能顯著地提高系統(tǒng)的性能。具有了某些權(quán)限，也就意味著擁有了某些功能（對(duì)系統(tǒng)的操作和管理）。 （ 2）建立權(quán)限節(jié)點(diǎn)的概念。 RBAC 模型在 MVC 網(wǎng)站中的應(yīng)用 由需求分析可知，需要為企業(yè)內(nèi)部網(wǎng)管理系統(tǒng)設(shè)計(jì)一個(gè)用戶權(quán)限管理的功能模塊，從而達(dá)到對(duì)用戶權(quán)限進(jìn)行管理的目的。 圖 23 RBAC 模型 核心 RBAC 模型的組成部分是： Users：用戶集 {u1， u2， u3?? ， un}； Roles：角色集 {r1， r2， r3，?? ， rn}； OPS：操作集 {op1， op2， op3，??， opn} OBJ：客體集 {obj1， obj2， obj3，??， objn} P= OPS X 0BJ：權(quán)限集是不同客體上不同操作的描述 {pl， p2， p3， .? ， pn} 12 R olesU sersUA *? ：用戶 — 角色分配關(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ò)或智能代理。 業(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ù)訪問封裝起來(lái)，以供在其他應(yīng)用層中統(tǒng)一調(diào)用。 在上述的商務(wù)系統(tǒng)中，在安全性上一般會(huì)有如下的要求： 能夠很好的實(shí)現(xiàn)訪問控制。 圖 21 系統(tǒng)功能模塊圖 部門管理模塊：針對(duì)公司內(nèi)部的所 有的部門進(jìn)行管理，用戶可以方便地添加部門、修改部門信息、刪除某一部門和查詢某一部門的信息。 RBAC 訪問控制模型實(shí)現(xiàn)了用戶與訪問權(quán)限的邏輯分離，減少了授權(quán)管理的復(fù)雜性，降低了管理開銷和管理的復(fù)雜度。在這樣的環(huán)境下，安全目標(biāo)支持產(chǎn)生于現(xiàn)有法律、道德規(guī)范、規(guī)章、或一般慣例的高端組織策略。強(qiáng)制訪問控制（ MAC）的主要特征是對(duì)所有主體及其所控制的客體（例如：進(jìn)程、文件、段、設(shè)備）實(shí)施強(qiáng)制訪問控制。 自主訪問控制，允許把訪問控制權(quán)的授予和取消留給個(gè)體用戶來(lái)判斷。 （ 3） MD5 加密技術(shù) MD5 的全稱是 MessageDigest Algorithm 5，當(dāng)用戶登錄的時(shí)候，系統(tǒng)把用戶輸入的密碼計(jì)算成 MD5 值，然后再去和保存在文件系統(tǒng)中的 MD5 值進(jìn)行比較，進(jìn)而確定輸入的密碼是否正確。在企業(yè)商務(wù) Web系統(tǒng)中利用 RBAC 模 型，可以簡(jiǎn)便、科學(xué)、清晰地進(jìn)行訪問控制，從而在一定程度上提高了整個(gè) Web 系統(tǒng)的安全性。 通過了解 RBAC模型的原理和 RBAC模型中對(duì)訪問控制的支持，我們可以看出，RBAC 模型可以很好的應(yīng)用于已有或?qū)⒁_發(fā)的企業(yè)商務(wù) Web 系統(tǒng)中。一般時(shí)間約束是指從 一個(gè)時(shí)間點(diǎn)持續(xù)到另一時(shí)間點(diǎn)之間可以訪問某個(gè)頁(yè)面，例如，企業(yè)商務(wù)系統(tǒng)中的商品招標(biāo)頁(yè)面，它在某一指定時(shí)間段內(nèi)開放，對(duì)這種約束可以在用戶訪問網(wǎng)頁(yè)的時(shí)候判斷訪問時(shí)間是否在允許范圍內(nèi)。 為更真實(shí)的描述現(xiàn)實(shí)， RBAC 模型還有許多的控制機(jī)制。 最小權(quán)限原則（ the Least Privilege Rule） 所謂最小權(quán)限原則是指：用戶所擁有的權(quán)力不能超過他執(zhí)行工作時(shí)所需的權(quán)限。用戶訪問的時(shí)候?qū)嶋H具有的角色只包含激活后的 角色，未激活的角色在訪問中不起作用。在應(yīng)用中，許可受到特定應(yīng)用 4 邏輯的限制。絕大多數(shù)基于角色的訪問控制研究都以這兩個(gè)模型作為出發(fā)點(diǎn)。只有在保證了安全性的前提下，功能的完整性和操作的簡(jiǎn)便性才變得有意義。通過訪問控制，一方面只有 合法的用戶才可以安全、正確的使用系統(tǒng)，非法的用戶是無(wú)法登陸系統(tǒng)進(jìn)行操作；的；另一方面合法的用戶登錄系統(tǒng)之后，由于用戶的類型不同，就會(huì)存在不用的用戶在訪問系統(tǒng)時(shí)具有不同的權(quán)限，比如一個(gè)企業(yè)或公司的經(jīng)理往往會(huì)比企業(yè)或公司的員工具有更多的權(quán)限和功能，相應(yīng)的用戶登錄系統(tǒng)之后，他們只能行使系統(tǒng)準(zhǔn)許他們的權(quán)限。 （ 3） 模型的可移植性。 2 第一章 課題背景 MVC 概述 由于 Inter 的普及和網(wǎng)絡(luò)技術(shù)的發(fā)展，大部分的企業(yè)或單位都擁有了自己的 Web 站點(diǎn)。 1 基于 MVC架構(gòu)的網(wǎng)站 RBAC 訪問控制框架設(shè)計(jì)與實(shí)現(xiàn) 畢業(yè)設(shè)計(jì)論文 2 摘 要 一個(gè)實(shí)際的商務(wù)網(wǎng)站系統(tǒng)除了需要關(guān)注于功能需求之外，還需要考慮很多非功能性需求，安全性就是其中一個(gè)非常重要的方面。通過 Inter 或 Intra，企業(yè)的管理變得更加方便；企業(yè)的信息發(fā)布變得更加便捷；企業(yè)的市場(chǎng)開拓變得更加簡(jiǎn)便。因?yàn)?模型是獨(dú)立于視圖的，所以可以把一個(gè)模型獨(dú)立地移植到新的平臺(tái)工作。 縱觀現(xiàn)在的 Web 系統(tǒng)，大都存在這樣的問題：功能雖強(qiáng)大，但是卻存在很多 3 的安全隱患。 RBAC 模型概述 RBAC原理簡(jiǎn)介 1992 年，美國(guó)國(guó)家標(biāo)準(zhǔn)與技術(shù)研究所（ NIST）的 David Ferraiolo 和 Rick Kuhn 在綜合了大量的實(shí)際研究之后，率先提出基于角色的訪問控制模型框架，并給出了 RBAC 模型的一種形式化定義。 在 RBAC 中，涉及到的基本概念如下： 用戶 （ User）：系統(tǒng)的使用者。 用戶指派（ User Assignment）：用戶與角色之間的關(guān)系是多對(duì)多的關(guān)系。相對(duì)于靜態(tài)的角色授權(quán)來(lái)說，角色激活是一種動(dòng)態(tài)的過程，提供了相當(dāng)?shù)撵`活性。實(shí)現(xiàn)最小權(quán)限原則，需分清用戶的工作內(nèi)容，確定執(zhí)行該項(xiàng)工作的最小權(quán)限集，然后將用戶限制在這些權(quán)限范圍之內(nèi)。如對(duì) Web 頁(yè)面多維度和細(xì)粒度控制，對(duì)角色、功能、節(jié)點(diǎn)的靜態(tài)限制和對(duì)角色的動(dòng)態(tài)限制。周期時(shí)間約束是指對(duì)那些功能和數(shù)據(jù)周期性開放的頁(yè)面進(jìn)行訪問控制。通過在系統(tǒng)中使用 RBAC 模型，可以 很好的解決如下的問題： 權(quán)限管理混亂的問題。 RBAC 在 MVC 中的應(yīng)用現(xiàn)狀 網(wǎng)站程序的安全是系統(tǒng)開發(fā)人員必須考慮的重要因素之一，因?yàn)檫@涉及到網(wǎng)站的建設(shè)者、網(wǎng)站用戶的諸多安全問題，如果不處理好，可能會(huì)給系統(tǒng)的使用者和管理者帶來(lái)嚴(yán)重問題。通過這樣的步驟，系統(tǒng)在并不知道用戶密碼的明碼的情況下就可以確定用戶登錄系統(tǒng)的合法性。為沒有訪問控制權(quán)的個(gè)體用戶授予和廢除許可。為這些主體及客體指定敏感標(biāo)記，這些標(biāo)記是等級(jí)分類和非等級(jí)類別的組合，它們是實(shí)施強(qiáng)制訪問控制的依據(jù)。這些環(huán)境通常需要控制個(gè)體行為的能力，而不僅僅是如何根據(jù)信息的敏感性為其設(shè)置標(biāo)簽從而訪問這一信息的個(gè)人能力。對(duì)于現(xiàn)在規(guī)模日益增大的基于 MVC 架構(gòu)的商務(wù)信息管理系統(tǒng)來(lái)說，采用 RBAC 訪問控制模型的訪問控制模塊將會(huì)起到越來(lái)越大的作用。 員工管理模塊：針對(duì)公司內(nèi)部的所有的員工進(jìn)行管理，用戶可以方便地添加員工信息、修改員工信息、刪除某一員工信息和查詢某一部門的所有員工信息。在一個(gè)企業(yè) 中，存在著很多種不同的用戶，如經(jīng)理、董事長(zhǎng)、一般職工，系統(tǒng)維護(hù)人員等。 數(shù)據(jù)源層（ Database Layer）：即數(shù)據(jù)庫(kù)層，存放系統(tǒng)的應(yīng)用數(shù)據(jù)，系統(tǒng)采用 Oracle9i 作為數(shù)據(jù)庫(kù)服務(wù)器。 角色：管理員依據(jù)安全策略劃分出來(lái)的操作集合，表示該角色 成員所授予的職權(quán)和責(zé)任。當(dāng)今的大型的信息管理系統(tǒng)都具有 13 功能復(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)管理的開銷。權(quán)限節(jié)點(diǎn)，顧名思義，它對(duì)應(yīng)著一個(gè) 或一組功能操作菜單，表示了該節(jié)點(diǎn)可以進(jìn)行系統(tǒng)操作的范圍。 舉例來(lái)說，假設(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ù)據(jù)存儲(chǔ)方案時(shí)，有三種可行的選擇，分別是文件方式、數(shù)據(jù)庫(kù)方式、 LDAP 方式，這三種方式都有各自的優(yōu)缺點(diǎn)。 表 32 角色表 編號(hào) 列名 類型 長(zhǎng)度 說明 約束 1 *JSID VARCHAR 5 角色 ID 2 JSMC VARCHAR 50 角色名稱 3 JSMS VARCHAR 200 角色描述 可為空 15 4 JSXYHZDS NUMBER 10 此角色下的用戶最大數(shù) 可為空 5 JSLX VARCHAR 1 角色類型 P_YHJSB 用戶角色表 用于記錄用戶角色指派的內(nèi)容，即記錄每個(gè)角色被賦予了哪些用戶。 表 36 節(jié)點(diǎn)表 編號(hào) 列名 類型 長(zhǎng)度 說明 約束 1 *JDID VARCHAR 5 節(jié)點(diǎn) ID 16 2. JDMC VARCHAR 50 節(jié)點(diǎn)名稱 3. FJDID VARCHAR 5 父節(jié)點(diǎn) ID 4 JDMS VARCHAR 500 節(jié)點(diǎn)描述 5 JDNXH VARCHAR 2 節(jié)點(diǎn)內(nèi)序號(hào) P_JDGNB 節(jié)點(diǎn)表 記錄每個(gè)節(jié)點(diǎn)所包含的權(quán)限信息。 表 310 企業(yè)員工工資 表 17 編號(hào) 列名 類型 長(zhǎng)度 說明 約束 1 *ID NUMBER 工資帳單序號(hào) 2 SALARY_NUM VARCHAR 10 工資帳單金額 3 WORKERBM VARCHAR 10 員工編號(hào) 4 SALARY_DATE DATE 工資帳單發(fā)放日期 1 P_WORKER 企業(yè)員工信息表 記錄每個(gè)企業(yè)員工的信息。 用到的 ActionForm 類是 GnoperatorForm 類，該類繼承 ActionForm 類，并具有 gnid,cz,ljxjd,gnmc,gnms,zurl 等屬性。139。具體的實(shí)現(xiàn)類如下所示。)； (sql)； } b = true； } catch (Exception e) { (e)； b = false； } return b； } /** * 刪除用戶角色 */ 26 public boolean deleteYhJs(String yhid, String jsid) { boolean b = false； String sql = delete p_yhjsb where yhid = 39。 + userId + 39。 （１）合法用戶的合法登陸 假定系統(tǒng)中存在公司經(jīng)理（為經(jīng)理設(shè)置了經(jīng)理的角色），某員工張三（為其設(shè)置了員工的角色）和系統(tǒng)的管理員（為其設(shè)置了系統(tǒng)管理員的角色），在他們輸入了正確的用戶名和用戶密碼后，將分別進(jìn)入如下圖所示的頁(yè)面。使用的后 臺(tái)數(shù)據(jù)庫(kù)服務(wù)器是 Oracle9i，提供了數(shù)據(jù)的安全性和穩(wěn)定性 。實(shí)現(xiàn)代碼如下。,39。139。+ zurl + 39。 為了完成最終的功能添加，在相應(yīng)的 Action 實(shí)現(xiàn)類中，還需要調(diào)用模型層中的業(yè)務(wù)功能函數(shù)，來(lái)完成此次的業(yè)務(wù)邏輯。 表 39 企業(yè)工程項(xiàng)目表