通过WCF实现身份验证的最佳方法是什么？
我宁愿不使用WS- *，因为它需要独立于传输。
我应该“自己动手”吗？是否有任何指导（文章/博客文章）？
或者有没有办法（我应该）使用服务器端内置的ASP.NET成员资格和配置文件提供程序？
答案 0 :(得分：2)
基于消息的身份验证（基于WS-Security）是您正在寻找的，并且得到basicHttpBinding和netTcpBinding的支持。我认为你错误地假设只有WsHttpBinding才支持WS-Security，这是不准确的。
WS绑定适用于WS-Security以外的WS- *元素，例如WS-ReliableMessaging。如果您希望它保持安全，那么设置与传输无关的邮件安全性仍然会非常棘手。对于非双工的传输，您需要至少提前交换一个证书。
这可能是您认为basicHttpBinding不支持邮件安全性的另一个原因。 basicHttpBinding将不允许您在没有传输安全性的情况下使用UserName身份验证（我也将添加）。而且由于运输安全本质上依赖于运输，我猜你正试图避免它。
所以，无论如何，如果你想完全独立于传输，你需要解决的第一件事就是按顺序获取证书并弄清楚你将如何分发第一个（根）证书，或者安全地交换证书。如果您拥有可以分发主证书的应用程序，那么请采用该路线。如果你处于一个比这更复杂的场景，你需要退一步思考这个问题到底有多难。
答案 1 :(得分：0)
为什么WS- *必须依赖传输？
WS- *规范的重点在于它们是消息的一部分，因此与传输无关。
答案 2 :(得分：0)
WS- *是独立运输的。这就是重点。
身份验证实际上取决于您所需服务的消费者是谁。不要使用不需要的安全性来衡量内部服务，同样，如果您需要了解有关第三方用户的具体信息，则添加额外的安全层也很有用。
对于外部API，我们使用证书进行WS- *身份验证，然后使用简单的身份验证机制（提供用户名和密码，返回GUID身份验证令牌，事后为所有请求提供令牌）。
答案 3 :(得分：0)
感谢您的回答。
我的意思并不代表交通工具，我的错误。我的意思是我希望消费者能够选择要绑定的端点。而且由于basicHttpBinding和netTcpBinding等不支持WS- *我需要在服务级别使用某些东西。
Davids简单身份验证是我一直试图避免的。理想情况下，我想要一种方法来完成同样的事情，而不必为我的所有操作合同添加一个令牌参数。
答案 4 :(得分：0)
如果您要公开需要用户级别身份验证/授权的外部服务，我建议您使用ASP.NET提供程序。
有一个有用的实用程序here，允许远程管理ASP.NET提供程序。 ASP.NET解决方案确实需要SQL ...