資料庫rbac
㈠ 五張表的RBAC有什麼優缺點 做許可權時幾張表最為合適
相同點:
兩種都是基於角色許可權控制
2.都是同一個用戶可屬於多個角色或用戶組
不同點:
Rbac:
1.Rbac是基於節點控制,根據3級節點,mole,controller,action,節點類似與樹形結構,3級節點間相互有關聯
2.表關系:用戶表->用戶角色關聯表->角色表->角色節點關聯表->節點表
3.根據3級節點控制,粒度到操作action,每個節點為單一的模塊,控制器或操作
Auth:
1.Auth是基於規則控制,定製規則和條件表達式 ,每一條規則都是獨立的
2.表關系:用戶表->用戶和用戶組關聯表->用戶組表->規則表
3.根據規則控制,可自由定製不同的規則,非常自由,同一個規則內可以定製多個不同節點(中間的關系:OR AND)
4.可定製規則表達式,比如定製積分表達式
想法和問題:
Auth:
1.Auth驗證多條規則時條件表達式不起效果
2.Auth官方例子只說一個根據積分的規則,假如我規則"Admin/Goods/goodsList,Admin/Goods/goodsDel"我
能不能定義這裡面的某些ID所屬角色操作許可權的規則表達式,而這些所屬角色id是goods表裡的某個欄位,可能所屬的角色是多個不同的角色?
3.Auth不支持"Admin/*"泛解析,因為他每一條規則都是獨立的
4.對菜單,頁面,按鈕類的顯示使用Auth會必Rbac更好更方便
Rbac:
1.新手配置Rbac的時候經常出現 Rbac $_SESSION['_access_list'] 獲取不到的問題,因為Rbac是使用ThinkPHP的底層DB引擎DSN連接資料庫,需要配置資料庫鏈接和5個表的關系,欄位名和表名不能出現問題
2.允許完成"Admin/*"類型的泛解析,比如這里直接定製一個Admin模塊的節點,不要下級節點就可以了
通用:
1.不管是Rbac的角色表或者Auth裡面的用戶組表也好,都可以擴展,比如對角色或用戶組進行多層分級
2.Rbac的節點和Auth的規則都可以進行分級,比如前端功能許可權,後端功能許可權,後端某個功能模塊許可權等等
3.上面兩個東西都不能應用到許可權管控之中去,比如Rbac不能分享上級角色許可權,Auth用戶組也不能,但是能更好的管理和更加流程化的操作.
㈡ thinkphp的auth許可權和rbac有什麼區別
相同點:
1.兩種都是基於角色許可權控制
2.都是同一個用戶可屬於多個角色或用戶組
不同點:
Rbac:
1.Rbac是基於節點控制,根據3級節點,mole,controller,action,節點類似與樹形結構,3級節點間相互有關聯
2.表關系:用戶表->用戶角色關聯表->角色表->角色節點關聯表->節點表
3.根據3級節點控制,粒度到操作action,每個節點為單一的模塊,控制器或操作
Auth:
1.Auth是基於規則控制,定製規則和條件表達式 ,每一條規則都是獨立的
2.表關系:用戶表->用戶和用戶組關聯表->用戶組表->規則表
3.根據規則控制,可自由定製不同的規則,非常自由,同一個規則內可以定製多個不同節點(中間的關系:OR AND)
4.可定製規則表達式,比如定製積分表達式
想法和問題:
Auth:
1.Auth驗證多條規則時條件表達式不起效果
2.Auth官方例子只說一個根據積分的規則,假如我規則"Admin/Goods/goodsList,Admin/Goods/goodsDel"我
能不能定義這裡面的某些ID所屬角色操作許可權的規則表達式,而這些所屬角色id是goods表裡的某個欄位,可能所屬的角色是多個不同的角色?
3.Auth不支持"Admin/*"泛解析,因為他每一條規則都是獨立的
4.對菜單,頁面,按鈕類的顯示使用Auth會必Rbac更好更方便
Rbac:
1.新手配置Rbac的時候經常出現 Rbac $_SESSION['_access_list'] 獲取不到的問題,因為Rbac是使用ThinkPHP的底層DB引擎DSN連接資料庫,需要配置資料庫鏈接和5個表的關系,欄位名和表名不能出現問題
2.允許完成"Admin/*"類型的泛解析,比如這里直接定製一個Admin模塊的節點,不要下級節點就可以了
通用:
1.不管是Rbac的角色表或者Auth裡面的用戶組表也好,都可以擴展,比如對角色或用戶組進行多層分級
2.Rbac的節點和Auth的規則都可以進行分級,比如前端功能許可權,後端功能許可權,後端某個功能模塊許可權等等
3.上面兩個東西都不能應用到許可權管控之中去,比如Rbac不能分享上級角色許可權,Auth用戶組也不能,但是能更好的管理和更加流程化的操作.
㈢ 用一個具體資料庫,分別使用BLP模型和RBAC模型對其進行訪問控制策略分析
網路：陳步英
㈣ 請教關於RBAC許可權管理
禁止的許可權規則集
如果許可權規則不是一個集合，因為只有與用戶或角色關聯的許可權規則才允許訪問，所以用戶的許可權是一個閉合區域，不想用戶擁有某些許可權時，只要不進行關聯授權即可。如果許可權規則使用通配符變成一個集合，那麼用戶的許可權將變成一個開放區域，比如上面的論壇文章列表，假設論壇文章按照「版面/作者/文章標題」作為資源命名，那麼將(閱覽, 版面/作者/*)授權給某用戶時，該用戶允許閱覽該版面下該作者的所有文章，假設現在有一種管理需求要求某用戶可以閱覽某版面下某作者除某幾種文章標題外的所有文章，這樣單純的允許授權難以實現這個管理需求。
法律有許可和禁止的區別，那麼許可權管理也應該有許可和禁止兩種授權，上面的不允許訪問某幾種文章標題的文章就是一種禁止規則，如果將這種禁止規則合並到允許規則中，就可以解決上面的問題。這就相當於畫了一個大圈表示可以訪問的區域，但是大圈裡面的某些小圈是不可以訪問的區域。這又帶來一個問題，假設允許的和禁止的規則重疊，以誰為准？這個沒有一個准則，不過基於安全性考慮，應該採用禁止優先，只要是禁止的集合，就算有允許的集合重疊，也不允許訪問。
提高許可權驗證效率
使用關系資料庫存儲許可權數據時，許可權數據表更新和查詢的操作頻繁度通常小於1:9，也就是這是一個典型的OLAP系統，以查詢為主，所以可以採用OLAP的優化策略進行優化，但是大多數優化策略都不具備實時性，如果兼顧實時性和效率要求，可以單獨創建一個內存資料庫，這個內存資料庫只存放用戶、資源、操作關聯關系，也就是(用戶, 操作, 資源)集合，如果用戶通過角色關聯到許可權規則，那麼將這些用戶到許可權規則的間接傳遞關系轉變成直接傳遞關系保存。這個內存資料庫就相當於許可權數據的緩存，可以保證很高的查詢效率，並且該內存資料庫與許可權管理保持同步，可以保證實時性。
安裝和配置
附件是許可權管理和許可權驗證的實現，也有用戶管理的演示，不過用戶管理很粗糙，實際使用需要做進一步開發，之所以沒有開發相對完善的用戶管理，是因為現在已有的系統通常都有完善的用戶管理。
下面簡單講解安裝配置，只在Tomcat5523+MySQL5037+jre1.5.0_12下測試過。
1． 下載rbac+profile.rar，解壓，得到一系列文件，文件用途如下：
profile.admin.src.v1.jar 用戶管理源代碼
rbac.admin.src.v2.jar 許可權管理源代碼
rbac.auth.src.v2.jar 許可權驗證源代碼
profile.v1.MySQL5.sql 用戶管理用戶數據表
profile.war 用戶管理WEB系統
rbac.v2.MySQL5.sql 許可權管理數據表
rbac.war 許可權管理WEB系統
2． 創建資料庫profile，使用UTF-8導入profile.v1.MySQL5.sql到profile，使用下面SQL創建用戶root/1：
Insert into T_PROFILE(USER_ID, USER_NAME, USER_PASSWORD) values(『1』, 『root』, sha1(『1』));
如果創建過先前SSO單點登陸的用戶數據表，可以跳過這步，使用先前的數據表。
3． 創建資料庫rbac，使用UTF-8導入rbac.v2.MySQL5.sql到rbac。
4． 拷貝profile.war和rbac.war到Tomcat5523/webapps/，會自動生成profile和rbac目錄。
5． 參考http://blog.chinaunix.net/u1/52224/showart_412714.html配置單點登陸，因為許可權管理和用戶管理需要依賴單點登陸。
6． 下載相關依賴Java庫：
下載cglib最新版本http://cglib.sourceforge.net/，拷貝asm.jar和cglib-2.1.3.jar到Tomcat/shared/lib。
下載c3p0最新版本http://sourceforge.net/projects/c3p0，拷貝c3p0-0.9.1.1.jar到Tomcat/shared/lib。
下載mysql-connector最新版本http://sourceforge.net/projects/mmmysql/，拷貝mysql-connector-java-5.0.4-bin.jar到Tomcat/shared/lib。
下載dwr最新版本http://getahead.org/dwr，拷貝dwr2.0.1.jar到Tomcat/shared/lib。
7． 打開profile/ WEB-INF/classes/的rbac_auth.properties、sso_agent.properties、profile_admin.properties。
# 修改為合適配置
# rbac_auth.properties
rbac.auth.db.ds.c3p0.url=jdbc:mysql://localhost/rbac
rbac.auth.db.ds.c3p0.user=root
rbac.auth.db.ds.c3p0.password=1
# sso_agent.properties
sso.passport.login=http://bsmith-cn:8080/sso/passport/login.srv
sso.passport.logout=http://bsmith-cn:8080/sso/passport/logout.srv
# profile_admin.properties
profile.admin.db.ds.c3p0.url=jdbc:mysql://localhost/profile
profile.admin.db.ds.c3p0.user=root
profile.admin.db.ds.c3p0.password=1
8． 打開rbac/WEB-INF/classes/下的rbac_admin.properties、rbac_auth.properties、sso_agent.properties。
# 修改為合適配置
# rbac_auth.properties
rbac.auth.db.ds.c3p0.url=jdbc:mysql://localhost/rbac
rbac.auth.db.ds.c3p0.user=root
rbac.auth.db.ds.c3p0.password=1
# sso_agent.properties
sso.passport.login=http://bsmith-cn:8080/sso/passport/login.srv
sso.passport.logout=http://bsmith-cn:8080/sso/passport/logout.srv
# rbac_admin.properties
rbac.admin.profile.explorer=http://bsmith-cn:8080/profile/admin/explorer.jsp?
rbac.admin.profile.profile=http://bsmith-cn:8080/profile/admin/profile.jsp?
rbac.admin.db.rbac.ds.c3p0.url=jdbc:mysql://localhost/rbac
rbac.admin.db.rbac.ds.c3p0.user=root
rbac.admin.db.rbac.ds.c3p0.password=1
㈤ 需求一個基於RBAC許可權管理系統，JAVA版的，最好用SSH2做的，帶資料庫和源碼有的發郵箱[email protected]
自己做吧
㈥ 基於RBAC許可權設置的幾個問題
搜一下rbac，角色都在一個表中，分配許可權什麼的你用前端，然後帶id
㈦ 求個java版的rbac許可權管理系統做畢設，需要源代碼資料庫，最好有報告. 郵箱1540257456@qq
RBAC的意思是基於角色的許可權管理系統, 我這里好多基於Springmvc+Spring+mybatis整合的項目都是用這個模型回來實現的, 這個主要是要完答成好資料庫的設計
用戶表
資源表
角色表
用戶-角色表
角色-資源表
每次登陸的時候聯合查詢把所能訪問的資源查一遍就可以了
㈧ rbac是一種資料庫設計思想嗎
用戶的數量非常大時，要給系統每個用戶逐一授權（授角色），是件非常煩瑣的事情。這時，回就需要給答用戶分組，每個用戶組內有多個用戶。除了可給用戶授權外，還可以給用戶組授權。這樣一來，用戶擁有的所有許可權，就是用戶個人擁有的許可權與該用戶所在用戶組擁有的許可權之和。（下圖為用戶組、用戶與角色三者的關聯關系）
在應用系統中，許可權表現成什麼？對功能模塊的操作，對上傳文件的刪改，菜單的訪問，甚至頁面上某個按鈕、某個圖片的可見性控制，都可屬於許可權的范疇。有些許可權設計，會把功能操作作為一類，而把文件、菜單、頁面元素等作為另一類，這樣構成「用戶-角色-許可權-資源」的授權模型。而在做數據表建模時，可把功能操作和資源統一管理，也就是都直接與許可權表進行關聯，這樣可能更具便捷性和易擴展性。
㈨ oracle許可權設計原理像oracle、mysql等資料庫許可權設計是不是都是基於角色訪問控制(rbac)的原理啊
Oracle是基於角色訪問控制的.