對許可權系統設計的再思考
什麼是許可權系統，許可權系統究竟在整個系統中起到什麼作用，或者說許可權系統必須提供哪些功能？
談談個人的看法，我認為授權和驗證是乙個許可權系統最基本的功能，而乙個更完善的許可權系統會增加上如何驗證和驗證後如何處理這兩種功能。
對於乙個許可權系統的基本元素，我覺得只有兩個：principal(許可權主體)，許可權。使用者，使用者組，角色等都可以抽象為許可權主體這個概念；而許可權則是資源 +操作的抽象。許可權可分為兩種，一種純粹就是資源，沒有操作，也可以認為是預設操作；另外一種就是帶操作的資源。授權本身沒有什麼說的，賦予許可權主體許可權；驗證簡單的說就是傳入許可權主體和當前操作需要的許可權，然後驗證返回說可以操作或是不可以操作yes/no。同時要注意的是驗證的時候需要乙個類（介面）來返回使用者當前所擁有的許可權，然後與當前操作需要的許可權進行比對，最後返回比對結果。
以acegi為例，下面分開來說明：
首先，acegi是沒有授權功能的，它簡單把許可權主體與資源配置在了xml裡，當然這也帶來了可擴充套件性，可以看乙個配置：
/index.jsp=role_anonymous,role_user
/hello.htm=role_anonymous,role_user
/logoff.jsp=role_anonymous,role_user
/switchuser.jsp=role_supervisor
/j_acegi_switch_user=role_supervisor
/acegilogin.jsp*=role_anonymous,role_user
/**=role_user
/index.jsp，/hello.htm這些url都是資源，因為它預設的操作就是訪問，所以訪問特定url就成了乙個許可權，role_anonymous,role_user無疑就是許可權主體。
acegi對方法訪問許可權的配置也是和上面一樣的。
然後，看看acegi的驗證，其實它的驗證就是乙個個的voter，當你訪問乙個方法時，由它獲得當前使用者和需要的許可權（就是該方法），然後返回yes/no。
ok，這就是乙個完整的許可權系統了。當然acegi如果僅僅提供上面兩個基本功能，它是不會向現在這樣成功的，它最大的亮點就是提供了如何驗證和驗證後如何處理這兩種功能。對url它提供了filter，方法也一樣提供了interceptor，這就是如何驗證，和我們在action裡驗證沒有任何區別，只是換了一種方式而已。然後它驗證後的處理方式：yes就繼續往下執行,no就丟擲異常最後再處理這個異常。我們在執行每個action前同樣也可以做到這一點。
這裡著重要提到的是資料許可權。比如說a只能對部門a下的資料有檢視許可權，b可以對部門a的資料有修改許可權和對部門b的資料的檢視許可權。
看起來這個需求是比較麻煩的，但是我們可以按上面說的拆分以下：
資源1：部門a下的資料 ；資源2：部門b下的資料
操作1：檢視； 操作2：修改
產生四種許可權：
許可權1：資源1+操作1 ；許可權2：資源1+操作2；許可權3：資源2+操作1；許可權4：資源2+操作2
許可權主體a擁有許可權：1 ； 許可權主體b擁有許可權：2，3
這樣就非常清晰了。
總結：我始終認為擁有授權和驗證功能就完成了乙個完整的許可權系統。至於如何去校驗許可權，不管你是filter還是aop那是具體實現時的細節，採取的不同策略。而驗證後的處理則是和不同策略相對應的。在你考慮設計乙個許可權系統時首先考慮的是如何實現授權和驗證，而不是一開始就考慮我是採取filter，還是 aop，還是動態改變sql。
資料許可權設計思考
目前有關使用者許可權採用的比較多的都是基於rbac模型，即通過對角色許可權的定義完成對使用者許可權的限制。有關功能許可權部分想必都比較清楚，就是將系統的功能模組劃分清楚，並賦予不同角色的訪問許可權，這樣在使用者訪問某個功能模組之前進行許可權校驗即可。但是有關資料許可權部分卻一直比較模糊。在如下這篇文...
許可權系統設計
許可權系統 2 operation 許可權控制可以看作乙個filter模式的應用,這也符合aop思想的應用條件。在乙個簡化的圖象中，我們只需要將乙個判別函式 isallowed subject,operation,resource 插入到所有安全敏感的函式呼叫之前就可以了。雖然概念上很完美，具體實現...
系統設計的幾點思考
前言又有好一陣子沒有更新文章了，今天聊聊系統設計的幾點思考。對於我們來說，始終會獨自設計，研發，迭代系統。為系統的演進，整個生命週期負責。而負責的系統到底處於什麼狀態？是否健康？是否出現問題？這些都是需要考慮的問題。開關對關鍵流程，進行開關設定。例如 交易開關，資金池開關。對於金融系統而言，特別是出...