[Spike] Allow extensions to contribute custom authorization providers and strategies

[bajtos]

So far, LB4 does not provide any built-in solution for authorizing incoming requests (see #538). In this spike, we should investigate how LB4 app developers can implement and configure their own authorization scheme and verify that LB4 design is flexible enough to support them.

The idea is to build a new authorization component to validate if our extensibility story is good enough - #1205. Basically, instead of shooting in dark, using the authorization use case as the driver for the spike.

Acceptance Criteria

• use authorization component to hash out how our extensibility feature is going to be further devleoped

See also #1034 and #1035

[raymondfeng]

See #1205

[raymondfeng]

The idea is to build a new authorization component to validate if our extensibility story is good enough - #1205. Basically, instead of shooting in dark, using the authorization use case as the driver for the spike.

[shimks]

Please add in the exact questions that need to be answered as a result of this spike: how does it play with the existing authentication component? What exact artifacts need to be explored with this component?

[dhmlau]

@raymondfeng , with the PR #1205, would you consider the spike is done and we should have a spike meeting to share/discuss the outcome? Thanks.

[bajtos]

Cross-posting from #1072

User Experience

• For a given controller method, we should be able to use decorators to express the authorization requirement. e.g. we allow / deny certain roles.
• need to have the ability to decorate the methods to indicate the scope of the resource access. i.e. group the methods for access. e.g. write access for Order.
  • describe your protection scope for the method
• An authorization example: when cancelling order, only the customer and customer rep can cancel.
• can possibly use json / yaml files to define the access rules, besides using decorators.
• Need infrastructure to help us to make the yes/no decision - decision could be determined by the rules defined in the application, or need to consult external provider (e.g. enterprise might have a centralized authorization management system). This can be expressed in extension points to plug in other authorization providers.
• from admin perspective, we need a way to specify the role mapping. i.e. which user belongs to which role.
  1. static mapping table.
  2. some role has to be dynamically determined per request, e.g. cancelling order. need to figure out for the given orderid, it matches with the customerid to place the order.
• authorization has the dependencies on authentication, because we need to know who is making the call. Two pieces of identity 1) the user itself, 2) application id making the request <--- think FB app.
• also look at what we have in LB3 for functional parity
• we also allow developers to write code to override our authorization decisions (added business logics in the controller)

Questions to answer

Timeboxed max to 2 weeks

• mockup decorators to show what metadata is required for controller/method
• need to understand the interface for authorization provider
• need to understand the roles (for grouping users)/scope (for grouping resources)
• what customization we allow developers to do at the controller level
• need to understand what json/yaml externalization for access rules and resource definitions and other metadata
• need to understand what tooling to provide to harness the authorization requirement
• identify the dependencies to the authentication component