We are currently securing our web services using WSE. The reason for
this is interoperability. We want our customers to be able clients
using our services with a reasonable effort.

Our progress so far is that we have enabled WS-Security and
WS-Secureconversation using our custom policy assertion. This works
fine although the learning curve have been pretty steep.

We plan to later setup our own STS but so far we are relying on the
implicit RSTs to create our SCTs.

However, we also have a couple of stateful services requiring state to
be persisted on the server side. Redesigning them to being stateless is
not an option unfortunately. Which way should be proceed to persist
state?

We need to consider the following requirements:
1) State information should be on the message level, that is SOAP but
not HTTP.
2) The service will trust the Identify information in the SCT to
identify the user on the first request.
3) The service is secured using WSE 3.0.

Preferrably:
4) The solution should be based on a published standard.
5) We should be able to provide not only a user id, but also it's role
for each service (a user may have different roles on differnet
services). However we would like to not create a custom SCT since this
seems to make interoperability quite complex.

So far we have investigated the SessionState property on the
SoapContext class but been unable to access the information across
several requests. Another problem to handle seems to be that the SCTs
and the associated proxies seem to be recycled when the SCTs are
renewed.