通过WCF实施身份验证的最佳方法是什么？

我宁愿不使用WS- *，因为它需要独立于传输。

我应该"自己滚"吗？有什么指导(文章/博客文章)吗？
还是有某种方法(我应该)在服务器端使用内置的ASP.NET成员资格和配置文件提供程序？

解决方案

回答

WS- *为什么要依赖于传输？

WS- *规范的全部要点是它们是消息的一部分，因此独立于传输。

回答

WS- *与传输无关。这就是重点。

身份验证实际上取决于我们希望服务的使用者是谁。不要用不需要的安全性来权衡内部服务，同样，如果我们需要了解有关第三方用户的特定知识，则可以添加额外的安全性层，这很有用。

对于外部API，我们使用了使用证书的WS- *身份验证，然后使用了一种简单的身份验证机制(提供了用户名和密码，返回了GUID身份验证令牌，所有请求之后都提供了令牌)。

回答

感谢回答。

我的意思不是说要依靠运输。我的意思是我希望使用者能够选择要绑定到的端点。而且由于basicHttpBinding和netTcpBinding等都不支持WS- *，因此我需要在服务级别使用。

我一直在尝试避免使用Davids的简单身份验证。理想情况下，我想要一种无需添加令牌参数即可完成所有操作的方法。

回答

我们正在寻找基于消息的身份验证，它是基于WS-Security的，并且肯定受到basicHttpBinding和netTcpBinding的支持。我认为我们错误地假设只有WsHttpBinding将支持WS-Security，这是不准确的。

WS绑定用于除WS-Security之外的WS- *元素，例如WS-ReliableMessaging。如果要保持传输独立的消息安全性，它仍然很棘手。对于非双工传输，我们需要至少提前交换一份证书。

这可能是我们认为basicHttpBinding不支持消息安全性的另一个原因。 basicHttpBinding将不允许我们在没有传输安全性的情况下使用UserName身份验证(也有充分的理由，我也会添加)。而且由于运输安全性本质上是取决于运输的，所以我想我们正在努力避免这种情况。

因此，无论如何，如果要完全独立于传输，那么我们需要解决的第一件事就是按顺序获取证书，并弄清楚如何分发第一个(根)证书或者安全地交换证书。如果我们拥有可以分发主证书的应用程序的奢侈品，那么可以采取这种方法。如果我们所处的环境比这更复杂，则需要退后一步，考虑一下此问题的严重程度。

回答

如果要公开需要用户级身份验证/授权的外部服务，则建议使用ASP.NET提供程序。

这里有一个有用的实用程序，允许对ASP.NET提供程序进行远程管理。 ASP.NET解决方案确实需要SQL ...