如何使用基本和Windows身份验证选项公开WCF服务，以便协商工作

一些客户端需要能够使用基本身份验证连接到我们的WCFSOAP服务，而其他客户端则需要使用Windows身份验证。我们通常在IIS中托管我们的服务，尽管我们提供了一个开发程度较低的Windows服务托管选项

据我所知，不可能将一个端点配置为同时支持基本身份验证和Windows身份验证。因此，每个服务有两个端点

<endpoint address="" binding="basicHttpBinding" bindingConfiguration="BasicBinding" contract="SomeContract" bindingNamespace="http://www.somewhere.com/Something" />
<endpoint address="win" binding="basicHttpBinding" bindingConfiguration="WindowsBinding" contract="SomeContract" bindingNamespace="http://www.somewhere.com/Something" />

...

<bindings>
  <basicHttpBinding>
    <binding name="BasicBinding">
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Basic"/>
        <message clientCredentialType="UserName"/>
      </security>
    </binding>
    <binding name="WindowsBinding">
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Windows"/>
        <message clientCredentialType="UserName"/>
      </security>
    </binding>
  </basicHttpBinding>
</bindings>

...

它们位于IIS中的同一Web应用程序中。该Web应用程序同时启用了基本身份验证和Windows身份验证（否则上述绑定之一将无法工作）

当客户机使用Windows身份验证端点（URL末尾带有“win”）时，这通常可以正常工作。当初始请求不包含任何身份验证信息时，客户端和IIS之间会进行协商，他们会选择Windows身份验证，一切正常

当客户端使用基本身份验证端点（URL末尾没有“win”）时，如果客户端包含带有正确编码凭据的授权HTTP头，则此操作有效。但是，如果它们在初始请求中不包含任何身份验证信息，则协商最终选择Windows身份验证。这会使请求通过IIS安全性，但WCF会拒绝该请求，因为它将发送到一个基本的经过身份验证的端点

我不太清楚谈判中到底发生了什么。但在我看来，IIS提供了Web应用程序启用的所有身份验证方法（即Basic和Windows），即使请求的特定WCF端点URL仅支持Basic

我想知道我们在IIS中是否可以做些什么来让协商得到正确的答案：也就是说，如果请求是到一个基本的经过身份验证的端点，那么告诉客户端使用基本的。当然，我们仍然希望在请求到达Windows身份验证端点时，协商最终选择Windows

若并没有，那个么你们认为我们最好专注于我们的Windows服务托管版本的服务吗？还是会有类似的问题

---

最后一点注意：我们确实在一些内部使用Basic和HTTP，但我们知道这是一种不安全的组合。因此，我们通常在生产中使用HTTPS；为了简单起见，我把它忘在这里了。

是的，clientCredentialType=“InheritedFromHost”为我解决了这个问题。这是.NET4.5中新增的，意味着现在可以对多个身份验证类型使用相同的端点URL。IIS设置控制允许的身份验证，这意味着不再可能获取冲突中的IIS和WCF设置。

I因为发现了clientCredentialType=“InheritedFromHost”这是.Net 4.5中新增的，似乎有助于解决我的问题。我还不确定它是否解决了所有问题。