权限系统设计
來源：http://thomaslee007.javaeye.com/blog/164280
?
權限系統(1)--基本模式
在系統中發生的事情，抽象的說都是某個主體 (subject)在某個資源(resource)上執行了某個操作(operation)。
subject --[operation]--> resource
所謂權限管理，就是在這條信息傳遞路徑中加上一些限制性控制。
主體試圖去做 的 limited by 系統允許主體去做的 = 主體實際做的。
可以看到，權限控制基本對應于filter模式。subject試圖去做的事 情應該由業務邏輯決定，因而應該編碼在業務系統中。
先考慮最粗粒度的控制策略，控制點加在subject處，即無論從事何種操作，針對何 種資源，我們首先需要確認subject是受控的。只有通過認證的用戶才能使用系統功能，這就是authentication。boolean isAllowed subject)
稍微復雜一些，控制可以施加在subject和operation的邊界處（此時并不知道具體進行何種操 作），稱為模塊訪問控制，即只有某些用戶才能訪問特定模塊。isAllowed(subject, operation set)
第三級控制直接 施加在operation上，即操作訪問控制。operation知道resource和subject（但它尚沒有關于resource的細節知識)， 我們能夠采取的權限機制是bool isAllowed(subject, operation, resource), 返回true允許操作，返回false則不允許操作。
最簡單的情況下，subject與resource之間的訪問控制關系是靜態的，可 以直接寫成一個權限控制矩陣
for operationA:
resourceA resourceB
subjectA 1 0
subjectB 0 1
isAllowed(subjectA, resourceA)恒等于true
如 果多個operation的權限控制都可以通過這種方式來表示，則多個權限控制矩陣可以疊加在一起
for operationA, operationB:
resourceA resourceB
subjectA 10 01
subjectB 01 11
當 subject和resource的種類很多時，權限控制矩陣急劇膨脹，它的條目數是N*M。很顯然，我們需要進行矩陣分解。這也是最基本的控制手段之 一: 在系統中增加一個瓶頸，或者說尋找到隱含的結構。
subject_resource = subject_role * role_resource
這樣系統權限配置條目的數量為 N*R + R*M, 如果R的數目遠小于subject和resource，則實現簡化。這稱為RBAC(role based access control)，它的一個額外好處是權限系統的部分描述可以獨立于subject存在，即在系統中沒有任何用戶的時候，通過角色仍然可以表達部分權限信 息。可以說角色是subject在權限系統中的代理(分解)。
有時候引入一個瓶頸還不過癮，有人引入組的概念，與role串聯，
subject_resource = subject_group_role * role_resource
或著group與role并聯,
subject_resource = subject_group * group_resource
與role稍有不同，一般情況下group的業務含義更加明顯，可 能對應于組織結構等。將組織機構明確引入權限體系，有的時候比較方便，但對于權限系統自身的穩定性而言，未見得有什么太大的好處。并聯模式有些多余，串聯 模式又過于復雜，細節調整困難，特別是多條控制路徑造成的沖突情況。一般情況下，我不提倡將group引入權限控制中。
比操作控制更加深 入的控制就是數據控制了，此時需要對于resource的比較全面的知識。雖然表面上，仍然是
boolean isAllowed(subject, operation, resource)，但控制函數需要知道resource的細節。例如行級控制(row-level)或者列級控制(column-level)的實現。 因為我們一般情況下不可能將每一個條目都建模為獨立的resource，而只能是存在一個整體描述，例如所有密級為絕密的文檔。在witrix平臺中，數 據控制主要通過數據源的filter來實現，因為查詢條件（數據的定位條件)已經被對象化為Query類，所以我們可以在合適的地方自由的追加權限控制條 件。
以上的討論中，權限控制都是根據某些靜態描述信息來進行的，但現實世界是多變的。最簡單的，當subject從事不同業務時，對應于 同一組資源，也可能對應的權限控制并不同(在witrix平臺中,對應于IDataSource的模式切換)。更復雜一些, 在不同的時刻, 我們需要根據其他附加信息來作出是否允許操作的判斷, 即此時我們權限設置的不僅僅是一些靜態的描述信息, 而是一個完整的控制函數, 這就是所謂的工作流權限控制,一種動態權限控制.
權限系統(2)--operation
權限控制可以看作一個filter模式的應用, 這也符合AOP思想的應用條件。在一個簡化的圖象中，我們只需要將一個判別函數 isAllowed(subject, operation, resource)插入到所有安全敏感的函數調用之前就可以了。雖然概念上很完美，具體實現的時候仍然有一些細節上的問題。基本的困難在于很難在最細的粒 度上指定權限控制規則（連續的？動態的？可擴展的？），因而我們只能在一些關鍵處指定權限規則，或者設置一些整體性的權限策略，然后通過特定的推理來推導 出細粒度的權限規則，這就引出結構的問題。我們需要能夠對權限控制策略進行有效的描述（控制策略的結構），并且決定如何與程序結構相結合。 subject, operation和resource為了支持推理，都可能需要分化出復雜的結構，而不再是簡單的原子性的概念。而在與程序結構結合這一方面，雖然AOP 使得我們可以擴展任何函數，但這種擴展需要依賴于cutpoint處所能得到的信息，因而權限控制的有效實施也非常依賴于功能函數本身良好的設計。有的時 候因為需要對結構有過于明確的假定，權限控制的實現不得不犧牲一定的通用性。
下面我們將分別討論一下operation, subject和resource的結構分解的問題。首先是operation。
說到推理結構，讓人最先想起的就是決策樹，樹形結構，在面向對象 語言中可以對應于繼承。金字塔式的樹形結構也正是在現實世界中我們應用最多的控制結構。通過層層分解，operation的結構可以組織為一棵樹,
應 用程序 ==> 各個子系統 ==> 每個子系統的功能模塊 ==> 子功能模塊
==> 每個模塊的功能點(具有明確的業務含義) ==> 每個功能點對應的訪問函數(程序實現中的結構)
一個常見的需求是根據權限配置決定系統菜 單樹的顯示，一般控制用戶只能看到自己有權操作的功能模塊和功能按鈕。這種需求的解決方法是非常直接的。首先，在后臺建立子系統到功能模塊，功能模塊到功 能點以及功能點到實現函數之間的映射表（如果程序組織具有嚴格規范，這甚至可以通過自動搜集得到）。然后，在權限配置時建立用戶與功能點之間的關聯。此 時，通過一個視圖，我們就可以搜集到用戶對哪些功能模塊具有訪問權限的信息。
為了控制菜單樹的顯示，witrix平臺中的SiteMap 采用如下策略：
1. 如果用戶對某個子功能具有操作權限，則所有父菜單項都缺省可用
2. 如果用戶對某個功能具有操作權限，并且標記為cascade，則所有子菜單項都自動缺省可用
3. 如果明確指定功能不可用，則該菜單及子菜單都強制不可用
4. 如果明確指定功能對所有人可用，則不驗證權限，所有子菜單自動缺省可用
4. 強制設定覆蓋缺省值
5. 不可用的菜單缺省不可見
6. 明確標記為可見的菜單即使不可用也可見
7. 父菜單可見子菜單才可見
我 們通過預計算來綜合考慮這些相互影響的控制策略。盡量將推導運算預先完成也是解決性能問題的不二法門。
在witrix平臺中，每一次網絡 訪問的url都符合jsplet框架所要求的對象調用格式，需要指定objectName和objectEvent參數，這就對應于功能點的訪問函數。訪 問控制點集中在objectManager并且訪問格式是標準的。使用spring等AOP方式實現細粒度訪問控制，困難似乎在于不容易引入外部配置信息 （例如功能點信息等），而且控制點所對應的對象函數格式也不統一，因而多數需要在細粒度上一一指定。
權限系統(3)-- subject
權限控制中，subject可能不會簡單的對應于userId, 而是包含一系列的security token或certificate, 例如用戶登陸地址，登陸時間等。一般情況下，這些信息在權限系統中的使用都是很直接的，不會造成什么問題。
subject域中最重要的結構是 user和role的分離，可以在不存在user的情況下，為role指定權限。有人進一步定義了userGroup的概念，可以為userGroup指 定role，而user從其所屬的group繼承role的設置。一般情況下，我不提倡在權限系統中引入userGroup的概念。這其中最重要的原因就 是它會造成多條權限信息傳遞途徑，從而產生一種路徑依賴, 并可能出現信息沖突的情況。一般user與group的關聯具有明確的業務含義，因而不能隨意取消。如果我們希望對user擁有的權限進行細調，除去 user從group繼承的某個不應該擁有的權限，解決的方法很有可能是所謂的負權限，即某個權限條目描述的是不能做某某事。負權限會造成各個權限設置之 間的互相影響，造成必須嘗試所有權限規則才能作出判斷的困境，引出對額外的消歧策略的需求，這些都極大的限制了系統的可擴展性。在允許負權限的環境中，管 理員將無法直接斷定某個權限設置的最終影響，他必須在頭腦中完成所有的權限運算之后才能理解某用戶最終擁有的實際權限，如果發現權限設置沖突，管理員可能 需要多次嘗試才能找到合適方案。這種配置時的推理需求可能會增加配置管理的難度，造成微妙的安全漏洞，而且負權限導致的全局關聯也降低了權限系統的穩定 性。我更傾向于將group作為權限設置時的一種輔助標記手段，系統中只記錄用戶最終擁有的角色，即相當于記錄用戶通過group擁有權限的推導完成的結 果, 如果需要權限細調，我們直接在用戶擁有的角色列表上直接進行。當然，如果實現的復雜一些，權限系統對外暴露的接口仍然可以模擬為能夠指定 userGroup的權限。
推理在面向對象語言中最明顯的表現是繼承，所以有些人將subject域中的推理直接等價于role之間的繼承問題， 這未必是最好的選擇。繼承可以形成非常復雜的推理關系，但是可能過于復雜了（特別是直接使用sql語句無法實現樹形推理查詢）。按照級列理論，從不相關發 展到下一階段是出現簡單的序關系，即我們可以說subject出現級別上的差異，高級別subject將自動具有低級別的權限。一種選擇是定義 roleRank,規定高級別role自動具有低級別role的權限，但考慮到user與role的兩分結構，我們也可以同時定義userRank和 roleRank,規定高級別user自動具有低級別的role，而role之間不具有推理關系。在面向對象領域中，我們已經證實了完全采用繼承來組織對 象關系會導致系統的不穩定，所以我傾向于第二種選擇，即將role看作某種類似于interface的東西，一種權限的切片。為了進一步限制這種推導關 系，我們可以定義所謂的安全域的概念. security domain, 規定推導只能在一定的域中才能進行。
select user.userId, role.roleId
from user, role
where user.userRank > role.roleRank
and user.domain = role.domain
將權限控制一般需要施加在最細的粒度 上，這在復雜的系統中可能過于理想化了。復雜的情況下我們需要進行局部化設計，即進行某些敏感操作之前進行一系列復雜的權限校驗工作。當完成這些工作之 后，進入某個security zone, 在其中進行操作就不再需要校驗了。
總的來說，權限系統采用非常復雜的結構效果未必理想。很多時候只是 個管理模式的問題，應該盡量通過重新設計權限空間的結構來加以規避。不過在一些非常復雜的權限控制環境下，也許簡單的描述信息確實很難有效的表達權限策略 （雖然我從未遇到過），此時嘗試一下規則引擎可能比在權限系統中強行塞入越來越多的約束要好的多
權限系統(4)--resource
權限管理中進行數據訪問控制，其基本模式如下
operation target = selector(resource)
selector = user selector + auth filter
這里需要對 resource的結構，以及選擇算子的顯式建模。selector必須允許權限系統追加filter，例如
IDataSource包中所使用的 Query對象。
sql語言的表達能力有限, 作為選擇算子來使用有時需要resource作一些結構上的調整，增加一些冗余的字段。例如表達一段時間內的利率，我們需要使用from_date和 to_date兩個字段來進行描述，其中to_date的值與下一條記錄的from_date相同。
value from_date to_date
0.01 2003-01-01 2003-05-01
0.012 2003-05-01 2004-01-01
如 果表達一條航線中的多個階段，我們可能會在每條記錄中增加起始站和終點站兩個字段。
更重要的一個常見需求是樹形結構在關系數據庫中的表達。為了能 夠直接操縱一個分支下的所有記錄，在層次固定的情況下，我們可能會增加多個分類字段，例如數據倉庫中的層次維度。在層次數目不確定的情況下，我們將不得不 使用層次碼或者類似于url的其他方案，通過layer_code like '01.01.%' 之類的語句實現分支選擇。為了限制選擇的深度，我們可能還需要layer_level字段。基于層次碼和層次數，我們可以建立多種選擇算子，例如包含所有 直接子節點，包含自身及所有父節點等等。
http://www.dbazine.com/oracle/or-articles/tropashko4
權限系統(5)--動態性
動態權限最簡單的一個表現是時限性，subject只在某個時間段內具有某種權限。這只需要在 user和role的映射中，或者role自身的屬性中增加startTime和expireTime即可。
更復雜的動態性一般與流程控 制相關，此時權限控制應該由工作流系統完成，而不是在數據上增加越來越多的權限標記。在witrix平臺中，使用tpl模板技術來定制權限設置。
http://canonical.blogdriver.com/canonical/658364.html
?
基于 RBAC 模型的權限管理系統的設計和實現 裴輝東 梁云風 （1. 山東省煙臺海頤軟件股份有限公司；2山東省煙臺東方電子信息產業股份有限公司 ） 摘要： 提出了基于RBAC模型的權限管理 系統的 設計和實現方案。介紹了采用的J2EE架構的多層體系結構設計，闡述了基于角色的訪問控制RBAC模 型的設計思想 ，并討論了權限管理系統的核心面向對象設計模型，以及權限訪 問、權限控制和權限存儲機制等關鍵技術。 關鍵詞： 權限管 理系統；角色； 訪問控制；RBAC模型；J2EE；LDAP 0 引言 管 理信息系統是一個復雜的人機交互系統，其中每個具體環節都可能受到安全威脅。構建強健的權限管理系統，保證管理信息系統的安全性是十分重要的。權限管理系 統是管理信息系統中可代碼重用性最高的模塊之一。任何多用戶的系統都不可避免的涉及到相同的權限需求，都需要解決實體鑒別、數據保密性、數據完整性、防抵 賴和訪問控制等安全服務 (據ISO7498-2) 。例如，訪問控制服務要求系統根據操作者已經設定的操作權限，控制操作者可以訪問哪些資源，以及確定 對資源如何進行操作。 目前，權限管理系統也是重 復開發率最高的模塊之一。在企業中，不同的應用系統都擁有一套獨立的權限管理系統。每套權限管理系統只滿足自身系統的權限管理需要，無論在數據存儲、權限 訪問和權限控制機制等方面都可能不一樣，這種不一致性存在如下弊端： a. 系統管理員需要維護 多套權限管理系統，重復勞動。 b. 用戶管理、組織機構等數據重復維護，數據一致性、完整性得不到保證。 c. 由于權限管理系統的 設計不同，概念解釋不同，采用的技術有差異，權限管理系統之間的集成存在問題，實現單點登錄難度十分大，也給企業構建企業門戶帶來困難。 采用統一的安全管理設計思想，規范化設計和先進的技術架構體系，構建一個通用的、完善的、安全的、 易于管理的、有良好的可移植性和擴展性的權限管理系統，使得權限管理系統真正成為權限控制的核心，在維護系統安全方面發揮重要的作用，是十分必要的。 本文介紹一種基于角色的訪問控制RBAC（Role-Based policies Access Control）模型的權限管理系統的設計和實現，系統采用基于J2EE架構技術實現。并以討論了應用系統如何進行 權限的訪問和控制 。 1 采用 J2EE 架構設計 采用J2EE企業平臺架構構建權限管理系統。J2EE架構集成了先進的軟件體系架構思想，具有采用 多層分布式應用模型、基于組件并能重用組件、統一完全模型和靈活的事務處理控制等特點。 系統邏輯上分為四層：客戶層、Web層、業務層和資源層。 a. 客戶層主要負責人機交互。可以使系統管理員通過Web瀏覽器訪問，也可以提供不同業務系統的API、Web Service調用。 b. Web層封裝了用來提供通過Web訪問本系統的客戶端的表示層邏輯的服務。 c. 業務層提供業務服務，包括業務數據和業務邏輯，集中了系統業務處理。主要的業務管理模塊包括組織機構管理、用戶管理、資源管理、權限管理和訪問控制幾個部 分。 d. 資源層主要負責數據的存儲、組織和管理等。資源層提供了兩種實現方式：大型關系型數據庫（如ORACLE）和LDAP（Light Directory Access Protocol，輕量級目錄訪問協議）目錄服務器（如微軟的活動目錄）。 2 RBAC 模型 訪問控制是針對越權使用資源的防御措施。基本目標是為了限制訪問主體（用戶、進程、服務等）對訪問 客體（文件、系統等）的訪問權限，從而使計算機系統在合法范圍內使用；決定用戶能做什么，也決定代表一定用戶利益的程序能做什么[1] 。 企業環境中的訪問控制策略一般有三種：自主型訪問控制方法、強制型訪問控制方法和基于角色的訪問控制方 法（RBAC）。其中，自主式太弱，強制式太強，二者工作量大，不便于管理[1] 。基于角色的訪問控制方法 是目前公認的解決大型企業的統一資源訪問控制的有效方法。其顯著的兩大特征是： 1.減 小授權管理的復 雜性，降低管理開銷 ；2.靈活地支 持企業的安全策略，并對企業的變化有很大的伸縮性。 NIST（The National Institute of Standards and Technology，美國國家標準與技術研究院）標準RBAC模型由4個部件模型組成，這4個部件模型分別是基本模型RBAC0（Core RBAC）、角色分級模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和統一模型RBAC3（Combines RBAC）[1] 。RBAC0模型如圖1所示。 ? 圖1 RBAC0 模型 a. RBAC0定義了能構成一個RBAC控制系統的最小的元素集合。在RBAC之中,包含用戶users(USERS)、角色roles(ROLES)、目標 objects(OBS)、操作operations(OPS)、許可權permissions(PRMS)五個基本數據元素，權限被賦予角色,而不是用 戶，當一個角色被指定給一個用戶時，此用戶就擁有了該角色所包含的權限。會話sessions是用戶與激活的角色集合之間的映射。RBAC0與傳統訪問控 制的差別在于增加一層間接性帶來了靈活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的擴展。 b. RBAC1引入角色間的繼承關系，角色間的繼承關系可分為一般繼承關系和受限繼承關系。一般繼承關系僅要求角色繼承關系是一個絕對偏序關系，允許角色間的 多繼承。而受限繼承關系則進一步要求角色繼承關系是一個樹結構。 c. RBAC2模型中添加了責任分離關系。RBAC2的約束規定了權限被賦予角色時,或角色被賦予用戶時,以及當用戶在某一時刻激活一個角色時所應遵循的強制 性規則。責任分離包括靜態責任分離和動態責任分離。約束與用戶-角色-權限關系一起決定了RBAC2模型中用戶的訪問許可。 d. RBAC3包含了RBAC1和RBAC2，既提供了角色間的繼承關系，又提供了責任分離關系。 3 核心對象模型設計 根據 RBAC模型的權限 設計思想，建立權限管理系統的核心對象模型。如圖2所示。對象模型中包含的基本元素主要有：用戶（Users）、用戶組（Group）、角色（Role）、目標 （Objects）、 訪問模式 （Access Mode）、操作（Operator）。主要的關系有：分配角色權限PA（Permission Assignment）、分配用戶角色UA（Users Assignmen描述如下： ?????????????????????????????????????????????? 圖2 權限管理系統核心類圖 a .控制對象： 是系統所要保護的資源（Resource），可 以被訪問的對象 。 資源的定義需要注 意以下兩個問題： 1.資源具有層次關系和包含關系 。例如，網頁是資源，網頁上的按鈕、文本框等對象也是資源，是網頁節點的子節點，如可以訪問按鈕，則必須能夠訪問頁面。 2. 這里提及的資源概念 是指資源的類別 （Resource Class），不是某個特定資源的實例（Resource Instance）。 資源的類別和資源的實例的區分，以及資源的粒度的細分，有利于確定權限管理系統和應用系統之間的管理邊界，權限管理系統需要對于資源的類別進 行權限管理，而應用系統需要對特定資源的實例進行權限管理。兩者的區分主要是基于以下兩點考慮： 一方面，資源實例的權限常具有資源的相關性。即根據資源實例和訪問資源的主體之間的關聯關系，才可 能進行資源的實例權限判斷。 例如，在管理信息系統中，需要按 照營業區域劃分不同部門的客戶， A區和B區 都具有修改客戶資料這一受控的資源，這里“客戶檔案資料”是屬于資源的類別的范疇。如果規 定A區只能修改A區 管 理的客戶資料，就必須要區分出資料的歸屬，這里的 資源是屬于資源實例的范疇 。客戶檔案（資源）本身應該有其使用者的信息（客戶資料可能就含有營業區域這一屬性），才能區分特定 資源的實例操作，可以修改屬于自己管轄的信息內容。 另一方面，資源的實例權限常具有相當大的業務邏輯相關性。對不同的業務邏輯，常常意味著完全不同的 權限判定原則和策略。 b.權限： 對受保護的資源操作的訪問許可 (Access Permission) ，是綁定在特定的資源 實例上的。對應地，訪問策略 （Access Strategy）和資源 類別 相關，不同的資源 類別 可能采用不同的訪 問模式（Access Mode）。例如，頁面具有能打開、不能打開的 訪問 模式，按鈕具有可用、不可用的訪問模式，文本編輯框具有可編輯、不可編輯的訪問模式。同一資源的訪問策略可能存在排斥和包含關系。例如，某個數據集的可修 改訪問模式就包含了可查詢訪問模式。 c.用戶： 是 權限的擁有者或主體。用戶和權限實現分離，通過授權管理進行 綁定。 d.用戶組： 一組用戶的集合。在業務邏輯的判斷中，可以實現基于個人身份或組的身份進行判斷。系統弱化了用戶組的 概念，主要實現用戶（個人的身份）的方式。 e.角色： 權限分配的單位與載體。角色通過繼承關系支持分級的權限實現。例如，科長角色同時具有科長角色、科內不同業務人員角色。 f.操作： 完成資源的類別和訪問策略之間的綁定。 g.分配角色權限PA： 實現操作和角色之間的關聯關系映射。 h.分配用戶角色UA： 實現用戶和角色之間的關聯關系映射。 該對象模型最終將訪問控制模型轉化為訪問矩陣形式。訪問矩陣中的行對應于用戶，列對應于操作，每個 矩陣元素規定了相應的角色，對應于相應的目標被準予的訪問許可、實施行為。按訪問矩陣中的行看，是訪問能力表CL(Access Capabilities)的內容；按訪問矩陣中的列看，是訪問控制表ACL（Access Control Lists）的內容。 4 權限訪問機制 權限管理系統端：提供集中管理權限的服務，負責提供用戶的鑒別、用戶信息、組織結構信息,以及權限 關系表 的計算。如圖3 所示。
圖3 權限的訪問示意圖 Fig.3 Privilege invoke 系統根據用戶，角色、操作、 訪問 策略和控制對象之 間的關聯關系，同時考慮權限的正負向授予，計算出用戶的最小權限。在 業務邏 輯層采用 Session Bean實現此服務，也可以發布成Web Service。采用代理Proxy模式，集中控制來自應用系統的所要訪問的權限計算服務，并返回權限關系表，即二元組 {ObjectId，OperatorId}。 應用系統端：可以通過訪問能力表CL和訪問控制表ACL兩種可選的訪問方式訪問權限管理系統。 以基于 J2EE 框架的應用系統為例，說明訪問過程 ： a.首先采用基于表單的驗 證，利用Servlet方式集中處理登錄請求[2] 。考慮到需要鑒別的實體是用戶，采用基于ACL訪問方式。用戶登錄時調用權限管 理系統的用戶鑒別服務，如果驗證成功，調用權限計算服務，并返回權限關系表，以HashMap的方式存放到登錄用戶的全局Session中；如果沒有全局 的Session或者過期，則被導向到登錄頁面，重新獲取權限。 b. 直接URL資源采用基于CL訪問方式進行的訪問控制。如果用戶直接輸入URL地址訪問頁面，有兩種方法控制訪問：1.通過權限標簽讀取CL進行控制；2. 采取Filter模式，進行權限控制，如果沒有權限，則重定向到登錄頁面。 5 權限控制機制 權 限所要控制的資源類別是根據應用系統的需要而定義的，具有的語義和控制規則也是應用系統提供的，對于權限管理系統來說是透明的，權限將不同應用系統的資源 和操作統一對待。應用系統調用權限管理系統所獲得的權限關系表，也是需要應用系統來解釋的。按此設計，權限管理系統的通用性較強，權限的控制機制則由應用 系統負責處理。 由于應用系統的權限控制與特定的技 術環境有關，以基于 J2EE架 構的應用系統為例來說明，系統 主要的展示組件是JSP頁面， 采用標記庫和權限控制組件共同來 實現。 a. 權限標識：利用標簽來標識不同級別資源，頁面權限標簽將標識頁面對象。 b. 權限注冊：遍歷JSP頁面上的權限控制標簽，讀取JSP的控制權限。通過權限注冊組件將JSP頁面上的權限控制對象以及規則注冊到權限管理信息系統中。 c. 權限控制：應用系統用戶登錄系統時，從權限管理系統獲得權限關系表之后，一方面，權限標簽控制頁面展示；另一方面，利用權限控制組件在業務邏輯中進行相應 的權限 控制 ， 尤其是和業務邏輯緊密聯系的控制對象實例的權限控制。 6 權限存儲機制 權限管理系統采用了兩種可選的存儲機制：LDAP（Lightweight Directory Access Protocol）目錄服務數據庫和關系型數據庫。存儲用戶信息、組織結構、角色、操作、訪問模式等信息。 其中，目錄服務系統基于LDAP標準，具有廣泛的數據整合和共享能力。元目錄（Meta- Directory）功能允許快速、簡潔的與企業現存基礎結構進行集成，解決基于傳統RDBMS等用戶數據庫與LDAP用戶數據庫的同步問題。 7 結語 本 文論述了 一種基于RBAC模型的權限管理系統的 實現技術方案。該 權限管 理系統 已成功應用于系統的設計和開發實踐，與應用系統具有很好的集成。實踐 表明，采用 基于RBAC模型的權限具有以下優勢：權限分配 直觀、容易理解，便于使用；擴展性好，支持崗位、權限多變的需求；分級權限適合分層的組織結構形式； 重用性強。 參考文獻 1. 段云所（著）（Duan Yunsuo）。信息安全概論。北京:高等教育出版社（Beijing：Publishing House of Higher Education），2003 2. Kevin Duffey Vikram Goyal Ted Husted著。JSP站點設計編程指南（Professional JSP Site Design）。北京：電子工業出版社（Beijing：Publishing House of Electronics Industry），2002
總結
- 上一篇： CMD 查看 TCP&UDP 端
- 下一篇： 炒股软件有哪些 有哪些炒股软件