Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a 100+ users on a Silverlight application that uses WCF and entity framework.

Everyone has their own database and here comes my problem.

How do I make sure that only the user gets access to his database via WCF. Do I have to send the connectionstring every time I make a call to the service, or?

share|improve this question
1  
Is this some kind of SaaS? Did you actually create 100 separate databases? –  Emmad Kareem Nov 2 '12 at 19:50

2 Answers 2

you should have some form of authentication mechanism, so you know who the user is that's connected to your back-end web service. Then you can just look up the user id against a 'global' DB configuration to get the connection string - so user "Dave" connects, you look up in the list of DBs to see that Dave's DB is "DB_001gh443a" (or whatever it is).

share|improve this answer
    
What could be that authentication mechanism? To authenticate the user, could i send a unique username with every WCF request? So that every operation contract expect at least a username? –  user1741807 Nov 2 '12 at 18:37
    
You could use the WCF UserNamePasswordValidator –  epalm Nov 2 '12 at 18:56
    
Or you could use the BeforeSendRequest method in an IClientMessageInspector in an IEndpointBehavior to attach some headers (like a username) to each client request. –  epalm Nov 2 '12 at 19:01

Sending the connection string to the service would not be a good idea. The caller should really have no idea if there is one database or one million (unless you are building something truly odd, like a database front end, along the lines of phpMyAdmin).

On the Entity Framework side of things, you can change the connection when your context is created. So, for example:

    public class EFContext : DbContext
    {
        public EntityFrameworkSession()
            : base(DetermineConnection(), true)
       {
       }

       private static DbConnection DetermineConnection()
       {
           // create an ADO.NET connection here based on your criteria
       }
    }

Which would leave open the connection of how to store/retrieve the connection. There are a few ways to handle this, beginning with the simplest (storing multiple connection strings in your web.config and pulling the one that applies to the current user) to more sophisticated methods (like putting all of your connection strings in an encrypted database).

Being the paranoid type, I would be more likely to do the latter.

The method that makes sense for authenticating a user (and, thereby having the information to determine which database connection to use) is mostly dependent on your setup. Some good links on setting this up with WCF would include:

  1. http://msdn.microsoft.com/en-us/library/ff647503.aspx
  2. http://msdn.microsoft.com/en-us/library/bb386582(v=vs.100).aspx

Since you are using WCF, I would use Active Directory if it is at all feasible. Windows authentication tends to play very nicely with .NET security.

share|improve this answer
    
Thanks for all the great comments :) –  user1741807 Nov 2 '12 at 21:04
    
-1: Sending the call to the service would not be a good idea. The caller should really have no idea if there is one database or one million: So tell me again - Why doesn't it make sense to let the service decide which database to route the request to? –  Jim G. Dec 2 '12 at 20:19
1  
@JimG. The wording was a little awkward. I'll edit it to reflect this, but the point was that it didn't make sense to send the connection string to the service. e.g., that it makes sense to let the service figure out which database to route to. –  Michael Dec 2 '12 at 21:17
    
OK. Then I most definitely agree with you. I'll reverse my vote to a +1. –  Jim G. Dec 2 '12 at 22:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.