java權限系統的技術演變曆史

      java的權限管控在平台化和企業化得過程中大體經過了如下的階段：

       權限系統功能上分為兩部分：認證+鑒權。

      1. 标準jaas時代。在最早的時候，j2ee時代，java提出了标準的鑒權服務，即jaas。tomcat，jboss，weblogic等容器都支援這一标準，隻是配置略有不同。通過簡單的容器配置和檔案配置，通過一個ldap（可以用資料庫，隻是效率不高），就可以提供一個極為高效便捷的權限管控服務。這個模式不僅支援頁面管控，還支援ejb服務接口管控。非常高效。其鑒權因為ldap的數倍于資料庫的查詢效率而無需任何緩存，速度很快。業務系統的代碼，沒有任何入侵，當你僅僅隻是想有有個簡單和通用的鑒權模型，且各個系統互相隔離，甚至沒有sso，獨立部署，并且并發量大，這種模式是最完美的。但是問題來了，第一，當應用的數量無限度增長，這種散落在各個容器的配置給容災和修改，都帶來了極大的挑戰。其二，ldap的可讀化差，修改和編輯極為不便，當需求一旦個性化超過了樹能夠表達的模型便很難在适應，也就是一旦超過過經典權限模型的範疇，便很難适應。其三，當ldap的資料爆炸式增長，且呈現28規律時（資料冷熱不均），或者如果需要頻繁的寫ldap，查詢效率會陡然下降。是以這種模式今天已經不是很流行了。但是在大量使用标準中間件産品的公司，包括銀行都還大量部署這種模式的權限管控。實際上我們看到後來的springsecurity也是支援了這個标準的，隻是不是基于容器，而是基于spring的配置。

      2.統一登入（sso）+接口鑒權時代。既然分散的登入認證不能解決問題，那麼很自然的就是統一登入，sso，單點登入。權限系統通過引導将需要鑒權的系統引導到統一的登入中心，進行登入。那麼問題就來了，這就需要權限系統能夠保證登入風暴的壓力。此外超過了經典權限模型的資料類型，必須要放棄ldap轉回到資料庫，那麼因為放棄了标準的jaas鑒權，那麼權限系統就需要提供接口鑒權服務，或者依賴統一的分布式session，将權限在登入時注入進去。是以在去除jaas方式的ldap後，因為失去了ldap天然的高效檢索能力（耗時約為資料庫的百分之一），在經典的rbsc（基于角色的鑒權模型）下，如何最終将資料庫格式化、規正化的權限資料，聚合和散列到：人-權限，就尤為重要。采取nosql或者各種這類扁平化的模型，使得鑒權服務能夠一步拿到最終權限資料，是一種通俗的做法。但是，當無法解決資料散列和聚合問題的時候，如果存在登入風暴和海量鑒權訴求時，采用接口鑒權将有災難性的後果。

    3.統一登入（分布式session）+接口鑒權時代。在回到分布式session：基于sso的系統，因為沒有共享session，是以系統間的跳轉，都需要一次接口鑒權，而分布式session很好的共享和緩存了使用者的權限資訊。這是一個雙刃劍，這是以犧牲使用者權限的實時性，作為替代。同時，一旦分布式session出現技術問題，如果垮掉，後果不堪設想。此外分布式session比較适合經典的權限模型，一旦超出了這個領域，實際上就沒法再預先注入是以資料，必須要提供鑒權接口。即：統一登入+接口鑒權。

   此外，java标準鑒權模型沒能很好的解決資料權限的問題，是以權限系統長期以來，很難界定資料權限的适用範圍和如何建設一個通用的資料權限模型，是以實際過程中，我們看到所謂的通用的權限系統，都沒有解決這部分問題，而具體的各個實際遇到該問題的系統的解決方案，更是千差萬别。此外，很多系統都沒能解決一個那就是如何通過權限反向查詢人的問題，因為這個會帶來更大的性能消耗。

    建設一個僅僅隻是滿足鑒權目的權限系統并不複雜，複雜在于權限系統是企業管理的一部分，甚至是很關鍵的一部分，随着企業管理和營運要求的不同，權限系統所面臨不僅僅是技術問題，而是如何管理的問題，不斷演化的企業人員組織架構和業務條線，都對權限管理提出了新的訴求和差異化的要求，而且不斷的有業務模型和超過經典權限模型的資料進入權限系統的範疇，都給權限系統的設計者們增添額不少的挑戰。無論如何建設一個使用者量少的權限系統是一個比較容易的事情且不用太擔心性能的問題，如果建設一個滿足十萬級、百萬級使用者的權限系統，是一個極富挑戰的工作。