We have a winform app that communicates to the server via web services. Here is how we do it:
Every call to a web method is a 2 step process: a. User makes a call to the GetToken() method of the web service. Server creates a GUID and sends it back to the user. Server throws the GUID in a list of active requests (we use the HTTP cache object currently). b. User makes the call to the actual method he wants (i.e. DeleteCompany()). The user must supply the Guid, the MemberID, and the PasswordHash (the MD5 sum of the password + Guid), plus any particular parameters required by the method being called (in this case a CompanyID). c. Server first looks to see if the Guid exists in its list of active requests. If it is not there, it aborts. If it is, it proceeds to locate the password for the memberID given, and computes the MD5 hash for the password + guid. If they match the password hash sent in with the request, then we know the user is valid, and the business logic in the web method is executed. So we can have a secure transaction take place, never sending the password over the wire, and authentication happens for each and every request. The system is not prone to a replay attack. It is suceptible to a man in the middle attack (attacker could intercept your call and replace the method and parameters being called with ones of their choosing), but that could be taken care of by the client making some sort of hash out of the method signature and the server validating the hash with the actual method requested. So far this has worked out fabulously for us. --b Bryan Batchelder eBusiness Consultant ConnectWise, Inc. 813-935-7100 x 425 > -----Original Message----- > From: Brian Gambs [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 23, 2002 3:15 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier > > > There are lots of ways to accomplish this; which one is best > depends on your precise scenario and things like how > important it is to avoid vulnerabilities like replay attacks > and spoofing, the cost/benefit of SSL, etc. > > One simple technique, for example, you could use some kind of > session key as the response to the authentication method call > from client to server. The key, which indirectly maps back to > some table that stores the identity of the authenticated > user, is then stored on the client, and you require that a > valid session key be part of every method call to the web > service from the client. The web service then uses the > session key to determine who is making the call and authorize > them appropriately, connect to the right db in your case, > etc. The key expires periodically and is not just an > incrementing integer or something. > > You could transmit such a key to the WS from client in the > soap header or as an extra parameter in each method sig. > There is an MSDN sample that shows/explains such a method, I > think perhaps it was cold storage or something like that. > > Make sure authentication method is over SSL and this is a > relatively secure approach, though vulnerable if you can > sniff the calls to the WS, obviously. Unless it is all over > ssl or you get even fancier and more complex about your method calls. > > Brian > > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED]] > On Behalf Of > franklin gray > Sent: Thursday, May 23, 2002 12:02 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier > > > "you _do_ require them to authenticate, right?" > > Actually, shamefully to admit, no. I am unfamiliar with > authentication methods other then the basic application login > where I store a hashed PW in the DB and verify two hashed > values and go from there. I started to read up on it and am > getting a little lost. > > How would you suggest that I authenticate that the web > service call is from a client who has already logged into the > application and is requesting data (by Web service calls) to > populate the forms? I read that there is passport > authentication but I don't want to require my users to have a > passport. Any easy DotNet ways of doing this? > > You can read messages from the Advanced DOTNET archive, > unsubscribe from Advanced DOTNET, or subscribe to other > DevelopMentor lists at http://discuss.develop.com. > > You can read messages from the Advanced DOTNET archive, > unsubscribe from Advanced DOTNET, or subscribe to other > DevelopMentor lists at http://discuss.develop.com. > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.