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

У нас есть служба 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>


x509certificate wcf ws-security ws-addressing
person Shawn Hubbard    schedule 28.01.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

person Shawn Hubbard    schedule 14.02.2011