wcf - 使用 WCF 服务创建自定义 WS-Federation 身份提供程序

Question

这与我的问题有关，但我很确定不会重复:Looking for a secure and robust STS implementation

自从提出这个问题后，来自业务的一些输入和一些研究让我相信，与其实现安全 token 服务来包装我的自定义身份提供者，我可以将 token 的发布委托(delegate)给身份提供者本身。

身份提供者是一个 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 实现，但如果可能的话，我想简单地将颁发和签署 token 的任务转移到身份提供者中，并最终将其限定为 WS - 联合身份提供程序，稍后我可以将其包含在我的 Azure 访问控制的提供程序中。

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

Answer 1

“一个不只是将 WS-Federation 身份提供者组合在一起” - 涉及许多必要的复杂性，主要是为了确保所断言的声明的安全性、完整性和可证明性。

你不想弄错这些东西——看看最近在 Target、Home Depot、Sony 和其他公司发生了什么!

我强烈建议您阅读并重新阅读 Michele Leroux Bustamante 的 "Building A Custom Security Token Service" article直到您彻底了解 STS 的作用以及这样做所涉及的各种复杂性。

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

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

如果这一切看起来需要大量的工作，那就是(而且应该是——安全性真的非常非常难!)。

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