Background:
We have an ASP.NET / Silveright web application. The silverlight client displays user specific data in a graphical form - it requests the data from the server:
Problem: Getting this data is expensive, due to the underlying database queries that the server has to perform - so the client has to wait...
Optimisation Idea: We run the database queries at regular intervals on the server, writing the results to a 'userdata' table in a database 'close' to where the ASP.NET server runs.
The process of running the queries and writing the data to the tables is performed by a 'data collection' service, which is separated from the ASP.NET server.
When the client requests data the server retrieves it from a 'userdata' table. This should be nice and quick - we probably have the 'userdata' tables on the same machine as the ASP.NET server. We also have the added benefit that the client sees data even if the underlying database is offline.
Of course the data is not live - but all data is potentially old as soon as it reaches the client.
So now my Problem: The 'data collection' service needs the user credentials in order to perform these database queries (because each user gets different results for the same query).
Question:
How can I store user credentials in a database, in an acceptable 'secure' way? Such that the 'data collection' can impersonate a user to perform the database queries. Our initial scenario is based upon using windows integrated login to the database.