[update]: Here is a good article too: http://blogs.msdn.com/drnick/archive/2008/10/08/working-with-session-state.aspx
One concept that sometimes confuses ASP.NET developers when moving to WCF is the notion of session state. In ordinary WCF services, all of the session state is stored in local volatile memory. The application has to choose to copy over a portion of the session state to a durable storage location for that state to be preserved across running instances. WCF doesn't come with a built-in option for enabling persistent storage of session state or enabling access to the session state from other processes.
There are a couple ways to make WCF more like ASP.NET.
One way to make WCF more like ASP.NET is to make WCF exactly like ASP.NET by turning on ASP.NET compatibility mode. A WCF application that is hosted in IIS and uses HTTP as a transport binding runs together with the ASP.NET pipeline but does not have access to many of the ASP.NET features. Turning on compatibility mode integrates the WCF application with the ASP.NET pipeline and makes many of those features available. Obviously, this approach is only interesting when your WCF service is already very much like an ASP.NET application.
Another way to make WCF more like ASP.NET is to change the management of WCF session state to use remote durable storage rather than local volatile memory. This approach is more like the one used by workflow services to create durable applications. The management of service instances and instance contexts is controlled by the IInstanceProvider that creates and destroys service objects, the IInstanceContextProvider that creates and destroys instance contexts, and the IInstanceContextInitializer that sets up newly acquired instance contexts. Although durable services have different semantics than session state, there are common building blocks that can be used for both. [/update]
There are a couple of things I can suggest to you in addition to the above. Take a look at this post for one of them: http://stackoverflow.com/questions/275926/wcf-data-presistence-between-sessions. Next, consider using some form of a cache. This can be a cache style service or it could be a cache farm. For more on caching take a look at my post here: http://stackoverflow.com/questions/21870/system-web-caching-vs-enterprise-library-caching-block/984076#984076
This would basically allow you to store a unique key for the user (think similar to a session ID) and all of the so-called session objects for that user would be prefixed by the users pseudo session ID in the caching layer. This caching layer could then be called by the web site that you are using to run your site as well as your various WCF services/projects.