知識星球Intro
最近開始真正的實踐了一些閘道器的東西，最近寫幾篇文章分享一下我的實踐以及遇到的問題。
本文主要介紹閘道器後面的服務如何進行認證。
解決思路
閘道器可以做一部分的認證和授權，服務內部有時候也會需要使用者的資訊，這時該怎麼辦呢，我們使用的是 JWT 認證，有一個 identity server去頒發，驗證 token，一種簡單方式可以把 token 直接往後傳，傳遞給後面的具體某個服務，後面的服務可以去 identity server 拿到公鑰資訊去驗證 token 的合法性，依然可以拿到使用者的一些基本資訊，但又覺得這樣後面的服務還是要依賴 identityserver 不是太好，因為認證已經在閘道器做掉了，後面不應該再去做認證的事情了，而且解析 JWT token 也是有一定的效能損耗，於是想把使用者的基本資訊在閘道器認證完成之後放到請求頭中。
我們閘道器用的Ocelot，開源的原生 .NET 專案方便自己擴充套件，Ocelot 中有一個 Claims2Headers 可以把 Claims 中的資訊轉換為請求頭，詳細使用參見檔案，但是實現有個bug，如果有多個值他只會取第一個，詳見issue，可以自己擴充套件一個 ocelot 的中介軟體替換掉原有的中介軟體。
把使用者資訊放到請求頭中，後面的服務從請求頭中就可以拿到使用者的基本資訊了，為了後面的服務不做過多的改動，我做了一個自定義的認證，從請求頭中拿使用者的基本資訊進行認證，這樣後面的服務還是可以直接使用 User.Identity.IsAuthenticated 和 User.Identity.Name 等，不需要做什麼改動。於是就有了這一根據請求頭認證的專案
實現效果
下載示例專案，在 TestWebApplication 目錄下執行 dotnet run
在瀏覽器中訪問 http://localhost:5000/api/values
使用 postman 或 fiddler （或其它你喜歡的工具）帶上 essay-header 訪問 http://localhost:5000/api/values
使用方式
使用方式可以參考示例專案
使用自定義的 HeaderAuthentication 來替代之前的認證方式，預設配置了使用者名稱，使用者id以及使用者角色，如果不能滿足可以在 options 中的 AdditionalHeaderToClaims 中新增更多轉換
這樣就可以了，你可以下載示例專案，快速體驗，你可以直接新增下麵幾個請求頭
UserId 使用者id
UserName 使用者名稱稱
UserRoles 使用者角色（多個角色以 , 分割，可以在 options 裡自定義多個值的分隔符
直接訪問需要授權才能訪問的資源了
現在只是初步的設想與實現，並已經驗證確實可行，程式碼還有一些業務邏輯比如 UserId 現在是必須的，可以根據自己需要自行修改，最近有點忙，找時間再修改重構一下再釋出 nuget 包。如果有什麼需求或問題，歡迎一起探討。
原始碼
自定義認證原始碼
提供了 HeaderAuthetication 和 QueryAuthentication 兩種實現，一種使用請求頭資訊認證，一種使用 QueryString 資訊認證。
HeaderAuthetication 主要實現在 HeaderAuthenticationHandler
核心程式碼，重寫 Authenticate 方法：
註意
請註意，如果使用這種方式，請確保你的服務不會被外界直接訪問，請求只能從閘道器或者本地除錯發起。需要保證安全性，不能直接暴露到公網，才能使用這種方式。
原文地址：https://www.cnblogs.com/weihanli/p/10464507.html
.NET社群新聞，深度好文，歡迎訪問公眾號文章彙總 http://www.csharpkit.com
