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时，如下：