Web API中的客户端证书和基于声明的身份验证

Question

如果一个客户端通过HTTPS访问一个作为ASP.NET Web API控制器实现的终结点并提供了客户端证书，那么该证书可以通过Request.GetClientCertificate获得。但是，我在想：是否有可能获取以声明为基础的模型所提供的信息，该模型已与.NET 4.5中的安全模型集成？

我想这样做的主要原因是，我需要不同的客户端能够以不同的方式进行身份验证以访问相同的服务，因此我更喜欢抽象出具体的内容，例如证书。我希望我的控制器能够基于当前用户的声明来做出决策，而不用考虑这些声明的来源。

我知道有一个X509CertificateClaimSet类型，它使得自然流程似乎是：

1. 通过TLS/SSL传递的客户端证书通过某种令牌映射过程（类似于您可以用于ACS的联合提供程序生成的传入cookie由SessionSecurityTokenHandler处理）被表示为X509CertificateClaimSet 2. 声明变换模块（从ClaimsAuthenticationManager派生的东西，并配置了一个<claimsAuthenticationManager>元素）检查来自证书的声明集，并将其转换为非令牌特定的应用程序特定声明 3. 处理程序查找应用程序特定声明。

甚至有一个X509SecurityTokenHandler，听起来它应该这样做。然而，据我所知，那是为处理在发送的消息内部处理基于证书的身份验证的情况而设计的--它似乎没有支持证书所有权验证发生在传输级别（即作为TLS/SSL握手的一部分）的情况下的支持。

我想知道是否需要编写自己的模块来实现这一点。理论上，这似乎可能是一个处理AuthenticateRequest事件的情况，从请求中查找证书，如果存在，则从证书构建一个X509CertificateClaimSet。但是...然后呢？我只需创建自己的ClaimsPrincipal并替换现有的用户吗？或者是否有一些“正确”的方法将我发现的声明添加到集合中？（客户端证书不一定是声明的唯一来源-我的应用程序已经使用来自与ACS集成的声明。是否有一种标准机制来确保正确地合并所有可能的声明来源？）

看起来SessionAuthenticationModule（SAM）是当前提供声明主体的标识模型组件，它替换了以前在上下文中和当前线程的用户。但是，它似乎提供了可扩展性-如果覆盖其ValidateSessionToken，则会返回构成主体的ClaimsIdentity对象集合。因此，理论上，在那一点上我可以重写它并添加任何额外的声明。

但我不确定这是正确的方法。据我所知，SAM在ClaimsAuthenticationManager完成声明转换后执行此操作。或者说，在这里使用声明转换的模型是错误的吗？

- Ian Griffiths

Answer 1

可以看看这里：客户端证书认证和声明生成是Thinktecture.IndetityModel的一部分。

- leastprivilege

---

只是为了澄清，在这个上下文中，“identity model”指的是Thinktecture身份模型库，而不是System.IdentityModel？（...这意味着Microsoft的身份框架默认情况下不支持这个吗？） - Ian Griffiths

是的。虽然它得到了Microsoft的支持，但Web API并没有使用它（因为它是设计为在4.0和4.5上运行的）。我只是在我的库中提供了粘合剂。 - leastprivilege

@leastprivilege 或 Ian/Ruben - 你们中的任何人知道 ASP.NET Identity 2.0 是否已经集成了对基于客户端证书的身份验证的支持吗？如果没有，我可以集成 Thinktecture.IdentityModel 并仅将其用于基于客户端证书的身份验证，同时继续使用 asp.net identity 默认的身份验证和存储来进行简单身份验证/外部身份验证吗？我非常想知道 Ian 是否能够找到一个可行的解决方案，尽管我正在使用 ASP.NET MVC 5 和 Identity 2.0。 - Sandeep Phadke

Answer 2

如果我是你，我会将身份验证外部化 - 让其他服务提供身份验证，并返回具有所需声明的SAML令牌。

这样，在您的应用程序中，您不需要考虑证书，您只需要从联合身份提供者获取一些具体的声明。

然后，您可以实现其中一个身份提供者来实际接受证书，但出站SAML隐藏了此实现细节，并将证书转换为对您的应用程序有用的声明集。

- Wiktor Zychla

---

这听起来更加复杂了。这意味着我需要编写或找到一个合适的外部ID提供者，同时还需要让我的客户理解联合身份验证，因此会使实现变得更加复杂。而且我还需要维护额外的服务。将映射推送到其他地方只有在您真正想要联合时才有意义，但在这种情况下，我没有特别的需求，因此似乎没有回报。（我仍然需要实现证书处理和映射，只是移到了不同的服务器上。） - Ian Griffiths