webapi框架搭建-安全機制（一）

本系列博客連接:webapi框架搭建系列博客

前言

　　webapi接口是開放給外部使用的，包括接口的地址，傳參的規範，還有返回結果的說明。正由於接口的開放性，使得接口的安全很重要。試想一下，用抓包工具（如fiddler)，甚至瀏覽器獲取到接口的規範後（甚至能夠猜到接口的其它規範），若是接口沒有作」安全「這一道防火牆，任何人均可以調用接口來獲取及提交數據，這真是太可怕了。17年我負責一個氣象類項目的開發，其中有些功能是咱們沒法完成但甲方要求必須有的功能，並給咱們展現了實現該功能的一個產品。後面經過對此產品的fiddler抓包分析，瞭解了該產品是經過接口向apps端提供數據，而全部的接口居然都沒有加密，因而這個項目基於此功能的實現基本上都是經過調用該產品的接口實現，對我來講是省去了很大的開發成本，但對於那個產品的公司來講是損失了有價值的數據。

　　對於webapi方面的安全，可寫的東西太多了，且asp.net webapi及asp.net core webapi在安全方面也有些差別。我只對」webapi框架搭建「項目裏用到的技術作一些說明。後續的博客會對每個技術的實現作詳細的描述。

 

JWT技術

　　考慮http的無狀態性，且又必須讓服務器能區分每次的http請求是」誰「發出的，但又不想在http請求裏攜帶不少信息（儘可能每次的請求包比較小），我採用token技術。即將用戶的基本信息，如用戶id，用戶的角色等進行加密，並附在http請求頭裏。服務器端只要對token進行解密後就能知道是誰發起的請求。以前我是本身生成token，規範token的加密/解密規則和token裏存儲的信息（如一個user實體的信息），後面發現這一技術已經有一個規則，那就是jwt。jwt參考以下網站：https://jwt.io/。

 

webapi安全

　　微軟對webapi的安全拆分爲authentication和authorization，authentication的職責是解決」用戶是誰「的問題，而authorization的職責是解決」是否有權限「的問題。經過jwt技術，能夠解決」用戶是誰「的問題，經過」基於角色的權限控制「能夠解決」是否有權限「的問題。後續的博客會詳細說明。

 

安全的」切入點「

　　咱們確定不想在每一個接口裏都去寫一段」安全代碼「，而是用aop的思想，在整個http請求的生命週期中作爲一個切面插入到生命週期的某個點上。因此先讓咱們瞭解下webapi的生命週期。以下圖。

對於在哪個環節作爲安全機制的切入點，微軟的一篇文章裏說的很好：https://msdn.microsoft.com/en-us/magazine/dn781361.aspx。我總結以下

Http Module：若是webapi的host爲iis，全部的請求會經過httpmodule，能夠建立本身的httpmodule並在該類裏寫安全機制的代碼。缺點是和iis耦合了。而咱們如今的教程裏用的是owin技術。因此先排除。

owin middleware：若是webapi的host爲owin，可建立本身的安全middleware組件，並註冊到owin管道里。只要webapi組件註冊在該組件以後就行。且這種方式有一個優勢（也能說是它的缺點），不只能夠用於webapi框架，也能夠用於其它框架的安全，只要該框架能夠註冊在owin管道里就行。

http Message handler：從上圖能夠看出，請求從httpserver出來後的第一個通道就是http message handler。微軟的這篇文章裏也提到怎麼用這種方式去實現：https://docs.microsoft.com/en-us/aspnet/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api。

action filter：能夠但不建議的方式，良好的安全通道是http請求先通過authentication再通過authorization（即要先知道這我的「是誰」才能知道他有什麼「權限」）。但從圖能夠看出action filter是在authorization filter以後，雖然能夠不用authorization filter，只用action filter，但畢竟有點怪異。

authentication filter和authorization filter：推薦的方式。