asp.net core 认证及简单集群

众所周知，在Asp.net WebAPI中，认证是通过AuthenticationFilter过滤器实现的，我们通常的做法是自定义AuthenticationFilter，实现认证逻辑，认证通过，继续管道处理，认证失败，直接返回认证失败结果，类似如下：

public async Task AuthenticateAsync(HttpAuthenticationContext context, CancellationToken cancellationToken)
        {
            var principal = await this.AuthenticateAsync(context.Request);
            if (principal == null)
            {
                context.Request.Headers.GetCookies().Clear();
                context.ErrorResult = new AuthenticationFailureResult("未授权请求", context.Request);
            }
            else
            {
                context.Principal = principal;
            }
        }

但在.net core中，AuthenticationFilter已经不复存在，取而代之的是认证中间件。至于理由，我想应该是微软觉得Authentication并非业务紧密相关的，放在管道中间件中更合适。那么，话说回来，在.net core中，我们应该怎么实现认证呢？如大家所愿，微软已经为我们提供了认证中间件。这里以CookieAuthenticationMiddleware中间件为例，来介绍认证的实现。

1、引用Microsoft.AspNetCore.Authentication.Cookies包。项目实践中引用的是"Microsoft.AspNetCore.Authentication.Cookies": "1.1.0"。

2、Startup中注册及配置认证、授权服务：

服务注册：

services.AddMvc(options =>
            {
                //添加模型绑定过滤器
                options.Filters.Add(typeof(ModelValidateActionFilter));

                //添加授权过滤器，以便强制执行Authentication跳转及屏蔽逻辑
                //var policy = new AuthorizationPolicyBuilder().RequireAuthenticatedUser().Build();
                var policy = new AuthorizationPolicyBuilder().AddRequirements(new AuthenticationRequirement()).Build();
                options.Filters.Add(new AuthorizeFilter(policy));
            });

            //services.AddAuthorization(options =>
            //{
            //    options.AddPolicy("RequireAuthentication", policy => policy.AddRequirements(new AuthenticationRequirement()));
            //});

大家注意，上面代码中有两处注释掉的地方。第一处注释，RequireAuthenticatedUser()是.net core预定义的授权验证，代表通过授权验证的最低要求是提供经过认证的Identity。Demo中，我的要求也是这个，只要是经过基本认证的用户即可，那为什么Demo中没有使用呢？因为这里是个坑！实际实践中，我发现，采用注释中的做法，无论如何，调用总是返回401，迫不得已，download认证及授权源码，发现该处逻辑是这样的：

var user = context.User;
            var userIsAnonymous =
                user?.Identity == null ||
                !user.Identities.Any(i => i.IsAuthenticated);
            if (!userIsAnonymous)
            {
                context.Succeed(requirement);
            }

加入断点猛调，发现IsAuthenticated永远是false！！！迫不得已，反编译查看源码，发现ClaimsIdentity的IsAuthenticated属性是这样定义的：

WTF！！！坑爹么这是！！！.net framework中， 记得 这里的逻辑是，只要Name非空，就返回true，到了.net core中成了这样，你说坑不坑。。。

那怎么办？总不能放弃吧？我想，大家第一想法应该是继承ClaimsIdentity自定义一个Identity，尤其是看到属性上那个virtual的时候，我也不例外。可继承后， 发现认证框架那儿依然不认，还是一直返回false，可能是我哪里用的不对吧。所以，Startup中第一处注释出现了。最终解决方案是自定义AuthenticationRequirement及处理器，实现要求的验证，如下：

public class AuthenticationRequirement : AuthorizationHandler<AuthenticationRequirement>, IAuthorizationRequirement
    {
        protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, AuthenticationRequirement requirement)
        {
            var user = context.User;
            var userIsAnonymous =
                user?.Identity == null
                || string.IsNullOrWhiteSpace(user.Identity.Name);
            if (!userIsAnonymous)
            {
                context.Succeed(requirement);
            }
            return TaskCache.CompletedTask;
        }
    }

 上述代码红色的部分便是相对默认实现变化的部分。

startup中第二部分注释，是注册授权策略的，注册方法也是官网文档中给出的注册方法。那为什么这里又没有采用呢？因为，如果按注释中的方法配置，我需要在每个希望认证的控制器或方法上都用Authorize标记，甚至还需要在特性上配置角色或策略，而这里我的预设是全局认证，所以，直接以全局过滤器的形式添加到了MVC处理管道中。读到这里，细心的读者应该有疑问了，你一个简单的认证，跟授权毛线关系啊，注册授权过滤器作甚！我也觉得没关系啊，这是net core认证的第二个坑，那就是，在.net core或者微软看来，认证仅仅提供Principal的生成、序列化、反序列化及重新生成Principal，它的职责确实也包括了返回401、403等各种认证失败信息，但这部分不会主动触发，必须有处理管道中其他逻辑去触发。我仔细阅读了官网文档，得出的大致结论是，.net core大概认为，认证是个多样化的过程，不光有我们目前看到的或需要的某一种认证，实际需求中很可能会多种认证并存，我们的API也可能会同时允许多种认证方式通过，所以某一种认证失败就直接返回401或403是错误的。这是实践当中第二个坑！那话说回来，添加了授权，就可以触发这个过程，这个是看源码发现的，具体流程就是，如果授权失败，过滤器会返回一个challengeResult，这个Result最终会跑到认证中间件中的对应Challenge方法，在.net core源码中表现如下：

public async Task ChallengeAsync(ChallengeContext context)
        {
            ChallengeCalled = true;
            var handled = false;
            if (ShouldHandleScheme(context.AuthenticationScheme, Options.AutomaticChallenge))
            {
                switch (context.Behavior)
                {
                    case ChallengeBehavior.Automatic:
                        // If there is a principal already, invoke the forbidden code path
                        var result = await HandleAuthenticateOnceSafeAsync();
                        if (result?.Ticket?.Principal != null)
                        {
                            goto case ChallengeBehavior.Forbidden;
                        }
                        goto case ChallengeBehavior.Unauthorized;
                    case ChallengeBehavior.Unauthorized:
                        handled = await HandleUnauthorizedAsync(context);
                        Logger.AuthenticationSchemeChallenged(Options.AuthenticationScheme);
                        break;
                    case ChallengeBehavior.Forbidden:
                        handled = await HandleForbiddenAsync(context);
                        Logger.AuthenticationSchemeForbidden(Options.AuthenticationScheme);
                        break;
                }
                context.Accept();
            }

            if (!handled && PriorHandler != null)
            {
                await PriorHandler.ChallengeAsync(context);
            }
        }

以其中HandleForbiddenAsync为例，具体又如下：

/// <summary>
        /// Override this method to deal with a challenge that is forbidden.
        /// </summary>
        /// <param name="context"></param>
        protected virtual Task<bool> HandleForbiddenAsync(ChallengeContext context)
        {
            Response.StatusCode = 403;
            return Task.FromResult(true);
        }

这样，经由授权流程触发Challenge，Challenge返回相应验证结果到API调用方。

注册完了认证及授权所需相关服务，接下来注册中间件，如下：

app.UseCookieAuthentication(new CookieAuthenticationOptions
            {
                AuthenticationScheme = "GuoKun",
                AutomaticAuthenticate = true,
                AutomaticChallenge = true,
                DataProtectionProvider = DataProtectionProvider.Create(new DirectoryInfo(env.ContentRootPath))
            });

app.UseMvc();

注意UseCookieAuthentication要放在UseMvc前面。大家注意其中红色部分，这里为什么要自己手动创建DataProtectionProvider呢？因为这里是要做服务集群的，如果单机或单服务实例情况下，采用默认DataProtection机制就可以了。代码中手动指定目录创建，与默认实现的区别就是，默认实现会生成一个与当前机器及应用相关的key进行数据加解密，而手动指定目录创建provider，会在指定的目录下生成一个key的xml文件。这样，服务集群部署时候，加解密key一样，加解密得到的报文也是一致的。别问我怎么知道的，踩过坑，使劲儿调试，外加看官网文档，泪流满面。。。

3、添加控制器模拟登陆及认证授权

[Route("api/[controller]")]
    public class AccountController : Controller
    {
        [AllowAnonymous]
        [HttpPost("login")]
        public async Task Login([FromBody]User user)
        {
            IEnumerable<Claim> claims = new List<Claim>()
                {
                    new Claim(ClaimTypes.Name, user.UID)
                };

            await HttpContext.Authentication.SignInAsync("GuoKun",
                new ClaimsPrincipal(new ClaimsIdentity(claims)));
        }

        [HttpGet("serverresponse")]
        public ContentResult ServerResponse()
        {
            return this.Content($"来自{((Microsoft.AspNetCore.Server.Kestrel.Internal.Http.ConnectionContext)this.HttpContext.Features).LocalEndPoint.ToString()}的响应：{this.User.Identity.Name ?? "匿名"}，您好");
        }
    }

因为授权现在是全局的，所以在登陆方法上用AllowAnonymous标记，跳过认证及授权。

在ServerResponse方法中，返回当前服务实例绑定的IP及端口号。由于本Demo是采用ANCM寄宿在IIS中的，所以具体服务实例绑定的端口是动态的。

4、部署。具体在IIS中的部署如下：

三个站点的端口分别为9001,9002,9003，具体运行时，ANCM会将IIS的请求代理到KestrlServer。

5、Nginx负载均衡配置：

upstream guokun    {
        server localhost:9001;
        server localhost:9002;
        server localhost:9003;
    }

    server {
        listen       9000;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            root   html;
            index  index.html index.htm;
            proxy_pass http://guokun;
        }

这个比较简单，不废话。

6、运行效果：

这里采用Postman模拟请求。当未调用登录API，直接请求api/Account/serverresponse时，如下：

可以看到，直接401了，而且，响应标头中，有个Location，这个是challenge中默认实现的，告诉我们需要去登录认证，认证完了会跳转到当前请求资源url（在MVC中尤其有用）。

接下来，登录：

我们可以看到，登录成功，而且，服务端返回了加密及序列化后的凭证。接下来，我们再请求api/Account/serverresponse：

 

看到没，请求成功。那么多请求几次，分别得到如下结果：

可以看见，请求已经被负载到了不同的服务实例。

有人会问，为什么不部署在多台不同服务器上啊，搞一台机器在那儿模拟。哥没那么多钱整那么多台机器啊，而且，装虚拟机，配置撑不了，望大神勿喷勿吐槽。

如此，一个简易的基于asp.net core，带认证，具有集群负载的后端，便实现了。

补充说明：

之前，由于网络原因，ClaimsIdentity部分没有下载源码，而是直接反编译的方式查看，导致得出ClaimsIdentity.IsAuthenticated总是返回false的结论，在此更正，并特别感谢Savorboard大神的特别指正。经过翻阅Github上源码，该属性是这样定义的：

/// <summary>
        /// Gets a value that indicates if the user has been authenticated.
        /// </summary>
        public virtual bool IsAuthenticated
        {
            get { return !string.IsNullOrEmpty(_authenticationType); }
        }

之前一直返回false，则是由于登录成功构建ClaimsIdentity时没有指定AuthenticationType。弄清楚了这个，那么对应授权策略的注册，就可以采用如下方式了：

 services.AddMvc(options =>
            {
                //添加模型绑定过滤器
                options.Filters.Add(typeof(ModelValidateActionFilter));

                //添加授权过滤器，以便强制执行Authentication跳转及屏蔽逻辑
                var policy = new AuthorizationPolicyBuilder().RequireAuthenticatedUser().Build();
                //var policy = new AuthorizationPolicyBuilder().AddRequirements(new AuthenticationRequirement()).Build();
                options.Filters.Add(new AuthorizeFilter(policy));
            });

相应地，在登录成功后，构建ClaimsIdentity时指定其AuthenticationType：

await HttpContext.Authentication.SignInAsync("GuoKun",
                new ClaimsPrincipal(new ClaimsIdentity(claims, "GuoKun")));