使用WCF服务创建自定义WS联合身份提供程序

Question

这涉及到,但我很确定不会重复,我的问题是:寻找安全可靠的STS实现

由于要求,来自业务和一些研究的一些输入使我相信,不是实现安全令牌服务来包装我的自定义身份提供者,我可以将令牌的发布委托给身份提供者本身.

身份提供程序是一种WCF服务,它根据用户的某些标识数据在成功验证用户身份时返回声明集合.例如

[ServiceContract(Namespace = "http://namespace")]
public interface IIdService
{
    [FaultContract(typeof(IdServiceFault))]
    [OperationContract]
    ICollection<Claim> Authenticate(string idDatum1, string idDatum2);
}

哪里Claim是Microsoft.IdentityModel.Claims.Claim.我目前只关注一个仅有质量的STS实现示例,作为一个网站项目,但如果可能的话,我想简单地将发布和签署令牌的任务转移到身份提供者,并最终将其限定为WS -Federation Identity Provider,我稍后可以将其包含在Azure Access Control的提供程序中.

如果可以,我需要在WCF服务中做什么？

Answer 1

“我们不只是将 WS-Federation 身份提供商拼凑在一起”——其中涉及许多必要的复杂性，主要是为了确保所主张的声明的安全性、完整性和可证明性。

\n\n

你不想把这些事情弄错——看看塔吉特、家得宝、索尼和其他公司最近发生的事情！

\n\n

我强烈建议您阅读并重新阅读 Michele Leroux Bustamante 的“构建自定义安全令牌服务”文章，直到您彻底理解 STS 的作用以及这样做所涉及的各种复杂性。

\n\n

请注意，为了构建安全的 STS，您需要支持 SAML、WS-Security、WS-Trust、WS-Federation，并使用 SSL 来安全传输令牌和数据。您需要仔细实施允许身份信息联合所需的通信协议的各个阶段。

\n\n

一旦您深入了解了主题，您就会更好地理解为什么将 STS 构建为位于旁边/前面的 fa\xc3\xa7ade 服务可能是一个好主意 -现有的身份服务 - 而不是通过构建 STS 所涉及的相当复杂的过程来“污染”您现有的服务。

\n\n

如果这一切看起来像是一项繁重的工作，那么事实确实如此（而且应该如此——安全真的非常非常困难！）。

\n\n

我强烈建议您考虑使用 Thinktecture 的 Identity Server，而不是构建您自己的。出色的Dominick Baier和团队在构建强大、设计精良的开源身份服务器方面做得非常出色，该服务器支持 WS-Fed 以及 OpenID、OAUTH 等。

\n