什么是權(quán)限系統(tǒng)，權(quán)限系統(tǒng)究竟在整個系統(tǒng)中起到什么作用，或者說權(quán)限系統(tǒng)必須提供哪些功能？
談?wù)剛€人的看法，我認為授權(quán)和驗證是一個權(quán)限系統(tǒng)最基本的功能，而一個更完善的權(quán)限系統(tǒng)會增加上如何驗證和驗證后如何處理這兩種功能。
對于一個權(quán)限系統(tǒng)的基本元素，我覺得只有兩個：Principal(權(quán)限主體)，權(quán)限。用戶，用戶組，角色等都可以抽象為權(quán)限主體這個概念；而權(quán)限則是資源+操作的抽象。權(quán)限可分為兩種，一種純粹就是資源，沒有操作，也可以認為是默認操作；另外一種就是帶操作的資源。授權(quán)本身沒有什么說的，賦予權(quán)限主體權(quán)限；驗證簡單的說就是傳入權(quán)限主體和當(dāng)前操作需要的權(quán)限，然后驗證返回說可以操作或是不可以操作yes/no。同時要注意的是驗證的時候需要一個類（接口）來返回用戶當(dāng)前所擁有的權(quán)限，然后與當(dāng)前操作需要的權(quán)限進行比對，最后返回比對結(jié)果。
以acegi為例，下面分開來說明：
首先，acegi是沒有授權(quán)功能的，它簡單把權(quán)限主體與資源配置在了xml里，當(dāng)然這也帶來了可擴展性，可以看一個配置：

/index.jsp，/hello.htm這些URL都是資源，因為它默認的操作就是訪問，所以訪問特定URL就成了一個權(quán)限，ROLE_ANONYMOUS,ROLE_USER無疑就是權(quán)限主體。
Acegi對方法訪問權(quán)限的配置也是和上面一樣的。
然后，看看acegi的驗證，其實它的驗證就是一個個的Voter，當(dāng)你訪問一個方法時，由它獲得當(dāng)前用戶和需要的權(quán)限（就是該方法），然后返回yes/no。
OK，這就是一個完整的權(quán)限系統(tǒng)了。當(dāng)然acegi如果僅僅提供上面兩個基本功能，它是不會向現(xiàn)在這樣成功的，它最大的亮點就是提供了如何驗證和驗證后如何處理這兩種功能。對url它提供了filter，方法也一樣提供了Interceptor，這就是如何驗證，和我們在action里驗證沒有任何區(qū)別，只是換了一種方式而已。然后它驗證后的處理方式：yes就繼續(xù)往下執(zhí)行,no就拋出異常最后再處理這個異常。我們在執(zhí)行每個action前同樣也可以做到這一點。
這里著重要提到的是數(shù)據(jù)權(quán)限。比如說A只能對部門A下的數(shù)據(jù)有查看權(quán)限，B可以對部門A的數(shù)據(jù)有修改權(quán)限和對部門B的數(shù)據(jù)的查看權(quán)限。
看起來這個需求是比較麻煩的，但是我們可以按上面說的拆分以下：
資源1：部門A下的數(shù)據(jù)? ；資源2：部門B下的數(shù)據(jù)
操作1：查看；??? 操作2：修改
產(chǎn)生四種權(quán)限：
權(quán)限1：資源1+操作1 ；權(quán)限2：資源1+操作2；權(quán)限3：資源2+操作1；權(quán)限4：資源2+操作2
權(quán)限主體A擁有權(quán)限：1 ； 權(quán)限主體B擁有權(quán)限：2，3
這樣就非常清晰了。
總結(jié)：我始終認為擁有授權(quán)和驗證功能就完成了一個完整的權(quán)限系統(tǒng)。至于如何去校驗權(quán)限，不管你是filter還是aop那是具體實現(xiàn)時的細節(jié)，采取的不同策略。而驗證后的處理則是和不同策略相對應(yīng)的。在你考慮設(shè)計一個權(quán)限系統(tǒng)時首先考慮的是如何實現(xiàn)授權(quán)和驗證，而不是一開始就考慮我是采取filter，還是aop，還是動態(tài)改變sql。
謝謝wolfsquare，它的blog相關(guān)

http://www.aygfsteel.com/ronghao 榮浩原創(chuàng)，轉(zhuǎn)載請注明出處：）