Hmm...the downsides I see are: 1. Expensive in that every call requires 2 web service calls
2. Support-intensive in that your users must read your documentation to know how to authenticate 3. Difficult to scale across machines in a web farm, since you are essentially maintaining state between calls (assuming you're not storing the tokens in a shared data store) As far as #1 goes, you might be able to mitigate this somewhat by each call returning a "next token" value, perhaps in the SOAP header. This could eliminate the need for a client to call GetToken for the next call. For #2, if you were to switch to something like Digest auth, which can provide roughly the same level or security as your implementation, no one would have to read the docs; their toolkit would take care of it. If they're lucky enough to be using a toolkit that understands digest. ;-) Greg Reinacker Reinacker & Associates, Inc. http://www.rassoc.com On Thu, 23 May 2002 17:07:47 -0400, Bryan Batchelder <[EMAIL PROTECTED]> wrote: >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. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
