4

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

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

我应该“自己动手”吗?是否有任何指导(文章/博客文章)?
或者有什么方法可以(而且我应该)在服务器端使用内置的 ASP.NET 成员资格和配置文件提供程序?

4

5 回答 5

2

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

WS 绑定用于 WS-Security 以外的 WS-* 元素,例如 WS-ReliableMessaging。如果您希望它保持安全,那么设置独立于传输的消息安全性仍然很棘手。对于非双工传输,您需要提前至少交换一个证书。

这可能是您认为 basicHttpBinding 不支持消息安全的另一个原因。basicHttpBinding 不允许您在没有传输安全性的情况下使用 UserName 身份验证(出于充分的理由,我也会添加)。而且由于传输安全本质上是依赖于传输的,我猜你是在试图避免它。

所以无论如何,如果你想完全独立于传输,你需要解决的第一件事就是按顺序获取证书并弄清楚你将如何分发第一个(根)证书,或者安全地交换证书。如果您有一个可以分发主证书的应用程序,那么请走这条路。如果你处于比这更复杂的场景中,你需要退后一步,想想这个问题到底有多难。

于 2008-09-10T04:53:34.030 回答
0

感谢您的回答。

我不是说依赖交通,我的错。我的意思是我希望消费者能够选择绑定到哪个端点。由于 basicHttpBinding 和 netTcpBinding 等不支持 WS-*,因此我需要在服务级别使用某些东西。

Davids 简单的身份验证是我一直试图避免的。理想情况下,我想要一种方法来完成相同的事情,而不必为我的所有操作合同添加令牌参数。

于 2008-08-20T13:15:14.360 回答
0

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

身份验证实际上取决于您的服务所需的消费者是谁。不要用不需要的安全性来权衡内部服务,同样,如果您需要了解有关第三方用户的特定信息,添加额外的安全层也很有用。

对于外部 API,我们使用证书进行 WS-* 身份验证,然后使用简单的身份验证机制(提供用户名和密码,返回 GUID 身份验证令牌,事后向所有请求提供令牌)。

于 2008-08-20T08:45:12.777 回答
0

为什么 WS-* 应该依赖于传输?

WS-* 规范的全部意义在于它们是消息的一部分,因此独立于传输。

于 2008-08-20T07:58:25.743 回答
0

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

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

于 2009-08-03T15:06:51.260 回答