Какая самая быстрая конфигурация безопасности для netTcpBinding? - PullRequest
Новая
       11

Какая самая быстрая конфигурация безопасности для netTcpBinding?

6 голосов
/ 23 августа 2009

Я использую службу WCF, которая, помимо прочего, используется в качестве серверной части для веб-сайта. Поскольку и веб-сайт, и служба WCF работают на одном компьютере, и в интересах производительности я настроил его с помощью netTcpBinding.

Теперь дело в том, что, поскольку они существуют в одном и том же блоке, меня действительно не волнует ни безопасность транспортного уровня, ни шифрование на уровне сообщений; единственный возможный способ перехвата сообщений - это если кто-то сам заходит на веб-сервер, и если они это делают, у меня уже есть большие проблемы.

Итак, мой вопрос: когда клиент и сервер уже находятся в доверенной подсистеме, какую конфигурацию можно использовать для обеспечения максимально быстрой работы netTcpBinding?

Конечно, ответ может заключаться в использовании безопасности "none". Но в моем конкретном случае мне все еще нужно использовать аутентификацию UserName для пользовательской базы данных. Можно ли настроить его так, чтобы он все еще использовал аутентификацию UserName, но не беспокоился о сертификатах или защите данных между конечными точками? Или, возможно, мне нужно реализовать пользовательское поведение с настраиваемым заголовком SOAP для хранения имени пользователя / пароля, и тогда я действительно смогу установить безопасность на «none»?

Конфигурация сервера 

  <netTcpBinding>
    <binding name="Net_Tcp_Binding">
        <security mode="Message">
            <message clientCredentialType="UserName" />
        </security>
    </binding>
  </netTcpBinding>

Он использует пользовательскую аутентификацию UserName - в основном, каждый вызов аутентифицируется и авторизуется по пользовательской базе данных. Сервисная сторона также использует сертификат для ведения переговоров со своими клиентами, например: 

<serviceBehaviors>
  <behavior name="MyBehavior">
    <serviceMetadata httpGetEnabled="true" />
    <serviceDebug includeExceptionDetailInFaults="true" />
    <serviceAuthorization principalPermissionMode="Custom">
      <authorizationPolicies>
        <add policyType="MyAssembly.CustomAuthorizationPolicy,MyAssembly" />
      </authorizationPolicies>
    </serviceAuthorization>
    <serviceCredentials>
      <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="MyAssembly.CustomCredentialValidator,MyAssembly" />
      <serviceCertificate x509FindType="FindBySubjectName" findValue="CN=servercert" storeLocation="LocalMachine" storeName="My" />
    </serviceCredentials>
  </behavior>
</serviceBehaviors>

Конфиг клиента 

<netTcpBinding>
  <binding name="Net_Tcp_Endpoint">
    <reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false" />
    <security mode="Message">
      <message clientCredentialType="UserName" />
    </security>
  </binding>
</netTcpBinding>

1 Ответ

4 голосов
/ 23 августа 2009

«Нет» будет самым быстрым, да :-)

С другой стороны, если ваша служба и серверная часть работают на одной и той же машине, вам также следует серьезно взглянуть на привязку netNamedPipe, которая является абсолютным оптимальным, если у вас есть связь «на машине». Это даже быстрее и эффективнее, чем netTcp.

Для проверки подлинности вызывающей стороны по службе, вам необходимо использовать какой-либо метод безопасности - поскольку netNamedPipe поддерживает только «none» или «Windows», я бы выбрал Windows. Если вы не используете ни один, у вас нет возможности идентифицировать (аутентифицировать) вызывающего абонента, и, таким образом, вы не можете иметь авторизацию (кто может делать что) на основе личности вызывающего абонента.

После того как вы аутентифицировали абонента (который звонит мне), вы можете использовать либо группы Windows, либо встроенную подсистему поставщика членства / роли ASP.NET для выполнения авторизации на основе ролей, чтобы убедиться, что кто может делать какие операции. Это можно настроить с помощью поведения службы с именем <serviceAuthoritzation> в разделе вашего поведения в конфигурации службы.

Марк

...