.NET 6中CAS外部认证用户如何基于外部数据库角色完成授权

完全可行，不需要引入ASP.NET Identity的数据库体系，原生的基于角色的授权特性（包括[Authorize(Roles = "xxx")]、User.IsInRole()方法）可以直接正常使用。

ASP.NET Core的授权体系本质是检查当前ClaimsPrincipal中是否存在类型为ClaimTypes.Role、值匹配目标角色的声明，和你是否用ASP.NET Identity存储用户、角色数据没有关系。ASP.NET Identity本身也只是内置了从自身数据表读取角色并追加对应声明的逻辑，你完全可以自己把外部查询到的角色作为标准Role声明注入到认证身份中，效果和Identity生成的完全一致。

注意：不要在Blazor组件的业务代码里直接修改AuthenticationState返回的User对象，这种修改只在当前组件上下文生效，全局授权过滤器、中间件无法感知，必须在认证管道的官方扩展点注入角色，才能全局生效。

有两种常用实现方式，根据你的业务场景选择即可：

方案1：动态加载角色（角色实时生效，适合角色变更频繁的场景） #

使用ASP.NET Core认证体系原生提供的IClaimsTransformation扩展点，这个扩展点会在每次请求认证完成后、授权执行前触发，你可以在这里动态查询用户角色并追加到身份声明中。

• 首先实现自定义声明转换类，注入你已经写好的外部角色查询服务：

  using System.Security.Claims;
  using Microsoft.AspNetCore.Authentication;
  
  public class CasRoleClaimsTransformer : IClaimsTransformation
  {
      private readonly IExternalRoleService _roleService;
      // 注入你已实现的、根据用户名查询角色的服务
      // 注意：IClaimsTransformation默认单例注册，如果你的角色服务是Scoped生命周期，请通过IServiceScope创建作用域获取
      public CasRoleClaimsTransformer(IExternalRoleService roleService)
      {
          _roleService = roleService;
      }
  
      public async Task<ClaimsPrincipal> TransformAsync(ClaimsPrincipal principal)
      {
          // 跳过未认证、非CAS认证方案的请求
          if (principal.Identity?.IsAuthenticated != true)
          {
              return principal;
          }
  
          var userName = principal.Identity.Name;
          if (string.IsNullOrWhiteSpace(userName))
          {
              return principal;
          }
  
          // 避免管道重复执行时重复追加角色声明
          var identity = (ClaimsIdentity)principal.Identity;
          if (identity.HasClaim(c => c.Type == ClaimTypes.Role))
          {
              return principal;
          }
  
          // 调用你已有的方法查询当前用户的角色列表
          var userRoles = await _roleService.GetRolesByUserNameAsync(userName);
          foreach (var role in userRoles)
          {
              identity.AddClaim(new Claim(ClaimTypes.Role, role));
          }
  
          return principal;
      }
  }
  

• 在Program.cs中注册服务，注意注册位置要放在认证配置之后、授权配置之前：

  var builder = WebApplication.CreateBuilder(args);
  
  // 保留你原有的CAS认证相关配置，不需要修改
  builder.Services.AddAuthentication(/* 你的原有CAS/Cookie认证配置 */);
  
  // 注册自定义声明转换服务
  builder.Services.AddScoped<IClaimsTransformation, CasRoleClaimsTransformer>();
  
  // 保留你原有的授权、MVC/Blazor相关配置
  builder.Services.AddAuthorization();
  builder.Services.AddRazorPages();
  builder.Services.AddServerSideBlazor();
  

这种方案的特点是每次请求都会加载最新的角色，角色变更后用户不需要重新登录就能立即生效，建议给角色查询逻辑加内存缓存，避免每次请求都访问数据库，缓存时长根据业务可设置为1-10分钟。

方案2：登录时加载角色（性能更好，适合角色变更不频繁的场景） #

如果你用Cookie作为CAS认证的本地会话存储，可以在CAS登录完成的回调事件中查询角色，把角色声明直接序列化到加密的认证Cookie中，后续请求直接从Cookie读取角色，不需要重复查询数据库。

• 实现方式是在Cookie认证配置中添加OnTicketReceived事件处理：

  builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
      .AddCookie(options =>
      {
          options.Events.OnTicketReceived = async context =>
          {
              var roleService = context.HttpContext.RequestServices
                  .GetRequiredService<IExternalRoleService>();
              
              var userName = context.Principal?.Identity?.Name;
              if (!string.IsNullOrWhiteSpace(userName))
              {
                  var roles = await roleService.GetRolesByUserNameAsync(userName);
                  var identity = (ClaimsIdentity)context.Principal!.Identity!;
                  foreach (var role in roles)
                  {
                      identity.AddClaim(new Claim(ClaimTypes.Role, role));
                  }
              }
          };
      })
      // 保留你原有的CAS认证扩展配置
      .AddCAS(/* 你的原有CAS配置参数 */);
  

这种方案的缺点是用户角色变更后，需要等待用户退出重新登录才能生效，适合权限调整频率低的业务场景。

配置完成后，你不需要修改原有授权逻辑，所有原生角色授权能力都可以直接使用：

• 控制器、Razor页面、Blazor组件上的[Authorize(Roles = "Admin")]特性会正常校验权限
• 业务代码中调用User.IsInRole("Admin")会返回正确的判断结果
• 你之前在Blazor组件中获取认证状态的代码只需要修正笔误即可正常拿到带角色的用户信息：

  private async void AuthorizeUser()
  {
      // 修正原代码中重复调用GetAuthenticationStateAsync的笔误
      var authState = await AuthenticationStateProvider.GetAuthenticationStateAsync();
      var casUserName = authState.User.Identity?.Name;
      // 直接判断角色，返回结果和ASP.NET Identity实现的效果完全一致
      var isAdmin = authState.User.IsInRole("Admin");
  }
  

内容的提问来源于stack exchange，提问作者geoCode