You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by Amir Yeshurun <am...@qwilt.com> on 2017/04/02 12:44:27 UTC
API GW, new AAA model and legacy AAA model in Traffic Ops
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
Re: API GW, new AAA model and legacy AAA model in Traffic Ops
Posted by Amir Yeshurun <am...@qwilt.com>.
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) <ef...@cisco.com>
wrote:
> 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) <
> efriedri@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
> >>
> >>
>
>
Re: API GW, new AAA model and legacy AAA model in Traffic Ops
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
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) <ef...@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
>>
>>
Re: API GW, new AAA model and legacy AAA model in Traffic Ops
Posted by Amir Yeshurun <am...@qwilt.com>.
Hi Eric, please see response inline
On Mon, Apr 3, 2017 at 3:20 PM Eric Friedrich (efriedri) <ef...@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)
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.
>
>
> —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
>
>
Re: API GW, new AAA model and legacy AAA model in Traffic Ops
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
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 <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