Extension: Add Authorization component

[dhmlau]

Related to #512

• decoration at controller/method level may not be flexible enough
• URL-based rules as an alternative
• fine-grained access control on per-model-instance basis - ideally solved at Repository level
• local User/AccessToken auth scheme and models
• ACL/Role-based rules vs. scope-based rules
• JWT
• OAuth

[dhmlau]

Marking as Core-GA per our discussion.

[buzzware]

As a general framework approach for authorization, I've used Pundit extensively in Ruby on Rails and found it extremely flexible and powerful. SailsJs has something similar https://sailsjs.com/documentation/concepts/policies

Pundit is really a documented pattern and a support library implementing it in very little code.
It imposes a minimum of assumptions on what your authentication logic is, since it boils down to :

1. a plain Ruby "policy" class for each model class, with
   a) a constructor which receives a user model and a model object or class and stores them as instance variables
   b) methods loosely named after actions the user would ask for authorization to perform on that model. These methods return true if the user should be able to perform the action on the model, otherwise false.
2. utility methods for assisting the process of creating an instance of the right policy object

Thats it! How you implement the methods in b) is entirely arbitrary, and since it is just a plain class/object, you can use inheritance or whatever you like, and application code can arbitrarily instantiate a policy object and query it anywhere.

I believe this approach can be adopted and recommended at a framework level, and used directly by app developers, or used to implement other authorization strategies.

[elv1s]

Is there going to be a User and Role model included in the authorization framework, or will that be provided by the app?

Will the framework concern be annotation on the controllers to describe authorized roles per path/verb?

[jannyHou]

I would proposal we provide built-in User and Role models and allow app developers replace them.

[raymondfeng]

Is there going to be a User and Role model included in the authorization framework, or will that be provided by the app?

At the moment, we don't have a plan to ship built-in User/Role models. There are probably some interfaces to capture the basic requirements for such entities if necessary.

Will the framework concern be annotation on the controllers to describe authorized roles per path/verb?

I expect to have decorators to allow developers express their authorization requirements at controller class/method level.

[bajtos]

+1 to for leaving out User/Role models from the core authorization framework. In my experience from LB3, built-in User/Role models were difficult to maintain and very often not flexible enough to support different real-world use cases.

However, I think it probably makes sense to provide a standalone package offering a minimal implementation of User & Role models for demonstration purposes. LB4 users can then use this minimal implementation to build their own User & Role classes.

[samarpanB]

@bajtos We did implement a separate authorisation component in our first lb4 application. It was implemented as decorators at method level in controllers. The permissions were picked from access token (JWT). The implementation was not as vast as mentioned here, but it was good workable solution for us. If there is any way I can help/contribute to this task, please do let me know. I can share our implementation if needed. But it was more or less following the same guidelines mentioned here for authentication component. These guidelines were really helpful.

[dhmlau]

@samarpanB, I think that would be helpful if you could add documentation on how to create such component.
I'm thinking to add LoopBack Component > Authorization on the sidebar where the content from @samarpanB will be on that page.
Thoughts, @samarpanB @strongloop/loopback-maintainers?

[dhmlau]

Related:
@osmanmesutozcan has created an extension https://github.com/xanthous-tech/loopback-4-accesscontrol (mentioned in #2254)

[samarpanB]

@dhmlau Sure. That's a good idea. I'll put that documentation up. Can you please help me with where to start ? I think https://github.com/strongloop/loopback-next/tree/master/docs/site is the place where all pages md files are kept. So I need to create a new one here, right ?

[dhmlau]

@samarpanB , you're right. For sidebar, it's from https://github.com/strongloop/loopback-next/blob/master/docs/site/sidebars/lb4_sidebar.yml. Thanks!

[samarpanB]

@dhmlau added documenation in above PR. Please have a look.

[lvlinh961]

Hi everone,

I want to check whether user loged in berfore check I check his/her permission, I dont want to add "@authenticate" decorator to method when i added "@access" decorator to it (option configure the access control). How can I do that.

[samarpanB]

@raymondfeng I was trying to look for the doc page on https://loopback.io/doc/en/lb4/Using-components.html. But it’s not there yet. Is it not yet moved there ? As per my understanding, there is a daily job which moves it there.

[raymondfeng]

We need to publish a release to npm 1st.

[raymondfeng]

@samarpanB I just made a release. The document site will be updated soon.

[dhmlau]

@samarpanB, it's up: https://loopback.io/doc/en/lb4/Loopback-component-authorization.html. Thanks for your contribution!

[dougal83]

Thanks for your work @samarpanB. I've just been looking at your implementation.

Could I ask if there are plans to map roles to scopes at this point in time? Personally I'd find an implementation or roles based on oath scopes a logical path to follow especially in conjunction jwt for auth.

EDIT: NM Found this: #1035 (comment)

[raymondfeng]

See #1205

[dhmlau]

Closing as done.