Hey Amir- Makes sense. 1) Will API Gateway be a service external to TO (like a trafficserver/nginx proxy responsible just for authorization)?
2) The API GW will be performing the authorization, so will it need access to the TO DB to read the policy stored there? This seems like it may be breaking module boundaries? 3) What authentication methods with the auth service support (user/pass, API token, OAuth)? —Eric > On Apr 2, 2017, at 8:44 AM, Amir Yeshurun <[email protected]> wrote: > > Hi, > > This email relates to an the API GW and to the new AAA model that are under > development for post 2.0 TC. > > The purpose is to explain how new AAA model and existing AAA model live > together then using the new API GW. > > Currently TO handles Authentication and Authorization. > Authentication is handled by Mojolicious. > Authorization is spread in many places in the code (is_admin(), is_oper(), > is_federation()...) > > When introducing API GW, authentication is done via an authentication > service external to legacy TO. Authorization is done in the API GW. > > A new AAA model was introduced. > > - Each user in the users table has roles. Each role has capabilities. > - Capabilities define the API calls that the user is allowed to perform. > - TO DB contains a table that maps each API route to the list of > capabilities required to perform this API call > > Brief summary of the new AAA flow > > - Authentication service provides login endpoint, verify credentials > against TO DB, read the user's authorized capabilities from TO DB and set > them as claims on a JWT. > - Per each API call, the API GW verifies the JWT and match the user's > capabilities against the required capabilities for the route. > - If authorized, the API GW forwards API calls to TO. > > Note that the API GW only handles "/api" routes. It does not handle UI > routes. There was no change in the current UI app. The Current UI is not > affected by the new AAA model and keeps playing by the old rules. > > As long as TO is enforcing the current AAA model, a session has to be > authenticated against TO even when using API GW. > > To achieve that, a simple design would be > > - Upon a "/login" to the new authentication service, the authentication > service will perform a login operation against TO to get a "legacy" > authentication token. The auth server sets the legacy token as a claim in > the JWT. > - Legacy authentication is done *in addition *(and *not instead of*) to > verifying the user tmUser and providing capabilities using the new AAA > model. > - The legacy token expiration should be longer than the JWT expiration. > - The API GW authorizes the call using the new model. > - If the request is authorized, API GW pulls the legacy token from the > JWT and set the request "Cookie:" header accordingly, before forwarding the > request. > > When all TO functionality is supported via API, and TO UI is replaces to > the new UI built on top of the API, we can consider deprecating the old > model as well as the Mojolitions app. > > Thanks > /amiry
