Re documentation - yes, there is no problem to share the JWT structure. The list of capability names is also part of TO API
On Mon, Apr 3, 2017, 6:43 PM Eric Friedrich (efriedri) <[email protected]> wrote: > Thanks Amir- > > On Apr 3, 2017, at 11:03 AM, Amir Yeshurun <[email protected]> wrote: > > > > Hi Eric, please see response inline > > > > On Mon, Apr 3, 2017 at 3:20 PM Eric Friedrich (efriedri) < > [email protected]> > > wrote: > > > >> Hey Amir- > >> Makes sense. > >> > >> 1) Will API Gateway be a service external to TO (like a > >> trafficserver/nginx proxy responsible just for authorization)? > >> > > [AY] Yes, the API GW and the authentication service are both external to > > TO. In a futuristic vision, TO functionality is split into a set of > > (micro)services. > > > >> > >> 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? > >> > > [AY] Yes, API GW use TO API to read AAA policy in order to enforce it. > IMO > > that is valid. Can you explain your concern about module boundaries? > > (Note that performance wise, since policy changes are rare, the policy is > > cached in the API GW) > [EF] Glad to hear that API GW is using the TO API- no concerns about this. > If API GW was making direct reads to the TO DB, I would have been concerned. > > > > > 3) What authentication methods with the auth service support (user/pass, > >> API token, OAuth)? > >> > > [AY] The current implementation is naive, and currently serve as a proof > of > > concept. Login is done via user/pass, JWT is used as the API token. > > Note that you can also use any 3rd party to maintain your users DB. The > 3rd > > party service should return a JWT that contains the user's capabilities. > If we are using a 3rd party authentication service, will there be > documentation that will allow us to generate the same JWT? > > > > >> > >> > >> —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 > >> > >> > >
