1. 前言

目前在做門戶，有很多不明白的地方，經過思考和討論，大致梳理出了一個基本的思路。

2. 單點登入

單點登入用於多個系統之間的統一認證，做到“登陸一次，隨意通行”。單點登入和門戶沒有必然聯絡，單點登入元件比如CAS只管認證，不管其他的。

問題：若干個系統只用一份使用者表，那麼每個系統裡面沒有維護使用者資訊，怎麼去維護各自系統的許可權，角色，組織機構等關係呢？

方案一

每個系統都維護一份使用者表，和單點登入的使用者表保持同步，然後每個系統使用自己的使用者表來維護使用者和許可權，角色，組織機構等的關係。
這種方式的關鍵在於用什麼手段保持同步：

• 在資料庫層面同步使用者資訊
  可以在單點登入使用者表中建立觸發器，在新增、修改、刪除的時候同時編輯各個子系統的使用者表還有其他的使用者關聯資訊。
  這種辦法簡單好用，但是要求各個系統的資料庫在同一臺機器上或者可以提供DBLink之類的連線，缺點是不利於擴充套件，比如子系統更換了資料庫型別就歇菜了。
• 在應用層面同步使用者資訊
  各個系統提供維護使用者資訊的WebService介面或者API，在維護單點登入使用者的時候呼叫各子系統的介面實現系統間的同步
  這種方式的缺點是：
  
  • 將同步的操作寫在程式碼中，可能會經常改動程式碼。
  • 可能會因為介面服務宕掉或者其他原因並不能保證各系統之間資料的完全一致，最後還是需要人工參與。
• 提供使用者資訊檢視
  直接對外暴露一個使用者資訊檢視，各子系統想怎麼同步就怎麼同步，這種方法最簡單，需要注意不要把原始的資料庫暴露出去，單獨建一個使用者使用這個使用者提供檢視。

方案二

抽離出公共的許可權模組，用來統一管理使用者、角色、許可權、機構等資訊。
這個就有點類似於門戶的功能了，把這些資源都抽離成一個父模組統一管理，各個子系統不需要維護這些關係，自然也就不需要同步了。
父模組需要提供方案供各個子模組獲取許可權、角色、機構等資訊。

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是不一致的，都可以用這種思路解決。

4. 說明

我對這方面的理解實在有限，本文說的也肯定有不全面或者不對的地方，如果有更好的方案，希望有大神看到指點一二，謝謝！