Extend ACL with Relation Support

[ritch]

#115 brings up an issue that can only be fixed by extending ACLs with specific support for relations.

In this thread lets discuss the feature and track the work for implementing it.

We should also add example usage of this new feature to the access control example.

@raymondfeng @chandadharap @bajtos

[bajtos]

An idea to consider:

The remoting metadata already has accessType option allowing the method to specify READ/WRITE instead of EXECUTE.

Perhaps we can add accessTarget option that will allow the method to specify the model to use for checking the access control?

For example, Product.prototype.__get__categories can have accessTarget: 'Category'.

define('__get__' + relationName, {
  isStatic: false,
  // ...
  accessType: 'READ',
  accessTarget: relation.modelTo
});

The permission check for GET /api/products/1/categories then must perform two steps:

1. Verify that the caller is allowed to access the parent model instance (Product id 1).
2. Verify that the caller is allowed to execute the operation on the target model (READ Categories).

What is not clear: how to deal with writes, does POST /api/products/1/categories require write permissions for both Product and Category, or is it sufficient to havea READ permission for Product and WRITE permission for Category?

[ritch]

accessTarget seems like exactly what we need. We can just call checkAccess() on the target instead of the "from" model.

Verify that the caller is allowed to access the parent model instance (Product id 1).

Why do we need this? I guess this could be accomplished by calling checkAccess on both the accessTarget and the original parent model.

So to illustrate the check:

/api/products/1 => READ (Product.findById()) Product as $ROLE

/api/products/1/categories =>
  READ (Product.findById()) Product as $ROLE
  and
  READ (Category.find()) Category as $ROLE

What is not clear: how to deal with writes, does POST /api/products/1/categories require write permissions for both Product and Category, or is it sufficient to havea READ permission for Product and WRITE permission for Category?

Hmm... This makes me think that we should treat these methods as sugar and just apply the ACLs as if they were accessed without a relation. If we do this the accessType and accessTarget would be used to form a new AccessContext and a single check would be performed:

/api/products/1/categories => READ (Category.find()) Category as $ROLE

[ritch]

During an offline discussion @raymondfeng brought up an interesting alternative. To pass the remote context around the call stack as part of the options param.

The implementation of this has several parts.

1. injecting the remoteContext into the options argument

remotes.before('**', function(ctx, next) {
  if(theMethodToInvokeHasAnOptionsObject(ctx)) {
    var options = ctx.args.options = ctx.args.options || {};
    options.remoteContext = ctx;
  }

  next();
});

2. check access in all DAO methods by using observers

// add this to each DAO method
if(options && options.remoteContext) {
  // new method based on Model.checkAccess()
  Model.checkAccessForContext({
    method: 'create', // or the method
    modelId: modelId,
    remoteContext: options.remoteContext,
  }, continueWithDaoMehtod);
}

3. ensure options.remoteContext is passed in every DAO call (especially the relation sugar methods)

[ritch]

I'm leaning towards the simpler solution: adding an accessTarget to the remoting metadata and treating __get__categories exactly like Categories.find().

[bajtos]

There is one thing I dislike about options.remoteContext: it's introducing coupling between strong-remoting context object, loopback's checkAccessForContext and loopback-datasource-juggler.

At the moment, juggler is a standalone library that can be used on its own and I'd like to preserve that, as it is a good design decision IMO.

Having said that, I can imagine we can rework this initial proposal to make it more generic and fit better into the standalone juggler. For example, instead of options.remoteContext, we can pass options.principal and expect Models to override Model._authorizeOperation({ operation, instanceId, principal }). Operation = method name, e.g. "create" or "updateOrCreate". instanceId = the id of the affected model instance, undefined for "create".

Now it all depends on how much time we are willing to invest into this. Providing the current user in the options object will allow us to implement acl-based filtering in queries, i.e. the find method can return only the items the user can read. (At the moment, it returns 401 unless the user can read everything.) On the other hand, this solution will need more time to implement compared to the accessTarget alternative.

I am personally fine with both ways.