基于MVC架構的網站RBAC訪問控制框架設計與實現(xiàn)

1、基于基于 MVCMVC 架構的網站架構的網站 RBACRBAC 訪問訪問控制框架設計與控制框架設計與實現(xiàn)實現(xiàn)蘇州科技學院蘇州科技學院畢業(yè)設計論文畢業(yè)設計論文姓名：周霖欽姓名：周霖欽專業(yè)：計算機科學與技術專業(yè)：計算機科學與技術指導老師：陸指導老師：陸 悠悠摘摘要要一個實際的商務網站系統(tǒng)除了需要關注于功能需求之外，還需要考慮很多非功能性需求，安全性就是其中一個非常重要的方面。訪問控制是幾乎所有的應用系統(tǒng)都不可缺少的一部分。本文從 MVC 架構商務管理系統(tǒng)的需求出發(fā)，首先分析了幾種訪問控制的優(yōu)缺點，在此基礎上提出了利用 RBAC 模型來進行系統(tǒng)的訪問控制。并將其用于某一具體的商務系統(tǒng)中，給出了實現(xiàn)過

2、程。關鍵詞關鍵詞：MVC、RBAC、訪問控制、角色、權限。AbstractWhen functional requirements are chiefly paid attention to by people in a commercial application system, many nonfunctional requirements are also taken into account. Security is one of the most important aspects of the nonfunctional requirements. Access control a

3、lmost is a necessary part in all application systems. This paper analyses the requirements of comprehensive commercial information management system based on MVC. It analyses the merits and demerits among the common access controls, and proposes process access control based on RBAC model. Finally, i

4、t describes how to realize the model in a material commercial system.Key words： MVC，RBAC，Access Control， Role，Permission. 目錄引引言言 .1第一章第一章 課題背景課題背景 .21.1 MVC 概述.21.2 RBAC 模型概述.3原理簡介.3適用性分析.51.3 RBAC 在 MVC 中的應用現(xiàn)狀.6第二章第二章 系統(tǒng)框架分析與設計系統(tǒng)框架分析與設計 .92.1 基于 MVC 架構的 WEB系統(tǒng).92.2 RBAC 模型的建立.112.3 RBAC 模型在 MVC 網站中的

5、應用.12第三章第三章 設計實現(xiàn)設計實現(xiàn) .143.1 RBAC 框架實現(xiàn).143.2 RBAC 模型在系統(tǒng)中的實現(xiàn).17系統(tǒng)功能模塊的實現(xiàn).17系統(tǒng)權限模塊的實現(xiàn).21系統(tǒng)角色模塊的實現(xiàn).23為用戶設置角色.25用戶權限功能樹的生成.26第四章第四章 系統(tǒng)測試系統(tǒng)測試 .294.1 系統(tǒng)測試.29測試環(huán)境.29測試方案.294.2 總結與展望.324.3 致謝.33參考文獻參考文獻 .34附錄附錄 A A：英文原文：英文原文 .35附錄附錄 B B：中文翻譯：中文翻譯 .41引引言言本此畢業(yè)設計將基于角色訪問控制（Role-Based Access Control，RBAC）作為研究課題，來

6、實現(xiàn)一個企業(yè)內部管理系統(tǒng)中的權限管理部分。本文在RBAC2001 建議標準的參考模型(下稱 NIST RBAC 模型)的基礎上，結合綜合信息管理系統(tǒng)以及軟件系統(tǒng)集成的要求和特點，將 RBAC 訪問控制框架應用到一個已有的以 MVC 為架構建立而成的商務網站中去。第一章第一章 課題背景課題背景1.11.1 MVCMVC 概述概述由于 Internet 的普及和網絡技術的發(fā)展，大部分的企業(yè)或單位都擁有了自己的 Web 站點。通過 Internet 或 Intranet，企業(yè)的管理變得更加方便；企業(yè)的信息發(fā)布變得更加便捷；企業(yè)的市場開拓變得更加簡便。企業(yè)網站大部分屬于商務網站，企業(yè)通過利用 Web

7、系統(tǒng)，可以方便的發(fā)布產品信息，管理訂單信息，管理內部的諸如人事、員工薪酬信息等。從而在一定程度上提高工作和管理效率，降低生產和管理成本?，F(xiàn)在用來建立 Web 站點的工具和編程語言主要有 ASP、PHP 和 JSP，使用的設計模式是 MVC。MVC 作為構建網站系統(tǒng)的主流設計模式，有其自身的特點和優(yōu)勢，具體表現(xiàn)在：（1）可以為一個模型在運行時同時建立和使用多個視圖。變化-傳播機制可以確保所有相關的視圖及時得到模型數據變化，從而使所有關聯(lián)的視圖和控制器做到行為同步。 （2） 視圖與控制器的可接插性，允許更換視圖和控制器對象，而且可以根據需求動態(tài)的打開或關閉、甚至在運行期間進行對象替換。 （3） 模

8、型的可移植性。因為模型是獨立于視圖的，所以可以把一個模型獨立地移植到新的平臺工作。需要做的只是在新平臺上對視圖和控制器進行新的修改。 （4） 潛在的框架結構。可以基于此模型建立應用程序框架，不僅僅是用在設計界面的設計中?；?MVC 模式建設 Web 站點系統(tǒng)，可以提高代碼的重用性；可以提高代碼的可維護性；可以提高編寫程序的效率。所以目前，越來越多的網站開始采用MVC 模式來進行架構，但是在這其中，對于系統(tǒng)安全性問題的研究還進行的不多。在構建 Web 系統(tǒng)之初，就要考慮系統(tǒng)的安全性，考慮用戶對系統(tǒng)的訪問控制。通過訪問控制，一方面只有合法的用戶才可以安全、正確的使用系統(tǒng)，非法的用戶是無法登陸系統(tǒng)

9、進行操作；的；另一方面合法的用戶登錄系統(tǒng)之后，由于用戶的類型不同，就會存在不用的用戶在訪問系統(tǒng)時具有不同的權限，比如一個企業(yè)或公司的經理往往會比企業(yè)或公司的員工具有更多的權限和功能，相應的用戶登錄系統(tǒng)之后，他們只能行使系統(tǒng)準許他們的權限?？v觀現(xiàn)在的 Web 系統(tǒng)，大都存在這樣的問題：功能雖強大，但是卻存在很多的安全隱患。系統(tǒng)中的不同類型的用戶對信息都具有相同的權限，可以任意的修改和刪除，這對于一些重要的信息是非常危險的。對信息的科學管理，應該是最高層的用戶擁有對信息最高的權限，而處于底層或次底層的用戶僅擁有對信息最少的權限。此外，現(xiàn)在大部分 Web 系統(tǒng)中都缺少一個良好的訪問控制模塊。在該模塊

10、中，可以為系統(tǒng)設定不同的用戶，分配不同的權限。將系統(tǒng)中的用戶和系統(tǒng)中的權限關聯(lián)起來，形成一種有效的系統(tǒng)安全管理。綜上所述，企業(yè)在構建自身的商務 Web 系統(tǒng)時，在考慮功能完整性和操作簡便性的同時，還應重點考慮構建的 Web 系統(tǒng)的安全性。只有在保證了安全性的前提下，功能的完整性和操作的簡便性才變得有意義。1.21.2 RBACRBAC 模型概述模型概述 RBACRBAC 原理簡介原理簡介1992 年，美國國家標準與技術研究所（NIST）的 David Ferraiolo 和Rick Kuhn 在綜合了大量的實際研究之后，率先提出基于角色的訪問控制模型框架，并給出了 RBAC 模型的一種形式化定

11、義。該模型第一次引入了角色的概念并給出其基本語義，指出 RBAC 模型實現(xiàn)了最小權限原則（the least privilege）和職責分離原則（separation of duty） 。該模型中給出了一種集中式管理的 RBAC 管理方案。1995 年他們以一種更直觀的方式對該模型進行了描述。Ravi Sandhu 和他領導的位于 George Mason 大學的信息安全技術實驗室（LIST）于 1996 年提出了著名的 RBAC96 模型，將傳統(tǒng)的 RBAC 模型根據不同需要拆分成四種嵌套的模型并給出形式化定義，極大的提高了系統(tǒng)靈活性和可用性。1997 年他們更進一步，提出了一種分布式 RB

12、AC 管理模型 DRBAC97，實現(xiàn)了在 RBAC 模型基礎上的分布式管理。這兩個模型清晰的表征了 RBAC 概念并且蘊涵了他人的工作，成為 RBAC 的經典模型。絕大多數基于角色的訪問控制研究都以這兩個模型作為出發(fā)點。在 RBAC 中，涉及到的基本概念如下：用戶（User）：系統(tǒng)的使用者?？梢允侨恕⒂嬎銠C、機器人等，一般指人。角色（Role）：一定數量的權限的集合。權限分配的單位與載體，目的是隔離用戶與權限的邏輯關系。對應于組織中某一特定的職能崗位，代表特定的任務范疇。角色的例子有：經理、采購員、推銷員等。權限（Permission）：表示對系統(tǒng)中的客體進行特定模式訪問的操作許可，例如對數據

13、庫系統(tǒng)中關系表的選擇、插入、刪除。在應用中，許可受到特定應用邏輯的限制。用戶指派（User Assignment）：用戶與角色之間的關系是多對多的關系。用戶指派指根據用戶在組織中的職責和能力被賦為對應角色的成員。用戶通過被指派到角色間接獲得訪問資源的權限。權限指派（Permission Assignment）：角色與權限之間的關系也是多對多的關系。權限指派指角色按其職責范圍與一組操作權限相關聯(lián)。進行權限分配時，應遵循最小特權原則（the Least Privilege Rule） ，即分配的權限集既能保證角色充分行使其職權，又不能超越職權范圍。角色激活（Role Activation）：是指用

14、戶從被授權的角色中選擇一組角色的過程。用戶訪問的時候實際具有的角色只包含激活后的角色，未激活的角色在訪問中不起作用。相對于靜態(tài)的角色授權來說，角色激活是一種動態(tài)的過程，提供了相當的靈活性。會話（Session）：用戶是一個靜態(tài)的概念，會話則是一個動態(tài)的概念。一次會話是用戶的一個活躍進程，它代表用戶與系統(tǒng)進行交互，也叫主體（Subject） 。用戶與會話是一對多關系，一個用戶可同時打開多個會話?；钴S角色集（ARS）：一個對話構成一個用戶到多個角色的映射，即會話激活了用戶授權角色集的某個子集，這個子集被稱為活動角色集，ARS 決定了本次會話的許可集。在 RBAC 中，它遵循如下的基本原則：角色繼承

15、（Role Inheritance）為了提高效率，避免相同權限的重復設置，RBAC 采用了“角色繼承”的概念，定義了這樣的一些角色，他們有自己的屬性，但可能還繼承其他角色的屬性和權限。角色繼承把角色組織起來，能夠很自然地反映組織內部人員之間的職權、責任關系。最小權限原則（the Least Privilege Rule）所謂最小權限原則是指：用戶所擁有的權力不能超過他執(zhí)行工作時所需的權限。實現(xiàn)最小權限原則，需分清用戶的工作內容，確定執(zhí)行該項工作的最小權限集，然后將用戶限制在這些權限范圍之內。在 RBAC 中，可以根據組織內的規(guī)章制度、職員的分工等設計擁有不同權限的角色，只有角色需要執(zhí)行的操作才

16、授權給角色。當一個主體預訪問某資源時，如果該操作不在主體當前活躍角色的授權操作之內，該訪問將被拒絕。職責分離（Separation of Duty）對于某些特定的操作集，某一個角色或用戶不可能同時獨立地完成所有這些操作。職責分離的概念包括：多路共享資源，用功能分解命名互相區(qū)分的權限集，對用戶進行強制分類，允許層次性的分解權限。 RBACRBAC 適用性分析適用性分析在 RBAC 模型中，一個用戶通過用戶授權獲得一個或者幾個角色，但角色不能被同時激活；一個角色可以被同時授予多個用戶；每個角色有一個或多個節(jié)點，一個節(jié)點也可以被賦予多個角色；每個節(jié)點有一個或者多個功能，一個功能可以被同時掛在不同的節(jié)

17、點上，而節(jié)點可以有子節(jié)點，子節(jié)點也可以再有子節(jié)點；一個功能對應一個或多個頁面；一個頁面有一個或多個操作。這樣每個用戶登錄時就可以根據角色得到一棵功能樹從而使用系統(tǒng)中的資源。為更真實的描述現(xiàn)實， RBAC 模型還有許多的控制機制。如對 Web 頁面多維度和細粒度控制，對角色、功能、節(jié)點的靜態(tài)限制和對角色的動態(tài)限制。對頁面的限制主要是限制用戶在特定時間和特定地點所能看到的功能和所能進行的操作。其他限制主要是在功能被賦予節(jié)點時、節(jié)點被賦予角色時和角色被賦予用戶時的限制。模型中有了這些限制才更完整、更真實地反應現(xiàn)實，從而使實際模型細化的過程更加平滑，現(xiàn)實和計算機實現(xiàn)策略達到較好的融合。頁面是 Web

18、應用系統(tǒng)中最重要的元素，控制頁面訪問是整個系統(tǒng)安全的重要條件。對頁面的訪問控制可以從時間和空間兩個方面來進行，對頁面功能和數據的訪問，可以通過用戶登錄后所帶 session 中的信息進行控制。時間約束分為一般時間約束和周期時間約束兩種。一般時間約束是指從一個時間點持續(xù)到另一時間點之間可以訪問某個頁面，例如，企業(yè)商務系統(tǒng)中的商品招標頁面，它在某一指定時間段內開放，對這種約束可以在用戶訪問網頁的時候判斷訪問時間是否在允許范圍內。周期時間約束是指對那些功能和數據周期性開放的頁面進行訪問控制?？臻g約束主要是對用戶在不同地方（網段）登錄所能看到的頁面以及頁面能提供的信息進行控制。例如，管理部門內部事務所

19、對應的頁面通常對用戶所在的訪問位置有較嚴的限制。一般系統(tǒng)的高層用戶都有一個固定的 IP 段，就可以對那些重要的頁面設置允許訪問的 IP 范圍來達到對關鍵資源的保護。對頁面的空間約束可以分成分網段、分樓層、分房間、分 IP 地址等不同層次的控制。對頁面功能和數據的訪問需要知道用戶的大概類型，主要包括管理員、部門管理員、一般職工、游客（企業(yè)或單位以外的人員）等。用戶登錄后將用戶的類型保存到 session 中，在用戶訪問頁面時就可以根據用戶的不同類型，以及他們對時間、空間等硬性約束的滿足情況來顯示相應的功能和數據。通過了解 RBAC 模型的原理和 RBAC 模型中對訪問控制的支持，我們可以看出，R

20、BAC 模型可以很好的應用于已有或將要開發(fā)的企業(yè)商務 Web 系統(tǒng)中。通過在系統(tǒng)中使用 RBAC 模型，可以很好的解決如下的問題：權限管理混亂的問題。通過在系統(tǒng)中增加角色這個概念，很好的解決了這個問題。在 RBAC 模型中，可以利用角色與系統(tǒng)中的所有權限關聯(lián)，使得某種角色具有某種特定的權限，從而在為用戶設定好相應的角色之后，也就意味著得到了相應的系統(tǒng)權限?？刂七壿嫽靵y的問題。通過使用 RBAC 模型，可以避免在系統(tǒng)中書寫負責的控制邏輯來進行訪問控制。尤其當系統(tǒng)設計的用戶和角色比較多時，單純的依靠代碼進行訪問控制將變得相當困難。換句話說，RBAC 模型為我們提供了良好的訪問控制支持。在企業(yè)商務

21、Web系統(tǒng)中利用 RBAC 模型，可以簡便、科學、清晰地進行訪問控制，從而在一定程度上提高了整個 Web 系統(tǒng)的安全性。1.31.3 RBACRBAC 在在 MVCMVC 中的應用現(xiàn)狀中的應用現(xiàn)狀 網站程序的安全是系統(tǒng)開發(fā)人員必須考慮的重要因素之一，因為這涉及到網站的建設者、網站用戶的諸多安全問題，如果不處理好，可能會給系統(tǒng)的使用者和管理者帶來嚴重問題?，F(xiàn)在普遍在使用的安全措施有如下幾種：（1）防止 SQL 注入比如 URL、表單等提交信息時，通過一段防止 SQL 注入的過濾代碼即可防止出錯信息暴露，或者通過轉向，當系統(tǒng)出錯時轉到一個提示出錯的頁面等。對于文本型輸入，如果要進行檢查，就得根據字

22、段本身的性質進行。例如如果是年齡，就得限定必須是數字，大小必須限定在一個范圍之間，比如說18-120 之間。對于用戶名，應該建立一個集合，這個集合里存放有被允許的字符，或被禁止的字符。（2）驗證碼技術所謂驗證碼，就是將一串隨機產生的數字或符號，生成一幅圖片，圖片里加上一些干擾象素，由用戶肉眼識別其中的驗證碼信息，輸入表單提交網站驗證，驗證成功后才能使用某項功能。放在會員注冊、留言本等所有客戶端提交信息的頁面，要提交信息，必須要輸入正確的驗證碼，從而可以防止不法用戶用軟件頻繁注冊，頻繁發(fā)送不良信息等。（3）MD5 加密技術MD5 的全稱是 Message-Digest Algorithm 5，當

23、用戶登錄的時候，系統(tǒng)把用戶輸入的密碼計算成 MD5 值，然后再去和保存在文件系統(tǒng)中的 MD5 值進行比較，進而確定輸入的密碼是否正確。通過這樣的步驟，系統(tǒng)在并不知道用戶密碼的明碼的情況下就可以確定用戶登錄系統(tǒng)的合法性。這不但可以避免用戶的密碼被具有系統(tǒng)管理員權限的用戶知道，而且還在一定程度上增加了密碼被破解的難度。（4）數據備份一般采用數據庫系統(tǒng)自動定時備份、定時自動刪除幾天以前的數據等，即可完成數據的備份功能。而圖片、文件一般是不能自動備份，需要手工操作，所以我們必須要定期手工對網站的圖片、文件進行備份操作。訪問控制技術是由美國國防部（Department of Defense, DoD）資

24、助的研究和開發(fā)成果演變而來的。這一研究導致兩種基本類型訪問控制的產生：自主訪問控制（Discretionary Access Control, DAC）和強制訪問控制（Mandatory Access Control, MAC） 。最初的研究和應用主要是為了防止機密信息被未經授權者訪問，近期的應用主要是把這些策略應用到為商業(yè)領域。自主訪問控制，允許把訪問控制權的授予和取消留給個體用戶來判斷。為沒有訪問控制權的個體用戶授予和廢除許可。自主訪問控制機制允許用戶被授權和取消訪問其控制之下的任何客體（object） ，換句話說，用戶就是他們控制下的客體的擁有者。然而，對于多數組織來說，最終用戶對所訪問

25、的信息沒有擁有權。對于這些組織，公司或代理機構是事實上的系統(tǒng)客體和處理他們的程序的擁有者。訪問優(yōu)先權受組織控制，而且也常?；诠蛦T功能而不是數據所有權。強制訪問控制，在美國國防部 Trusted Computer Security Evaluation Criteria (TCSEC) 中定義如下：“一種限制訪問客體的手段，它以包含在這些客體中的信息敏感性和訪問這些敏感性信息的主體的正式授權信息（如清除）為基礎” 。強制訪問控制是“強加”給訪問主體的，即系統(tǒng)強制主體服從訪問控制政策。強制訪問控制（MAC）的主要特征是對所有主體及其所控制的客體（例如：進程、文件、段、設備）實施強制訪問控制。為這

26、些主體及客體指定敏感標記，這些標記是等級分類和非等級類別的組合，它們是實施強制訪問控制的依據。系統(tǒng)通過比較主體和客體的敏感標記來決定一個主體是否能夠訪問某個客體。用戶的程序不能改變他自己及任何其它客體的敏感標記，從而系統(tǒng)可以防止特洛伊木馬的攻擊。強制訪問控制一般與自主訪問控制結合使用，并且實施一些附加的、更強的訪問限制。一個主體只有通過了自主與強制性訪問限制檢查后，才能訪問某個客體。用戶可以利用自主訪問控制來防范其它用戶對自己客體的攻擊，由于用戶不能直接改變強制訪問控制屬性，所以強制訪問控制提供了一個不可逾越的、更強的安全保護層以防止其它用戶偶然或故意地濫用自主訪問控制。以上訪問控制策略對于處

27、理一些無需保密但又敏感的信息的政府和行業(yè)組織的需求并不是特別的適合。在這樣的環(huán)境下，安全目標支持產生于現(xiàn)有法律、道德規(guī)范、規(guī)章、或一般慣例的高端組織策略。這些環(huán)境通常需要控制個體行為的能力，而不僅僅是如何根據信息的敏感性為其設置標簽從而訪問這一信息的個人能力。就基于角色訪問控制而言，訪問決策是基于角色的，個體用戶是某個組織的一部分。用戶具有指派的角色（比如醫(yī)生、護士、出納、經理） 。定義角色的過程應該基于對組織運轉的徹底分析，應該包括來自一個組織中更廣范圍用戶的輸入。訪問權按角色名分組，資源的使用受限于授權給假定關聯(lián)角色的個體。例如，在一個商務管理系統(tǒng)中，經理角色可能包括人事管理、工資管理、分

28、配項目等；而一般員工的角色則被限制為僅能瀏覽自己的一些信息，如基本信息、工資信息和工程項目信息等。基于角色的訪問控制模型 RBAC 比傳統(tǒng)的自主訪問控制和強制訪問控制更優(yōu)越，同時也提供了更高的靈活性和擴展性。RBAC 訪問控制模型實現(xiàn)了用戶與訪問權限的邏輯分離，減少了授權管理的復雜性，降低了管理開銷和管理的復雜度。對于現(xiàn)在規(guī)模日益增大的基于 MVC 架構的商務信息管理系統(tǒng)來說，采用RBAC 訪問控制模型的訪問控制模塊將會起到越來越大的作用。綜上分析，控制訪問角色的運用是一種開發(fā)和加強企業(yè)特殊安全策略，進行安全管理過程流程化的有效手段。運用 RBAC 模型可以很好的解決 Web 系統(tǒng)中提出的訪問

29、控制要求，而 DAC、MAC 等等訪問控制技術由于各種各樣的局限性和特性，都不是 WEB 系統(tǒng)下實現(xiàn)訪問控制的最好選擇。從目前的應用現(xiàn)狀來看，以 MVC 為架構而建成的 WEB 網站特別是商務網站的數量較為龐大，而由于其自身的管理特性，對安全措施的要求也越來越高，這就要求我們找到一種更為有效的權限管理方法去適應網站對訪問控制技術的要求。而 RBAC 作為一種科學、合理、靈活、成熟的訪問控制技術，最適合于在WEB 環(huán)境下使用，所以如何使它應用到那些基于 MVC 架構的網站中去，會是一個具有相當研究價值的課題。第二章第二章 系統(tǒng)框架分析與設計系統(tǒng)框架分析與設計2.12.1 基于基于 MVCMVC

30、架構的架構的 WebWeb 系統(tǒng)系統(tǒng)在當前開發(fā)的商務系統(tǒng)中，一般都會包括部門管理功能模塊，員工管理功能模塊，工程項目管理功能模塊和員工薪水管理功能模塊，以及包括針對員工使用的信息查看模塊。先下面給出一個已經設計完善的基于 MVC 架構的 WEB 網站，系統(tǒng)的功能模塊圖如圖 2-1 所示。系統(tǒng)的功能模塊部門管理模塊員工管理模塊工程項目管理模塊員工工資管理模塊信息查看模塊系統(tǒng)功能管理模塊系統(tǒng)用戶管理模塊系統(tǒng)角色管理模塊圖 2-1 系統(tǒng)功能模塊圖部門管理模塊：針對公司內部的所有的部門進行管理，用戶可以方便地添加部門、修改部門信息、刪除某一部門和查詢某一部門的信息。員工管理模塊：針對公司內部的所有的員

31、工進行管理，用戶可以方便地添加員工信息、修改員工信息、刪除某一員工信息和查詢某一部門的所有員工信息。工程項目管理模塊：針對公司的工程項目進行管理，用戶可以方便地添加工程項目信息、修改某一工程項目的信息、刪除某工程項目的信息和查詢某一工程項目信息。員工工資管理模塊：針對公司內部的所有的員工的薪酬進行管理，用戶可以方便地添加工資信息、修改工資信息、刪除工資信息和查詢某一員工在某段時間內的所有工資信息。信息查看模塊：針對公司員工設計的功能模塊，通過該模塊員工可以方便的查看自己的基本信息，工資信息以及所負責的工程項目信息。系統(tǒng)功能管理模塊：用戶可以通過該模塊管理系統(tǒng)中涉及到的所有功能，可以添加、刪除和

32、修改。系統(tǒng)用戶管理模塊：用戶可以通過該模塊管理系統(tǒng)中涉及到的所有用戶，可以添加、刪除和修改。系統(tǒng)角色管理模塊：用戶可以通過該模塊為系統(tǒng)中的不同的用戶設置不同的權限，并能夠修改某一用戶所賦予的權限。在上述的商務系統(tǒng)中，在安全性上一般會有如下的要求：能夠很好的實現(xiàn)訪問控制。在一個企業(yè)中，存在著很多種不同的用戶，如經理、董事長、一般職工，系統(tǒng)維護人員等。當所有的用戶面對同一個系統(tǒng)時，就應該做到用戶之間要有區(qū)分，即進入系統(tǒng)后不同的用戶只能實行自身擁有的權限，不可以越權。部分信息的保密。公司中存在著一些決定企業(yè)利益的信息，這些信息只能由公司的管理人員來查看和管理，任何非法的侵入都有可能造成不良的后果?，F(xiàn)

33、代主流的 Web 系統(tǒng)的體系架構設計基于 J2EE 平臺上的 MVC 設計模式，應用 Struts 框架，采用 B/S 模式，具體的架構設計如圖 2-2 所示。ActionActionActionHTMLJSPsStruts Tags(JSTL)Style SheetActionServletRequestProcessorWeb ContainerControllerModelPresentationLayerHttp ResponseHttp RequestBusinessManagement_MessagerRpertiesStruts-config.xmlVie

34、wJavaBeanBusinessObjectsDatabase LayerWeb.xmlBusiness LayerClientLayer圖 2-2 商務管理系統(tǒng)架構圖在圖 2-2 中，系統(tǒng)架構可以細分為以下 4 個層次：客戶層（Client Layer）：運行在用戶機器的瀏覽器中，處理與用戶的交互。表現(xiàn)層（Presentation Layer）：運行在 J2EE Web 容器中，產生系統(tǒng)的表現(xiàn)邏輯，處理用戶的請求并做出響應；整個 Web 層建立在 Struts 框架基礎上，其中 View 由 HTML 和 JSP 頁面組成，其數據表示是 ActionForm Oracle 9iBrowse

35、rBean；Controller 由 ActionServlet 組合 Struts-config.xml 和 Action 類組成；而 Model 則交由業(yè)務邏輯層來實現(xiàn)。業(yè)務邏輯層（Business Layer）：運行在 J2EE Web 容器中，完成系統(tǒng)的業(yè)務需求，為 Web 層提供所需的業(yè)務方法，由 JavaBean 構成系統(tǒng)的 Business Objects（BO） ，并使用 DAO 模式把數據訪問封裝起來，以供在其他應用層中統(tǒng)一調用。數據源層（Database Layer）：即數據庫層，存放系統(tǒng)的應用數據，系統(tǒng)采用 Oracle9i 作為數據庫服務器。系統(tǒng)的架構可以表示為 JSP

36、+Struts+Database。使用這種架構一方面便于系統(tǒng)的開發(fā)和管理；另一方面，層與層之間的開發(fā)幾乎是完全獨立的，從而降低了數據在各層之間的耦合性，提高了系統(tǒng)的可維護性和可擴展性。此外，系統(tǒng)是由 Java 來開發(fā)實現(xiàn)的，Java 的跨平臺特性實現(xiàn)了系統(tǒng)的可移植性。2.22.2 RBACRBAC 模型的建立模型的建立根據上述商務系統(tǒng)對安全性的需求，通過在 Web 系統(tǒng)中使用 RBAC 模型可以很好的滿足各項需求。RBAC 的核心思想就是：根據用戶需求，給用戶分派各種角色，為不同的角色分配各種權限，用戶通過自己所屬的角色獲得操作權限許可。其核心模型如圖 2-3 所示。圖 2-3 RBAC 模型

37、核心 RBAC 模型的組成部分是：Users：用戶集u1，u2，u3 ，un；Roles：角色集r1，r2，r3， ，rn；OPS：操作集op1，op2，op3，opnOBJ：客體集obj1，obj2，obj3，objnP= OPS X 0BJ：權限集是不同客體上不同操作的描述pl，p2，p3，. ，pnRolesUsersUA*：用戶角色分配關系：多對多；Assigned-users：，角色與用戶的映射，將一個角色與一組用戶相映射；：權限-角色分配關系，多對多；Assigned privileges ： ，角色與權限的映射，將一個角色與一組權限相映射；Session ：會話集s1，s2，s3

38、，sn User_sessions ：，用戶與會話的映射，將一個用戶與一個會話相映射；Session_roles ：，會話與角色的映射，將一個會話與一組角色相映射；Avail_session_privilege ：，在一次會話中一個用戶允許的權限；用戶：不僅指人，也可以指機器，網絡或智能代理。角色：管理員依據安全策略劃分出來的操作集合，表示該角色成員所授予的職權和責任?？腕w：指系統(tǒng)需要保護的資源。權限：對系統(tǒng)中的客體進行特定存取的許可。權限是與客體緊密相關的，不同的系統(tǒng)，其權限規(guī)定是不同的，既可以指網絡的應用，如對某個子網的訪問權限，也可以指對數據庫的表單等的訪問。權限的粒度大小取決于實際系統(tǒng)

39、的定義。會話：為了對系統(tǒng)資源進行操作，用戶需要建立會話，每個會話將一個用戶與他所對應的角色集中的一部分建立映射關系，這一角色子集成為被會話激活的角色，在這次會話中，用戶可以執(zhí)行的操作就是該會話激活的角色對應的權限所允許的操作。上述 RBAC 模型是 RBAC 核心模型，此模型保留了 RBAC 的最小特征集，是每個 RBAC 系統(tǒng)都需要的元素。2.32.3 RBACRBAC 模型在模型在 MVCMVC 網站中的應用網站中的應用由需求分析可知，需要為企業(yè)內部網管理系統(tǒng)設計一個用戶權限管理的功能模塊，從而達到對用戶權限進行管理的目的。當今的大型的信息管理系統(tǒng)都具有功能復雜，用戶眾多的特點，如果仍采用

40、傳統(tǒng)的權限管理方式，直接將權限分配給用戶，對具有相同權限的一類用戶同樣的授權操作將被重復很多遍，一旦用戶工作崗位有變化，則對其權限的調整將非常復雜，而基于 RBAC 模型的權限控制方法則大大簡化了這種授權管理的復雜度，降低了系統(tǒng)管理的開銷。RBAC 模型描述了一種良好的訪問控制方法和原理。通過在商務 Web 系統(tǒng)中使用 RBAC 模型可以方便、科學、合理地進行訪問控制，有了良好的訪問控制，不同的用戶在使用系統(tǒng)的時候僅能訪問自身被賦予的權限，用戶之間不能越權訪問，從而保證了信息的安全性和一致性，從而提高了系統(tǒng)的安全性。通過以下幾個步驟，可以將 RBAC 模型應用在 MVC 網站中。（1）建立功能

41、的概念。功能，即操作。在系統(tǒng)中，如對員工的添加、刪除和修改的操作，都可以描述為一個功能。（2）建立權限節(jié)點的概念。權限節(jié)點，顧名思義，它對應著一個或一組功能操作菜單，表示了該節(jié)點可以進行系統(tǒng)操作的范圍。（3）建立角色的概念。將角色與節(jié)點對應起來，一個角色可以對應多個節(jié)點，一個節(jié)點也可以對應多個角色，這是一個多對多的關系。角色與節(jié)點對應好之后，也就意味著角色與某一個或某一組功能操作菜單建立了關聯(lián)。系統(tǒng)中存在不同類型的用戶，也即不同的用戶隸屬于不同的角色。（4）將系統(tǒng)的用戶和角色關聯(lián)起來。一旦一個用戶被設置了某個角色，那么也就意味著該用戶具有了某些權限。具有了某些權限，也就意味著擁有了某些功能（對

42、系統(tǒng)的操作和管理） 。舉例來說，假設系統(tǒng)中存在兩個權限節(jié)點 1 和 2，兩個角色 A 和 B，用戶有甲（經理）和乙（部門經理） ，很顯然甲和乙在登陸系統(tǒng)后應該具有不同的權限，甲可以管理整個公司的信息，而乙僅能管理所在部門的信息。這時，設定權限節(jié)點 1 下包含了管理整個公司信息的所有功能，權限節(jié)點 2 下包含了管理某個部門信息的所有功能；將角色 A 與節(jié)點 1 進行關聯(lián)，將角色 B 與節(jié)點 2 進行關聯(lián)。最后，將用戶甲的角色設定為角色 A，用戶乙的角色設定為角色 B。在用戶甲和乙登陸系統(tǒng)后，就會看到自己所具有的功能菜單，其他用戶的功能菜單是非可見的，從而實現(xiàn)了訪問控制。簡言之，通過在系統(tǒng)中設置功

43、能、權限和角色的概念，就可以在系統(tǒng)中實現(xiàn) RBAC 模型，并讓它很好地為 Web 系統(tǒng)提供訪問控制功能。第三章第三章 設計實現(xiàn)設計實現(xiàn)3.13.1 RBACRBAC 框架實現(xiàn)框架實現(xiàn)數據存儲是個非常重要的功能需求。系統(tǒng)中很多的地方都要存儲數據，并且其格式要求也不相同，數據量也差別較大。良好的設計不但能減少因數據保存不當造成的對系統(tǒng)的損害，而且能顯著地提高系統(tǒng)的性能。在考慮數據存儲方案時，有三種可行的選擇，分別是文件方式、數據庫方式、LDAP 方式，這三種方式都有各自的優(yōu)缺點。文件方式的好處在于簡單直觀，存取速度最快，但不夠安全，在 RBAC 的早期版本中，我們采用的就是文件方式。LDAP 方式

44、可以保證數據的安全和完整性，但使用不方便，普及程度也不高；數據庫方式是業(yè)界比較認可的主流存儲方案，而且現(xiàn)在的數據庫技術也比較成熟，是較為理想的選擇。有鑒于此，我們在系統(tǒng)中采用了數據庫方式作為本系統(tǒng)數據存儲方案。以下為數據存儲的表結構：1、P_YHB 用戶表用于記錄用戶基本信息。如表 3-1 所示。表表 3-13-1 用戶表用戶表編號列名類型長度說明約束1*YHIDVARCHAR8用戶 ID2YHMCVARCHAR20用戶名稱3YHMMVARCHAR25用戶密碼4SSBMVARCHAR5用戶所屬部門5YHMSVARCHAR500用戶描述2、P_JSB 角色表記錄和角色相關和信息。如表 3-2 所

45、示。表表 3-23-2 角色表角色表編號列名類型長度說明約束1*JSIDVARCHAR5角色 ID2JSMCVARCHAR50角色名稱3JSMSVARCHAR200角色描述可為空4JSXYHZDSNUMBER10此角色下的用戶最大數可為空5JSLXVARCHAR1角色類型3、P_YHJSB 用戶角色表用于記錄用戶角色指派的內容，即記錄每個角色被賦予了哪些用戶。如表3-3 所示。表表 3-33-3 用戶角色表用戶角色表編號列名類型長度說明約束1*YHIDVARCHAR8用戶 ID1.12*JSIDVARCHAR5角色 ID2.14、P_GNB 功能表存放權限，一條記錄就是一個權限，一個權限指的是

46、一個用戶可以使用的一個功能項，在表中記錄了該權限對應的主 URL。如表 3-4 所示。表表 3-43-4 功能表功能表編號列名類型長度說明約束1*GNIDVARCHAR5功能 ID2GNMCVARCHAR50功能名稱3GNMSVARCHAR500功能描述可為空4ZURLVARCHAR200主 URL5CZVARCHAR1操作（只讀、讀寫、執(zhí)行）5、P_JSJDB 角色節(jié)點表記錄權限角色指派的內容，即記錄每個角色所擁有的權限信息。如表 3-5所示。表表 3-53-5 角色節(jié)點表角色節(jié)點表編號列名類型長度說明約束1*JSIDVARCHAR5角色 ID2.12*JDIDVARCHAR5節(jié)點 ID6.

47、16、P_JDB 節(jié)點表記錄每個節(jié)點信息。如表 3-6 所示。表表 3-63-6 節(jié)點表節(jié)點表編號列名類型長度說明約束1*JDIDVARCHAR5節(jié)點 ID2.JDMCVARCHAR50節(jié)點名稱3.FJDIDVARCHAR5父節(jié)點 ID4JDMSVARCHAR500節(jié)點描述5JDNXHVARCHAR2節(jié)點內序號7、P_JDGNB 節(jié)點表記錄每個節(jié)點所包含的權限信息。如表 3-7 所示。表表 3-73-7 節(jié)點功能表節(jié)點功能表編號列名類型長度說明約束1IDVARCHAR1節(jié)點層次2*GNIDVARCHAR5節(jié)點 ID3*JDIDVARCHAR5節(jié)點 ID8、P_DEPARTMENT 企業(yè)部門表記

48、錄每個企業(yè)部門所包含的部門信息。如表 3-8 所示。表表 3-83-8 企業(yè)企業(yè)部門表部門表編號列名類型長度說明約束1*DEPBMVARCHAR3部門編號2DEPMCVARCHAR100部門名稱3DEPLXDHVARCHAR25部門聯(lián)系電話4DEPMANAGERVARCHAR8部門負責人9、P_PROJECT 企業(yè)工程項目表記錄每個工程項目所包含的工程項目信息。如表 3-9 所示。表表 3-93-9 企業(yè)工程項目表企業(yè)工程項目表編號列名類型長度說明約束1*PRJBHVARCHAR20項目編號2PRJNAMEVARCHAR100項目名稱3PRJMANVARCHAR20項目負責人11.14PRJM

49、ONEYVARCHAR40項目資金5PRJDATEDATE立項日期10、P_SALARY 企業(yè)員工工資表記錄每個企業(yè)員工的工資信息。如表 3-10 所示。表表 3-103-10 企業(yè)員工工資企業(yè)員工工資表表編號列名類型長度說明約束1*IDNUMBER工資帳單序號2SALARY_NUMVARCHAR10工資帳單金額3WORKERBMVARCHAR10員工編號11.14SALARY_DATEDATE工資帳單發(fā)放日期11、P_WORKER 企業(yè)員工信息表記錄每個企業(yè)員工的信息。如表 3-11 所示。表表 3-113-11 企業(yè)員工表企業(yè)員工表編號列名類型長度說明約束1*WORKERBMVARCHAR

50、10員工編號2WORKERMCVARCHAR50員工姓名3WORKERAGEVARCHAR3員工年齡4WORKERSEXVARCHAR1員工性別5WORKERADDRESSVARCHAR200員工地址6WORKERLXDHVARCHAR50員工聯(lián)系電話7WORKERZJHMVARCHAR50員工證件號碼8WORKERDEPBMVARCHAR5員工所在部門 RBACRBAC 模型在系統(tǒng)中的實現(xiàn)模型在系統(tǒng)中的實現(xiàn) 系統(tǒng)功能模塊的實現(xiàn)系統(tǒng)功能模塊的實現(xiàn)在功能管理模塊中，用戶可以進行的操作有：功能添加、修改和刪除。系統(tǒng)功能添加的實現(xiàn)過程可以描述為：瀏覽器ActionForm 類Act

51、ion 類提交表單Struts-config.xml封裝表單數據調用查找JavaBean轉向圖 3-1 系統(tǒng)功能模塊實現(xiàn)的流程圖從圖 3-1 可以看出，用戶在試圖添加一個系統(tǒng)功能時，應該首先填寫表單，填寫好表單后，點擊表單的提交按鈕之后，會觸發(fā)一個請求事件（Action） ，該數據庫事件由頁面的表單指定。在 Struts-config.xml 文檔中找到相應的 Action，同時得到該 Action 使用的 ActionForm 類。此時表單的數據將會保存到該ActionForm 類中，在 Action 中就可以得到表單中的數據。為了完成最終的功能添加，在相應的 Action 實現(xiàn)類中，還需要

52、調用模型層中的業(yè)務功能函數，來完成此次的業(yè)務邏輯。在相應的 JavaBean 中，完成與數據庫的交互，實現(xiàn)對數據的添加。用到的 ActionForm 類是 GnoperatorForm 類，該類繼承 ActionForm 類，并具有 gnid,cz,ljxjd,gnmc,gnms,zurl 等屬性。GnoperatorForm 的部分實現(xiàn)代碼如下：public class GnoperatorForm extends ActionForm private static final long serialVersionUID = 1L；private String gnid；private St

53、ring cz；private String ljxjd；private String gnmc；private String gnms；private String kfgb；private String zurl；public String getGnmc() return gnmc；public void setGnmc(String gnmc) this.gnmc = gnmc；public String getGnms() return gnms；public void setGnms(String gnms) this.gnms = gnms；實現(xiàn)功能添加的 Action 類 Gn

54、operatorAction.java,部分實現(xiàn)代碼如下：public class GnoperatorAction extends Action public ActionForward execute(ActionMapping mapping, ActionForm form,HttpServletRequest request, HttpServletResponse response) ActionForward nextdisplay = new ActionForward()； / 生成一個 ActionForward 對象String actionmappingpara = m

55、apping.getParameter()； / 接收 ActionMaping 的參數if (gnoperator.equalsIgnoreCase(actionmappingpara) nextdisplay = gnoperator(mapping, form, request, response)； else if (gnoperator_update.equalsIgnoreCase(actionmappingpara) nextdisplay = gnoperator_update(mapping, form, request, response)； else if (gnoper

56、ator_getgn.equalsIgnoreCase(actionmappingpara) nextdisplay = gnoperator_getgn(mapping, form, request, response)；return nextdisplay；/完成功能添加的實現(xiàn)方法public ActionForward gnoperator(ActionMapping mapping,ActionForm form,HttpServletRequest request, HttpServletResponse response) GnoperatorForm gnof = (Gnoper

57、atorForm) form；ActionForward forward = new ActionForward()；String method = (String) request.getParameter(method)；dbOp db = new dbOp()；response.setCharacterEncoding(gbk)；if (method.equalsIgnoreCase(insert) / 新增功能if (db.insertintoGnb(gnof) gnof.setGnmc()；gnof.setGnms()；gnof.setZurl()；gnof.setZimc(null

58、)；gnof.setZims(null)；gnof.setZiurl(null)；request.setAttribute(result, success)；forward = mapping.findForward(success)； else request.setAttribute(result, failure)；forward = mapping.findForward(failure)； else if (method.equalsIgnoreCase(update) / 更新功能if (db.UpdateGnb(gnof) request.setAttribute(result,

59、 更新成功)；forward = mapping.findForward(successupdate)； else request.setAttribute(result, 更新失敗)；forward = mapping.findForward(failureupdate)；db.close()；return forward；完成功能添加的業(yè)務函數存放在 dbOp 類中，它的部分實現(xiàn)代碼如下：public class dbOp extends DBOperator /* * 插入一個新的功能 */public boolean insertintoGnb(GnoperatorForm gnof)

60、 String gnmc = this.toGBK(gnof.getGnmc()；String zurl = this.toGBK(gnof.getZurl()；String gnms = this.toGBK(gnof.getGnms()；String ljxjd = gnof.getLjxjd()；boolean b = false；String sql = insert into p_gnb(gnid, gnmc, gnms, zurl, cz, ljxjd, sfglip, kfgb) + values (p_gnidxl.nextval,+ gnmc+ ,+ gnms + ,+ zu