Terry.Li-彬

          虛其心,可解天下之問;專其心,可治天下之學;靜其心,可悟天下之理;恒其心,可成天下之業。

            BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
            143 隨筆 :: 344 文章 :: 130 評論 :: 0 Trackbacks

          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中間件

          框架的好處,顯然是有個體系結構,團隊遵循該方式進行開發、組裝即可。提供了一種標準和開發模式。

          中間件的好處,顯然是提供了自由,而且易于結合、易于分工。提供了一種服務方式。

          ?

          我本人希望自由,所以討厭框架,偏愛中間件。但我對選用中間件、框架的選擇標準是非常中肯的,供大家參考。

          Metadmin 寫道
          在系統結構分層的場景,適合使用框架。
          在系統功能分離的場景,適合使用中間件。
          ?那么具體到權限管理領域,顯然是功能分離,中間件更合適。這么做,還將不給原有系統、新開發系統的既定框架造成沖突。一個系統里面使用多個框架,是非常痛苦的事情。殊不知在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 on 2010-09-11 11:12 禮物 閱讀(1761) 評論(0)  編輯  收藏

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

          網站導航:
           
          主站蜘蛛池模板: 萨嘎县| 武定县| 平武县| 林甸县| 涞水县| 桂林市| 门源| 邳州市| 平邑县| 昌都县| 准格尔旗| 永安市| 农安县| 长宁区| 双辽市| 阳城县| 潞城市| 定边县| 宾川县| 衡山县| 通榆县| 武清区| 茂名市| 福鼎市| 房产| 金溪县| 子洲县| 安化县| 巩留县| 常州市| 岳阳县| 花莲市| 牡丹江市| 府谷县| 嵊泗县| 霞浦县| 嘉鱼县| 潢川县| 花莲县| 云龙县| 宁乡县|