我正在尝试将我的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的解决方案。我想依靠随邮件传递的用户名和密码。
答案 0 :(得分:3)
另外,请参阅我的博客文章,了解如何实现一个绑定,允许您在没有SSL的情况下通过HTTP传递用户名和密码:http://blog.tonysneed.com/2012/06/18/building-scalable-and-secure-wcf-services/但是,请记住,这不是一个好主意通过非安全传输以明文形式传递凭据。我描述的技术假设您正在使用其他机制(例如IPSec)来保护传输,并且它对于支持SSL终止以实现更好可伸缩性的负载均衡器非常有用。
为了专门针对您的场景,我建议您咬紧牙关并使用SSL设置开发环境,以便您可以使用HTTPS绑定WCF和用户名密码验证器。这比实现自定义绑定元素容易得多,并不像您想象的那么困难。实际上,如果安装了IIS Express,您将获得一个自签名证书,您可以轻松地将其用作IIS上的证书或Windows服务。
干杯, Tony Sneed
答案 1 :(得分:1)
默认情况下,WCF框架不允许通过HTTP通道传输用户名/密码作为明文和安全违规,因此当您切换到HTTPS时,用户名/密码验证器可以正常工作。如果您希望在HTTP上使用用户名/密码验证程序,则可能需要编写执行此操作的自定义服务主机工厂。你可以在很久以前找到一个名为ClearUserNameBinding的人。它允许您通过HTTP执行用户名/密码验证。
注意:如上所述,由于安全性,建议不建议使用HTTP上的用户名/密码,但如果您确定您的服务位于足够安全的防火墙后面并且客户端到防火墙的呼叫是安全的,那么用户名/密码不会泄露,然后您可以使用它
答案 2 :(得分:1)