本文轉載自： https://www.cnblogs.com/ywlaker/p/6113927.html

作者：淩承一

出處：http://www.cnblogs.com/ywlaker/

聲明：本文版權歸作者和部落格園共有，歡迎轉載，但轉載必須保留此段聲明，并在文章頁面明顯位置給出原文連結，否則作者将保留追究法律責任的權利。

單系統登入機制

web應用采用browser/server架構，http作為通信協定。http是無狀态協定，浏覽器的每一次請求，伺服器會獨立處理，不與之前或之後的請求産生關聯，這個過程用下圖說明，三次請求/響應對之間沒有任何聯系。

但這也同時意味着，任何使用者都能通過浏覽器通路伺服器資源，如果想保護伺服器的某些資源，必須限制浏覽器請求；要限制浏覽器請求，必須鑒别浏覽器請求，響應合法請求，忽略非法請求；要鑒别浏覽器請求，必須清楚浏覽器請求狀态。既然http協定無狀态，那就讓伺服器和浏覽器共同維護一個狀态吧！這就是會話機制。

會話機制

浏覽器第一次請求伺服器，伺服器建立一個會話，并将會話的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的請求響應過程如下圖：

登入狀态

有了會話機制，登入狀态就好明白了，我們假設浏覽器第一次請求伺服器需要輸入使用者名與密碼驗證身份，伺服器拿到使用者名密碼去資料庫比對，正确的話說明目前持有這個會話的使用者是合法使用者，應該将這個會話标記為“已授權”或者“已登入”等等之類的狀态，既然是會話的狀态，自然要儲存在會話對象中，tomcat在會話對象中設定登入狀态如下：

HttpSession session = request.getSession();
session.setAttribute("isLogin", true);

使用者再次通路時，tomcat在會話對象中檢視登入狀态：

HttpSession session = request.getSession();
session.getAttribute("isLogin");

實作了登入狀态的浏覽器請求伺服器模型如下圖描述：

每次請求受保護資源時都會檢查會話對象中的登入狀态，隻有

isLogin=true

的會話才能通路，登入機制是以而實作。

多系統的複雜性

web系統早已從久遠的單系統發展成為如今由多系統組成的應用群，面對如此衆多的系統，使用者難道要一個一個登入、然後一個一個登出嗎？就像下圖描述的這樣

web系統由單系統發展成多系統組成的應用群，複雜性應該由系統内部承擔，而不是使用者。無論web系統内部多麼複雜，對使用者而言，都是一個統一的整體，也就是說，使用者通路web系統的整個應用群與通路單個系統一樣，登入/登出隻要一次就夠了。

雖然單系統的登入解決方案很完美，但對于多系統應用群已經不再适用了，為什麼呢？

單系統登入解決方案的核心是cookie，cookie攜帶會話id在浏覽器與伺服器之間維護會話狀态。但cookie是有限制的，這個限制就是cookie的域（通常對應網站的域名），浏覽器發送http請求時會自動攜帶與該域比對的cookie，而不是所有cookie。

子域名cookie共享完成單點登入

既然這樣，為什麼不将web應用群中所有子系統的域名統一在一個頂級域名下，例如“

*.baidu.com

”，然後将它們的cookie域設定為“baidu.com”，這種做法理論上是可以的，甚至早期很多多系統登入就采用這種同域名共享cookie的方式。

然而，可行并不代表好，共享cookie的方式存在衆多局限。

首先，應用群域名得統一。
其次，應用群各系統使用的技術（至少是web伺服器）要相同，不然cookie的key值（tomcat為JSESSIONID）不同，無法維持會話，共享cookie的方式是無法實作跨語言技術平台登入的，比如java、php、.net系統之間。
第三，cookie本身不安全。

除上面之外，如果我們在

session

存放的是

User

對象，那麼我們使用全局cookie共享

JSESSIONID

值，每一個子域名就可以通路同一個session，登入成功後儲存一個user對象，登出後就移除這個user對象。session中的user對象必須先序列化儲存到redis中，并且每次通路的時候，都需要去redis中取出session，并且重新序列化成user對象。這樣會造成額外的消耗。

是以，我們需要一種全新的登入方式來實作多系統應用群的登入，這就是單點登入。

單點登入

什麼是單點登入？

單點登入全稱Single Sign On（以下簡稱SSO），是指在多系統應用群中登入一個系統，便可在其他所有系統中得到授權而無需再次登入，包括單點登入與單點登出兩部分。

相比于單系統登入，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與參數

登出

單點登入自然也要單點登出，在一個子系統中登出，所有子系統的會話都将被銷毀，用下面的圖來說明：

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吧！

sso-client攔截未登入請求

java攔截請求的方式有servlet、filter、listener三種方式，我們采用filter。在sso-client中建立LoginFilter.java類并實作Filter接口，在doFilter()方法中加入對未登入使用者的攔截：

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");
}

sso-server攔截未登入請求

攔截從sso-client跳轉至sso認證中心的未登入請求，跳轉至登入頁面，這個過程與sso-client完全一樣。

sso-server驗證使用者登入資訊

使用者在登入頁面輸入使用者名密碼，請求登入，sso認證中心校驗使用者資訊，校驗成功，将會話狀态标記為“已登入”。

@RequestMapping("/login")
public String login(String username, String password, HttpServletRequest req) {
    this.checkLoginInfo(username, password);
    req.getSession().setAttribute("isLogin", true);
    return "success";
}

sso-server建立授權令牌

授權令牌是一串随機字元，以什麼樣的方式生成都沒有關系，隻要不重複、不易僞造即可，下面是一個例子：

String token = UUID.randomUUID().toString();

sso-client取得令牌并校驗

sso認證中心登入後，跳轉回子系統并附上令牌，子系統（sso-client）取得令牌，然後去sso認證中心校驗，在LoginFilter.java的doFilter()中添加幾行：

// 請求附帶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詳細使用方法請參考官方文檔。

HttpPost httpPost = new HttpPost("sso-server-verify-url-with-token");
HttpResponse httpResponse = httpClient.execute(httpPost);

sso-server接收并處理校驗令牌請求

使用者在sso認證中心登入成功後，sso-server建立授權令牌并存儲該令牌，是以，sso-server對令牌的校驗就是去查找這個令牌是否存在以及是否過期，令牌校驗成功後sso-server将發送校驗請求的系統注冊到sso認證中心（就是存儲起來的意思）
令牌與注冊系統位址通常存儲在key-value資料庫（如redis）中，redis可以為key設定有效時間也就是令牌的有效期。redis運作在記憶體中，速度非常快，正好sso-server不需要持久化任何資料。
令牌與注冊系統位址可以用下圖描述的結構存儲在redis中，可能你會問，為什麼要存儲這些系統的位址？如果不存儲，登出的時候就麻煩了，使用者向sso認證中心送出登出請求，sso認證中心登出全局會話，但不知道哪些系統用此全局會話建立了自己的局部會話，也不知道要向哪些子系統發送登出請求登出局部會話。

sso-client校驗令牌成功建立局部會話

令牌校驗成功後，sso-client将目前局部會話标記為“已登入”，修改LoginFilter.java，添加幾行：

if (verifyResult) {
    session.setAttribute("isLogin", true);
}

sso-client還需将目前會話id與令牌綁定，表示這個會話的登入狀态與令牌相關，此關系可以用java的hashmap儲存，儲存的資料用來處理sso認證中心發來的登出請求

登出過程

使用者向子系統發送帶有“logout”參數的請求（登出請求），sso-client攔截器攔截該請求，向sso認證中心發起登出請求：

String logout = req.getParameter("logout");
if (logout != null) {
    this.ssoServer.logout(token);
}

sso認證中心也用同樣的方式識别出sso-client的請求是登出請求（帶有“logout”參數），sso認證中心登出全局會話：

@RequestMapping("/logout")
public String logout(HttpServletRequest req) {
    HttpSession session = req.getSession();
    if (session != null) {
        session.invalidate();//觸發LogoutListener
    }
    return "redirect:/";
}

sso認證中心有一個全局會話的監聽器，一旦全局會話登出，将通知所有注冊系統登出

public class LogoutListener implements HttpSessionListener {
    @Override
    public void sessionCreated(HttpSessionEvent event) {}
    @Override
    public void sessionDestroyed(HttpSessionEvent event) {
        //通過httpClient向所有注冊系統發送登出請求
    }
}

代碼部署

GitHub位址： https://github.com/morethink/simple-sso.git

IDEA部署

通路a系統：

http://localhost/a/test

通路b系統：

http://localhost/b/test

a系統登入成功：

b系統同時也登入成功:

單點登入原理與簡單實作