SSO單點登陸解決方案[轉載]

時間 2019-11-13

原文原文鏈接

http://www.blogjava.net/Jack2007/archive/2008/04/10/191795.htmlhtml

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

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

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

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

用戶天天平均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

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

提升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的功能，須要兩個部分的合做：跨域

統一的身份認證服務。
修改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 ut = 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的全部功能。服務器

若是用戶尚未登陸過，是第一次登陸本系統，會被跳轉到login.jsp頁面（在後面會解釋如何跳轉）。用戶在提供了用戶名和密碼之後，就會用handlerFromLogin()這個方法來驗證。
若是用戶已經登陸過本系統，再訪問別的應用的時候，是不須要再次登陸的。由於瀏覽器會將第一次登陸時產生的cookie和請求一塊兒發送。效驗cookie的有效性是SSOAuth的主要功能之一。
SSOAuth還能直接效驗非login.jsp頁面過來的用戶名和密碼的效驗請求。這個功能是用於非web應用的SSO，這在後面的桌面SSO中會用到。
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 ut = 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中所須要的功能。
      其餘的方法更加簡單，這裏就很少解釋了。cookie

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

再轉載點內容：

昨天和幾位朋友探討到了這個話題，發現雖然單點登陸，或者叫作獨立的passport登陸雖然已經有了不少實現方法，可是能真正瞭解並實現的人卻並不太多，因此些下此文，但願從原理到實現，能讓你們瞭解的多一些

至於什麼是單點登陸，舉個例子，若是你登陸了msn messenger，訪問hotmail郵件就不用在此登陸。
通常單點登陸都須要有一個獨立的登陸站點,通常具備獨立的域名，專門的進行註冊，登陸，註銷等操做

咱們爲了討論方便，把這個登陸站點叫作站點P，設其Url爲http://passport.yizhu2000.com，須要提供服務的站點設爲A和B，跨站點單點登陸是指你在A網站進行登陸後，使用B網站的服務就不須要再登陸

從技術角度講單點登陸分爲：

跨子域單點登陸
徹底跨單點域登陸

跨子域單點登陸

所謂跨子域登陸，A，B站點和P站點位於同一個域下面，好比A站點爲http://blog.yizhu2000.com B站點爲 http://forum.yizhu2000.com,他們和登陸站點P的關係能夠看到，都是屬於同一個父域，yizhu2000.com,不一樣的是子域不一樣，一個爲blog，一個爲forum，一個是passport

咱們先看看最經常使用的非跨站點普通登陸的狀況，通常登陸驗證經過後，通常會將你的用戶名和一些用戶信息，經過某一密鑰進行加密，寫在本地，也就是一個加密的cookie，咱們把這個cookie叫作--票（ticket）。

須要判斷用戶是否登陸的頁面，須要讀取這個ticket，並從其中解密出用戶信息，若是ticket不存在，或者沒法解密，意味着用戶沒有登陸，或者登陸信息不正確，這時就要跳轉到登陸頁面進行登陸，在這裏加密的做用有兩個，一是防止用戶信息被不懷好意者看到，二是保證ticket不會被僞造，後者其實更爲重要，加密後，各個應用須要採用與加密一樣的密鑰進行解密，若是不知道密鑰，就不能僞造出ticket，

（注：加密和解密的密鑰有可能不一樣，取決於採用什麼加密算法，若是是對稱加密，則爲同一密鑰，若是是非對稱，就不一樣了，通常用私鑰加密，公鑰解密，可是不管怎樣，密鑰都只有內部知道，這樣僞造者既沒法僞造也沒法解密ticket）

跨子域的單點登陸，和上述普通登陸的過程沒有什麼不一樣，惟一不一樣的是寫cookie時，因爲登陸站點P和應用A處於不一樣的子域，P站寫入的 cookie的域爲passport.yizhu2000.net，而A站點爲forum.yizhu2000.net，A在判斷用戶登陸時沒法讀到P站點的ticket

解決方法很是簡單，當Login完成後P站點寫ticket的時候，只需把cookie的域設爲他們共同的父域，yizhu2000.net就能夠了：cookie.domain="yizhu2000.net"，A站點天然就能夠讀到這個ticket了

ASP。Net的form驗證自己實現了這個機制，你們能夠參考http://blog.csdn.net/octverve/archive/2007/09/22/1796338.aspx

ASP.NET身份驗證信息跨域共享狀態

在ASP.NET 2.0 中只需修改web.config文件便可，修改方法以下:

domain指定了cookie保存的域，只要保存的是 abc.com形式或者.abc.com的形式，那麼其二級域名均可以共享此cookie。

此外，web.config標籤中的<sessionState >也作相應修改，mode改成StateServer或者SqlServer，那麼裏面的session信息也就所有能夠共享了。

StateServer須要在服務中開啓「asp.net狀態服務」的服務。

http://www.imneio.com/2007/11/17/aspnetnote1/，以上斜體內容摘自此連接

徹底跨單點域登陸

徹底跨域登陸，是指A，B站點和P站點沒有共同的父域，好比A站點爲forum.yizhu1999.net,B站點爲blog.yizhu1998.net，你們能夠參考微軟旗下的幾個站點http://www.live.com，www.hotmail.com,這兩個站點就沒有共同的父域，而仍然能夠共用登陸，怎樣才能實現呢？請參考下圖，因爲這種狀況ticket比較複雜，咱們暫時把P站點建立的的ticket叫作P-ticket，而A站點建立的ticket叫A-ticket，B的爲B-ticket

因爲站點A（forum.yizhu1999.com）不能讀取到由站點P（passport.yizhu2000.com）建立的加密 ticket，因此當用戶訪問A站點上須要登陸才能訪問的資源時，A站點會首先查看是否有A-ticket，若是沒有，證實用戶沒有在A站點登陸過，不過並不保證用戶沒有在B站點登陸，（重複一下，既然是單點登陸，固然不管你在A，B任意一個站點登陸過，另一個站點都要能夠訪問），請求會被重定向到p站點的驗證頁面，驗證頁面讀取P-ticket，若是沒有，或者解密不成功，就須要重定向登陸頁面，登陸頁面完成登陸後，寫一個加密cookie，也就是 P-ticket，而且重定向到A站點的登陸處理頁，並把加密的用戶信息做爲參數傳遞給這個頁面，這個頁面接收登陸頁的用戶信息，解密後也要寫一個 cookie，也就是A-ticket，從此用戶再次訪問A站點上須要登陸權限才能訪問的資源時，只須要檢查這個A-cookie是否存在就能夠了

當用戶訪問B站點時，會重複上面的過程，監測到沒有B-ticket，就會重定向到P站點的驗證頁面，去檢查P-ticket，若是沒有，就登陸，有則返回B的登陸處理頁面寫B-ticket

註銷的時候須要刪除P-ticket和A-ticket

怎麼刪除cookie：原本覺得這個不是問題，不過仍是有朋友問道，簡單的說實際上是建立一個和你要刪除的cookie同名的cookie，並把 cookie的expire設爲當前時間以前的某個時間，不過在跨子域的刪除cookie時有一點要注意：必需要把cookie的域設置爲父域，在本文中爲yizhu2000.com

爲了保證各個環節的傳輸的安全性，最好使用https鏈接