Attached please find examples for forwarding rules file (rules.json) and the authorization rules file (traffic-ops-routes.json)
On Sun, May 7, 2017 at 10:39 AM Amir Yeshurun <[email protected]> wrote: > 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 >
