單點登入（SSO）小記

What

單點登入（SSO，Single Sign-On）指對于多個應用，隻要在其中一個中登入了就可直接通路其中任一應用而不用再登入、同樣地隻要在其中一個登出了就不能再通路其中任一應用。

借助SSO可以實作統一的Authenticate、Authorize服務。

實作方案

如下三種方案，前面的方案可以視為後面的方案的特例，越後面的方案越通用。

方案1 - Gateway

弄一個統一的網關，所有服務都放在該網關後面，前端的任何請求都經過該網關，對使用者的認證、授權、登出等都在網關層做。由網關負責進行使用者Authenticate、Authorize、轉發到下遊服務等操作，下遊服務不再需要進行Authenticate操作。在Java裡通常是業務網關，如Zuul、Spring Gateway等。

在實作上既可以由網關直接去通路資料庫校驗使用者也可以調用專門的使用者中心服務來校驗使用者，但本質上都是有一個統一的使用者中心。

顯然，此法要求你對所有服務都有控制權，否則沒法把它們組織到一個網關下。比如一個組内的各種産品（如教育産品線下的各子産品），或者一個産品背後的各種微服務。

特點：各服務需要有統一的使用者中心；各服務不需要自己實作任何認證和授權邏輯（由網關統一實作）；要求方案實施者對各服務有絕對控制權，将各服務統一組織在網關背後。

方案2 - CAS（Central Authentication Service）

（參閱：https://developer.ibm.com/zh/articles/os-cn-cas/）

前面的方案要求所有産品在一個網關後面，然而實際上很多情況下該條件難以滿足，比如你公司内的OA系統、EHR系統，硬要把它們組織到一個網關下對于開發、維護都會很麻煩。此時可用CAS。

從結構上看，CAS包括兩部分：CAS Server 和 CAS Client。

CAS Server 需要獨立部署，主要負責對使用者的認證工作；可在此直接去通路資料庫校驗使用者也可以調用專門的使用者中心服務來校驗使用者。

CAS Client 與受保護的用戶端應用部署在一起，負責處理對用戶端受保護資源的通路請求。需要登入時，重定向到 CAS Server。

協定具體工作過程如下：

CAS Client 與受保護的用戶端應用部署在一起，以 Filter 方式保護受保護的資源。

對于通路受保護資源的每個 Web 請求，CAS Client 會分析該請求的 Http 請求中是否包含 Service Ticket，如果沒有，則說明目前使用者尚未登入，于是将請求重定向到指定好的 CAS Server 登入位址，并傳遞 Service （也就是要通路的目的資源位址），以便登入成功過後轉回該位址。

使用者在第 3 步中輸入認證資訊，如果登入成功，CAS Server 随機産生一個相當長度、唯一、不可僞造的 Service Ticket，并緩存以待将來驗證，之後系統自動重定向到 Service 所在位址，并為用戶端浏覽器設定一個 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新産生的 Ticket 過後，在第 5，6 步中與 CAS Server 進行身份合适，以確定 Service Ticket 的合法性。

簡而言之，此方案有專門的CAS Server負責認證，而每個應用都要內建CAS Client；目前端通路應用時，CAS Client會校驗使用者是否登入，若未登入則定向到CAS Server讓使用者登入并從CAS Server獲得使用者的資訊。

與Gateway方案相比，CAS不再要求所有應用在一個網關後（實際上也可以将CAS視為一個邏輯上的Gateway，從這角度上看與上一個方案一樣），但仍需要有一個統一的使用者中心。

特點：各服務需要有統一的使用者中心；各服務需要自己實作部分的認證和授權邏輯（內建CAS Client、與CAS Server互動）；各服務通常同屬于一個組織，如公司。 

此方式下的具體處理過程：

登入：

登出：

更多參考資料：

https://www.cnblogs.com/ywlaker/p/6113927.html

https://blog.csdn.net/anumbrella/article/details/80821486

https://github.com/xuxueli/xxl-sso/tree/master/xxl-sso-server （實作）

方案3 - SAML（Security Assertion Markup Language）

（參閱：http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html、https://developers.onelogin.com/saml）

當沒有一個統一的使用者中心時（如不同公司的産品整合做到單點登入的效果），上述方案都不可行了，此時可用SAML，SAML可使不相關的兩個系統互認身份。

SAML是個Authenticate、Authorize協定。它定義了一套XML文法，用于将使用者的唯一辨別從一個應用（身份提供者）中的轉換為另一應用（服務提供者）中的，這使用者在後者中并不存在、且兩應用沒有共同的使用者中心。

協定具體工作過程：

SAML SSO works by transferring the user’s identity from one place (the identity provider) to another (the service provider). This is done through an exchange of digitally signed XML documents.

Consider the following scenario: A user is logged into a system that acts as an identity provider. The user wants to log in to a remote application, such as a support or accounting application (the service provider). The following happens:

1. The user accesses the remote application using a link on an intranet, a bookmark, or similar and the application loads.
2. The application identifies the user’s origin (by application subdomain, user IP address, or similar) and redirects the user back to the identity provider, asking for authentication. This is the authentication request.
3. The user either has an existing active browser session with the identity provider or establishes one by logging into the identity provider.
4. The identity provider builds the authentication response in the form of an XML-document containing the user’s username or email address, signs it using an X.509 certificate, and posts this information to the service provider.
5. The service provider, which already knows the identity provider and has a certificate fingerprint, retrieves the authentication response and validates it using the certificate fingerprint.
6. The identity of the user is established and the user is provided with app access.

與CAS類似，此方案也需要各應用實作SAML協定的交換邏輯。

特點：不需要各服務有統一的使用者中心；各服務需要自己實作部分的認證和授權邏輯（實作SAML協交換邏輯）；不要求各服務同屬于一個組織，可以是任意不同服務。 

方案4 - OAuth2.0

OAuth2.0協定用來授權第三方站點來通路本站點的資源。當這裡的“資源”指使用者資訊時，通常就可用目前站點的賬号來登入第三方系統。常見的很多站點上的“用微信登入”、“用QQ登入”等就是用的此協定。

OAuth2.0大多用在互不相關無法互相控制的兩個系統間，而不是像CAS一樣各個子系統處于一個組織或公司下可以自己控制。借助此協定，隻要多個系統中有一個是OAuth Authorization Server，其他系統就可以當做是該Server的Oauth Client，這樣就可以以Server中的使用者來登入這些系統。

此方案的效果看上去很像SSO，但嚴格來說不是SSO方案，因為通常每個系統内部還會維護使用者資訊表，表中維護本系統使用者與OAuth Server使用者的關聯關系。

20210407更新：此方案實際上有專門的标準，OpenID Connect。

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 [RFC6749] protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. Use of this extension is requested by Clients by including the openid scope value in the Authorization Request. Information about the authentication performed is returned in a JSON Web Token (JWT) [JWT] called an ID Token (see Section 2). OAuth 2.0 Authentication Servers implementing OpenID Connect are also referred to as OpenID Providers (OPs). OAuth 2.0 Clients using OpenID Connect are also referred to as Relying Parties (RPs). 

特點：不需要各服務有統一的使用者中心；各服務需要自己實作部分的認證和授權邏輯（實作OAuth授權流程）；不要求各服務同屬于一個組織，可以是任意不同服務。