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：推荐的方式。