2010年9月6日
-------------------------------------------- 總大綱 ---------------------------------
Ralasafe開源有段時間了，大約有2個月了。根據社區的反饋，我打算圍繞Ralasafe最佳實踐，書寫一系列BLOG。
大體內容有：
1， 登錄控制： 哪些頁面需要登錄后才能訪問，登錄用戶名、密碼驗證，登錄轉向頁面；
2， URL權限控制：哪些頁面訪問需要進行角色權限驗證，怎樣驗證最簡單有效，如何處理驗證失敗情況；
3， 數據級權限管理方案探討：選擇中間件呢還是框架？
4， Ralasafe體系結構： 用戶怎么讀取，用戶有哪些字段，怎樣與應用基礎；
5， 數據級查詢權限管理： 如何給不同的人分配不同的查詢數據權限，返回where條件呢，還是直接返回結果集？
6， 數據級決策權限管理： 如何給不同的人分配不同的數據操作權限，當用戶不具備權限怎么辦？
7， 其他細小的權限控制： 如下拉框顯示內容；按鈕、鏈接是否顯示，圖片是否顯示等。
-------------------------------------------- ------- --------------------------------
數據級權限管理需求
數據級權限管理需求主要有：
1，支持不同用戶查詢到數據是不同的；
2，支持數據庫行級、列級查詢；
3，支持分頁查詢——包括2個方面：a，分頁查出數據；b，能告知總數據條數是多少；
4，支持自定義條件（比如：張三在自己的查詢權限范圍內，查詢50w以上的訂單）。
理論分析
能夠將數據級權限，與業務分離出來——是多年來開發人員追求的目標。一旦遇到疑難雜癥，馬上會讓人聯想到高難度的API編程，或者絢麗的XML配置。
不過，我今天的分析，會極其簡單。不過我強烈建議大家看下去。如果對該方案有所懷疑，請使用你的應用案例進行試驗。我當時不敢確認的時候，就是這么做的。
（當初，我提出該方案的時候，我們團隊認為該方案過于簡單，不可行。我堅持讓他們實現該方案。等產品做出來后，他們略有所悟，認為該方案可行。當，我讓他們做demo的時候，將該方案運用于案例的時候，他們拍腿叫道：超級太棒了！我希望你也有該感受）
分類思想的提出
首先，我們思考這個問題：為什么我們在程序里面使用了if/else？為什么數據級權限難以處理？
原因就是：1，有很多種情況；2，我們需要針對不同的人、不同的情況做不同的權限邏輯。比如：
if 是總公司用戶？ then 查詢所有訂單；
else if 是分公司用戶？ then 查詢本分公司（${用戶的公司}）及下屬子公司訂單；
else // 是子公司用戶了
then 查詢本子公司訂單（${用戶的公司}）
在RBAC模型里面有用戶群組概念，也有不少開發人員將用戶群組引入數據級權限管理領域。群組很好的將用戶歸組，但不足之處是要事先將用戶歸入組內。比如，在將張三指定到“總公司用戶組”之前，他不屬于該用戶組，即便張三的機構屬性顯示他屬于總公司。
我們對群組進行稍微改造：使用規則來定義群組，滿足該規則的用戶，我們則認為該用戶屬于該群組。傳統編程里面的if/else判斷條件，基本都可以使用規則或者規則表達式組來描述。此時，張三的機構屬性顯示是總公司，那么他就屬于總公司用戶組；如果他的機構屬性是某個分公司，那么他就屬于分公司用戶組了。無需進行額外操作（指定、重新指派等，一切都是動態智能的）。
OK，至此，我們提出了使用規則描述的“用戶分類”。該規則應該能讀取用戶信息、上下文信息、數據查詢等，并進行相關運算（比較、集合運算等）
至此，我們可以基于用戶要分類，為每個用戶分類分配一個查詢。（該查詢可以接受相關參數，比如用戶參數、上下文參數等）
那么上述例子，使用分類思想，可以這么解決：
用戶分類：總公司用戶類 —— 查詢：查詢所有訂單
用戶分類：分公司用戶類 —— 查詢：查詢本分公司及下屬子公司訂單；
用戶分類：子公司用戶類 —— 查詢：查詢本子公司訂單。
與功能權限結合
我認為功能權限與數據權限分開非常合適。功能權限由企業IT管理員維護；數據權限由軟件開發商維護。有人會說這樣不好，比如這個案例怎么處理：
普通審查員可以審查50w財務數據；中級審查員審查50w～500w的財務數據。這個50w、500w，企業需要自行維護。
OK，我認為這50w、500w應該稱為“權限策略數據”，可以保存到數據庫里面，做為基礎數據或者數據字典由企業通過界面自行維護。而軟件開發商，開發的“數據級權限”策略讀取這些數據。（當然，你可以緩存。。。。）
Ralasafe方案
怎樣實現數據級查詢權限
為了理解本節內容，建議下載ralasafe demo應用，對照圖形界面，更容易理解些。
Ralasafe使用管理界面來定制用戶分類、定制數據查詢。為了確保定制無誤，Ralasafe支持在線測試。比如定制用戶分類后，可以選擇一個用戶進行測試。數據查詢等都是可以在線測試的。
定制完畢后，將用戶分類和數據查詢配對，賦給特點權限。一個權限，可以賦多個（用戶分類——數據查詢）配對。和前面的理論分析一樣。
具體定制，怎樣配對，可以參考文檔，配有圖片，在此不做多說。定制用戶分類，定制數據查詢，給權限授權策略（即配對）。
怎樣與應用結合
Ralasafe提供org.ralasafe.Ralasafe和org.ralasafe.WebRalasafe兩個接口類。里面的query方法對應數據級查詢權限。在應用系統相應的地方，調用該方法即可。我建議在系統的控制層調用，即：servlet或者action。
ralasafe demo例子，EmployeServlet就是這么調用的：（demo演示員工查詢，不是訂單查詢
）
// 通過Ralasafe接口獲取當前用戶被授權查看的員工
Collection employees = WebRalasafe.query(req, Privilege.QUERY_EMPLOYEE);
// 將數據放入request，供前臺展示
req.setAttribute("employees", employees);
OK，就這么簡單。需要編程的工作量非常非常少，達到了極致。世界從此清凈了。
（WebRalasafe.query方法接受req<HttpRequest>參數，從這里讀取User。Ralasafe.query方法則直接傳入User，可供非web類應用調用）
系統結構
Ralasafe由權限引擎和管理界面組成。權限引擎解析權限策略；管理界面生成、維護權限策略。如圖示：
注：ralasafe團隊博客在javaeye/baidu/blogjava等空間，同步發布。ralasafe官方網站：http://www.ralasafe.org/zh
posted @
2010-09-08 21:38 細粒度權限管理 閱讀(4832) |
評論 (1) |
編輯 收藏
-------------------------------------------- 總大綱 ---------------------------------
Ralasafe開源有段時間了，大約有2個月了。根據社區的反饋，我打算圍繞Ralasafe最佳實踐，書寫一系列BLOG。
大體內容有：
1， 登錄控制： 哪些頁面需要登錄后才能訪問，登錄用戶名、密碼驗證，登錄轉向頁面；
2， URL權限控制：哪些頁面訪問需要進行角色權限驗證，怎樣驗證最簡單有效，如何處理驗證失敗情況；
3， 數據級權限管理方案探討：選擇中間件呢還是框架？
4， Ralasafe體系結構： 用戶怎么讀取，用戶有哪些字段，怎樣與應用基礎；
5， 數據級查詢權限管理： 如何給不同的人分配不同的查詢數據權限，返回where條件呢，還是直接返回結果集？
6， 數據級決策權限管理： 如何給不同的人分配不同的數據操作權限，當用戶不具備權限怎么辦？
7， 其他細小的權限控制： 如下拉框顯示內容；按鈕、鏈接是否顯示，圖片是否顯示等。
-------------------------------------------- ------- --------------------------------
數據級權限
數據級權限，無外乎這些類型：
1，數據庫行列級：比如領導查詢數據范圍和普通員工查詢的數據范圍不同，客戶經理能夠查詢客戶聯系方式字段，而其他人不能查看客戶聯系方式字段。
2，字段內容控制：比如普通審查員審查50w以下財務數據，剛入職客戶經理只能將客戶級別調整不能超過3級。
從用戶與數據的交互方向可以分為2大類：
1，從系統獲取數據（查詢）；
2，向系統提交數據之前的判斷。
現實困惑
這種權限與業務緊密耦合，很難找到通用方法。絕大部分系統仍然采用if/else來編程，而且這種邏輯分散到系統的各個環節，甚至還會在系統多處出現重復判斷。
也有不少網友嘗試5表模型等，試圖通過數據模型構造好的ACCESS CONTROL LIST來控制。這種構造ENTRY模式，當數據量小的時候，是可行的，維護工作量也不大。當數據量大的時候，顯然不能奏效。甚至無法運行，維護工作量非常大。
主要表現在：
1，where 語句里面的in(..., ..., ..., ..., ...) 子條件過長，或者使用in (select ... from ACL_ENTRY where ... )性能也是非常低下的；
2，當刪除某用戶的時候，需要在ACL_ENTRY表里面，刪除相關記錄；
3，當刪除某業務數據的時候，也需要在ACL_ENTRY表里面，刪除掉相關記錄；
4，數據量大，ACL_ENTRY數據量承幾何級增長。
也有企業嘗試使用規則引擎來解決。這是非常好的嘗試，提升了系統開發效率、組件復用率。
主要表現在：
1，首先，主動的實踐了一項最佳項目實踐：權限與業務松耦合。
2，通過松耦合，大幅優化了系統結構。
3，進一步提高了組件復用率。
只是，規則引擎畢竟不是專業于權限管理領域，對于復雜需求，或者有些需求實現起來還是很別扭。看起來像if/else的規則表達罷了。
Ralasafe和IBM、Oracle商業產品一樣，都使用規則進行描述。大家的區別在于：誰滿足需求更多、更容易了。
框架or中間件
框架的好處，顯然是有個體系結構，團隊遵循該方式進行開發、組裝即可。提供了一種標準和開發模式。
中間件的好處，顯然是提供了自由，而且易于結合、易于分工。提供了一種服務方式。
我本人希望自由，所以討厭框架，偏愛中間件。但我對選用中間件、框架的選擇標準是非常中肯的，供大家參考。
在系統結構分層的場景，適合使用框架。
在系統功能分離的場景，適合使用中間件。
那么具體到權限管理領域，顯然是功能分離，中間件更合適。這么做，還將不給原有系統、新開發系統的既定框架造成沖突。一個系統里面使用多個框架，是非常痛苦的事情。殊不知在SSH的海洋里面，有多少人將N多時間“Kill”在沙灘上？！
Ralasafe體系結構及應用集成
Ralasafe是中間件，采用服務模型。在業務需要的地方，調用Ralasafe接口，或者將Ralasafe接口向LOG4J那樣wrap到你的aspect里面去。
Ralasafe按照權限的方向，提供2種數據級權限管理服務，也正好對應2個接口：
1，從系統獲取數據， Ralasafe.query( int privilegeId, User user, CustomizedWhere where, int fromIndex, int size );
2，向系統提交數據之前的判斷，Ralasafe.permit( int privilegeId, User user, Object businessData);
Ralasafe還針對web應用，提供了WebRalasafe。
接口非常簡單，在接口層只要告知Ralasafe：當前這個是誰，他/她想干什么。
權限邏輯，全部在Ralasafe圖形化管理界面，點擊鼠標完成配置，并進行在線測試。無需編程。
所以，使用Ralasafe編程工作量非常少。也給不少開發人員造成“不知道怎樣與應用集成”的錯覺。
Ralasafe的用戶怎么來
Ralasafe并不會給你的應用系統“假定”有哪些字段。你的應用系統用戶可以由任意字段，通過XML文件安裝到Ralasafe即可。該XML文件，主要指明：用戶存在那張表（也可以是視圖，這樣可以從多張表關聯讀取數據。比如ralasafe-demo，就關聯到company表讀取了companyLevel和companyName字段）； 哪些字段是唯一字段； 哪些字段是主鍵；各字段對應類型。
然后，在所有權限規則里面，可以讀取這些用戶字段。比如ralasafe-demo應用（下載地址：
http://www.ralasafe.org/zh/download/download.jsp ) 用戶含有companyLevel字段，在定制“總公司”用戶分類的時候，就將該用戶companyLevel字段與總公司級別“1”進行比較。
（下期真正開始探討數據級權限管理實現了）
注：ralasafe團隊博客在javaeye/baidu/blogjava等空間，同步發布。ralasafe官方網站：http://www.ralasafe.org/zh
posted @
2010-09-06 22:58 細粒度權限管理 閱讀(2068) |
評論 (0) |
編輯 收藏