Keeping a secret key secret with Amazon Web Services

Question

I'm playing around with using amazon web services in my personal project. I've grabbed their AWS SDK for .NET and I'm using that, but I'm a little confused.

1. Access to the web service (in this case, SimpleDB, though I don't think that's really material to the question) is authorized via a private/public key pair.

2. The AWS SDK for .NET API used to create a client object requires the private key:

   AWSClientFactory.CreateAmazonSimpleDBClient(publicKey, privateKey);
   

3. This is a client application, so the code would be running entirely on the client.

4. Suggesting that the client would need to have access to my private key to have access to the SimpleDB. But amazon repeatedly and emphatically states that my private key must not leave my control.

This doesn't make sense to me, so I figure I must be missing something.

Is a client-side application the wrong model for the amazon web services in general, for using their AWS SDK for .NET, or am I missing something that makes a client application perfectly reasonable? Is there a good way to work around this without creating a proxy service of my own that would authenticate clients and forward their requests to the SimpleDB?

Answer 1

It sounds like you need a proxy web service, that handles authentication between your proxy and your users. Each user would authenticate using some credential you issue only to them. If the proxy decides a client is authorized, it can make the call to Amazon's service using your private key.

Answer 2

You don't need to implement a proxy that fronts the remote (AWS) service. Just implement a simple, small, authenticated service which returns to the client the URL and headers to use when contacting AWS. Your authenticated webservice keeps the AWS secret, and only provides the signed request URL and headers to the client, which then goes and makes the actual work call using that returned information.

This way, you avoid the overhead during the AWS call of having to go through your own servers, saving latency, bandwidth, tied up sockets on your server, failure handling complexity, etc. You just take a lightweight hit up front for the client to get the proper instructions.