I've seen the "API Key" pattern also crop up in SOAP messages before. It's reasonably common practice to use a WS-Security block as the way to encapsulate the API Key, rather than, say, coming up with a new custom token.
The problem which Scott ran into was how to create this password-less WS-Security block using WCF. This is something that's easy to do with the SOAPbox testing tool - here is how:
First load in your SOAP message (or generate one from WSDL). Next, in the "security" menu, choose "Insert WS-Security Username":
You'll notice that you have the option to include a password, or not include a password, by selecting the checkbox:
Here we've chosen not to include a password. When we look at the message in the design view in SOAPbox, we see the WS-Security token there, but no password:
The neat thing about SOAPbox is that the configuration carries over to the Vordel XML Gateway. So the same screens which you use to configure SOAPbox are used to configure the Vordel Gateway. Let's say you want to deploy the Vordel Gateway to create the SOAP messages containing API Keys in password-less WS-Security UsernameToken blocks, as in Scott Hanselman's example. Basically you are converting from a HTTP GET (REST) to SOAP (I've written about how to do REST-to-SOAP conversion with the Vordel Gateway before) while taking the API Key from the HTTP headers and dynamically inserting it into a UsernameToken. In this way, you can support "traditional" browser clients sending API Keys, while also supporting the back-end Web Service which requires this non-traditional usage of a UsernameToken to encapsulate an API Key. This is shown below:
So, an XML Gateway is a way to support this type of "API Key in UsernameToken" case, while SOAPbox is a way to test it from the client-side perspective.
Get more information on the Vordel Gateway here.
...and Grab your copy of SOAP box here.
