通过 WCF 进行身份验证的最佳方法是什么？
通过 WCF 实施身份验证的最佳方法是什么？
我不想使用 WS-*，因为它需要独立于传输。
我应该“自己动手”吗？ 有这样做的任何指导吗（文章/博客文章）？
或者是否有某种方法可以（我应该）在服务器端使用内置的 ASP.NET 成员资格和配置文件提供程序？
What's the best way to implement authentication over WCF?
I'd prefer to not use WS-* as it needs to be transport independent.
Should I "roll my own"? Is there any guidance for doing that (articles/blog posts)?
Or is there some way to (and should I) use the built in ASP.NET Membership and Profile providers on the server side?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
为什么 WS-* 应该依赖于传输？
WS-* 规范的全部要点在于它们是消息的一部分，因此与传输无关。
Why should WS-* be transport dependant?
The whole point of the WS-* specifications is that they are part of the message, and hence transport independent.
WS-* 与传输无关。 这就是重点。
身份验证实际上取决于您的服务所需的消费者是谁。 不要用不需要的安全性来压垮内部服务，同样，如果您需要了解有关第三方用户的特定信息，添加额外的安全层也很有用。
对于外部 API，我们使用证书进行 WS-* 身份验证，然后使用简单的身份验证机制（提供用户名和密码，返回 GUID 身份验证令牌，事后随所有请求提供令牌）。
WS-* is transport independant. That's the entire point.
Authentication really depends on who the desired consumers of your service are. Don't weigh down internal services with security that isn't required, and likewise it's useful to add extra layers of security if you need to know specific things about third party users.
For external APIs we've gone with WS-* authentication using certificates and then a simple authentication mechanism (username and password is supplied, GUID authentication token is returned, token is supplied with all requests after the fact).
感谢您的回答。
我的意思不是依赖交通，我的错误。 我的意思是我希望消费者能够选择要绑定到哪个端点。 由于 basicHttpBinding 和 netTcpBinding 等不支持 WS-*，我需要在服务级别使用某些东西。
大卫的简单身份验证是我一直试图避免的。 理想情况下，我想要一种方法来完成同样的事情，而不必向我的所有操作合约添加令牌参数。
Thanks for your answers.
I did not mean transport dependant, my mistake. I meant that I'd like the consumer to be able to choose which endpoint to bind to. And since basicHttpBinding and netTcpBinding, amongst others, don't suppport WS-* I need to use something at the at the service level.
Davids simple authentication is what I've been trying to avoid. Ideally I'd like a way to accomplish the same thing without having to add a token argument to all my operation contracts.
如果您公开需要用户级身份验证/授权的外部服务，我建议使用 ASP.NET 提供程序。
这里有一个有用的实用程序，它允许远程ASP.NET 提供程序的管理。 ASP.NET 解决方案确实需要 SQL...
If you are exposing an external service that requires user level authentication / authorization, I would recommend using the ASP.NET provider.
There's a useful utility here that allows remote administration of the ASP.NET provider. The ASP.NET solution does require SQL...
基于消息的身份验证（基于 WS-Security）正是您所寻找的，并且 basicHttpBinding 和 netTcpBinding 绝对支持它。 我认为您错误地认为只有 WsHttpBinding 将支持 WS-Security，这是不准确的。
WS 绑定适用于 WS-Security 之外的 WS-* 元素，例如 WS-ReliableMessaging。 如果您希望保持安全，设置独立于传输的消息安全性仍然会很棘手。 对于非双工传输，您需要提前交换至少一份证书。
这可能是您认为 basicHttpBinding 不支持消息安全性的另一个原因。 basicHttpBinding 不允许您在没有传输安全的情况下使用 UserName 身份验证（我也会添加一个很好的理由）。 由于传输安全本质上依赖于传输，我猜你正在试图避免它。
因此，无论如何，如果您想完全独立于传输，您需要解决的第一件事就是按顺序获取证书，并弄清楚如何分发第一个（根）证书，或安全地交换证书。 如果您有一个可以分发主证书的应用程序，那么就采取这条路线。 如果您遇到的情况比这更复杂，您需要退一步思考这个问题到底有多难。
Message based authentication, which is WS-Security based, is what you're looking for and is definitely supported by basicHttpBinding and netTcpBinding. I think you are making the mistaken assumption that only WsHttpBinding will support WS-Security, which is inaccurate.
The WS bindings are for WS-* elements other than WS-Security, such as WS-ReliableMessaging. Setting up transport independent message security is still going to be tricky, if you want it to stay secure. For the transports that aren't duplex you'll need to have at least one certificate exchanged in advance.
That might be the other reason you believe message security isn't supported by basicHttpBinding. basicHttpBinding will not allow you to use UserName authentication without transport security (for good reason too I'll add). And since transport security is inherently transport dependent I'm guessing you're trying to avoid it.
So anyhow, if you want to be fully transport independent the first thing you need to tackle is getting the certificates in order and figuring out how you're going to distribute the first (root) certificate(s), or securely exchange certificates. If you have the luxury of an application where you can distribute a master certificate, then take that route. If you're in a more complex scenario than that, you need to step back and think about how hard this problem really is.