My problem is that I don't want anyone else to be able to use the web
service. Meaning that only the applications should be able to call the
web service to get information or execute an action on another
application.
Is there any "simple" way to do that?
There are several ways. You say you use HTTPS; so you can add a simple authentication scheme (shared secret) with very reasonable safety. I assume the applications themselves are secured.
You can also perhaps employ client certificates for the SSL conversation (i.e., the SSL channel also supplies identity certification). Depending on your setup, it might be easier to implement than adding authentication to the web service.
Possibly, you can use an authenticating proxy. This requires a more awkward setup, since you're in practice using the proxy to run a man-in-the-middle attack against your own SSL connection. Or you can use some sort of web service-aware front-end developed for that purpose, that would do essentially the same (identifying itself as the real web service, then passing the connection to the real web service after removing extra authentication information).
In all cases, you can reduce the attack surface by routinely denying access to the services at the IP level, unless the requests come from a neighbourhood of known application installations.
A specialization of this approach would be to establish a full VPN between applications and web service. This would have the advantage that neither apps nor web service would require any substantial modification, but would come at some performance cost (you're running an encrypted connection inside another).
I figured that since only the applications have access to the
database, I could probably use it as a trusted third party to validate
the identity of the one calling the web service.
You can, but at that point your applications are already communicating with the system running the web service through the database. Whatever channel you're using for the database, you can either use that same channel/method, or you should suspect it to be insecure.
For example, the applications (or the service) are now accessing an external database server - can anyone access that server? If yes, you might have some problems right there. If not, which is more likely, then why? (And I guess the answer is "SSL encrypted connection, password/certificate authentication, and/or IP verification, or full VPN").
Update
In your setup, the applications and the web services they expose are on the same machine (this is not so common, which is why I hadn't thought of the possibility). This allows for 'trivial security' -- i.e., you can expose the web service interface(s) on 'localhost'. You can even use them in the clear, dropping SSL altogether, since localhost communications won't leak outside the machine. And to intercept them one would need a sufficient level of access to the server that the point is moot anyway.
If you want, or if you ever need that, you can also expose a (different?) web service on the external interface, and run that endpoint with authentication and SSL security (possibly with client certificate check also).
As things stand, it seems to me that you are already secure. Just check that the applications/frameworks/servers default configuration does not include binding to any interface (it is very often the default), because that would potentially allow access from outside.
