【发布时间】:2013-01-31 17:59:33
【问题描述】:
如果通过 HTTPS 访问作为 ASP.NET Web API 控制器实现的端点的客户端提供了客户端证书,则该证书可通过 Request.GetClientCertificate 获得。但是,我想知道:是否有可能以与 .NET 4.5 中的安全模型集成的基于声明的模型的形式提供信息?
我想这样做的主要原因是我需要不同的客户端能够以不同的方式进行身份验证来访问相同的服务,所以我更愿意从证书等细节中抽象出来。我希望我的控制者能够根据当前用户的声明做出决定,而不用担心这些声明的出处。
我知道有一个 X509CertificateClaimSet 类型,这使得它看起来像自然流动:
- 通过 TLS/SSL 传递的客户端证书通过某种令牌映射过程表示为
X509CertificateClaimSet(类似于您可以用于 ACS 的联合提供程序生成的传入 cookie 由SessionSecurityTokenHandler处理的方式李> - 声明转换模块(派生自
ClaimsAuthenticationManager并配置有<claimsAuthenticationManager>元素)检查来自证书的声明集,并将其转换为非令牌特定的应用程序特定声明 - 处理程序查找特定于应用程序的声明。
甚至还有X509SecurityTokenHandler,听起来应该这样做。但是,据我所知,这是为在发送的消息中处理基于证书的身份验证的场景而设计的——它似乎不支持证书所有权证明发生在传输级别,即作为 TLS/SSL 握手的一部分。
我想知道是否需要编写自己的模块来执行此操作。从理论上讲,它看起来可能只是处理AuthenticateRequest 事件,查看证书请求,从证书构造一个X509CertificateClaimSet(如果存在)。但是……然后呢?我是否只是创建自己的ClaimsPrincipal 并替换现有用户?还是有一些“正确”的方法可以将我发现的声明添加到集合中? (客户端证书不一定是声明的唯一来源 - 我的应用程序已经在使用来自与 ACS 集成的声明。是否有标准机制来确保正确合并所有可能的声明来源?)
看起来SessionAuthenticationModule (SAM) 是当前提供声明主体的身份模型组件,它只是替换了先前在上下文中的那个以及当前线程的用户。但它似乎提供了可扩展性——如果你覆盖它的ValidateSessionToken,它将返回构成主体的ClaimsIdentity 对象集。所以理论上,我可以覆盖它并在那时添加任何额外的声明。
但我不确定这是要走的路。据我所知,SAM 是在 ClaimsAuthenticationManager 完成声明转换之后执行此操作的。还是索赔转换是错误的模型?
【问题讨论】:
标签: asp.net asp.net-web-api ssl-certificate wif claims-based-identity