0
votes

I'm testing out the recently released DocumentDb and can't find any documentation indicating best practice on how to perform user data segregation.

I imagine the rough design would be:

  • Authenticate the user and create new/obtain existing user id
  • On document insert inject the user id into the document
  • On read of document/collection of documents query where document user id = current user id

I'm creating an AngularJs application and currently use an Azure Sql Database combined with Azure Mobile Services.

Mobile services handles the user authentication and also the server side user data segregation by the use of data script javascript functions:

e.g.

function insert(item, user, request) {
  item.userId = user.userId;
  request.execute();
}

Any suggestions on what would be the technique for secure user data segregation from AngularJS using DocumentDB?

1
So the penny just dropped on how this should be implemented. Azure Mobile Services uses Express to provide both the built in API for Sql, and the Custom Api functionality. So the obvious path will be to write a custom api using js that uses Express to access the DocumentDB under the Azure authenticated user's credentials. When I have some source that works I'll answer my own question and post here. - j3r3m7

1 Answers

1
votes

Your approach sounds reasonable to me - assuming the logic mentioned in your rough design takes place in your backend service.

Generally, I'd treat DocumentDB similarly as you would treat any other datastore. Your client (AngularJS) makes calls to your backend service, rather than making calls directly to your datastore. Your backend validates the client's request (i.e. assert that the user is authenticated and may touch a particular piece of data) before delegating any work to your datastore.

If direct database access from the client is desired - you can check out DocumentDB's users and permissions. For implementing multi-tenancy for your application, you can create users in DocumentDB which corresponds to your actual users or the tenants of your application. You can then create permissions for a given user which correspond to the access control over various collections, documents, attachments etc. On your client, you can connect to the database using the User's resource key rather than your DocumetnDB's administrator keys.

Check out this blog post on DocumentDB users / permissions: http://blogs.msdn.com/b/cloud_solution_architect/archive/2014/12/09/permissions-in-azure-documentdb.aspx