Protecting Web Services

I've got a WebService project that we've created to expose some methods to our clients (specifically if they call one of the methods it will trigger an event on our servers) that they can call in their own C# projects (some clients will be doing web form apps and some will be doing it on their internal site).

Due to the nature of the method, one of the parameters is a string which identifies who the client is (so we can trigger the appropriate event) and I'm not overly confident this is enough to prevent people from sending random data until they stumble upon one of the valid identifiers.

What is the standard way of protecting something like this from abuse? Most of the tutorials I find don't seem to mention anything about keep开发者_开发问答ing them secure. Thanks!

Daniel Vassallo is correct. You will want to use a X509 certificate to verify that the person calling the service is legitimate. However this does raise the complexity of the solution a lot. You will want to use Microsoft WSE and likely a purchased 3rd party component.

Without that, you can use a user name and password passed in. However, there would need to be some shared algorithm to hash the information based on date, time, etc.. without the hash, you open yourself up to a hack much more than not. Even with SSL, as a dictionary attack could eventually break in.

1. Using a username and password should be good.
2. If you know the clients IP address of the machines that will call webservice, restrict the URL to only to the known IPs.

You may want to check out the WS-Security protocol.

This protocol contains specifications on how integrity and confidentiality can be enforced on Web services messaging.

Authentication is usually handled using SOAP headers, see this MSDN page.

This codeguru article gives an example although it's quite old.

as part of the protocol you may send a random number to the client. The client then salts the Identifier with that random number and Hashes the combined value. You may return that combined value back to the server.

Server then computes the same ID+Number hash and verifies the two values.

This is efectively a password... except wait no its a user name and password in one field.

There is no technical reason per se why you shouldn't combine a username and password into one field but by convention oin the absence of additional secret keys they are two fields.

This is for three business reasons:

• The account identity can be discussed unambiguously between people that should know the user identity (user name?!) but not possess the password

• It is easiest in law to prove unauthorised access, should this ever be necessary, if the access protocol is conventional because then case law is more likely to apply and the situation is more likely to be clear cut (and to lead to smaller legal bills!). Not having a user name on a public network for a commercial system is not unheard of and in some systems is a good idea (but generally it just plain isn't... a good idea).

• Guidelines on best practice in security generally and specific processes assume you use a user name and password rather than a combined field where possible. It may make it harder to formulate consensus policies down the line.

The password (or the password portion if you go with a combined username/password string) will be subject to all the usual recommendations on security regarding change policy, non-disclosure, complexity and length. I suggest you use SSL and WS-Security as well, to be as conventional in the security area as possible. You probably need encryption on the wire.

EDIT

I meant to write TLS not SSL.

EDIT

Sorry no I meant either TLS or WS-Security.