.Net Core权限认证基于Cookie的认证&授权.Scheme、Policy扩展

在身份认证中,如果某个Action需要权限才能访问,最开始的想法就是,哪个Action需要权限才能访问,我们写个特性标注到上面即可,[TypeFilter(typeof(CustomAuthorizeActionFilterAttribute))]

/// <summary>
 /// 这是一个Action的Filter`  但是用作权限验证
 /// </summary>
 public class CustomAuthorizeActionFilterAttribute : Attribute, IActionFilter
 {
     private ILogger<CustomAuthorizeActionFilterAttribute> _logger = null;
     public CustomAuthorizeActionFilterAttribute(ILogger<CustomAuthorizeActionFilterAttribute> logger)
     {
         this._logger = logger;
     }

     public void OnActionExecuting(ActionExecutingContext context)
     {
         //取出Session
         var strUser = context.HttpContext.Session.GetString("CurrentUser");
         if (!string.IsNullOrWhiteSpace(strUser))
         {
             CurrentUser currentUser = Newtonsoft.Json.JsonConvert.DeserializeObject<CurrentUser>(strUser);
             _logger.LogDebug($"userName is {currentUser.Name}");
         }
         else
         {
             context.Result = new RedirectResult("~/Fourth/Login");
         }

     }
     public void OnActionExecuted(ActionExecutedContext context)
     {
         //context.HttpContext.Response.WriteAsync("ActionFilter Executed!");
         Console.WriteLine("ActionFilter Executed!");
         //this._logger.LogDebug("ActionFilter Executed!");
     }

 }

当然了,要先在服务里面使用Session的服务==》services.AddSession();

但是这样不好。.Net Core框架下,有一个特性Authorize,当我们需要使用的时候,在某个Action上面标注即可

 [Authorize]
 public IActionResult Center()
 {
     return Content("Center");
 }

我们来运行看一下,会报异常

因为我们没有使用服务,在.Net Core下面,是默认不启用授权过滤器的。这也是.Net Core框架的一个好处,我们需要的时候才进行使用。框架做的少,更轻。

下面我们在服务里面使用授权过滤器的服务

services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme).
    AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
o =>
    {
        o.LoginPath = new PathString("/Home/Login");
    });

再次浏览刚才的页面,这样就会请求到登录页面,会把刚才请求的页面当做一个参数

当然也要使用app.UseAuthentication();这个中间件。

在.Net Core里面,保存登录状态,也是通过Cookie的方式。使用ClaimsIdentity与ClaimsPrincipal

public ActionResult Login(string name, string password)
{
    this._ilogger.LogDebug($"{name} {password} 登陆系统");
    #region 这里应该是要到数据库中查询验证的
    CurrentUser currentUser = new CurrentUser()
    {
        Id = 123,
        Name = "Bingle",
        Account = "Administrator",
        Password = "123456",
        Email = "[email protected]",
        LoginTime = DateTime.Now,
        Role = name.Equals("Bingle") ? "Admin" : "User"
    };
    #endregion

    #region cookie
    {
        ////就很像一个CurrentUser,转成一个claimIdentity
        var claimIdentity = new ClaimsIdentity("Cookie");
        claimIdentity.AddClaim(new Claim(ClaimTypes.NameIdentifier, currentUser.Id.ToString()));
        claimIdentity.AddClaim(new Claim(ClaimTypes.Name, currentUser.Name));
        claimIdentity.AddClaim(new Claim(ClaimTypes.Email, currentUser.Email));
        claimIdentity.AddClaim(new Claim(ClaimTypes.Role, currentUser.Role));
        claimIdentity.AddClaim(new Claim(ClaimTypes.Sid, currentUser.Id.ToString()));
        var claimsPrincipal = new ClaimsPrincipal(claimIdentity);
        base.HttpContext.SignInAsync(claimsPrincipal).Wait();//不就是写到cookie
    }
    #endregion

    return View();
}

再次进行登录,我们就可以看到这样一个Cookie

在这之后,我们再去访问Genter页面,发现还是和之前返回的结果一样,还是访问不到。这是为什么呢?是因为我们在Action上面打的标签[Authorize],什么都没给,我们做下修改

 [Authorize(AuthenticationSchemes = CookieAuthenticationDefaults.AuthenticationScheme)]
 public IActionResult Center()
 {
     return Content("Center");
 }

现在我们再次进行访问,发现就可以访问成功了

通过User.FindFirstValue(ClaimTypes.Sid);这种方式,可以获取到我们存入的值。

Scheme、Policy扩展

Scheme

#region 设置自己的schema的handler
 services.AddAuthenticationCore(options => options.AddScheme<MyHandler>("myScheme", "demo myScheme"));
 #endregion
 #region  Schame 验证

 services.AddAuthentication(options =>
 {
     options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;// "Richard";//
 })
 .AddCookie(options =>
 {
     options.LoginPath = new PathString("/Fourth/Login");// 这里指定如果验证不通过就跳转到这个页面中去
     options.ClaimsIssuer = "Cookie";
 });

Policy

 #region 支持 policy 认证授权的服务  

 // 指定通过策略验证的策略列
 services.AddSingleton<IAuthorizationHandler, AdvancedRequirement>();

 services.AddAuthorization(options =>
 {
     //AdvancedRequirement可以理解为一个别名
     options.AddPolicy("AdvancedRequirement", policy =>
     {
         policy.AddRequirements(new NameAuthorizationRequirement("1"));
     });
 }).AddAuthentication(options =>
 {
     options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
 })
 .AddCookie(options =>
 {
     options.LoginPath = new PathString("/Fourth/Login");
     options.ClaimsIssuer = "Cookie";
 });

 #endregion

还需要在Configure方法中对中间件进行使用

app.UseSession();
app.UseCookiePolicy(); //
app.UseAuthentication(); // 标识在当前系统中使用这个权限认证

原文地址:https://www.cnblogs.com/taotaozhuanyong/p/11594931.html

时间: 2024-10-08 09:25:56

.Net Core权限认证基于Cookie的认证&授权.Scheme、Policy扩展的相关文章

网络安全之身份认证---基于口令的认证

基于口令的认证方式是较常用的一种技术.在最初阶段,用户首先在系统中注册自己的用户名和登录口令.系统将用户名和口令存储在内部数据库中,注意这个口令一般是长期有效的,因此也称为静态口令.当进行登录时,用户系统产生一个类似于时间戳的东西,把这个时间戳使用口令和固定的密码算法进行加密,连同用户名一同发送给业务平台,业务平台根据用户名查找用户口令进行解密,如果平台能恢复或接收到那个被加密的时间戳,则对解密结果进行比对,从而判断认证是否通过:如果业务平台不能获知被加密的时间戳,则解密后根据一定规则(如时间戳

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作为我们的主站肯定是可以匿名访问

将 Shiro 作为应用的权限基础 三:基于注解实现的授权认证过程

授权即访问控制,它将判断用户在应用程序中对资源是否拥有相应的访问权限. 如,判断一个用户有查看页面的权限,编辑数据的权限,拥有某一按钮的权限等等. 一.用户权限模型 为实现一个较为灵活的用户权限数据模型,通常把用户信息单独用一个实体表示,用户权限信息用两个实体表示. 用户信息用 LoginAccount 表示,最简单的用户信息可能只包含用户名 loginName 及密码 password 两个属性.实际应用中可能会包含用户是否被禁用,用户信息是否过期等信息. 用户权限信息用 Role 与 Per

JavaWeb--Servlet过滤器Filter和SpringMVC的HandlerInterceptor(Session和Cookie登录认证)

拦截一些请求进行处理,比如通过它来进行权限验证,或者是来判断用户是否登陆,日志记录,编码,或者限制时间点访问等等,是非常有必要的.所以就有了此篇文章啦. 文章结构:(1)Servlet过滤器Filter:(2)SpringMVC的HandlerInterceptor:(3)对比认知. 一.Servlet过滤器Filter: 此部分是从赵四大佬那里学来的,并补充自己的认知 (1)概念: 能够对Servlet容器的请求和响应对象进行检查和修改. Servlet过滤器本身并不产生请求和响应对象,它只能

使用 AngularJS &amp; NodeJS 实现基于 token 的认证应用(转)

认证是任何 web 应用中不可或缺的一部分.在这个教程中,我们会讨论基于 token 的认证系统以及它和传统的登录系统的不同.这篇教程的末尾,你会看到一个使用 AngularJS 和 NodeJS 构建的完整的应用. 一.传统的认证系统 在开始说基于 token 的认证系统之前,我们先看一下传统的认证系统. 用户在登录域输入 用户名 和 密码 ,然后点击 登录 : 请求发送之后,通过在后端查询数据库验证用户的合法性.如果请求有效,使用在数据库得到的信息创建一个 session,然后在响应头信息中

Openssl建立CA,在组织内部基于ca的认证

Openssl建立CA,在组织内部基于ca的认证 1.给自己生成一对密钥 2.自签署证书 节点:1.生成密钥对   2.申城证书签署请求    3.把请求发送给CA CA: 1.验证请求者信息     2.签署证书 一.建立CA服务器 /etc/pki/CA/private用于存放CA的私钥 1.(umask 077:openssl genrsa -out /etc/pki/private/cakey.pem 2048)   生成密钥 2.req -x509 自签署证书,常用于CA自己签署自己的

使用 AngularJS & NodeJS 实现基于 token 的认证应用

传统的认证系统 在开始说基于 token 的认证系统之前,我们先看一下传统的认证系统. 用户在登录域输入 用户名 和 密码 ,然后点击 登录 : 请求发送之后,通过在后端查询数据库验证用户的合法性.如果请求有效,使用在数据库得到的信息创建一个 session,然后在响应头信息中返回这个 session 的信息,目的是把这个 session ID 存储到浏览器中: 在访问应用中受限制的后端服务器时提供这个 session 信息: 如果 session 信息有效,允许用户访问受限制的后端服务器,并且

[转]asp.net权限认证:HTTP基本认证(http basic)

本文转自:http://www.cnblogs.com/lanxiaoke/p/6353955.html HTTP基本认证示意图 HTTP基本认证,即http basic认证. 客户端向服务端发送一个携带基于用户名/密码的认证凭证的请求.认证凭证的格式为“{UserName}:{Password}”,并采用Base64编码,经过编码的认证凭证被存放在请求报头Authorization中,Authorization报头值类似:Basic MTIzNDU2OjEyMzQ1Ng==.服务端接收到请求之

openssh远程登录服务器端和基于密钥的认证机制

ssh服务的最佳实践方案:1.更换服务端口,不要使用默认的22号端口:2.禁止使用sshv1:3.合理的设置登录用户的黑名单和白名单:4.设置空闲会话的超时时间,将其改的短一些:5.需要利用防火墙来配合设置ssh的安全访问规则:6.监听固定的IP地址而不是0.0.0.0:7.如果必须使用口令认证机制,则需要使用足够复杂的密码:~]# tr -dc A-Za-z0-9 < /dev/urandom | head -c 30 | xargs~]# openssl rand -base64 30 |