|
根據(jù)上面的需求描述以及對需求的分析,我們得知通常的一個中小型系統(tǒng)對于權(quán)限系統(tǒng)所需實現(xiàn)的功能以及非功能性的需求,在下面我們將根據(jù)需求從技術(shù)角度上分析實現(xiàn)的策略以及基于目前兩種比較流行的權(quán)限設(shè)計思想來討論關(guān)于權(quán)限系統(tǒng)的實現(xiàn)。 1.1. 技術(shù)策略 l 身份認證 在B/S的系統(tǒng)中,為識別用戶身份,通常使用的技術(shù)策略為將用戶的身份記錄在Session中,也就是當用戶登錄時即獲取用戶的身份信息,并將其記錄到Session里,當需要進行身份認證的時候通過從Session中獲取用戶的身份信息來實現(xiàn)用戶的身份認證。 l 資源權(quán)限校驗 資源權(quán)限校驗取決于系統(tǒng)的授權(quán)模型,這塊將在之后進行詳細的闡述。 l 數(shù)據(jù)權(quán)限校驗 數(shù)據(jù)權(quán)限校驗取決于系統(tǒng)的授權(quán)模型,這塊將在之后進行詳細的闡述。 l 授權(quán)模型 授權(quán)模型作為權(quán)限系統(tǒng)的核心,從本質(zhì)上決定了權(quán)限系統(tǒng)的易用性,這個易用性包括權(quán)限的授予和權(quán)限的校驗,并同時也決定了權(quán)限的繼承,權(quán)限的排斥和包含等方面的實現(xiàn)。 在經(jīng)歷了這么多年的發(fā)展,授權(quán)模型在目前中小型應(yīng)用系統(tǒng)接受的比較多的主要有RBAC模型和ACL模型,將在之后展開專門的篇幅進行講解。 l 權(quán)限校驗的體現(xiàn) 權(quán)限校驗的體現(xiàn)在中小型系統(tǒng)中體現(xiàn)出來的通常只是對于系統(tǒng)菜單、按鈕顯示的控制和對于擁有權(quán)限的數(shù)據(jù)的訪問上。 它們共同依賴于資源權(quán)限校驗和數(shù)據(jù)權(quán)限校驗,對于系統(tǒng)菜單、按鈕的顯示上的控制在B/S中通常采用的技術(shù)策略為在生成菜單、按鈕的Html時做權(quán)限級的判斷,當操作主體不具備權(quán)限時則不生成該菜單、按鈕的Html,從技術(shù)角度分析為方便使用者,避免使用者調(diào)用權(quán)限校驗接口,通常的做法為提供菜單、按鈕的標簽,通過此標簽生成的菜單和按鈕即為經(jīng)過權(quán)限過濾的。 l 高性能 為提高權(quán)限系統(tǒng)在授權(quán)以及校驗權(quán)限時的性能,通常的做法為采用緩存技術(shù)以及加強權(quán)限系統(tǒng)的管理建設(shè),加強權(quán)限系統(tǒng)的管理建設(shè)有助于建立一個最為適合需求的權(quán)限結(jié)構(gòu),同時做到了簡化系統(tǒng)權(quán)限授予。 l 安全性 安全性方面來講在B/S系統(tǒng)中通常有兩個方面需要控制: n 通過非法途徑訪問系統(tǒng)文件 在Java的Web應(yīng)用中通常采用的技術(shù)策略為將需要受保護的文件放入WEB-INF文件夾中,大家都知道在WEB-INF下的文件除了在服務(wù)器上能直接訪問外,通過普通的URL是無法訪問到的。 其次的做法為做Filter,即對需要受保護的資源做訪問的Filter,如操作者不具備權(quán)限則直接報出錯誤。 n 通過非法途徑訪問系統(tǒng)操作 通常采用的技術(shù)策略為對每個直接暴露對外的需要受權(quán)限保護的對象做操作級別的權(quán)限控制,簡單來說在Web系統(tǒng)中通常采用MVC框架來實現(xiàn),通常Command層是直接對外的,為防止用戶通過URL或其他方式訪問Command,從技術(shù)上我們需要考慮對現(xiàn)有系統(tǒng)的盡量少的侵入性,所以通常采用的做法是在Command之上做Before Interceptor或Proxy,在此Interceptor或Proxy中做權(quán)限的校驗,以確認操作者具有相應(yīng)的權(quán)限。
經(jīng)過上面的描述,我們已經(jīng)基本了解到滿足權(quán)限系統(tǒng)需求的技術(shù)實現(xiàn)策略,從中我們也可以看出權(quán)限系統(tǒng)中最為重要的為授權(quán)模型,由于權(quán)限系統(tǒng)的通用性,在業(yè)界也是推出了不少的授權(quán)模型,在這里我們已目前比較通用的兩種授權(quán)模型來具體講解權(quán)限系統(tǒng)的完整實現(xiàn)。 1.2. 基于RBAC的實現(xiàn) 1.2.1. RBAC介紹 RBAC模型作為目前最為廣泛接受的權(quán)限模型,在此也將對其模型進行簡要的介紹,RBAC模型成功的經(jīng)典應(yīng)用案例當屬Unix系統(tǒng)了。 NIST(The National Institute of Standards and Technology,美國國家標準與技術(shù)研究院)標準RBAC模型由4個部件模型組成,這4個部件模型分別是基本模型RBAC0(Core RBAC)、角色分級模型RBAC1(Hierarchal RBAC)、角色限制模型RBAC2(Constraint RBAC)和統(tǒng)一模型RBAC3(Combines RBAC)[1]。RBAC0模型如圖1所示。
l RBAC0定義了能構(gòu)成一個RBAC控制系統(tǒng)的最小的元素集合 在RBAC之中,包含用戶users(USERS)、角色roles(ROLES)、目標objects(OBS)、操作operations(OPS)、許可權(quán)permissions(PRMS)五個基本數(shù)據(jù)元素,權(quán)限被賦予角色,而不是用戶,當一個角色被指定給一個用戶時,此用戶就擁有了該角色所包含的權(quán)限。會話sessions是用戶與激活的角色集合之間的映射。RBAC0與傳統(tǒng)訪問控制的差別在于增加一層間接性帶來了靈活性,RBAC1、RBAC2、RBAC3都是先后在RBAC0上的擴展。 l RBAC1引入角色間的繼承關(guān)系 角色間的繼承關(guān)系可分為一般繼承關(guān)系和受限繼承關(guān)系。一般繼承關(guān)系僅要求角色繼承關(guān)系是一個絕對偏序關(guān)系,允許角色間的多繼承。而受限繼承關(guān)系則進一步要求角色繼承關(guān)系是一個樹結(jié)構(gòu)。 l RBAC2模型中添加了責任分離關(guān)系 RBAC2的約束規(guī)定了權(quán)限被賦予角色時,或角色被賦予用戶時,以及當用戶在某一時刻激活一個角色時所應(yīng)遵循的強制性規(guī)則。責任分離包括靜態(tài)責任分離和動態(tài)責任分離。約束與用戶-角色-權(quán)限關(guān)系一起決定了RBAC2模型中用戶的訪問許可。 l RBAC3包含了RBAC1和RBAC2 既提供了角色間的繼承關(guān)系,又提供了責任分離關(guān)系。 1.2.2. 實現(xiàn)方案 通過上面章節(jié)對RBAC的介紹,從RBAC模型中我們可以看出它已經(jīng)實現(xiàn)了一個使用起來很方便的授權(quán)模型,并同時也就權(quán)限的繼承,權(quán)限的排斥和包含提出了解決的模型。 那么現(xiàn)在的關(guān)鍵是我們需要來看看基于RBAC到底是怎么實現(xiàn)權(quán)限系統(tǒng)的需求的呢?在這里我們針對在技術(shù)策略中未描述的授權(quán)模型和權(quán)限校驗部分做實現(xiàn)方案的講解。 l 授權(quán)模型 授權(quán)模型遵循RBAC進行搭建,即建立如上圖表一的模型。 針對授權(quán)模型中的幾個關(guān)鍵部分我們進行描述: n 授權(quán) 按照RBAC的模型,在授權(quán)時分為配置資源以及資源的操作、授予角色對資源的操作權(quán)限、分配角色給用戶這幾個步驟來完成。 從這幾個步驟我們進行分析: u 配置資源以及資源的操作 實現(xiàn)這步非常的簡單,直接維護資源以及資源操作兩個對象的持久即可實現(xiàn)。 u 授予角色對資源的操作權(quán)限 實現(xiàn)這步同樣非常的簡單,維護角色與資源的關(guān)聯(lián)模型即可。 u 分配角色給用戶 實現(xiàn)這步同樣非常的簡單,維護角色與用戶的關(guān)聯(lián)模型即可。 n 權(quán)限的繼承 權(quán)限的繼承在RBAC的模型中通過增加角色的自關(guān)聯(lián)來實現(xiàn),即角色可擁有子角色,子角色繼承父角色的權(quán)限。 按照此模型可以看出在授權(quán)時維護權(quán)限的繼承也是非常的簡單,維護角色的自關(guān)聯(lián)模型即可。 n 權(quán)限的排斥和包含 權(quán)限的排斥和包含這塊我沒有具體看RBAC的規(guī)范,通常的做法是通過在資源的操作權(quán)限模型中增加自關(guān)聯(lián)模型以定義哪些資源的操作權(quán)限是排斥和包含的,在授權(quán)時可以看到同樣需要維護的只是資源權(quán)限的自關(guān)聯(lián)模型。 l 資源權(quán)限校驗 根據(jù)上面的授權(quán)模型,在做資源權(quán)限校驗的時候需要經(jīng)過以下步驟: n 判斷用戶所在的角色是否擁有對資源進行操作的權(quán)限 獲取用戶所擁有的角色,遍歷其角色,以各角色建立Session,并通過類似的role.doPrivilege(Resource,Operation)的方式來判斷該角色是否具備權(quán)限,如具備則直接返回,如不具備則直到遍歷結(jié)束。 n 遞規(guī)用戶所在角色的父角色判斷是否擁有對資源進行操作的權(quán)限 當遍歷完用戶本身的角色得到用戶不具備對資源進行該操作的權(quán)限時,則開始遞規(guī)其所在角色的父角色來判斷是否擁有對資源進行操作的權(quán)限,過程同上,如確定某角色具備,則返回,如不具備直到遞規(guī)結(jié)束。 l 數(shù)據(jù)權(quán)限校驗 在RBAC模型中沒有明確定義數(shù)據(jù)權(quán)限的實現(xiàn)策略,鑒于此首先要講解下基于RBAC模型的數(shù)據(jù)授權(quán)模型的建立,基于RBAC模型,將數(shù)據(jù)映射為RBAC中的資源,對數(shù)據(jù)的操作則映射為資源的操作,同樣的是將此資源以及資源的操作構(gòu)成的權(quán)限授予給角色,將用戶分配給角色完成數(shù)據(jù)權(quán)限的授權(quán)過程。 但根據(jù)數(shù)據(jù)權(quán)限校驗的需求,數(shù)據(jù)的權(quán)限也是需要繼承的,而且數(shù)據(jù)權(quán)限的授予對象需要是多種,這樣的話就對上面根據(jù)RBAC映射形成的數(shù)據(jù)權(quán)限的授權(quán)模型造成了沖擊,需要重構(gòu)上面的授權(quán)模型來滿足需求。 為實現(xiàn)數(shù)據(jù)權(quán)限的繼承,需要將RBAC模型中的資源重構(gòu)為允許自關(guān)聯(lián)的模型,為實現(xiàn)數(shù)據(jù)權(quán)限能夠授予給多種對象,需要將本來資源操作權(quán)限授予給角色的模型演變?yōu)閿?shù)據(jù)操作權(quán)限授予給角色、組織機構(gòu)或具體人員,根據(jù)RBAC模型,同樣的建立一個中間對象,此對象和數(shù)據(jù)操作權(quán)限所授予的對象做1對多的關(guān)聯(lián),在經(jīng)過這樣的重構(gòu)之后數(shù)據(jù)權(quán)限的授權(quán)模型就形成了,也滿足了數(shù)據(jù)權(quán)限的繼承和授予給多種對象的需求。
上面的圖中少畫了數(shù)據(jù)的自關(guān)聯(lián)。 在做數(shù)據(jù)權(quán)限校驗的時候我們需要實現(xiàn)的為兩種方式,一種是獲取操作主體具有數(shù)據(jù)操作權(quán)限的全部數(shù)據(jù),另外一種為分頁獲取操作主體具有數(shù)據(jù)操作權(quán)限的數(shù)據(jù)。 就這兩種方式分別來進行闡述: n 獲取操作主體具有數(shù)據(jù)操作權(quán)限的全部數(shù)據(jù) 從數(shù)據(jù)庫中獲取所有數(shù)據(jù),遍歷取出的數(shù)據(jù)從數(shù)據(jù)權(quán)限模型中獲取相應(yīng)的擁有數(shù)據(jù)操作權(quán)限的權(quán)限擁有者,如果該數(shù)據(jù)未配置數(shù)據(jù)操作權(quán)限的控制,那么就無需對該數(shù)據(jù)進行權(quán)限級的判斷,如配置了,則需判斷當前用戶是否在該數(shù)據(jù)操作權(quán)限所對應(yīng)的擁有者中,如用戶不在,則需遞規(guī)獲取該數(shù)據(jù)的父數(shù)據(jù)的操作權(quán)限的擁有者,到用戶擁有權(quán)限或遞規(guī)結(jié)束時終止。 n 分頁獲取操作主體具有數(shù)據(jù)操作權(quán)限的數(shù)據(jù) 分頁的做法和上面差不多,只是在獲取了所有的數(shù)據(jù)后在內(nèi)存中做分頁返回。 1.2.3. 優(yōu)缺點分析 從上面的基于RBAC的實現(xiàn)方案中可以看出基于RBAC模型的優(yōu)點在于: l 易用和高效的授權(quán)方式 用戶在進行授權(quán)時只需對角色進行授權(quán),之后將相應(yīng)的角色分配給用戶即可。 l 簡便和高效的授權(quán)模型維護 在技術(shù)角度來講,進行授權(quán)模型的維護上因為基本只需要維護關(guān)聯(lián)模型而顯得簡單而高效。 缺點在于: l 復(fù)雜的權(quán)限校驗 在進行權(quán)限校驗時需要不斷的遍歷和遞規(guī),造成了性能的影響。 l 對于數(shù)據(jù)權(quán)限的不夠支持 沒有明確的數(shù)據(jù)權(quán)限模型,可以看到在經(jīng)過重構(gòu)的數(shù)據(jù)權(quán)限模型其實已經(jīng)和RBAC模型有一定的出入,而且在數(shù)據(jù)權(quán)限的校驗上實現(xiàn)起來是非常的低效。 |
|
|
來自: smoking_boy > 《我的圖書館》