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

老张的哲学

发布于 2022-04-11 16:43:14

4880

发布于 2022-04-11 16:43:14

文章被收录于专栏：NetCore 从壹开始

书接上文，上回咱们说到了《【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信息给下游。

01PART

网关自定义认证处理器

在网关中注册认证服务，并设计处理器，实现认证授权拦截，比如说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给传给下游服务了。

02PART

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

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

03PART

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"
  }
},

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

04PART

下游服务查看具体效果

在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这个问题，以后我会优化下，写个扩展中间件。

查看下具体的情况：