System.IdentityModel.dll中KerberosSecurityTokenProvider用于WPF Kerberos认证的相关问询

可以。KerberosSecurityTokenProvider属于System.IdentityModel命名空间下的WCF安全相关API，设计初衷就包含了基于当前用户上下文或者指定凭据向KDC请求对应SPN的Kerberos服务票据的能力。你可以在构造该Provider实例时传入目标服务的SPN、客户端凭据，调用GetToken(TimeSpan)方法即可获取对应的Kerberos安全令牌，拿到的令牌可以直接注入到HTTP请求的Authorization头中（格式为Negotiate <base64编码的令牌内容>），完全可以支撑WPF应用调用Kerberos认证HTTP服务的需求。

简单使用示例：

// 目标服务的SPN，HTTP服务的SPN前缀通常为HTTP
var targetSpn = "HTTP/your.target.service.com";
var clientCredentials = new ClientCredentials();
// 如需使用当前Windows登录用户的上下文凭据，不需要额外配置
// 如需指定其他用户凭据，可放开下面的配置
// clientCredentials.Windows.ClientCredential = new NetworkCredential("用户名", "密码", "域");
var tokenProvider = new KerberosSecurityTokenProvider(targetSpn, TokenImpersonationLevel.Identification, clientCredentials);
// 请求票据
var kerberosToken = (KerberosRequestorSecurityToken)tokenProvider.GetToken(TimeSpan.FromSeconds(30));
// 转Base64后即可放入HTTP请求头
var ticketBase64 = Convert.ToBase64String(kerberosToken.GetRequest());

和Kerberos.NET、原生SSPI API相比，它的限制非常明显：

• 强绑定Windows平台：该API是.NET Framework时代的产物，仅完整支持Windows环境，如果你后续要将WPF应用迁移到.NET Core/.NET 5+的跨平台版本，该API完全不可用
• 配置灵活性极低：仅支持接入Windows本地LSASS缓存的凭据和标准AD域环境，无法自定义KDC地址、无法处理非标准Kerberos部署场景（比如对接云身份提供商的Kerberos服务、自定义票证有效期），也不支持Kerberos协议的扩展特性
• 排查难度大：API封装度过高，暴露的可观测参数极少，票据请求过程中出现的SPN不存在、域连通性异常、凭据无效等问题，返回的报错信息非常模糊，很难定位根因
• 功能边界受限：仅能完成基础的服务票据请求能力，不支持票据缓存管理、自动续期、AP_REP响应验证、复杂委派场景配置等，如果你有进阶认证需求，需要额外实现大量配套逻辑
• 生命周期停滞：该API属于WCF生态组件，微软已经多年没有对其进行功能更新，仅做基础的安全漏洞修复，后续不会新增任何特性

如果你的应用仅需要在Windows标准AD域环境下运行，认证逻辑非常简单，KerberosSecurityTokenProvider足够使用。如果需要跨平台支持、自定义Kerberos配置、更好的调试能力，优先选择Kerberos.NET；如果需要极致性能和Windows平台的底层定制能力，可以直接调用SSPI API。

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