Yesterday, I found an article, a video and code about using API keys with WCF. I've got to lock down a publicly exposed web service as part of what we need to do in order to comply with PCI-DSS, and this looks like the right way to move forward. In the past, this app and webservice were used only by a VB4/5/6 (now .NET) desktop application, but the boss wants it opened up as a for-pay service to others.
One financial client used a scheme with a security information element in the SOAP header. This element had 4 attributes, one was the name of the application, the timestamp and guid elements were used to prevent replay attacks and the 4th attribute was a hash based on the name of the app, the timestamp and guid, along with a "secret" (think of a password) stored in the registry (for windows servers, or a special locked down file for unix-based servers, with different "passwords" for different application names). The "secret" (or password) was intended to prevent situations where a trojan in the datacenter would be able to make inappropriate calls, or respond to them. This was obviously not WCF as it had to support unix, windows and other operating systems in the data centers, but the technique was fascinating and could be used elsewhere. Because they used url-rewriting, the security information element would not show up in WSDLs, you had to know about it from documentation that only authorised folks received; if you added
?WSDL to the end of a webservice endpoint, you got a lie.