views:

87

answers:

2

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?

A: 
  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!

Maxime
Thanks! 1. Yes, I had the same idea, about the app pool. So a dedicated application under the main website.2. So sessions... Would be good to have them because several different requests need autehntication. And when the session is alive I don't need to turn every time to the DB. So the question still remains - the second "DefaultSOAPBasedHTTPSBinding" can be simplified? With IIS hosting: what kind of effect has the "<transport clientCredentialType="Basic" />" configuration ?
smcoder
Only you know if it's better to have a hit to the db or the instance to manage resources but sessions need to be managed... I wouldn't use them if I was you. Authentication is still possible without session by the way.
Maxime
A: 

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

related questions