Hi all, I am about to submit a PR with a first operational version of the API GW, to the "experimental" code base.
The API GW forwarding logic is as follow: 1. Find host to forward the request: Prefix match on the request path against a list of forwarding rules. The matched forwarding rule defines the target's host, and the target's *authorization rules*. 2. Authorization: Regex match on the request path against a list of *authorization rules*. The matched rule defines the required capabilities to perform the HTTP method on the route. These capabilities are compared against the user's capabilities in the user's JWT At this moment, the 2 sets of rules are hard-coded in json files. The files are provided with the API GW distribution and contain definitions for TC 2.0 API routes. I have tested parts of the API, however, there might be mistakes in some of the routes. Please be warned. Considering manageability and high availability, I am aware that using local files for storing the set of authorization rules is inferior to centralized configuration. We are considering different approaches for centralized configuration, having the following points in mind - Microservice world: API GW will front multiple services, not only Mojo. It can also front other TC components like Traffic Stats and Traffic Monitor. Each service defines its own routes and capabilities. Here comes the question of what is the "source of truth" for the route definitions. - Handling private routes. API GW may front non-TC services. - User changes to the AAA scheme. The ability for admin user to makes changes in the required capabilities of a route, maybe even define new capability names, was raised in the past as a use case that should be supported. - Easy development and deployment of new services. - Using TO DB for expediency. I would appreciate any feedback and views on your approach to manage route definitions. Thanks /amiry
