Take the 2-minute tour ×


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:

enter image description here

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.

enter image description here

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).


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.

share|improve this question
What have you used to create this diagram? –  lszk Dec 12 '12 at 10:24
@Iszk - Diagram was made with Powerpoint –  GarethOwen Dec 12 '12 at 10:37

1 Answer 1

As I understand this you will need to run a query per user but you do not want to make this a blocking call. You want the responsiveness of a denormalized read model, the UserData.

I have an idea where you instead of storing the credentials somewhere, you simply start a thread and provide that thread with the current credentials taken from the request.

class MyClass
    public static void DoSomething(object principal)
        if (principal == null || !(principal is IPrincipal))
            throw new ArgumentException();
        Thread.CurrentPrincipal = (IPrincipal) principal;
        // Do heavy querying and update UserData

I call this from an ASP.NET MVC Controller like this:

public ActionResult Index() 
    var t = new Thread(MyClass.DoSomething);

    return View();

This would update the UserData for each request. If you want, you could introduce some logic for the update frequency and only make the call on certain conditions.

Another approach I was thinking about was a step towards the CQRS mindset, where I in this case would publish a message containing the serialized IPrincipal and that message would be consumed by another instance/server that would update the read model as a separate process. But I am uncertain that the IPrincipal would actually work if deserialized on another server.

Anyway, I don't see the benefit of persisting the credentials. Just use them in the scope of a new thread or in the context of a message consumed.

share|improve this answer
@MikeEast - thanks for your reply. What I actually want is for the data to 'already be there' when the user starts a new session. Because it may take many minutes for the data to be retrieved. When the 'dataCollection' service gets the data for a user, that user may not even be logged on. I like your mention of CQRS - this pattern is motivation for my idea. –  GarethOwen Apr 1 '11 at 12:24
@GarethOwen - What you should try to do is to turn things around and update the UserData model when things that it depends on has changed. That is the true CQRS/Event Sourcing way. But with that you have the issue with you queries again. Maybe you should try to use another key than full credentials, such as the user id. But perhaps that is in a Legacy/dont-want-to-touch-that system? –  Mikael Östberg Apr 1 '11 at 13:42
@MikeEast - turn it around - great idea. But as you suspect, I have little control over the legacy system. In fact the 'legacy system' is a 'generic' data source - the data could be coming from anywhere (database, webservice, excel spreadsheet...) –  GarethOwen Apr 1 '11 at 13:51
@GarethOwen - Ah, so data flows into the black box and the only means (short term) to get it out is to query it. And the only way to query it is to use the user's credentials. You might need to store the credentials after all. :) –  Mikael Östberg Apr 1 '11 at 14:00
so we get back to my original question (sorry it took so long to detail out the scenario): is it acceptable, from a security point of view, to save usernames and passwords in a database? And saving a hash (or salted hash) of the password will not suffice, because I need to get back to the password to impersonate the user. –  GarethOwen Apr 1 '11 at 15:00

Your Answer


