Suppose we've parent process, A. A recives the input username and password and appears them up inside a AllUsers database to make certain the username/password combination are valid. A then begins a brand new child process B and passes it the username/password. B needs more information in the database, like the user's age and nickname.

Should A simply be permitted to possess database access:

  • A will get all of the info in the database and passes everything to B via command line strings if this produces the brand new B. Despite the fact that A does not worry about age and nickname. B would parse the strings to seize the fields.
  • A only passes the username/password to B, and A has WCF services that allows B call the services, making A access the database and return the data to B.

Should A and B have database access:

  • A only hands B the username/password and allows B access the database therefore it could possibly get the age/nickname itself.

Must we have multiple databases:

  • A only can access the AllUsers database. But we have a database for every user. So, 10,000 customers = 10,000 databases. B accesses only the main one user database for that one user it likes you.

Bear in mind there are only one A but there might be 100s or 1000's of B processes. I wish to keep your load as even while possible, ie, I'm not going A to become a bottleneck if 1000's of B's need to speak to it. But I am also worried about getting two processes access exactly the same database simultaneously, appears enjoy it could potentially cause slow access or corrupt data.

Fundamental essentials ideas I've for how to pull off this. Which is the greatest? Or it is possible to better approach?

Databases specified for to deal with multiple synchronised access. Unless of course you do something strange, i quickly aren't seeing why A and B should not have the database(s) in case your first concern is staying away from bottlenecks.

I'd avoid getting a database per user, when you are most likely likely to be running many if not completely from the instances on a single machine.

I recommend reading through on database abilities and scaling.

Hope this can help.

For me account information shouldn't be sent at all if at all possible also it appears it's really simple to prevent it inside your scenario. To begin with no process must have full accessibility AllUsers database since it keeps security sensitive data. A good idea is always to make use of a saved method that only A connect, to pass through account information (hash) as parameters. By doing this if process A will get jeopardized, the attacker cannot simply get a listing of passwords. He/She could attempt to brute pressure however with adequately secure passwords (and proper monitoring) you ought to have ample time for you to place the big event. If they're correct the saved procedure should return a cryptographically secure random session token. This ought to be the only real bit of information to pass through by and exactly how you're doing so (WCF, command line argument etc) matters not, choose anything you like. Process B should have the ability to query whatever information it requires through saved methods that go ahead and take token as parameter and return strained results according to your requirements. For instance process B should have the ability to read only its very own user row but with no password. Then add finishing touches just like a job to obvious old periods and you've got a design it's both secure and simple to keep.