SSO單點登入原理和簡單實現
1、http無狀態協議
web應用採用browser/server架構,http作為通訊協議。http是無狀態協議,瀏覽器的每一次請求,伺服器會獨立處理,不與之前或之後的請求產生關聯,這個過程用下圖說明,三次請求/響應對之間沒有任何聯絡
但這也同時意味著,任何使用者都能通過瀏覽器訪問伺服器資源,如果想保護伺服器的某些資源,必須限制瀏覽器請求;要限制瀏覽器請求,必須鑑別瀏覽器請求,響應合法請求,忽略非法請求;要鑑別瀏覽器請求,必須清楚瀏覽器請求狀態。既然http協議無狀態,那就讓伺服器和瀏覽器共同維護一個狀態吧!這就是會話機制
2、會話機制
瀏覽器第一次請求伺服器,伺服器建立一個會話,並將會話的id作為響應的一部分發送給瀏覽器,瀏覽器儲存會話id,並在後續第二次和第三次請求中帶上會話id,伺服器取得請求中的會話id就知道是不是同一個使用者了,這個過程用下圖說明,後續請求與第一次請求產生了關聯
伺服器在記憶體中儲存會話物件,瀏覽器怎麼儲存會話id呢?你可能會想到兩種方式
- 請求引數
- cookie
將會話id作為每一個請求的引數,伺服器接收請求自然能解析引數獲得會話id,並藉此判斷是否來自同一會話,很明顯,這種方式不靠譜。那就瀏覽器自己來維護這個會話id吧,每次傳送http請求時瀏覽器自動傳送會話id,cookie機制正好用來做這件事。cookie是瀏覽器用來儲存少量資料的一種機制,資料以”key/value“形式儲存,瀏覽器傳送http請求時自動附帶cookie資訊
tomcat會話機制當然也實現了cookie,訪問tomcat伺服器時,瀏覽器中可以看到一個名為“JSESSIONID”的cookie,這就是tomcat會話機制維護的會話id,使用了cookie的請求響應過程如下圖
3、登入狀態
有了會話機制,登入狀態就好明白了,我們假設瀏覽器第一次請求伺服器需要輸入使用者名稱與密碼驗證身份,伺服器拿到使用者名稱密碼去資料庫比對,正確的話說明當前持有這個會話的使用者是合法使用者,應該將這個會話標記為“已授權”或者“已登入”等等之類的狀態,既然是會話的狀態,自然要儲存在會話物件中,tomcat在會話物件中設定登入狀態如下
1 2 |
HttpSession session = request.getSession();
session.setAttribute( "isLogin" ,
true );
|
使用者再次訪問時,tomcat在會話物件中檢視登入狀態
1 2 |
HttpSession session = request.getSession();
session.getAttribute( "isLogin" );
|
實現了登入狀態的瀏覽器請求伺服器模型如下圖描述
每次請求受保護資源時都會檢查會話物件中的登入狀態,只有 isLogin=true 的會話才能訪問,登入機制因此而實現。
二、多系統的複雜性
web系統早已從久遠的單系統發展成為如今由多系統組成的應用群,面對如此眾多的系統,使用者難道要一個一個登入、然後一個一個登出嗎?就像下圖描述的這樣
web系統由單系統發展成多系統組成的應用群,複雜性應該由系統內部承擔,而不是使用者。無論web系統內部多麼複雜,對使用者而言,都是一個統一的整體,也就是說,使用者訪問web系統的整個應用群與訪問單個系統一樣,登入/登出只要一次就夠了
雖然單系統的登入解決方案很完美,但對於多系統應用群已經不再適用了,為什麼呢?
單系統登入解決方案的核心是cookie,cookie攜帶會話id在瀏覽器與伺服器之間維護會話狀態。但cookie是有限制的,這個限制就是cookie的域(通常對應網站的域名),瀏覽器傳送http請求時會自動攜帶與該域匹配的cookie,而不是所有cookie
既然這樣,為什麼不將web應用群中所有子系統的域名統一在一個頂級域名下,例如“*.baidu.com”,然後將它們的cookie域設定為“baidu.com”,這種做法理論上是可以的,甚至早期很多多系統登入就採用這種同域名共享cookie的方式。
然而,可行並不代表好,共享cookie的方式存在眾多侷限。首先,應用群域名得統一;其次,應用群各系統使用的技術(至少是web伺服器)要相同,不然cookie的key值(tomcat為JSESSIONID)不同,無法維持會話,共享cookie的方式是無法實現跨語言技術平臺登入的,比如java、php、.net系統之間;第三,cookie本身不安全。
因此,我們需要一種全新的登入方式來實現多系統應用群的登入,這就是單點登入
三、單點登入
什麼是單點登入?單點登入全稱Single Sign On(以下簡稱SSO),是指在多系統應用群中登入一個系統,便可在其他所有系統中得到授權而無需再次登入,包括單點登入與單點登出兩部分
1、登入
相比於單系統登入,sso需要一個獨立的認證中心,只有認證中心能接受使用者的使用者名稱密碼等安全資訊,其他系統不提供登入入口,只接受認證中心的間接授權。間接授權通過令牌實現,sso認證中心驗證使用者的使用者名稱密碼沒問題,建立授權令牌,在接下來的跳轉過程中,授權令牌作為引數傳送給各個子系統,子系統拿到令牌,即得到了授權,可以藉此建立區域性會話,區域性會話登入方式與單系統的登入方式相同。這個過程,也就是單點登入的原理,用下圖說明
下面對上圖簡要描述
- 使用者訪問系統1的受保護資源,系統1發現使用者未登入,跳轉至sso認證中心,並將自己的地址作為引數
- sso認證中心發現使用者未登入,將使用者引導至登入頁面
- 使用者輸入使用者名稱密碼提交登入申請
- sso認證中心校驗使用者資訊,建立使用者與sso認證中心之間的會話,稱為全域性會話,同時建立授權令牌
- sso認證中心帶著令牌跳轉會最初的請求地址(系統1)
- 系統1拿到令牌,去sso認證中心校驗令牌是否有效
- sso認證中心校驗令牌,返回有效,註冊系統1
- 系統1使用該令牌建立與使用者的會話,稱為區域性會話,返回受保護資源
- 使用者訪問系統2的受保護資源
- 系統2發現使用者未登入,跳轉至sso認證中心,並將自己的地址作為引數
- sso認證中心發現使用者已登入,跳轉回系統2的地址,並附上令牌
- 系統2拿到令牌,去sso認證中心校驗令牌是否有效
- sso認證中心校驗令牌,返回有效,註冊系統2
- 系統2使用該令牌建立與使用者的區域性會話,返回受保護資源
使用者登入成功之後,會與sso認證中心及各個子系統建立會話,使用者與sso認證中心建立的會話稱為全域性會話,使用者與各個子系統建立的會話稱為區域性會話,區域性會話建立之後,使用者訪問子系統受保護資源將不再通過sso認證中心,全域性會話與區域性會話有如下約束關係
- 區域性會話存在,全域性會話一定存在
- 全域性會話存在,區域性會話不一定存在
- 全域性會話銷燬,區域性會話必須銷燬
你可以通過部落格園、百度、csdn、淘寶等網站的登入過程加深對單點登入的理解,注意觀察登入過程中的跳轉url與引數
2、登出
單點登入自然也要單點登出,在一個子系統中登出,所有子系統的會話都將被銷燬,用下面的圖來說明
sso認證中心一直監聽全域性會話的狀態,一旦全域性會話銷燬,監聽器將通知所有註冊系統執行登出操作
下面對上圖簡要說明
- 使用者向系統1發起登出請求
- 系統1根據使用者與系統1建立的會話id拿到令牌,向sso認證中心發起登出請求
- sso認證中心校驗令牌有效,銷燬全域性會話,同時取出所有用此令牌註冊的系統地址
- sso認證中心向所有註冊系統發起登出請求
- 各註冊系統接收sso認證中心的登出請求,銷燬區域性會話
- sso認證中心引導使用者至登入頁面
四、部署圖
單點登入涉及sso認證中心與眾子系統,子系統與sso認證中心需要通訊以交換令牌、校驗令牌及發起登出請求,因而子系統必須整合sso的客戶端,sso認證中心則是sso服務端,整個單點登入過程實質是sso客戶端與服務端通訊的過程,用下圖描述
sso認證中心與sso客戶端通訊方式有多種,這裡以簡單好用的httpClient為例,web service、rpc、restful api都可以
五、實現
只是簡要介紹下基於java的實現過程,不提供完整原始碼,明白了原理,我相信你們可以自己實現。sso採用客戶端/服務端架構,我們先看sso-client與sso-server要實現的功能(下面:sso認證中心=sso-server)
sso-client
- 攔截子系統未登入使用者請求,跳轉至sso認證中心
- 接收並存儲sso認證中心傳送的令牌
- 與sso-server通訊,校驗令牌的有效性
- 建立區域性會話
- 攔截使用者登出請求,向sso認證中心傳送登出請求
- 接收sso認證中心發出的登出請求,銷燬區域性會話
sso-server
- 驗證使用者的登入資訊
- 建立全域性會話
- 建立授權令牌
- 與sso-client通訊傳送令牌
- 校驗sso-client令牌有效性
- 系統註冊
- 接收sso-client登出請求,登出所有會話
接下來,我們按照原理來一步步實現sso吧!
1、sso-client攔截未登入請求
java攔截請求的方式有servlet、filter、listener三種方式,我們採用filter。在sso-client中新建LoginFilter.java類並實現Filter介面,在doFilter()方法中加入對未登入使用者的攔截
1 2 3 4 5 6 7 8 9 10 11 12 |
public
void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
HttpServletRequest req = (HttpServletRequest) request;
HttpServletResponse res = (HttpServletResponse) response;
HttpSession session = req.getSession();
if
(session.getAttribute( "isLogin" )) {
chain.doFilter(request, response);
return ;
}
//跳轉至sso認證中心
res.sendRedirect( "sso-server-url-with-system-url" );
}
|
2、sso-server攔截未登入請求
攔截從sso-client跳轉至sso認證中心的未登入請求,跳轉至登入頁面,這個過程與sso-client完全一樣
3、sso-server驗證使用者登入資訊
使用者在登入頁面輸入使用者名稱密碼,請求登入,sso認證中心校驗使用者資訊,校驗成功,將會話狀態標記為“已登入”
1 2 3 4 5 6 |
@RequestMapping ( "/login" )
public
String login(String username, String password, HttpServletRequest req) {
this .checkLoginInfo(username, password);
req.getSession().setAttribute( "isLogin" ,
true );
return
"success" ;
}
|
4、sso-server建立授權令牌
授權令牌是一串隨機字元,以什麼樣的方式生成都沒有關係,只要不重複、不易偽造即可,下面是一個例子
1 |
String token = UUID.randomUUID().toString();
|
5、sso-client取得令牌並校驗
sso認證中心登入後,跳轉回子系統並附上令牌,子系統(sso-client)取得令牌,然後去sso認證中心校驗,在LoginFilter.java的doFilter()中新增幾行
1 2 3 4 5 6 7 8 9 10 11 |
// 請求附帶token引數
String token = req.getParameter( "token" );
if
(token != null ) {
// 去sso認證中心校驗token
boolean
verifyResult = this .verify( "sso-server-verify-url" , token);
if
(!verifyResult) {
res.sendRedirect( "sso-server-url" );
return ;
}
chain.doFilter(request, response);
}
|
verify()方法使用httpClient實現,這裡僅簡略介紹,httpClient詳細使用方法請參考官方文件
1 2 |
HttpPost httpPost =
new HttpPost( "sso-server-verify-url-with-token" );
HttpResponse httpResponse = httpClient.execute(httpPost);
|
6、sso-server接收並處理校驗令牌請求
使用者在sso認證中心登入成功後,sso-server建立授權令牌並存儲該令牌,所以,sso-server對令牌的校驗就是去查詢這個令牌是否存在以及是否過期,令牌校驗成功後sso-server將傳送校驗請求的系統註冊到sso認證中心(就是儲存起來的意思)
令牌與註冊系統地址通常儲存在key-value資料庫(如redis)中,redis可以為key設定有效時間也就是令牌的有效期。redis執行在記憶體中,速度非常快,正好sso-server不需要持久化任何資料。
令牌與註冊系統地址可以用下圖描述的結構儲存在redis中,可能你會問,為什麼要儲存這些系統的地址?如果不儲存,登出的時候就麻煩了,使用者向sso認證中心提交登出請求,sso認證中心登出全域性會話,但不知道哪些系統用此全域性會話建立了自己的區域性會話,也不知道要向哪些子系統傳送登出請求登出區域性會話
7、sso-client校驗令牌成功建立區域性會話
令牌校驗成功後,sso-client將當前區域性會話標記為“已登入”,修改LoginFilter.java,新增幾行
1 2 3 |
if
(verifyResult) {
session.setAttribute( "isLogin" ,
true );
}
|
sso-client還需將當前會話id與令牌繫結,表示這個會話的登入狀態與令牌相關,此關係可以用java的hashmap儲存,儲存的資料用來處理sso認證中心發來的登出請求
8、登出過程
使用者向子系統傳送帶有“logout”引數的請求(登出請求),sso-client攔截器攔截該請求,向sso認證中心發起登出請求
1 2 3 4 |
String logout = req.getParameter( "logout" );
if
(logout != null ) {
this .ssoServer.logout(token);
}
|
sso認證中心也用同樣的方式識別出sso-client的請求是登出請求(帶有“logout”引數),sso認證中心登出全域性會話
1 2 3 4 5 6 7 8 |
@RequestMapping ( "/logout" )
public
String logout(HttpServletRequest req) {
HttpSession session = req.getSession();
if
(session != null ) {
session.invalidate(); //觸發LogoutListener
}
return
"redirect:/" ;
}
|
sso認證中心有一個全域性會話的監聽器,一旦全域性會話登出,將通知所有註冊系統登出
1 2 3 4 5 6 7 8 |
public
class LogoutListener implements
HttpSessionListener {
@Override
public
void sessionCreated(HttpSessionEvent event) {}
@Override
public
void sessionDestroyed(HttpSessionEvent event) {
//通過httpClient向所有註冊系統傳送登出請求
}
}
|
相關推薦
SSO單點登入原理和簡單實現
1、http無狀態協議 web應用採用browser/server架構,http作為通訊協議。http是無狀態協議,瀏覽器的每一次請求,伺服器會獨立處理,不與之前或之後的請求產生關聯,這個過程用下圖說明,三次請求/響應對之間沒有任何聯絡 但這也同時意味著,任何使用者都能通過瀏覽器訪問伺服器資源,如
單點登入原理與簡單實現學習
一、單系統登入機制 1、http無狀態協議 web應用採用browser/server架構,http作為通訊協議。http是無狀態協議,瀏覽器的每一次請求,伺服器會獨立處理,不與之前或之後的請求產生關聯,這個過程用下圖說明,三次請求/響應對之間沒有任何聯絡 但這也同時意味著
單點登入原理與簡單實現
一、單系統登入機制 1、http無狀態協議 web應用採用browser/server架構,http作為通訊協議。http是無狀態協議,瀏覽器的每一次請求,伺服器會獨立處理,不與之前或之後的請求產生關聯,這個過程用下圖說明,三次請求/響應對之間沒有任何聯絡 但這也同
單點登入原理與簡單實現(轉) 單點登入原理與簡單實現
單點登入原理與簡單實現 (2017-09-22更新)GitHub:https://github.com/sheefee/simple-sso 一、單系統登入機制 1、http無狀態協議 web應用採用browser/server架構,http作為通訊
關於單點登入原理與簡單實現,寫的太好了一看就懂!
一、單系統登入機制1、http無狀態協議web應用採用browser/server架構,http
CAS實現SSO單點登入原理
1. CAS簡介 CAS(Central Authentication Service) 是 Yale大學發起的一個企業級的、開源的專案,旨在為 Web 應用系統提供一種可靠的單點登入解決方法(屬於Web SSO)。 CAS開始於2001年, 並在 2004年
sso單點登入原理詳解(最後解說的比較好)
yale cas可以百度一下,這是學習cas後的一點總結,以備日後使用!安全性:使用者只須在cas錄入使用者名稱和密碼,之後通過ticket繫結使用者,在cas客戶端與cas校驗是通過ticket,並不會在網上傳輸密碼,所以可以保證安全性,密碼不被竊取原理:1個cookie+
SSO單點登入原理解析
一、單系統登入原理解析 一、無狀態協議http會話 客戶端每發出一次請求,伺服器就會獨立的進行處理,而當客戶端過了一定的時間之後再次向伺服器發出請求,伺服器依然進行單獨的處理,而不與之前和之後的請求產生聯絡
【SSO單點登入實現原理與總結】
一、什麼是單點登入SSO(Single Sign-On) SSO是一種統一認證和授權機制,指訪問同一伺服器不同應用中的受保護資源的同一使用者,只需要登入一次,即通過一個應用中的安全驗證後,再訪問其他應用中的受保護資源時,不再需要重新登入驗證。 二、單點登入解決
SSO單點登入系統原理分析及功能實現
Sso系統分析什麼是sso系統SSO英文全稱Single Sign On,單點登入。SSO是在多個應用系統中,使用者只需要登入一次就可以訪問所有相互信任的應用系統。它包括可以將這次主要的登入對映到其他應用中用於同一個使用者的登入的機制。它是目前比較流行的企業業務整合的解決方案
SSO單點登入,簡單模擬
SSO單點登入(以下全是個人理解,如果有誤,共同批評進步) 1.什麼是單點登入: 在不同的應用中,受保護的同一使用者,登入一次就可以訪問相關的其他系統應用。比如搜狐登入後,可以直接訪問部落格、郵箱等等,而不用再重新登入部落格系統、郵箱系統等等。方便了使用者的操作。 2.同域下單點登入
CAS 實現 SSO 單點登入
環境 cas-server-4.1.8,cas-client-3.4.0,Java-8,Maven-3,Tomcat-7.0.72 CAS Server 安裝 點此進入 CAS 下載列表,選擇下載 cas-4.1.
SpringBoot+MyBatis+Redis實現SSO單點登入系統(二)
SpringBoot+MyBatis+Redis實現SSO單點登入系統(二) 三、程式碼 配置檔案配置資料庫,redis等相關的資訊。 # See http://docs.spring.io/spring-boot/docs/current/reference/html
SpringBoot+MyBatis+Redis實現SSO單點登入系統(一)
SpringBoot+MyBatis+Redis實現SSO單點登入系統(一) 一、SSO系統概述 SSO英文全稱Single Sign On,單點登入。SSO是在多個應用系統中,使用者只需要
CAS實現SSO單點登入
環境cas-server-4.1.8,cas-client-3.4.0,Java-8,Maven-3,Tomcat-7.0.72 CAS Server 安裝點此進入 CAS 下載列表,選擇下載 cas-4.1.8.zip。 解壓縮 cas-4.1.8.zip 並進入 cas-server-webapp 目
Java架構-Spring mvc+oss儲存+fileupload多檔案上傳實現SSO單點登入模板管理
之前給大家介紹了sso的相關知識點和整合方案,考慮到每個系統所屬行業的不同,這邊針對於不同行業做了一些統一的sso單點登入介面模板,使用fileupload多檔案上傳+OSS阿里雲端儲存方案。 1. 阿里雲oss儲存Utils Java程式碼 2. 阿里雲配
Java架構-spring+springmvc+Interceptor+jwt+redis實現sso單點登入
在分散式環境中,如何支援PC、APP(ios、android)等多端的會話共享,這也是所有公司都需要的解決方案,用傳統的session方式來解決,我想已經out了,我們是否可以找一個通用的方案,比如用傳統cas來實現多系統之間的sso單點登入或使用oauth的第三方登入方案? 今天給大家
使用jwt實現sso單點登入
Single Sign On 匯入pom <dependencyManagement> <dependencies> <dependency> <groupId>io.spring.platform
ssm + redis 實現sso單點登入,類適於CAS
1.原理講解 由於CAS 過於重量級且時間成本較高 ,所以我決定公司採用自己的sso 單點系統來處理系統之間只要一個系統登入成功,其他子系統就不用登入。 舉例說明: 比如公司有 系統 A 系統 B 此時我們就要定義一個專門用來做登入認證的sso系統。 如果使用者登入的是
Docker 建立 Crucible4.6.1 以及與 Crowd3.3.2 實現 SSO 單點登入
目錄 目錄 1、介紹 1.1、什麼是 Crucible? 2、Crucible 的官網在哪裡? 3、如何下載安裝? 4、對 Crucible 進行配置 4.1、破解 Crucible 第一步 4.2、破解 Crucible 第二步,獲取授權許