單點登錄

 

跨域：客戶端請求的時候，請求的服務器，不是同一個IP,端口，域名，主機名的時候，都成爲跨域

域：在應用模型，一個完整的，有獨立訪問路徑的功能集合稱爲一個域

域名和IP是不一樣的域，協議不一樣不叫跨域

SPRING session 將session保存到三方存儲容器中，如mysql,redis

主要解決同域名下多服務器集羣session共享的問題，不能解決跨域session共享問題

JWT 數據結構   A.B.C

A -head頭信息

B- payload(有效荷載)   用戶非重要信息

C-signature 簽名

 

頭信息   數據結構{"alg":"加密算法","typ":"JWT"}

payload

明文

分爲三個部分：

已註冊信息(registered claims)：iss(發行者)，exp（到期時間），sub(主題)，aud(受衆)

公開數據(public claims), 自定義的

私有數據（private claims）自定義

 

signature

簽名信息

先使用header中定義的加密算法，將header和payload 進行加密，

再使用相同的加密算法，對加密後的數據和簽名信息進行加密

 

 

 

 

1. 前言

目前在作門戶，有不少不明白的地方，通過思考和討論，大體梳理出了一個基本的思路。
2. 單點登陸

單點登陸用於多個系統之間的統一認證，作到「登錄一次，隨意通行」。單點登陸和門戶沒有必然聯繫，單點登陸組件好比CAS只管認證，無論其餘的。
問題：若干個系統只用一份用戶表，那麼每一個系統裏面沒有維護用戶信息，怎麼去維護各自系統的權限，角色，組織機構等關係呢？
方案一

每一個系統都維護一份用戶表，和單點登陸的用戶表保持同步，而後每一個系統使用本身的用戶表來維護用戶和權限，角色，組織機構等的關係。
這種方式的關鍵在於用什麼手段保持同步：

    1在數據庫層面同步用戶信息
    能夠在單點登陸用戶表中建立觸發器，在添加、修改、刪除的時候同時編輯各個子系統的用戶表還有其餘的用戶關聯信息。
    這種辦法簡單好用，可是要求各個系統的數據庫在同一臺機器上或者能夠提供DBLink之類的鏈接，缺點是不利於擴展，好比子系統更換了數據庫類型就歇菜了。
 

    2 在應用層面同步用戶信息
    各個系統提供維護用戶信息的WebService接口或者API，在維護單點登陸用戶的時候調用各子系統的接口實現系統間的同步
    這種方式的缺點是：
        將同步的操做寫在代碼中，可能會常常改動代碼。
        可能會由於接口服務宕掉或者其餘緣由並不能保證各系統之間數據的徹底一致，最後仍是須要人工參與。

    3提供用戶信息視圖

     直接對外暴露一個用戶信息視圖，各子系統想怎麼同步就怎麼同步，這種方法最簡單，須要注意不要把原始的數據庫暴露出去，單獨建一個用戶使用這個用戶提供    視圖。

方案二

抽離出公共的權限模塊，用來統一管理用戶、角色、權限、機構等信息。
這個就有點相似於門戶的功能了，把這些資源都抽離成一個父模塊統一管理，各個子系統不須要維護這些關係，天然也就不須要同步了。
父模塊須要提供方案供各個子模塊獲取權限、角色、機構等信息。
3. 門戶

門戶的概念可大可小，基本包含以下幾點：

    單點登陸
    統一權限管理
    日誌管理
    各系統功能的整合

3.1. 單點登陸

門戶提供單點登陸功能。
3.2. 統一權限管理
問題一：門戶既然統一管理權限，各個子系統怎麼獲取本身須要的權限信息呢？

獲取信息的方式能夠有不少種，可是真正的難點在於如何控制好各個子系統的數據權限，好比：

    如何在保證易用性的前提下作到各個子系統訪問本身的數據，而不能訪問其餘子系統的數據；
    有時子系統不可避免的會有對權限進行操做的需求，如何知足這部分需求的同時保證數據的安全。

方案一：

門戶提供Webservice查詢接口供各個子系統調用。
這種方式性能不太好。
方案二：

門戶提供API（jar包）查詢接口供各個子系統調用。
這種方式不錯，提供Maven依賴也能夠比較方便的更新。
方案三：

使用Redis保存用戶信息和權限信息，各個子系統和門戶都從Redis裏面取信息，從而作到Session信息共享。
這種方式適合多系統之間Session共享，須要單獨的Redis服務器。
問題二：子系統中有一些資源須要受權，可是這些資源門戶中很難維護怎麼辦？

有些數據量很大（好比數據庫的元數據信息）；有些資源變更特別頻繁（好比文件資源）；有些資源權限控制複雜（好比須要控制訪問範圍、讀寫權限，相似於LInux文件）；甚至有一些資源是須要動態獲取的，根本沒法固化到數據庫中。
以上這些資源是很難再門戶中維護的。
方案一

子系統同步門戶的用戶、部門等表，具體辦法參考上文。
方案二

門戶提供用戶列表、部門列表等信息的查詢接口或者API供子系統調用，子系統受權的時候從接口或者API中獲取這些信息，而後用來受權創建關聯信息。這種方式只是理論上可行，可是確定很是複雜繁瑣。
缺點：

    開發很困難
    不安全
    權限管理複雜，有些用戶有隻A系統的權限，沒有B系統的權限，那麼用戶A須要只能獲取到有本系統權限的用戶。

3.3. 日誌管理

日誌分爲兩種：訪問日誌和操做日誌。
3.3.1. 訪問日誌

    若是訪問的是門戶中的資源，那麼門戶直接記錄訪問日誌。
    若是訪問的是子系統中的資源，須要子系統調用門戶提供的訪問日誌接口或者API來記錄訪問日誌。

3.3.2. 操做日誌

    若是是門戶自己的操做，好比用戶信息的維護，資源的註冊和刪除等，這些操做日誌由門戶直接記錄。
    其餘設計具體子系統業務的操做，由子系統調用門戶提供的接口或者API記錄操做日誌。

3.4. 各系統功能整合

門戶整合子系統根據實際狀況有不少種方式。

    徹底整合
    徹底控制子系統的各類資源的管理和受權，甚至能夠將子系統的功能嵌入到門戶中。
    控制權限、提供單點登陸
    徹底控制子系統的各類資源的管理和受權，提供單點登陸功能，以門戶做爲入口訪問各個子系統。
    只提供單點登陸
    只提供單點登陸，子系統同步用戶機構等表，本身控制權限。
    僅整合入口
    僅整合入口，僞單點登陸。

問題一：子系統不想改造，只想簡單嵌入到門戶中怎麼辦？

實際工做中由於門戶須要整合其餘系統，可能會遇到各類各類的問題或者阻力，好比已經上線運行的系統要整合到門戶中，進行單點登陸、權限等改造是很耗費時間的，尤爲是客戶不掏錢的狀況下廠商是確定不想改的。
這種狀況能夠作一種僞單點登陸，子系統基本不用怎麼改動便可。
解決方案：
1. 這種狀況門戶中只能維護一個子系統的入口，其餘的權限、用戶等等都不用管，用戶點擊入口連接時，門戶打開新窗口調用子系統的登陸頁面，將用戶名密碼等信息傳過去。
2. 子系統的邏輯也基本不用修改，判斷用戶名密碼是否正確就能夠，出於安全考慮連接和請求信息通常會加密，因此子系統通常須要對信息進行解密再校驗。
3. 子系統的用戶表須要從門戶的用戶表中同步，注意只須要同步有登錄該系統權限的用戶。
4. 子系統開發一個沒有訪問權限的頁面，若是登陸驗證失敗，就返回這個無權限頁面。
問題二：關於本來使用Shiro控制權限的系統如何做爲子系統接入門戶？

Shiro本來控制權限使用的是一個惟一的字符串也就是權限標識來控制用戶的權限的，這個字符串通常是惟一的，可讀性好的，有必定業務含義的。
可是門戶控制權限不大可能爲使用Shiro的子系統去維護這樣的字符串。
因此子系統能夠維護一個資源ID和權限標識的映射關係表，獲取到擁有權限的資源ID集合之後再映射成權限標識的集合提供給Shiro。
注意：
其實不僅是Shiro，各個子系統均可能存在這個問題，就是門戶的資源ID和系統的資源ID是不一致的，均可以用這種思路解決。
---------------------
做者：程序員GO
來源：CSDN
原文：https://blog.csdn.net/hao7030187/article/details/70670323
版權聲明：本文爲博主原創文章，轉載請附上博文連接！

 

 

 

 

 

 

 

 

 

 

 

 

1.登錄

用戶訪問系統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認證中心，全局會話與局部會話有以下約束關係

1 2 3

局部會話存在，全局會話必定存在 全局會話存在，局部會話不必定存在 全局會話銷燬，局部會話必須銷燬

 

2.註銷

單點登陸天然也要單點註銷，在一個子系統中註銷，全部子系統的會話都將被銷燬

sso認證中心一直監聽全局會話的狀態，一旦全局會話銷燬，監聽器將通知全部註冊系統執行註銷操做

 

用戶向系統1發起註銷請求

系統1根據用戶與系統1創建的會話id拿到令牌，向sso認證中心發起註銷請求

sso認證中心校驗令牌有效，銷燬全局會話，同時取出全部用此令牌註冊的系統地址

sso認證中心向全部註冊系統發起註銷請求

各註冊系統接收sso認證中心的註銷請求，銷燬局部會話

sso認證中心引導用戶至登陸頁面

 

sso-client

1 2 3 4 5 6

攔截子系統未登陸用戶請求，跳轉至sso認證中心 接收並存儲sso認證中心發送的令牌 與sso-server通訊，校驗令牌的有效性 創建局部會話 攔截用戶註銷請求，向sso認證中心發送註銷請求 接收sso認證中心發出的註銷請求，銷燬局部會話

　　sso-server

1 2 3 4 5 6 7

驗證用戶的登陸信息 建立全局會話 建立受權令牌 與sso-client通訊發送令牌 校驗sso-client令牌有效性 系統註冊 接收sso-client註銷請求，註銷全部會話