http - 使用 HTTP 的 WCF 自定义用户名身份验证

Question

我正在尝试配置我的 WCF 服务以通过 HTTP 和我的 ASP.NET 开发服务器使用自定义用户名验证器。以下是 serviceModel 的部分...

<basicHttpBinding>
    <binding name="Authentication" >
      <security mode="TransportCredentialOnly" >
        <message clientCredentialType="UserName"/>
      </security>
    </binding>
</basicHttpBinding>

  <service behaviorConfiguration="ApiBehavior" name="CriticalWatch.AuthenticationAPI.AuthenticationAPI">
    <endpoint address="/" binding="basicHttpBinding" bindingConfiguration="AuthenticationBinding" name="Authentication" contract="CriticalWatch.AuthenticationAPI.IAuthenticationAPI" />
  </service>

然后我有一个验证器的行为......

  <serviceBehaviors>
    <behavior name="ApiBehavior">
      <serviceMetadata httpGetEnabled="true" />
      <serviceDebug includeExceptionDetailInFaults="true" />
      <serviceCredentials>
        <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="Service.CustomUserNameValidator, MyService" />
      </serviceCredentials>

    </behavior>
  </serviceBehaviors>

我的 CustomUserNameValidator 继承自 UserNamePasswordValidator。验证器类被实例化，但永远不会调用 Validate 方法。另外，客户端可以在不传递任何用户名和密码的情况下调用该方法。

我错过了什么？

此时，我想要一个不需要HTTPS的方案。我想依赖随消息传递的用户名和密码。

Answer 1

另外，请参阅我关于如何实现绑定(bind)的博客文章，该绑定(bind)允许您在不使用 SSL 的情况下通过 HTTP 传递用户名和密码:http://blog.tonysneed.com/2012/06/18/building-scalable-and-secure-wcf-services/但是请记住，通过非安全传输以明文形式传递凭据并不是一个好主意。我描述的技术假设您正在使用另一种机制(例如 IPSec)来保护传输，并且它对于支持 SSL 终止以实现更好的可扩展性的负载平衡器非常有用。

为了具体解决您的情况，我建议您硬着头皮使用 SSL 设置您的开发环境，以便您可以将 HTTPS 绑定(bind)与 WCF 和您的用户名-密码验证程序结合使用。这比实现自定义绑定(bind)元素要容易得多，并且没有您想象的那么困难。事实上，如果您安装了 IIS Express，您将获得一个自签名证书，您可以轻松地将其用作 IIS 上的证书或与 Windows 服务一起使用。

干杯， 托尼·斯尼德