You can use IAM to restrict access to DynamoDB items but for those unfamiliar with the intricacies of IAM roles or wishing for more dynamic permissions on the application level we can use a second table instead.
If we have a set of entities we want to control access to, we can use the pattern
actor controlType entity. For example:
So for example let's say the following steps happen.
user 6as a writer so they can start writing.
user 5as an editor, so that they can make changes and suggestions to the document
user 5sends the document to
user 9, who can now read it but not make any changes
We would end up with the following DynamoDB table items
With an index of pk+sk on the table, this allows us to query for any roles a user has.
and then we can use the
Items returned from our query to determine if a user has a sufficient role for a given entity.
Here's an implementation that uses dynamodb-toolbox to create the
hidden means the serialized object won't have that key, and
save means that field won't be saved in the DynamoDB table as an attribute. So what we end up with is two fields, built up from the other 6.