创建声明感知型ASP.NET Web应用是否需使用Windows身份联合工具？

1. Windows身份联合工具是否必须使用？ #

答案是不是必须，但强烈推荐，尤其是在对接完整AD FS环境时：

• 这个工具的核心作用是帮你自动配置web.config中与WS-Federation身份验证相关的所有细节，包括Microsoft.IdentityModel命名空间下的配置节、信赖方的元数据地址、AD FS的STS颁发端点、受众URI等。手动配置这些内容很容易出错（比如拼写错误的端点地址、不匹配的信赖方ID），工具能帮你避免这些坑。
• 微软文档没提及它，是因为文档用的是本地STS（比如VS自带的开发STS），这类轻量STS的配置更简单，不需要工具辅助。而AD FS作为企业级身份提供商，配置项更多更复杂，工具的价值就体现出来了。
• 如果你对AD FS和ASP.NET的身份验证配置非常熟悉，完全可以手动编写web.config里的相关节点，跳过工具。但对于大多数场景，用工具能节省时间并减少配置错误。

2. 撤销工具的web.config修改后出现401错误的原因 #

这是必然的，因为工具添加的配置是你的ASP.NET应用与AD FS正常通信的核心依赖：

• 工具在web.config中写入了system.identityModel和system.identityModel.services两个关键配置节，里面包含了AD FS的STS地址、你的应用作为信赖方的唯一ID（与AD FS中配置的信赖方信任ID必须一致）、令牌验证规则等。没有这些配置，应用不知道该如何向AD FS发起认证请求，也无法验证AD FS返回的安全令牌。
• 你先运行工具再添加AD FS信赖方信任，工具已经根据你的输入生成了对应的配置信息（比如信赖方ID），而AD FS那边的信赖方信任是基于这个配置创建的。当你撤销修改后，应用的配置与AD FS的信赖方配置不再匹配，AD FS会拒绝应用的认证请求，返回401未授权。

额外补充：Claim类型兼容问题 #

你遇到的System.Security.Claims.Claim失效、Microsoft.IdentityModel.Claims.Claim正常的情况，是因为：

• 在.NET 4.5之后，System.Security.Claims是微软主推的标准Claim体系，但AD FS 2016默认返回的令牌可能仍使用旧的Microsoft.IdentityModel命名空间下的Claim类型，再加上工具配置的身份验证模块是基于旧框架的，所以两者不兼容。
• 如果你想切换到标准的System.Security.Claims，可以尝试在web.config中配置Claim类型映射，或者升级应用的身份验证组件到更现代的版本（比如使用Microsoft.Owin.Security.WsFederation中间件，不过这需要对应用做一些改造）。但在当前的.NET 4.7+AD FS 2016环境下，继续使用Microsoft.IdentityModel.Claims.Claim是最稳妥的兼容方案。

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