<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    posts - 30,  comments - 85,  trackbacks - 0

    權限分析文檔

    基于RBAC的權限設計模型:

    ?

    1??????? RBAC 介紹

    RBAC 模型作為目前最為廣泛接受的權限模型。

    NIST The National Institute of Standards and Technology,美國國家標準與技術研究院)標準RBAC模型由4個部件模型組成,這4個部件模型分別是基本模型RBAC0Core RBAC)、角色分級模型RBAC1Hierarchal RBAC)、角色限制模型RBAC2Constraint RBAC)和統一模型RBAC3Combines RBAC[1]RBAC0模型如圖1所示。

    clip_image001.jpg
    圖表 1 RBAC 0 模型

    l ???????? RBAC0 定義了能構成一個RBAC控制系統的最小的元素集合

    RBAC之中,包含用戶users(USERS)、角色roles(ROLES)、目標objects(OBS)、操作operations(OPS)、許可權permissions(PRMS)五個基本數據元素,權限被賦予角色,而不是用戶,當一個角色被指定給一個用戶時,此用戶就擁有了該角色所包含的權限。會話sessions是用戶與激活的角色集合之間的映射。RBAC0與傳統訪問控制的差別在于增加一層間接性帶來了靈活性,RBAC1RBAC2RBAC3都是先后在RBAC0上的擴展。

    l ???????? RBAC1 引入角色間的繼承關系

    角色間的繼承關系可分為一般繼承關系和受限繼承關系。一般繼承關系僅要求角色繼承關系是一個絕對偏序關系,允許角色間的多繼承。而受限繼承關系則進一步要求角色繼承關系是一個樹結構。

    l ???????? RBAC2 模型中添加了責任分離關系

    RBAC2 的約束規定了權限被賦予角色時,或角色被賦予用戶時,以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。責任分離包括靜態責任分離和動態責任分離。約束與用戶-角色-權限關系一起決定了RBAC2模型中用戶的訪問許可。

    l ???????? RBAC3 包含了RBAC1RBAC2

    既提供了角色間的繼承關系,又提供了責任分離關系。

    建立角色定義表。定出當前系統中角色。

    因為有繼承的問題,所以角色體現出的是一個樹形結構。

    test.bmp

    2??????? 權限設計:

    ?

    配置資源以及資源的操作 : 這里資源可以定義為一個通用的資源模型。提供通用的資源統一接口。

    ?

    ?

    ?

    ?

    ?

    數據庫 ER 圖:

    clip_image002.gif

    ?

    關系圖:

    ?

    clip_image003.gif

    ?

    未命名.bmp

    ?

    3??????? 分析:

    ?

    ??? 根據以上的類關系圖和ER圖可以看出。整個權限可以抽象為五個對象組成。

    OrgBean : 用于描述org模型。

    Role : 用于描述角色。

    Permission : 用于描述權限。

    Resource : 用于描述資源。

    Operation : 用于描述操作。

    ?

    其中Permission中有Resource , Operation 的聚合,資源和操作組成權限。

    Role Permission 都有自包含。因為設計到權限的繼承。

    資源Resource 也可能出現一顆樹形結構,那資源也要有自包含。

    ?

    思想 :

    權限系統的核心由以下三部分構成: 1. 創造權限, 2. 分配權限, 3. 使用權限,然后,系統各部分的主要參與者對照如下: 1. 創造權限 - Creator 創造, 2. 分配權限 - Administrator 分配, 3. 使用權限 - User

    1. Creator 創造 Privilege Creator 在設計和實現系統時會劃分,一個子系統或稱為模塊,應該有哪些權限。這里完成的是 Privilege Resource 的對象聲明,并沒有真正將 Privilege 與具體 Resource 實例聯系在一起,形成 Operator

    2. Administrator 指定 Privilege Resource Instance 的關聯 。在這一步, 權限真正與資源實例聯系到了一起, 產生了 Operator Privilege Instance )。 Administrator 利用 Operator 這個基本元素,來創造他理想中的權限模型。如,創建角色,創建用戶組,給用戶組分配用戶,將用戶組與角色關聯等等 ... 這些操作都是由 Administrator 來完成的。

    3. User 使用 Administrator 分配給的權限去使用各個子系統。 Administrator 是用戶,在他的心目中有一個比較適合他管理和維護的權限模型。于是,程序員只要回答一個問題,就是什么權限可以訪問什么資源,也就是前面說的 Operator 。程序員提供 Operator 就意味著給系統穿上了盔甲。 Administrator 就可以按照他的意愿來建立他所希望的權限框架 可以自行增加,刪除,管理 Resource Privilege 之間關系。可以自行設定用戶 User 和角色 Role 的對應關系。 ( 如果將 Creator 看作是 Basic 的發明者, Administrator 就是 Basic 的使用者,他可以做一些腳本式的編程 ) Operator 是這個系統中最關鍵的部分,它是一個紐帶,一個系在 Programmer Administrator User 之間的紐帶。

    ?

    4??????? 權限API

    ? ?getPermissionByOrgGuid(String orgGuid )

    ??? ? 通過傳入一個orgGuid , 拿到當前這個org對象都具有那些訪問權限。

    ?getSourcePermissionByOrgGuid(String orgGuid , String resouceGuid)

    ??? 通過傳入一個orgGuid 和 一個資源的Guid , 返回改Org對當前這個資源的訪問權限。

    ?

    getPermissionByResourceGuid(String resource)

    ??? 通過傳入一個資源的Guid , 得到當前資源下都有那些權限定義。

    ?

    havingHeritPermission(String orgGuid , String resouceGuid) : Boolean

    ??? 傳入一個orgGuid, 資源GUID ,查看改OrgGuid下對資源是否有向下繼承的權限。這里繼承是資源的繼承。即對父欄目有權限,可以繼承下去對父欄目下的子欄目同樣有權限。

    ?

    havingPermission(String orgGuid , String resourceGuid) : Boolean

    ??? 判斷某Org對某一資源是否用權限。

    ?

    以上是粗粒度的權限API 。 以下為細粒度的權限:

    ?

    getOperationByPermission(String permissionGuid)

    ??? 通過permission Guid 得到該permission 的所有有效操作。

    ?

    getOperationByGuid(String permissionGuid , String resourceGuid)

    ??? 通過permisionGuid , 資源的Guid 得到該資源下所有的有效操作。

    ?

    screeningOpreationByGuid (String permissionGuid , String resourceGuid , String orgGuid)

    ??? 通過permission resource orgGuid 得到改Org對這一資源的有效操作。

    ?

    hasOperation(String operationGuid) : boolean

    ??? 通過傳入的operationGuid 返回是否具有操作權限。

    ?

    5??????? 權限的實現:

    1 .表單式認證,這是常用的,但用戶到達一個不被授權訪問的資源時, Web 容器就發

    出一個 html 頁面,要求輸入用戶名和密碼。

    2 .用 Filter 防止用戶訪問一些未被授權的資源, Filter 會截取所有 Request/Response

    然后放置一個驗證通過的標識在用戶的 Session 中,然后 Filter 每次依靠這個標識來決定是否放行 Response

    這個模式分為:

    Gatekeeper :采取 Filter 或統一 Servlet 的方式。

    Authenticator Web 中使用 JAAS 自己來實現。

    ?

    Filter 攔截只是攔截該用戶是否有訪問這個頁面,或這一資源的權限。真正做到顯示后攔截是在應用程序內部去做。

    ?

    做顯示攔截提供API , 標簽這兩種方式。

    posted on 2006-11-21 14:37 安文豪 閱讀(9710) 評論(3)  編輯  收藏

    FeedBack:
    # re: [原創] 基于RBAC的權限設計 - 歡迎大家討論
    2009-12-19 00:58 | java1995
    請問下 你的UML是用什么畫的啊?  回復  更多評論
      
    # re: [原創] 基于RBAC的權限設計 - 歡迎大家討論
    2010-01-15 11:50 | idreamer
    您的這篇文章我已經讀過n遍了,上次一個論文作為參考文獻,這次又來看看rbac的分級。  回復  更多評論
      
    # re: [原創] 基于RBAC的權限設計 - 歡迎大家討論
    2011-10-16 18:52 | qq346
    真的寫得不錯,慢慢體會一下  回復  更多評論
      

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


    網站導航:
     

    <2009年12月>
    293012345
    6789101112
    13141516171819
    20212223242526
    272829303112
    3456789

    常用鏈接

    留言簿(6)

    隨筆檔案(28)

    文章分類(3)

    文章檔案(4)

    最新隨筆

    搜索

    •  

    積分與排名

    • 積分 - 86472
    • 排名 - 666

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 亚洲第一精品福利| 亚洲精品无码久久久久| 亚洲一区二区三区高清视频| 七色永久性tv网站免费看| 亚洲乱码无码永久不卡在线| 国产免费人成视频尤勿视频| 国产成人99久久亚洲综合精品 | 免费精品人在线二线三线区别| 337p欧洲亚洲大胆艺术| 99国产精品视频免费观看| 久久精品国产亚洲av麻豆小说| 性xxxxx大片免费视频| 亚洲老熟女@TubeumTV| 亚洲美女免费视频| 亚洲免费综合色在线视频| 国产精品二区三区免费播放心| 国产青草亚洲香蕉精品久久| 又粗又硬免费毛片| 久久国产精品免费| 97久久精品亚洲中文字幕无码 | 国内精品免费视频精选在线观看| 亚洲AV无码成人专区片在线观看 | 亚洲va中文字幕无码久久| 永久免费A∨片在线观看| 久久久国产精品亚洲一区| 黄页网站在线看免费| 亚洲av无码成人精品区一本二本| 亚洲国产精品第一区二区三区| 中文字幕a∨在线乱码免费看| 亚洲日本中文字幕| 免费看的黄色大片| 久久久久女教师免费一区| 亚洲美免无码中文字幕在线| 日韩免费视频网站| a级毛片毛片免费观看久潮| 亚洲国产成人久久| 亚洲午夜精品第一区二区8050| 久久中文字幕免费视频| 精品亚洲成a人在线观看| 国产A在亚洲线播放| 最新仑乱免费视频|