This is possible using AWS IAM (Identity and Access Management) and a server side "token vending machine". AWS docs have an article specifically written for the use case Authenticating Users of AWS Mobile Applications with a Token Vending Machine and sample code for server, iOS, and Android in GitHub. The general technique can be used for non-mobile and/or for JavaScript clients.
Note: a server component is still required to vend out the temporary access tokens. However, the volume of these requests can be significantly reduced (up to once every 36 hours). The remaining requests are from untrusted client to SimpleDB directly, no intermediary.
General Technique
- anonymous client calls your token vending machine (your server)
- token vending machine knows the secret key, calls AWS to generate a temporary token
- vending machine returns token to client
- client calls simpleDB API using anonymous, temporary token; cannot write to SimpleDB
Read Only Access Policy
From AWS sample code "Read Only Access Policy"
{
"Statement": [
{
"Action": ["sdb:GetAttributes", "sdb:List*", "sdb:Select*"],
"Effect": "Allow",
"Resource": "*"
}
]
}
This extends beyond SimpleDB. You can set an access policy for several other AWS resources (see full access policy example).
Variation to Replace Dynamic Client-Server calls with Static Resource
Although you cannot eliminate a server component, clients don't necessarily have to talk to the vending machine directly:
- scheduled job generates
token
every N seconds where N + fudge == token expiry
- job writes
token
to public S3 bucket (or any other static resource)
- set appropriate maxAge cache-control header based on
fudge
- anonymous client reads
token
from static URI
- client authenticates with
token
, makes read-only calls to SimpleDB
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…