Как предоставить сервис WCF с опциями проверки подлинности Basic и Windows, чтобы согласование работало

Question

Некоторые клиенты должны иметь возможность подключаться к нашим службам WCF SOAP с помощью обычной проверки подлинности, в то время как другим необходимо использовать проверку подлинности Windows. Обычно мы размещаем наши службы в IIS, хотя мы предоставляем менее развитый вариант размещения Windows Service.

Насколько я понимаю, невозможно сконфигурировать одну конечную точку для поддержки базовой и 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. В этом веб-приложении включена обычная проверка подлинности и проверка подлинности Windows (в противном случае одно из приведенных выше назначений не будет работать)

Когда клиент использует конечную точку с проверкой подлинности Windows (с "win" в конце URL), это обычно работает нормально. Когда первоначальный запрос не содержит никакой информации об аутентификации, между клиентом и IIS происходит согласование, они основываются на аутентификации Windows, и все идет хорошо.

Когда клиент использует конечную точку с проверкой подлинности Basic (без "win" в конце URL-адреса), это работает, если в него включен HTTP-заголовок Authorization с правильными закодированными учетными данными. Однако, если они не включают никакой информации об аутентификации в начальный запрос, согласование заканчивается выбором аутентификации Windows. Это получает запрос за безопасность IIS, но WCF затем отклоняет запрос, потому что он идет к конечной точке с проверкой подлинности Basic.

Я довольно смутно от того, что именно происходит на переговорах. Но мне кажется, что IIS предлагает все методы проверки подлинности, включенные для веб-приложения (т. Е. Basic и Windows), даже если конкретный URL-адрес конечной точки WCF для запроса поддерживает только Basic.

Я хотел бы знать, есть ли что-то, что мы можем сделать в IIS, чтобы согласование дало правильный ответ: то есть, если запрос направлен к конечной точке с проверкой подлинности Basic, скажите клиенту использовать Basic. Конечно, мы все еще хотим, чтобы в результате переговоров был выбран Windows, когда запрос отправлялся в оконечную точку с проверкой подлинности Windows.

Если нет, то как вы думаете, было бы лучше сконцентрироваться на нашей версии служб, размещенной в Windows Service? Или это будет иметь схожие проблемы?

Последнее замечание: мы используем Basic с HTTP для некоторых внутренних целей, но мы знаем, что это небезопасная комбинация. Поэтому мы обычно включаем HTTPS для производственного использования; Я оставил это здесь, для простоты.

Answer 1

Да, clientCredentialType="InheritedFromHost" решает проблему для меня. Это новое в.Net 4.5 означает, что теперь можно использовать один и тот же URL-адрес конечной точки для нескольких типов аутентификации. Параметры IIS определяют, какая проверка подлинности разрешена, а это означает, что больше невозможно получить конфликт параметров IIS и WCF.