網站安全認證系統的設計變遷
網站在從小到大的發展歷程中，安全認證系統是如何變遷的？
下面我們從其發展的幾個階段來分下：
階段1：
起步，注冊用戶很少，兩臺服務器，一臺應用服務器，一臺數據庫服務器。
用戶登陸后在應用服務器記錄用戶 session （通常就是 tomcat session）。
當用戶請求受保護資源（網頁）時，首先請求經過一個安全認證過濾器進行攔截，并調用認證模塊進行檢測用戶是否登陸。
認證模塊的檢測方式很簡單，就是判斷用戶的登陸 session 是否保存在服務器內存中，過期的 session 會自動清除。
其架構如下：（圖1）
階段2：
隨著用戶的增長，一臺服務器已經不足以支撐時，我們開始擴展服務器，加入從1臺應用服務器擴展到N（N<10）臺。
用戶登陸時，通過前面 apache 的負載均衡可能隨機平均訪問任何一臺 Tomcat。
這時產生了一個問題，原來保存在一臺應用服務器內存中的 session 數據，現在分散在不同服務器上。
這時我們沒法像上面簡單的在內存中檢測 session 了，為了不改動原先的程序方案，我們開始考慮 session 復制。
還好 Tomcat 這樣的應用服務器為 session 復制提供了直接支持，只需改動配置即可，而不用變動程序。
其架構如下：（圖2）
階段3：
用戶進一步增長，應用服務器集群進一步增長，當超過10臺后，session 復制開始顯示出明顯的低效和性能問題。
而且單臺服務器維護的 session 數據量也達到了瓶頸，我們考慮用專用的緩存服務器來取代 session 復制方案。
memcache 或 redis 這樣的緩存產品被引入作為集中式的 session 存儲區域，應用服務器分離了 session 后變成了
無狀態的服務，不再受到 session 復制所需的內存和網絡限制，可以進一步擴展數量。
其架構如下：（圖3）
階段4：
網站越來越受歡迎，用戶越來越多，業務越做越廣，于是開始對業務進行分類。
應用部署上也開始按業務分類劃分了不同的業務服務器集群。
例如原本網站域名為 www.xxx.com，按業務劃分集群后，我們采用子域名區分業務集群，例如 biz1.xxx.com, biz2.xxx.com。
那么整個網站應用被劃分成了各個不同的子業務系統，而所有子業務系統都需要認證授權，如何來做統一認證呢？
這時，我們將安全認證服務也獨立為一個子系統，部署在 auth.xxx.com 域名下。
如果繼續采用集中式的 session 管理，那么對每個業務子系統受保護資源的訪問都需要驗證 session 是否存在。
業務子系統調用認證子系統檢測用戶認證信息，這樣認證子系統的訪問頻次將很高，幾乎等于全部業務子系統的 PV 總和。
這時，認證系統的可用性將變得非常重要。
其架構如下：（圖4）
階段5：
為了降低業務子系統對認證系統的高可用性依賴，我們決定放棄服務端的集中式 session 管理，而采用客戶端 Cookie 方式。
當用戶訪問業務子系統的受保護資源時，若未登陸，則跳轉到認證系統（auth.xxx.com）去進行登陸。
登陸后認證系統寫一個加密 cookie 到用戶的瀏覽器，并跳轉到用戶訪問的業務系統頁面，瀏覽器自動攜帶這個加密 cookie 發送給業務子系統。
業務子系統解密該 cookie 提取來自認證系統的驗證和授權信息，并進行后續的業務處理。
這里，加密的 cookie 里存儲了來自認證系統授權的訪問憑證（ticket），業務子系統正確解密 cookie 后獲取訪問憑證，即可認為用戶已經過認證系統授權訪問。
其架構如下：（圖5）
這個架構機制解決了業務子系統高度依賴認證系統可用性的問題，降低了認證系統的訪問壓力，但也有新的問題。
這里比較明顯的是，認證系統和業務子系統的互信是依賴于約定的共享密鑰，密鑰如何管理成為一個新的問題？
認證系統加密 cookie 使用的密鑰需要被業務子系統用來解密，如果密鑰分散配置到各個業務子系統中則造成密鑰分散容易泄露（降低安全性）。
更重要的是一旦認證系統需要變更密鑰則連帶影響所有業務子系統，而且變更過程很難保持同步更新，導致業務子系統在更新密鑰的過程中不可用的問題。
為了提升這個架構的可用性，考慮在認證系統中包含一個密鑰管理子系統，可以采用 Lease 機制來解決密鑰的分布式同步和一致性問題。
階段6：
網站越做越大，后來開始并購了一些其他網站，比如 www.yyy.com。
這時我們面臨一個新問題了，需要整合多個域名下的用戶統一認證。前述的 cookie 方案碰到了跨域問題。
這里假設我們首先合并了多個站點的用戶數據庫，這里只需要解決基于 cookie 跨域的認證問題。
這里提兩種方式可選：
1. 同步登錄
用戶登錄xxx.com同時登錄yyy.com，具體做法是在 xxx.com 進行認證成功返回后攜帶相關的認證憑證。
然后調用 yyy.com 的認證接口傳遞認證憑證，yyy.com 驗證憑證后設置來自 yyy.com 的 cookie。
這樣用戶在任一站點訪問受保護資源時，因為都包含了相應的 cookie 所以可以正常訪問。
流程如下：（圖6）
2. 延遲登錄
與同步方式不同的是，用戶登錄了xxx.com時并不會立刻去請求 yyy.com 設置 cookie。
而是等到用戶真正訪問 yyy.com 受保護資源時，由 yyy.com 請求統一認證中心認證后再跳轉回 yyy.com 設置 cookie。
流程如下：（圖7）
兩種方式僅僅是策略上的不同，從合理性上看后一種方式感覺更合理，因為畢竟用戶訪問了 xxx.com不代表一定要去 yyy.com。
轉自：http://blog.csdn.net/mindfloating/article/details/7905093