單點登錄java開源

A. java web應用如何實現單點登錄

• 實現方式一：父域 Cookie

• 實現方式二：認證中心

• 實現方式三：LocalStorage跨域

• 補充：域名分級

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

單點登錄（Single Sign On, SSO）是指在同一帳號平台下的多個應用系統中，用戶只需登錄一次，即可訪問所有相互信任的應用系統。舉例來說，網路貼吧和網路地圖是網路公司旗下的兩個不同的應用系統，如果用戶在網路貼吧登錄過之後，當他訪問網路地圖時無需再次登錄，那麼就說明網路貼吧和網路地圖之間實現了單點登錄。

單點登錄的本質就是在多個應用系統中共享登錄狀態。如果用戶的登錄狀態是記錄在 Session 中的，要實現共享登錄狀態，就要先共享 Session，比如可以將 Session 序列化到 Redis 中，讓多個應用系統共享同一個 Redis，直接讀取 Redis 來獲取 Session。

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

實現方式一：父域 Cookie

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

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

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

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

總結：此種實現方式比較簡單，但不支持跨主域名。

實現方式二：認證中心

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

用戶統一在認證中心進行登錄，登錄成功後，認證中心記錄用戶的登錄狀態，並將 Token 寫入 Cookie。（注意這個 Cookie 是認證中心的，應用系統是訪問不到的。）

應用系統檢查當前請求有沒有 Token，如果沒有，說明用戶在當前系統中尚未登錄，那麼就將頁面跳轉至認證中心。由於這個操作會將認證中心的 Cookie 自動帶過去，因此，認證中心能夠根據 Cookie 知道用戶是否已經登錄過了。如果認證中心發現用戶尚未登錄，則返回登錄頁面，等待用戶登錄，如果發現用戶已經登錄過了，就不會讓用戶再次登錄了，而是會跳轉回目標 URL ，並在跳轉前生成一個 Token，拼接在目標 URL 的後面，回傳給目標應用系統。

應用系統拿到 Token 之後，還需要向認證中心確認下 Token 的合法性，防止用戶偽造。確認無誤後，應用系統記錄用戶的登錄狀態，並將 Token 寫入 Cookie，然後給本次訪問放行。（注意這個 Cookie 是當前應用系統的，其他應用系統是訪問不到的。）當用戶再次訪問當前應用系統時，就會自動帶上這個 Token，應用系統驗證 Token 發現用戶已登錄，於是就不會有認證中心什麼事了。

這里順便介紹兩款認證中心的開源實現：

Apereo CAS 是一個企業級單點登錄系統，其中 CAS 的意思是」Central Authentication Service「。它最初是耶魯大學實驗室的項目，後來轉讓給了 JASIG 組織，項目更名為 JASIG CAS，後來該組織並入了Apereo 基金會，項目也隨之更名為 Apereo CAS。

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

總結：此種實現方式相對復雜，支持跨域，擴展性好，是單點登錄的標准做法。

實現方式三：LocalStorage 跨域

前面，我們說實現單點登錄的關鍵在於，如何讓 Session ID（或 Token）在多個域中共享。

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

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

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

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

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

版權聲明：本文為CSDN博主「風水道人」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。

原文鏈接：https://blog.csdn.net/jcmj123456/article/details/114296482

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

總結：此種實現方式完全由前端控制，幾乎不需要後端參與，同樣支持跨域。

補充：域名分級

從專業的角度來說（根據《計算機網路》中的定義），.com、.cn 為一級域名（也稱頂級域名），.com.cn、.com 為二級域名，sina.com.cn、tieba..com 為三級域名，以此類推，N 級域名就是 N-1 級域名的直接子域名。

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

B. JeeSpringCloud-互聯網雲快速開發框架

（一款免費開源的JAVA互聯網雲快速開發平台）微服務分布式代碼生成的敏捷開發系統架構。項目代碼簡潔,注釋豐富,上手容易,還同時集中分布式、微服務,同時包含許多基礎模塊和監控、服務模塊。

演示版地址：http://bknfdnl.hn3.mofasui.cn/admin/login

一、平台簡介

在線文檔：https://gitee.com/JeeHuangBingGui/jeeSpringCloud/wikis

視頻和文檔下載：https://gitee.com/JeeHuangBingGui/jeeSpringCloud/attach_files

開源中國地址：https://www.oschina.net/p/jeeSpringCloud

文檔視頻下載：https://gitee.com/JeeHuangBingGui/jeeSpringCloud/attach_files

JeeSpringCloudV3.0-互聯網雲快速開發框架模塊包含定時任務調度、伺服器監控、平台監控、異常郵件監控、伺服器Down機郵件監控、平台設置、開發平台、郵件監控、圖表監控、地圖監控、單點登錄、Redis分布式高速緩存、

ActiveMQ隊列、會員、營銷、在線用戶、日誌、在線人數、訪問次數、調用次數、直接集群、介面文檔、生成模塊、代碼實例、安裝視頻、教程文檔、bbo、springCloud、SpringBoot、mybatis、springmvc、IOC、AOP、定時任務、切面緩存、MVC、事務管理。

RedisMQ隊列、代碼生成(單表、主附表、樹表、列表和表單、增刪改查雲介面、redis高速緩存對接扒段旦代碼、圖表統計、地圖統計、vue.js)、工作流、模塊化

代碼生成前端控制項包括單行文本、富文本、下拉選項、復選框、日期選擇、文件上傳選擇、樹選擇控制項、單選按鈕、多行文本….。

二、平台功能

用戶管理：用戶是系統操作者，該功能主要完成系統用戶配置。

部門管理：配置系統組織機構（公司、部門、小組），樹結構展現支持數據許可權。

崗位管理：配置系統用戶所屬擔任職務。

菜單管理：配置系統菜單，操作許可權，按鈕許可權標識等。

角色管理：角色菜單許可權分配、設置角色按機構進行數據范圍許可權劃分。

字典管理：對系統中經常使用的一些較為固定的數據進行維護。

參數管理：對系統動態配置常用參數。

通知公告：系統通知公告信息發布維護。

操作日誌：系統正常操作日誌記錄和查詢；系統異常信息日誌記錄和查詢。

登錄日誌：系統登錄日誌記錄查詢包含登錄異常。

在線用戶：當前系統中活躍用戶狀態監控。

定時任務：在線（添加、修改、刪除)任務調度包含執行結果日誌。

代碼生成：前後端代碼生成(單表、主附表、樹表、列表和表單、增刪改查雲介面、redis高速緩存對接代碼、圖表統計、地圖統計、vue.js) ，並生成菜單和許可權直接使用。

系統介面：根據業務代碼自動生成相關的api介面文檔。

連接池監視：監視當期系統資料庫連接池狀態，可進行分析SQL找出系統性能瓶頸。

在線介面文檔：使用swager生成在線文檔。

ActiveMQ隊列:提供ActiveMQ隊列，處理批量發送大數據量郵件、大數據量日誌文件。

工作流：功能包括在線辦公、我的任務、審批測試、流程管理、模型管理。

CMS：功能包括內容管理、內容管理、統計分析、欄目設置、首頁。

bbo:代碼生成直接生成bbo對接代碼。

伺服器Down機郵件監控:通過定時任務監控伺服器是否Down機，並發送通知郵件。

伺服器監控:通過 sigar 進行伺服器圖形化監控。

異常郵件監控:全局攔截系統異常，並發送通知郵件。

單點登錄:使用shior和Redis、共享session方式實現單點登錄。

Redis分布式高速緩存:代碼生成直接生成Redis對接代碼。

三、系統截圖

JeeSpringCloudV3.0-互聯網雲快速開發框架春擾（後台燃者）

四、平台特性

JeeSpringCloud基於SpringBoot+SpringMVC+Mybatis+Redis+SpringCloud+Vue.js微服務分布式代碼生成的敏捷開發系統架構。項目代碼簡潔,注釋豐富,上手容易,還同時集中分布式、微服務,同時包含許多基礎模塊(用戶管理,角色管理,部門管理,字典管理等10個模塊。成為大眾認同、大眾參與、成就大眾、大眾分享的開發平台。JeeSpring官方qq群(328910546)。代碼生成前端界面、底層代碼（spring mvc、mybatis、Spring boot、Spring Cloud、微服務的生成）、安全框架、視圖框架、服務端驗證、任務調度、持久層框架、資料庫連接池、緩存框架、日誌管理、IM等核心技術。努力用心為大中小型企業打造全方位J2EE企業級平台ORM/Redis/Service倉庫開發解決方案。一個RepositoryService倉庫就直接實現bbo、微服務、基礎伺服器對接介面和實現。

努力用心為大中小型企業打造全方位J2EE企業級平台開發解決方案。

Spring Boot/Spring cloud微服務是利用雲平台開發企業應用程序的最新技術，它是小型、輕量和過程驅動的組件。微服務適合設計可擴展、易於維護的應用程序。它可以使開發更容易，還能使資源得到最佳利用。

微服務/集群(nignx) 支持REST風格遠程調用（HTTP + JSON/XML)：基於非常成熟的Spring Boot框架，在Spring Boot Spring Cloud中實現了REST風格（HTTP + JSON/XML）的遠程調用，以顯著簡化企業內部的跨語言交互，同時顯著簡化企業對外的Open API、無線API甚至AJAX服務端等等的開發。

事實上，這個REST調用也使得Dubbo可以對當今特別流行的「微服務」架構提供基礎性支持。 另外，REST調用也達到了比較高的性能，在基準測試下，HTTP + JSON默認的RPC協議（即TCP + Hessian2二進制序列化）之間只有1.5倍左右的差距，詳見下文的基準測試報告。

ORM/Redis/Service倉庫

RepositoryORM倉庫,提供ORM介面和多種實現,可進行配置實現。

RepositoryRedis倉庫,提供Redis介面和多種實現,可進行配置實現。可以配置調用單機、redis、雲redis對接。

RepositoryService倉庫,提供Service介面和多種實現,可進行配置實現。一個RepositoryService倉庫就直接實現bbo、微服務、基礎伺服器對接介面和實現。

五、架構說明

技術選型

六、代碼生成器

代碼生成器

七、開發入門

平台教程：https://gitee.com/JeeHuangBingGui/jeeSpringCloud/attach_files

官方提供：

1、詳細部署文檔。

2、部署視頻。

3、中級培訓視頻待定，包括代碼生成、架構代碼介紹。

4、高級培訓視頻待定，包括架構代碼詳解。

5、架構培訓視頻待定，包括架構詳解、代碼生成詳解。

平台教程：https://gitee.com/JeeHuangBingGui/jeeSpringCloud/attach_files

八、在線體驗

演示版地址：http://bknfdnl.hn3.mofasui.cn/admin/login

C. 「開源」springboot快速開發框架推薦，接私活利器

本期為大家精選了 碼雲 上優秀的 Spring Boot 語言開源項目，涵蓋了企業級系統框架、文件文檔系統、秒殺系統、微服務化系統、後台管理系統等，希望能夠給大家帶來一點幫助：）

1、項目名稱： 分布式敏捷開發系統架構

項目簡介： 基於 Spring + SpringMVC + Mybatis 分布式敏捷開發系統架構，提供整套公共微服務服務模塊：集中許可權管理（單點登錄）、內容管理、支付中心、用戶管理（支持第三方登錄）、微信平台、存儲系統、配置中心、日誌分析、任務和通知等，支持服務治理、監控和追蹤，努力為中小型企業打造全方位J2EE企業級開發解決方案。

項目地址：https://gitee.com/shuzheng/zheng2、

2、項目名稱： 模塊化開發系統

項目簡介： 以 SpringBoot 為中心，模塊化開發系統，用戶可以隨意刪減除許可權框架外 任意的系統模塊。復用，組裝性強主要應用技術：

項目地址： https://gitee.com/YYDeament/88ybg

3、項目名稱： JAVA 分布式快速開發平台

項目簡介： JAVA 分布式快速開發平台：SpringBoot，SpringMVC，Mybatis，mybatis-plus，motan/bbo分布式，Redis 緩存，Shiro 許可權管理，Spring-Session 單點登錄，Quartz 分布式集群調度，Restful 服務，QQ/微信登錄，App token 登錄，微信/支付寶支付；日期轉換、數據類型轉換、序列化、漢字轉拼音、身份證號碼驗證、數字轉人民幣、發送簡訊、發送郵件、加密解密、圖片處理、excel 導入導出、FTP/SFTP/fastDFS 上傳下載、二維碼、XML 讀寫、高精度計算、系統配置工具類等。

項目地址：https://gitee.com/iBase4J/iBase4J

4、項目名稱： 快速開發框架 ThinkGem

項目地址： https://gitee.com/thinkgem/jeesite

5、項目名稱： Java 快速開發平台 MCMS

項目簡介： 完整開源，Java 快速開發平台。基於 Spring、SpringMVC、Mybatis 架構，MStore 提供更多好用的插件與模板（文章、商城、微信、論壇、會員、評論、支付、積分、工作流、任務調度等，同時提供上百套免費模板任意選擇），價值源自分享！銘飛系統不僅一套簡單好用的開源系統、更是一整套優質的開源生態內容體系。

項目地址： https://gitee.com/mingSoft/MCMS

6、項目名稱： 分布式秒殺系統

項目簡介： 可能秒殺架構原理大家都懂，網上也有不少實現方式，但大多都是文字的描述，告訴你如何如何，什麼加鎖、緩存、隊列之類。但很少全面有的案例告訴你如何去做，既然是從0到1，希望以下代碼案例可以幫助到你。當然最終落實到生產，還有很長的路要走，要根據自己的業務進行編碼，實施並部署。你將會在代碼案例中學到以下知識：

項目地址： https://gitee.com/52itstyle/spring-boot-seckill

7、項目名稱： Spring Boot 快速開發平台

項目簡介： renren-fast 是一個輕量級的 Spring Boot 快速開發平台，其設計目標是開發迅速、學習簡單、輕量級、易擴展；使用 Spring Boot、Shiro、MyBatis、Redis、Bootstrap、Vue2.x 等框架，包含：管理員列表、角色管理、菜單管理、定時任務、參數管理、代碼生成器、日誌管理、雲存儲、API 模塊(APP 介面開發利器)、前後端分離等。

項目地址： https://gitee.com/bao/renren-fast

8、項目名稱： 企業級快速開發腳手架

項目簡介： 本項目是 spring boot 搭建的一個企業級快速開發腳手架。其技術棧如下所示：

項目地址： https://gitee.com/jamen/slife

9、項目名稱： 文件文檔在線預覽

項目簡介： 此項目為使用 spring boot 打造文件文檔在線預覽項目解決方案，對標業內付費產品有【永中office】【office365】【idocv】等，在取得公司高層同意後以Apache協議開源出來反哺社區，該項目使用流行的spring boot搭建，易上手和部署，基本支持主流辦公文檔的在線預覽，如 doc、docx、Excel、pdf、txt、zip、rar、圖片等等。

項目地址： https://gitee.com/kekingcn/file-online-preview

10、項目名稱： 微服務化開發平台

項目簡介： Cloud-Admin 是國內首個基於 Spring Cloud 微服務化開發平台，核心技術採用 Spring Boot2 以及 Spring Cloud Gateway 相關核心組件，前端採用 vue-element-admin 組件。具有統一授權、認證後台管理系統，其中包含具備用戶管理、資源許可權管理、網關 API 管理等多個模塊，支持多業務系統並行開發，可以作為後端服務的開發腳手架。代碼簡潔，架構清晰，適合學習和直接項目中使用。

項目地址： https://gitee.com/minull/ace-security

11、項目名稱： 後台管理系統 Guns

項目簡介： Guns 基於 SpringBoot，致力於做更簡潔的後台管理系統，完美整合 springmvc + shiro + mybatis-plus + beetl。Guns 項目代碼簡潔，注釋豐富，上手容易，同時 Guns 包含許多基礎模塊(用戶管理，角色管理，部門管理，字典管理等10個模塊)，可以直接作為一個後台管理系統的腳手架。Guns v3.0 新增 rest api 服務，提供對接服務端介面的支持，並利用 jwt token 鑒權機制給予客戶端的訪問許可權，傳輸數據進行 md5 簽名保證傳輸過程數據的安全性！

項目地址： https://gitee.com/naan1993/guns

D. 用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服務。

E. 單點登錄，java實現

可以直接通過玉符科技IDAAS平台來實現單點登錄，支持所有的標准協議，如果是老舊或者自研的系統，也有SDK去適配所有的開發語言，不止是java。

玉符單點登錄