这与我有关,但我很确定不会重复,我的问题是:Looking for a secure and robust STS implementation
由于要求,来自业务和一些研究的一些意见使我相信,不是实现安全令牌服务来包装我的自定义身份提供者,我可以将令牌的发布委托给身份提供者本身。
身份提供程序是一种WCF服务,它根据用户的某些标识数据在成功对用户进行身份验证时返回声明集合。 E.g。
[ServiceContract(Namespace = "http://namespace")]
public interface IIdService
{
[FaultContract(typeof(IdServiceFault))]
[OperationContract]
ICollection<Claim> Authenticate(string idDatum1, string idDatum2);
}
其中Claim
为Microsoft.IdentityModel.Claims.Claim
。我目前只关注一个仅有质量的STS实现示例,作为一个网站项目,但如果可能的话,我想简单地将签发和签署令牌的任务转移到身份提供者,并最终将其限定为< em> WS-Federation Identity Provider ,我稍后可以将其包含在我的Azure Access Control的提供程序中。
如果可以,我在WCF服务中需要做什么?
答案 0 :(得分:3)
“一个人不只是将WS-Federation身份提供商拼凑在一起” - 涉及许多必要的复杂性,主要是为了确保声明的声明的安全性,完整性和可证明性。
你不想让这些东西出错 - 看看Target,Home Depot,索尼和其他公司最近发生的事情!
我强烈建议您阅读并重新阅读Michele Leroux Bustamante的"Building A Custom Security Token Service" article,直到您完全理解STS的作用以及这样做所涉及的各种复杂性。
请注意,为了构建安全的STS,您需要支持SAML,WS-Security,WS-Trust,WS-Federation并使用SSL来安全地传输令牌和数据。您需要仔细实施允许联合身份信息所必需的通信协议的各个阶段。
一旦你深入了解了这个主题,你就会更好地理解为什么建立一个STS作为与现有身份服务同时/在前面的外观服务的好主意 - 而不是“污染”您现有的服务,而是建立STS所涉及的相当复杂的程度。
如果这一切看起来像很多工作,那就是(而且应该是 - 安全真的,非常难!)。
我强烈建议您考虑使用Thinktecture的Identity Server而不是构建自己的Identity Server。 真棒Dominick Baier &amp;团队在构建强大,精心设计的开源Identity Server方面做得非常出色,该服务器支持WS-Fed以及OpenID,OAUTH等。