Сохранять привязку MEX небезопасной, защищая привязку HTTP с помощью UsernamePasswordValidator?

Мы используем UsernamePasswordValidator вместе с сертификатом для защиты доступа к нашим службам WCF.

Однако настраиваемые политики авторизации, которые мы используем, относятся к поведению SERVICE, а не к поведению конечной точки, поэтому они применяются ко всем конечным точкам, включая конечную точку MEX. Мы хотели бы иметь возможность получать ссылки на службы с помощью Visual Studio без необходимости каждый раз комментировать поведение службы, но, поскольку и конечная точка mex, и конечная точка wshttp защищены, мы получаем сообщение об ошибке при выполнении «Добавить ссылку на службу». .."

Есть ли способ обойти это?


.net c# wcf wcf-security
person mgerety    schedule 24.06.2009    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вы используете одну и ту же привязку на обоих? Если это так, попробуйте две отдельные привязки — одну для конечной точки mex и одну для wshttp:

Итак, для службы - что-то вроде:

<wsHttpBinding><binding name="wsHttpBindingMessageUname">
<security mode="Message">
    <message clientCredentialType="UserName" negotiateServiceCredential="true"
      establishSecurityContext="false" />
</security></binding></wsHttpBinding>

и для конечной точки mex (без защиты):

<customBinding><binding name="customMex">
<textMessageEncoding>
    <readerQuotas maxDepth="2147483647"
          maxStringContentLength="2147483647"
          maxArrayLength="2147483647"
          maxBytesPerRead="2147483647"
          maxNameTableCharCount="2147483647" />
</textMessageEncoding>
<httpTransport transferMode="Buffered"
               maxReceivedMessageSize="2147483647"
               maxBufferSize="2147483647"/></binding></customBinding>

Конечные точки службы будут выглядеть примерно так:

<endpoint address="" behaviorConfiguration="Server.Services.DefaultEndpointBehavior"  binding="wsHttpBinding" bindingConfiguration="wsHttpBindingMessageUname" name="DefaultHttp" contract="Server.Services.IMyService" listenUriMode="Explicit" />
<endpoint address="mex" binding="customBinding" contract="IMetadataExchange" name="" bindingConfiguration="customMex" listenUriMode="Explicit" />

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

В следующем сообщении MSDN есть образец этого, и дополнительную информацию можно получить в этом блоге относительно безопасных конечных точек MEX.

person Tanner    schedule 25.06.2009

arrow_upward
0
arrow_downward

Я думаю, что из вопроса он также отметил, что использует поведение службы, поэтому конфигурация привязки не будет иметь значения, поскольку вся служба использует средство проверки имени и пароля пользователя.

Здесь на ум приходят две вещи.

Удалите явную привязку mex и добавьте поведение службы.

<serviceMetadata httpsGetEnabled="true" />

Или оставьте привязку mex и включите

<serviceMetadata httpGetEnabled="true" />

CustomUserNameValidator не запускается при запросе метаданных, поэтому, если httpsgetenabled не включен, и у вас есть привязка mex на http, вам нужно httpGetenabled по крайней мере

person Neil    schedule 25.06.2009
comment
Я думаю, что это все еще должно работать, поскольку все мои службы имеют конфигурацию поведения на уровне обслуживания, которая указывает serviceCredentials: cert & uname/pass. Затем в конечной точке службы у меня behaviorConfiguration установлено пустое поведение конечной точки (только с именем, которое может не потребоваться, но не сломано, поэтому не исправлено), тогда конечная точка mex не имеет поведения Configuration. - person Tanner; 25.06.2009
comment
Это должно работать, но проблема не в имени пользователя, я не думаю, что это кодировка транспортного уровня или уровня сообщений или используемая привязка. Я думаю, это тот факт, что mex на http, когда служба пытается вести себя как https с сертификатом является виновником - person Neil; 25.06.2009