如何使用用户名/密码+ SSL使用WCF配置安全的RESTful服务
我希望编写一个配置文件,以允许在WCF中使用RESTful服务,但我仍然希望能够"利用"成员资格提供程序进行用户名/密码身份验证。
以下是使用basicHttp绑定或者不带WS Security的wsHttp的当前配置的一部分,如何对基于REST的服务进行更改?
<bindings> <wsHttpBinding> <binding name="wsHttp"> <security mode="TransportWithMessageCredential"> <transport/> <message clientCredentialType="UserName" negotiateServiceCredential="false" establishSecurityContext="false"/> </security> </binding> </wsHttpBinding> <basicHttpBinding> <binding name="basicHttp"> <security mode="TransportWithMessageCredential"> <transport/> <message clientCredentialType="UserName"/> </security> </binding> </basicHttpBinding> </bindings> <behaviors> <serviceBehaviors> <behavior name="NorthwindBehavior"> <serviceMetadata httpGetEnabled="true"/> <serviceAuthorization principalPermissionMode="UseAspNetRoles"/> <serviceCredentials> <userNameAuthentication userNamePasswordValidationMode="MembershipProvider"/> </serviceCredentials> </behavior> </serviceBehaviors> </behaviors>
解决方案
在继续努力通过WCF实现REST之前,建议我们阅读Tim Ewald的这篇文章。以下语句使我受到特别的影响:
I'm not sure I want to build on a layer designed to factor HTTP in on top of a layer that was designed to factor it out.
在过去的12个月中,我已经用WCF开发了基于REST的内容,并且该声明一遍又一遍地证明了自己的正确性。恕我直言,WCF带来的好处远远超过了它为执行REST工作而引入的复杂性。
我同意Darrel的观点,即基于WCF的复杂REST场景是一个坏主意。只是不漂亮。
但是,Dominick Baier在他的最低特权博客上对此有一些不错的帖子。
如果我们希望看到WSSE身份验证支持以及对WCF的FormsAuthenticationTicket支持的回退,请查看BlogService的源代码。
这是有关使用ASP.net成员资格提供程序保护WCF REST服务的播客:
http://channel9.msdn.com/posts/rojacobs/endpointtv-Securing-RESTful-services-with-ASPNET-Membership/
不管社区是否对WCF上的REST持反对意见(我本人都是站在篱笆上),Microsoft对此都采取了轻描淡写的做法:http://msdn.microsoft.com/zh-cn/netframework/cc950529.aspx
是的,与Moto一致,我看到的WCF入门工具包链接是使用自定义HTTP标头(http://msdn.microsoft.com/zh-cn/library/dd203052.aspx)对凭据进行身份验证的最接近的工具。
但是我无法理解这个例子。
尝试custombasicauth @ Codeplex