Thanks Amir- > On Apr 3, 2017, at 11:03 AM, Amir Yeshurun <am...@qwilt.com> wrote: > > Hi Eric, please see response inline > > On Mon, Apr 3, 2017 at 3:20 PM Eric Friedrich (efriedri) <efrie...@cisco.com> > 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 <am...@qwilt.com> 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 >> >>
