從權限系統談起，我想只要工作了幾年的一般都會對這個有接觸，特別是做項目的，^_^，可能很多都自己做過權限系統，一般來說權限系統主要需要做到以下幾種情況的控制：
1、身份認證。主要是控制訪問系統的用戶的身份，以確定用戶是否有足夠的身份進行操作。
2、系統菜單、按鈕的控制。需要根據權限顯示相應的菜單和按鈕，這種主要是控制顯示級別的以及用戶正常訪問系統操作。
3、系統操作的控制。需要根據權限來控制用戶是否有權進行某操作，這個主要是控制避免用戶通過不正常的方式來訪問系統的操作。(如通過直接敲url等)
4、系統資源級別的控制。這個就比較復雜些，需要控制用戶可以看到哪些資源，而資源通常又分成很多種操作級別的資源，如對資源進行管理時看到的就是用戶擁有管理權限的資源，如只是對資源進行訪問時看到的則為用戶擁有訪問權限的資源，更為復雜的情況是資源要求支持權限繼承的情況，就是對父資源進行授權后，相應的子資源也擁有同樣的權限。
對應以上的需求，在權限系統中采用的最多的兩種實現方式是RBAC和ACL，無論是RBAC還是ACL，對應以上的需求都是可以實現的，只是實現起來的復雜度不同，還有就是用戶操作起來的易用性不同。
上面的需求講的基本是非常實際的需求，歸納性的和更為合理的描述大家可以看看acegi reference guide里面的描述。
實現權限系統來講，個人覺得主要是兩個方面：
1、授權。主要是授權模型的維護，如資源權限、角色、用戶的對應關系等。
2、校驗權限。校驗權限根據需求主要有校驗對于資源進行操作的權限，用戶身份的校驗，還有一種就是資源操作權限的校驗。
在這里主要以RBAC來說說，RBAC規范中RBAC主要分為四個級別，分別為RBAC 0、RBAC 1、RBAC 2和RBAC 3。
RBAC 0又稱為Core RBAC，實現的為基本的權限模型，如用戶與角色、角色與資源權限、資源權限與資源、資源操作的關系的維護，同時提供基于角色的資源操作權限的校驗，類似的偽代碼：role.doPrivilege(Principle,Resource,Operation)，相對來講RBAC 0是比較容易實現的，在RBAC 0中進行權限校驗時的關鍵就是根據用戶的角色來檢驗用戶是否有操作的權限。
RBAC 1中提出了角色權限繼承的實現，雖然看起來只是增加了一個角色權限繼承，但在實現起來系統的復雜度則是大大的增加了，在RBAC 0中校驗一個用戶是否擁有對某資源的操作權限時只需校驗用戶的角色即可，現在則變成了除了需要校驗用戶的角色權限外，在用戶角色權限不足的情況下還需校驗其父角色的權限，這個在系統效率方面必然會造成影響，但其實對于資源操作來講還算是比較好處理的，因為畢竟可以通過緩存等等技術來解決，但對于系統資源級別的權限控制來說則變得更為復雜多了，因為在進行系統資源級別權限控制時通常需要分頁的獲取有權限的資源，而通常分頁我們需要依賴數據庫進行實現，也就是說并不是直接獲取所有的資源然后再進行分頁，這樣在進行大量資源訪問的時候是會出現問題的，這個時候問題就很明顯的出現了，因為通過RBAC模型的話我們只能做到先獲取出所有的資源，然后進行權限過濾，而且這個時候在進行權限過濾的時候會比較的麻煩，需要去校驗用戶的角色以及父角色，不斷的判斷，這個時候其實ACL的優點倒是體現了，因為按照ACL的話是可以直接獲取出用戶有權限訪問的資源的，這樣的話分頁其實同樣不是問題了，但ACL的麻煩同樣也在繼承這個地方，這樣的話授權模型會非常復雜，因為在授權的時候需要維護好ACL這張表，把用戶所在的角色的父角色的權限也要考慮進來，同時維護ACL的表，而且在角色變動的時候也要去維護ACL表，可以看出這其實也是很復雜的，就舉一個簡單的例子，如果一個父角色下有幾十個子角色，那么在父角色對于資源訪問的權限變動時那么所有的子角色的資源都需變動，這個時候ACL表就得變動。
RBAC 2則更為復雜，RBAC 2中提出了角色權限互斥的問題，其實在角色權限繼承的基礎上我們就會考慮到這個問題，既然角色權限繼承那么很容易出現權限互斥的問題，RBAC 2模型就是為了解決這個。
RBAC 3則沒什么說的，因為它就是RBAC 1和RBAC 2都實現。
上面講的是沒什么章理去了，呵呵，不好意思，其實不管采用什么模型，對用戶而言重要的是授權的簡易性和校驗權限的高效性，當然，還有就是權限控制的有效性，而RBAC模型和ACL模型都是為了這個目標而去，其實通過上面的大概介紹可以看出，RBAC模型在授權模型上會比較的簡單和清晰，而ACL模型則在校驗權限上比較的簡單和高效，所以說兩者各有優缺點，如果有什么能兩者都實現的就好了，因為兩者的優點其實也是非常的映射出兩者的缺點。
其實在沒有權限繼承的時候權限系統的時候是比較容易的，但為了提高系統管理的方便，權限繼承也是不可避免的會出現，這個時候就要考慮在什么時候去完成權限繼承，是授權時完成還是校驗權限時完成，授權時完成就會造成授權模型的復雜，但可以保證校驗權限時的簡便，校驗權限時完成則可保證授權時的簡單，但造成校驗權限時的低效。
最后針對以上需求來說，還是認為1、2、3點需求是比較容易做到的，即使在權限繼承的情況下也不是那么的難，但對于需求4來說目前仍然沒有想出很好的辦法，目前的做法只能是ACL，也就是增加授權時的復雜，但保證校驗權限時的簡單。
這篇作為漫談權限系統的開篇，講的可能有些混亂了，在第二篇中將重點來描述RBAC和ACL分別實現需求1、2、3的方法。