元数据请求需要在 WCF 中进行身份验证，即使服务描述页面不需要
我已经使用以下配置设置了一个 WCF 服务来要求 NTLM 身份验证：
<system.serviceModel>
<bindings>
<customBinding>
<binding name="BinarySecurityBinding">
<binaryMessageEncoding/>
<httpTransport authenticationScheme="Ntlm"/>
</binding>
</customBinding>
</bindings>
<services>
<service name="Services.LogisticsServices" behaviorConfiguration="ServiceBehavior">
<endpoint address="" binding="customBinding" bindingConfiguration="BinarySecurityBinding" contract="Services.ILogisticsServices" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
我这样做是为了强制使用 Web 服务的应用程序登录，因为我的所有服务操作都使用模拟 ([OperationBehavior(Impersonation = ImpersonationOption.Required)])。
在 IIS 7 中，我启用了匿名和 Windows 身份验证。
当我访问托管上述服务的http://test.server/LogisticsServices.svc时，我可以匿名看到默认的服务描述页面。但是，当 Visual Studio 尝试访问 http://test.server/LogisticsServices.svc/$metadata 来生成客户端代理时，服务器会使用 HTTP 代码 401 进行响应并期望进行身份验证。我不仅期望元数据可以匿名使用，而且服务器不接受我提供的凭据（尽管我知道它们是正确的）。
测试不同的配置，我尝试从绑定的传输中删除 authenticationScheme ，只是为了能够生成客户端代理，但这会导致异常，因为服务的操作需要模拟 ([OperationBehavior(模拟 = ImpersonationOption.Required)])。
我的服务配置中缺少哪些内容可以使服务的元数据匿名可用？如果我对整个事情的处理方式是错误的，我也愿意接受建议。
I've set up a WCF service to require NTLM authentication using the following configuration:
<system.serviceModel>
<bindings>
<customBinding>
<binding name="BinarySecurityBinding">
<binaryMessageEncoding/>
<httpTransport authenticationScheme="Ntlm"/>
</binding>
</customBinding>
</bindings>
<services>
<service name="Services.LogisticsServices" behaviorConfiguration="ServiceBehavior">
<endpoint address="" binding="customBinding" bindingConfiguration="BinarySecurityBinding" contract="Services.ILogisticsServices" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
I did this so that the applications that consume the web service are forced to log in because all my service's operations use impersonation ([OperationBehavior(Impersonation = ImpersonationOption.Required)]).
In IIS 7 I've enabled anonymous and Windows authentication.
When I visit http://test.server/LogisticsServices.svc, which hosts the service described above, I can see the default service description page anonymously. However, when Visual Studio tries to access http://test.server/LogisticsServices.svc/$metadata to generate a client proxy, the server is responding with HTTP code 401 and expecting authentication. Not only would I've expected the metadata to be available anonymously, but additionally, the server is not accepting the credentials I am giving it (even though, I know for a fact that they are correct).
Testing different configuration, I tried removing the authenticationScheme from my binding's transport, just to be able to generate the client proxy, but that results in an exception because the service's operations require impersonation ([OperationBehavior(Impersonation = ImpersonationOption.Required)]).
What am I missing in my service's configuration that would make the service's metadata available anonymously? I'm also open to suggestions if I'm approaching the whole thing wrong.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这里有一个类似的讨论：
Getting an Security setting exception while访问 WCF 服务
here is a similar discussion:
Getting an Security setting exception while accessing a WCF service
解决这个问题的一种方法是不使用自动生成的代理。
在我们可以控制服务器和客户端的情况下，我们发现避免使用自动生成的代理会更有效率。
有关如何执行此操作的截屏视频可以在此处找到：http://www.dnrtv.com /default.aspx?showNum=122
您可以尝试命令式模型而不是声明式模型，请参阅：http://msdn.microsoft.com/en-us/library/ms730088.aspx
One way around this is not to use the autogenerated proxies.
In cases where we have control over both the server and the client we have found that it is much more productive to avoid using the autgenerated proxies.
A screencast of how to do this can be found here: http://www.dnrtv.com/default.aspx?showNum=122
You could try imperative instead of declarative model, see: http://msdn.microsoft.com/en-us/library/ms730088.aspx