背景
本文主題是作者在 Spring Cloud 體系下通過 Zuul 網關來進行認證的遷移授權的前移、統一管理和業務服務進行鑒權的思考和做法。
本文介紹的做法是根據 Zuul 來做的，對 Zuul 不熟悉的朋友可以看看下面這篇文章，通過這篇對 Zuul 深入淺出的介紹之后能對 Zuul 有個大致的了解。
出自方志朋的博客:深入理解Zuul之源碼解析
核心思想
本人認為微服務中權限的處理應該分為兩種：
- 用戶的權限控制
- 系統服務的權限控制
具體思路
先上圖
Zuul+微服務鑒權.png
UML時序圖.png
- 由圖中可以看出將請求簡單的定義為內部請求和外部請求。
再來分析外部請求（token）
- 本人將
token理解成認證的令牌，token完全由 Zuul 來具體管理（新建、刷新和銷毀）與其他服務無關，但是 Zuul 中處理token的動作指令由業務服務發出。 - 用戶登錄：用戶請求登錄，
Cookie中無token，Zuul 不對其進行認證（即這個人我不認識，我不管），將請求投遞路由到業務服務，業務服務該接口不會校驗其權限，通過登錄邏輯處理，登錄成功返回，響應頭中增加了登錄成功標示和該用戶權限角色信息（authentication后文通過該單詞代替 ），Zuul 接收到信息之后新建token，并將token與authentication對應起來。 - 用戶請求信息：
Cookie中有token，校驗token的有效性，如果成功將取出對應的authentication，設置進路由的請求頭中，業務系統通過請求頭解析出該用戶的身份，并鑒權。 - 用戶退出登錄：請求部分與
用戶請求信息一致，返回時將在響應頭中設置注銷登錄標示，Zuul 獲取標示之后會銷毀token與其對應authentication。
最后分析內部請求
- 由于是內部請求，于是將安全校驗的機制設置得相對簡單了。
- 將每個
Service理解為一個獨立的第三方服務系統，調用Service理解為請求客戶系統。 - 凡是想調用某個
Service之前，必須先去申請一個secretKey，然后每個請求都必須攜帶該secretKey，通過secretKey可以查出調用者，控制調用系統權限。 - 補充：有人覺得通過一個
secretKey來處理不夠安全，對于內部請求安全級別高的，可以對應secretKey設置 ip白名單，甚至設置secretKey的有效時間通過系統刷新來刷新secretKey，個人感覺大部分的企業不需要來刷新secretKey來提高安全級別，通過 ip白名單的方式安全程度已經夠高了。
總結
- 本文只介紹了作者在改造系統權限體系時的想法思路，文中 Zuul 可以就理解為網關，后面系列將介紹如何在 Zuul 中實現，這里具體實現就沒有提及了。
- 作者的
token處理參考了Oauth2.0協議的token機制，即具備刷新過期等機制，如果感覺本文有那么一些道理，想繼續看看我是怎么做的話，可以繼續關注，后面有計劃將整個實現機制開源出來。 - 文中的想法很多是我與公司團隊的想法，歡迎大家與我交流分享，熱烈歡迎指正不對之處。
