问Web中的客户端证书和基于声明的标识

EN

如果通过HTTPS访问作为ASP.NET Web实现的端点的客户端提供客户端证书，则该证书可通过Request.GetClientCertificate获得。但是，我想知道:是否有可能获得与.NET 4.5中的安全模型集成的基于索赔的模型提供的信息？

我想这样做的主要原因是，我需要不同的客户端才能以不同的方式访问相同的服务，所以我更倾向于从证书之类的细节中抽象出来。我希望我的控制器能够根据当前用户的索赔做出决定，而不必担心这些索赔的来源。

我知道有一种X509CertificateClaimSet类型，它看起来像是自然流：

1. 通过TLS/SSL传递的客户端证书通过某种令牌映射过程被表示为X509CertificateClaimSet (类似于SessionSecurityTokenHandler如何处理由联邦提供者生成的传入cookie )。
2. 索赔转换模块(从ClaimsAuthenticationManager派生并配置为<claimsAuthenticationManager>元素)检查来自证书的索赔集，并将其转换为非特定于令牌的应用程序声明。
3. 处理程序查找特定于应用程序的声明。

甚至还有一个X509SecurityTokenHandler，听起来应该这样做。但是，据我所知，这是为在发送的消息中处理基于证书的身份验证的场景而设计的--它似乎不支持在传输级别(即作为TLS/SSL握手的一部分)证明证书所有权的场景。

我想知道我是否需要编写自己的模块来完成这个任务。理论上，它看起来可能只是处理AuthenticateRequest事件，查看对证书的请求，如果证书存在，则从证书构造一个X509CertificateClaimSet。But...then什么？我只是创建自己的ClaimsPrincipal并替换现有的用户吗？或者有什么“正确”的方法来把我发现的说法添加到片场里？(客户端证书不一定是索赔的唯一来源-我的应用程序已经使用了与ACS集成的索赔。是否有确保所有可能的索赔来源正确合并的标准机制？)

看起来，SessionAuthenticationModule (SAM)是当前提供声明主体的身份模型组件，它只是替换了以前在上下文中的组件以及当前线程的用户。但是它似乎提供了扩展性--如果覆盖它的ValidateSessionToken，则返回组成主体的一组ClaimsIdentity对象。所以在理论上，我可以推翻这一点，并在这一点上添加任何额外的声明。

但我不确定这是不是该走的路。据我所知，SAM是在ClaimsAuthenticationManager完成其声明转换之后才这样做的。或者在这里，声明转换是错误的模式吗？