[Spike] Investigate the minimal infrastructure we need to support authorization

[dhmlau]

Description / Steps to reproduce / Feature proposal

Capturing the discussion with @raymondfeng @bajtos

There are different choices to support authorization:

1. interceptor
2. middleware (our original approach, that's why we have https://github.com/strongloop/loopback-next/pull/2434)
3. sequence action

@raymondfeng did some initial investigation and think interceptor might be a better approach, because middleware doesn't have access to the target method.

Acceptance Criteria

• [ ] Investigate what's the better approach to support authorization - interceptor, middleware or sequence action
• [ ] look into what's the minimal infrasturcture we need to support authorization

[raymondfeng]

See https://github.com/strongloop/loopback-next/pull/2687.

Please note the middleware layer does not have information about the target method and corresponding arguments and context. It's probably not suitable for authorization decisions.

[emonddr]

Investigate minimal infrastructure to support authorization, using interceptors and a community authorization example as inspiration for the POC.

[JesusTheHun]

Interceptors are great because they are quite simple, they are just annotations with a clear semantic purpose : modify the incoming request and/or the out coming response. However this simplicity implies a few limitations :

1. You cannot add default behaviour in the absence of these annotations, so a controller without the proper annotation will not have its access denied, which is the security standard.
2. You do not control the chain of execution. If you add a class level interceptor and then you add a different method level interceptor, you don't know which one will be executed first, which can be important if not a true issue.

These problems can be over come, of course :

1. you can add the default annotation to a base controller you will use as a default, but as an architect I don't like this approach since it's a security related feature, I don't want to rely on developers not forgetting something. Security should be the default behaviour.
2. you can add a priority number in your declaration but you will never know if some third party interceptor is not hijacking your position, and maybe you will encounter equalities.

For those reasons I think the sequence approach is the most reasonable : your sequence action is always called, so you have a default security behaviour. You can declare specific authorization behaviours by using annotation on the class or the method you want. You always know when your sequence action will be executed ; if you need extra context execution such as loading database-stored ACLs, you can declare those by using previously mentioned annotations.

EDIT : the minimal infrastructure required for my proposal is :

• An authorization definition interface and common adapters : database, authorization server
• An authorization manager : a service to which authorization definitions and user code annotations will register to. This is the core component.
• An authorization sequence action : uses the authorization manager to allow or deny the request, provide default rejection response or redirections.

[bajtos]

Related: https://github.com/strongloop/loopback-next/issues/1462

[raymondfeng]

You cannot add default behaviour in the absence of these annotations, so a controller without the proper annotation will not have its access denied, which is the security standard.

We support global interceptors that are bound the context with a special tag.

You do not control the chain of execution. If you add a class level interceptor and then you add a different method level interceptor, you don't know which one will be executed first, which can be important if not a true issue.

We define the order of execution.

See https://github.com/strongloop/loopback-next/blob/interceptor/docs/site/Interceptors.md for more details.

[JesusTheHun]

I've think about it lot. Global interceptors solve the first issue I mentioned, but the second about third parties was not answered. I was unable to find the definition of order execution of global interceptors in your doc, beside local interceptors.

The order of execution must be defined in user land, not in the interceptor itself. This will prevent third-party interceptor order overlap, and add a bit of security preventing malicious invisible interception embodied into a third-party interceptor.

This being said, interceptor pattern seems fine to me.

[raymondfeng]

Interceptors are now supported. We also allow you to control order of global interceptors.

[dhmlau]

See PR https://github.com/strongloop/loopback-next/pull/1205

[raymondfeng]

Based on https://github.com/strongloop/loopback-next/pull/1205, we can use interceptor to enforce authorization.