【導讀】前些天一位朋友要我?guī)兔ψ鲆粏吸c登錄，其實這個概念早已耳熟能詳，但實際應用很少，難得最近輕閑，于是決定通過本文來詳細描述一個SSO解決方案，希望對大家有所幫助。的解決方案很多，但搜索結果令人大失所望，大部分是相互轉載，并且描述的也是走馬觀花。閑話少敘，進入正題，我的想法是使用集中驗證方式，多個站點集中Passport驗證。為方便清晰描述，先定義幾個名詞，本文中出現(xiàn)之處均為如下含義。使用的是Cache，分站使用Session。同時產生分站a的本地憑證，當該用戶需要再次驗證時將先檢查本地憑證，以減少網絡交。DEMO中令牌我使用主站的Cookie，并指定=""。從分站Redirect到主站頁面，然后該頁面讀取Cookie并以URL參數(shù)。如果有多個頁面的話不可能為每個頁寫一個這樣的邏輯，OK，那么把這套邏輯封裝成一。("恭喜，分站憑證存在，您被授權訪問該頁面！

　　

【正文】 需要調用身份認證的服務，來判斷 cookie 時候真的有效，以及當前的cookie 對應的用戶是誰。 如 果 cookie 效驗成功，就允許用戶訪問當前請求的資源。 以上這些功能，可以用很多方法來實現(xiàn)： 在每個被訪問的資源中（ JSP 或 Servlet）中都加入身份認證的服務，來獲得 cookie，并且判斷當前用戶是否登錄過。不過這個笨方法沒有人會用 :)。 可以通過一個 controller，將所有的功能都寫到一個 servlet 中，然后在 URL 映射的時候，映射到所有需要保護的 URL集合中（例如 *.jsp， /security/*等）。這個方法可以使用，不過，它的缺點是不能重用。在每個應用中都要部署一個相同的 servlet。 Filter 是比較好的方法。符合 以上的 J2EE 容器就具有部署 filter 的功能。（ Filter的 使 用 可 以 參 考 JavaWolrd 的 文 章 Filter 是一個具有很好的模塊化，可重用的編程 API，用在 SSO 正合適不過。本樣例就是使用一個 filter 來完成以上的功能。 package SSO。 import .*。 import .*。 import .*。 import .*。 import .*。 import .*。 import .*。 import .*。 import 。 public class SSOFilter implements Filter { private FilterConfig filterConfig = null。 private String cookieName=WangYuDesktopSSOID。 private String SSOServiceURL= private String SSOLoginPage= public void init(FilterConfig filterConfig) { = filterConfig。 if (filterConfig != null) { if (debug) { log(SSOFilter:Initializing filter)。 } } cookieName = (cookieName)。 SSOServiceURL = (SSOServiceURL)。 SSOLoginPage = (SSOLoginPage)。 } ..... ..... } 以上的初始化的源代碼有兩點需要說明：一是有兩個需要配置的參數(shù) SSOServiceURL 和SSOLoginPage。因為當前的 Web應用很可能和身份認證服務（ SSOAuth）不在同一臺機器上，所以需要讓這個 filter 知道身份認證服務部署的 URL，這樣才能去調用它的服務。另外一點就是由于身份認證的服務調用是要通過 協(xié)議來調用的（在本樣例中是這樣設計的，讀者完全可以設計自己的身份服務，使用別的調用協(xié)議，如 RMI 或 SOAP 等等），所有筆者引用 了 apache 的 mons 工具包（詳細信息情 訪問 apache 的網 站 “client”可以大大簡化 調用的編程。 下面看看 filter 的主體方法 doFilter(): public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { if (debug) log(SSOFilter:doFilter())。 HttpServletRequest request = (HttpServletRequest) req。 HttpServletResponse response = (HttpServletResponse) res。 String result=failed。 String url = ().toString()。 String qstring = ()。 if (qstring == null) qstring =。 //檢查 請求的 head 是否有需要的 cookie String cookieValue =。 [] diskCookies = ()。 if (diskCookies != null) { for (int i = 0。 i 。 i++) { if(diskCookies[i].getName().equals(cookieName)){ cookieValue = diskCookies[i].getValue()。 //如果找到了相應的 cookie 則效驗其有效性 result = SSOService(cookieValue)。 if (debug) log(found cookies!)。 } } } if ((failed)) { //效驗失敗或沒有找到 cookie，則需要登錄 (SSOLoginPage+?goto=+url)。 } else if ((logout) 1) {//logout 服務 if (debug) log(logout action!)。 logoutService(cookieValue)。 (SSOLoginPage+?goto=+url)。 } else {//效驗成功 (SSOUser,result)。 Throwable problem = null。 try { (req, res)。 } catch(Throwable t) { problem = t。 ()。 } if (problem != null) { if (problem instanceof ServletException) throw (ServletException)problem。 if (problem instanceof IOException) throw (IOException)problem。 sendProcessingError(problem, res)。 } } } doFilter()方法的邏輯也是非常簡單的，在接收到請求的時候，先去查找是否存在 期望的cookie值，如果找到了，就會調用 SSOService(cookieValue)去效驗這個 cookie 的有效性。如果 cookie 效驗不成功或者 cookie 根本不存在，就會直接轉到登錄界面讓用戶登錄；如果cookie 效驗成功，就不會做任何阻攔，讓此請求進行下去。在配置文件中，有下面的一個節(jié)點表示了此 filter 的 URL 映射關系：只攔截所有的 jsp 請求。 filtermapping filternameSSOFilter/filtername urlpattern*.jsp/urlpattern /filtermapping 下面還有幾個主要的函數(shù)需要說明： private String SSOService(String cookievalue) throws IOException { String authAction = ?action=authcookieamp。cookiename=。 HttpClient client = new HttpClient()。 GetMethod get = new GetMethod(SSOServiceURL+authAction+cookievalue)。 try { (get)。 String result = ()。 return result。 } finally { ()。 } } private void logoutService(String cookievalue) throws IOException { String authAction = ?action=logoutamp。cookiename=。 HttpClient client = new HttpClient()。 GetMethod get = new GetMethod(SSOServiceURL+authAction+cookievalue)。 try { (get)。 ()。 } finally { ()。 } } 這兩個函數(shù) 主要是利用 apache 中的 client 訪問 SSOAuth 提供的認證服務來完成效驗cookie 和 logout 的功能。 其他的函數(shù)都很簡單，有很多都是我的 IDE（ NetBeans）替我自動生成的。 4 當前方案的安全局限性 當前這個 WEBSSO 的方案是一個比較簡單的雛形，主要是用來演示 SSO 的概念和說明SSO 技術的實現(xiàn)方式。有很多方面還需要完善，其中安全性是非常重要的一個方面。 我們說過，采用 SSO 技術的主要目的之一就是加強安全性，降低安全風險。因為采用了SSO，在網絡上傳遞密碼的次數(shù)減少，風 險降低是顯然的，但是當前的方案卻有其他的安全風險。由于 cookie 是一個用戶登錄的唯一憑據(jù)，對 cookie 的保護措施是系統(tǒng)安全的重要環(huán)節(jié)： cookie 的長度和復雜度 在本方案中， cookie是有一個固定的字符串（我的姓名）加上當前的時間戳。這樣的 cookie很容易被偽造和猜測。懷有惡意的用戶如果猜測到合法的 cookie 就可以被當作已經登錄的用戶，任意訪問權限范圍內的資源 cookie 的效驗和保護 在本方案中，雖然密碼只要傳輸一次就夠了，可 cookie 在網絡中是經常傳來傳去。一些網絡探測工具（如 sniff, snoop,tcpdump 等）可以很容易捕獲到 cookie的數(shù)值。在本方案中，并沒有考慮 cookie在傳輸時候的保護。另外對 cookie的效驗也過于簡單，并不去檢查發(fā)送cookie 的來源究竟是不是 cookie 最初的擁有者，也就是說無法區(qū)分正常的用戶和仿造cookie 的用戶。 當其中一個應用的安全性不好，其他所有的應用都會受到安全威脅 因為有 SSO，所以當某個處于 SSO 的應用被黒客攻破，那么很容易攻破其他處于同一個SSO 保護的應用。 這些安全漏洞在商業(yè)的 SSO解決方案中都會有所考慮，提供相關 的安全措施和保護手段，例如 Sun公司的 Access Manager， cookie 的復雜讀和對 cookie 的保護都做得非常好。另外在 OpneSSO （ 的架構指南中也給出了部分安全措施的解決方案。 5 當前方案的功能和性能局限性 除了安全性，當前方案在功能和性能上都需要很多的改進： 當前所提供的登錄認證模式只有一種：用戶名和密碼，而且為了簡單，將用戶名和密碼放在內存當中。事實上，用戶身份信息的來源應該是多種多樣的，可以是來自數(shù)據(jù)庫中， LDAP 中，甚 至于來自操作系統(tǒng)自身的用戶列表。還有很多其他的認證模式都是商務應用不可缺少的，因此 SSO的解決方案應該包括各種認證的模式，包括數(shù)字證書， Radius， SafeWord ，MemberShip， SecurID 等多