java實現簡單的單點登陸_轉

摘要：單點登陸（SSO）的技術被愈來愈普遍地運用到各個領域的軟件系統當中。本文從業務的角度分析了單點登陸的需求和應用領域；從技術自己的角度分析了單點登陸技術的內部機制和實現手段，而且給出Web-SSO和桌面SSO的實現、源代碼和詳細講解；還從安全和性能的角度對現有的實現技術進行進一步分析，指出相應的風險和須要改進的方面。本文除了從多個方面和角度給出了對單點登陸（SSO）的全面分析，還而且討論瞭如何將現有的應用和SSO服務結合起來，可以幫助應用架構師和系統分析人員從本質上認識單點登陸，從而更好地設計出符合須要的安全架構。

關鍵字：SSO, Java, J2EE, JAAS

1  什麼是單點登錄

單點登陸（Single Sign On），簡稱爲 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。

較大的企業內部，通常都有不少的業務支持系統爲其提供相應的管理和IT服 務。例如財務系統爲財務人員提供財務的管理、計算和報表服務；人事系統爲人事部門提供全公司人員的維護服務；各類業務系統爲公司內部不一樣的業務提供不一樣的 服務等等。這些系統的目的都是讓計算機來進行復雜繁瑣的計算工做，來替代人力的手工勞動，提升工做效率和質量。這些不一樣的系統每每是在不一樣的時期建設起來 的，運行在不一樣的平臺上；也許是由不一樣廠商開發，使用了各類不一樣的技術和標準。若是舉例說國內一著名的IT公司（名字隱去），內部共有60多個業務系統，這些系統包括兩個不一樣版本的SAP的ERP系統，12個不一樣類型和版本的數據庫系統，8個不一樣類型和版本的操做系統，以及使用了3種不一樣的防火牆技術，還有數十種互相不能兼容的協議和標準，你相信嗎？不要懷疑，這種狀況其實很是廣泛。每個應用系統在運行了數年之後，都會成爲不可替換的企業IT架構的一部分，以下圖所示。

隨 着企業的發展，業務系統的數量在不斷的增長，老的系統卻不能輕易的替換，這會帶來不少的開銷。其一是管理上的開銷，須要維護的系統愈來愈多。不少系統的數 據是相互冗餘和重複的，數據的不一致性會給管理工做帶來很大的壓力。業務和業務之間的相關性也愈來愈大，例如公司的計費系統和財務系統，財務系統和人事系 統之間都不可避免的有着密切的關係。

爲了下降管理的消耗，最大限度的重用已有投資的系統，不少企業都在進行着企業應用集成（EAI）。 企業應用集成能夠在不一樣層面上進行：例如在數據存儲層面上的「數據大集中」，在傳輸層面上的「通用數據交換平臺」，在應用層面上的「業務流程整合」，和用 戶界面上的「通用企業門戶」等等。事實上，還用一個層面上的集成變得愈來愈重要，那就是「身份認證」的整合，也就是「單點登陸」。

一般來講，每一個單獨的系統都會有本身的安全體系和身份認證系統。整合之前，進入每一個系統都須要進行登陸，這樣的局面不只給管理上帶來了很大的困難，在安全方面也埋下了重大的隱患。下面是一些著名的調查公司顯示的統計數據：

• 用戶天天平均 16 分鐘花在身份驗證任務上 - 資料來源： IDS
• 頻繁的 IT 用戶平均有 21 個密碼 - 資料來源： NTA Monitor Password Survey
• 49% 的人寫下了其密碼，而 67% 的人不多改變它們
• 每 79 秒出現一塊兒身份被竊事件 - 資料來源：National Small Business Travel Assoc
• 全球欺騙損失每一年約 12B - 資料來源：Comm Fraud Control Assoc
• 到 2007 年，身份管理市場將成倍增加至 $4.5B - 資料來源：IDS

 

使用「單點登陸」整合後，只須要登陸一次就能夠進入多個系統，而不須要從新登陸，這不只僅帶來了更好的用戶體驗，更重要的是下降了安全的風險和管理的消耗。請看下面的統計數據：

• 提升 IT 效率：對於每 1000 個受管用戶，每用戶可節省$70K
• 幫助臺呼叫減小至少1/3，對於 10K 員工的公司，每一年能夠節省每用戶 $75，或者合計 $648K
• 生產力提升：每一個新員工可節省 $1K，每一個老員工可節省 $350 �資料來源：Giga
• ROI 回報：7.5 到 13 個月 �資料來源：Gartner

 

另外，使用「單點登陸」仍是SOA時代的需求之一。在面向服務的架構中，服務和服務之間，程序和程序之間的通信大量存在，服務之間的安全認證是SOA應用的難點之一，應此創建「單點登陸」的系統體系可以大大簡化SOA的安全問題，提升服務之間的合做效率。

2  單點登錄的技術實現機制

隨着SSO技術的流行，SSO的產品也是滿天飛揚。全部著名的軟件廠商都提供了相應的解決方案。在這裏我並不想介紹本身公司（Sun Microsystems）的產品，而是對SSO技術自己進行解析，而且提供本身開發這一類產品的方法和簡單演示。有關我寫這篇文章的目的，請參考個人博客（ http://yuwang881.blog.sohu.com/3184816.html）。

單 點登陸的機制實際上是比較簡單的，用一個現實中的例子作比較。頤和園是北京著名的旅遊景點，也是我常去的地方。在頤和園內部有許多獨立的景點，例如「蘇州 街」、「佛香閣」和「德和園」，均可以在各個景點門口單獨買票。不少遊客須要遊玩全部德景點，這種買票方式很不方便，須要在每一個景點門口排隊買票，錢包拿 進拿出的，容易丟失，很不安全。因而絕大多數遊客選擇在大門口買一張通票（也叫套票），就能夠玩遍全部的景點而不須要從新再買票。他們只須要在每一個景點門 口出示一下剛纔買的套票就可以被容許進入每一個獨立的景點。

單點登陸的機制也同樣，以下圖所示，當用戶第一次訪問應用系統1的時候，由於尚未登陸，會被引導到認證系統中進行登陸（1）；根據用戶提供的登陸信息，認證系統進行身份效驗，若是經過效驗，應該返回給用戶一個認證的憑據－－ticket（2）；用戶再訪問別的應用的時候（3，5）就會將這個ticket帶上，做爲本身認證的憑據，應用系統接受到請求以後會把ticket送到認證系統進行效驗，檢查ticket的合法性（4，6）。若是經過效驗，用戶就能夠在不用再次登陸的狀況下訪問應用系統2和應用系統3了。

從上面的視圖能夠看出，要實現SSO，須要如下主要的功能：

• 全部應用系統共享一個身份認證系統。
  統一的認證系統是SSO的前提之一。認證系統的主要功能是將用戶的登陸信息和用戶信息庫相比較，對用戶進行登陸認證；認證成功後，認證系統應該生成統一的認證標誌（ticket），返還給用戶。另外，認證系統還應該對ticket進行效驗，判斷其有效性。
• 全部應用系統可以識別和提取ticket信息
  要實現SSO的功能，讓用戶只登陸一次，就必須讓應用系統可以識別已經登陸過的用戶。應用系統應該能對ticket進行識別和提取，經過與認證系統的通信，能自動判斷當前用戶是否登陸過，從而完成單點登陸的功能。

 

上面的功能只是一個很是簡單的SSO架構，在現實狀況下的SSO有着更加複雜的結構。有兩點須要指出的是：

• 單一的用戶信息數據庫並非必須的，有許多系統不能將全部的用戶信息都集中存儲，應該容許用戶信息放置在不一樣的存儲中，以下圖所示。事實上，只要統一認證系統，統一ticket的產生和效驗，不管用戶信息存儲在什麼地方，都能實現單點登陸。

 

• 統一的認證系統並非說只有單個的認證服務器，以下圖所示，整個系統能夠存在兩個以上的認證服務器，這些服務器甚至能夠是不一樣的產品。認證服務器之間要經過標準的通信協議，互相交換認證信息，就能完成更高級別的單點登陸。以下圖，當用戶在訪問應用系統1時，由第一個認證服務器進行認證後，獲得由此服務器產生的ticket。當他訪問應用系統4的時候，認證服務器2可以識別此ticket是由第一個服務器產生的，經過認證服務器之間標準的通信協議（例如SAML）來交換認證信息，仍然可以完成SSO的功能。

 

3 WEB-SSO 的實現

隨着互聯網的高速發展，WEB應用幾乎統治了絕大部分的軟件應用系統，所以WEB-SSO是SSO應用當中最爲流行。WEB-SSO有其自身的特色和優點，實現起來比較簡單易用。不少商業軟件和開源軟件都有對WEB-SSO的實現。其中值得一提的是OpenSSO （ https://opensso.dev.java.net），爲用Java實現WEB-SSO提供架構指南和服務指南，爲用戶本身來實現WEB-SSO提供了理論的依據和實現的方法。

爲何說WEB-SSO比較容易實現呢？這是有WEB應用自身的特色決定的。

衆所周知，Web協議（也就是HTTP）是一個無狀態的協議。一個Web應用由不少個Web頁面組成，每一個頁面都有惟一的URL來定義。用戶在瀏覽器的地址欄輸入頁面的URL，瀏覽器就會向Web Server去發送請求。以下圖，瀏覽器向Web服務器發送了兩個請求，申請了兩個頁面。這兩個頁面的請求是分別使用了兩個單獨的HTTP鏈接。所謂無狀態的協議也就是表如今這裏，瀏覽器和Web服務器會在第一個請求完成之後關閉鏈接通道，在第二個請求的時候從新創建鏈接。Web服務器並不區分哪一個請求來自哪一個客戶端，對全部的請求都一視同仁，都是單獨的鏈接。這樣的方式大大區別於傳統的（Client/Server）C/S結構,在那樣的應用中，客戶端和服務器端會創建一個長時間的專用的鏈接通道。正是由於有了無狀態的特性，每一個鏈接資源可以很快被其餘客戶端所重用，一臺Web服務器纔可以同時服務於成千上萬的客戶端。

可是咱們一般的應用是有狀態的。先不用提不一樣應用之間的SSO，在同一個應用中也須要保存用戶的登陸身份信息。例如用戶在訪問頁面1的時候進行了登陸，可是剛纔也提到，客戶端的每一個請求都是單獨的鏈接，當客戶再次訪問頁面2的時候，如何才能告訴Web服務器，客戶剛纔已經登陸過了呢？瀏覽器和服務器之間有約定：經過使用cookie技術來維護應用的狀態。Cookie是能夠被Web服務器設置的字符串，而且能夠保存在瀏覽器中。以下圖所示，當瀏覽器訪問了頁面1時，web服務器設置了一個cookie，並將這個cookie和頁面1一塊兒返回給瀏覽器，瀏覽器接到cookie以後，就會保存起來，在它訪問頁面2的時候會把這個cookie也帶上，Web服務器接到請求時也能讀出cookie的值，根據cookie值的內容就能夠判斷和恢復一些用戶的信息狀態。

Web-SSO徹底能夠利用Cookie結束來完成用戶登陸信息的保存，將瀏覽器中的Cookie和上文中的Ticket結合起來，完成SSO的功能。

 

爲了完成一個簡單的SSO的功能，須要兩個部分的合做：

1. 統一的身份認證服務。
2. 修改Web應用，使得每一個應用都經過這個統一的認證服務來進行身份效驗。

3.1 Web SSO  的樣例

根據上面的原理，我用J2EE的技術（JSP和Servlet）完成了一個具備Web-SSO的簡單樣例。樣例包含一個身份認證的服務器和兩個簡單的Web應用，使得這兩個 Web應用經過統一的身份認證服務來完成Web-SSO的功能。此樣例全部的源代碼和二進制代碼均可以從網站地址 http://gceclub.sun.com.cn/wangyu/ 下載。

 

樣例下載、安裝部署和運行指南：

• Web-SSO的樣例是由三個標準Web應用組成，壓縮成三個zip文件，從http://gceclub.sun.com.cn/wangyu/web-sso/中下載。其中SSOAuth（http://gceclub.sun.com.cn/wangyu/web-sso/SSOAuth.zip）是身份認證服務；SSOWebDemo1（http://gceclub.sun.com.cn/wangyu/web-sso/SSOWebDemo1.zip）和SSOWebDemo2（http://gceclub.sun.com.cn/wangyu/web-sso/SSOWebDemo2.zip）是兩個用來演示單點登陸的Web應用。這三個Web應用之因此沒有打成war包，是由於它們不能直接部署，根據讀者的部署環境須要做出小小的修改。樣例部署和運行的環境有必定的要求，須要符合Servlet2.3以上標準的J2EE容器才能運行（例如Tomcat5,Sun Application Server 8, Jboss 4等）。另外，身份認證服務須要JDK1.5的運行環境。之因此要用JDK1.5是由於筆者使用了一個線程安全的高性能的Java集合類「ConcurrentMap」，只有在JDK1.5中才有。
• 這三個Web應用徹底能夠單獨部署，它們能夠分別部署在不一樣的機器，不一樣的操做系統和不一樣的J2EE的產品上，它們徹底是標準的和平臺無關的應用。可是有一個限制，那兩臺部署應用（demo一、demo2）的機器的域名須要相同，這在後面的章節中會解釋到cookie和domain的關係以及如何製做跨域的WEB-SSO
• 解壓縮SSOAuth.zip文件，在/WEB-INF/下的web.xml中請修改「domainname」的屬性以反映實際的應用部署狀況，domainname須要設置爲兩個單點登陸的應用（demo1和demo2）所屬的域名。這個domainname和當前SSOAuth服務部署的機器的域名沒有關係。我缺省設置的是「.sun.com」。若是你部署demo1和demo2的機器沒有域名，請輸入IP地址或主機名（如localhost），可是若是使用IP地址或主機名也就意味着demo1和demo2須要部署到一臺機器上了。設置完後，根據你所選擇的J2EE容器，可能須要將SSOAuth這個目錄壓縮打包成war文件。用「jar -cvf SSOAuth.war SSOAuth/」就能夠完成這個功能。
• 解壓縮SSOWebDemo1和SSOWebDemo2文件，分別在它們/WEB-INF/下找到web.xml文件，請修改其中的幾個初始化參數
  <init-param>
  <param-name>SSOServiceURL</param-name>
  <param-value>http://wangyu.prc.sun.com:8080/SSOAuth/SSOAuth</param-value>
  </init-param>
  <init-param>
  <param-name>SSOLoginPage</param-name>
  <param-value>http://wangyu.prc.sun.com:8080/SSOAuth/login.jsp</param-value>
  </init-param>
  將其中的SSOServiceURL和SSOLoginPage修改爲部署SSOAuth應用的機器名、端口號以及根路徑（缺省是SSOAuth）以反映實際的部署狀況。設置完後，根據你所選擇的J2EE容器，可能須要將SSOWebDemo1和SSOWebDemo2這兩個目錄壓縮打包成兩個war文件。用「jar -cvf SSOWebDemo1.war SSOWebDemo1/」就能夠完成這個功能。
• 請輸入第一個web應用的測試URL（test.jsp）,例如http://wangyu.prc.sun.com:8080/ SSOWebDemo1/test.jsp，若是是第一次訪問，便會自動跳轉到登陸界面，以下圖
  
  
• 使用系統自帶的三個賬號之一登陸（例如，用戶名：wangyu,密碼：wangyu），便能成功的看到test.jsp的內容：顯示當前用戶名和歡迎信息。
  

• 請接着在同一個瀏覽器中輸入第二個web應用的測試URL（test.jsp）,例如http://wangyu.prc.sun.com:8080/ SSOWebDemo2/test.jsp。你會發現，不須要再次登陸就能看到test.jsp的內容，一樣是顯示當前用戶名和歡迎信息，並且歡迎信息中明確的顯示當前的應用名稱（demo2）。

             

3.2 WEB-SSO 代碼講解

3.2.1 身份認證服務代碼解析

Web-SSO的源代碼能夠從網站地址http://gceclub.sun.com.cn/wangyu/web-sso/websso_src.zip下載。身份認證服務是一個標準的web應用，包括一個名爲SSOAuth的Servlet，一個login.jsp文件和一個failed.html。身份認證的全部服務幾乎都由SSOAuth的Servlet來實現了；login.jsp用來顯示登陸的頁面（若是發現用戶尚未登陸過）；failed.html是用來顯示登陸失敗的信息（若是用戶的用戶名和密碼與信息數據庫中的不同）。

SSOAuth的代碼以下面的列表顯示，結構很是簡單，先看看這個Servlet的主體部分 ：

package DesktopSSO;
 
import java.io.*;
import java.net.*;
import java.text.*;
import java.util.*;
import java.util.concurrent.*;
 
import javax.servlet.*;
import javax.servlet.http.*;
 
 
public class SSOAuth extends HttpServlet {
   
    static private ConcurrentMap accounts;
    static private ConcurrentMap SSOIDs;
    String cookiename="WangYuDesktopSSOID";
    String domainname;
   
    public void init(ServletConfig config) throws ServletException {
        super.init(config);
        domainname= config.getInitParameter("domainname");
        cookiename = config.getInitParameter("cookiename");
        SSOIDs = new ConcurrentHashMap();
        accounts=new ConcurrentHashMap();
        accounts.put("wangyu", "wangyu");
        accounts.put("paul", "paul");
        accounts.put("carol", "carol");
    }
 
    protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        PrintWriter out = response.getWriter();
        String action = request.getParameter("action");
        String result="failed";
        if (action==null) {
            handlerFromLogin(request,response);
        } else if (action.equals("authcookie")){
            String myCookie = request.getParameter("cookiename");
            if (myCookie != null) result = authCookie(myCookie);
            out.print(result);
            out.close();
        } else if (action.equals("authuser")) {
           result=authNameAndPasswd(request,response);
            out.print(result);
            out.close();
        } else if (action.equals("logout")) {
            String myCookie = request.getParameter("cookiename");
            logout(myCookie);
            out.close();
        }
    }
 
.....
 
}

從代碼很容易看出，SSOAuth就是一個簡單的Servlet。其中有兩個靜態成員變量：accounts和SSOIDs，這兩個成員變量都使用了JDK1.5中線程安全的MAP類： ConcurrentMap，因此這個樣例必定要JDK1.5才能運行。Accounts用來存放用戶的用戶名和密碼，在init()的方法中能夠看到我給系統添加了三個合法的用戶。在實際應用中，accounts應該是去數據庫中或LDAP中得到，爲了簡單起見，在本樣例中我使用了ConcurrentMap在內存中用程序建立了三個用戶。而SSOIDs保存了在用戶成功的登陸後所產生的cookie和用戶名的對應關係。它的功能顯而易見：當用戶成功登陸之後，再次訪問別的系統，爲了鑑別這個用戶請求所帶的cookie的有效性，須要到SSOIDs中檢查這樣的映射關係是否存在。

 

在主要的請求處理方法processRequest()中，能夠很清楚的看到SSOAuth的全部功能

1. 若是用戶尚未登陸過，是第一次登陸本系統，會被跳轉到login.jsp頁面（在後面會解釋如何跳轉）。用戶在提供了用戶名和密碼之後，就會用handlerFromLogin()這個方法來驗證。
2. 若是用戶已經登陸過本系統，再訪問別的應用的時候，是不須要再次登陸的。由於瀏覽器會將第一次登陸時產生的cookie和請求一塊兒發送。效驗cookie的有效性是SSOAuth的主要功能之一。
3. SSOAuth還能直接效驗非login.jsp頁面過來的用戶名和密碼的效驗請求。這個功能是用於非web應用的SSO，這在後面的桌面SSO中會用到。
4. SSOAuth還提供logout服務。

 

下面看看幾個主要的功能函數：

private void handlerFromLogin(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        String username = request.getParameter("username");
        String password = request.getParameter("password");
        String pass = (String)accounts.get(username);
        if ((pass==null)||(!pass.equals(password)))
            getServletContext().getRequestDispatcher("/failed.html").forward(request, response);
        else {
            String gotoURL = request.getParameter("goto");
            String newID = createUID();
            SSOIDs.put(newID, username);
            Cookie wangyu = new Cookie(cookiename, newID);
            wangyu.setDomain(domainname);
            wangyu.setMaxAge(60000);
            wangyu.setValue(newID);
            wangyu.setPath("/");
            response.addCookie(wangyu);
            System.out.println("login success, goto back url:" + gotoURL);
            if (gotoURL != null) {
                PrintWriter out = response.getWriter();
                response.sendRedirect(gotoURL);
                out.close();
            }
        }  
    }

handlerFromLogin()這個方法是用來處理來自login.jsp的登陸請求。它的邏輯很簡單：將用戶輸入的用戶名和密碼與預先設定好的用戶集合（存放在accounts中）相比較，若是用戶名或密碼不匹配的話，則返回登陸失敗的頁面（failed.html），若是登陸成功的話，須要爲用戶當前的session建立一個新的ID，並將這個ID和用戶名的映射關係存放到SSOIDs中，最後還要將這個ID設置爲瀏覽器可以保存的cookie值。

登陸成功後，瀏覽器會到哪一個頁面呢？那咱們回顧一下咱們是如何使用身份認證服務的。通常來講咱們不會直接訪問身份服務的任何URL，包括login.jsp。身份服務是用來保護其餘應用服務的，用戶通常在訪問一個受SSOAuth保護的Web應用的某個URL時，當前這個應用會發現當前的用戶尚未登陸，便強制將也頁面轉向SSOAuth的login.jsp，讓用戶登陸。若是登陸成功後，應該自動的將用戶的瀏覽器指向用戶最初想訪問的那個URL。在handlerFromLogin()這個方法中，咱們經過接收「goto」這個參數來保存用戶最初訪問的URL，成功後便從新定向到這個頁面中。

另一個要說明的是，在設置cookie的時候，我使用了一個setMaxAge(6000)的方法。這個方法是用來設置cookie的有效期，單位是秒。若是不使用這個方法或者參數爲負數的話，當瀏覽器關閉的時候，這個cookie就失效了。在這裏我給了很大的值（1000分鐘），致使的行爲是：當你關閉瀏覽器（或者關機），下次再打開瀏覽器訪問剛纔的應用，只要在1000分鐘以內，就不須要再登陸了。我這樣作是下面要介紹的桌面SSO中所須要的功能。

其餘的方法更加簡單，這裏就很少解釋了。

 

3.2.2 具備 SSO 功能的 web 應用源代碼解析

要實現WEB-SSO的功能，只有身份認證服務是不夠的。這點很顯然，要想使多個應用具備單點登陸的功能，還須要每一個應用自己的配合：將本身的身份認證的服務交給一個統一的身份認證服務－SSOAuth。SSOAuth服務中提供的各個方法就是供每一個加入SSO的Web應用來調用的。

通常來講，Web應用須要SSO的功能，應該經過如下的交互過程來調用身份認證服務的提供的認證服務：

• Web應用中每個須要安全保護的URL在訪問之前，都須要進行安全檢查，若是發現沒有登陸（沒有發現認證以後所帶的cookie），就從新定向到SSOAuth中的login.jsp進行登陸。
• 登陸成功後，系統會自動給你的瀏覽器設置cookie，證實你已經登陸過了。
• 當你再訪問這個應用的須要保護的URL的時候，系統仍是要進行安全檢查的，可是此次系統可以發現相應的cookie。
• 有了這個cookie，還不能證實你就必定有權限訪問。由於有可能你已經logout,或者cookie已通過期了，或者身份認證服務重起過，這些狀況下，你的cookie均可能無效。應用系統拿到這個cookie，還須要調用身份認證的服務，來判斷cookie時候真的有效，以及當前的cookie對應的用戶是誰。
• 若是cookie效驗成功，就容許用戶訪問當前請求的資源。

以上這些功能，能夠用不少方法來實現：

• 在每一個被訪問的資源中（JSP或Servlet）中都加入身份認證的服務，來得到cookie，而且判斷當前用戶是否登陸過。不過這個笨方法沒有人會用:-)。
• 能夠經過一個controller，將全部的功能都寫到一個servlet中，而後在URL映射的時候，映射到全部須要保護的URL集合中（例如*.jsp，/security/*等）。這個方法可使用，不過，它的缺點是不能重用。在每一個應用中都要部署一個相同的servlet。
• Filter是比較好的方法。符合Servlet2.3以上的J2EE容器就具備部署filter的功能。（Filter的使用能夠參考JavaWolrd的文章http://www.javaworld.com/javaworld/jw-06-2001/jw-0622-filters.html）Filter是一個具備很好的模塊化，可重用的編程API，用在SSO正合適不過。本樣例就是使用一個filter來完成以上的功能。

package SSO;
 
import java.io.*;
import java.net.*;
import java.util.*;
import java.text.*;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.*;
import org.apache.commons.httpclient.*;
import org.apache.commons.httpclient.methods.GetMethod;
 
public class SSOFilter implements Filter {
    private FilterConfig filterConfig = null;
    private String cookieName="WangYuDesktopSSOID";
    private String SSOServiceURL= "http://wangyu.prc.sun.com:8080/SSOAuth/SSOAuth";
    private String SSOLoginPage= "http://wangyu.prc.sun.com:8080/SSOAuth/login.jsp";
   
    public void init(FilterConfig filterConfig) {
 
        this.filterConfig = filterConfig;
        if (filterConfig != null) {
            if (debug) {
                log("SSOFilter:Initializing filter");
            }
        }       
        cookieName = filterConfig.getInitParameter("cookieName");
        SSOServiceURL = filterConfig.getInitParameter("SSOServiceURL");
        SSOLoginPage = filterConfig.getInitParameter("SSOLoginPage");
    } 
.....
.....
 
}

以上的初始化的源代碼有兩點須要說明：一是有兩個須要配置的參數SSOServiceURL和SSOLoginPage。由於當前的Web應用極可能和身份認證服務（SSOAuth）不在同一臺機器上，因此須要讓這個filter知道身份認證服務部署的URL，這樣才能去調用它的服務。另一點就是因爲身份認證的服務調用是要經過http協議來調用的（在本樣例中是這樣設計的，讀者徹底能夠設計本身的身份服務，使用別的調用協議，如RMI或SOAP等等），全部筆者引用了apache的commons工具包（詳細信息情訪問apache 的網站http://jakarta.apache.org/commons/index.html），其中的「httpclient」能夠大大簡化http調用的編程。

下面看看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 = request.getRequestURL().toString();
        String qstring = request.getQueryString();
        if (qstring == null) qstring ="";
 
        //檢查http請求的head是否有須要的cookie
        String cookieValue ="";
        javax.servlet.http.Cookie[] diskCookies = request.getCookies();
        if (diskCookies != null) {
            for (int i = 0; i < diskCookies.length; i++) {
                if(diskCookies[i].getName().equals(cookieName)){
                    cookieValue = diskCookies[i].getValue();
 
                    //若是找到了相應的cookie則效驗其有效性
                    result = SSOService(cookieValue);
                    if (debug) log("found cookies!");
                }
            }
        }
        if (result.equals("failed")) { //效驗失敗或沒有找到cookie，則須要登陸
            response.sendRedirect(SSOLoginPage+"?goto="+url);
        } else if (qstring.indexOf("logout") > 1) {//logout服務
            if (debug) log("logout action!");
            logoutService(cookieValue);
            response.sendRedirect(SSOLoginPage+"?goto="+url);
        } else {//效驗成功
            request.setAttribute("SSOUser",result);
            Throwable problem = null;
            try {
                chain.doFilter(req, res);
            } catch(Throwable t) {
                problem = t;
                t.printStackTrace();
            }      
            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效驗成功，就不會作任何阻攔，讓此請求進行下去。在配置文件中，有下面的一個節點表示了此filter的URL映射關係：只攔截全部的jsp請求。

<filter-mapping>
<filter-name>SSOFilter</filter-name>
<url-pattern>*.jsp</url-pattern>
</filter-mapping>

 

下面還有幾個主要的函數須要說明：

private String SSOService(String cookievalue) throws IOException {
        String authAction = "?action=authcookie&cookiename=";
        HttpClient httpclient = new HttpClient();
        GetMethod httpget = new GetMethod(SSOServiceURL+authAction+cookievalue);
        try { 
            httpclient.executeMethod(httpget);
            String result = httpget.getResponseBodyAsString();
            return result;
        } finally {
            httpget.releaseConnection();
        }
    }
   
    private void logoutService(String cookievalue) throws IOException {
        String authAction = "?action=logout&cookiename=";
        HttpClient httpclient = new HttpClient();
        GetMethod httpget = new GetMethod(SSOServiceURL+authAction+cookievalue);
        try {
            httpclient.executeMethod(httpget);
            httpget.getResponseBodyAsString();
        } finally {
            httpget.releaseConnection();
        }
    }

這兩個函數主要是利用apache中的httpclient訪問SSOAuth提供的認證服務來完成效驗cookie和logout的功能。

其餘的函數都很簡單，有不少都是個人IDE（NetBeans）替我自動生成的。

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映射等等，都是一個嚴肅的解決方案須要考慮的問題。

6  桌面 SSO 的實現

從WEB-SSO的概念延伸開，咱們能夠把SSO的技術拓展到整個桌面的應用，不只僅侷限在瀏覽器。SSO的概念和原則都沒有改變，只須要再作一點點的工做，就能夠完成桌面 SSO 的應用。

桌面SSO和WEB-SSO同樣，關鍵的技術也在於如何在用戶登陸事後保存登陸的憑據。在WEB-SSO中，登陸的憑據是靠瀏覽器的cookie機制來完成的；在桌面應用中，能夠將登陸的憑證保存到任何地方，只要全部SSO的桌面應用都共享這個憑證。

從網站能夠下載一個簡單的桌面SSO的樣例( http://gceclub.sun.com.cn/wangyu/desktop-sso/desktopsso.zip)和所有源碼（http://gceclub.sun.com.cn/wangyu/desktop-sso/desktopsso_src.zip），雖然簡單，可是它具備桌面SSO大多數的功能，稍微加以擴充就能夠成爲本身的解決方案。

 

6.1 桌面樣例的部署

1. 運行此桌面SSO須要三個前提條件：
   a) WEB-SSO的身份認證應用應該正在運行，由於咱們在桌面SSO當中須要用到統一的認證服務
   b) 當前桌面須要運行Mozilla或Netscape瀏覽器，由於咱們將ticket保存到mozilla的cookie文件中
   c) 必須在JDK1.4以上運行。（WEB-SSO須要JDK1.5以上）
2. 解開desktopsso.zip文件，裏面有兩個目錄bin和lib。
3. bin目錄下有一些腳本文件和配置文件，其中config.properties包含了三個須要配置的參數：
   a) SSOServiceURL要指向WebSSO部署的身份認證的URL
   b) SSOLoginPage要指向WebSSO部署的身份認證的登陸頁面URL
   c) cookiefilepath要指向當前用戶的mozilla所存放cookie的文件
4. 在bin目錄下還有一個login.conf是用來配置JAAS登陸模塊，本樣例提供了兩個，讀者能夠任意選擇其中一個（也能夠都選），再從新運行程序，查看登陸認證的變化
5. 在bin下的運行腳本可能須要做相應的修改
   a) 若是是在unix下，各個jar文件須要用「:」來隔開，而不是「;」
   b) java 運行程序須要放置在當前運行的路徑下，不然須要加上java的路徑全名。

 

6.2 桌面樣例的運行

樣例程序包含三個簡單的Java控制檯程序，這三個程序單獨運行都須要登陸。若是運行第一個命叫「GameSystem」的程序，提示須要輸入用戶名和密碼：

效驗成功之後，便會顯示當前登陸的用戶的基本信息等等。

 這時候再運行第二個桌面Java應用（mailSystem）的時候，就不須要再登陸了，直接就顯示出來剛纔登陸的用戶。

第三個應用是logout，運行它以後，用戶便退出系統。再訪問的時候，又須要從新登陸了。請讀者再製裁執行完logout以後，從新驗證一下前兩個應用的SSO：先運行第二個應用，再運行第一個，會看到相同的效果。

咱們的樣例並無在這裏停步，事實上，本樣例不只可以和在幾個Java應用之間SSO，還能和瀏覽器進行SSO，也就是將瀏覽器也當成是桌面的一部分。這對一些行業有着不小的吸引力。

這時候再打開Mozilla瀏覽器，訪問之前提到的那兩個WEB應用，會發現只要桌面應用若是登陸過，Web應用就不用再登陸了，並且能顯示剛纔登陸的用戶的信息。讀者能夠在幾個桌面和Web應用之間進行登陸和logout的試驗，看看它們之間的SSO。

6.3 桌面樣例的源碼分析

桌面SSO的樣例使用了JAAS（要了解JAAS的詳細的信息請參考http://java.sun.com/products/jaas）。JAAS是對PAM（Pluggable Authentication Module）的Java實現，來完成 Java應用可插拔的安全認證模塊。使用JAAS做爲Java應用的安全認證模塊有不少好處，最主要的是不須要修改源代碼就能夠更換認證方式。例如原有的Java應用若是使用JAAS的認證，若是須要應用SSO，只須要修改JAAS的配置文件就好了。如今在流行的J2EE和其餘 Java的產品中，用戶的身份認證都是經過JAAS來完成的。在樣例中，咱們就展現了這個功能。請看配置文件login.conf

DesktopSSO {
   desktopsso.share.PasswordLoginModule required;
   desktopsso.share.DesktopSSOLoginModule required;
};

當咱們註解掉第二個模塊的時候，只有第一個模塊起做用。在這個模塊的做用下，只有test用戶（密碼是12345）才能登陸。當咱們註解掉第一個模塊的時候，只有第二個模塊起做用，桌面SSO纔會起做用。

 

全部的Java桌面樣例程序都是標準JAAS應用，熟悉JAAS的程序員會很快了解。JAAS中主要的是登陸模塊（LoginModule）。下面是SSO登陸模塊的源碼：

public class DesktopSSOLoginModule implements LoginModule {
   ..........
   private String SSOServiceURL = "";
   private String SSOLoginPage = "";
   private static String cookiefilepath = "";  
   .........

在config.properties的文件中，咱們配置了它們的值：

SSOServiceURL=http://wangyu.prc.sun.com:8080/SSOAuth/SSOAuth
SSOLoginPage=http://wangyu.prc.sun.com:8080/SSOAuth/login.jsp
cookiefilepath=C:\\Documents and Settings\\yw137672\\Application Data\\Mozilla\\Profiles\\default\\hog6z1ji.slt\\cookies.txt

SSOServiceURL和SSOLoginPage成員變量指向了在Web-SSO中用過的身份認證模塊：SSOAuth，這就說明在桌面系統中咱們試圖和Web應用共用一個認證服務。而cookiefilepath成員變量則泄露了一個「天機」：咱們使用了Mozilla瀏覽器的cookie文件來保存登陸的憑證。換句話說，和Mozilla共用了一個保存登陸憑證的機制。之因此用Mozilla是應爲它的Cookie文件格式簡單，很容易編程訪問和修改任意的Cookie值。（我試圖解析Internet Explorer的cookie文件但沒有成功。）

下面是登陸模塊DesktopSSOLoginModule的主體：login()方法。邏輯也是很是簡單：先用Cookie來登錄，若是成功，則直接就進入系統，不然須要用戶輸入用戶名和密碼來登陸系統。

public boolean login() throws LoginException{
        try {
            if (Cookielogin()) return true;
        } catch (IOException ex) {
            ex.printStackTrace();
        }
      if (passwordlogin()) return true;
      throw new FailedLoginException();
 }

下面是Cookielogin()方法的實體，它的邏輯是：先從Cookie文件中得到相應的Cookie值，經過身份效驗服務效驗Cookie的有效性。若是cookie有效就算登陸成功；若是不成功或Cookie不存在，用cookie登陸就算失敗。

public boolean Cookielogin() throws LoginException,IOException {
      String cookieValue="";
      int cookieIndex =foundCookie();
      if (cookieIndex<0)
            return false;
      else
            cookieValue = getCookieValue(cookieIndex);
     username = cookieAuth(cookieValue);
     if (! username.equals("failed")) {
         loginSuccess = true;
         return true;
     }
     return false;
 }

用用戶名和密碼登陸的方法要複雜一些，經過Callback的機制和屏幕輸入輸出進行信息交互，完成用戶登陸信息的獲取；獲取信息之後經過userAuth方法來調用遠端SSOAuth的服務來斷定當前登陸的有效性。

public boolean passwordlogin() throws LoginException {
    //
    // Since we need input from a user, we need a callback handler
    if (callbackHandler == null) {
       throw new LoginException("No CallbackHandler defined");
    }
    Callback[] callbacks = new Callback[2];
    callbacks[0] = new NameCallback("Username");
    callbacks[1] = new PasswordCallback("Password", false);
    //
    // Call the callback handler to get the username and password
    try {
      callbackHandler.handle(callbacks);
      username = ((NameCallback)callbacks[0]).getName();
      char[] temp = ((PasswordCallback)callbacks[1]).getPassword();
      password = new char[temp.length];
      System.arraycopy(temp, 0, password, 0, temp.length);
      ((PasswordCallback)callbacks[1]).clearPassword();
    } catch (IOException ioe) {
      throw new LoginException(ioe.toString());
    } catch (UnsupportedCallbackException uce) {
      throw new LoginException(uce.toString());
    }
   
    System.out.println();
    String authresult ="";
    try {
        authresult = userAuth(username, password);
    } catch (IOException ex) {
        ex.printStackTrace();
    }
    if (! authresult.equals("failed")) {
        loginSuccess= true;
        clearPassword();
        try {
            updateCookie(authresult);
        } catch (IOException ex) {
            ex.printStackTrace();
        }
        return true;
    }
  
 
    loginSuccess = false;
    username = null;
    clearPassword();
    System.out.println( "Login: PasswordLoginModule FAIL" );
    throw new FailedLoginException();
 }
 

CookieAuth和userAuth方法都是利用apahce的httpclient工具包和遠程的SSOAuth進行http鏈接，獲取服務。

 private String cookieAuth(String cookievalue) throws IOException{
        String result = "failed";
       
        HttpClient httpclient = new HttpClient();      
        GetMethod httpget = new GetMethod(SSOServiceURL+Action1+cookievalue);
   
        try {
            httpclient.executeMethod(httpget);
            result = httpget.getResponseBodyAsString();
        } finally {
            httpget.releaseConnection();
        }
        return result;
    }
 
private String userAuth(String username, char[] password) throws IOException{
        String result = "failed";
        String passwd= new String(password);
        HttpClient httpclient = new HttpClient();      
        GetMethod httpget = new GetMethod(SSOServiceURL+Action2+username+"&password="+passwd);
        passwd = null;
   
        try {
            httpclient.executeMethod(httpget);
            result = httpget.getResponseBodyAsString();
        } finally {
            httpget.releaseConnection();
        }
        return result;
       
    }

還有一個地方須要補充說明的是，在本樣例中，用戶名和密碼的輸入都會在屏幕上顯示明文。若是但願用掩碼形式來顯示密碼，以提升安全性，請參考：http://java.sun.com/developer/technicalArticles/Security/pwordmask/

7  真正安全的全方位 SSO 解決方案： Kerberos

咱們的樣例程序（桌面SSO和WEB-SSO）都有一個共性：要想將一個應用集成到咱們的SSO解決方案中，或多或少的須要修改應用程序。Web應用須要配置一個咱們預製的filter；桌面應用須要加上咱們桌面SSO的JAAS模塊（至少要修改JAAS的配置文件）。但是有不少程序是沒有源代碼和沒法修改的，例如經常使用的遠程通信程序telnet和ftp等等一些操做系統本身帶的經常使用的應用程序。這些程序是很難修改加入到咱們的SSO的解決方案中。

事實上有一種全方位的SSO解決方案可以解決這些問題，這就是Kerberos協議（RFC 1510）。Kerberos是網絡安全應用標準( http://web.mit.edu/kerberos/)，由MIT學校發明，被主流的操做系統所採用。在採用kerberos的平臺中，登陸和認證是由操做系統自己來維護，認證的憑證也由操做系統來保存，這樣整個桌面均可以處於同一個SSO的系統保護中。操做系統中的各個應用（如ftp,telnet）只須要經過配置就能加入到SSO中。另外使用Kerberos最大的好處在於它的安全性。經過密鑰算法的保證和密鑰中心的創建，能夠作到用戶的密碼根本不須要在網絡中傳輸，而傳輸的信息也會十分的安全。

目前支持Kerberos的操做系統包括Solaris, windows,Linux等等主流的平臺。只不過要搭建一個Kerberos的環境比較複雜，KDC（密鑰分發中心）的創建也須要至關的步驟。Kerberos擁有很是成熟的API，包括Java的API。使用Java Generic Security Services(GSS) API而且使用JAAS中對Kerberos的支持（詳細信息請參見Sun的Java&Kerberos教程http://java.sun.com/ j2se/1.5.0/docs/guide/security/jgss/tutorials/index.html），要將咱們這個樣例改形成對Kerberos的支持也是不難的。 值得一提的是在JDK6.0 （http://www.java.net/download/jdk6）當中直接就包含了對GSS的支持，不須要單獨下載GSS的包。

 

8  總結

本文的主要目的是闡述SSO的基本原理，並提供了一種實現的方式。經過對源代碼的分析來掌握開發SSO服務的技術要點和充分理解SSO的應用範圍。可是，本文僅僅說明了身份認證的服務，而另一個和身份認證密不可分的服務----權限效驗，卻沒有提到。要開發出真正的SSO的產品，在功能上、性能上和安全上都必須有更加完備的考慮。