Permissions vs. REST find/list - not applied?

[fabien]

As far as I can see enableAuth / Model.checkAccess doesn't prevent an instance from being listed. In other words, (array) output is not filtered based on the current permissions, and thus exposes data without restrictions.

Of course there will be quite some performance impact, performing (async) checkAccess calls on the results to be returned, but Loopback should be secure by default. One should be able to at least enable/disable this kind of filtering easily.

In general it should be possible to quickly do a security audit and see all the exposed resources at a glance - currently it's easy to miss any unintentionally exposed api endpoints, as it's not clear what the Loopback default behavior actually is.

[karlmikko]

@fabien As there may be multiple ACL and these ACL can be custom, and multiple ACL could resolve true for any given instance, it will be very difficult to place a default behaviour for find/list.

The current way loopback handles this is by using hasMany. So Users would haveMany books, then you ACL deny GET /books for everyone. Then you can call /users/[id]/books to get all the books for that user. Then you can edit that book with $owner ACL PUT /books/[id].

[fabien]

@karlmikko makes sense, thanks. I guess it's also possible to use an 'after remote' hook and perform the filtering - at the cost of performance perhaps?

[karlmikko]

@fabien I have been using Model.beforeRemote('**', function(ctx, instance, done){ to change a scope. That way you can look at the ctx see who is logged in, do some role checks, then alter the filter/where (find/count) to change what is visible. This way you get no performance hit as the db will do all the work, with good indexes this will be very fast.

[fabien]

@karlmikko that sounds useful too, indeed. Loopback is quite flexible in that regard. Although I would have expected that the default behavior would just apply whatever ACL is defined for findById() to also apply to find() (listing).

[karlmikko]

@fabien I expected the behaviour to be the same also. But when you look at the code closer you see that isn't really possible very easily and the hasMany seems to work well. Maybe in the future they may be able to implement this.

[raymondfeng]

Moving forward, I think we need to have a balanced solution for ACLs:

1. The declarative ACLs to check requests against model APIs
2. Developers should be able to hook some code to a remote model and/or its methods to further enforce more checks before/after the DB call

[fabien]

@raymondfeng +1 for the hooks, and possibly a way to easily merge filter/where in a beforeRemote call in a way that the find* related methods pick up the added scope. So in essence, some concept of chained scopes would be ideal, and apparently, it's already implemented in Juggler somehow:

      // Define scope-chaining, such as
      // Station.scope('active', {where: {isActive: true}});
      // Station.scope('subway', {where: {isUndeground: true}});
      // Station.active.subway(cb);

It just needs a runtime scope as part of the remoting code.

[fabien]

@karlmikko see: loopbackio/loopback-datasource-juggler#172

I am using this as a solution based on your beforeRemote technique - a combination of a hasMany and beforeRemote handler to further scope down if needed.

It's not just meant for security scoping though, and should allow dynamic scoping in general. Thoughts are welcome.

[fabien]

I posted some more info on how to tackle this here: #337

Basically, I'm using NodeJS domains and scoping at the MongoDB connector-level to ensure that all interactions are scoped accordingly. This might make its way into core somehow (generalized into loopback/juggler), so any input is welcome.

From my testing sofar this seems very flexible and easy to integrate into various scenarios, like multi-tenancy.

[bajtos]

LoopBack version 3 is in LTS, we won't be adding any new features.