.NET MVC中指定WebMethod强制Windows认证的配置及授权特性选择

web.config 核心配置 #

首先要满足“全局匿名可用，受限资源触发Windows认证”的混合模式要求，不能把全局认证规则改成只允许Windows用户，否则其他正常匿名访问的页面都会被拦截。
需要按粒度配以下规则：

• 全局基础配置
  • system.web/authorization节点保持全局允许所有用户的规则：<allow users="*" />，不要加全局的<deny users="?" />。
  • system.webServer/security/authentication节点下，确保anonymousAuthentication和windowsAuthentication的enabled属性都设为true，两个认证模块都要保留，不能移除Windows认证模块——否则就算配置了拒绝匿名，也不会触发401认证弹窗流程。
• 分粒度的路径授权
  • 如果可以将整个Default.aspx页面（包括页面本身、所有内嵌WebMethod）都纳入Windows认证范围：在web.config中新增独立的<location path="Default.aspx">节点，节点内部配置授权规则为禁止匿名用户：<deny users="?" />。配置生效后，所有访问该路径的匿名请求会被IIS管道拦截，自动返回带WWW-Authenticate响应头的401状态码，浏览器会直接弹出Windows凭据输入框；用户输入正确凭据后，浏览器会自动缓存当前域名的NTLM/Negotiate票据，后续同站点的Windows认证请求会自动携带票据，无需重复验证。
  • 如果需要保留Default.aspx页面的匿名访问能力，仅对retr_key这个WebMethod强制Windows认证：不要在web.config中锁定Default.aspx路径。因为静态WebMethod没有独立的物理路由路径，根本无法通过web.config的location规则精准到单个方法，配置层拦截的粒度到不了这个级别。

代码端授权逻辑 #

这里要避一个高频坑：MVC框架自带的[Authorize]特性对WebForm静态WebMethod完全不生效。这类WebMethod的执行管道阶段早于MVC授权过滤器的挂载时机，就算在方法上标注了[Authorize]，程序运行时根本不会执行对应的校验逻辑，相当于白写。
对应到仅拦截单个WebMethod的场景，直接在方法内部写校验逻辑即可：

• 方法最开头判断当前请求的HttpContext.Current.Request.LogonUserIdentity.IsAnonymous属性，如果检测到是匿名访问，直接构造401响应：把响应状态码设为401，添加WWW-Authenticate: Negotiate, NTLM响应头，直接结束当前请求，浏览器收到响应后就会弹出Windows凭据输入框。
• 校验通过后再执行原本的业务逻辑返回结果。

常见踩坑点 #

• 不要开启Windows认证的“扩展保护”选项，如果客户端存在老旧浏览器，会导致认证流程校验失败，出现反复弹窗的问题。
• 必须保证IIS的Windows认证开启“内核模式认证”，否则浏览器的认证票据缓存会失效，就算用户验证通过，后续请求依然会被要求重新输入凭据。
• 如果AJAX调用是跨域发起的，需要手动设置请求对象的withCredentials = true，否则浏览器不会自动携带缓存的Windows认证票据，导致验证逻辑失效。

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