WCF отклоняет сообщения с дополнительными подписанными элементами - PullRequest
Новая
       34

WCF отклоняет сообщения с дополнительными подписанными элементами

1 голос
/ 28 января 2011

У нас есть служба WCF 4.0 через https, которая позволяет клиенту подписать сообщение, чтобы идентифицировать себя.Затем мы можем использовать сертификат для предоставления клиенту надлежащих прав на серверную часть.Это прекрасно работает, когда клиент WCF 4.0 отправляет запрос, но когда не-WCF пытается отправить запрос, происходит сбой со следующим: CryptographicException: невозможно разрешить URI «# Id- {Guid идет здесь}» в подписивычислить дайджест.При проверке запроса клиентов этот сбой происходит всякий раз, когда подписывается что-либо большее, чем узлы To и Timestamp.Клиент, не являющийся WCF, ожидает подписи разделов body, Action, MessageID и ReplyTo.Можно ли настроить WCF для ожидания и разрешения этих подписей или, что еще лучше, разрешить их, если они есть, но не ошибаться, если их нет?

Файл конфигурации службы: 

<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
<extensions>
  <behaviorExtensions>
    <add name="wsdlExtensions" type="MyWCFElements" />
  </behaviorExtensions>
  <bindingElementExtensions>
    <add name="httpsViaProxyTransport" type="MyWCFElements" />
  </bindingElementExtensions>
</extensions>
<behaviors>
  <endpointBehaviors>
    <behavior name="WsdlBehavior">
      <wsdlExtensions singleFile="true" />
    </behavior>
  </endpointBehaviors>
  <serviceBehaviors>
    <behavior name="WebServicesServiceBehavior">
      <serviceMetadata httpsGetEnabled="false" httpGetEnabled="true" />
      <serviceDebug includeExceptionDetailInFaults="false" />
      <serviceAuthenticationManager serviceAuthenticationManagerType="MyServiceAuthenticationManager" />
      <serviceAuthorization serviceAuthorizationManagerType="MyServiceAuthorizationManager" />
      <serviceCredentials>
        <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="MyUserNameValidator" />
        <clientCertificate>
          <authentication certificateValidationMode="PeerTrust" trustedStoreLocation="LocalMachine" />
        </clientCertificate>
      </serviceCredentials>
    </behavior>
  </serviceBehaviors>
</behaviors>
<bindings>
  <customBinding>
    <binding name="SignedWebServicesF5BindingConfig">
      <textMessageEncoding />
      <security authenticationMode="CertificateOverTransport" allowInsecureTransport="true" requireDerivedKeys="false" securityHeaderLayout="Lax" />
      <httpsViaProxyTransport />
    </binding>
  </customBinding>
</bindings>
<services>
  <service behaviorConfiguration="WebServicesServiceBehavior" name="WebService">
      <endpoint address="signed" binding="customBinding" behaviorConfiguration="WsdlBehavior" bindingConfiguration="SignedWebServicesF5BindingConfig" contract="IWebServicesContract" name="SignedWebServices"/>
      <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
  </service>
</services>

1 Ответ

0 голосов
/ 14 февраля 2011

После работы с Microsoft ответ, как представляется, заключается в том, что вы не можете использовать CertificateOverTransport и подписать тело сообщения, что и пытался сделать наш клиент. Мы перешли на MutualCertificateDuplex и изменили ProtectionLevel нашего ответа на ProtectionLevel.None (поскольку мы не заинтересованы в подписании ответа). Теперь мы можем получать запрос и получать ответ по протоколу https, поэтому мы все еще можем полагаться на транспорт для шифрования, пока безопасность сообщения поддерживается на уровне сообщения, а не на уровне транспорта.

Надеюсь, это кому-то поможет, похоже, это довольно часто встречается в сценариях взаимодействия WCF, но в Интернете нет тонны рекомендаций по этому поводу.

...