I have a client-server program that uses sockets to transfer information in a stateful fashion. What I mean is, the connection is persistent, and authenticated using a public and private key baked into the software itself. It works well and is very efficient, but the overall framework I’ve set up makes adding anything new a long process, so I’d like to move to Web Services. At some point I’ll get a certificate and use SSL, but right now I’m just worrying about making sure users are authenticated to do what they’re trying to do.
The original schema had users entering their username and password at the start and the server simply remembered who they were for the life of their connection. Now that I’m moving to stateless web services, I’ll probably have to hand this information over with every request. I’m fairly new to web services, did some searching around the net, and found two suggestions for how to do this. One was just to send an authentication object with each function call, and the other was to stick username and password info in the SOAP header. I’m a little confused as to which would work better since either way you’re still just doing a string compare on the server side (well, in the case of a password, a hash and then a compare).
Also, while the client side of this is a WPF application, in the future I’d like to make a browser enabled version. Would my decision of how this is done affect future web efforts? Thoughts!
Edit: I should mention that there are a few levels of access. The lower levels can only access certain functions, where as the highest level can access them all. I assumed this is something I would have to verify in the functions themselves, but if there’s a built in way to handle this easier I’m all ears.
You should opt for standard implementation, something from WS-Security, which means passing authentication data outside of message body. That’s reasonable because security and message contents represent two separate concerns that should not be mixed; you should be able to simply swap out one security option for another without changing message structure.