After posting my sample implementation of accessing Amazon Simple Storage Solution (S3) via Silverlight, I reflected quickly and also chatted with some AWS engineers.
Cross-domain Policy
One thing that you should never do is just deploy a global clientaccesspolicy.xml file blindly. Often times in samples, we (I) do this. I need to be better about this guidance to be honest, so I’ll start here. As an example, for the S3 cross domain policy file, we really should add some additional attributes to it to make it more secure. Since we know it is a SOAP service, we can ratchet down the requests a little bit by adding the http-request-headers restrictions like this:
1: <?xml version="1.0" encoding="utf-8" ?>
2: <access-policy>
3: <cross-domain-access>
4: <policy>
5: <allow-from http-request-headers="SOAPAction,Content-Type">
6: <domain uri="*"/>
7: </allow-from>
8: <grant-to>
9: <resource include-subpaths="true" path="/"/>
10: </grant-to>
11: </policy>
12: </cross-domain-access>
13: </access-policy>
Additionally (and ideally) we’d be hosting our application from a known domain. In this instance let’s say I was going to host my application on timheuer.com in the root domain. I would add the allow from attribute and complete my security like this:
1: <?xml version="1.0" encoding="utf-8" ?>
2: <access-policy>
3: <cross-domain-access>
4: <policy>
5: <allow-from http-request-headers="SOAPAction,Content-Type">
6: <domain uri="http://timheuer.com"/>
7: </allow-from>
8: <grant-to>
9: <resource include-subpaths="true" path="/"/>
10: </grant-to>
11: </policy>
12: </cross-domain-access>
13: </access-policy>
Of course if I had a cool application and others wanted to embed it, I could add more domains to that allow list as well and just list them in there. But restricting it makes sense if you want to provide some secure access to your APIs (as a service provider) and to you (in methods of doing things like this sample).
More security with SSL
As I mentioned in the initial sample I changed the binding configuration, modifying the binding to use a security mode of “None” instead of “Transport.” I actually did this because I use the built-in web server from Visual Studio for most of my development and it doesn’t support HTTPS connectivity. To demonstrate my sample with S3 I had to ensure the schemes matched because in Silverlight 2 right now to access a secure service, the XAP itself would have to be served from a secure location. The contexts must match.
I’ve come to learn that even with a bucket alias (except ones with “.” characters) you can use the SSL cert from Amazon S3 as it is a wildcard certificate. So your endpoint (assuming a bucket name of timheuer-aws) could be https://timheuer-aws.s3.amazonaws.com/soap and it would work.
Using SSL of course means that currently you will have to serve your application from an SSL endpoint as well to avoid cross-scheme violations.
I hope this helps clear some things up and provide you with a more secure and recommended way of accessing Amazon S3 services with Silverlight!