Front-End Web & Mobile
DynamoDB on Mobile – Part 5: Fine-Grained Access Control
In previous posts in this series (Parts 1, 2, 3, and 4), we discussed how we can read from and write to an Amazon DynamoDB table using the AWS Mobile SDKs. In this post, we will discuss one way we can secure the data accessible from individual mobile devices.
A User Data Table Revisited
In Part 1, we discussed a user data table where we had multiple users’ data existing in the same table. Our model looked like the following:
- UserId – our Hash Key to uniquely identify the user, stored as a numeric value.
- RecordId – our Range Key to identify a given record for the user, stored as a string.
- Data – the data for the given record and user. As it is not being indexed, we can use any type supported by Amazon DynamoDB.
As the data for all users is stored in the same table, any user who has access to the table via an access policy has access to all users’ data. Now with fine-grained access control for DynamoDB developers can set a policy to restrict access to those items they actually own:
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "dynamodb:DeleteItem", "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Query" ], "Resource": ["arn:aws:dynamodb:REGION:123456789012:table/UserData"], "Condition": { "ForAllValues:StringEquals": { "dynamodb:LeadingKeys": "1234"} } }] }
The above policy would allow the user with the UserID 1234
to access and modify only their data. We could use a policy such as this, in combination with a token vending machine to vend credentials to our mobile apps and restrict access to our users’ data. By simply replacing the dynamodb:LeadingKeys
value with the user logged into the app. This is a great solution if your app already has a back end and its own private pool of users.
Integrating with Web Identity Federation
If our users are logging in via Facebook, Google, or Amazon, we can instead make use of web identity federation and policy variables in AWS Identity and Access Management to create a temporary session for any user.
The DynamoDB console makes this easier, including an Access Control wizard for generating a web identity federation compatible policy.
In the wizard, you can select the provider you want to use and the operations you wish to allow, as well as specifying which attributes to grant access to.
The wizard will generate a policy like the following, which you can then take to the IAM console and create a role for web identity federation:
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "dynamodb:DeleteItem", "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Query" ], "Resource": ["arn:aws:dynamodb:REGION:123456789012:table/UserData"], "Condition": { "ForAllValues:StringEquals": { "dynamodb:LeadingKeys": ["${graph.facebook.com:id}"]} } }] }
Using Fine-Grained Access Control with Local Secondary Indexes
If we want our mobile app to be able to make use of a local secondary index, such as we described in Part 4, we simply need to add any indexes we want to use as additional resources in our policy:
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "dynamodb:DeleteItem", "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Query" ], "Resource": [ "arn:aws:dynamodb:REGION:123456789012:table/UserData", "arn:aws:dynamodb:REGION:123456789012:table/UserData/index/LastModifiedBy-Index", "arn:aws:dynamodb:REGION:123456789012:table/UserData/index/LastWritten-Index" ], "Condition": { "ForAllValues:StringEquals": { "dynamodb:LeadingKeys": ["${graph.facebook.com:id}"]} } }] }
Conclusion
We hope this shows how you can effectively and securely use DynamoDB in a mobile application. As more features are added to DynamoDB and/or the AWS Mobile SDKs, we will continue to post how you can leverage these features in your mobile apps. If you have suggestions for new features or posts you’d like to see, please consider leaving a comment here or in our forum.