启用Windows身份验证的ASP.NET Core 5.0 MVC应用如何基于数据库更新触发通知

为什么很少找到适配Windows身份验证的相关案例：SignalR、SQL依赖这类通知能力本身完全复用ASP.NET Core的通用认证管线，和上层采用Windows认证、Cookie认证还是JWT认证没有绑定关系。网上多数案例默认配置了ASP.NET Identity的认证方案，才会出现适配逻辑和你的现有体系不兼容的问题，实际实现不需要照搬Identity的用户体系逻辑，直接复用现有Windows认证管线即可。

方案一：基于SignalR的实时推送（推荐，低延迟） #

1. 接入SignalR到现有Windows认证管线 #

• 服务注册阶段：在Startup.cs的ConfigureServices方法中，保留现有Windows认证的服务配置，仅追加SignalR的基础服务注册即可，不需要引入任何ASP.NET Identity相关的服务依赖：

// 原有Windows认证服务配置（保留不动）
services.AddAuthentication(IISDefaults.AuthenticationScheme);
// 新增SignalR服务
services.AddSignalR();

• 端点映射阶段：在Configure方法的UseEndpoints配置中，映射Hub端点并直接复用现有授权规则，不需要自定义Identity相关的授权策略：

app.UseEndpoints(endpoints => {
    // 原有MVC路由配置（保留不动）
    endpoints.MapControllerRoute(
        name: "default",
        pattern: "{controller=Home}/{action=Index}/{id?}");
    // 映射SignalR Hub，直接套用现有Windows认证的授权规则
    endpoints.MapHub<NotificationHub>("/notificationHub")
        .RequireAuthorization();
});

• 说明：Windows域环境下，SignalR的协商请求会自动携带当前登录用户的Windows凭据，鉴权逻辑和普通MVC控制器完全一致，不需要额外配置Cookie、Token的传递逻辑。

2. 实现NotificationHub的核心逻辑 #

• 不需要继承自定义的基于Identity的Hub类，直接继承标准Hub基类即可，核心是维护Windows用户名和SignalR连接Id的映射关系（多实例部署时将内存字典替换为分布式缓存即可）：

public class NotificationHub : Hub
{
    // 单机场景的连接映射缓存，多实例部署时替换为Redis等分布式实现
    private static readonly ConcurrentDictionary<string, List<string>> UserConnectionMap 
        = new ConcurrentDictionary<string, List<string>>();

    public override async Task OnConnectedAsync()
    {
        // 直接获取Windows认证返回的当前登录用户名，无需从Identity Claims中解析
        var currentWindowsUser = Context.User.Identity.Name;
        var currentConnectionId = Context.ConnectionId;
        
        // 更新映射关系
        UserConnectionMap.AddOrUpdate(
            key: currentWindowsUser,
            addValueFactory: _ => new List<string> { currentConnectionId },
            updateValueFactory: (_, existingList) => {
                existingList.Add(currentConnectionId);
                return existingList;
            });
        
        await base.OnConnectedAsync();
    }

    public override async Task OnDisconnectedAsync(Exception exception)
    {
        var currentWindowsUser = Context.User.Identity.Name;
        if (UserConnectionMap.TryGetValue(currentWindowsUser, out var connectionIds))
        {
            connectionIds.Remove(Context.ConnectionId);
            if (!connectionIds.Any())
            {
                UserConnectionMap.TryRemove(currentWindowsUser, out _);
            }
        }
        await base.OnDisconnectedAsync();
    }
}

3. 对接外部API的写库触发逻辑 #

• 你的外部API基于基本身份验证，和UI层的Windows认证完全解耦，不需要让API端单独维护SignalR客户端连接，只需要在API的POST接口完成数据库事务写入后，通过依赖注入拿到IHubContext<NotificationHub>，直接向目标用户的连接推送通知即可：

[HttpPost]
[BasicAuth] // 现有API的基本身份验证特性
public async Task<IActionResult> NewDataWrite(NewRecordDto input)
{
    // 原有业务写库逻辑
    var entity = input.ToEntity();
    await _dbContext.BusinessRecords.AddAsync(entity);
    await _dbContext.SaveChangesAsync();

    // 触发通知推送，可根据业务规则指定需要接收通知的目标Windows用户名
    var targetUser = GetAssignedOwnerUser(input);
    if (UserConnectionMap.TryGetValue(targetUser, out var connectionIds))
    {
        foreach (var connId in connectionIds)
        {
            await _hubContext.Clients.Client(connId).SendAsync(
                "ReceiveNewNotification", 
                new {
                    RecordId = entity.Id,
                    Message = "收到新的待处理业务记录",
                    CreateTime = DateTimeOffset.Now
                });
        }
    }

    return Ok();
}

方案二：基于SQL依赖的变更通知（低实时性要求场景可选） #

• 该方案完全不依赖实时通信组件，适配成本更低：
  • 在业务表上启用SQL Server查询通知，表结构发生写入变更时触发通知
  • UI端配置一个无感知轮询的MVC接口，接口本身沿用Windows认证逻辑，通过User.Identity.Name过滤出当前登录用户对应的未读通知，前端定时拉取即可
• 缺点是实时性有10~30秒的延迟，不适合对即时性要求高的场景。

常见踩坑点 #

• Windows认证场景下的跨域配置：如果UI层和API层不属于同域，SignalR的CORS配置必须显式允许凭据，不能使用AllowAnyOrigin()，否则浏览器会拦截携带Windows凭据的协商请求。
• IIS部署配置：部署时需要在IIS站点的功能配置中启用WebSocket协议，否则SignalR会自动降级为长轮询，增加服务端开销、降低实时性。
• 不要照搬ASP.NET Identity场景下的用户映射逻辑，直接使用Windows认证返回的域账号名称（格式一般为DOMAIN\username）作为用户标识即可，不需要额外关联自定义用户表。

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