標籤：一個 名稱 ref tps 修改 filter 列表 擴充 方案
4 當前方案的安全域限性當前這個WEB-SSO的方案是一個比較簡單的雛形，主要是用來示範SSO的概念和說明SSO技術的實現方式。有很多方面還需要完善，其中安全性是非常重要的一個方面。我們說過，採用SSO技術的主要目的之一就是加強安全性，降低安全風險。因為採用了SSO，在網路上傳遞密碼的次數減少，風險降低是顯然的，但是當前的方案卻有其他的安全風險。由於cookie是一個使用者登入的唯一憑據，對cookie的保護措施是系統安全的重要環節：
- cookie的長度和複雜度
在本方案中，cookie是有一個固定的字串（我的姓名）加上當前的時間戳記。這樣的cookie很容易被偽造和猜測。懷有惡意的使用者如果猜測到合法的cookie就可以被當作已經登入的使用者，任意存取權限範圍內的資源
- cookie的效驗和保護
在本方案中，雖然密碼只要傳輸一次就夠了，可cookie在網路中是經常傳來傳去。一些網路探測工具（如sniff, snoop,tcpdump等）可以很容易捕獲到cookie的數值。在本方案中，並沒有考慮cookie在傳輸時候的保護。另外對cookie的效驗也過於簡單，並不去檢查發送cookie的來源究竟是不是cookie最初的擁有者，也就是說無法區分正常的使用者和仿造cookie的使用者。
- 當其中一個應用的安全性不好，其他所有的應用都會受到安全威脅
因為有SSO，所以當某個處於 SSO的應用被黒客攻破，那麼很容易攻破其他處於同一個SSO保護的應用。
這些安全性漏洞在商業的SSO解決方案中都會有所考慮，提供相關的安全措施和保護手段，例如Sun公司的Access Manager，cookie的複雜讀和對cookie的保護都做得非常好。另外在OpneSSO （https://opensso.dev.java.net）的架構指南中也給出了部分安全措施的解決方案。5 當前方案的功能和效能局限性除了安全性，當前方案在功能和效能上都需要很多的改進：
- 當前所提供的登入認證模式只有一種：使用者名稱和密碼，而且為了簡單，將使用者名稱和密碼放在記憶體當中。事實上，使用者身份資訊的來源應該是多種多樣的，可以是來自資料庫中，LDAP中，甚至於來自作業系統自身的使用者列表。還有很多其他的認證模式都是商務應用不可缺少的，因此SSO的解決方案應該包括各種認證的模式，包括數位憑證，Radius， SafeWord ，MemberShip，SecurID等多種方式。最為靈活的方式應該允許可插入的JAAS架構來擴充身份認證的介面
- 我們編寫的Filter只能用於J2EE的應用，而對於大量非Java的Web應用，卻無法提供SSO服務。
- 在將Filter應用到Web應用的時候，需要對容器上的每一個應用都要做相應的修改，重新部署。而更加流行的做法是Agent機制：為每一個應用伺服器安裝一個agent，就可以將SSO功能應用到這個應用伺服器中的所有應用。
- 當前的方案不能支援分別位於不同domain的Web應用進行SSO。這是因為瀏覽器在訪問Web伺服器的時候，僅僅會帶上和當前web伺服器具有相同domain名稱的那些cookie。要提供跨域的SSO的解決方案有很多其他的方法，在這裡就不多說了。Sun的Access Manager就具有跨域的SSO的功能。
- 另外，Filter的效能問題也是需要重視的方面。因為Filter會截獲每一個符合URL映射規則的請求，獲得cookie，驗證其有效性。這一系列任務是比較消耗資源的，特別是驗證cookie有效性是一個遠端http的調用，來訪問SSOAuth的認證服務，有一定的延時。因此在效能上需要做進一步的提高。例如在本範例中，如果將URL映射從“.jsp”改成“/*”，也就是說filter對所有的請求都起作用，整個應用會變得非常慢。這是因為，頁面當中包含了各種靜態元素如gif圖片，css樣式檔案，和其他html靜態頁面，這些頁面的訪問都要通過filter去驗證。而事實上，這些靜態元素沒有什麼安全上的需求，應該在filter中進行判斷，不去效驗這些請求，效能會好很多。另外，如果在filter中加上一定的cache，而不需要每一個cookie效驗請求都去遠端的身份認證服務中執行，效能也能大幅度提高。
- 另外系統還需要很多其他的服務，如在記憶體中定時刪除無用的cookie映射等等，都是一個嚴肅的解決方案需要考慮的問題。
web-sso的安全
