Authenticating servers - what's a good approach?

Edit

Thanks for the suggestions; to clarify, we already use SSL, but that doesn't generally authenticate the requesting party, merely the responding party (IIRC?). I'll look into the other ideas right away, thanks for the brainstorm!

Background

The organization I work for has a heterogeneous bunch of servers providing various services throughout the network. They're each written in their own idiosyncratic way and have their own protocols for querying and modifying data. Unsurpr开发者_StackOverflow中文版isingly, communication between these systems is constantly growing, and keeping everything in sync and able to communicate is getting harder. To improve maintainability, we want to switch to using web-services internally; this would help simply to improve maintainability to have some kind of portable, standardized data-interchange + messaging format. With more communication also comes the need to trust other servers and the messages they're sending.

Question

We have a bunch of servers offering interrelated services via web services (i.e. SOAP). All HTTP traffic is via SSL. How can the requesting servers ensure that they're talking to the right responding server? SSL by default authenticates the receiver to the sender. E.g. assume the network is hacked or someone wants to change some info (by calling a method) without authorization. How can we prevent such an agent from simply spoofing the sender?

WS-Security implementations from various vendors (say, .NET and java) don't seem to play nice with each other - in particular when services get more complicated (with stuff like transaction support), so that solution is unfortunately probably not a good one.

We have a (trusted) LDAP server against which users are authenticated; storing server authentications here is natural - but how? Having a username/password for a server is somewhat pointless, since if you need to send those to another server to authenticate yourself, that server might not be who it claims to be, and in any case, if it's hacked, it now can pretend to be you...

Perhaps we're missing an obvious solution, so I won't muddy the waters with our own ideas just yet - what would you do?

---

You need a PKI. You can do this with stunnel, wrapping the servers. Stunnel can then be used to check certificates and authenticate, without having to alter the server code at all. Then, as you work on the servers, you can move them SSL/TLS at your own pace, without even having to do both ends at once.

---

The obvious answer here is certificates (some sort of internal PKI). But getting them to work with your various languages and so on may be complicated; and just the management of it may itself be a security nightmare.

Thus, as a way of "cheating" I wonder if you can't have them all write to a centralised 'sync' server of some type, and then they all query it. At least in this way, you make your authentication process much simpler, and you get the benefit of centralised data. I don't know if it's relevant for you, but it's the first thing I'd try and do, in such a situation.

---

At a web service level you've got things like WS-Security and WS-Trust, but sounds from your description like maybe those are the bits you're having issues with?

At a lower level you could access the web services via SSL and use the SSL infrastructure to ensure the servers are who they say they are.

Since this is internal you can sign your own certificates using something like TinyCA and install the CA root certificate on each server manually rather than paying for Versign/Thawte certs.

---

I would try to use TLS certificates. Every plattform should be able to handle this http standard mechanism.