.NET Core 3.1自定义ClaimsPrincipal在指定认证方案的授权策略下IsInRole失效

当授权策略明确指定AddAuthenticationSchemes("Cookies")时，授权中间件会直接针对该认证方案对应的ClaimsIdentity进行角色校验——哪怕IClaimsTransformation已经执行并返回了CustomClaimsPrincipal，授权流程仍会跳过Principal层级的IsInRole方法，直接操作底层Identity的声明集合，导致你的自定义逻辑无法触发。

方案1：用自定义授权需求替代IsInRole #

放弃重写ClaimsPrincipal.IsInRole，改用自定义授权需求实现角色校验逻辑，不受认证方案指定的影响：

1. 定义自定义角色需求：

public class CustomRoleRequirement : IAuthorizationRequirement
{
    public string Role { get; }

    public CustomRoleRequirement(string role)
    {
        Role = role;
    }
}

2. 实现授权处理器：

public class CustomRoleHandler : AuthorizationHandler<CustomRoleRequirement>
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, CustomRoleRequirement requirement)
    {
        // 在这里实现你的自定义角色校验逻辑
        var isInRole = /* 你的角色判断逻辑，比如从context.User提取信息验证 */;
        if (isInRole)
        {
            context.Succeed(requirement);
        }
        return Task.CompletedTask;
    }
}

3. 注册处理器并更新授权策略：

services.AddSingleton<IAuthorizationHandler, CustomRoleHandler>();

services.AddAuthorization(options =>
{
    options.AddPolicy("X", builder =>
    {
        builder.AddAuthenticationSchemes("Cookies")
               .RequireAuthenticatedUser()
               .AddRequirements(new CustomRoleRequirement("Admin")); // 按需传入角色
    });
});

方案2：为Cookie认证方案自定义ClaimsPrincipalFactory #

直接在Cookie认证流程中生成CustomClaimsPrincipal，确保授权时使用的Principal就是你自定义的实例：

1. 实现自定义Principal工厂：

public class CustomCookieClaimsPrincipalFactory : IClaimsPrincipalFactory<AuthenticationTicket>
{
    public Task<ClaimsPrincipal> CreateAsync(AuthenticationTicket ticket)
    {
        var customPrincipal = new CustomClaimsPrincipal(ticket.Principal);
        return Task.FromResult<ClaimsPrincipal>(customPrincipal);
    }
}

2. 注册到Cookie认证方案配置：

services.AddAuthentication(options =>
{
    options.DefaultScheme = "Cookies";
})
.AddCookie("Cookies", options =>
{
    options.ClaimsPrincipalFactory = new CustomCookieClaimsPrincipalFactory();
    // 其他Cookie相关配置
})
.AddOpenIdConnect("OIDC", options =>
{
    // 你的OpenId Connect配置
});

这样Cookie认证完成后会直接生成CustomClaimsPrincipal，授权流程中调用IsInRole时会触发你的自定义逻辑。

方案3：重写ClaimsIdentity的IsInRole方法 #

如果必须保留IsInRole的调用方式，可以自定义ClaimsIdentity并重写其角色校验逻辑，在转换时替换所有Identity：

1. 实现自定义Identity：

public class CustomClaimsIdentity : ClaimsIdentity
{
    public CustomClaimsIdentity(ClaimsIdentity identity) : base(identity)
    {
    }

    public override bool IsInRole(string role)
    {
        // 在这里实现你的自定义角色判断逻辑
        return /* 你的校验逻辑 */;
    }
}

2. 修改IClaimsTransformation实现：

public Task<ClaimsPrincipal> TransformAsync(ClaimsPrincipal principal)
{
    var customIdentities = principal.Identities.Select(id => new CustomClaimsIdentity(id));
    var customPrincipal = new ClaimsPrincipal(customIdentities);
    return Task.FromResult(customPrincipal);
}

授权流程检查角色时会直接调用自定义Identity的IsInRole方法，无论是否指定认证方案。

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