.Net Core 2.0 preview1实现自定义认证方案

Microsoft.Authentication的使用方法在2.0中发生了比较大的变化,在1.1中认证配置是在Configure中完成。

public void ConfigureServices(IServiceCollection services)
{
  services.AddAuthentication();
}

public void Configure(IApplicationBuilder app)
{
  app.UseJwtBearerAuthentication(new JwtBearerOptions
  {
  Authority = Configuration["jwt:authority"],
  Audience = Configuration["jwt:audience"],
  Events = new JwtBearerEvents()
  {
    OnAuthenticationFailed = c =>
    {
      c.HandleResponse();
      c.Response.StatusCode = 500;
      c.Response.ContentType = "text/plain";
      if (Environment.IsDevelopment())
      {
        return c.Response.WriteAsync(c.Exception.ToString());
      }
      return c.Response.WriteAsync("An error occurred processing your authentication.");
    }  
  }
});

UseJwtBearerAuthentication其实是添加了一个中间件

        public static IApplicationBuilder UseJwtBearerAuthentication(this IApplicationBuilder app, JwtBearerOptions options)
        {
            if (app == null)
            {
                throw new ArgumentNullException(nameof(app));
            }
            if (options == null)
            {
                throw new ArgumentNullException(nameof(options));
            }

            return app.UseMiddleware<JwtBearerMiddleware>(Options.Create(options));
        }

而在2.0中,认证配置则是在ConfigureServices中完成,并且通过Scheme-Handler的形式来实现多种认证方案的策略式选择。

public void ConfigureServices(IServiceCollection services)
{
  services.AddJwtBearerAuthentication(o =>
  {
    o.Authority = Configuration["jwt:authority"];
    o.Audience = Configuration["jwt:audience"];
    o.Events = new JwtBearerEvents()
    {
      OnAuthenticationFailed = c =>
      {
              c.HandleResponse();
              c.Response.StatusCode = 500;
              c.Response.ContentType = "text/plain";
              if (Environment.IsDevelopment())
              {
                  return c.Response.WriteAsync(c.Exception.ToString());
              }
              return c.Response.WriteAsync("An error occurred processing your authentication.");
          }
       };
    });
}

public void Configure(IApplicationBuilder app)
{
    app.UseAuthentication();
}  
public static IServiceCollection AddJwtBearerAuthentication(this IServiceCollection services, string authenticationScheme, Action<JwtBearerOptions> configureOptions)
{
    return services.AddScheme<JwtBearerOptions, JwtBearerHandler>(authenticationScheme, configureOptions);
}
public static IApplicationBuilder UseAuthentication(this IApplicationBuilder app)
{
  if (app == null)
   {
     throw new ArgumentNullException(nameof(app));
   }
   return app.UseMiddleware<AuthenticationMiddleware>();
}
namespace Microsoft.AspNetCore.Authentication
{
    public class AuthenticationMiddleware
    {
        private readonly RequestDelegate _next;

        public AuthenticationMiddleware(RequestDelegate next, IAuthenticationSchemeProvider schemes)
        {
            if (next == null)
            {
                throw new ArgumentNullException(nameof(next));
            }
            if (schemes == null)
            {
                throw new ArgumentNullException(nameof(schemes));
            }

            _next = next;
            Schemes = schemes;
        }

        public IAuthenticationSchemeProvider Schemes { get; set; }

        public async Task Invoke(HttpContext context)
        {
            context.Features.Set<IAuthenticationFeature>(new AuthenticationFeature
            {
                OriginalPath = context.Request.Path,
                OriginalPathBase = context.Request.PathBase
            });

            // REVIEW: alternatively could depend on a routing middleware to do this

            // Give any IAuthenticationRequestHandler schemes a chance to handle the request
            var handlers = context.RequestServices.GetRequiredService<IAuthenticationHandlerProvider>();
            foreach (var scheme in await Schemes.GetRequestHandlerSchemesAsync())
            {
                var handler = await handlers.GetHandlerAsync(context, scheme.Name) as IAuthenticationRequestHandler;
                if (handler != null && await handler.HandleRequestAsync())
                {
                    return;
                }
            }

            var defaultAuthenticate = await Schemes.GetDefaultAuthenticateSchemeAsync();
            if (defaultAuthenticate != null)
            {
                var result = await context.AuthenticateAsync(defaultAuthenticate.Name);
                if (result?.Principal != null)
                {
                    context.User = result.Principal;
                }
            }

            await _next(context);
        }
    }
}

  

也就是说,1.1的时候我们使用不同的认证方案时,是使用不同的中间件来实现认证,而2.0则刚好反过来,官方实现了一个统一的认证中间件,在中间件里获取对应的Scheme的Handler,然后调用Handler来完成认证过程。

在2.0中实现自己的认证方案非常方便——自己实现一个AuthenticationSchemeOptions和一个AuthenticationHandler,然后通过AddScheme注入并指定Scheme就可以了。

以官方JwtBearerAuthentication为例:

源码在此:https://github.com/aspnet/Security/tree/rel/2.0.0-preview1/src/Microsoft.AspNetCore.Authentication.JwtBearer

在ConfigureServices中调用AddJwtBearerAuthentication,其实是调用了AddScheme,authenticationScheme是JwtBearerDefaults.AuthenticationScheme。

JwtBearerOptions是继承AuthenticationSchemeOptions的类,用来保存认证配置。

JwtBearerHandler继承了AuthenticationHandler<JwtBearerOptions>,用于认证过程处理,需要什么依赖,直接从构造函数注入。关键在HandleAuthenticateAsync和HandleUnauthorizedAsync这两个方法。

认证流程是这样的:

1. ConfigureServices中调用AddScheme提供<AuthenticationSchemeOptions,AuthenticationHandler>并指定Scheme。

2. Configure中调用UseAuthentication。

3. 访问一个带有AuthorizeAttribute的Action。

4. AuthenticationMiddleware获取默认Scheme(或者AuthorizeAttribute指定的Scheme)的AuthenticationHandler,调用到Handler的HandleAuthenticateAsync,根据返回结果来决定是调用HandleUnauthorizedAsync还是HandleForbiddenAsync。

我们自己实现认证方案主要就是要实现HandleAuthenticateAsync这个方法,想怎么认证就怎么写。

时间: 2024-11-06 03:42:21

.Net Core 2.0 preview1实现自定义认证方案的相关文章

EntityFramework Core 2.0自定义标量函数两种方式

前言 上一节我们讲完原始查询如何防止SQL注入问题同时并提供了几种方式.本节我们继续来讲讲EF Core 2.0中的新特性自定义标量函数. 自定义标量函数两种方式 在EF Core 2.0中我们可以将方法映射到数据库中的标量函数,我们可在LINQ中调用此方法并会被正确翻译成SQL语句,这为编写数据访问层的开发人员提供了一个很棒的功能来创建一个方法并在其上应用DbFunction特性即可.该属性会将静态CLR方法映射到数据库函数,以便可以在LINQ查询中使用此方法.默认情况下,数据库函数中的CLR

asp.net core 2.0 web api基于JWT自定义策略授权

JWT(json web token)是一种基于json的身份验证机制,流程如下: 通过登录,来获取Token,再在之后每次请求的Header中追加Authorization为Token的凭据,服务端验证通过即可能获取想要访问的资源.关于JWT的技术,可参考网络上文章,这里不作详细说明, 这篇博文,主要说明在asp.net core 2.0中,基于jwt的web api的权限设置,即在asp.net core中怎么用JWT,再次就是不同用户或角色因为权限问题,即使援用Token,也不能访问不该访

asp.net core 自定义认证方式--请求头认证

原文:asp.net core 自定义认证方式--请求头认证 asp.net core 自定义认证方式--请求头认证 Intro 最近开始真正的实践了一些网关的东西,最近写几篇文章分享一下我的实践以及遇到的问题. 本文主要介绍网关后面的服务如何进行认证. 解决思路 网关可以做一部分的认证和授权,服务内部有时候也会需要用户的信息,这时该怎么办呢,我们使用的是 JWT 认证,有一个 identity server去颁发,验证 token,一种简单方式可以把 token 直接往后传,传递给后面的具体某

ASP.NET Core 2.0使用Cookie认证实现SSO单点登录

之前写了一个使用ASP.NET MVC实现SSO登录的Demo,https://github.com/bidianqing/SSO.Sample,这个Demo是基于.NET Framework,.NET Core 2.0出来了试着使用ASP.NET Core尝试一下.假如我们有三个站点 domain.dev order.domain.dev passport.domain.dev domain.dev作为我们的主站肯定是可以匿名访问的,当点击登录按钮的时候就会跳转到passport.domain

NET Core 2.0使用Cookie认证实现SSO单点登录

NET Core 2.0使用Cookie认证实现SSO单点登录 之前写了一个使用ASP.NET MVC实现SSO登录的Demo,https://github.com/bidianqing/SSO.Sample,这个Demo是基于.NET Framework,.NET Core 2.0出来了试着使用ASP.NET Core尝试一下.假如我们有三个站点 domain.dev order.domain.dev passport.domain.dev domain.dev作为我们的主站肯定是可以匿名访问

ASP.NET Core 2.0利用Jwt实现授权认证

背景 在微服务架构下,一般都会按不同的业务或功能将整个系统切分成不同的独立子系统,再通过REST API或RPC进行通讯并相互调用,形成各个子系统之间的串联结构.在这里,我们将采用REST API的通讯方式.比如: 1.有一个“用户中心”独立子系统名为“Lezhima.UserHub”,是一个基于ASP.NET Core mvc 2.0的项目. 2.有一个处理用户订单的独立子系统名为“Lezhima.UserOrder”,是一个基于ASP.NET Core webp api 2.0的项目. 3.

.net core 3.0 Signalr - 07 业务实现-服务端 自定义管理组、用户、连接

## Hub的管理 - 重写OnConnectedAsync 从连接信息中获取UserId.Groups,ConnectId,并实现这三者的关系,存放于redis中 [代码请查看](https://github.com/xiexingen/CTS.Signalr/blob/master/CTS.Signalr.Server/Hubs/NotifyHub.cs) ``` C# using CTS.Signalr.Server.Cores; using CTS.Signalr.Server.Dtos

C# 6 与 .NET Core 1.0 高级编程 - 41 ASP.NET MVC(上)

译文,个人原创,转载请注明出处(C# 6 与 .NET Core 1.0 高级编程 - 41 ASP.NET MVC(上)),不对的地方欢迎指出与交流. 章节出自<Professional C# 6 and .NET Core 1.0>.水平有限,各位阅读时仔细分辨,唯望莫误人子弟. 附英文版原文:Professional C# 6 and .NET Core 1.0 - Chapter 41 ASP.NET MVC ------------------------------------ 本

springSecurity自定义认证配置

上一篇讲了springSecurity的简单入门的小demo,认证用户是在xml中写死的.今天来说一下自定义认证,读取数据库来实现认证.当然,也是非常简单的,因为仅仅是读取数据库,权限是写死的,因为相对简单,没几个角色,就直接写死了. 还有就是加密,使用的是框架自带的   BCryptPasswordEncoder   加密方法.存在数据库的用户密码也是通过这个类加密,然后登陆的时候也是通过这个类验证,需要在xml中配置下就ok. 简单说一下这个加密类.比md5更加的高级. 加密分为  : 可逆