關(guān)于javaWeb單點登錄

描述：在A系統(tǒng)登錄后，點擊A系統(tǒng)的某個模塊，登錄到B系統(tǒng)。

沂源網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián),沂源網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為沂源上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)公司要多少錢，請找那個售后服務(wù)好的沂源做網(wǎng)站的公司定做！

解決思路：在B系統(tǒng)的后臺代碼獲取B系統(tǒng)的用戶名和密碼，當點擊A系統(tǒng)的某個模塊時將用戶名和密碼通過url登錄到B系統(tǒng)。?描述：點擊A系統(tǒng)的退出按鈕，同時退出B系統(tǒng)；

解決思路： ?在A系統(tǒng)的帶有退出按鈕的jsp頁面，找到退出方法，將退出成功后執(zhí)行的方法改為退出B系統(tǒng)。?描述：找到B系統(tǒng)的登錄界面，通過js，執(zhí)行頁面加載完畢后執(zhí)行

解決方案：Window.onload=function 在執(zhí)行方法中執(zhí)行A系統(tǒng)的登錄接口，即可完成單點退出。

總結(jié)：A和B是兩個工程，那就讓A和B一個做客戶端，一個做服務(wù)端，服務(wù)端可以把服務(wù)發(fā)布出來，客戶端進行調(diào)用，就可以了啊，分布式開發(fā)。

java web應(yīng)用如何實現(xiàn)單點登錄

實現(xiàn)方式一：父域 Cookie

實現(xiàn)方式二：認證中心

實現(xiàn)方式三：LocalStorage?跨域

補充：域名分級

在 B/S 系統(tǒng)中，登錄功能通常都是基于 Cookie 來實現(xiàn)的。當用戶登錄成功后，一般會將登錄狀態(tài)記錄到 Session 中，或者是給用戶簽發(fā)一個 Token，無論哪一種方式，都需要在客戶端保存一些信息（Session ID 或 Token ），并要求客戶端在之后的每次請求中攜帶它們。在這樣的場景下，使用 Cookie 無疑是最方便的，因此我們一般都會將 Session 的 ID 或 Token 保存到 Cookie 中，當服務(wù)端收到請求后，通過驗證 Cookie 中的信息來判斷用戶是否登錄 。

單點登錄（Single Sign On, SSO）是指在同一帳號平臺下的多個應(yīng)用系統(tǒng)中，用戶只需登錄一次，即可訪問所有相互信任的應(yīng)用系統(tǒng)。舉例來說，百度貼吧和百度地圖是百度公司旗下的兩個不同的應(yīng)用系統(tǒng)，如果用戶在百度貼吧登錄過之后，當他訪問百度地圖時無需再次登錄，那么就說明百度貼吧和百度地圖之間實現(xiàn)了單點登錄。

單點登錄的本質(zhì)就是在多個應(yīng)用系統(tǒng)中共享登錄狀態(tài)。如果用戶的登錄狀態(tài)是記錄在 Session 中的，要實現(xiàn)共享登錄狀態(tài)，就要先共享 Session，比如可以將 Session 序列化到 Redis 中，讓多個應(yīng)用系統(tǒng)共享同一個 Redis，直接讀取 Redis 來獲取 Session。

當然僅此是不夠的，因為不同的應(yīng)用系統(tǒng)有著不同的域名，盡管 Session 共享了，但是由于 Session ID 是往往保存在瀏覽器 Cookie 中的，因此存在作用域的限制，無法跨域名傳遞，也就是說當用戶在 app1.com 中登錄后，Session ID 僅在瀏覽器訪問 app1.com 時才會自動在請求頭中攜帶，而當瀏覽器訪問 app2.com 時，Session ID 是不會被帶過去的。實現(xiàn)單點登錄的關(guān)鍵在于，如何讓 Session ID（或 Token）在多個域中共享。

實現(xiàn)方式一：父域 Cookie

在將具體實現(xiàn)之前，我們先來聊一聊 Cookie 的作用域。

Cookie 的作用域由 domain 屬性和 path 屬性共同決定。domain 屬性的有效值為當前域或其父域的域名/IP地址，在 Tomcat 中，domain 屬性默認為當前域的域名/IP地址。path 屬性的有效值是以“/”開頭的路徑，在 Tomcat 中，path 屬性默認為當前 Web 應(yīng)用的上下文路徑。

如果將 Cookie 的 domain 屬性設(shè)置為當前域的父域，那么就認為它是父域 Cookie。Cookie 有一個特點，即父域中的 Cookie 被子域所共享，換言之，子域會自動繼承父域中的Cookie。

利用 Cookie 的這個特點，不難想到，將 Session ID（或 Token）保存到父域中不就行了。沒錯，我們只需要將 Cookie 的 domain 屬性設(shè)置為父域的域名（主域名），同時將 Cookie 的 path 屬性設(shè)置為根路徑，這樣所有的子域應(yīng)用就都可以訪問到這個 Cookie 了。不過這要求應(yīng)用系統(tǒng)的域名需建立在一個共同的主域名之下，如 tieba.baidu.com 和 map.baidu.com，它們都建立在 baidu.com 這個主域名之下，那么它們就可以通過這種方式來實現(xiàn)單點登錄。

總結(jié)：此種實現(xiàn)方式比較簡單，但不支持跨主域名。

實現(xiàn)方式二：認證中心

我們可以部署一個認證中心，認證中心就是一個專門負責(zé)處理登錄請求的獨立的 Web 服務(wù)。

用戶統(tǒng)一在認證中心進行登錄，登錄成功后，認證中心記錄用戶的登錄狀態(tài)，并將 Token 寫入 Cookie。（注意這個 Cookie 是認證中心的，應(yīng)用系統(tǒng)是訪問不到的。）

應(yīng)用系統(tǒng)檢查當前請求有沒有 Token，如果沒有，說明用戶在當前系統(tǒng)中尚未登錄，那么就將頁面跳轉(zhuǎn)至認證中心。由于這個操作會將認證中心的 Cookie 自動帶過去，因此，認證中心能夠根據(jù) Cookie 知道用戶是否已經(jīng)登錄過了。如果認證中心發(fā)現(xiàn)用戶尚未登錄，則返回登錄頁面，等待用戶登錄，如果發(fā)現(xiàn)用戶已經(jīng)登錄過了，就不會讓用戶再次登錄了，而是會跳轉(zhuǎn)回目標 URL ，并在跳轉(zhuǎn)前生成一個 Token，拼接在目標 URL 的后面，回傳給目標應(yīng)用系統(tǒng)。

應(yīng)用系統(tǒng)拿到 Token 之后，還需要向認證中心確認下 Token 的合法性，防止用戶偽造。確認無誤后，應(yīng)用系統(tǒng)記錄用戶的登錄狀態(tài)，并將 Token 寫入 Cookie，然后給本次訪問放行。（注意這個 Cookie 是當前應(yīng)用系統(tǒng)的，其他應(yīng)用系統(tǒng)是訪問不到的。）當用戶再次訪問當前應(yīng)用系統(tǒng)時，就會自動帶上這個 Token，應(yīng)用系統(tǒng)驗證 Token 發(fā)現(xiàn)用戶已登錄，于是就不會有認證中心什么事了。

這里順便介紹兩款認證中心的開源實現(xiàn)：

Apereo CAS 是一個企業(yè)級單點登錄系統(tǒng)，其中 CAS 的意思是”Central Authentication Service“。它最初是耶魯大學(xué)實驗室的項目，后來轉(zhuǎn)讓給了 JASIG 組織，項目更名為 JASIG CAS，后來該組織并入了Apereo 基金會，項目也隨之更名為 Apereo CAS。

XXL-SSO 是一個簡易的單點登錄系統(tǒng)，由大眾點評工程師許雪里個人開發(fā)，代碼比較簡單，沒有做安全控制，因而不推薦直接應(yīng)用在項目中，這里列出來僅供參考。

總結(jié)：此種實現(xiàn)方式相對復(fù)雜，支持跨域，擴展性好，是單點登錄的標準做法。

實現(xiàn)方式三：LocalStorage 跨域

前面，我們說實現(xiàn)單點登錄的關(guān)鍵在于，如何讓 Session ID（或 Token）在多個域中共享。

父域 Cookie 確實是一種不錯的解決方案，但是不支持跨域。那么有沒有什么奇淫技巧能夠讓 Cookie 跨域傳遞呢？

很遺憾，瀏覽器對 Cookie 的跨域限制越來越嚴格。Chrome 瀏覽器還給 Cookie 新增了一個 SameSite 屬性，此舉幾乎禁止了一切跨域請求的 Cookie 傳遞（超鏈接除外），并且只有當使用 HTTPs 協(xié)議時，才有可能被允許在 AJAX 跨域請求中接受服務(wù)器傳來的 Cookie。

不過，在前后端分離的情況下，完全可以不使用 Cookie，我們可以選擇將 Session ID （或 Token ）保存到瀏覽器的 LocalStorage 中，讓前端在每次向后端發(fā)送請求時，主動將 LocalStorage 的數(shù)據(jù)傳遞給服務(wù)端。這些都是由前端來控制的，后端需要做的僅僅是在用戶登錄成功后，將 Session ID （或 Token ）放在響應(yīng)體中傳遞給前端。

在這樣的場景下，單點登錄完全可以在前端實現(xiàn)。前端拿到 Session ID （或 Token ）后，除了將它寫入自己的 LocalStorage 中之外，還可以通過特殊手段將它寫入多個其他域下的 LocalStorage 中。

————————————————

版權(quán)聲明：本文為CSDN博主「風(fēng)水道人」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。

原文鏈接：

前端通過 iframe+postMessage() 方式，將同一份 Token 寫入到了多個域下的 LocalStorage 中，前端每次在向后端發(fā)送請求之前，都會主動從 LocalStorage 中讀取 Token 并在請求中攜帶，這樣就實現(xiàn)了同一份 Token 被多個域所共享。

總結(jié)：此種實現(xiàn)方式完全由前端控制，幾乎不需要后端參與，同樣支持跨域。

補充：域名分級

從專業(yè)的角度來說（根據(jù)《計算機網(wǎng)絡(luò)》中的定義），.com、.cn 為一級域名（也稱頂級域名），.com.cn、baidu.com 為二級域名，sina.com.cn、tieba.baidu.com 為三級域名，以此類推，N 級域名就是 N-1 級域名的直接子域名。

從使用者的角度來說，一般把可支持獨立備案的主域名稱作一級域名，如 baidu.com、sina.com.cn 皆可稱作一級域名，在主域名下建立的直接子域名稱作二級域名，如 tieba.baidu.com 為二級域名。

單點登錄，java實現(xiàn)

可以直接通過玉符科技IDAAS平臺來實現(xiàn)單點登錄，支持所有的標準協(xié)議，如果是老舊或者自研的系統(tǒng)，也有SDK去適配所有的開發(fā)語言，不止是java。

玉符單點登錄

如何用java實現(xiàn)單點登錄，最好能有代碼

單點登陸的話,你可以使用token來實現(xiàn),比如一個用戶一次只生成一個token,這樣別人在訪問的時候,就會重新生成一個,之前的就會被踢出線

用java來實現(xiàn)單點登錄大概有哪些種方法

1 什么是單點登陸

單點登錄（Single Sign On），簡稱為 SSO，是目前比較流行的企業(yè)業(yè)務(wù)整合的解決方案之一。SSO的定義是在多個應(yīng)用系統(tǒng)中，用戶只需要登錄一次就可以訪問所有相互信任的應(yīng)用系統(tǒng)。

較大的企業(yè)內(nèi)部，一般都有很多的業(yè)務(wù)支持系統(tǒng)為其提供相應(yīng)的管理和IT服 務(wù)。例如財務(wù)系統(tǒng)為財務(wù)人員提供財務(wù)的管理、計算和報表服務(wù)；人事系統(tǒng)為人事部門提供全公司人員的維護服務(wù)；各種業(yè)務(wù)系統(tǒng)為公司內(nèi)部不同的業(yè)務(wù)提供不同的 服務(wù)等等。這些系統(tǒng)的目的都是讓計算機來進行復(fù)雜繁瑣的計算工作，來替代人力的手工勞動，提高工作效率和質(zhì)量。這些不同的系統(tǒng)往往是在不同的時期建設(shè)起來 的，運行在不同的平臺上；也許是由不同廠商開發(fā)，使用了各種不同的技術(shù)和標準。如果舉例說國內(nèi)一著名的IT公司（名字隱去），內(nèi)部共有60多個業(yè)務(wù)系統(tǒng)，這些系統(tǒng)包括兩個不同版本的SAP的ERP系統(tǒng)，12個不同類型和版本的數(shù)據(jù)庫系統(tǒng)，8個不同類型和版本的操作系統(tǒng)，以及使用了3種不同的防火墻技術(shù)，還有數(shù)十種互相不能兼容的協(xié)議和標準，你相信嗎？不要懷疑，這種情況其實非常普遍。每一個應(yīng)用系統(tǒng)在運行了數(shù)年以后，都會成為不可替換的企業(yè)IT架構(gòu)的一部分，如下圖所示。

隨 著企業(yè)的發(fā)展，業(yè)務(wù)系統(tǒng)的數(shù)量在不斷的增加，老的系統(tǒng)卻不能輕易的替換，這會帶來很多的開銷。其一是管理上的開銷，需要維護的系統(tǒng)越來越多。很多系統(tǒng)的數(shù) 據(jù)是相互冗余和重復(fù)的，數(shù)據(jù)的不一致性會給管理工作帶來很大的壓力。業(yè)務(wù)和業(yè)務(wù)之間的相關(guān)性也越來越大，例如公司的計費系統(tǒng)和財務(wù)系統(tǒng)，財務(wù)系統(tǒng)和人事系 統(tǒng)之間都不可避免的有著密切的關(guān)系。

為了降低管理的消耗，最大限度的重用已有投資的系統(tǒng)，很多企業(yè)都在進行著企業(yè)應(yīng)用集成（EAI）。 企業(yè)應(yīng)用集成可以在不同層面上進行：例如在數(shù)據(jù)存儲層面上的“數(shù)據(jù)大集中”，在傳輸層面上的“通用數(shù)據(jù)交換平臺”，在應(yīng)用層面上的“業(yè)務(wù)流程整合”，和用 戶界面上的“通用企業(yè)門戶”等等。事實上，還用一個層面上的集成變得越來越重要，那就是“身份認證”的整合，也就是“單點登錄”。

通常來說，每個單獨的系統(tǒng)都會有自己的安全體系和身份認證系統(tǒng)。整合以前，進入每個系統(tǒng)都需要進行登錄，這樣的局面不僅給管理上帶來了很大的困難，在安全方面也埋下了重大的隱患。下面是一些著名的調(diào)查公司顯示的統(tǒng)計數(shù)據(jù)：

用戶每天平均 16 分鐘花在身份驗證任務(wù)上 - 資料來源： IDS

頻繁的 IT 用戶平均有 21 個密碼 - 資料來源： NTA Monitor Password Survey

49% 的人寫下了其密碼，而 67% 的人很少改變它們

每 79 秒出現(xiàn)一起身份被竊事件 - 資料來源：National Small Business Travel Assoc

全球欺騙損失每年約 12B - 資料來源：Comm Fraud Control Assoc

到 2007 年，身份管理市場將成倍增長至 $4.5B - 資料來源：IDS

使用“單點登錄”整合后，只需要登錄一次就可以進入多個系統(tǒng)，而不需要重新登錄，這不僅僅帶來了更好的用戶體驗，更重要的是降低了安全的風(fēng)險和管理的消耗。請看下面的統(tǒng)計數(shù)據(jù)：

提高 IT 效率：對于每 1000 個受管用戶，每用戶可節(jié)省$70K

幫助臺呼叫減少至少1/3，對于 10K 員工的公司，每年可以節(jié)省每用戶 $75，或者合計 $648K

生產(chǎn)力提高：每個新員工可節(jié)省 $1K，每個老員工可節(jié)省 $350 ?資料來源：Giga

ROI 回報：7.5 到 13 個月 ?資料來源：Gartner

另外，使用“單點登錄”還是SOA時代的需求之一。在面向服務(wù)的架構(gòu)中，服務(wù)和服務(wù)之間，程序和程序之間的通訊大量存在，服務(wù)之間的安全認證是SOA應(yīng)用的難點之一，應(yīng)此建立“單點登錄”的系統(tǒng)體系能夠大大簡化SOA的安全問題，提高服務(wù)之間的合作效率。

2 單點登陸的技術(shù)實現(xiàn)機制

隨著SSO技術(shù)的流行，SSO的產(chǎn)品也是滿天飛揚。所有著名的軟件廠商都提供了相應(yīng)的解決方案。在這里我并不想介紹自己公司（Sun Microsystems）的產(chǎn)品，而是對SSO技術(shù)本身進行解析，并且提供自己開發(fā)這一類產(chǎn)品的方法和簡單演示。有關(guān)我寫這篇文章的目的，請參考我的博客（）。

單 點登錄的機制其實是比較簡單的，用一個現(xiàn)實中的例子做比較。頤和園是北京著名的旅游景點，也是我常去的地方。在頤和園內(nèi)部有許多獨立的景點，例如“蘇州 街”、“佛香閣”和“德和園”，都可以在各個景點門口單獨買票。很多游客需要游玩所有德景點，這種買票方式很不方便，需要在每個景點門口排隊買票，錢包拿 進拿出的，容易丟失，很不安全。于是絕大多數(shù)游客選擇在大門口買一張通票（也叫套票），就可以玩遍所有的景點而不需要重新再買票。他們只需要在每個景點門 口出示一下剛才買的套票就能夠被允許進入每個獨立的景點。

單點登錄的機制也一樣，如下圖所示，當用戶第一次訪問應(yīng)用系統(tǒng)1的時候，因為還沒有登錄，會被引導(dǎo)到認證系統(tǒng)中進行登錄（1）；根據(jù)用戶提供的登錄信息，認證系統(tǒng)進行身份效驗，如果通過效驗，應(yīng)該返回給用戶一個認證的憑據(jù)－－ticket（2）；用戶再訪問別的應(yīng)用的時候（3，5）就會將這個ticket帶上，作為自己認證的憑據(jù)，應(yīng)用系統(tǒng)接受到請求之后會把ticket送到認證系統(tǒng)進行效驗，檢查ticket的合法性（4，6）。如果通過效驗，用戶就可以在不用再次登錄的情況下訪問應(yīng)用系統(tǒng)2和應(yīng)用系統(tǒng)3了。

從上面的視圖可以看出，要實現(xiàn)SSO，需要以下主要的功能：

所有應(yīng)用系統(tǒng)共享一個身份認證系統(tǒng)。

統(tǒng)一的認證系統(tǒng)是SSO的前提之一。認證系統(tǒng)的主要功能是將用戶的登錄信息和用戶信息庫相比較，對用戶進行登錄認證；認證成功后，認證系統(tǒng)應(yīng)該生成統(tǒng)一的認證標志（ticket），返還給用戶。另外，認證系統(tǒng)還應(yīng)該對ticket進行效驗，判斷其有效性。

所有應(yīng)用系統(tǒng)能夠識別和提取ticket信息

要實現(xiàn)SSO的功能，讓用戶只登錄一次，就必須讓應(yīng)用系統(tǒng)能夠識別已經(jīng)登錄過的用戶。應(yīng)用系統(tǒng)應(yīng)該能對ticket進行識別和提取，通過與認證系統(tǒng)的通訊，能自動判斷當前用戶是否登錄過，從而完成單點登錄的功能。

上面的功能只是一個非常簡單的SSO架構(gòu)，在現(xiàn)實情況下的SSO有著更加復(fù)雜的結(jié)構(gòu)。有兩點需要指出的是：

單一的用戶信息數(shù)據(jù)庫并不是必須的，有許多系統(tǒng)不能將所有的用戶信息都集中存儲，應(yīng)該允許用戶信息放置在不同的存儲中，如下圖所示。事實上，只要統(tǒng)一認證系統(tǒng)，統(tǒng)一ticket的產(chǎn)生和效驗，無論用戶信息存儲在什么地方，都能實現(xiàn)單點登錄。

統(tǒng)一的認證系統(tǒng)并不是說只有單個的認證服務(wù)器，如下圖所示，整個系統(tǒng)可以存在兩個以上的認證服務(wù)器，這些服務(wù)器甚至可以是不同的產(chǎn)品。認證服務(wù)器之間要通過標準的通訊協(xié)議，互相交換認證信息，就能完成更高級別的單點登錄。如下圖，當用戶在訪問應(yīng)用系統(tǒng)1時，由第一個認證服務(wù)器進行認證后，得到由此服務(wù)器產(chǎn)生的ticket。當他訪問應(yīng)用系統(tǒng)4的時候，認證服務(wù)器2能夠識別此ticket是由第一個服務(wù)器產(chǎn)生的，通過認證服務(wù)器之間標準的通訊協(xié)議（例如SAML）來交換認證信息，仍然能夠完成SSO的功能。

3 WEB-SSO的實現(xiàn)

隨著互聯(lián)網(wǎng)的高速發(fā)展，WEB應(yīng)用幾乎統(tǒng)治了絕大部分的軟件應(yīng)用系統(tǒng)，因此WEB-SSO是SSO應(yīng)用當中最為流行。WEB-SSO有其自身的特點和優(yōu)勢，實現(xiàn)起來比較簡單易用。很多商業(yè)軟件和開源軟件都有對WEB-SSO的實現(xiàn)。其中值得一提的是OpenSSO （），為用Java實現(xiàn)WEB-SSO提供架構(gòu)指南和服務(wù)指南，為用戶自己來實現(xiàn)WEB-SSO提供了理論的依據(jù)和實現(xiàn)的方法。

為什么說WEB-SSO比較容易實現(xiàn)呢？這是有WEB應(yīng)用自身的特點決定的。

眾所周知，Web協(xié)議（也就是HTTP）是一個無狀態(tài)的協(xié)議。一個Web應(yīng)用由很多個Web頁面組成，每個頁面都有唯一的URL來定義。用戶在瀏覽器的地址欄輸入頁面的URL，瀏覽器就會向Web Server去發(fā)送請求。如下圖，瀏覽器向Web服務(wù)器發(fā)送了兩個請求，申請了兩個頁面。這兩個頁面的請求是分別使用了兩個單獨的HTTP連接。所謂無狀態(tài)的協(xié)議也就是表現(xiàn)在這里，瀏覽器和Web服務(wù)器會在第一個請求完成以后關(guān)閉連接通道，在第二個請求的時候重新建立連接。Web服務(wù)器并不區(qū)分哪個請求來自哪個客戶端，對所有的請求都一視同仁，都是單獨的連接。這樣的方式大大區(qū)別于傳統(tǒng)的（Client/Server）C/S結(jié)構(gòu),在那樣的應(yīng)用中，客戶端和服務(wù)器端會建立一個長時間的專用的連接通道。正是因為有了無狀態(tài)的特性，每個連接資源能夠很快被其他客戶端所重用，一臺Web服務(wù)器才能夠同時服務(wù)于成千上萬的客戶端。

但是我們通常的應(yīng)用是有狀態(tài)的。先不用提不同應(yīng)用之間的SSO，在同一個應(yīng)用中也需要保存用戶的登錄身份信息。例如用戶在訪問頁面1的時候進行了登錄，但是剛才也提到，客戶端的每個請求都是單獨的連接，當客戶再次訪問頁面2的時候，如何才能告訴Web服務(wù)器，客戶剛才已經(jīng)登錄過了呢？瀏覽器和服務(wù)器之間有約定：通過使用cookie技術(shù)來維護應(yīng)用的狀態(tài)。Cookie是可以被Web服務(wù)器設(shè)置的字符串，并且可以保存在瀏覽器中。如下圖所示，當瀏覽器訪問了頁面1時，web服務(wù)器設(shè)置了一個cookie，并將這個cookie和頁面1一起返回給瀏覽器，瀏覽器接到cookie之后，就會保存起來，在它訪問頁面2的時候會把這個cookie也帶上，Web服務(wù)器接到請求時也能讀出cookie的值，根據(jù)cookie值的內(nèi)容就可以判斷和恢復(fù)一些用戶的信息狀態(tài)。

Web-SSO完全可以利用Cookie結(jié)束來完成用戶登錄信息的保存，將瀏覽器中的Cookie和上文中的Ticket結(jié)合起來，完成SSO的功能。

為了完成一個簡單的SSO的功能，需要兩個部分的合作：

統(tǒng)一的身份認證服務(wù)。

修改Web應(yīng)用，使得每個應(yīng)用都通過這個統(tǒng)一的認證服務(wù)來進行身份效驗。

3.1 Web SSO 的樣例

根據(jù)上面的原理，我用J2EE的技術(shù)（JSP和Servlet）完成了一個具有Web-SSO的簡單樣例。樣例包含一個身份認證的服務(wù)器和兩個簡單的Web應(yīng)用，使得這兩個 Web應(yīng)用通過統(tǒng)一的身份認證服務(wù)來完成Web-SSO的功能。此樣例所有的源代碼和二進制代碼都可以從網(wǎng)站地址 下載。

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

Web-SSO的樣例是由三個標準Web應(yīng)用組成，壓縮成三個zip文件，從中下載。其中SSOAuth（）是身份認證服務(wù)；SSOWebDemo1（）和SSOWebDemo2（）是兩個用來演示單點登錄的Web應(yīng)用。這三個Web應(yīng)用之所以沒有打成war包，是因為它們不能直接部署，根據(jù)讀者的部署環(huán)境需要作出小小的修改。樣例部署和運行的環(huán)境有一定的要求，需要符合Servlet2.3以上標準的J2EE容器才能運行（例如Tomcat5,Sun Application Server 8, Jboss 4等）。另外，身份認證服務(wù)需要JDK1.5的運行環(huán)境。之所以要用JDK1.5是因為筆者使用了一個線程安全的高性能的Java集合類“ConcurrentMap”，只有在JDK1.5中才有。

這三個Web應(yīng)用完全可以單獨部署，它們可以分別部署在不同的機器，不同的操作系統(tǒng)和不同的J2EE的產(chǎn)品上，它們完全是標準的和平臺無關(guān)的應(yīng)用。但是有一個限制，那兩臺部署應(yīng)用（demo1、demo2）的機器的域名需要相同，這在后面的章節(jié)中會解釋到cookie和domain的關(guān)系以及如何制作跨域的WEB-SSO

解壓縮SSOAuth.zip文件，在/WEB-INF/下的web.xml中請修改“domainname”的屬性以反映實際的應(yīng)用部署情況，domainname需要設(shè)置為兩個單點登錄的應(yīng)用（demo1和demo2）所屬的域名。這個domainname和當前SSOAuth服務(wù)部署的機器的域名沒有關(guān)系。我缺省設(shè)置的是“.sun.com”。如果你部署demo1和demo2的機器沒有域名，請輸入IP地址或主機名（如localhost），但是如果使用IP地址或主機名也就意味著demo1和demo2需要部署到一臺機器上了。設(shè)置完后，根據(jù)你所選擇的J2EE容器，可能需要將SSOAuth這個目錄壓縮打包成war文件。用“jar -cvf SSOAuth.war SSOAuth/”就可以完成這個功能。

解壓縮SSOWebDemo1和SSOWebDemo2文件，分別在它們/WEB-INF/下找到web.xml文件，請修改其中的幾個初始化參數(shù)

init-param

param-nameSSOServiceURL/param-name

param-value;/param-value

/init-param

init-param

param-nameSSOLoginPage/param-name

param-value;/param-value

/init-param

將其中的SSOServiceURL和SSOLoginPage修改成部署SSOAuth應(yīng)用的機器名、端口號以及根路徑（缺省是SSOAuth）以反映實際的部署情況。設(shè)置完后，根據(jù)你所選擇的J2EE容器，可能需要將SSOWebDemo1和SSOWebDemo2這兩個目錄壓縮打包成兩個war文件。用“jar -cvf SSOWebDemo1.war SSOWebDemo1/”就可以完成這個功能。

請輸入第一個web應(yīng)用的測試URL（test.jsp）,例如 SSOWebDemo1/test.jsp，如果是第一次訪問，便會自動跳轉(zhuǎn)到登錄界面，如下圖

使用系統(tǒng)自帶的三個帳號之一登錄（例如，用戶名：wangyu,密碼：wangyu），便能成功的看到test.jsp的內(nèi)容：顯示當前用戶名和歡迎信息。

請接著在同一個瀏覽器中輸入第二個web應(yīng)用的測試URL（test.jsp）,例如 SSOWebDemo2/test.jsp。你會發(fā)現(xiàn)，不需要再次登錄就能看到test.jsp的內(nèi)容，同樣是顯示當前用戶名和歡迎信息，而且歡迎信息中明確的顯示當前的應(yīng)用名稱（demo2）。

3.2 WEB-SSO代碼講解

3.2.1身份認證服務(wù)代碼解析

Web-SSO的源代碼可以從網(wǎng)站地址下載。身份認證服務(wù)是一個標準的web應(yīng)用，包括一個名為SSOAuth的Servlet，一個login.jsp文件和一個failed.html。身份認證的所有服務(wù)幾乎都由SSOAuth的Servlet來實現(xiàn)了；login.jsp用來顯示登錄的頁面（如果發(fā)現(xiàn)用戶還沒有登錄過）；failed.html是用來顯示登錄失敗的信息（如果用戶的用戶名和密碼與信息數(shù)據(jù)庫中的不一樣）。

SSOAuth的代碼如下面的列表顯示，結(jié)構(gòu)非常簡單，先看看這個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。其中有兩個靜態(tài)成員變量：accounts和SSOIDs，這兩個成員變量都使用了JDK1.5中線程安全的MAP類： ConcurrentMap，所以這個樣例一定要JDK1.5才能運行。Accounts用來存放用戶的用戶名和密碼，在init()的方法中可以看到我給系統(tǒng)添加了三個合法的用戶。在實際應(yīng)用中，accounts應(yīng)該是去數(shù)據(jù)庫中或LDAP中獲得，為了簡單起見，在本樣例中我使用了ConcurrentMap在內(nèi)存中用程序創(chuàng)建了三個用戶。而SSOIDs保存了在用戶成功的登錄后所產(chǎn)生的cookie和用戶名的對應(yīng)關(guān)系。它的功能顯而易見：當用戶成功登錄以后，再次訪問別的系統(tǒng)，為了鑒別這個用戶請求所帶的cookie的有效性，需要到SSOIDs中檢查這樣的映射關(guān)系是否存在。

在主要的請求處理方法processRequest()中，可以很清楚的看到SSOAuth的所有功能

如果用戶還沒有登錄過，是第一次登錄本系統(tǒng)，會被跳轉(zhuǎn)到login.jsp頁面（在后面會解釋如何跳轉(zhuǎn)）。用戶在提供了用戶名和密碼以后，就會用handlerFromLogin()這個方法來驗證。

如果用戶已經(jīng)登錄過本系統(tǒng)，再訪問別的應(yīng)用的時候，是不需要再次登錄的。因為瀏覽器會將第一次登錄時產(chǎn)生的cookie和請求一起發(fā)送。效驗cookie的有效性是SSOAuth的主要功能之一。

SSOAuth還能直接效驗非login.jsp頁面過來的用戶名和密碼的效驗請求。這個功能是用于非web應(yīng)用的SSO，這在后面的桌面SSO中會用到。

SSOAuth還提供logout服務(wù)。

Java實現(xiàn)單點登錄（多域）

代碼不能帖給你 不好意思....

使用 CAS-server組件 一般的,單點登錄都是使用LDAP數(shù)據(jù)庫

我之前給學(xué)校做過一個基于SOA的校園統(tǒng)一管理構(gòu)建 使用的就是這套配置 不錯呀不錯 呵呵~~

單點登錄的重點是:無論兩個網(wǎng)站地域和服務(wù)器是否分離,只要他們服務(wù)器上面都有你單點登錄服務(wù)器上的證書存根即可... 所以不需要關(guān)心什么域名之類的東西 只要證書存根在每個網(wǎng)站上 一切好說

你的思路有些問題:單點登錄并不是對網(wǎng)站cookies的傳遞 它是基于https的一種安全機制的東東 也就是ca證書 如果用cookies傳遞的話,你就會遇到跨網(wǎng)站時cookies共享問題,這是個思路死角

網(wǎng)站欄目：單點登錄java代碼實現(xiàn),java單點登錄主流技術(shù)
文章轉(zhuǎn)載：http://chinadenli.net/article4/hsgcoe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機、移動網(wǎng)站建設(shè)、電子商務(wù)、做網(wǎng)站、云服務(wù)器、關(guān)鍵詞優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)