WCF 拒绝带有附加签名元素的消息

发布于 2024-10-14 23:26:29 字数 2723 浏览 1 评论 0原文

我们有一个基于 https 的 WCF 4.0 服务,允许客户端对消息进行签名以识别自己的身份。然后我们可以使用该证书在后端为客户端提供适当的权限。当 WCF 4.0 客户端发送请求时,此方法工作正常,但当非 WCF 尝试发送请求时,它会失败并显示以下内容: CryptographicException:无法解析签名中的“#Id-{Guid gets here}”URI来计算摘要。在检查客户端请求时,只要签署了“To”和“Timestamp”节点以外的任何内容,就会发生此故障。非 WCF 客户端希望对正文、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>

We have a WCF 4.0 service over https that allows the client to sign the message to identify themselves. We can then use the cert to give the client the proper rights on the back end. This works fine when a WCF 4.0 client sends the request, but when a non-WCF attempts to send the request, it fails with the following: CryptographicException: Unable to resolve the '#Id-{Guid goes here}' URI in the signature to compute the digest. Upon inspecting the clients request, this failure occurs whenever anything more than the To and Timestamp nodes are signed. The non-WCF client expects to sign the body, Action, MessageID, and ReplyTo sections. Can WCF be configured to expect and allow these signatures or, better yet, allow them if they are there but don't fault if they aren't?

Service config file:

<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>

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

無處可尋 2024-10-21 23:26:29

与 Microsoft 合作后,答案似乎是您无法使用 CertificateOverTransport 并对消息正文进行签名,而这正是我们的客户尝试做的事情。我们转向 MutualCertificateDuplex,并将响应的 ProtectionLevel 更改为 ProtectionLevel.None(因为我们对签署响应不感兴趣)。我们现在能够通过 https 接收请求并获得响应,因此我们仍然可以依赖传输进行加密,同时消息的安全性保持在消息级别,而不是传输级别。

希望这对其他人有帮助,这在 WCF 互操作场景中似乎相当常见,但网络上没有大量关于此的指导。

After working with Microsoft, the answer seems to be that you cannot use CertificateOverTransport and sign the message body, which is what our client was attempting to do. We moved to MutualCertificateDuplex and changed the ProtectionLevel of our response to ProtectionLevel.None (since we aren't interested in signing the response). We're now able to receive a request and get a response over https, so we can still rely on the transport for encryption while the security of the message is maintained at the message level, not the transport level.

Hope this helps someone else, this seems to be fairly common in WCF interop scenarios but there isn't a ton of guidance about this on the web.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文