Question

The situation:

  1. We have Windows 2008 web serverse with IIS7, (.NET4)
  2. We can comminicate with the webserver only through the default HTTPS (443) port
  3. There is an ASP.NET website hosted on the servers, the service is part of the website code.
  4. Some clients (desktop applications with WCF support) want to communicate with our new WCF webservice
  5. Message size between the parties can be 100 - 400 kb
  6. We'd like to keep the WCF service part of the IIS.
  7. On client side we request a custom username and password to connect to our service
  8. There are longer sessions with more DB processign behind
  9. And there are quick short sessions - like ping from the client
  10. The client passwords are stored on our webserver (from DB) - clients should be authenticated against these passwords.

Question:
1. From these constraints what would be the best protocol to use?
2. Would you use sessions by default?
3. Tried this binding first (it works, however there is no session support)

  <!--define a SOAP binding-->
  <wsHttpBinding>
    <binding name="DefaultSOAPBasedHTTPSBinding" maxReceivedMessageSize="400000">
      <readerQuotas maxArrayLength="102400" />
      <security mode="Transport">
        <transport clientCredentialType="None" />
      </security>
    </binding>
  </wsHttpBinding>

To enable sessions:

  <wsHttpBinding>
    <binding name="DefaultSOAPBasedHTTPSBinding" maxReceivedMessageSize="400000">          
      <readerQuotas maxArrayLength="102400" />
      <reliableSession enabled="true" />
      <security mode="TransportWithMessageCredential">
        <transport clientCredentialType="Basic" />
        <message clientCredentialType="Certificate"/>
      </security>
    </binding>
  </wsHttpBinding>

My feeling is that this transport & message securtiy is too much - I mean do we really need this in order to allow sessions with wsHttpBinding?

Was it helpful?

Solution

  1. wsHttpBinding, stay with http and security and IIS will manage the service's life cycle. Also, you might want a dedicated application pool.
  2. Using Session or not is matter of design. Use Sessions if there is a state to maintain between the calls otherwise use per call. A ping operation wouldn't require Sessions.

I suggest the following binding configuration along with per call:

  <wsHttpBinding>
    <binding name="DefaultSOAPBasedHTTPSBinding" maxReceivedMessageSize="400000">          
      <readerQuotas maxArrayLength="102400" />
      <security>
        <message clientCredentialType="Username"/>
      </security>
    </binding>
  </wsHttpBinding>

Hope it helps!

OTHER TIPS

So, finally I use Session because it hasn't got too big performance impact. And it was also a constrain that we should know how is talking to us via the webservice. So we need authentication.

Beaud's answer helped a lot - however the missing piece was the custom name and password validaror: http://msdn.microsoft.com/en-us/library/aa702565.aspx

With this web.config:

        <wsHttpBinding>
            <binding name="DefaultSOAPBasedHTTPSBinding" maxReceivedMessageSize="400000">
                <readerQuotas maxArrayLength="102400"/>
                <reliableSession enabled="true"/>
                <security mode="TransportWithMessageCredential">
                    <transport clientCredentialType="Basic"/>
                    <message clientCredentialType="UserName"/>
                </security>
            </binding>
        </wsHttpBinding>

Maybe it helps somebody...

And the WCF tracing is also a big help when finding these magic WCF configuration issues:

<system.diagnostics>
    <trace autoflush="true"/>
    <sources>
        <source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
            <listeners>
                <add name="sdt" type="System.Diagnostics.XmlWriterTraceListener" initializeData="SdrConfigExample.e2e"/>
            </listeners>
        </source>
    </sources>
</system.diagnostics>
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top