如果访问通过HTTPS实现为ASP.NET Web API Controller的端点的客户端提供客户端证书,则该证书可通过Request.GetClientCertificate
获得。但是,我想知道:是否有可能以基于声明的模型的形式提供与.NET 4.5中的安全模型集成的信息?
我想要这样做的主要原因是我需要不同的客户端才能以不同的方式进行身份验证以访问相同的服务,所以我更愿意从证书等细节中抽象出来。我希望我的控制器能够根据当前用户的索赔做出决定,而不必担心这些索赔的来源。
我知道有X509CertificateClaimSet
类型,这看起来像是自然流程:
X509CertificateClaimSet
(类似于您可以用于ACS的联合提供程序生成的传入cookie由{{1}处理的方式}} SessionSecurityTokenHandler
派生并使用ClaimsAuthenticationManager
元素配置的内容)检查来自证书的声明集,并将其转换为特定于非令牌的特定于应用程序的声明甚至有一个<claimsAuthenticationManager>
,听起来应该这样做。但是,据我所知,这是针对在发送的消息中处理基于证书的身份验证的情况而设计的 - 它似乎没有任何支持证书的所有权证明发生在传输级别,即作为TLS / SSL握手的一部分。
我想知道是否需要编写自己的模块来执行此操作。从理论上讲,它似乎只是处理X509SecurityTokenHandler
事件,查看证书请求,从证书中构建AuthenticateRequest
(如果存在)。但是......那又怎样?我只是创建自己的X509CertificateClaimSet
并替换现有用户吗?或者是否有一些“正确”的方式将我发现的声明添加到集合中? (客户端证书不一定是声明的唯一来源 - 我的应用程序已经在使用与ACS集成的声明。是否有一种标准机制来确保所有可能的声明来源都正确合并?)
看起来ClaimsPrincipal
(SAM)是当前提供声明主体的身份模型组件,它只是替换先前在上下文中的那个以及当前线程的用户。但它似乎提供了可扩展性 - 如果覆盖其SessionAuthenticationModule
,则返回构成主体的ValidateSessionToken
个对象集。所以从理论上讲,我可以覆盖它,并在那时添加任何其他声明。
但我不确定这是不行的方法。据我所知,SAM在ClaimsIdentity
完成声明转换后执行此操作。或者索赔转换是错误的模型吗?
答案 0 :(得分:6)
查看here:客户端证书身份验证和声明生成是Thinktecture.IndetityModel
的一部分。
答案 1 :(得分:1)
如果我是你,我会外部化身份验证 - 让其他一些服务提供身份验证,然后返回带有所需声明的SAML令牌。
这样,在您的应用程序中,您并不真正想到证书,您只需要联合身份提供者提出一些具体的声明。
然后,您实现一个身份提供程序以实际接受证书,但传出SAML隐藏此实现详细信息并将证书转换为对您的应用程序有用的声明集。