andyj2ee

          java tec sky

          統計

          留言簿(4)

          activemq

          aop

          design pattern

          other blog

          spring

          workflow

          多線程

          軟件架構師

          閱讀排行榜

          評論排行榜

          基于角色管理(RBAC)的權限系統

           

          這里的權限系統要區分2個概念:

           

          粗粒度:表示類(model)別級,即僅考慮對象的類別(the type of object),不考慮對象的某個特定的實例。比如,對合同這個類別(contract)的管理中,創建、刪除等操作,對所有的用戶都一視同仁,并不區分具體的對象實例(銷售合同,生產合同)。

          細粒度:表示實例(instance)級別,即需要考慮具體對象的實例(the instance of object),當然,細粒度是在考慮粗粒度的對象類別之后才再考慮特定實例。比如,銷售合同管理中,合同所有者擁有查看、修改、刪除等權限,其他用戶只有合同的查看權限。

          權限系統的設計原則:權限邏輯配合業務邏輯。即權限系統以為業務邏輯提供服務為目標。

           

          細粒度的權限問題因為其業務相關性而不具通用意義,它們被理解為是業務邏輯的一部分。比如,要求:某個合同只能被它的創建者刪除,與創建者同組的用戶可以修改,所有的用戶能夠瀏覽。這既是一個細粒度的權限問題,也是一個業務邏輯問題。在這里它是業務邏輯問題,在整個權限系統的架構設計之中不予考慮。當然,權限系統的構架設計也必須要能支持這樣的業務邏輯?;蛘哒f,系統提供足夠多但不是完全的控制能力。即,設計原則歸結為:系統只提供粗粒度的權限,細粒度的權限被認為是業務邏輯的職責。

          權限邏輯 ?à 粗粒度

           

          業務邏輯 ?à 細粒度

          概念:

           

          Object:  指系統中各種功能模塊,業務模型(Model),業務對象(Object),界面元素等,它是主體能訪問到的所有對象。由于對象的類型不同,被訪問的權限也不同。

          (1)      系統功能模塊:系統中除了公用的界面,公用的模塊外,其他均為業務功能模塊,業務操作在設計階段完成,因此不存在實例的概念。可以直接針對角色進行授權。

          (2)      界面元素:除了功能菜單受到控制外,如要控制功能模塊的界面元素其功能模塊界面元素也需定義,大部分界面元素均包含有相關的業務功能操作,因此可以與數據模型統一來處理。

          (3)      業務模型,業務對象:業務模型是我們的Domain Model,開發人員在設計開發階段就已經定義好了相關的業務操作,也就是相應的權限。 業務對象是我們業務模型的實例化Domain Object。是用戶在系統運行時創建的,因此它的權限也是用戶在系統運行時創建的。

          粗粒度

           

          細粒度

           

          Domain Model

          業務模型,比如合同(Contract Model

          Domain Object

          業務模型的某個實例話對象,比如銷售合同(Sell Contract Object

          Privilege(Operative, Permission) : Object Related的操作。就是指,這個權限是綁定在特定的對象上的。比如說部門新聞的發布權限,叫做"部門新聞發布權限"。這就表明,該Privilege是一個發布權限,而且是針對部門新聞這種資源的一種發布權限。權限,包括系統定義權限和用戶自定義權限,用戶自定義權限之間可以指定排斥和包含關系(如:讀取,修改,管理三個權限,管理 權限 包含 前兩種權限)

          Role: 是權限的集合,是粗粒度和細粒度(業務邏輯)的接口。一個基于粗粒度控制的權限框架軟件,對外的接口應該是Role,具體業務實現可以直接繼承或拓展豐富Role的內容,Role不是如同UserGroup的具體實體,它是接口概念,抽象的通稱。Role的繼承通過Group來體現,所以不考慮Role的繼承關系。但是Role可以與相關的Group相關聯,便于授權。

           

          Group: 用戶組,權限分配的單位與載體,直接映射組織關系。權限不考慮分配給特定的用戶。組可以包括組(以實現權限的繼承)。組可以包含用戶,組內用戶繼承組的權限。Group要實現繼承。即在創建時必須要指定該GroupParent是什么Group。在粗粒度控制上,可以認為,只要某用戶直接或者間接的屬于某個Group那么它就具備這個Group的所有操作許可。細粒度控制上,在業務邏輯的判斷中,User僅應關注其直接屬于的Group,用來判斷是否同組。

           

          但是Group的繼承導致的權限繼承和組織關系正好相反,組織關系的上層相應的權限更大,所以是一種逆向繼承。

          User: 純粹的用戶,與權限(operative?permission?privilege)分離,只能通過Role去關聯相應的權限。

           

          關系:

          Privilege ? n : 1 à Resource

          Role ? n : n à Privilege

          Group ? n : n à User

          Group ? n : n à Role

          User ? n : n à Role

          權限系統的操作模式:

          (1): 創造資源,權限:  這里要從粗,細粒度2方面來考慮

          粗粒度:開發人員設計DomainModel的時候就定義好相關的操作。比如ContractModel

          這個DomainModel,開發人員設計的時候就已經定義好了模型的相關操作,比如查看,修改等等。默認的情況下對所有的Role都是相同的。

                   細粒度: 用戶創建一個DomainModel的實例DomainObject的時候指定相關的權

          限以及權限分配。比如銷售合同只能創建者有修改的權限,同Group的人員只能擁有查看的權限。

          (2): 分配權限: Administrator指定相關DomainModel的權限分配,創建Role,創建Group,給

          Group分配User,給Group賦予某個Role等等。

          (3): 使用權限: User 使用 Administrator分配的角色去使用相應的系統功能。

          模塊劃分:

          1)        對象管理模塊。此模塊主要負責從粗細粒度對于系統中可提供的資源或資源實例進行管理。

          2)        權限管理模塊。此模塊主要負責對資源權限進行管理。管理員可以在粗細粒度下對資源權限進行管理。用戶可以對創建的資源實例進行權限的管理。

          3)        角色管理模塊。此模塊主要負責對角色進行相應的管理(包括添加、刪除、修改);對角色所擁有的權限進行相應的管理(包括授予、刪除所擁有的權限);對用戶和組賦予相應的角色等等

          4)        用戶管理模塊。此模塊主要負責對用戶進行管理(包括添加、刪除、修改);對用戶所屬的角色進行管理(包括添加、刪除);對用戶所屬的組進行管理。

          5)        組管理模塊。組映射組織機構,提供對于部門組織機構維護(添加、修改、刪除);對組的成員進行維護;對組所擁有的角色進行管理。



          方向:分布式系統設計

          posted on 2005-04-22 10:40 java光環 閱讀(2155) 評論(0)  編輯  收藏 所屬分類: rbac


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


          網站導航:
           
          主站蜘蛛池模板: 东辽县| 田东县| 武穴市| 华亭县| 宾阳县| 漾濞| 和政县| 康保县| 穆棱市| 台安县| 红桥区| 兴文县| 陆丰市| 京山县| 安平县| 崇信县| 拜泉县| 资中县| 衡水市| 凤翔县| 额尔古纳市| 基隆市| 南乐县| 元谋县| 阳城县| 滕州市| 凤山县| 改则县| 竹北市| 乌拉特前旗| 宣恩县| 永善县| 璧山县| 绵竹市| 忻城县| 青浦区| 阿克陶县| 郁南县| 固始县| 龙井市| 高邑县|