<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與傳統訪問控制的差別在于增加一層間接性帶來了靈活性,RBAC1RBAC2、RBAC3都是先后在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 之間關系??梢宰孕性O定用戶 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)

    最新隨筆

    搜索

    •  

    積分與排名

    • 積分 - 86493
    • 排名 - 666

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 亚洲精品美女久久7777777| 毛片在线播放免费观看| 亚洲国产成人久久一区WWW| 中文字幕无码日韩专区免费 | 亚洲av永久中文无码精品| 亚洲精品无码av天堂| 最近2019免费中文字幕视频三| 亚洲色欲色欲www在线播放| 国产亚洲精品激情都市| 人成午夜免费视频在线观看| 男女啪啪免费体验区| 67pao强力打造67194在线午夜亚洲 | 99精品免费视品| 亚洲av无码一区二区三区观看| 亚洲精品无码专区2| 中文字幕无码成人免费视频 | 国产片免费在线观看| 午夜精品射精入后重之免费观看 | 亚洲中文字幕日产乱码高清app| 2020久久精品国产免费| 一级毛片**免费看试看20分钟| 亚洲精品不卡视频| 中文亚洲成a人片在线观看| 免费无码AV片在线观看软件| 99免费在线视频| 免费观看亚洲人成网站| 亚洲国产成人精品无码区在线秒播| 国产日韩成人亚洲丁香婷婷| 免费被黄网站在观看| 免费无码一区二区三区| 一区二区三区免费视频观看| 亚洲欧美黑人猛交群| 亚洲三级中文字幕| 亚洲av无码国产精品色午夜字幕| 四虎影库久免费视频| 久久精品网站免费观看| 麻豆成人久久精品二区三区免费| jyzzjyzz国产免费观看| 蜜臀亚洲AV无码精品国产午夜.| 亚洲精品123区在线观看| 亚洲精品一卡2卡3卡三卡四卡|