Question

某些客户端需要能够使用基本身份验证连接到我们的WCF SOAP服务，而其他客户端则需要使用Windows身份验证。我们通常在IIS中托管我们的服务，尽管我们确实提供了一个欠发达的Windows服务托管选项。

我的理解是，无法配置一个端点以支持Basic和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”）时，如果它们包含具有正确编码凭据的Authorization HTTP标头，则此方法有效。但是，如果它们在初始请求中不包含任何身份验证信息，则协商最终会选择Windows身份验证。这会使请求超过IIS安全性，但WCF会拒绝该请求，因为它将转到基于身份验证的端点。

我对谈判中发生的事情非常朦胧。但在我看来，IIS提供了为Web应用程序启用的所有身份验证方法（即Basic和Windows），即使请求的特定WCF端点URL仅支持Basic。

我想知道在IIS中我们能做些什么来使协商得到正确的答案：也就是说，如果请求是基于身份验证的端点，请告诉客户端使用Basic。当然，当请求进入Windows认证端点时，我们仍然希望协商最终选择Windows。

如果没有，那么您认为我们最好专注于我们的Windows服务托管版本的服务吗？或者那会有类似的问题吗？

最后的注释：我们确实将Basic和HTTP用于某些内部用途，但我们知道这是一个不安全的组合。所以我们通常打开HTTPS进行生产使用;为简单起见，我把它留在了这里。

Answer 1

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

如何使用Basic和Windows身份验证选项公开WCF服务，因此协商可以正常工作

1 个答案: