-------------------------------------------- 總大綱 ---------------------------------

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，我們需要針對不同的人、不同的情況做不同的權限邏輯。比如：

 

在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演示員工查詢，不是訂單查詢）

 

OK，就這么簡單。需要編程的工作量非常非常少，達到了極致。世界從此清凈了。

 

（WebRalasafe.query方法接受req<HttpRequest>參數，從這里讀取User。Ralasafe.query方法則直接傳入User，可供非web類應用調用） 

系統結構

Ralasafe由權限引擎和管理界面組成。權限引擎解析權限策略；管理界面生成、維護權限策略。如圖示：

 

 

注：ralasafe團隊博客在javaeye/baidu/blogjava等空間，同步發布。ralasafe官方網站：http://www.ralasafe.org/zh

 

 

 

-------------------------------------------- 總大綱 ---------------------------------
Ralasafe開源有段時間了，大約有2個月了。根據社區的反饋，我打算圍繞Ralasafe最佳實踐，書寫一系列BLOG。

大體內容有：
1， 登錄控制： 哪些頁面需要登錄后才能訪問，登錄用戶名、密碼驗證，登錄轉向頁面；
2， URL權限控制：哪些頁面訪問需要進行角色權限驗證，怎樣驗證最簡單有效，如何處理驗證失敗情況；
3， 數據級權限管理方案探討：選擇中間件呢還是框架？
4， Ralasafe體系結構： 用戶怎么讀取，用戶有哪些字段，怎樣與應用基礎；
5， 數據級查詢權限管理： 如何給不同的人分配不同的查詢數據權限，返回where條件呢，還是直接返回結果集？
6， 數據級決策權限管理： 如何給不同的人分配不同的數據操作權限，當用戶不具備權限怎么辦？
7， 其他細小的權限控制： 如下拉框顯示內容；按鈕、鏈接是否顯示，圖片是否顯示等。
-------------------------------------------- ------- --------------------------------

今天說的URL權限控制，內容主要有：URL權限控制，當用戶訪問某URL時，進行角色權限驗證。如果有相應權限，則允許其正常訪問；否則，轉到拒絕頁面。
我們依然通過一個Filter來實現，這樣就無需在代碼中增加權限判斷，也無需套用任何框架。對于整個權限管理系統來說，本節內容也非常簡單。

理論分析

當軟件實施人員進行系統實施的時候，會將一些訪問菜單定義為權限。然后定義角色，讓角色擁有權限。然后再將權限賦給用戶。
所以，當用戶請求某個URL的時候，要不該URL需要權限驗證，要不就是不需要權限驗證。
檢驗標準就是：看權限表里面有沒有該URL。檢驗的時候，唯一需要注意的是：URL參數，比如employeeManage?op=add。

數據庫模型

權限表：id<int>,name<varchar>,url<varchar>,description<varchar>   | pk(id)
角色表：id<int>,name<varchar>,description<varchar>                        | pk(id)
角色-權限關系表：roleId<int>,privilegeId<int>                                       | pk(roleId,privilegeId)
用戶-角色關系表：userId<int>(根據你系統的情況，也可能是varchar等),roleId<int> | pk(userId,roleId)

Ralasafe方案

Ralasafe權限管理中間件(下載地址)，既可以管理和控制功能級權限，也可以管理和控制數據級權限。開發者還可以根據需求，只選擇功能級控制，或者只選擇數據級控制。

當安裝好用戶元數據的時候，Ralasafe自動創建所有權限表。相關權限數據，都由Ralasafe界面進行管理（即錄入）。

Ralasafe的管理界面，在功能權限方面可以做到：
1，管理權限界面；
2，管理角色界面，并給角色賦權限；
3，給用戶分配角色界面。這里還需要注意：不同用戶管理可以給不同范圍的用戶分配角色。比如：總公司的管理員可以給所有人分配角色；分公司管理員可以給本分公司及下屬子公司用戶分配角色。

Ralasafe將最后一點視為數據級權限。詳見：http://www.ralasafe.org/zh/guide/reference/safe.html#ralasafe 和http://www.ralasafe.org/jforum/posts/list/11.page


將org.ralasafe.webFilter.UrlAclFilter配置到web.xml即可，而且配置工作量極其少。

 
該Filter具有這些功能：
1，在用戶具有權限的時候，正常訪問；
2，在用戶不具有權限的時候，轉到拒絕頁面；
3，如果用戶沒用登錄，轉到登錄頁面，讓用戶先登錄。

其他

這里我簡單說說spring security。
spring security在控制功能權限的時候，還會幫助開發人員控制Dao/Service等組件。我個人認為這種控制是多余的。
因為，功能權限控制應該站在最終用戶角度進行考慮。Dao/Service等編程開發級的組件，并不是最終用戶關心的事情。所以無需進行功能權限控制。
另外，大家在使用spring security，我建議將功能級權限控制放在數據庫里面，而不是annotation到java code里面。因為annotation到java code里面，最終用戶就不能控制了。

注：ralasafe團隊博客在javaeye/baidu/blogjava等空間，同步發布。ralasafe官方網站：http://www.ralasafe.org/zh


原文：http://www.ralasafe.org/jforum/posts/list/66.page
Ralasafe自從2010年6月23日開源以來，得到廣大網友的支持和鼓勵，在此非常感謝。Ralasafe團隊也通過網站、論壇、博客、Email、QQ等各種方式與社區互動，形成交流。根據這段時間的社區維護情況，我們制定如下社區維護原則。

我們歡迎這樣的人，樂于回答他們的問題：
1，說話友好，平等切磋的人；
2，勤于學習，而不論技術高低，不論新手老手。即便你是新手，但只要你肯予學習，不斷交流，我們樂于提供幫助；
3，帶有個人偏見，但言之有物的人。

我們不歡迎這樣的人，也不想回答他們的問題：
1，出言不遜，帶有蔑視或者侮辱性語言的人；
2，懶惰的人，尤其是沒有看文檔，沒有對Ralasafe-demo進行揣摩，沒有進行基本學習的人；（文檔沒有看懂的人例外，確實我們可能撰寫方式有問題，個人理解力有差距等）
3，帶有個人偏見，且言之無物的人。

Ralasafe團隊將繼續保持開源，并致力于社區維護工作。對于新手，只要樂于學習，我們甚至會對學習難點，免費提供QQ遠程協助。      摘要: Ralasafe是基于MIT協議開源的，數據級權限管理中間件。開源有2個月了。根據社區的反饋，我圍繞Ralasafe最佳實踐，書寫一系列BLOG。今天說的登錄控制，內容主要有：哪些頁面需要登錄控制、登錄驗證邏輯、登錄后頁面轉向哪里，以及權限菜單等問題。雖然本系列講解權限管理，尤其是數據級權限管理。但嚴格意義來說，登錄控制，并不屬于權限管理內容。它屬于用戶身份認證內容。權限基本都與用戶相關，用戶首先就涉及到用戶名密碼驗證。所以我們從這里開始說起。  閱讀全文      摘要: 很多系統對于黑客不堪一擊。請看這樣的示例：
1. 前臺展現客戶能查看的客戶數據，而且用戶能刪除的客戶數據，就是前臺展現出來的數據；
2. 當用戶選擇某個用戶，點擊刪除按鈕，后臺執行刪除操作。
比如，請求后臺刪除的url是：http://www.test.com/crm/customer.do?id=3
假設，id=13的客戶在前臺不顯示（因為當前用戶沒有對該客戶數據有刪除權限），但用戶輸入http://www.test.com/crm/customer.do?id=13 顯然id=13的客戶將被刪除掉。

有開發者建議采用id值不要使用自增長型，而改用其他型，比如hashcode等。這也不大合適，可以使用爬蟲輕松地將漏洞爬出來。

顯然，僅僅通過界面層次控制數據級權限是不夠的。  閱讀全文 今天是夏至，白天是一年中最長的。好好努力。此文激烈自己和同樣在努力的朋友們。      摘要: 上一章講解通過設計器，設計出數據查詢，并在線測試。本章講解如何快速定制數據查詢，如果將業務代碼中的if else邏輯判斷去掉，如何將這種細粒度的權限集成到業務系統。  閱讀全文