WCF sessions with a wsHttpBinding and without windows security

Question

I need to create a WCF service that is hosted in IIS, uses http transport and hold state in the server’s memory. While I’m aware that stateful services aren't a good idea, this last constrain is necessary to make the service work with a legacy client.

My first thought was to asp.net’s session to store the values. I activated the asp.net compatibility mode in my service, which gave me access to the HttpContext, but values that were placed in the session object were not being persisted in memory. I assume this was because the http module that handles session state was not correctly configured, but when googling for answer I came across, WCF sessions and thought it might be a better idea to use them.

However, WCF sessions seem what under-document and place a strange set of prerequises on a service, and I haven’t been able to find a configuration that suits my needs: must be hosted in IIS, must use http or https transport and can’t reply on windows authentication because the client and server will not be part of the same domain. I’m trying to get this going using the wsHttpBinding, I had heard WCF sessions required either security or reliable message, but: - Using the standard binding and when the servers are not part of the same domain it fails with a “SecurityNegotiationException The caller was not authenticated by the service” exception. This is fairly logical as it was using windows security.

• If I disable security complete it fails with a “Contract requires Session, but Binding 'WSHttpBinding' doesn't support it or isn't configured properly to support it.”

• If while keeping security disabled I enable reliable message I get the exception “Binding validation failed because the WSHttpBinding does not support reliable sessions over transport security (HTTPS). The channel factory or service host could not be opened. Use message security for secure reliable messaging over HTTP.”

• I’ve tried enabling transport level security but this doesn’t seem to make any difference to the error generated

Is there any configuration that might work for me? Or should I just go back to the plan of using asp.net sessions?

Answer 1

You can have WCF hold session information in memory in a pretty simple way. To eliminate any possible external influences in my instructions, I'll assume you're starting with a brand new project:

1. Create a new WCF Service Library project. This project will already contain a service with a WSHttpBiding binding preconfigured.

2. Go to the service contract (IService1.cs) and change the ServiceContract attribute to the following:

   [ServiceContract(SessionMode = SessionMode.Required)]
   

3. Go to the service implimentation (Service1.cs) and add the following ServiceBehavior attribute to the service class (Service1):

   [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession, ConcurrencyMode = ConcurrencyMode.Single)]
   

4. Add session data as members of the service class (Service1):

   public class Service1 : IService1
   {
       ...
   
       private string UserFullName { get; set; }
   
       ...
   }
   

5. Use the members to present session specific data (remember to also add them to the service contract, IService1):

   public class Service1 : IService1
   {
       ...
   
       public string Welcome(string fullName)
       {
           UserFullName = fullName ?? "Guest";
           return string.Format("Welcome back, {0}!", UserFullName);
       }
   
       public string Goodbye()
       {
           return string.Format("Come back soon, {0}!", UserFullName ?? "Guest");
       }
   
       ...
   }
   

SessionMode.Required ensures that your clients are session-tracked.
InstanceContextMode.PerSession ensures that an instance of your service class (Service1) is created for every session, so that you can retain session data in it and it will exist in memory across multiple calls in the same session.
ConcurrencyMode.Single ensures that only one thread can enter each service class instance (Service1), and prevents possible concurrency issues if you only access data from the service class (and external thread-safe locations).

EDIT: By default, WSHttpBinding only allows security sessions. But it also support reliable sessions, which allow establishing sessions without security enabled. The following binding configuration disables security and enables reliable sessions:

<wsHttpBinding>
    <binding name="wsHttpBindingConfiguration">
        <security mode="None" />
        <reliableSession enabled="true" />
    </binding>
</wsHttpBinding>

Answer 2

IMO this is what happens when you're using a technology with a poor abstraction over HTTP like WCF. The fact that WCF web services could in theory be hosted without HTTP (i.e. over NET TCP, MSMQ, etc) just makes it hard to use built-in features of HTTP without entering in configuration hell and start a game of "guess the correct configuration by trial and error" where you try every possible configuration permutation until you've found the correct one that works!

Ultimately if you couldn't use WCF and had to implement the web service from scratch you would simply set a cookie when the client successfully authenticated. Then with every client request just grab the session information referenced by that cookie.

One possible solution if you had to use WCF is to take session management in your own hands (It's what I do when I'm unhappy with the effort required to get something to work) and have an explicit 'Session' property on all your web services that require a session/authentication (usually a guid generated on Authentication). So for each subsequent request you use the guid to rehydrate the session information associated with that client.

If you're interested in trying out different web service frameworks I maintain an Open Source Web Services Framework that lets you build configuration-free, DRY, testable web services where (without any configuration required) each web service you create is automatically accessible over REST XML, JSON, JSV, SOAP 1.1, SOAP 1.2 endpoints. Effectively it allows you to access your same web service via a HTTP GET url for REST-ful clients and easy debugging as well as SOAP endpoints (a popular choice still mandated by some enterprises). The Hello World tutorial should give you a good overview on some of its features and how it works.