<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
    真的寫得不錯,慢慢體會一下  回復  更多評論
      

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


    網站導航:
     

    <2010年1月>
    272829303112
    3456789
    10111213141516
    17181920212223
    24252627282930
    31123456

    常用鏈接

    留言簿(6)

    隨筆檔案(28)

    文章分類(3)

    文章檔案(4)

    最新隨筆

    搜索

    •  

    積分與排名

    • 積分 - 86472
    • 排名 - 666

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 国产成人yy免费视频| 青娱乐免费视频在线观看| 91精品全国免费观看青青| 亚洲视频免费观看| 亚洲片一区二区三区| 亚洲依依成人精品| a国产成人免费视频| 免费看一级做a爰片久久| 在线电影你懂的亚洲| 产传媒61国产免费| 成人毛片18女人毛片免费96| 亚洲第一中文字幕| 国产精品免费看久久久香蕉| 美女黄网站人色视频免费国产| 亚洲网站在线播放| a级片在线免费看| 亚洲va无码手机在线电影| 十八禁的黄污污免费网站| 在线精品亚洲一区二区三区| 亚洲av无码成人精品国产| 97免费人妻无码视频| 亚洲国产精品成人综合色在线| 两性刺激生活片免费视频| 亚洲日韩一区二区一无码| 国产h视频在线观看网站免费| 国产成人亚洲精品| 国产成人午夜精品免费视频| 亚洲综合色丁香麻豆| 黄网址在线永久免费观看| 久久性生大片免费观看性| 久久久久亚洲爆乳少妇无 | 成年性午夜免费视频网站不卡| 亚洲va在线va天堂成人| 国产99视频精品免费视频7| a级毛片毛片免费观看永久| 亚洲日本在线免费观看| 中国人xxxxx69免费视频| 亚洲Av永久无码精品黑人| 久久亚洲国产精品一区二区| a级毛片免费高清毛片视频| 亚洲人成电影青青在线播放|