具有自定义基本身份验证的 WCF 安全性

我已经使用自定义基本身份验证在我的 RESTFUL WCF 服务中设置了安全性(因此停用了 iis 基本身份验证并且根本不使用 Windows 帐户登录；我的服务由 iis 托管)使用以下内容链接。

我了解消费者必须实现客户端才能在请求 header 中传递凭据。

它是基于 64 位编码的，我们可以在调试时看到凭据在 firebug 网络选项卡中传递(它始终是相同的字符串编码 <=> 相同的凭据......)

因此，此外，为了加强安全性，我将添加 SSL 来加密 url:

现在消费者问我为什么不把登录名和密码放在 url 请求中，即

https://myrestfulserviceurl.com/Method?login=XXX&password=YYY (也结合 SSL)

因此更改需要在我的操作合约中添加登录名和密码作为参数，并在我的方法“方法”中调用一个方法进行身份验证......等等

我的问题是:

自定义基本身份验证(请求 header 中的凭据)与简单地在参数中的 url 中传递凭据 之间有什么区别(两种情况都将使用 ssl)？

我的意思是:我只是在问自己为什么要费心实现基本身份验证。在 url 或 header 中传递凭据看起来很相似:它在请求中传递内容。但就安全性而言，它看起来是一样的？

除了基于 64 位的编码，基本身份验证看起来并不更安全。

如果我错了，请纠正我。

我只是在寻找实现自定义基本身份验证的原因。

任何想法/建议？谢谢

最佳答案

想到的主要区别在于数据的可见程度以及数据可能保留的时间。

例如，假设 SSL 在您的应用程序服务器上终止，get 参数中的值可能会自动记录到您的文件系统中(例如在请求日志中)。将用户名和密码保存在其中并不理想，因为它们更容易被泄露。

如果 SSL 在负载均衡器或某些类似代理处终止，则用户名和密码可能会保存在服务器上的请求日志中，您可能没有考虑过这些服务器，并且可能对其控制较少。

相比之下，身份验证 header 不太可能记录到您不期望的地方。

关于具有自定义基本身份验证的 WCF 安全性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20387117/