saml認證

Ⅰ 用java來實現單點登錄大概有哪些種方法

1 什麼是單點登陸
單點登錄（Single Sign On），簡稱為 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服務。

Ⅱ 公司已經有了AD/OPEN LDAP或者某個認證源，為什麼還需要單點登錄，比如yufuSSO

比如AD是一款20多年錢的老舊產品，無法和雲端應用對接，又比如Open LDAP/某認證源，專往往只支持saml協議，但是國內應屬用的介面五花八門，如果強行打通，就需要大量的介面二開工作，費用和時間長，而玉符SSO支持市面上所有的標准協議，也能提供超輕量級SDK給無介面應用，保客戶基本上無需二開和改造，就能實現對各類雲端和本地部署應用的單點登錄。
希望我的回答對你有幫助。

Ⅲ 電信SSO是什麼

尊敬的用戶您好：
SSO英文全稱Single Sign On，單點登錄。SSO是在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。它包括可以將這次主要的登錄映射到其他應用中用於同一個用戶的登錄的機制。它是目前比較流行的企業業務整合的解決方案之一。 SSO技術實現機制 當用戶第一次訪問應用系統1的時候，因為還沒有登錄，會被引導到認證系統中進行登錄；根據用戶提供的登錄信息，認證系統進行身份效驗，如果通過效驗，應該返回給用戶一個認證的憑據－－ticket；用戶再訪問別的應用的時候就會將這個ticket帶上，作為自己認證的憑據，應用系統接受到請求之後會把ticket送到認證系統進行效驗，檢查ticket的合法性。如果通過效驗，用戶就可以在不用再次登錄的情況下訪問應用系統2和應用系統3了。 要實現SSO，需要以下主要的功能： 1、所有應用系統共享一個身份認證系統。 統一的認證系統是SSO的前提之一。認證系統的主要功能是將用戶的登錄信息和用戶信息庫相比較，對用戶進行登錄認證；認證成功後，認證系統應該生成統一的認證標志（ticket），返還給用戶。另外，認證系統還應該對ticket進行效驗，判斷其有效性。 2、所有應用系統能夠識別和提取ticket信息 要實現SSO的功能，讓用戶只登錄一次，就必須讓應用系統能夠識別已經登錄過的用戶。應用系統應該能對ticket進行識別和提取，通過與認證系統的通訊，能自動判斷當前用戶是否登錄過，從而完成單點登錄的功能。 另外： 1、單一的用戶信息資料庫並不是必須的，有許多系統不能將所有的用戶信息都集中存儲，應該允許用戶信息放置在不同的存儲中，如下圖所示。事實上，只要統一認證系統，統一ticket的產生和效驗，無論用戶信息存儲在什麼地方，都能實現單點登錄。 2、統一的認證系統並不是說只有單個的認證伺服器 認證伺服器之間要通過標準的通訊協議，互相交換認證信息，就能完成更高級別的單點登錄。如：當用戶在訪問應用系統1時，由第一個認證伺服器進行認證後，得到由此伺服器產生的ticket。當他訪問應用系統2的時候，認證伺服器2能夠識別此ticket是由第一個伺服器產生的，通過認證伺服器之間標準的通訊協議（例如SAML）來交換認證信息，仍然能夠完成SSO的功能。 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應用，使得每個應用都通過這個統一的認證服務來進行身份效驗。

中國電信提供最優質的網路通訊服務，老友換新機，網齡抵現金，百兆寬頻免費體驗，超清電視iTV，電信活動可以直接通過營業廳查詢。

Ⅳ 單點登錄：公司已經有了AD/open ldap/某個認證源，為什麼還需要玉符

玉符能支持各類應用不受限制。

這些老舊的方案最大的問題就是適配性差內2，比如AD是一款容20年前的老舊產品，根本無法和雲端應用進行對接，又比如Open LDAP/某認證源，往往只能支持saml協議，但國內應用的介面五花八門，如果強行打通，就需要大量的介面二開工資，費用高時間長，而玉符SSO支持市面所有標准協議，也能提供超輕量級SDK給無介面應用，保證客戶基本無需改造和二開，就能實現對各類雲端和本地部署應用的單點登錄。

Ⅳ 兩個系統之間怎麼實現單點登錄

主要實現方式有：

1、 共享 cookies

基於共享同域的 cookie 是 Web 剛開始階段時使用的一種方式，它利用瀏覽同域名之間自動傳遞 cookies 機制，實現兩個域名之間系統令牌傳遞問題；另外，關於跨域問題，雖然 cookies本身不跨域，但可以利用它實現跨域的 SSO 。如：代理、暴露 SSO 令牌值等。

缺點：不靈活而且有不少安全隱患，已經被拋棄。

2、 Broker-based( 基於經紀人 )

這種技術的特點就是，有一個集中的認證和用戶帳號管理的伺服器。經紀人給被用於進一步請求的電子身份存取。中央資料庫的使用減少了管理的代價，並為認證提供一個公共和獨立的 "第三方 " 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight （憑證庫思想 ) 等。 Kerberos是由麻省理工大學發明的安全認證服務，已經被 UNIX 和 Windows 作為默認的安全認證服務集成進操作系統。

3、 Agent-based （基於代理人）

在這種解決方案中，有一個自動地為不同的應用程序認證用戶身份的代理程序。這個代理程序需要設計有不同的功能。比如，它可以使用口令表或加密密鑰來自動地將認證的負擔從用戶移開。代理人被放在伺服器上面，在伺服器的認證系統和客戶端認證方法之間充當一個 " 翻譯 "。例如 SSH 等。

4、 Token-based

例如 SecureID,WebID ，現在被廣泛使用的口令認證，比如 FTP 、郵件伺服器的登錄認證，這是一種簡單易用的方式，實現一個口令在多種應用當中使用。

5、 基於網關

6、 基於 SAML

SAML(Security Assertion Markup Language ，安全斷言標記語言）的出現大大簡化了 SSO ，並被 OASIS 批准為 SSO 的執行標准 。開源組織 OpenSAML 實現了 SAML 規范。

Ⅵ OAUTH，OPENID，SAML，CAS做統一認證與授權時有什麼區別

OpenID是Authentication
OAuth是Authorization

前者是網站對用戶進行認證，讓網站知道逗你是你所聲稱的URL的屬主地
後者其實並不包括認證，只不過逗只有認證成功的人才能進行授權地，結果類似於逗認證+授權地了。OAuth相當於：A網站給B網站一個令牌，然後告訴B網站說根據這個令牌你可以獲取到某用戶在A網站上允許你訪問的所有信息

如果A網站需要用B網站的用戶系統進行登錄（學名好像叫federated login），它可以

選擇OpenID認證，然後通過attribute exchange獲取用戶的昵稱或其他通過OpenID暴露出來的用戶屬性，或者
選擇OAuth認證，獲取到token後再用token獲取用戶昵稱或其他允許被訪問的信息

Ⅶ nginx cas單點登錄受影響嗎

1.1. What is CAS ？
CAS （ Central Authentication Service ） 是 Yale 大學發起的一個企業級的、開源的項目，旨在為 Web 應用系統提供一種可靠的單點登錄解決方法（屬於 Web SSO ）。
CAS 開始於 2001 年， 並在 2004 年 12 月正式成為 JA-SIG 的一個項目。
1.2. 主要特性
1、 開源的、多協議的 SSO 解決方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。
2、 支持多種認證機制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等；
3、 安全策略：使用票據（ Ticket ）來實現支持的認證協議；
4、 支持授權：可以決定哪些服務可以請求和驗證服務票據（ Service Ticket ）；
5、 提供高可用性：通過把認證過的狀態數據存儲在 TicketRegistry 組件中，這些組件有很多支持分布式環境的實現，如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等；
6、 支持多種客戶端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。

2. SSO 單點登錄原理
本文內容主要針對 Web SSO 。
2.1. 什麼是SSO
單點登錄（ Single Sign-On , 簡稱 SSO ）是目前比較流行的服務於企業業務整合的解決方案之一， SSO 使得在多個應用系統中，用戶只需要 登錄一次 就可以訪問所有相互信任的應用系統。
2.2. SSO 原理
2.2.1. SSO 體系中的角色
一般 SSO 體系主要角色有三種：
1、 User （多個）
2、 Web 應用（多個）
3、 SSO 認證中心（ 1 個 ）
2.2.2. SSO 實現模式的原則
SSO 實現模式一般包括以下三個原則：
1、 所有的認證登錄都在 SSO 認證中心進行；
2、 SSO 認證中心通過一些方法來告訴 Web 應用當前訪問用戶究竟是不是已通過認證的用戶；
3、 SSO 認證中心和所有的 Web 應用建立一種信任關系，也就是說 web 應用必須信任認證中心。（單點信任）
2.2.3. SSO 主要實現方式
SSO 的主要實現方式有：
1、 共享 cookies
基於共享同域的 cookie 是 Web 剛開始階段時使用的一種方式，它利用瀏覽同域名之間自動傳遞 cookies 機制，實現兩個域名之間系統令牌傳遞問題；另外，關於跨域問題，雖然 cookies 本身不跨域，但可以利用它實現跨域的 SSO 。如：代理、暴露 SSO 令牌值等。
缺點：不靈活而且有不少安全隱患，已經被拋棄。
2、 Broker-based( 基於經紀人 )
這種技術的特點就是，有一個集中的認證和用戶帳號管理的伺服器。經紀人給被用於進一步請求的電子身份存取。中央資料庫的使用減少了管理的代價，並為認證提供一個公共和獨立的 " 第三方 " 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight （憑證庫思想 ) 等。 Kerberos 是由麻省理工大學發明的安全認證服務，已經被 UNIX 和 Windows 作為默認的安全認證服務集成進操作系統。
3、 Agent-based （基於代理人）
在這種解決方案中，有一個自動地為不同的應用程序認證用戶身份的代理程序。這個代理程序需要設計有不同的功能。比如，它可以使用口令表或加密密鑰來自動地將認證的負擔從用戶移開。代理人被放在伺服器上面，在伺服器的認證系統和客戶端認證方法之間充當一個 " 翻譯 " 。例如 SSH 等。
4、 Token-based
例如 SecureID,WebID ，現在被廣泛使用的口令認證，比如 FTP 、郵件伺服器的登錄認證，這是一種簡單易用的方式，實現一個口令在多種應用當中使用。
5、 基於網關
6、 基於 SAML
SAML(Security Assertion Markup Language ，安全斷言標記語言）的出現大大簡化了 SSO ，並被 OASIS 批准為 SSO 的執行標准 。開源組織 OpenSAML 實現了 SAML 規范。

3. CAS 的基本原理
3.1. 結構體系
從結構體系看， CAS 包括兩部分： CAS Server 和 CAS Client 。
3.1.1. CAS Server
CAS Server 負責完成對用戶的認證工作 , 需要獨立部署 , CAS Server 會處理用戶名 / 密碼等憑證 (Credentials) 。
3.1.2. CAS Client
負責處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到 CAS Server 進行認證。（原則上，客戶端應用不再接受任何的用戶名密碼等 Credentials ）。
CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。
3.2. CAS 原理和協議
3.2.1. 基礎模式
基礎模式 SSO 訪問流程主要有以下步驟：
1. 訪問服務： SSO 客戶端發送請求訪問應用系統提供的服務資源。
2. 定向認證： SSO 客戶端會重定向用戶請求到 SSO 伺服器。
3. 用戶認證：用戶身份認證。
4. 發放票據： SSO 伺服器會產生一個隨機的 Service Ticket 。
5. 驗證票據： SSO 伺服器驗證票據 Service Ticket 的合法性，驗證通過後，允許客戶端訪問服務。
6. 傳輸用戶信息： SSO 伺服器驗證票據通過後，傳輸用戶認證結果信息給客戶端。
下面是 CAS 最基本的協議過程：

cas基礎協議圖
基礎協議圖

如上圖： CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護 Web 應用的受保護資源，過濾從客戶端過來的每一個 Web 請求，同時， CAS Client 會分析 HTTP 請求中是否包含請求 Service Ticket( ST 上圖中的 Ticket) ，如果沒有，則說明該用戶是沒有經過認證的；於是 CAS Client 會重定向用戶請求到 CAS Server （ Step 2 ），並傳遞 Service （要訪問的目的資源地址）。 Step 3 是用戶認證過程，如果用戶提供了正確的 Credentials ， CAS Server 隨機產生一個相當長度、唯一、不可偽造的 Service Ticket ，並緩存以待將來驗證，並且重定向用戶到 Service 所在地址（附帶剛才產生的 Service Ticket ） , 並為客戶端瀏覽器設置一個 Ticket Granted Cookie （ TGC ） ； CAS Client 在拿到 Service 和新產生的 Ticket 過後，在 Step 5 和 Step6 中與 CAS Server 進行身份核實，以確保 Service Ticket 的合法性。
在該協議中，所有與 CAS Server 的交互均採用 SSL 協議，以確保 ST 和 TGC 的安全性。協議工作過程中會有 2 次重定向 的過程。但是 CAS Client 與 CAS Server 之間進行 Ticket 驗證的過程對於用戶是透明的（使用 HttpsURLConnection ）。
CAS 請求認證時序圖如下：
cas認證時序圖
3.2.1. CAS 如何實現 SSO
當用戶訪問另一個應用的服務再次被重定向到 CAS Server 的時候， CAS Server 會主動獲到這個 TGC cookie ，然後做下面的事情：
1) 如果 User 持有 TGC 且其還沒失效，那麼就走基礎協議圖的 Step4 ，達到了 SSO 的效果；
2) 如果 TGC 失效，那麼用戶還是要重新認證 ( 走基礎協議圖的 Step3) 。

3.2.2. CAS 代理模式
該模式形式為用戶訪問 App1 ， App1 又依賴於 App2 來獲取一些信息，如： User -->App1 -->App2 。
這種情況下，假設 App2 也是需要對 User 進行身份驗證才能訪問，那麼，為了不影響用戶體驗（過多的重定向導致 User 的 IE 窗口不停地閃動 ) ， CAS 引入了一種 Proxy 認證機制，即 CAS Client 可以代理用戶去訪問其它 Web 應用。
代理的前提是需要 CAS Client 擁有用戶的身份信息 ( 類似憑據 ) 。之前我們提到的 TGC 是用戶持有對自己身份信息的一種憑據，這里的 PGT 就是 CAS Client 端持有的對用戶身份信息的一種憑據。憑借 TGC ， User 可以免去輸入密碼以獲取訪問其它服務的 Service Ticket ，所以，這里憑借 PGT ， Web 應用可以代理用戶去實現後端的認證，而 無需前端用戶的參與 。
下面為代理應用（ helloService ）獲取 PGT 的過程： （註： PGTURL 用於表示一個 Proxy 服務，是一個回調鏈接； PGT 相當於代理證； PGTIOU 為取代理證的鑰匙，用來與 PGT 做關聯關系；）
cas代理PGT獲取
如上面的 CAS Proxy 圖所示， CAS Client 在基礎協議之上，在驗證 ST 時提供了一個額外的 PGT URL( 而且是 SSL 的入口 ) 給 CAS Server ，使得 CAS Server 可以通過 PGT URL 提供一個 PGT 給 CAS Client 。
CAS Client 拿到了 PGT(PGTIOU-85 … ..ti2td) ，就可以通過 PGT 向後端 Web 應用進行認證。
下面是代理認證和提供服務的過程：

如上圖所示， Proxy 認證與普通的認證其實差別不大， Step1 ， 2 與基礎模式的 Step1,2 幾乎一樣，唯一不同的是， Proxy 模式用的是 PGT 而不是 TGC ，是 Proxy Ticket （ PT ）而不是 Service Ticket 。

3.2.3. 輔助說明
CAS 的 SSO 實現方式可簡化理解為： 1 個 Cookie 和 N 個 Session 。 CAS Server 創建 cookie ，在所有應用認證時使用，各應用通過創建各自的 Session 來標識用戶是否已登錄。
用戶在一個應用驗證通過後，以後用戶在同一瀏覽器里訪問此應用時，客戶端應用中的過濾器會在 session 里讀取到用戶信息，所以就不會去 CAS Server 認證。如果在此瀏覽器里訪問別的 web 應用時，客戶端應用中的過濾器在 session 里讀取不到用戶信息，就會去 CAS Server 的 login 介面認證，但這時 CAS Server 會讀取到瀏覽器傳來的 cookie （ TGC ），所以 CAS Server 不會要求用戶去登錄頁面登錄，只是會根據 service 參數生成一個 Ticket ，然後再和 web 應用做一個驗證 ticket 的交互而已。
3.3. 術語解釋
CAS 系統中設計了 5 中票據： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。
Ø Ticket-granting cookie(TGC) ：存放用戶身份認證憑證的 cookie ，在瀏覽器和 CAS Server 間通訊時使用，並且只能基於安全通道傳輸（ Https ），是 CAS Server 用來明確用戶身份的憑證；
Ø Service ticket(ST) ：服務票據，服務的惟一標識碼 , 由 CAS Server 發出（ Http 傳送），通過客戶端瀏覽器到達業務伺服器端；一個特定的服務只能有一個惟一的 ST ；
Ø Proxy-Granting ticket （ PGT ）：由 CAS Server 頒發給擁有 ST 憑證的服務， PGT 綁定一個用戶的特定服務，使其擁有向 CAS Server 申請，獲得 PT 的能力；
Ø Proxy-Granting Ticket I Owe You （ PGTIOU ） : 作用是將通過憑證校驗時的應答信息由 CAS Server 返回給 CAS Client ，同時，與該 PGTIOU 對應的 PGT 將通過回調鏈接傳給 Web 應用。 Web 應用負責維護 PGTIOU 與 PGT 之間映射關系的內容表；
Ø Proxy Ticket (PT) ：是應用程序代理用戶身份對目標程序進行訪問的憑證；

其它說明如下：
Ø Ticket Granting ticket(TGT) ：票據授權票據，由 KDC 的 AS 發放。即獲取這樣一張票據後，以後申請各種其他服務票據 (ST) 便不必再向 KDC 提交身份認證信息 (Credentials) ；
Ø Authentication service(AS) --------- 認證用服務，索取 Credentials ，發放 TGT ；
Ø Ticket-granting service (TGS) --------- 票據授權服務，索取 TGT ，發放 ST ；
Ø KDC( Key Distribution Center ) ---------- 密鑰發放中心；

4. CAS 安全性
CAS 的安全性僅僅依賴於 SSL 。使用的是 secure cookie 。
4.1. TGC/PGT 安全性
對於一個 CAS 用戶來說，最重要是要保護它的 TGC ，如果 TGC 不慎被 CAS Server 以外的實體獲得， Hacker 能夠找到該 TGC ，然後冒充 CAS 用戶訪問 所有 授權資源。 PGT 的角色跟 TGC 是一樣的。
從基礎模式可以看出， TGC 是 CAS Server 通過 SSL 方式發送給終端用戶，因此，要截取 TGC 難度非常大，從而確保 CAS 的安全性。
TGT 的存活周期默認為 120 分鍾。
4.2. ST/PT 安全性
ST （ Service Ticket ）是通過 Http 傳送的，因此網路中的其他人可以 Sniffer 到其他人的 Ticket 。 CAS 通過以下幾方面來使 ST 變得更加安全（事實上都是可以配置的）：
1、 ST 只能使用一次
CAS 協議規定，無論 Service Ticket 驗證是否成功， CAS Server 都會清除服務端緩存中的該 Ticket ，從而可以確保一個 Service Ticket 不被使用兩次。
2、 ST 在一段時間內失效
CAS 規定 ST 只能存活一定的時間，然後 CAS Server 會讓它失效。默認有效時間為 5 分鍾。
3、 ST 是基於隨機數生成的
ST 必須足夠隨機，如果 ST 生成規則被猜出， Hacker 就等於繞過 CAS 認證，直接訪問 對應的 服務。

5. 參考資料
1、 https://wiki.jasig.org/display/CASUM/Introction
2、 http://www.jasig.org/cas/protocol/
3、 http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html
4、 http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html
5、 http://ke..com/view/190743.htm