❶ java web應用如何實現單點登錄
單點登錄（Single Sign On），簡稱為 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。實現單點登錄需要兩個部分的合作：統一的身份認證服務和修改Web應用，使得每個應用都通過這個統一的認證服務來進行身份效驗。
❷ 用java來實現單點登錄大概有哪些種方法
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的功能，需要兩個部分的合作：
統一的身份認證服務。
修改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的產品上，它們完全是標準的和平台無關的應用。但是有一個限制，那兩台部署應用（demo1、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的主體部分：
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
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的所有功能
如果用戶還沒有登錄過，是第一次登錄本系統，會被跳轉到login.jsp頁面（在後面會解釋如何跳轉）。用戶在提供了用戶名和密碼以後，就會用handlerFromLogin()這個方法來驗證。
如果用戶已經登錄過本系統，再訪問別的應用的時候，是不需要再次登錄的。因為瀏覽器會將第一次登錄時產生的cookie和請求一起發送。效驗cookie的有效性是SSOAuth的主要功能之一。
SSOAuth還能直接效驗非login.jsp頁面過來的用戶名和密碼的效驗請求。這個功能是用於非web應用的SSO，這在後面的桌面SSO中會用到。
SSOAuth還提供logout服務。
❸ 談談單點登錄
寒假學習的小課題，把之前的筆記整理整理記錄一下（長文警告）因為當時看到的東西涉及很多，所以有一些地方沒有深入去探討。
網路：單點登錄（Single Sign On），簡稱為 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。
簡而言之就是用戶在多個相互信任的應用系統中，只需要登錄一次，就可以訪問其他相互信任的應用系統。這里的關鍵是一次登錄，以及一次退出，都對所有的系統生效。
在普通的登錄中，比如典型的B/S情景，瀏覽器訪問伺服器，發送登錄請求，在發送完用戶名和密碼之後，伺服器會生成該用戶的session來標准該用戶的狀態，比如已登錄還是已注銷，並給一個cookie給瀏覽器，因此，用戶繼續訪問就會帶上這個cookies，服務端會根據這個Cookie找到對應的session，通過session來判斷這個用戶的登錄狀態。比如php中使用phpsessid。當然也可以自定義session的生命周期，session的生命周期過長的話一旦session被盜用就會出現用戶被竊取的情況。同時，生命周期過長的session配置會佔用較多的伺服器資源。
單點登錄主要針對同平台下多應用，多系統的情景下多次登錄的一種解決方案。單點登錄相當於將多個應用的認證體系聯通。
假設現在一個平台上有3個都帶有登錄功能的應用，由上面的普通登錄的情況可以想到，這3台伺服器都會自己的記錄session。那麼要想達到單點登錄，一個最簡單的方法就出現了：共享session。
共享session的方式來實現單點登錄是最方便也是最直接的。在三個子系統中，使用同一個額外的記錄session的伺服器，比如我們可以使用一個redis伺服器來存儲三個系統的session。
用戶登錄了應用1，獲取了應用1返回的cookies，再次訪問應用1的其他功能的候攜帶了cookie就是已登錄的狀態了，但是這樣又有新的問題，雖然實現了共享session，但是用戶登錄了應用1，獲取了應用1返回的cookie，但是因為cookie是無法跨域的，因此用戶無法使用應用1的cookie去訪問應用2。這里我們就需要將系統的全局cookie domain的屬性設置為頂級域名，比如應用1的域名是1.test.com，應用2的域名是2.test.com。在普通登錄的情況下，應用1的cookie domain的屬性是1.test.com，指這個cookie只能在該子域名上被使用。我們將系統的全局cookie domain設置為頂級域名，即.test.com，這樣就可以實現用戶登錄了應用1，之後可以以已登錄狀態訪問應用2和3。
上面的共享session的情況是三個應用都有登錄功能，還有一種類似的情況是應用1和應用2都有登錄模塊和其他模塊，還有一個單獨的SSO系統，是僅有登錄模塊的：
共享session的方法雖然簡單，但是存在局限性，因為使用了cookie頂域的特性，所以不能做到跨域。一個公司或者一個平台很可能不是所有的域名都在在一個一級域名之下的，所以同域名下的單點登錄並不是完整的單點登錄。
先說說openid，openid是一種認證標准，規定如何認證的標准！即其關注的是登錄時身份的認證。官方給出的一個場景，其中一方是一個openid身份伺服器，用來存放注冊好的openid賬號，另一方是受這個openid身份伺服器信賴的服務或應用。openid協議就是提供openid身份伺服器和被信賴的服務或應用之間的通信的。比如我們在很多網站上可以使用QQ登錄，這里的騰訊的QQ就是openid的身份伺服器，我們所要登錄的網站就是受信賴的服務或應用。
在使用openid實現單點登錄的方法有很多，可以使用上面共享session的方法，即把openid帶在cookie裡面，但是這樣也會出現一樣的cookie跨域的問題。
在實際場景中，我們在訪問提供服務的應用時檢測到未登錄就會直接跳轉到openid身份伺服器，或者沒有重定向而是在登錄表單附近點擊選擇使用第三方openid登錄，進行賬號密碼登錄（這可以保證我們所登錄的伺服器無法獲取我們的敏感身份認證信息），具體流程如下：
CAS全稱為Central Authentication Service即中央認證服務，是一個企業多語言單點登錄的解決方案，並努力去成為一個身份驗證和授權需求的綜合平台。CAS就是一個現成的單點登錄的demo，企業只需要簡單修改就可使用。
CAS支持各種協議，SAML，OAuth，OpenID，OIDC等等，支持LDAP，Radius，JWTX，509等等進行身份認證和授權，還有各種常用語言的客戶端，Java，PHP，C# 等等。反正就是一個十分完整的，兼容性特別好的SSO框架。
簡單了解CAS是如何實現單點登錄的。在官網上可以看到其給出的一個 流程圖 ，。這個圖說的特別詳細，一下就能看懂，直接原圖上進行標注查看：
學習了上面幾種單點登錄的知識，結合實際場景可知，跨域單點登錄才是真正的單點登錄，因為實際情況下很多平台或者域名不可能都在一個一級域名下。在解決跨域單點登錄的問題的時候，上面也給說了幾種方式，但是究其根本，就是利用一個SSO認證中心來實現認證與授權的。當然，也會有其他的解決跨域單點登錄的方案，但是大體流程都與cas類似。
比如在上圖的11步驟，也可使用POST包，或者JSONP和iframe方法來跨域發送請求進行重定向。
在利用認證中心來實現單點登錄是現在比較普遍的解決方案，那麼有沒有不需要使用認證中心來解決跨域單點登錄的方案呢？
利用JSONP同步登錄狀態，大概流程流程如下：
在學習單點登錄的過程中，在其中認證的過程中授權令牌的傳遞等相關信息沒有特別詳細的說明，而且在思考單點登錄的時候也會有想過一個比較矛盾的問題：單點登錄的目標是為了讓用戶可以在相互信任的系統中一次登錄即可，但是如果真的是做到所有用戶都可以訪問所有系統，豈不是會帶來越權的問題，是否需要對不同的用戶以不同的授權，甚至限制訪問的應用，但是這樣是不是就不是原本狹義的單點認證？
在說單點登錄的認證和授權之前，先談一談我一直想弄清楚的統一身份認證和單點登錄的區別。說起單點登錄可能很少聽過，但是統一身份認證肯定不陌生，不管是企業還是高校都會有這種統一身份認證的系統。
統一身份認證最重要的一方面就是身份認證，另一方面就是和身份認證相關的授權控制，許可權控制。而單點登錄是多應用一次登錄，也可以叫統一登錄，可以理解為主要在認證方面。對於統一身份認證來說會有賬號管理，如LDAP，認證管理OAuth，SMAL等，因此我覺得，統一身份認證一般是包括狹義的單點登錄，狹義的單點登錄，即只需要滿足多應用一次登錄即可。但是現在的單點登錄，SSO系統並不僅僅是要求這些，他的范圍正在慢慢擴大。
單點登錄的認證和授權，前面說到的CAS實現單點登錄里就會看到需要ticket來進行認證，授權。CAS支持多種認證方案，比如OAuth，OpenID，SAML等等，我們可以來比較比較用這些協議的區別，或者說是在哪些場景下使用哪些認證方案較為合適。本身單點登錄是沒有許可權控制的功能的，但是因為這些認證協議的需求，自然支持了許可權控制。
在使用SAML進行認證的過程中，可以看到下圖，其是基本流程都差不多，這里需要注意的就是在用戶在認證中心成功登陸之後，重定向的時候返回的是一個SAML token，一個XML節點，這里的token會包括用戶的身份信息，用戶名等。
在OAuth2.0的標准中流程是和上面的基本相同，但是OAuth2因為客戶端並沒有一點是瀏覽器，所以token中默認是沒有簽名的。這里可能沒有體現出來，OAuth2的目標是授權，所以token更關注的是許可權，token在向認證伺服器驗證的時候就會有不同的授權，但是既然是授權，就間接實現了認證。
在傳統的認證中都是基於session機制的，具體的session模式上面也說了，根據其特性可知session的一些確定：
https://www.mutuallyhuman.com/blog/choosing-an-sso-strategy-saml-vs-oauth2/
https://yq.aliyun.com/articles/636281
https://juejin.im/post/5d0dbb7e6fb9a07f0420512d
❹ CAS單點登錄原理分析(一)
一，業務分析
在分布式系統架構中，假設把上述的三個子系統部署在三個不同的伺服器上。前提是用戶登錄之後才能訪問這些子系統。那麼使用傳統方式，可能會存在這樣的問題：
1.當訪問用戶中心，需要用戶登錄帳號
2.當訪問購物車，還需要用戶登錄帳號
3.當訪問商品結算，又一次需要用戶登錄帳號
訪問每一個子系統都需要用戶登錄帳號，這樣的體驗對於用戶來說是極差。而使用單點登錄就可以很好地解決上述的問題。
二，單點登錄
單點登錄（Single Sign On），簡稱為 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO 的定義是在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。
我們目前的系統存在諸多子系統，而這些子系統是分別部署在不同的伺服器中，那麼使用傳統方式的 session 是無法解決的，我們需要使用相關的單點登錄技術來解決。
第一步 ：用戶訪問應用系統1。過濾器判斷用戶是否登錄，沒有登錄，則重定向（302）到認證系統去進行認證操作。
第二步 ：重定向到認證系統，顯示登錄界面，用戶輸入用戶名密碼。認證系統將用戶登錄的信息記錄到伺服器的session中。
第三步 ：認證系統給瀏覽器發送一個特殊的憑證ticket，瀏覽器將憑證交給應用系統1，應用系統1則拿著瀏覽器交給他的憑證ticket去認證系統驗證憑證ticket是否有效。憑證ticket若是有效，將用戶信息保存到應用系統1的session中一份，並告知應用系統1，用戶通過認證。
第四步 ：用戶通過認證，瀏覽器與網站之間進行正常的訪問。
第五步 ：當用戶再次訪問應用系統1，由於應用系統1的session中有用戶信息，所以就不用經過認證系統認證，就可以直接訪問應用系統1了。
第六步 ：當用戶再去訪問其他應用系統時，瀏覽器會帶著憑證ticket過去，其他應用系統到認證系統驗證憑證，憑證ticket若是有效，將用戶信息保存到其他應用系統的session中一份，並告知其他應用系統，用戶通過認證。
第七步 ：用戶通過認證，瀏覽器與網站之間進行正常的訪問。
第八步 ：當用戶再次訪問其他應用系統，由於其他應用系統的session中有用戶信息，所以就不用經過認證系統認證，就可以直接訪問其他應用系統了。
三、Yelu大學研發的CAS(Central Authentication Server)
1.什麼是CAS？
CAS 是 Yale 大學發起的一個開源項目，旨在為 Web 應用系統提供一種可靠的單點登錄方法，CAS 在 2004 年 12 月正式成為 JA-SIG 的一個項目。CAS 具有以下特點：
【1】開源的企業級單點登錄解決方案。
【2】CAS Server 為需要獨立部署的 Web 應用。這個CAS框架已經提供
【3】CAS Client 支持非常多的客戶端(這里指單點登錄系統中的各個 Web 應用)，包括Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
從結構上看，CAS 包含兩個部分： CAS Server 和 CAS Client。CAS Server 需要獨立部署，主要負責對用戶的認證工作；CAS Client 負責處理對客戶端受保護資源的訪問請求，需要登錄時，重定向到 CAS Server。下圖是 CAS 最基本的協議過程：
2.CAS的詳細登錄流程
該圖主要描述
1.第一次訪問http://shopping.xiaogui.com
2.在登錄狀態下第二次訪問http://shopping.xiaogui.com
3.在登錄狀態下第一次訪問http://pay.xiaogui.com
下面對圖中序號代表的操作進行說明
當用戶第一次訪問http://shopping.xiaogui.com
序號1: 用戶請求http://shopping.xiaogui.com，會經過AuthenticationFilter認證過濾器(在cas client 的web.xml中配置)
主要作用：判斷是否登錄，如果沒有登錄則重定向到認證中心。
大概知道這個就行，CAS的具體實現會在以後的博客中寫道
序號2: AuthenticationFilter發現用戶沒有登錄，則返回瀏覽器重定向地址。
重定向的地址就是認證伺服器CAS Server的地址，後面的參數是我們請求的客戶端地址，這個參數目的就是為了認證成功以後，根據這個參數的地址重定向回請求的客戶端
序號3: 瀏覽器根據響應回來的重定向地址，向cas.xiaogui.com認證系統發出請求
序號4: 認證系統cas.xiaogui.com接收請求，響應登陸頁面
序號5: ：用戶登陸頁面輸入用戶名密碼，提交請求
序號6: ：CAS Server 認證伺服器接收用戶名和密碼，就行驗證，驗證邏輯CAS Server 已經實現，並響應給瀏覽器信息
這里的用戶名，密碼不需要關心，後續會講到
圖中1，2部分表示序號5 輸入的用戶名，密碼，以及發出的請求。當認證伺服器驗證通過之後，根據請求參數service的值，進行重定向，其實就是回到了請求的客戶端，同時會攜帶一個ticket令牌參數。同時會在Cookie中設置一個TGC，該cookie是網站認證系統cas.xiaogui.com的cookie，只有訪問這個網站才會攜帶這個cookie過去。
*****注意：這個攜帶TGC的Cookie是實現CAS單點登錄的關鍵所在！
Cookie中的TGC：向cookie中添加該值的目的是當下次訪問cas.xiaogui.com認證系統時，瀏覽器將Cookie中的TGC攜帶到伺服器，伺服器根據這個TGC，查找與之對應的TGT。從而判斷用戶是否登錄過了，是否需要展示登錄頁面。TGT與TGC的關系就像SESSION與Cookie中SESSIONID的關系。
TGT：Ticket Granted Ticket（俗稱大令牌，或者說票根，他可以簽發ST）
TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根據他可以找到TGT。
ST：Service Ticket （小令牌），是TGT生成的，默認是用一次就生效了。也就是上面數字3處的ticket值。
序號7: 客戶端拿到請求中的ticket信息，也就是圖中1的位置
然後經過一個ticket過濾器，去認證系統CAS Server判斷ticket是否有效
這個過濾器的主要工作就是校驗客戶端傳過來的ticket是否有效
CAS Client 客戶端 shopping.xiaogui.com 中web.xml的配置
序號8: 向CAS Server認證系統發出驗證ticket的請求，也就是圖中2的位置，然後執行ticket驗證
序號9: 通過校驗之後，把用戶信息保存到客戶端的session中，並把客戶端的SessionID設置在Cookie中，同時告知客戶端ticket有效。當用戶再次訪問該客戶端，就可以根據Cookie 中的SessionID找到客戶端的Session，獲取用戶信息，就不用再次進行驗證了。也就是圖中響應給瀏覽器的部分。
序號10: shopping.xiaogui.com客戶端接收到cas-server的返回，知道了用戶已經登錄，ticket有效，告知瀏覽器可以進行訪問。
至此，用戶第一次訪問流程結束。
當用戶第二次訪問http://shopping.xiaogui.com
序號11: 當用戶第二次訪問，仍然會經過AuthenticationFilter過濾器，但與第一次訪問不同的是此時客戶端session中已經存在用戶的信息，瀏覽器中的Cookie會根據SessionID找到Session，獲取用戶信息，所以不需要進行驗證，可以直接訪問。
序號12: 客戶端告知瀏覽器可以進行訪問。
當用戶第一次訪問http://pay.xiaogui.com
序號13: 用戶向pay.xiaogui.com CAS Client客戶端發出請求
序號14: ：pay.xiaogui.com接收到請求，發現第一次訪問，於是給他一個重定向的地址，讓他去找認證中心登錄。
序號15: 瀏覽器根據上面響應的地址，發起重定向，因為之前訪問過一次了，因此這次會攜帶上次返回的Cookie：TGC到認證中心。
序號16: 認證中心收到請求，發現TGC對應了一個TGT，於是用TGT簽發一個ticket，並且返回給瀏覽器，讓他重定向到pay.xiaogui.comCAS Client客戶端。
序號17: 根據上面響應回來的地址，進行重定向到pay.xiaogui.comCAS Client客戶端
序號18: pay.xiaogui.comCAS Client客戶端帶著ticket去認證中心驗證是否有效。
序號19: 認證成功，把用戶信息保存到客戶端的session中，並把客戶端的SessionID設置在Cookie中。當用戶下次訪問pay.xiaogui.comCAS Client客戶端，直接登錄，無需驗證。
序號20: 告知瀏覽器可以進行訪問
CAS單點登錄的原理分析大致就是上述的這些，至於CAS單點登錄的具體實現，將在下篇博客中寫道。
❺ 什麼是cas單點登錄
CAS是一個單點登錄框架，開始是由耶魯大學的一個組織開發，後來歸到apereo去管。 同時CAS也是開源，遵循著apache 2.0協議，代碼目前是在github上管理。單點登錄：Single Sign On,簡稱SSO，SSO使得在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。CAS 是 Yale 大學發起的一個開源項目，旨在為 Web 應用系統提供一種可靠的單點登錄方法，CAS 在 2004 年 12 月正式成為 JA-SIG 的一個項目。cas單點登錄目前國內玉符科技技術實力可以，可以考察，望採納！
❻ Java實現單點登錄（多域）
代碼不能帖給你 不好意思....
使用 CAS-server組件 一般的,單點登錄都是使用LDAP資料庫
我之前給學校做過一個基於SOA的校園統一管理構建 使用的就是這套配置 不錯呀不錯 呵呵~~
單點登錄的重點是:無論兩個網站地域和伺服器是否分離,只要他們伺服器上面都有你單點登錄伺服器上的證書存根即可... 所以不需要關心什麼域名之類的東西 只要證書存根在每個網站上 一切好說
你的思路有些問題:單點登錄並不是對網站cookies的傳遞 它是基於https的一種安全機制的東東 也就是ca證書 如果用cookies傳遞的話,你就會遇到跨網站時cookies共享問題,這是個思路死角