The simplest way seems to configure the webserver so no request other than from "your system" can be made to said webservice.

Otherwise, use some kind of authentication. There are thousands of techniques to choose from, many of them available in ready made source code, randing from simple and easy to use for the user, to very secure, and more hassle (work) for the user.

What's the best pick for you, is impossible to determine from the post.

You could use a public key encryption scheme. Crypt::RSA would seem like a good start.
Another option might be persistent sessions, CGI::Session might be worth a look.
Sorry for the vagueness of the answer, but there isn't enough information in the original post to be more specific.

No way? Uhm, that very much depends on your definition of "your system". And HTTP may be stateless, TCP certainly isn't (not that statelessness matters). In the simplest case, you have a network like this:

As the context is a web game there is probably money involved. It really depends on how far you want to push it. I advice you to first write down your security objectives i.e. wat are your requirements? You probably need more than establishing who sent the message. (If authentication is the only thing you need you can for example do this with SOAP Headers.) Next you do some threat analysis, e.g. what threats are relevant for you? Then you can start thinking about implementation. If your users perceive the system as unsafe your game will probably be short-lived.

With SOAs being all the rage, and WSs often being part of that, a lot of effort was put into security. I recommend scanning through the book "Improving Web Services Security" although this is MS based it gives a lot of useful information, e.g. architectures, security patterns etc.

Actually no. You can use a challenge/response technique. Take the MD5 hash of the current time plus some secret "seed", and send that to the client. Then, whenever the client requests that action, it must supply this MD5 hash. On the server side, you recalculate the hash for each of the last x seconds, and see if any matches what the client supplied. Only permit the action if the hash matches.

The trick is to only deliver a hash to the client when it is a valid time to perform the action. And by restricting x to a small number of seconds, you control fairly tightly when the action can take place. So even if they do fake it, they can only fake it when it's a valid time to perform the action anyway.

Think of the server as a bartender, who needs to check id, serve drinks, make change ... only bartender touches the cash register, customers always have to go through bartender, and he knows how to spot fake currency, fake ids, how much vodka is left ... bartender is gatekeeper

This is both an authentication problem, and an authorization problem. The request (of course) has to come from a properly authenticated subscriber. But in addition, the incoming request must have been authorized. For example, add some kind of token, whose contents are random, that must be returned by the client (in so-many minutes, and acceptable just once) with the request. The server confirms that the token is authentic, issued to this user, and not-yet-used. The presence of that token-value authorizes the request to be carried out. The token, issued by the server and with totally unpredictable contents, can’t be faked, and once the server decides it’s been used, can’t be used again.