asp.net core 2.1认证

asp.net core 2.1认证

这篇文章基于asp.net core的CookieAuthenticationHandler来讲述。

认证和授权很相似,他们的英文也很相似,一个是Authentication认证,一个是Authorization授权。

asp.net core中的认证需要在Startup类中进行配置:

//ConfigureServices方法中:
 services.AddAuthentication(option =>
            {
                option.DefaultScheme = "Cookie";
                option.DefaultChallengeScheme = "Cookie";
                option.DefaultAuthenticateScheme = "Cookie";
                option.DefaultForbidScheme = "Cookie";
                option.DefaultSignInScheme = "Cookie";
                option.DefaultSignOutScheme = "Cookie";
            }).AddCookie("Cookie", option =>
            {
                option.LoginPath = "/Account/Login";
                option.AccessDeniedPath = "/Account/Forbidden";
                //.......
            });
//Configure方法中
 app.UseAuthentication();

看一看到如果需要认证的话是需要分别在ConfigureService方法和Configure方法中分别进行配置的。

我们看到上面在AddAuthentication方法中配置了一个option,这个option是一个Action<AuthenticationOption>,在里面,写了一堆scheme。这个scheme是什么意思呢?我们先解释一下在asp.neet core中发生的这几个动作。在asp.net core中是有几个动作要发生的:

1、登陆(Signin):用户要进行登陆的动作。

2、登出(Signout):用户要进行登出。

3、Challenge:这个不好翻译,意思当用户需要请求一个被保护的资源时,系统要求用户进行登陆。总之他也是一个登陆的动作,但是被动的登陆。

4、认证(Authenticate):认证,系统将用户的信息从token/cookie中读取出来。和登陆这个动作正好相反。

5、Forbid:系统对用户执行了拒绝的操作。

上面这些动作最后都是由一个Handler来执行的,这个handler就是一个IAuthenticationHandler的实现。

我们先给出了上面的总结,再看一下具体的情况。asp.net core2.0开始上面的这些动作的执行都是通过HttpContext的扩展方法来执行的。我们拿登陆来说,其他都大同小异。

先看HttpContext.SigninAsync这个方法:

            var claim = new Claim("name", "wallee");//我的众多信息中的一个信息单元,还有年龄、性别、家庭等等
            var identity = new ClaimsIdentity("身份证");//我的众多身份证件中的一个,还有驾驶证、准考证、会计证、计算机二级证等等
            identity.AddClaim(claim);//将上面那个信息片段添加到我的身份证里面
            var principal=new ClaimsPrincipal(identity);//将身份证作为我这个人的初始化参数,初始化一个ClaimsPrincipal就代表了一个主体。
            HttpContext.SignInAsync(principal);//最后,利用这个主体,调用HttpContext的扩展方法进行登陆。

上面的代码中注释解释了一些和本文无关但又非常重要的信息,我们关键看最后哪一行:HttpContext.SigninAsync(principal);这行代码实现了最终的登陆。现在我们看一下它的实现:

public static Task SignInAsync(this HttpContext context, string scheme, ClaimsPrincipal principal, AuthenticationProperties properties)
    {
      return context.RequestServices.GetRequiredService<IAuthenticationService>().SignInAsync(context, scheme, principal, properties);
}

上面的代码就是SigninAsync这个扩展方法的最终实现,之所以说是最终是因为它一开始调用的是同名的其他重载方法,但是方法内部最终调用到了这里。

可以看到一开始这个方法是从DI里面获取了一个IAuthenticationService,这个东西在services.AddAuthentication()这个方法中被注入到了DI,有兴趣的可以看一下。本文对这个不展开了。

之后,调用IAuthenticationService类型上面的SigninAsync(),这个方法要接收四个参数,都是从HttpContext.SigninAsync()方法中传进来的。

  • 一个是context,表示一个http上下文
  • 一个是scheme,表示一个方案
  • 一个是ClaimsPrincipal,表示一个主体,就是用户
  • 一个是AuthenticationProperties,用来设置一些参数比如Cookie持续时间等等

然后继续看一下IAuthenticationService.SignAsync()方法:

public virtual async Task SignInAsync(HttpContext context, string scheme, ClaimsPrincipal principal, AuthenticationProperties properties)
    {
      if (principal == null)
        throw new ArgumentNullException(nameof (principal));
      if (scheme == null)
      {
        scheme = (await this.Schemes.GetDefaultSignInSchemeAsync())?.Name;
        if (scheme == null)
          throw new InvalidOperationException("No authenticationScheme was specified, and there was no DefaultSignInScheme found.");
      }
      IAuthenticationSignInHandler handlerAsync = await this.Handlers.GetHandlerAsync(context, scheme) as IAuthenticationSignInHandler;
      if (handlerAsync == null)
        throw new InvalidOperationException(string.Format("No IAuthenticationSignInHandler is configured to handle sign in for the scheme: {0}", (object) scheme));
      await handlerAsync.SignInAsync(principal, properties);
    }

这个方法的流程是:

1、判断principal是否为null如果是则抛异常

2、如果scheme为null则从Scheme属性(IAuthenticationSchemeProvider)中找出默认的scheme的名字。

3、如果这个默认的也是null的话,就抛异常

4、利用scheme(string),和context(httpcontext)从Handlers属性(IAuthenticationHandlerProvider)中找出IAuthenticationHandler。

5、如果第四步找出的handler为空,那么抛异常。

6、如果不为空,那么,有最后得到的handler来执行Signin的动作,这个动作需要两个参数,一个是ClaimsPrincipal类型的principal,还有一个是AuthenticationProperties的properties。

总结:上面的登陆方法是从调用HttpContext的扩展方法SigninAsync开始的,最终会调用一个接收三个参数(this HttpContext context, string scheme, ClaimsPrincipal principal, AuthenticationProperties properties,context不算)的扩展方法,这个方法在内部要从DI中拿到一个IAuthenticationSerivce接口类型的对象,这个对象是对IAuthenticationScheme和对IAuthenticationHandler的一个封装。拿到这个IAuthentcationService的对象之后,调用这个对象上的SigninAsync方法,这个方法内部会先对传入的scheme参数进行一些判断,如果shcme为空,那么通过Scheme(IAuthenticationSchemeProvider)属性来查找一个默认的。如果还是空的话抛异常,接着,利用Handlers属性(IAuthenticationHandlerProvider类型)找到最终的handler:IAuthenticationHandler对象,来处理最后的登陆。

原文地址:https://www.cnblogs.com/pangjianxin/p/9388224.html

时间: 2024-10-01 00:37:57

asp.net core 2.1认证的相关文章

ASP.NET Core的身份认证框架IdentityServer4--入门【转】

原文地址 Identity Server 4是IdentityServer的最新版本,它是流行的OpenID Connect和OAuth Framework for .NET,为ASP.NET Core和.NET Core进行了更新和重新设计.在本文中,我们将快速了解IdentityServer 4存在的原因,然后直接进入并创建一个从零到英雄的工作实现. IdentityServer 3与IdentityServer 4 目前流行的一句话是"概念上兼容",但这对于Identity Se

ASP.NET Core 实现带认证功能的Web代理服务器

引言 最近在公司开发了一个项目,项目部署架构图如下: 思路 如图中文本所述,公司大数据集群不允许直接访问外网,需要一个网关服务器代理请求,本处服务器A就是边缘代理服务器的作用. 通常技术人员最快捷的思路是在服务器A上部署IIS+Application Request Routing Module组件,或者配置由Nginx代理请求完成此次边缘代理服务器的功能. 但是由于本处代理服务器A 还需要完成额外的功能: 服务器A需要定时访问外网云服务器将数据请求并保存到本地 代理服务器A集中管理云服务器B的

开源DDD设计模式框架YMNNetCoreFrameWork第二篇-增加ASp.net core Identity身份认证,JWT身份认证

1.框架增加Identity注册功能 2.框架增加identity登录以后获取JWTtoken 3.请求接口通过token请求,增加验证特性 源代码地址:https://github.com/topgunymn/YMNNetCoreFrameWork JWTtoken生成代码: private string CreateAccessToken(IEnumerable<Claim> claims, TimeSpan? expiration = null) { var now = DateTime

ASP.NET Core 认证与授权[4]:JwtBearer认证

在现代Web应用程序中,通常会使用Web, WebApp, NativeApp等多种呈现方式,而后端也由以前的Razor渲染HTML,转变为Stateless的RESTFulAPI,因此,我们需要一种标准的,通用的,无状态的,与语言无关的认证方式,也就是本文要介绍的JwtBearer认证. 目录 Bearer认证 JWT(JSON WEB TOKEN) 头部(Header) 载荷(Payload) 签名(Signature) 示例 模拟Token 注册JwtBearer认证 添加受保护资源 运行

ASP.NET Core 认证与授权[1]:初识认证

来源:https://www.cnblogs.com/RainingNight/p/introduce-basic-authentication-in-asp-net-core.html 在ASP.NET 4.X 中,我们最常用的是Forms认证,它既可以用于局域网环境,也可用于互联网环境,有着非常广泛的使用.但是它很难进行扩展,更无法与第三方认证集成,因此,在 ASP.NET Core 中对认证与授权进行了全新的设计,并使用基于声明的认证(claims-based authentication

ASP.NET Core 认证与授权[2]:Cookie认证

来源:https://www.cnblogs.com/RainingNight/p/cookie-authentication-in-asp-net-core.html 由于HTTP协议是无状态的,但对于认证来说,必然要通过一种机制来保存用户状态,而最常用,也最简单的就是Cookie了,它由浏览器自动保存并在发送请求时自动附加到请求头中.尽管在现代Web应用中,Cookie已略显笨重,但它依然是最为重要的用户身份保存方式.在 上一章 中整体的介绍了一下 ASP.NET Core 中的认证流程,而

Asp.net Core认证和授权:Cookie认证

这里我只是记录下自己在学习中的点滴和一些不懂的地方 Cookie一般是用户网站授权,当用户访问需要授权(authorization)的页面,程序会判断是否已经授权,并认证 添加认证代码:引入命名空间:Microsoft.AspNetCore.Authentication.Cookies; 添加服务 publicvoidConfigureServices(IServiceCollection services) { services.AddMvc().SetCompatibilityVersion

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

asp.net core的认证和授权

在asp.net core中,微软提供了基于认证(Authentication)和授权(Authorization)的方式,来实现权限管理的,本篇博文,介绍基于固定角色的权限管理和自定义角色权限管理,本文内容,更适合传统行业的BS应用,而非互联网应用. 固定角色: 即把角色与具体的Controller或Action直接关联起来,整个系统中的角色是固定的,每种角色可以访问那些Controller或Action也是固定的,这做法比较适合小型项目,角色分工非常明确的项目. 项目代码: https://