asp.net基于RBAC的軟件模塊開發(fā)論文

引言互聯(lián)網(wǎng)與生俱有的開放性、交互性和分散性特征使人類所憧憬的信息共享、開放、靈活和快速等需求得到滿足。網(wǎng)絡(luò)環(huán)境為信息共享、信息交流、信息服務(wù)創(chuàng)造了理想空間，網(wǎng)絡(luò)技術(shù)的迅速發(fā)展和廣泛應(yīng)用，為人類社會的進步提供了巨大推動力。然而，正是由于互聯(lián)網(wǎng)的上述特性，產(chǎn)生了許多安全問題：(1)信息泄漏、信息污染、信息不易受控。例如，資源未授權(quán)侵用、未授權(quán)信息流出現(xiàn)、系統(tǒng)拒絕信息流和系統(tǒng)否認(rèn)等，這些都是信息安全的技術(shù)難點。(2)在網(wǎng)絡(luò)環(huán)境中，一些組織或個人出于某種特殊目的，進行信息泄密、信息破壞、信息侵權(quán)和意識形態(tài)的信息滲透，甚至通過網(wǎng)絡(luò)進行政治顛覆等活動，使國家利益、社會公共利益和各類主體的合法權(quán)益受到威脅。(3)網(wǎng)絡(luò)運用的趨勢是全社會廣泛參與，隨之而來的是控制權(quán)分散的管理問題。由于人們利益、目標(biāo)、價值的分歧，使信息資源的保護和管理出現(xiàn)脫節(jié)和真空，從而使信息安全問題變得廣泛而復(fù)雜。(4)隨著社會重要基礎(chǔ)設(shè)施的高度信息化，社會的“命脈”和核心控制系統(tǒng)有可能面臨惡意攻擊而導(dǎo)致?lián)p壞和癱瘓，包括國防通信設(shè)施、動力控制網(wǎng)、金融系統(tǒng)和政府網(wǎng)站等。目前網(wǎng)絡(luò)環(huán)境下保護數(shù)據(jù)訪問的安全手段主要有身份認(rèn)證、數(shù)據(jù)加密和訪問控制等，然而以二進制方式打開數(shù)據(jù)庫文件時身份認(rèn)證過程就很容易被跳過，導(dǎo)致數(shù)據(jù)泄露。而數(shù)據(jù)加密手段雖然安全性較高，但有明顯的局限性，因為數(shù)據(jù)庫文件一般較大，加、解密的過程會耗費大量時間，尤其在Web環(huán)境下會造成用戶長時間等待，效率極低。訪問控制技術(shù)可以保證授權(quán)用戶對數(shù)據(jù)訪問的合法性，即通過對數(shù)據(jù)讀取、修改、刪除等操作的管理，確保主體對客體的訪問是經(jīng)過授權(quán)的，并拒絕非法的訪問，從而保證數(shù)據(jù)的機密性、完整性和可用性。1緒論1.1研究背景隨著信息化進程的深入和互聯(lián)網(wǎng)的迅速發(fā)展，人們的工作、學(xué)習(xí)和生活方式正在發(fā)生巨大變化，效率大為提高，信息資源得到最大程度的共享。但緊隨信息化發(fā)展而來的網(wǎng)絡(luò)安全問題日漸凸出，如果不能很好地解決這個問題，必將阻礙信息化發(fā)展的進程。一般意義上，網(wǎng)絡(luò)安全是指信息安全和控制安全兩部分。國際標(biāo)準(zhǔn)化組織把信息安全定義為“信息的完整性、可用性、保密性和可靠性”；控制安全則指身份認(rèn)證、不可否認(rèn)性、授權(quán)和訪問控制。1.2研究現(xiàn)狀目前我們討論的訪問控制技術(shù)主要有兩種類型：自主訪問控制（DiscretionaryAccessControl，DAC）和強制訪問控制（MandatoryAccessControl，MAC）。基于角色的訪問控制（Role-BasedAccessControl，RBAC）是一種特殊的強制訪問控制，在特定的條件下它又可構(gòu)造出自主訪問控制類型的系統(tǒng)，為解決上述數(shù)據(jù)訪問所遇到的安全問題提供了行之有效的方案，也是目前國際上訪問控制領(lǐng)域的研究熱點和難點。1.3本文的研究內(nèi)容1、對現(xiàn)有的各種安全訪問控制技術(shù)，尤其是RBAC技術(shù)的進行了比較全面的介紹和分析。通過對RBAC權(quán)限控制模型理論的深入研究，針對其存在的不足之處進行了改進，提出了一種新的任務(wù)－時間約束RBAC模型。實現(xiàn)了任務(wù)級的權(quán)限最小化原則，增強了訪問控制能力，在實際應(yīng)用開發(fā)中提高了權(quán)限在動態(tài)變化中的自適應(yīng)性。2、詳細(xì)分析了任務(wù)－時間約束RBAC模型中的角色層次、任務(wù)分解、時間約束等技術(shù)關(guān)鍵點。角色層次關(guān)系是RBAC的角色管理中的重點，體現(xiàn)了各種角色直接的相互關(guān)系；任務(wù)是工作流的基本執(zhí)行單元，任務(wù)角色的引入實現(xiàn)了任務(wù)級的權(quán)限劃分粒度，進一步實現(xiàn)了權(quán)限最小化原則，時間約束的提出則是為了避免可能產(chǎn)生的利益沖突和權(quán)力盜用，實現(xiàn)了職責(zé)分離原則。3、通過具體的網(wǎng)站應(yīng)用程序的設(shè)計與實現(xiàn)，實現(xiàn)了RBAC中的角色繼承、靜動態(tài)權(quán)限約束、任務(wù)角色和時間約束等思想，保證了Web下的資源安全訪問和工作流正確執(zhí)行。2.訪問控制技術(shù)綜述2.1.傳統(tǒng)的訪問控制策略2.1.1.自主訪問控制策略(DAC)自主訪問控制策略的基本思想是客體由它的屬主進行管理,而且這個屬主可以決定是否將訪問控制權(quán)交予其他主體"由此可以看出這種訪問控制權(quán)是自主的"也即,在自主訪問控制策略中,用戶可以根據(jù)自身特點,決定是否需要共享資源!以及與哪些用戶共享資源"自主訪問控制策略又稱任意訪問控制策略,當(dāng)前,許多主流的操作系統(tǒng)均采用了這種機制,如unix!Linux!windowsNT等"由于其自主性,自主訪問控制策略可以根據(jù)訪問者的身份和權(quán)限情況來決定訪問模式,同時主體的訪問者具有一定權(quán)利來對訪問控制進行管理"在具體實現(xiàn)上,該策略通常采用的方法是訪問控制表法"該表是基于訪問控制矩陣的,這個矩陣中的值表示訪問權(quán)限,即主體訪問某一客體的權(quán)限"通常情況下,通過維護訪問控制表可以控制用戶訪問的企業(yè)數(shù)據(jù)"對于每一種需要保護的資源,該表均規(guī)定了相應(yīng)的訪問模式,可以是單個用戶的,也司一以是用戶組的"自主訪問控制策略的缺陷在于對系統(tǒng)管理員來說,他很難從總體上對數(shù)據(jù)資源的權(quán)限進行管理"原因在于自主訪問控制允許用戶自定義權(quán)限,這樣就為權(quán)限的控制造成了很大的難度,從而導(dǎo)致管理混亂!權(quán)限容易泄露等問題"2.1.2.強制訪問控制策略(MAC)顧名思義,強制訪問控制是一種強制主體服從權(quán)限分配的策略,此外,主體所控制的所有客體,包括設(shè)備!文件等,也必須服從"在具體實施強制訪問控制策略會為每一個主體和客體指定敏感標(biāo)記,作為策略實施的重要依據(jù)"該標(biāo)記會組合等級分類和非等級分類,系統(tǒng)通過對比主體和客體的敏感標(biāo)記來決定主體對客體是否具有訪問權(quán)限"原則上,應(yīng)用程序無法改變它自己以及其他客體的敏感標(biāo)記,從而提高了安全性能"強制訪問策略會為每個用戶及文件分配具體的訪問級別,這些級別的安全性從高到低分別是最高秘密級別(TopSecI.et)!秘密級別(Scc,#et)!機密級別四類"如前所述,該策略根據(jù)敏感標(biāo)記確定訪問模式"其中,訪問模式包括:l)下讀:讀操作,并且用戶的訪問級別大于文件的訪問級別;2)上寫:寫操作,并且用戶的訪問級別小于文件的訪問級別;3)下寫:寫操作,并且用戶的訪問級別等于文件的訪問級別;4)上讀:讀操作,并且用戶的訪問級別小于文件的訪問級別:由此可以看出,強制訪問控制策略對于安全性能的要求是很高的。2.2RBAC的基本思想基于角色的訪問控制(Role-BasedAccessControl)是在上個世紀(jì)90年代提出的，它的出現(xiàn)取代了DAC和MAC兩種傳統(tǒng)模型，從而得到了廣泛的關(guān)注。它的基本思想是引入角色的概念，并將其分別與權(quán)限和用戶相關(guān)聯(lián)，從而形成權(quán)限到角色再到用戶的結(jié)構(gòu)，以此實現(xiàn)用戶對受限資源的訪問。RBAC對訪問權(quán)限的授予由管理員統(tǒng)一管理，并授予給角色，而用戶不直接與權(quán)限關(guān)聯(lián)，系統(tǒng)將根據(jù)用戶在組織內(nèi)所擁有的角色來做出訪問控制。正是由于RBAC模型將用戶與權(quán)限相分離，因此為權(quán)限的管理提供了很大的便利。在實際工作環(huán)境中，由于角色與用戶的對應(yīng)關(guān)系一經(jīng)確定就相對固定，而月_指派工作不需要過多的技術(shù)，這一任務(wù)可由對業(yè)務(wù)流程較為熟悉的行政或管理人員擔(dān)當(dāng)。而將權(quán)限授予角色的工作流程較為復(fù)雜，需要一定技術(shù)能力，可由專門的開發(fā)人員進行分配，但開發(fā)人員無法將權(quán)限授予給具體用戶，這與實際工作情況也是一致的。一個基本的RBAC模型如圖2-1所示:圖2.1基本的RBAC模型可以看出，它主要由四個數(shù)據(jù)元素和兩種關(guān)系組成:四個數(shù)據(jù)元素包括:1)角色(Role):總的來說，角色是一個權(quán)限集合的概念。根據(jù)權(quán)限粒度的具體劃分程度，它可以是細(xì)粒度權(quán)限或者粗粒度權(quán)限的接口。角色可以是一個抽象的概念，也可以是根據(jù)實際的系統(tǒng)功能需求而自定義的語義體。2)用戶(User):用戶是訪問受限資源的主體。受限資源可以是系統(tǒng)中的數(shù)據(jù)，也可以是Web交互界面、Web表單等，是實體的概念。通常，用戶可以是人，也可以軟件等應(yīng)用程序。3)權(quán)限(Permission):權(quán)限是資源(Resource)和對資源進行操作(Operation)的集合體，它是二元組的概念。其中，資源表示的是系統(tǒng)中我們需要進行訪問控制的實體，如菜單、文件等。操作表示的是主體在客體上的訪問方式，常見的操作有讀操作、寫操作和修改操作等。權(quán)限作為二者的結(jié)合，表示操作在資源上的許可程度，即執(zhí)行操作的權(quán)利。4)會話(Session):每次用戶登錄進入系統(tǒng)并獲得相應(yīng)的角色，這樣的動作就產(chǎn)生了一次會話。由此可以看出，會話是一個動態(tài)的概念，它由用戶發(fā)起。用戶與會話是一對多的關(guān)系，表示在實際中，一個用戶可以建立多個會話，而一個會話只允許對應(yīng)一個用戶。在一個會話結(jié)束后，與之對應(yīng)的角色將會被懸掛起來，處于未激活的狀態(tài)中。5)限制(Constrains):限制主要是針對角色而言的，它的含義包括兩方面，即角色所擁有的用戶數(shù)量限制和角色之間的限制。例如，在一個系統(tǒng)中，管理員的數(shù)量不能是無限的，若數(shù)目過多，會造成系統(tǒng)難于管理和其他安全隱患。另外，當(dāng)用戶數(shù)目較多時，為每位用少”分別指派角色變成了非常繁瑣的事情。2.3改進的RBAC模型DRBAC模型是動態(tài)結(jié)盟環(huán)境下的分布式RBAC模型，它用來解決在該環(huán)境下對資源的訪問控制所產(chǎn)生的問題。與傳統(tǒng)的RBAC模型相比，DRBAC模型具有三個特性，包括:1)第三方指派特性。表示如果一個實體被授予指派分配權(quán)后，它就可以對其命名空間之外的角色進行指派。2)數(shù)字屬性。表示我們可以處理與角色相關(guān)的數(shù)值，通過這樣的方式就可以對訪問權(quán)限進行控制。3)指派監(jiān)控特性。表示通過使用pub或sub結(jié)構(gòu)對信任關(guān)系進行持續(xù)監(jiān)控的方式，我們能對‘可被取消的指派狀態(tài)進行跟蹤。DRBAC是由在結(jié)盟環(huán)境下對資源的訪問控制這個問題引出的?！敖Y(jié)盟環(huán)境”可以是軍事上幾個國家一起工作達(dá)到一個共同的目標(biāo)，或者商業(yè)上幾個公司合伙。結(jié)盟環(huán)境定義的特點是存在多個組織或多個實體沒有共同的可信的授權(quán)中心。在這種情況下，實體在保護它們各自的資源的同時還必須協(xié)作來共享對結(jié)盟來說必要的受保護資源的部分。Internet上網(wǎng)絡(luò)服務(wù)的增長使這樣的需求很普遍。DRBAC結(jié)合了RBAC和信任管理系統(tǒng)的優(yōu)點，是既管理靈活又可分散的，可擴展實現(xiàn)的系統(tǒng)。根據(jù)角色的受控制程度，DRBAC會讓角色在一個實體的信任域內(nèi)進行相關(guān)操作，包括定義角色和將這個角色傳遞給另外一個信任域的其他角色等。另外，DRBAC也可以鑒別任何與信任敏感操作有關(guān)的實體，并確認(rèn)指派證書，這是通過PKI機制來實現(xiàn)的[9]。從角色到授權(quán)的名字空間的映射避免了確認(rèn)額外的策略根源的需要。3RBAC模型的一些改進及新的發(fā)展趨勢3.1傳統(tǒng)RBAC模型的一些優(yōu)勢與不足通過上一章的闡述，我們對RBAC模型的相關(guān)知識有了深入的理解。作為當(dāng)前應(yīng)用最廣泛的權(quán)限管理模型，RBAC有它自己的特點，才使得其在業(yè)界得到了如此的好評，總結(jié)起來，主要有以下幾點:1)RBAC模型符合各類組織機構(gòu)對于安全性的管理需求。它支持最小原則、責(zé)任分離原則等，這些基本原則都是生產(chǎn)管理中所需要的，正好與實際情況相吻合。2)RBAC模型支持?jǐn)?shù)據(jù)抽象的原則和繼承的概念。由于這兩種概念在當(dāng)前主流的設(shè)計語言中得到了廣泛的應(yīng)用，因此，RBAC模型自然也便于這些應(yīng)用系統(tǒng)中得到實現(xiàn)。3)RBAC模型中的概念與實際情況緊密對應(yīng)。模型中的角色、用戶和權(quán)限的思想，都是現(xiàn)實生活中真實存在的實體，這種特性使得RBAC模型可以更方便的部署到實際的系統(tǒng)中。當(dāng)然，盡管RBAC模型是當(dāng)前最流行的權(quán)限管理方式，它也大量用在各類信息管理系統(tǒng)中，但是隨著系統(tǒng)規(guī)模的不斷增大、用戶數(shù)和交互數(shù)據(jù)量的日益增加，RBAC模型本身也暴露出許多難以克服的問題，總結(jié)起來，包括:1)很多企業(yè)信息系統(tǒng)有這樣的特點，即工作流程復(fù)雜，數(shù)據(jù)處理量大，安全性要求高。在這種情況下，由于安全原因，常常要求對職責(zé)進行分離，也就是把不同的工作交予不同人員來處理，這就導(dǎo)致了控制顆粒越米越細(xì)。但是在RBAC模型中，并沒有明確定義對數(shù)據(jù)權(quán)限的實現(xiàn)機制，所以它無法深層次、細(xì)粒度的進行權(quán)限管理。2)在企業(yè)中，員工的職責(zé)往往與所在的部門有直接的關(guān)系，而且角色的層級也反映組織結(jié)構(gòu)關(guān)系，但這種反映是抽象的，并沒有說明具體的策略。因此在很多情況下，為了更好的適應(yīng)權(quán)限管理的要求，我們常常要對企業(yè)的組織結(jié)構(gòu)進行適當(dāng)?shù)恼{(diào)整，但是在RBAC模型中，卻無法體現(xiàn)部門或者群組這樣的自然屬性實體。3)RBAC模型沒有提供操作順序的控制機制，這一缺陷使得RBAC模型很難應(yīng)用于那些要求有嚴(yán)格操作次序的實際系統(tǒng)。例如，在某電子商務(wù)系統(tǒng)中，要求在用戶付款之前不能將商品取走，在這種情況下，RBAC模型就無法應(yīng)用到該系統(tǒng)中。4)在現(xiàn)實生活中，可能會出現(xiàn)以下情況，兩名用戶屬于同一角色，但是對同一資源的訪問權(quán)限卻不盡相同}。比如在某系統(tǒng)中，兩個地市級操作員各自可以維護本地市及其下級地市的數(shù)據(jù)信息，但他們卻不能相互訪問對方地市及下級地市的數(shù)據(jù)信自、。這違背了RBAC原則。因為，RBAC模型規(guī)定屬于相同角色的不同用戶之間應(yīng)該也具有相同的權(quán)限。此時，如果基于傳統(tǒng)RBAC原則，那就要為這兩個用戶單獨設(shè)置兩個不同的角色，這樣會導(dǎo)致角色過多、冗余，失去了角色管理的意義。5)當(dāng)組織結(jié)構(gòu)、人員職務(wù)發(fā)生變化時，會導(dǎo)致角色、用戶和權(quán)限三者之間關(guān)系的經(jīng)常變動。在用戶數(shù)目較大時，這些問題所帶來的工作量，如權(quán)限的分配、修改和刪除，將是巨大的。而且權(quán)限管理的具體實施工作是由系統(tǒng)管理員手工操作的，其工作量大而且容易出錯。對于本課題研究所涉及的基于RABC的軟件系統(tǒng)，以上闡述的問題都在一定程度存在，這就要求我們設(shè)計一個專用的擴展RBAC模型，以實現(xiàn)權(quán)限分配的簡單性和靈活性。3.2對RBAC模型的一些擴展嘗試在我們的系統(tǒng)中，存在這樣的需求，即屬于同一角色的不同用戶，他們針對同樣的數(shù)據(jù)資源，需要具有不同的權(quán)限。如，某省A.B兩個地市管理員，A管理員可以操作本地市及其下屬地區(qū)的數(shù)據(jù)，B管理員也可以操作本地市及其下屬地市的數(shù)據(jù)，但是A,B之間的數(shù)據(jù)信息是不可以相互訪問的。但同樣，這種方法也存在一定缺陷，因為它削弱了因引入角色概念而帶來的對訪問控制管理上進行簡化的優(yōu)勢。例如，某省有10個一級地市，20個二級地市，系統(tǒng)具有30項基本功能，那么這時系統(tǒng)就要創(chuàng)建30*(20+10)=900個角色，擁有這樣數(shù)量級角色的系統(tǒng)維護起來是相當(dāng)困難的。產(chǎn)生這個問題的原因是我們將角色的粒度劃分得過于細(xì)，使得角色的概念與單個系統(tǒng)功能模塊十分接近。對此我們采用了基于“用戶+群組十角色”權(quán)限控制策略，將群組與用戶、角色相關(guān)聯(lián)，實現(xiàn)集權(quán)和分級管理。這里，我們將權(quán)限分為三類，包括功能權(quán)限、數(shù)據(jù)權(quán)限和系統(tǒng)權(quán)限。擴展RBAC模型的工作主要集中在對功能權(quán)限和數(shù)據(jù)權(quán)限的研究和設(shè)計上。對于功能權(quán)限，它是指系統(tǒng)在運行期間己經(jīng)規(guī)定好的權(quán)限集合，在數(shù)據(jù)庫中表現(xiàn)為功能對象表與操作表的關(guān)系表。為了有效的管理功能權(quán)限，將功能對象分為幾個層次來控制，如圖3-1所示:圖3.1功能對象結(jié)構(gòu)層次圖功能及其各個子模塊構(gòu)成了層次模型的最高層，子模塊在系統(tǒng)中以系統(tǒng)菜單的形式表現(xiàn)，對應(yīng)于某一具體功能，如“終端管理”、“內(nèi)容管理”等。這一層主要控制用戶對相關(guān)模塊是否有執(zhí)行的權(quán)限。對系統(tǒng)中的不同用戶來說，所執(zhí)行的功能是不相同的。頁面層位于功能層的下一層，本層主要是控制用戶能夠進入的頁面。通過頁面層與功能層相分離，可以將某個模塊作為一個整體賦予給用戶，也可以讓用戶只擁有該模塊下的部分子功能，使系統(tǒng)管理員的權(quán)限指派和管理更加靈活方便。操作層位于模型的最底部，指用戶對某頁面元素的使用能力。在營業(yè)廳聯(lián)播系統(tǒng)中，這種能力體現(xiàn)在執(zhí)行某種操作的按鈕或菜單是否呈現(xiàn)。例如，對于系統(tǒng)管理員，可以呈現(xiàn)添加、刪除、修改等按鈕，而對于普通用戶，可能只呈現(xiàn)添加按鈕，刪除、修改按鈕隱藏起來。通過將功能對象進行分層，我們可以將操作層的具體操作作為頂層功能模塊的最小單位進行定義，并將其定義成權(quán)限表，保存在數(shù)據(jù)庫中進行持久化。在具體調(diào)用時，系統(tǒng)中的各個功能權(quán)限以客體對象的形式分配給角色，用戶通過自己所屬的角色來確定對哪些模塊、頁面具有操作權(quán)限。這樣的做法可以使權(quán)限控制粒度得到細(xì)化，同時，系統(tǒng)的安全性也得到了提高。數(shù)據(jù)權(quán)限指的是對數(shù)據(jù)資源的一種訪問能力。由于數(shù)據(jù)是系統(tǒng)控制的主要對象，其規(guī)模一般會隨著系統(tǒng)運行過程迅速增長，因此，數(shù)據(jù)權(quán)限是研究的重點。鑒于系統(tǒng)部署到現(xiàn)網(wǎng)時，用戶會很多，可能包括系統(tǒng)管理員、省級操作員、各地市操作員、廣告主、代理商等。如何有效的對用戶組織管理，成為系統(tǒng)開發(fā)的重要問題。通過分析，我們在傳統(tǒng)RBAC模型中引入了群組(Group)的概念，并進行擴展。群組解決了用戶量大時，手工指派角色繁瑣的情況?？梢灾苯訉⒔巧概山o群組，這樣，組內(nèi)的用戶便具有用戶組的所有權(quán)限，實現(xiàn)了批處理的功能。而且在現(xiàn)實情況下，群組的概念還可以與實際的組織結(jié)構(gòu)相對應(yīng)，如操作員組、廣告主組等。這樣，管理方便，且更加符合邏輯，因此具有很高的現(xiàn)實意義。擴展后的RBAC模型如圖3-2所示:圖3.2擴展的RBAC模型需要指出的是，在實際環(huán)境中，可能會有一些特殊情況發(fā)生，比如用戶由于某種需要，必須要擔(dān)當(dāng)多種角色，或者用戶臨時崗位調(diào)動，短時間內(nèi)還會調(diào)回原位。這時，如果依然按照常規(guī)的方法，即將權(quán)限下放給一特定角色，再由角分配給用戶或群組，成本將會提高，很不合理。針對這種情況，我們設(shè)計了另一種策略，即用戶直接由系統(tǒng)授權(quán)，繞過角色授權(quán)這一環(huán)節(jié)。這種方式簡單易行，代碼實現(xiàn)也比較容易。當(dāng)然，它也有一定弊端，這種方式的引入會造成系統(tǒng)管理更加復(fù)雜。因此，在實際工作中，我們應(yīng)該權(quán)衡利弊，采用最合適的方法，使系統(tǒng)的管理最高效。3.3.擴展后的RBAC模型的優(yōu)點通過上一節(jié)的介紹，我們總結(jié)該擴展RBAC模型的優(yōu)點，如下:1)通過對資源進行詳細(xì)分類，并在系統(tǒng)中使用目錄樹的表示方式，可以實現(xiàn)靈活的細(xì)粒度訪問控制，功能對象的控制到頁面的元素級別，數(shù)據(jù)對象的控制到目錄級別。2)使用“用戶+群組+角色”的權(quán)限控制策略，管理方便。群組可以與部門等組織結(jié)構(gòu)相關(guān)聯(lián)，是自然存在的屬性，符合生產(chǎn)中的實際情況。3)對于某些特殊的系統(tǒng)需求，該模型也有相應(yīng)的處理機制，處理靈活。4)擴展RBAC模型的維護簡單，當(dāng)組織結(jié)構(gòu)發(fā)生變化時，只需改變?nèi)航M的相關(guān)信息即可。4改進后的模型在系統(tǒng)里的實現(xiàn)4.1系統(tǒng)總體架構(gòu)我們的系統(tǒng)是一個基于Web的管理系統(tǒng)，因此在系統(tǒng)架構(gòu)上，也要遵循一些Web系統(tǒng)的特性。在客戶端，我們采用HTML進行頁面結(jié)構(gòu)的顯示，采用CSS進行頁面的渲染工作，在控制用戶行為方面，選取了優(yōu)秀的C#的Asp.Net框架ExtJs進行相關(guān)控制。在服務(wù)器端，PHP語言由于其快捷、高效的性能被我們所采用。在具體實施上，選取了基于MVC模式的C#框架Asp.Net進行開發(fā)工作。在后臺數(shù)據(jù)庫的選型上，我們選擇了SQL數(shù)據(jù)庫。4.2Asp.Net架構(gòu)Asp.Net一種由Netscape的LiveScript發(fā)展而來的客戶端腳本語言。它的主要特點包括原型化繼承、面向?qū)ο?、支持動態(tài)類型等。Asp.Net解決了服務(wù)器端語言遺留的速度問題，從而司一以為用戶提供更流暢的用戶體驗。我們不需要任何框架就能編寫富客戶端的應(yīng)用程序。但是，由于多種瀏覽器支持不同的Web標(biāo)準(zhǔn)，所以在實際中，編寫跨瀏覽器的應(yīng)用程序，并不是一件容易的事情。Asp.Net框架是一組函數(shù)庫，它可以輕松生成跨瀏覽器的代碼。每一種框架都在眾多流行的Web瀏覽器土進行了可靠性測試，因此，我們不必?fù)?dān)心出現(xiàn)原生、IavaScript出現(xiàn)的瀏覽器兼容性問題，我們的代碼可以在不同瀏覽器之問進行類似的操作。此外，除了解決瀏覽器兼容性問題外，在共他Asp.Nett操作方面，如DOM遍歷、事件處理等，Asp.Net框架也提供了一種通用的函數(shù)調(diào)用接口，使我們可以更方便快捷的進行相關(guān)操作。更為重要的是，Asp.Net框架在最近幾年的Web開發(fā)中變得日益流行。與其他問題類似，每種瀏覽器處理x的方式不盡相同，這往往使問題變得復(fù)雜。而Asp.Net框架完美地解決了這個問題，在跨瀏覽器的基礎(chǔ)上，何種框架提供了相關(guān)庫函數(shù)，以支持Ajax對象的請求和響應(yīng)。Ajax的全稱是AsynchronousAScriptandXML，即異步Asp.Net和XML，是指一種創(chuàng)建交互式網(wǎng)頁應(yīng)用的網(wǎng)頁開發(fā)技術(shù)。在傳統(tǒng)的Web應(yīng)用中，用戶填寫表單并提交后，服務(wù)器會根據(jù)請求的數(shù)據(jù)內(nèi)容進行響應(yīng)，并將處理后的頁面返回給客戶端。此時，客戶端會銷毀當(dāng)前頁面并載入新的頁而。其實這種方式大大浪費了網(wǎng)絡(luò)帶寬，因為在不同的Web頁面中，HTML代碼有很多是重復(fù)的，這降低了頁面處理的速度。Ajax則采用不同的機制，它只對需要的數(shù)據(jù)進行操作。Ajax通常采用Json或XML作為數(shù)據(jù)的交換格式，而在客戶端，它采用Asp.Net處理服務(wù)器端的響應(yīng)數(shù)據(jù)。由于在瀏覽器和服務(wù)器之間交換的數(shù)據(jù)量少，因此Ajax減輕了服務(wù)器的負(fù)載，并提高了處理速度。這也是Ajax可以提供更高響應(yīng)速度、更好用戶體驗應(yīng)用程序的根本原因。圖4-1展現(xiàn)了傳統(tǒng)的Web應(yīng)用模型與Ajax方式的Web應(yīng)用模型的異同。圖4-1傳統(tǒng)Web應(yīng)用模型與AjaxWeb應(yīng)用模型比較總結(jié)來說，Ajax程序的優(yōu)勢在于:1)客戶端與服務(wù)器端進行異步交互，提升了用戶體驗。2)有效減少了客戶端和}l}務(wù)器端之間的傳輸數(shù)據(jù)量，減少了帶寬占用。3)借助Asp.Net引擎可以運行在客戶端，并承擔(dān)了部分服務(wù)器的工作量，大量減少了服務(wù)器負(fù)載。此外，需要說明的是，一個經(jīng)典的Ajax請求，主要分為以下四個步驟:1)創(chuàng)建Ajax的請求，要兼顧多種瀏覽器的兼容性問題。2)如果需要的話，利用請求對象的onreadystatechange屬性設(shè)置回調(diào)函數(shù)callback3)利用open方法進行Ajax請求參數(shù)的參數(shù)，如參數(shù)傳遞方式、請求url地址、是否需要異步方式等。4)利用send方法進行勺ax請求。需要注意的是，如果采用GET方法進參數(shù)傳遞，那么send方法將不帶有任何參數(shù)，如果采用POST方法，則請求參數(shù)將會作為send方法的唯一參數(shù)發(fā)送出去正是由于Ajax有著諸多優(yōu)點，因此它成為了客戶端應(yīng)用開發(fā)必需的前端技術(shù)。當(dāng)前主流的Asp.Net框架，包括Prototype,jQuery,YUI,ExtJs}GlMooTools等，它們各有特點，并適用于不同的場景。其中，Ext1s框架是用Asp.NetCSS和HTML等技術(shù)實現(xiàn)的主要用于創(chuàng)建用戶界面、且與后臺技術(shù)無關(guān)的前端勺ax框架，還被用來開發(fā)RIA的Web應(yīng)用。無論是從WebUI界面美觀豐富上，還是從功能強大完善上看來，ExtJs都可以算得上是WebUI組件庫方面的佼佼者，同時也是一款不可多得的Asp.Net客戶端技術(shù)的精品之作。在所有ExtJs的UI組件中，Grid組件是使用最頻繁、功能最復(fù)雜、同時也是實現(xiàn)最好的。單選行、多選行、高亮顯示選中的行、拖拽改變列寬度、按列排序，這些功能只能算是Grid組件的基本功能。支持。heckbox全選、動態(tài)選擇顯示哪些列、對單元格按照自己的意愿進行渲染等，這些應(yīng)該算是一個功能較強的Grid組件應(yīng)該擁有的功能，而ExtJs的Grid組件都具備。當(dāng)然，Grid組件并不是ExtJs的全部，實際上，ExtJs提供了非常豐富的組件庫，可以分為基本組件、表單及元素組件、圖表組件3大類多達(dá)100多種組件，再加上各種各樣的擴展非官方組件和可選組件，基本上滿足了開發(fā)RIA應(yīng)用的各種需求。最然每一個組件不可能都如Grid組件一樣令人驚訝，但是見微知著，ExtJs的其他組件不管是從UI表現(xiàn)上還是功能上都是非常的出色?，F(xiàn)在越來越多的其他WebUI組件庫都在向ExtJs學(xué)習(xí)或看齊，這其中尤以與功能。所以，ExtJs的組件極有可能成為開發(fā)RIA應(yīng)用事實上的UI標(biāo)準(zhǔn)。4.3數(shù)據(jù)字典的設(shè)計我們的系統(tǒng)采用MySQL數(shù)據(jù)庫進行數(shù)據(jù)的存儲MySQL數(shù)據(jù)庫是當(dāng)前最流行的關(guān)系型數(shù)據(jù)庫之一，它的特點除了安全性能高、數(shù)據(jù)處理速度快之外，還提供分布式數(shù)據(jù)庫能力、支持大量媒體數(shù)據(jù)等功能，因此，MySQL數(shù)據(jù)庫成為了許多信息化系統(tǒng)的首選。整體E-R圖的設(shè)計如下：圖4.3整體E-R圖由圖4-3可以看出，整個數(shù)據(jù)字典包括如下幾張數(shù)據(jù)表:1)權(quán)限表(powerinfo)2)角色表(role)3)角色一權(quán)限關(guān)聯(lián)表(role-power)4))刃戶表(user)5)用戶一權(quán)限關(guān)聯(lián)表(user-power)6)用戶登錄日志表(userlog)7)群組表(group)8)用戶一群組關(guān)聯(lián)表(user-group)其中，權(quán)限表用來記錄與系統(tǒng)權(quán)限有關(guān)的信息，角色表用來記錄系統(tǒng)的各類角色，二者通過角色一權(quán)限表進行關(guān)聯(lián)。用戶表的地位與角色表類似，也是通過單獨的一張數(shù)據(jù)表進行關(guān)聯(lián)。用戶登陸日志表用來記錄用戶的系統(tǒng)行為，例如何時登錄系統(tǒng)、何時進行了何種操作等。群組表用來記錄與用戶組相關(guān)的信息，同樣，也是通過用戶一群組表進行關(guān)聯(lián)的。4.4權(quán)限表的設(shè)計在基于RBAC的軟件系統(tǒng)中，我們根據(jù)系統(tǒng)需求和自主設(shè)計，將整個系統(tǒng)功能分為若干模塊，并將它們進行分級。例如，我們將在系統(tǒng)主頁面中能看到的各項功能定義為一級功能，點擊一級功能進入到的頁面功能定義為二級功能，點擊二級功能進入到的頁面功能定義為三級功能，以此類推。由于每一級功能模塊對應(yīng)一定的訪問權(quán)限，我們將這種關(guān)系映射到數(shù)據(jù)庫的權(quán)限表中加以保存。各級功能存儲的形式如圖4-9所示:圖4.4數(shù)據(jù)庫里的權(quán)限表4.5角色表的控制角色表用來存儲與系統(tǒng)中的角色有關(guān)的信息，包括角色名稱、創(chuàng)建時間等，一張完整的角色表結(jié)構(gòu)如表4-5所示:表4-5角色表其中:1)Roleld是主鍵，用于唯一標(biāo)識該表2)RoleName表示角色名稱，在營業(yè)廳聯(lián)播系統(tǒng)中，角色名稱包括超級管理員、普通管理員等。3)Operatorld用來記錄創(chuàng)建該角色的操作員id，當(dāng)其值為一1時，表示操作員是系統(tǒng)管理員。4)SysRoleld表示是否要啟用系統(tǒng)角色。當(dāng)值為1時表示啟用系統(tǒng)角色的功能，值為0表示不啟用。5系統(tǒng)模塊的詳細(xì)設(shè)計5.1登陸認(rèn)證模塊的設(shè)計系統(tǒng)登錄界面如下圖所示：圖5.1登錄認(rèn)證界面登錄認(rèn)證模塊是用戶進入系統(tǒng)的入口，因此對它設(shè)計的好壞將會對整個系統(tǒng)安全產(chǎn)生重大的影響。同其他Web系統(tǒng)的設(shè)計方法一樣，它也涉及前端的HTML,CSS和JavaScrspt，而在服務(wù)器端，PHP進行業(yè)務(wù)邏輯的控制，數(shù)據(jù)庫則負(fù)責(zé)用戶登錄信息的存儲工作。對于登錄頁面的設(shè)計，我們遵循兩個基本的原則:1}安全性。這是所有Web系統(tǒng)的最基本要素，畢竟系統(tǒng)面向的是網(wǎng)絡(luò)中所有用戶，此時任何一個看似渺小的漏洞都會被不斷放大，并對系統(tǒng)木身造成重大影響。比如，利用XSS進行跨站腳本攻擊，用戶可以輕易的繞過認(rèn)證流程而進入到系統(tǒng)中，這對系統(tǒng)來說是一個潛在的安全隱患。因此，安全性，看似簡單，同時也是最重要、最難設(shè)計的一個環(huán)節(jié)。2)簡潔性。由于登錄模塊只是一個鑒權(quán)認(rèn)證的頁面，即進入系統(tǒng)的一個通道，它本身不應(yīng)具備任何其他信息。因此，對該模塊的設(shè)計沒有必要過于繁瑣。在安全性的基礎(chǔ)上，盡量做到簡單、實用即可。由此，我們設(shè)計了系統(tǒng)登錄認(rèn)證的流程圖:圖5.1系統(tǒng)流程圖其中ExtJs進行Ajax請求的功能模塊，調(diào)用了ExtJs的Ext.Ajax組件，該組件是一個Ext.data.Connection單例對象，提供了使用Ajax請求的簡單路徑，并具有最大的靈活性。在服務(wù)器端依然采用MVC模式進行請求響應(yīng)。5.2角色管理模塊的設(shè)計針對系統(tǒng)的特點和RBAC的基本概念，對于角色的設(shè)計，我們有如下原則需要遵循:1)角色需要有分層關(guān)系。例如“中心經(jīng)理”的角色包含“部門經(jīng)理”的角色，這表示一個層級的關(guān)系。那么“部門經(jīng)理”所擁有的全部權(quán)限，“中心經(jīng)理”也應(yīng)具有。這一原則保證了系統(tǒng)中角色的層級監(jiān)控和管理。2)角色需要互斥的關(guān)系。表示如果兩種角色具有互斥的關(guān)系，那么它們不同被同時賦予給同一用戶。這條原則保證了系統(tǒng)安全，并且與現(xiàn)實生活中的情況一致。另外，我們還規(guī)定一個客體它在未經(jīng)授權(quán)的情況下是不能擁有某一個活躍的角色的。3)角色還具有繼承的關(guān)系。表示該角色可以擁有被繼承角色的所有權(quán)限。另外，互斥關(guān)系也是可以被繼承的。根據(jù)以上闡述的設(shè)計原則，我們將角色與權(quán)限形成直接的映射關(guān)系，角色管理的相關(guān)操作在Table層只針對角色表、權(quán)限表和角色一權(quán)限關(guān)聯(lián)表。圖5.2角色控制模塊詳圖部分關(guān)鍵代碼如下<!DOCTYPEhtmlPUBLIC"-//W3C//DTDXHTML1.0Transitional//EN""/TR/xhtml1/DTD/xhtml1-transitional.dtd"><htmlxmlns="/1999/xhtml"><head><title></title><styletype="text/css">body{margin-left:3px;margin-top:0px;margin-right:3px;margin-bottom:0px;}.th{height:25px;background:#d3eaef;text-align:center;font-size:12px;font-weight:bold;}.td{height:25px;background:#ffffff;color:#344b50;text-align:center;font-size:12px;}.STYLE1{color:#e1e2e3;font-size:12px;}.STYLE1a{color:#e1e2e3;font-size:12px;}.STYLE2{font-size:12px;color:#295568;text-align:center;line-height:30px;vertical-align:middle;}.STYLE3{vertical-align:top;}.STYLE4{vertical-align:top;}</style><scripttype="text/javascript">varhighlightcolor='#d5f4fe';varclickcolor='#51b2f6';functionchangeto(){source=event.srcElement;if(source.tagName=="TR"||source.tagName=="TABLE")return;while(source.tagName!="TD")source=source.parentElement;source=source.parentElement;cs=source.children;//alert(cs.length);if(cs[1].style.backgroundColor!=highlightcolor&&source.id!="nc"&&cs[1].style.backgroundColor!=clickcolor)for(i=0;i<cs.length;i++){cs[i].style.backgroundColor=highlightcolor;}}functionchangeback(){if(event.fromElement.contains(event.toElement)||source.contains(event.toElement)||source.id=="nc")returnif(event.toElement!=source&&cs[1].style.backgroundColor!=clickcolor)//source.style.backgroundColor=originalcolorfor(i=0;i<cs.length;i++){cs[i].style.backgroundColor="";}}functionclickto(){source=event.srcElement;if(source.tagName=="TR"||source.tagName=="TABLE")return;while(source.tagName!="TD")source=source.parentElement;source=source.parentElement;cs=source.children;//alert(cs.length);if(cs[1].style.backgroundColor!=clickcolor&&source.id!="nc")for(i=0;i<cs.length;i++){cs[i].style.backgroundColor=clickcolor;}elsefor(i=0;i<cs.length;i++){cs[i].style.backgroundColor="";}}functionselectAll(obj){varinput=document.getElementsByTagName("input");for(i=0;i<input.length;i++){if(input[i].type=="checkbox")input[i].checked=obj.checked;}}</script></head>5.3用戶控制模塊的設(shè)計圖5.3用戶控制界面可以看出，界面總共分為左右兩欄。其中，左側(cè)欄表示的是用戶的分組與數(shù)據(jù)字典中的群組表相對應(yīng)。同樣，群組信息、以樹形結(jié)構(gòu)進行展現(xiàn)，并且是按照實際的行政部門進行劃分的，更符合實際情況。右側(cè)欄則是用戶列表，與角色列表類似，用戶列表也具有新建、刪除和編輯功能。并且，用戶的相關(guān)信息也會有所展現(xiàn)。如圖所示，名為“wxm”的用戶，他屬于“超級管理員”的角色，因此該用戶繼承了“超級管理員”的所有權(quán)限。但是，由于用戶的自身特點，他不能擁有某些權(quán)限。此時，只需在系統(tǒng)中自定義權(quán)限，通過勾選的方式設(shè)置即可。需要指出的是，根據(jù)圖3-2擴展RBAC模型所示，當(dāng)存在系統(tǒng)需求時，我們可以進行用戶直接授權(quán)。這一操作相當(dāng)于繞過了角色權(quán)限授予的流程，使用戶直接與權(quán)限形成對應(yīng)關(guān)系。在具體實現(xiàn)上，它其實與其他子功能模塊并無很大區(qū)別，只是省略了相應(yīng)步驟，并對用戶表、用戶一權(quán)限表和權(quán)限表進行操作。系統(tǒng)默認(rèn)直接授權(quán)的用戶擁有所有權(quán)限，根據(jù)用戶的需求進行自定義設(shè)置。對于用戶管理模塊的設(shè)計，有一個原則是，一名用戶只能交由一個執(zhí)行者進行操作，如果一個執(zhí)行者可以以對多名用戶的身份進行操作，那么權(quán)限管理的作用將大大削減。另外，由于用戶所屬角色擁有的權(quán)限是該用戶權(quán)限的最大集合，因此，用戶權(quán)限無法超越其角色的權(quán)限。這是通過在Table層聯(lián)查用戶表、角色表和權(quán)限表來進行控制的。屬于同一角色的不同用戶可以根據(jù)自身特點在權(quán)限集合內(nèi)任意設(shè)置權(quán)限而不必相互一致，這大大增加了系統(tǒng)的靈活性，方便用戶根據(jù)需求進行自定義設(shè)置。另外，用戶管理功能還支持群組，便于日常管理。用戶管理各功能模塊的關(guān)系如圖5.4所示:圖5.4用戶組身份控制6論文總結(jié)傳統(tǒng)的訪問控制策略包括自主訪問控制策略(DAC)和強制訪問控制策略(MAC)兩種。但是它們都存在一定缺陷。自主訪問控制的缺點在于對系統(tǒng)管理員來說，難以從總體上對系統(tǒng)數(shù)據(jù)資源權(quán)限進行管理。而強制訪問控制策略的不足是對于安全性能要求高、并且相對簡單的專用系統(tǒng)來說，它是一種比較有效的機制，但是對于那些通用的大型系統(tǒng)，強制訪問控制策略就不是十分合適。RBAC模型的出現(xiàn)取代了DAC和MAC這兩種傳統(tǒng)訪問控制策略。它的基本思想是引入角色的概念，并將其分別與權(quán)限和用戶相關(guān)聯(lián)，從而形成權(quán)限到角色再到用戶的結(jié)構(gòu)，以此實現(xiàn)用戶對受限資源的訪問。由于RBAC模型將用戶與權(quán)限相分離，因此為權(quán)限的管理提供了很大的便利。在實際生產(chǎn)環(huán)境中，RBAC模型也得到了極大的推廣，是當(dāng)前主流的權(quán)限管理策略。但是，盡管RBAC是一個相對完善的模型，但是隨著信息系統(tǒng)規(guī)模的不斷增大和用戶數(shù)以及交互數(shù)據(jù)量的日益增加，RBAC模型本身也暴露出許多難以克服的問題，包括無法深層次、細(xì)粒度的進行權(quán)限管理，無法體現(xiàn)部門或者群組這樣的自然屬性實體等。因此，針對本課題涉及的基于RBAC的軟件系統(tǒng)，設(shè)計一個專有的擴展RBAC模型，是必要的。本文從RBAC模型入手，對權(quán)限管理策略進行了深入地研究。并針對營業(yè)廳聯(lián)播系統(tǒng)的特點，在重點分析系統(tǒng)需求和用戶關(guān)系的基礎(chǔ)上，依據(jù)RBAC模型的設(shè)計原則，給出了一個可擴展的、專有的RBAC模型，并在該系統(tǒng)中得到了具體實現(xiàn)。論文做了以下兒個方面的工作:1)了解論文背景，熟悉系統(tǒng)的基本需求，并學(xué)習(xí)在具體功能現(xiàn)上所采用的設(shè)計模式，如MVC模式等。2)深入研究RBAC模型。包括RBAC模型的基本概念、基本特點等。并在此基礎(chǔ)上研究RBAC模型的衍生模型等，比較這些模型的異同、各自的適用場景等。3)總結(jié)RBAC模型的優(yōu)缺點，闡述對RBAC模型進行擴展的必要性。并針對系統(tǒng)的特點和需求，提出“群組”和“直接授權(quán)”的概念，擴展了RBAC模型。4)對系統(tǒng)進行開發(fā)工作。工作內(nèi)容包括針對系統(tǒng)的特點設(shè)計據(jù)庫ER圖、對ASP.NET框架和C#框架進行選型等，目的是最大限度的滿足系統(tǒng)需求。并嚴(yán)格依模塊的具體開發(fā)，包括登錄認(rèn)前面設(shè)計的擴展RBAC模型進行各功能模塊、角色管理模塊和用戶管理模塊