我的Blog我做主^_^

          走向一條通往JAVA的不歸路...

            BlogJava :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
            64 隨筆 :: 68 文章 :: 77 評論 :: 0 Trackbacks

            基于RBAC模型的權(quán)限管理系統(tǒng)的設(shè)計和實現(xiàn)

          作者:裴輝東 梁云風(fēng)  來源:網(wǎng)絡(luò)

          摘要:提出了基于RBAC模型的權(quán)限管理系統(tǒng)的設(shè)計和實現(xiàn)方案。介紹了采用的J2EE架構(gòu)的多層體系結(jié)構(gòu)設(shè)計,闡述了基于角色的訪問控制RBAC模型的設(shè)計思想,并討論了權(quán)限管理系統(tǒng)的核心面向?qū)ο笤O(shè)計模型,以及權(quán)限訪問、權(quán)限控制和權(quán)限存儲機制等關(guān)鍵技術(shù)。

           關(guān)鍵詞:權(quán)限管理系統(tǒng);角色;訪問控制;RBAC模型;J2EELDAP

           0 引言

           管理信息系統(tǒng)是一個復(fù)雜的人機交互系統(tǒng),其中每個具體環(huán)節(jié)都可能受到安全威脅。構(gòu)建強健的權(quán)限管理系統(tǒng),保證管理信息系統(tǒng)的安全性是十分重要的。權(quán)限管理系統(tǒng)是管理信息系統(tǒng)中可代碼重用性最高的模塊之一。任何多用戶的系統(tǒng)都不可避免的涉及到相同的權(quán)限需求,都需要解決實體鑒別、數(shù)據(jù)保密性、數(shù)據(jù)完整性、防抵賴和訪問控制等安全服務(wù)(據(jù)ISO7498-2)。例如,訪問控制服務(wù)要求系統(tǒng)根據(jù)操作者已經(jīng)設(shè)定的操作權(quán)限,控制操作者可以訪問哪些資源,以及確定對資源如何進(jìn)行操作。

           目前,權(quán)限管理系統(tǒng)也是重復(fù)開發(fā)率最高的模塊之一。在企業(yè)中,不同的應(yīng)用系統(tǒng)都擁有一套獨立的權(quán)限管理系統(tǒng)。每套權(quán)限管理系統(tǒng)只滿足自身系統(tǒng)的權(quán)限管理需要,無論在數(shù)據(jù)存儲、權(quán)限訪問和權(quán)限控制機制等方面都可能不一樣,這種不一致性存在如下弊端:

           a.系統(tǒng)管理員需要維護(hù)多套權(quán)限管理系統(tǒng),重復(fù)勞動。
           b.用戶管理、組織機構(gòu)等數(shù)據(jù)重復(fù)維護(hù),數(shù)據(jù)一致性、完整性得不到保證。
           c.由于權(quán)限管理系統(tǒng)的設(shè)計不同,概念解釋不同,采用的技術(shù)有差異,權(quán)限管理系統(tǒng)之間的集成存在問題,實現(xiàn)單點登錄難度十分大,也給企業(yè)構(gòu)建企業(yè)門戶帶來困難。

           采用統(tǒng)一的安全管理設(shè)計思想,規(guī)范化設(shè)計和先進(jìn)的技術(shù)架構(gòu)體系,構(gòu)建一個通用的、完善的、安全的、易于管理的、有良好的可移植性和擴(kuò)展性的權(quán)限管理系統(tǒng),使得權(quán)限管理系統(tǒng)真正成為權(quán)限控制的核心,在維護(hù)系統(tǒng)安全方面發(fā)揮重要的作用,是十分必要的。

           本文介紹一種基于角色的訪問控制RBACRole-Based policies Access Control)模型的權(quán)限管理系統(tǒng)的設(shè)計和實現(xiàn),系統(tǒng)采用基于J2EE架構(gòu)技術(shù)實現(xiàn)。并以討論了應(yīng)用系統(tǒng)如何進(jìn)行權(quán)限的訪問和控制。

           1 采用J2EE架構(gòu)設(shè)計

           采用J2EE企業(yè)平臺架構(gòu)構(gòu)建權(quán)限管理系統(tǒng)。J2EE架構(gòu)集成了先進(jìn)的軟件體系架構(gòu)思想,具有采用多層分布式應(yīng)用模型、基于組件并能重用組件、統(tǒng)一完全模型和靈活的事務(wù)處理控制等特點。

           系統(tǒng)邏輯上分為四層:客戶層、Web層、業(yè)務(wù)層和資源層。

           a. 客戶層主要負(fù)責(zé)人機交互。可以使系統(tǒng)管理員通過Web瀏覽器訪問,也可以提供不同業(yè)務(wù)系統(tǒng)的APIWeb Service調(diào)用。
           b. Web層封裝了用來提供通過Web訪問本系統(tǒng)的客戶端的表示層邏輯的服務(wù)。
           c. 業(yè)務(wù)層提供業(yè)務(wù)服務(wù),包括業(yè)務(wù)數(shù)據(jù)和業(yè)務(wù)邏輯,集中了系統(tǒng)業(yè)務(wù)處理。主要的業(yè)務(wù)管理模塊包括組織機構(gòu)管理、用戶管理、資源管理、權(quán)限管理和訪問控制幾個部分。
           d. 資源層主要負(fù)責(zé)數(shù)據(jù)的存儲、組織和管理等。資源層提供了兩種實現(xiàn)方式:大型關(guān)系型數(shù)據(jù)庫(如ORACLE)和LDAPLight Directory Access Protocol,輕量級目錄訪問協(xié)議)目錄服務(wù)器(如微軟的活動目錄)。
           2 RBAC模型

           訪問控制是針對越權(quán)使用資源的防御措施。基本目標(biāo)是為了限制訪問主體(用戶、進(jìn)程、服務(wù)等)對訪問客體(文件、系統(tǒng)等)的訪問權(quán)限,從而使計算機系統(tǒng)在合法范圍內(nèi)使用;決定用戶能做什么,也決定代表一定用戶利益的程序能做什么[1]

           企業(yè)環(huán)境中的訪問控制策略一般有三種:自主型訪問控制方法、強制型訪問控制方法和基于角色的訪問控制方法(RBAC)。其中,自主式太弱,強制式太強,二者工作量大,不便于管理[1]。基于角色的訪問控制方法是目前公認(rèn)的解決大型企業(yè)的統(tǒng)一資源訪問控制的有效方法。其顯著的兩大特征是:1.減小授權(quán)管理的復(fù)雜性,降低管理開銷;2.靈活地支持企業(yè)的安全策略,并對企業(yè)的變化有很大的伸縮性。

           NISTThe National Institute of Standards and Technology,美國國家標(biāo)準(zhǔn)與技術(shù)研究院)標(biāo)準(zhǔn)RBAC模型由4個部件模型組成,這4個部件模型分別是基本模型RBAC0Core RBAC)、角色分級模型RBAC1Hierarchal RBAC)、角色限制模型RBAC2Constraint RBAC)和統(tǒng)一模型RBAC3Combines RBAC[1]RBAC0模型如圖1所示。

           
           圖1 RBAC0模型

           a. RBAC0定義了能構(gòu)成一個RBAC控制系統(tǒng)的最小的元素集合。在RBAC之中,包含用戶users(USERS)、角色roles(ROLES)、目標(biāo)objects(OBS)、操作operations(OPS)、許可權(quán)permissions(PRMS)五個基本數(shù)據(jù)元素,權(quán)限被賦予角色,而不是用戶,當(dāng)一個角色被指定給一個用戶時,此用戶就擁有了該角色所包含的權(quán)限。會話sessions是用戶與激活的角色集合之間的映射。RBAC0與傳統(tǒng)訪問控制的差別在于增加一層間接性帶來了靈活性,RBAC1RBAC2RBAC3都是先后在RBAC0上的擴(kuò)展。

           b. RBAC1引入角色間的繼承關(guān)系,角色間的繼承關(guān)系可分為一般繼承關(guān)系和受限繼承關(guān)系。一般繼承關(guān)系僅要求角色繼承關(guān)系是一個絕對偏序關(guān)系,允許角色間的多繼承。而受限繼承關(guān)系則進(jìn)一步要求角色繼承關(guān)系是一個樹結(jié)構(gòu)。

           c. RBAC2模型中添加了責(zé)任分離關(guān)系。RBAC2的約束規(guī)定了權(quán)限被賦予角色時,或角色被賦予用戶時,以及當(dāng)用戶在某一時刻激活一個角色時所應(yīng)遵循的強制性規(guī)則。責(zé)任分離包括靜態(tài)責(zé)任分離和動態(tài)責(zé)任分離。約束與用戶-角色-權(quán)限關(guān)系一起決定了RBAC2模型中用戶的訪問許可。

           d. RBAC3包含了RBAC1RBAC2,既提供了角色間的繼承關(guān)系,又提供了責(zé)任分離關(guān)系。

           3核心對象模型設(shè)計

           根據(jù)RBAC模型的權(quán)限設(shè)計思想,建立權(quán)限管理系統(tǒng)的核心對象模型。如圖2所示。

          對象模型中包含的基本元素主要有:用戶(Users)、用戶組(Group)、角色(Role)、目標(biāo)(Objects)、訪問模式(Access Mode)、操作(Operator)。主要的關(guān)系有:分配角色權(quán)限PAPermission Assignment)、分配用戶角色UAUsers Assignmen描述如下:

            


           

          深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。

          作者:johnnylzb 發(fā)表時間:2008年02月03日 15:49 回復(fù)此消息回復(fù)

          原貼網(wǎng)址: http://www.jdon.com/jivejdon/thread/33471.html

          本人最近正在為公司的多個項目(包括未來項目)做通用的權(quán)限組件,在本論壇上看到”dunel”大俠的一個帖子 http://www.jdon.com/jivejdon/thread/13450.html,然后才注冊并發(fā)表此 話題,歡迎大家耐心閱讀并指正。

          目前已經(jīng)發(fā)布了一個版本并供幾個項目使用,先簡單介紹一下組件的情況:

          1.模式:建立在RBAC理論技術(shù)上的權(quán)限模式

          2.技術(shù):是以Java編寫的一個組件(計劃在下一個版本做成一個框架)

          3.結(jié)構(gòu):包括兩部分:
          (A)權(quán)限配置管理平臺,一個Web應(yīng)用(即一個war包),用于注冊受控資源,管理角色,和授權(quán)(把角色指派給宿主系統(tǒng)的用戶),本平臺是可選的
          (B)權(quán)限服務(wù)組件,一個嵌入式組件(即一個jar包),提供訪問控制服務(wù)和權(quán)限配置服務(wù)(后者供宿主系統(tǒng)通過接口調(diào)用實現(xiàn)權(quán)限配置管理,可以代替權(quán)限配置管理平臺)

          4.實現(xiàn)機制:權(quán)限相關(guān)數(shù)據(jù)與宿主系統(tǒng)的數(shù)據(jù)邏輯上式獨立的,宿主系統(tǒng)通過嵌入權(quán)限組件,本地調(diào)用組件提供的相關(guān)服務(wù)接口實現(xiàn)權(quán)限配置管理和訪問控制,組件提供四種服務(wù):
          (A)授權(quán)服務(wù):用戶訪問宿主系統(tǒng)的受控資源時,宿主系統(tǒng)把用戶ID和被訪問資源ID傳遞到授權(quán)服務(wù)接口,授權(quán)服務(wù)接口返回是否可以訪問的結(jié)果信息,宿主系統(tǒng)可以一次加載用戶的所有權(quán)限信息,也可以在每次用戶訪問時才調(diào)用授權(quán)服務(wù)接口。
          (B)實體管理服務(wù):提供受控資源(實體)的增、刪、改、查等管理服務(wù)。
          (C)角色管理服務(wù):提供角色的增、刪改、查管理服務(wù)和為角色配置受控資源的服務(wù)
          (D)授權(quán)管理服務(wù):提供為宿主系統(tǒng)用戶指派、移除角色的服務(wù)。
          宿主系統(tǒng)可以把UI相關(guān)的實體名以URI來注冊,權(quán)限組件提供默認(rèn)的Filter進(jìn)行攔截,對API的實體名以API對應(yīng)的方法名的全限定名進(jìn)行注冊,權(quán)限組件提供默認(rèn)的Interceptor以AOP的方式進(jìn)行攔截,這樣,宿主系統(tǒng)就不需要在業(yè)務(wù)層和頁面層編寫與權(quán)限控制相關(guān)的代碼,權(quán)限這個功能編程了一個可以切入和移除的Aspect。

          5.功能范圍:目前只能控制功能權(quán)限,數(shù)據(jù)權(quán)限控制還沒實現(xiàn)。

          re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年02月03日 15:50 回復(fù)
          johnnylzb 發(fā)表文章: 18/ 注冊時間: 2008年02月03日 13:41
          在本論壇看到了各位高手的一些關(guān)于權(quán)限模型和實現(xiàn)的討論,覺得受益匪淺,所以本人也想針對權(quán)限控制提出一些本人的觀點和針對一些困難請求解決方案,我的帖子將圍繞以下幾個方面討論:

          RBAC模型和相關(guān)概念
          功能權(quán)限和數(shù)據(jù)權(quán)限
          權(quán)限、角色與組織機構(gòu)、用戶之間的關(guān)系



          1. RBAC模型和相關(guān)概念(以下觀點是本人在理解RBAC模型之后結(jié)合個人意見的觀點,如不合理,請指出并歡迎討論)

          1.1 術(shù)語定義:

          受控資源:系統(tǒng)需要進(jìn)行訪問控制的資源,包括功能性資源和數(shù)據(jù)性資源,所以受控資源分為功能實體和業(yè)務(wù)實體:
          (A)功能實體:從抽象角度來看,用戶(不一定是人,也可以系統(tǒng))使用系統(tǒng)只有兩種途徑:通過UI訪問,如:按鈕、頁面、菜單等;通過API訪問,如服務(wù)接口,DAO接口。經(jīng)過這樣的定義,對功能實體的操作就可以抽象成只有一種:訪問。
          (B)業(yè)務(wù)實體:即宿主業(yè)務(wù)系統(tǒng)相關(guān)的領(lǐng)域模型對象,如房地產(chǎn)交易系統(tǒng)的客戶、樓盤、房間、合同等。對于業(yè)務(wù)實體,其操作可以抽象成四種:增加、刪除、修改、讀取。

          操作行為:對受控資源的操作類型的抽象,對功能實體,操作行為只有“訪問”,對業(yè)務(wù)實體,操作行為有“增加”、“刪除”、“修改”、“讀取”

          權(quán)限:權(quán)限是實體+操作的組合,即“對‘什么資源’執(zhí)行‘什么操作’”,因此,每個功能實體只能有一種權(quán)限,但每個業(yè)務(wù)實體,可以有最多四種權(quán)限。

          角色:角色抽象上跟權(quán)限是同一概念,因為角色是反映用戶可執(zhí)行的權(quán)限,角色實際上是權(quán)限集,因為“人”會頻繁變動,但“角色”卻很少變動,所以才需要引入“角色”這個概念。

          1.2 關(guān)系概念

          實體之間的關(guān)系:實體與實體之間可以表現(xiàn)為從屬關(guān)系和關(guān)聯(lián)關(guān)系。
          (A)從屬關(guān)系,實體可以擁有一個父結(jié)點,多個子結(jié)點,擁有子結(jié)點權(quán)限的前提是必須擁有父結(jié)點權(quán)限,例如“樓盤信息”頁面,擁有“查詢樓盤”、“修改樓盤”兩個按鈕,那么“樓盤信息”頁面這個功能實體就是“查詢樓盤”和“修改樓盤”兩個按鈕功能實體的父結(jié)點,用戶只有在擁有“樓盤信息”頁面的訪問權(quán)的前提下,才可能擁有“查詢樓盤”和“修改樓盤”兩個按鈕的操作權(quán)。
          (B)關(guān)聯(lián)關(guān)系:實體之間的松散耦合關(guān)系,如A頁面內(nèi)嵌了C頁面,B頁面也內(nèi)嵌了C頁面,C既不屬于A,也不屬于B,這種情況,A與C、B與C之間就構(gòu)成了關(guān)聯(lián)關(guān)系。

          角色與實體之間的關(guān)系:角色與實體之間存在多對多關(guān)系

          角色之間的關(guān)系:擴(kuò)展關(guān)系與排斥關(guān)系,建立這些關(guān)系主要是方便管理,對于正向授權(quán),可以使用擴(kuò)展關(guān)系,如角色A擁有1、2、3的權(quán)限,角色B比角色A多擁有4的權(quán)限,則角色B可以擴(kuò)展角色A,然后為它指派4;對于反向授權(quán),可以使用排斥關(guān)系,例子跟前者相反。對于這種關(guān)系還可以進(jìn)一步擴(kuò)展,就是一個角色可以擴(kuò)展自多個角色,也可以排斥多個角色。根據(jù)實際情況,擴(kuò)展關(guān)系比較常用。

          1.3 存在爭議

          【討論點1】其實對“業(yè)務(wù)實體”的操作最終都會表現(xiàn)為一種功能,如:對“合同”執(zhí)行“修改”操作,可以被定位為“修改合同服務(wù)”這樣一個功能,以業(yè)務(wù)接口的方式暴露出來,因為一般的業(yè)務(wù)系統(tǒng)設(shè)計中,業(yè)務(wù)系統(tǒng)并不會把純數(shù)據(jù)的操作(即DAO)直接暴露給外界使用,而是把業(yè)務(wù)接口暴露給用戶使用,用戶只能通過業(yè)務(wù)接口對數(shù)據(jù)進(jìn)行操作,不能直接操作一個業(yè)務(wù)對象。理論上,一個業(yè)務(wù)操作可能對應(yīng)多于一個的業(yè)務(wù)實體的多于一個的操作,舉個例子,刪除一個可售樓盤信息這個業(yè)務(wù),包括了多個業(yè)務(wù)實體操作:可售樓盤+刪除、樓盤的房間+刪除、銷售信息+修改。所以,從更高一層的抽象看待“受控資源”,它可以全部被定義為功能實體,而對受控資源的“操作”,則都可以被抽象成“訪問”。

          【討論點2】基于RBAC的理解模型,還應(yīng)不應(yīng)該允許直接把權(quán)限分配給用戶,從本人的角度來看,由于權(quán)限對于大部分系統(tǒng)都是一個Aspect的問題,因此權(quán)限這個Aspect是不應(yīng)該包括用戶的,即權(quán)限模塊的數(shù)據(jù)模型只有實體、角色及其之間的關(guān)系,用戶作為另外一個Aspect(可以做成一個統(tǒng)一用戶管理模塊),如果只允許把角色與用戶建立關(guān)系,不允許用戶之間指派權(quán)限,則從系統(tǒng)角度來看,“權(quán)限控制”與“用戶管理”作為業(yè)務(wù)系統(tǒng)的兩個Aspect模塊,他們之間的聯(lián)系就會更加簡單和清晰,就是“權(quán)限.角色”-“用戶”。但另外一個問題是,很多時候,管理人員需要為某些特定的用戶在他擁有的角色上根據(jù)實際需要分配多若干個權(quán)限,如果都需求定義角色,就會出現(xiàn)角色泛濫,不便管理了。這是從系統(tǒng)設(shè)計角度與現(xiàn)實情況角度相矛盾的地方。



          2.功能權(quán)限和數(shù)據(jù)權(quán)限

          2.1 概念定義
          功能權(quán)限:在第1點已經(jīng)闡述過,用戶與業(yè)務(wù)系統(tǒng)進(jìn)行交流,一般是面向服務(wù)的,即業(yè)務(wù)系統(tǒng)會把服務(wù)抽象成一個個功能點暴露給用戶,功能權(quán)限實際上就是決定用戶能否使用系統(tǒng)提供的功能點的問題,即“‘誰’對‘什么資源’進(jìn)行‘什么操作’”(而根據(jù)上面的第1點的討論點1,權(quán)限可以被簡化為對功能實體的訪問操作,即“‘誰’訪問‘什么功能實體’”)。

          數(shù)據(jù)權(quán)限:關(guān)于這個概念,有多種說法,有人認(rèn)為對一個對象進(jìn)行不同的操作就表現(xiàn)為數(shù)據(jù)權(quán)限,比如對“論壇帖子”進(jìn)行“閱讀”和“修改”、“刪除”等屬于數(shù)據(jù)權(quán)限,但本人認(rèn)為(結(jié)合第1點的討論點1),這歸根結(jié)底還是功能權(quán)限(或者說,可以被定義為功能權(quán)限)。本人理解的數(shù)據(jù)權(quán)限,是指基于特定用戶的權(quán)限控制,即“‘誰’訪問‘什么資源’當(dāng)中的‘哪些資源’”的問題,舉個例子:分論壇A的版主與分論壇B的版主擁有同樣的角色“版主”,即他們的功能權(quán)限是一致的,但A版主只能管理A論壇的帖子,B版主只能管理B論壇的帖子,這時,RBAC就不能解決這類權(quán)限問題,這種情況,角色就需要與組織結(jié)構(gòu)有所聯(lián)系了。進(jìn)一步,更復(fù)雜的情況:高級經(jīng)理能審批50萬以上的合同,中級經(jīng)理只能審批50萬以下的合同,這就更加需要引入“規(guī)則”進(jìn)行權(quán)限控制了。

          2.2 權(quán)限組件是否(能否)把數(shù)據(jù)權(quán)限控制也納入它的功能范圍

          本人對這點非常困惑,但經(jīng)過各種權(quán)衡,本人設(shè)計的權(quán)限組件還是“暫時”不把數(shù)據(jù)權(quán)限納入通用權(quán)限組件的范疇,理據(jù)如下:

          (A)功能需求上的考慮:“權(quán)限”是一個很大的概念,也和模糊,功能性權(quán)限無可非議,是純權(quán)限的功能,但對于如上述2.1所述兩個例子,就存在角度問題,從權(quán)限功能角度看,它們屬于權(quán)限的功能需求,但從業(yè)務(wù)的角度看,很明顯,上述兩個例子都屬于業(yè)務(wù)規(guī)則,他們的權(quán)限會根據(jù)業(yè)務(wù)的變化而變化的,例如論壇的分版主原來只可以管理本版的數(shù)據(jù),但需求改變了,他也可以管理其他版的數(shù)據(jù);對于第二個例子,變化更加難于控制,可能需要上要求高級經(jīng)理可以審批的金額數(shù)變化了,可能因為經(jīng)理的級別變化了,甚至可能會加入更多的規(guī)則。這兩個例子,后者更加偏向于業(yè)務(wù)規(guī)則,本人覺得這種于業(yè)務(wù)規(guī)則緊密集合的“權(quán)限”,不應(yīng)歸納到“權(quán)限組件”去實現(xiàn),但對于第一個例子,可以通過引入組織機構(gòu)得到一定程度的解決,但這樣也引出了一個新的問題:權(quán)限于組織機構(gòu)的關(guān)系,對于業(yè)務(wù)系統(tǒng)來說,兩者應(yīng)該是兩個獨立的Aspect,還是應(yīng)該整合在一起呢?這個問題在第3點進(jìn)行討論。

          (B)系統(tǒng)設(shè)計上的考慮:系統(tǒng)設(shè)計的原則是功能獨立單一,結(jié)構(gòu)清晰,依賴耦合低,靈活和可擴(kuò)展的。因此,我們目前主要的業(yè)務(wù)系統(tǒng)架構(gòu)是:展示層-業(yè)務(wù)層-數(shù)據(jù)層,把所有業(yè)務(wù)邏輯集中在“業(yè)務(wù)層”統(tǒng)一管理,這樣的好處有:
          功能單一:各層負(fù)責(zé)各層的功能,只要是面向接口通訊,每一層的修改都是獨立的,而且因為功能獨立,也便于維護(hù);
          業(yè)務(wù)封裝:所有業(yè)務(wù)被封裝在業(yè)務(wù)層,使業(yè)務(wù)可以被靈活的組合和重用,業(yè)務(wù)與展示也分離了;
          安全穩(wěn)定:所有業(yè)務(wù)處理被封裝到業(yè)務(wù)層中,無論外界傳遞一些什么破壞性數(shù)據(jù)過來,業(yè)務(wù)層都只做它該做的事,不會做它不該做的事情,例如用戶用戶系統(tǒng)的“修改用戶基本信息”服務(wù),但他嘗試把密碼也修改傳遞過來,而“修改用戶基本信息”這一服務(wù)把所有業(yè)務(wù)邏輯封裝了,它不會受外界影響,接收到用戶信息對象時,即使密碼被改變了,由于它的業(yè)務(wù)邏輯不處理密碼,密碼也不會被修改被持久化到數(shù)據(jù)庫。
          數(shù)據(jù)層獨立:數(shù)據(jù)持久化動作交給數(shù)據(jù)層(通常是DAO)處理,DAO不管業(yè)務(wù),把所有數(shù)據(jù)的訪問都抽象為“增”、“刪”、“改”、“查”,DAO可以被所有業(yè)務(wù)模塊公用,也可以進(jìn)行更換,例如因為性能或成本需要更換持久層ORM框架、更好數(shù)據(jù)庫(更準(zhǔn)確來說是數(shù)據(jù)源)。
          而“權(quán)限”,這作為一個“橫切面”的Aspect,根據(jù)AOP設(shè)計理論,是應(yīng)該從系統(tǒng)的三層結(jié)構(gòu)中分離開來的,三層架構(gòu)是系統(tǒng)的一個“維度”,權(quán)限又是另外一個“維度”,彼此之間只有連接點(JoinPoint),沒有耦合,彼此不可見。從這個角度來看,如果把與業(yè)務(wù)邏輯相關(guān)的所謂“權(quán)限”交給權(quán)限組件去做,則一來業(yè)務(wù)系統(tǒng)對權(quán)限組件依賴變成“硬性依賴”,二來業(yè)務(wù)邏輯被分散管理了。作為系統(tǒng)的設(shè)計人員,你會希望你的開發(fā)人員在修改業(yè)務(wù)邏輯的時候,需要從業(yè)務(wù)層和權(quán)限Aspect把零散的業(yè)務(wù)邏輯收集并理解嗎?一旦將來系統(tǒng)的權(quán)限控制需求發(fā)生改變,需要更換權(quán)限組件,或者需要以硬件的方式來進(jìn)行訪問控制,你是不得不向上級領(lǐng)導(dǎo)申請人月資源去重新編寫你的業(yè)務(wù)邏輯了吧?

          (C)重技術(shù)實現(xiàn)角度考慮,如果需要把這類與業(yè)務(wù)規(guī)則有關(guān)系的數(shù)據(jù)權(quán)限控制交給權(quán)限組件實現(xiàn),那么權(quán)限組件就需要設(shè)計成一個框架,提供標(biāo)準(zhǔn)的接口供業(yè)務(wù)系統(tǒng)根據(jù)不同的業(yè)務(wù)規(guī)則實現(xiàn)不同的訪問控制策略,但需要抽象的定義一套能適應(yīng)各種業(yè)務(wù)規(guī)則的接口(及其傳遞的參數(shù),返回的結(jié)果),并不是一件十分容易的事情(當(dāng)然,并不是不可能)。

          (未完待續(xù)。。。)

          [該貼被johnnylzb于2008-02-03 16:14修改過]

           

          回復(fù):re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年02月03日 19:50 回復(fù)
          banq 發(fā)表文章: 8773/ 注冊時間: 2002年08月03日 17:08
          非常清晰的思路,與我思路基本一致,也指出了一些待討論的地方,比較客觀。JiveJdon3的權(quán)限思路也是基本按照這種思路設(shè)計的。

          >權(quán)限組件是否(能否)把數(shù)據(jù)權(quán)限控制也納入它的功能范圍
          我個人也認(rèn)為數(shù)據(jù)權(quán)限屬于業(yè)務(wù)性質(zhì)范圍,所以,不應(yīng)有納入通用的權(quán)限組件,所以在JiveJdon3中,專門做一個ForumMessageShell來對數(shù)據(jù)權(quán)限進(jìn)行實現(xiàn),而且隨著業(yè)務(wù)變化,可能涉及修改面比較多,因此使用Proxy代理模式。

          這里就體現(xiàn)模式的作用:不能用框架(通用權(quán)限組件)實現(xiàn)的,在微觀上我們有模式來,總體目標(biāo)就是將權(quán)限盡量和業(yè)務(wù)功能分離,框架能夠?qū)崿F(xiàn)最大限度分離,框架無法發(fā)揮作用的,對于數(shù)據(jù)權(quán)限這樣又屬于業(yè)務(wù),又區(qū)別其他特定業(yè)務(wù)功能的,就使用模式對付它。所以,模式和框架是設(shè)計人員最常用的兩個武器(需要進(jìn)階的程序員必須學(xué)好這兩個常用武器)。

          權(quán)限這個問題在本站自開站以來一直在討論,復(fù)雜主要在分析和設(shè)計兩個方面,分析方面我們需要理解RBAC;在設(shè)計實現(xiàn)上,我們需要AOP框架和模式,所以,權(quán)限問題的解決能夠考驗一個程序員的全面素質(zhì)。

          所幸的是,在2007年即將過去,2008年春節(jié)來臨之際,終于看到有人完整地分析設(shè)計了權(quán)限問題,可賀啊。

           

          回復(fù):回復(fù):re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年02月04日 09:32 回復(fù)
          johnnylzb 發(fā)表文章: 18/ 注冊時間: 2008年02月03日 13:41
          謝謝你的回復(fù),很久就知道J道,以前水平太低,對于你的文章我讀不太懂,現(xiàn)在參與Java開發(fā)兩年了,有點心得,才敢在這里發(fā)言,其實我還有很多其他方面(設(shè)計方面,編碼方面)的心得,希望以后多交流

          >我個人也認(rèn)為數(shù)據(jù)權(quán)限屬于業(yè)務(wù)性質(zhì)范圍,所以,不應(yīng)有納入通用的權(quán)限組件,所以在JiveJdon3中,專門做一個ForumMessageShell來對數(shù)據(jù)權(quán)限進(jìn)行實現(xiàn),而且隨著業(yè)務(wù)變化,可能涉及修改面比較多,因此使用Proxy代理模式。

          請問這句話如何理解呢?如何使用Proxy模式呢?還有,針對Proxy,我有一點迷惑,由于我的設(shè)計是權(quán)限組件和用戶管理組件都是宿主系統(tǒng)Aspect方面的問題,而我的權(quán)限組件是依賴于用戶組件的(通過向用戶組件傳遞宿主系統(tǒng)標(biāo)識,獲取該宿主系統(tǒng)的用戶列表,用于把用戶與角色進(jìn)行綁定,即授權(quán)),在我設(shè)計權(quán)限組件的時候,領(lǐng)導(dǎo)還沒有詳細(xì)考慮統(tǒng)一用戶管理組件的問題,于是一個同事就用很短時間寫了一個提供用戶CRUD的組件,我當(dāng)時在想,這個組件是不穩(wěn)定的,不能直接使用,于是我就為權(quán)限組件寫多了一個模塊(com.***.***.proxy.***),這個Proxy的作用是為權(quán)限組件提供足夠的用于與用戶組件打交道的服務(wù)接口(權(quán)限組件并不需要增、刪、改,只需要查),并把用戶組件返回的用戶DO轉(zhuǎn)換成權(quán)限組件自定義的用戶DO,這樣做的目的是,用戶組件不穩(wěn)定,將來肯定會有變化(說不定由本人負(fù)責(zé)設(shè)計),為了屏蔽這些不穩(wěn)定因素,避免因為用戶組件重新設(shè)計而影響權(quán)限組件,所以設(shè)計了一個Proxy來做“中介”,將來用戶組件變化,只需要集中修改Proxy就行。我的這個問題可能是一個“文字問題”,究竟我使用的這種模式,是代理模式,還是適配器模式呢?

          另外,我的討論話題還沒完,其實我還想討論:究竟“權(quán)限”與“組織架構(gòu)”是否應(yīng)該設(shè)計在一起,還是應(yīng)該分開,以及角色、用戶、組織機構(gòu)之間的關(guān)系問題,不過我暫時還沒有想清楚如何條理的表達(dá)我的看法,所以還沒寫出來而已。

           

          回復(fù):回復(fù):回復(fù):re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年02月05日 11:04 回復(fù)
          banq 發(fā)表文章: 8773/ 注冊時間: 2002年08月03日 17:08
          我講proxy主要是指數(shù)據(jù)權(quán)限方面,因為數(shù)據(jù)其實就是業(yè)務(wù)對象,圍繞業(yè)務(wù)對象有其特定的業(yè)務(wù)操作,比如訂單操作,那么對于當(dāng)前這個訂單是只能被創(chuàng)建者操作這樣的權(quán)限,就依靠權(quán)限代理來做。

          代理模式和裝飾器模式有一些區(qū)別,可在本站查詢到,實際應(yīng)用中我們不必太在意這些區(qū)別。

           

          re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年02月17日 11:06 回復(fù)
          codeslave 發(fā)表文章: 15/ 注冊時間: 2006年07月28日 15:06
          -->討論點1:你所說的類似于功能與功能組,事實上,我覺得沒有這個問題,真的有必要對原子操作進(jìn)行受保嗎?相對于業(yè)務(wù)系統(tǒng),原子操作只是業(yè)務(wù)應(yīng)用(business service)的組成部分,因此受保的對象應(yīng)該是業(yè)務(wù)應(yīng)用而不是原子操作,就用你所舉的例子講,刪除一個可售樓盤信息就是一個業(yè)務(wù)應(yīng)用,也是用戶應(yīng)該關(guān)注的,至于里面包括多少原子操作,甘本不需理會。
          至于>>把純數(shù)據(jù)的操作(即DAO)直接暴露給外界使用
          有service之后不應(yīng)該有這種情況。

          -->討論點2:應(yīng)不應(yīng)該直接為用戶分配權(quán)限,這個應(yīng)該是需求上的問題,呵呵(客戶就是上帝),他有這種要求,你就不能不干。
          話說回來,一個優(yōu)秀的組件就應(yīng)該考慮盡可能多的情況,而你要做通用的組件更甚之,不能因為你某些設(shè)計思想或理念而降低它的應(yīng)用價值。

           

          回復(fù):回復(fù):re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年03月27日 13:45 回復(fù)
          goosped 發(fā)表文章: 8/ 注冊時間: 2007年08月31日 16:10
          這是我第二次來Jdon閱讀了 各位關(guān)于權(quán)限系統(tǒng)的討論,
          我進(jìn)公司不久,就被安排負(fù)責(zé)公司權(quán)限、組織機構(gòu)組件的維護(hù)和開發(fā)。因為公司所有的OA項目都使用這個平臺,在日常的維護(hù)中發(fā)現(xiàn)了許多問題,其中很多對資源的控制沒有通過權(quán)限系統(tǒng)控制,特定資源的控制代碼泛濫、難以維護(hù)的問題。
          許多同事在其中花費了大量的時間,需求一變就得反饋回來改代碼。

          這里很多都是 因為 數(shù)據(jù)權(quán)限 的處理不當(dāng),起因也是公司自己的權(quán)限組件對數(shù)據(jù)權(quán)限沒有提供很好的支持。

          數(shù)據(jù)權(quán)限是否應(yīng)該納入權(quán)限組件? 我個人也贊成樓主以及banq的意見。
          其中banq提到了 使用代理模式來處理數(shù)據(jù)權(quán)限,樓主也對此提出了自己的觀點和疑問。但我還是有點不太清楚,使用代理模式來處理數(shù)據(jù)權(quán)限具體原因,希望各位能詳細(xì)解說一下,謝謝!

          [該貼被goosped于2008-03-27 13:55修改過]


           

          全部摘自網(wǎng)絡(luò) 希望給大家一提示

          學(xué)習(xí)中......



          posted on 2008-03-30 23:40 java_蟈蟈 閱讀(1223) 評論(0)  編輯  收藏

          只有注冊用戶登錄后才能發(fā)表評論。


          網(wǎng)站導(dǎo)航:
           
          主站蜘蛛池模板: 铜山县| 锦州市| 阜南县| 班戈县| 淮滨县| 兴海县| 柏乡县| 张北县| 新疆| 清苑县| 定南县| 蒙阴县| 郴州市| 同江市| 赤峰市| 苗栗县| 东安县| 天台县| 金山区| 都江堰市| 曲阜市| 侯马市| 且末县| 景德镇市| 邮箱| 永泰县| 峨眉山市| 黔江区| 宕昌县| 永和县| 七台河市| 九龙县| 墨竹工卡县| 广南县| 贺兰县| 福贡县| 遵义县| 宁阳县| 齐齐哈尔市| 资溪县| 曲沃县|