4

如果通过 HTTPS 访问作为 ASP.NET Web API 控制器实现的端点的客户端提供客户端证书，则该证书可通过Request.GetClientCertificate. 但是，我想知道：是否有可能以与 .NET 4.5 中的安全模型集成的基于声明的模型的形式提供信息？

我想这样做的主要原因是我需要不同的客户端能够以不同的方式进行身份验证来访问相同的服务，所以我更愿意从证书等细节中抽象出来。我希望我的控制器能够根据当前用户的声明做出决定，而不用担心这些声明的出处。

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

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

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

我想知道是否需要编写自己的模块来执行此操作。从理论上讲，它看起来可能只是处理AuthenticateRequest事件，查看证书请求，X509CertificateClaimSet如果证书存在则从证书构造一个。但是……然后呢？我只是创建自己的ClaimsPrincipal并替换现有用户吗？还是有一些“正确”的方法可以将我发现的声明添加到集合中？（客户端证书不一定是声明的唯一来源 - 我的应用程序已经在使用来自与 ACS 集成的声明。是否有标准机制来确保正确合并所有可能的声明来源？）

看起来SessionAuthenticationModule（SAM）是当前提供声明主体的身份模型组件，它只是替换了先前在上下文中的那个，也是当前线程的用户。但它似乎提供了可扩展性——如果你覆盖它ValidateSessionToken，它会返回ClaimsIdentity构成主体的对象集。所以理论上，我可以覆盖它并在那时添加任何额外的声明。

但我不确定这是要走的路。据我所知，SAM 在ClaimsAuthenticationManager完成声明转换后执行此操作。或者索赔转换是错误的模型？

4

2 回答 2

6

看看这里：客户端证书身份验证和声明生成是其中的一部分Thinktecture.IndetityModel。

于 2013-02-15T21:15:36.030 回答
1

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

这样，在您的应用程序中，您并不会真正想到证书，您只是期望来自联合身份提供者的一些具体声明。

然后，您实施您的身份提供者之一以实际接受证书，但传出 SAML 隐藏此实施细节并将证书转换为对您的应用程序有用的声明集。

于 2013-02-15T19:10:03.240 回答