【Blog.Core开源】网关自定义认证鉴权与传参

书接上文，上回咱们说到了《【Blog.Core开源】网关统一集成下游服务文档》，已经将多个下游服务统一集成到了网关里，并且也把接口文档Swagger给集成了，那今天就说一下认证和鉴权相关的话题。

继续说下故事背景

在平时开发的时候，特别是有网关的情况下，经常会遇到一个不可避免的话题，就是网关到底要不要帮下游处理某些业务逻辑的问题，比如说认证鉴权、审计日志、当前用户信息获取，白名单等等。

这里其实见仁见智，同时也要考虑各个项目的具体架构设计和需要，我个人的习惯还是网关要轻一些，什么叫轻一些呢，拿BlogCore举例，认证走的是Ids4的统一认证平台，从平台那里得到令牌Token，然后经过网关走到BlogCore，解析，并走具体的自定义授权逻辑，因为这里涉及到动态菜单权限配置，所以很少会放到网关里处理，毕竟每个下游服务都可能会有自己的那部分逻辑。其实除了授权这块，还有一些数据，比如当前用户的私密信息，例如手机号之类的，这个phone肯定不能放到token里的，因为token虽然有过期时间，但是就算是失效，还是可以解密出来的，放到公网上的令牌基本都是只放一些非私密的个人信息，比如uid或者是roleId，实在有需要也可以在token里放部门的id的，这也无可厚非，但是phone和address是万万不能放到token里的。

那么问题来了，phone和address我们到底应该从哪里获取？上边的菜单权限大家已经达成共识，就是放到下游，让下游服务自己来处理，那根据token中的uid来获取phone信息，就需要考虑下了，很多人说放网关呗，每次请求查库等操作，然后放到header里传递给下游，这也是一个方案，今天也会给大家讲讲怎么获取，怎么传。

当然我个人的意见还是网关仅仅是解析token里有的，传递给下游，至于查库的那些，还是下游获取吧，这是我的个人意见，并不是完全正确。为什么呢，大家想想，咱们在网关里写拦截器或者中间件，每次接口请求，都根据header中的token来查库，这样不管下游需不需要，不管下游接口是不是匿名都去查库一下，会造成资源浪费，比如我就想搜索下list，每次都查询下当前人的user信息，似乎没那么必要，特别是list页面高并发的时候，是不是不太好，当然这样的好处就是对下游方便且能做详细的审计日志。

今天咱们就说下如何自定义拦截器传递自定义claim信息给下游。

PART

网关自定义认证处理器

在网关中注册认证服务，并设计处理器，实现认证授权拦截，比如说token是否可以正常的解密等，用来判断token的有效性等，也可以查询数据库，获取私密信息：

services.AddAuthentication().AddScheme<AuthenticationSchemeOptions, CustomAuthenticationHandler>(Permissions.GWName, _ => { });

然后具体的处理器，大家根据需求自定义即可，注意把信息放到Claims里，不仅可以在当前网关的其他地方获取，从而减少二次请求的情况。也可以传递给下游服务。

public class CustomAuthenticationHandler : AuthenticationHandler<AuthenticationSchemeOptions>
{public CustomAuthenticationHandler(IOptionsMonitor<AuthenticationSchemeOptions> options,ILoggerFactory logger,UrlEncoder encoder,ISystemClock clock) : base(options, logger, encoder, clock){}protected override async Task<AuthenticateResult> HandleAuthenticateAsync(){// 可以查询数据库等操作// 获取当前用户不能放到token中的私密信息var userPhone = "15010000000";var claims = new List<Claim>(){new Claim("user-phone", userPhone),new Claim("gw-sign", "gw")};var principal = new ClaimsPrincipal(new ClaimsIdentity(claims, Scheme.Name));var ticket = new AuthenticationTicket(principal, Scheme.Name);await Task.CompletedTask;return AuthenticateResult.Success(ticket);}
}

内容很简单，就是一个普通的处理器，那接下来就是看如何把Claim给传给下游服务了。

PART

对下游服务开启认证处理器

Ocelot已经做好了配置，就像是自定义响应处理器一样，认证的也可以直接配置：

// blog-svc
{"UpstreamPathTemplate": "/svc/blog/{url}","UpstreamHttpMethod": [ "Get", "Post", "Put", "Delete" ],"LoadBalancerOptions": {"Type": "RoundRobin"},"DownstreamPathTemplate": "/svc/blog/{url}","DownstreamScheme": "http","DownstreamHostAndPorts": [{"Host": "localhost","Port": 9291}],// 直接配置认证Key即可"AuthenticationOptions": {"AuthenticationProviderKey": "GW"}
},

也可以有更多的参数配置，具体可以参考官网：

https://ocelot.readthedocs.io/en/latest/features/configuration.html?highlight=AuthenticationOptions#configuration

PART

Ocelot将Claim传递下游

还是在Ocelot的官网上可以看到很多Demo，我只配置三项，1、分别是动态从Claim中获取并用Request的Header传值，2、直接在Request中传递固定Header值，3、获取下游服务的Response的Header给上游网关。

其中第三点还是很有用的，比如我们以后的Skywalking中，如果某次链路请求报错了，但是又想快速的定位，所以就需要用户给我们提供当前操作的标识，有时候是uid，有时候是url，这两个都不是很直观。通过配置Ocelot，正好可以从下游服务的response的header中返给前端，用户就能提供了，更加快速方便的定位问题。

// blog-svc
{"UpstreamPathTemplate": "/svc/blog/{url}","UpstreamHttpMethod": [ "Get", "Post", "Put", "Delete" ],"LoadBalancerOptions": {"Type": "RoundRobin"},"DownstreamPathTemplate": "/svc/blog/{url}","DownstreamScheme": "http","DownstreamHostAndPorts": [{"Host": "localhost","Port": 9291}],// 添加到headers// 从claims中获取"AddHeadersToRequest": {"user-phone": "Claims[user-phone] > value","gw-sign": "Claims[gw-sign] > value"},// 从上游网关的request的header中"UpstreamHeaderTransform": {"custom-key": "blog.gateway"},// 从下游服务的response的header中"DownstreamHeaderTransform": {"down-app": "{para-down-app}","trace-id": "Trace-Id"},"AuthenticationOptions": {"AuthenticationProviderKey": "GW"}
},

在上边注释的三块，就是常见的三种方案。

PART

下游服务查看具体效果

在BlogCore服务中，valueController中测试下是否传递了具体的参数：

[HttpGet]
public MessageModel<List<ClaimDto>> MyClaims()
{return new MessageModel<List<ClaimDto>>(){success = true,response = (_user.GetClaimsIdentity().ToList()).Select(d =>new ClaimDto{Type = d.Type,Value = d.Value}).ToList()};
}

其中获取Claim方法，也获取了下header中其他的参数：

public IEnumerable<Claim> GetClaimsIdentity(){var claims = _accessor.HttpContext.User.Claims.ToList();var headers = _accessor.HttpContext.Request.Headers;foreach (var header in headers){claims.Add(new Claim(header.Key, header.Value));}return claims;}

这里有一个小注意事项：

如果下游服务是加权的，可以直接通过swagger添加token的方式，获取claims信息，但是接口是匿名的，那swagger是不会传递token信息的，我们可以用postman测试，一样的效果，毕竟前端Vue.js也是我们手动传递的。

关于swagger不加权就不传递token这个问题，以后我会优化下，写个扩展中间件。

查看下具体的情况：