權限、日誌是系統必不可少的的功能，將這些通用的東西抽出來，以AOP方式切入系統中，可以得到非常高的複用率。
在OA中，接觸了ACL（access control list）模型的權限設計。在高校平臺中，採用RBAC（Role Based Access Control）模型的權限設計。
下面是ACL實體模型
ACL的原理非常簡單：每一項資源，都配有一個列表，這個列表記錄的就是哪些用戶可以對這項資源執行CRUD中的那些操作。當系統試圖訪問這項資源時，會首先檢查這個列表中是否有關於當前用戶的訪問權限，從而確定當前用戶可否執行相應的操作。
總得來說，ACL是一種面向資源的訪問控制模型，它的機制是圍繞“資源”展開的。
ACL核心在於用戶可以直接和權限掛鉤，簡單的同時它的缺點也是很明顯的，由於需要維護大量的訪問權限列表，所以在性能上有明顯的不足，因而便有了對ACL設計的改進，ACL不僅記錄用戶—資源—操作表，還記錄角色—資源—操作表。
通過ACL（訪問控制列表）把Role、User、Module、Permission、status（允許/禁止）關聯起來。用於記錄用戶或者角色對資源擁有的權限。
下面是RBAC物理模型
這樣設計的核心是把用戶按角色進行歸類，通過用戶的角色來確定用戶能否針對某項資源進行某項操作。
相對於ACL最大的優勢就是它簡化了用戶與權限的管理，通過對用戶進行分類，使得角色與權限關聯起來，而用戶與權限變成了間接關聯，從而解耦。
但是它也有自身的缺點，那就是由於權限是以角色爲載體分配的，如果某一角色下的個別用戶需要進行特別的權限定製，如同加入一些其他角色的小部分權限或去除當前角色的一些權限時，RBAC就無能爲力了，只能再重新創建角色，因爲RBAC對權限的分配是角色爲單位的。
爲了彌補這種設計不足，通過增加security_user_permission來滿到個性化需求。
兩種改進模型的比較
ACL由於用戶和權限直接掛鉤，可以滿足個性化，即爲系統中的用戶單獨分配權限；RBAC由於角色和權限直接掛鉤，使得權限可以被複用，把用戶按角色進行歸類。
兩種改進模型，都是爲了彌補自身不足而演變而來的，即ACL需要解決複用性問題，RBAC需要解決個性化問題。其實，兩種改進模型都駛向了一個平衡點，雖然RBAC改進模型中的表個數多，但是原理還是一樣的，只是爲了降低數據的冗餘度。
擴展模型
這兩個只是基本的ACL和RBAC模型，在它們基礎上可以進行擴展，比如可以在RBAC模型基礎上增加用戶組。用戶組在模型中相當於security_organization組織機構。
RBAC模型的更多擴展模型，可以參考權限管理之基於RBAC的擴展設計方案
除兩上述兩種主要的模型之外，還有包括：基於屬性的訪問控制ABAC和基於策略的訪問控制PBAC等等，因爲應用不是很廣泛，就不做介紹了。
