如何解决在HTTPS Silverlight应用程序上下文中的WCF maxClockSkew问题？ [英] How to fix the WCF maxClockSkew problem in a HTTPS Silverlight application context?

问题描述

状况：Silverlight 4中的应用程序通过WCF服务器组件通信时，使用basicHttpBinding的和HTTPS

Situation: Silverlight 4 app communicating with a server component through WCF, using basicHttpBinding and HTTPS.

下面是结合使用的服务器端：

Here is the binding used server side:

<basicHttpBinding>
<binding name="DefaultSecuredBinding" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647">
      <readerQuotas maxDepth="50" maxArrayLength="2147483647" maxStringContentLength="2147483647" />
      <security mode="TransportWithMessageCredential">
        <message clientCredentialType="UserName"/>
        <transport clientCredentialType="None" proxyCredentialType="None"/>
      </security>
    </binding>
</basicHttpBinding>

注意，我们使用的 TransportWithMessageCredential 的为安全模式。
证书正确安装IIS。

Notice that we use TransportWithMessageCredential as security mode. Certificate is correctly installed on IIS.

在本地运行应用程序时运行平稳。

Application runs smoothly when running locally.

不过，我们现在有外部用户连接到我们的应用程序。
他们中的一些遇到困难，并期待服务器日志里，我们发现了这个错误：

However, we now have external users connecting to our application. Some of them are experiencing difficulties, and looking inside the server logs, we discovered this error:

MessageSecurityException
的安全时间戳是陈旧的，因为它的截止时间（2010-10-18T22：37：58.198Z'）是在过去。当前时间是'2010-10-18T22：43：18.850Z'，并允许时钟偏斜是'00：05：00的

我们确实在网络上的话题通常的研究（计算器和放大器;谷歌......和Bing），阅读更多的话题。
我们接触的用户，以确保他们的时间与我们的服务器，后来证实抵消。

We did the usual research on the topics on the web (StackoverFlow & Google... and Bing), to read more on the topic. We contacted the users to ensure that they were time offset with our server, which was later confirmed.

这MSDN文章是开始：
<一href=\"http://msdn.microsoft.com/en-us/library/aa738468.aspx\">http://msdn.microsoft.com/en-us/library/aa738468.aspx

This MSDN article was the start: http://msdn.microsoft.com/en-us/library/aa738468.aspx

其中用在现有的绑定CustomBinding并设置自定义绑定的SecurityBindingElement的MaxClockSkew财产。
我们实施这个解决方案，但是改变SymmetricSecurityBindingElement到TransportSecurityBindingElement，因为我们对与Silverlight安全通信结合
是basicHttpBinding的使用HTTPS。

Which use a CustomBinding over an existing binding and sets the MaxClockSkew property on the SecurityBindingElement of the custom binding. We implemented this solution, changing however the SymmetricSecurityBindingElement to a TransportSecurityBindingElement, since our binding for secure communication with Silverlight is basicHttpBinding with HTTPS.

网络（包括上面列出这个MSDN文章）的额外的maxClockSkew属性设置为从 ProtectionTokenParameters采取引导的元素显示code片段若干文章。
我从来没有成功地达到了code应用这个部分，因为 TransportSecurityBindingElement 似乎没有任何的 ProtectionTokenParameters 的

Several articles on the web (including this MSDN article listed above) show code snippets that additionally set the maxClockSkew property to a bootstrap elements taken from ProtectionTokenParameters. I never succeeded to apply this part in our code, since TransportSecurityBindingElement doesn't seem to have any ProtectionTokenParameters.

下面是我们的code包装与maxClockSkew绑定：

Here is our code to wrap a binding with maxClockSkew:

protected virtual System.ServiceModel.Channels.Binding WrapClockSkew(System.ServiceModel.Channels.Binding currentBinding)
    {
        // Set the maximum difference in minutes
        int maxDifference = 300;

        // Create a custom binding based on an existing binding
        CustomBinding myCustomBinding = new CustomBinding(currentBinding);

        // Set the maxClockSkew
        var security = myCustomBinding.Elements.Find<TransportSecurityBindingElement>();
        if (security != null)
        {
            security.LocalClientSettings.MaxClockSkew = TimeSpan.FromMinutes(maxDifference);
            security.LocalServiceSettings.MaxClockSkew = TimeSpan.FromMinutes(maxDifference);
        }


        return myCustomBinding;
    }

的'security.LocalClientSettings'可以是无用这里，因为这个code是为服务器侧

The 'security.LocalClientSettings' may be useless here, since this code is for the server side.

这code的没有做的伎俩，我们仍然对服务器相同的错误消息时，我们曾与服务器超过5分钟的差别。
我仍然记住，我们没有申请的MSDN code段的引导招..所以我们继续我们的话题Web搜索。

This code didn't do the trick, we still had the same error message on server when we had more than 5 minutes difference with the server. I still had in mind that we did not apply the bootstrap trick of the MSDN code snippet.. so we continued our web search on the topic.

我们发现了一个整洁的WCF行为，我们认为，将解决我们的问题。

We found a neat wcf behavior that, we thought, would fix our problem.

它看起来就像它处理引导结合问题！

It looked like it handles Bootstrap binding matters!

下面是它搜索的一部分的令牌参数的在TransportSecurityBindingElement的背景下：

Here is a part where it searches for Token Parameters in a context of a TransportSecurityBindingElement:

//If the securityBindingElement's type is TransportSecurityBindingElement
if (securityBindingElement is TransportSecurityBindingElement)
{
foreach (SecurityTokenParameters securityTokenParameters in 
    securityBindingElement.EndpointSupportingTokenParameters.Endorsing)
{
    //Gets it from the EndpointSupportingTokenParameters.Endorsing property
    if (securityTokenParameters is SecureConversationSecurityTokenParameters)
    {
        secureConversationSecurityTokenParameters =
            securityTokenParameters as SecureConversationSecurityTokenParameters;

        break;
    }
}
}

注意的securityBindingElement.EndpointSupportingTokenParameters.Endorsing的...
在我们的情况（basicHttpBinding的，TransportWithMessageCredential，HTTPS ...），这个集合不过是空的！

Note the 'securityBindingElement.EndpointSupportingTokenParameters.Endorsing'... In our situation (basicHttpBinding, TransportWithMessageCredential, Https...), this collection is however empty!

所以，没有办法取回securityTokenParameters，因而无法进行设置maxClockSkew。

So, no way to retrieve the securityTokenParameters, thus impossible to set the maxClockSkew.

问题：

• 是我们绑定在SL不正确+ WCF + HTTPS方面？

• Are our bindings incorrect in a SL + WCF + HTTPS context?

这是正常至找不到任何方法来设置一个maxClockSkew引导元素在TransportSecurityBindingElement？

Is it normal to not find any way to set the maxClockSkew on a bootstrap element in a TransportSecurityBindingElement?

我们在做客户HTTPS Silverlight应用程序可能无法在完全相同的时间只有公司（与+ - 5分钟偏移量）

Are we the only company doing HTTPS Silverlight app with customers that might not be on the exact same time (with +- 5 minutes offset) ?

为什么它似乎是相当冒险来解决这些琐碎的配置吗？

Why does it seem to be quite an adventure to fix such trivial configuration?

任何帮助将是AP preciated！

Any help would be appreciated!

推荐答案

以下code片段让你设置maxClockSkew上TransportSecurityBindingElement。我的解决方案是一个Outlook插件+ WCF的HTTP和HTTPS环境经营，所以虽然不是同一个上下文中你的相似。

The following code snippet lets you set the maxClockSkew on the TransportSecurityBindingElement. My solution is an Outlook Add-in + WCF operating in http and https contexts, so although not the same context as yours its similar.

• 您绑定正确的看向我。



• 这里的code段

• Your bindings look correct to me.

• Here's the code snippet

WSHttpBinding wsSecureBinding = new WSHttpBinding(SecurityMode.TransportWithMessageCredential, false);
wsSecureBinding.Security.Message.ClientCredentialType = MessageCredentialType.UserName;
wsSecureBinding.Security.Message.EstablishSecurityContext = true;
wsSecureBinding.Security.Message.NegotiateServiceCredential = true;
wsSecureBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Certificate;
wsSecureBinding.ReaderQuotas.MaxStringContentLength = 500000;
wsSecureBinding.ReceiveTimeout =
wsSecureBinding.SendTimeout = new TimeSpan(0, 5, 0);
CustomBinding secureCustomBinding = new CustomBinding(wsSecureBinding);
TimeSpan clockSkew = new TimeSpan(0, 15, 0);

TransportSecurityBindingElement tsecurity = secureCustomBinding.Elements.Find();
SecureConversationSecurityTokenParameters secureTokenParams = (SecureConversationSecurityTokenParameters)tsecurity.EndpointSupportingTokenParameters.Endorsing.OfType().FirstOrDefault();
if (secureTokenParams != null)
{
    SecurityBindingElement bootstrap = secureTokenParams.BootstrapSecurityBindingElement;
    // Set the MaxClockSkew on the bootstrap element.
    bootstrap.LocalClientSettings.MaxClockSkew = clockSkew;
    bootstrap.LocalServiceSettings.MaxClockSkew = clockSkew;
} 

为您正在使用用户名客户端凭据和一些用户时钟偏差仅事项要么喜欢不被自己的计算机时钟正确的时间，或者他们不关心

The clock skew only matters as you are using UserName client credentials and some users either like their computer clocks not being the correct time, or they don't care

这篇关于如何解决在HTTPS Silverlight应用程序上下文中的WCF maxClockSkew问题？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！