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

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


    網站導航:
     

    <2006年11月>
    2930311234
    567891011
    12131415161718
    19202122232425
    262728293012
    3456789

    常用鏈接

    留言簿(6)

    隨筆檔案(28)

    文章分類(3)

    文章檔案(4)

    最新隨筆

    搜索

    •  

    積分與排名

    • 積分 - 86468
    • 排名 - 666

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 丁香五月亚洲综合深深爱| 亚洲欧洲精品成人久久曰影片| 亚洲va无码va在线va天堂| 成人无码精品1区2区3区免费看| 国产亚洲一区二区三区在线不卡| 男人扒开添女人下部免费视频| 亚洲精品无码久久毛片| 久久精品无码专区免费| 精品国产亚洲一区二区三区| 久久久久久久久久国产精品免费 | 亚洲人成无码网站| 最近中文字幕免费大全| 亚洲成人中文字幕| 日韩亚洲国产高清免费视频| 日韩亚洲国产综合高清| 国产精品免费视频播放器| xxxxxx日本处大片免费看| 国产国拍亚洲精品mv在线观看 | 国产vA免费精品高清在线观看| 伊人婷婷综合缴情亚洲五月| 全免费a级毛片免费看| 免费福利网站在线观看| 亚洲精品国产精品乱码在线观看| 国产VA免费精品高清在线| 亚洲AV无码专区亚洲AV伊甸园| 亚洲精品免费在线视频| 亚洲AV无码一区二区三区网址| 国产亚洲精品不卡在线| 精品无码免费专区毛片| 国产精品亚洲一区二区三区 | 中文字幕 亚洲 有码 在线| 免费观看日本污污ww网站一区| 精品无码国产污污污免费网站国产| 久久久亚洲欧洲日产国码农村| 中文字幕无码免费久久99| 黄色网页免费观看| 亚洲首页在线观看| 亚洲成A∨人片天堂网无码| 99久久久国产精品免费蜜臀| 亚洲精品色在线网站| 亚洲五月六月丁香激情|