I’m building SaaS application where back end will be SQL Server and WCF Services.
Here is where I’m little worrying.. I’m planning to have separate database per customer (thats decided) and will authenticate users against their database. Thats decided as well.
There will be central database which will have customers info like what database is their and what endpoints to use.
Ideally, I want something like this:
- a. Client hits main page ASP.NET or
Silverlight or open client app on
PC/mobile device/etc - b. Types in Customer ID, user name
and password - c. Call being made to main URL
- d. I will pull endpoint and DB
information for this Customer ID. I
do want WCF endpoint info also be
configurable for future
expansions/upgrades - e. Need somehow pass information
about endpoint/database to user.
Multiple customers can share same WCF
endpoint. - f. Call endpoint from client and
login to specific database.
This way I can see how performance will be OK since I won’t have to go through my “system” proxy on each call. Client will KNOW what endpoint and which database it deals with.
But I’m not sure how to implement this securely. Because database information in step “e” will flow back to customer. Technically, even if it’s cracked on customer – still no access to DB itself from outside. But not nice..
What your thoughts are? Or should each call be made with companyID token and then main central service will route those calls? But that’s like single point of failure. I’d rather see main server to work on on login.
We’ve done WCF sites connecting to multiple databases handling 1000 concurrent requests, there are fiddly bits in the WCF config that you need to tweak, but it should work fine.
I don’t see why database information needs to ‘flow’ back to the user.
All of that could happily live server side. Then all decisions about what database to connect to can be made based on the user credentials.
If you want multiple endpoints to handle load, then you redirect to a relevant (or random) end-point after login. Then store the relevant routing/mapping data on the relevant endpoint (or all of them if you’re using random).
All you need from them is their credentials to decide what database to use.
Tip: As with all performance issues: measure, measure, measure. You need to know if there is any benefit with multiple end-points under your expected load; so build a load test. Then you can see where the performance hit is. Over engineering before measuring sometimes works, but always wastes time.