最近在設計權限方面的內容，有些想法，亂彈一下。個人覺得實現權限系統主要是三個方面：
1、授權。主要是授權模型的維護，如資源、角色、用戶、部門的對應關系等。
2、認證。主要是用戶身份的認證，以及取出用戶的權限。
3、校驗權限。當用戶對某一資源進行操作時，將用戶的權限與操作該資源所應有的權限進行比對校驗。
在對這三個方面進行說明前，也想說說對數據權限的看法。什么是數據權限，很簡單，
考慮一種場景 （javaeye里的例子）
看看銷售數據
A銷售員可以看到自己的銷售情況和每一筆具體銷售業務，但是看不到B的
B銷售員可以看到自己的銷售情況和每一筆具體銷售業務，但是看不到A的
分公司銷售經理則可以看到本部門的A和B的銷售情況，但是看不到其他分公司的銷售業務
集團銷售Boss可以看到集團內所有分公司的銷售業務數據
共同點：他們都可以看到“銷售數據”這一模塊
不同點：他們讀取數據的范圍是不一樣的
這個也可以叫做實例級權限控制。有人認為這種權限一般是放在業務里做的, 如果非要用一個固定的模型實現,可以參考 ACL, 不過也是要在業務里寫 ACL 相關代碼的。確實，以前自己也都是放在業務里做的，但一直認為這也應該是權限系統的一部分，通過用戶的權限來構造不同的sql語句。具體通過AOP實現，好象已經有個開源的東西還沒看（lllyq的http://bba96.dev.java.net）。ACL對實例級權限控制感覺效率會有問題，個人看法。
具體來說：
1、授權
?? 具體開發里簡便的授權方式已經成了用戶必提的要求，很明顯，僅僅基于role和權限交互是遠遠不夠的。現實中你必須把角色、用戶、部門三者全部與權限掛鉤。而這三者毫無疑問地就會存在權限繼承的問題。考慮一下，在部門A增加一個用戶，很顯然該用戶會繼承部門A的權限；同時如果在部門A下增加一個部門角色，該角色應不應該也繼承部門A的權限呢？也許需要一個規則接口，具體規則實現看客戶需求。
?? 再說說資源，這里僅討論系統資源不考慮數據資源。考慮一個“業務管理”的模塊，該模塊下面還有“項目管理”，“物品管理”，“采購管理”三個模塊，當對用戶賦予了“業務管理”模塊的查看權限，用戶是否同時對“項目管理”，“物品管理”，“采購管理”具有查看權限呢？這里同樣存在資源權限繼承的問題。客戶的需求是不同的，所以同樣需要一個資源權限繼承的規則接口。
?? 最后說說授權信息的保存。考慮ACL。表設計：資源ID，權限主體ID，權限主體TYPE，資源操作權限。一開始考慮權限主體ID就是UserID，這樣會在認證的時候效率很高，但考慮到部門A下有100個用戶，當對部門A增加一個權限時，實際上會往ACL表里插入100條記錄，這就讓人不能接受了。
2、認證
?? 其實就兩個方面，一是檢查是否存在這個用戶，二是取出用戶的權限。呵呵，這里有些絕對了，取出用戶的權限完全可以放到校驗權限里來做，不必這里一次性全讀出來。用戶的權限放在一個List里，對象可以構造一個，兩個屬性：資源ID和資源操作權限。取出用戶的權限時候要用到上面定義的規則接口來組裝用戶實際的所有權限。
2、校驗權限
?? 這個就比較簡單了，個人傾向于在Action里完成這個工作，需要進行權限檢查的Action實現一個接口，接口里有一個 public boolean hasPermission() ，寫個攔截器攔截即可。這里的關鍵還是通過資源權限繼承的規則接口來校驗用戶操作該資源的權限。
完全是個人亂彈，歡迎拍磚：）

http://www.aygfsteel.com/ronghao 榮浩原創，轉載請注明出處：）