If I'm understanding you correctly, you have a client application that makes a web service call that might look something like the following:
DoDBStuff(serverName, dbName, otherInfo) You may have a client application that doesn't try to do anything fishy, but if these services are being hosted on a non-secured network (like the internet), then you can't control who else might try to access your services. Suppose I'm a customer of yours; with a little reverse engineering, I can figure out your API and the above signature. Now, I can try to write my own application that authenticates with my own credentials (you _do_ require them to authenticate, right?), but tries some other possibilities for serverName and dbName. If I work at this for a while, I'm bound to hit upon one. So there you have my point - if my understanding of your system is correct, then you are giving the user the opportunity to try to access data he should not be able to see. A much more secure solution would be to change your web service calls to something like DoDBStuff(otherInfo) And have your web service code look up the servername/dbname information from a shared database or directory based on the credentials of the caller. Greg Reinacker Reinacker & Associates, Inc. http://www.rassoc.com -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:ADVANCED- [EMAIL PROTECTED]] On Behalf Of franklin gray Sent: Thursday, May 23, 2002 8:15 AM To: [EMAIL PROTECTED] Subject: Re: Help Architecting A Middle Tier I think I have lost people. When I say the client, I mean the client software. This is a desktop app. When the user logs in, I create a Current user object on the client machine. The object will have a server and DB name properties. When Web Service calls are made, the client application will supply these two properties as parms to the web service call. Keep in mind, we are using Web Services as a backend to a desktop app for a few reasons. 1) has to go through firewall. 2) We control the cryption and compression of data being sent over port 80. Not SSL needed and large files sent from Client machine to server gets compressed. -----Original Message----- From: Greg Reinacker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 7:37 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier This is a bit OT, but you say "we were going to have everybody pass in what company they belonged to and we would know what server and DB to use for that user." If I were you, I'd force the user to authenticate, and then decide for yourself what company he belongs to. Don't give him the opportunity to lie and tell you the wrong company. I only mention this because I've actually seen a design like this in production, and in that system it was possible to try to lie about your identity. Difficult, but possible. Greg Reinacker Reinacker & Associates, Inc. http://www.rassoc.com -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]] On Behalf Of franklin gray Sent: Wednesday, May 22, 2002 2:43 PM To: [EMAIL PROTECTED] Subject: Re: Help Architecting A Middle Tier "If you're talking about scaling to 50 users, probably not a big deal. But maybe. If 5000, you definitely want to take a really hard look at your design, and above all else: read "Transactional COM+" by Tim Ewald." The design we are taking is that when we start hosting, we have to keep different clients data in different databases, at least that's what my boss says because the clients wouldn't go for their data sharing a DB with another company. Of course, we can't put to many companies data on one SQL server, so we were going to have everybody pass in what company they belonged to and we would know what server and DB to use for that user. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
