[PROPOSAL] Add Authentication Function To Mesher Gateway.

[郑志鹏 <al...@gmail.com>]

*Background:*
For now,  If Client A wants to call Service B through Gateway G with
authentication, the Authentication Server is AS. The workflow will be as
follows:

Client A (with authentication token) ---> Gateway G ----> Service
B-----> Authentication Server AS

There are two major problem with this workflow:

   1. If the interface of Authentication Server changes, all Services have
   to change. This is big disadvantage for upgradability and stability.
   2. The Authentication code fall apart in every Service and it's hard to
   manage.
   3. The authentication process happens on most of requests.But the call
   chain is too long and the performance is not good.

*PROPOSAL:*
Add an Authentication Handler in Gateway G.
There will be a configuration file in Gateway G which present that whether
an API of an MicroService access any access-controlled resource.

 For example:
/shop/good/{id}/inventory_increase   resource:inventory.

This means the url accesses the "inventory" resource.
Authentication Handler  will call the Authentication Server AS with
authentication token and the demanded resource to check if the current
token has the permission to access such resource.

The proposal approach can better all the 3 problems mentioned in the
Background section.

-- 
Best Wishes & Regards
———————————————
Alec Zheng

Re: [PROPOSAL] Add Authentication Function To Mesher Gateway.

[郑志鹏 <al...@gmail.com>]

Yes, We use mesher as gateway. Thanks for Tianxiaoliang's work, for now,
mesher can use as a gateway easily.

We deal with user&role-related authentication work in Gateway other than
in ServiceB.

Willem Jiang <wi...@gmail.com> 于2019年10月16日周三 下午5:35写道：

> It's more like a API gateway work (which should deal with the
> authentication) instead of mesher work.
> Do you want to use mesher as a Gateway?
> If you want to implement the authentication work on the Gateway side,
> the gateway need to bridge the request to Authentication Server
> instead of calling service B.
> If we want to make sure the Client A can call the ServiceB, we could
> let mesher of Client A to mesher of ServiceB with TLS client
> authentication instead of passing the token around.
> Can you explain more about your use case?
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Oct 16, 2019 at 4:57 PM 郑志鹏 <al...@gmail.com> wrote:
> >
> > *Background:*
> > For now,  If Client A wants to call Service B through Gateway G with
> > authentication, the Authentication Server is AS. The workflow will be as
> > follows:
> >
> > Client A (with authentication token) ---> Gateway G ----> Service
> > B-----> Authentication Server AS
> >
> > There are two major problem with this workflow:
> >
> >    1. If the interface of Authentication Server changes, all Services
> have
> >    to change. This is big disadvantage for upgradability and stability.
> >    2. The Authentication code fall apart in every Service and it's hard
> to
> >    manage.
> >    3. The authentication process happens on most of requests.But the call
> >    chain is too long and the performance is not good.
> >
> > *PROPOSAL:*
> > Add an Authentication Handler in Gateway G.
> > There will be a configuration file in Gateway G which present that
> whether
> > an API of an MicroService access any access-controlled resource.
> >
> >  For example:
> > /shop/good/{id}/inventory_increase   resource:inventory.
> >
> > This means the url accesses the "inventory" resource.
> > Authentication Handler  will call the Authentication Server AS with
> > authentication token and the demanded resource to check if the current
> > token has the permission to access such resource.
> >
> > The proposal approach can better all the 3 problems mentioned in the
> > Background section.
> >
> > --
> > Best Wishes & Regards
> > ———————————————
> > Alec Zheng
>


-- 
Best Wishes & Regards
———————————————
Alec Zheng

Re: [PROPOSAL] Add Authentication Function To Mesher Gateway.

[Willem Jiang <wi...@gmail.com>]

It's more like a API gateway work (which should deal with the
authentication) instead of mesher work.
Do you want to use mesher as a Gateway?
If you want to implement the authentication work on the Gateway side,
the gateway need to bridge the request to Authentication Server
instead of calling service B.
If we want to make sure the Client A can call the ServiceB, we could
let mesher of Client A to mesher of ServiceB with TLS client
authentication instead of passing the token around.
Can you explain more about your use case?


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Oct 16, 2019 at 4:57 PM 郑志鹏 <al...@gmail.com> wrote:
>
> *Background:*
> For now,  If Client A wants to call Service B through Gateway G with
> authentication, the Authentication Server is AS. The workflow will be as
> follows:
>
> Client A (with authentication token) ---> Gateway G ----> Service
> B-----> Authentication Server AS
>
> There are two major problem with this workflow:
>
>    1. If the interface of Authentication Server changes, all Services have
>    to change. This is big disadvantage for upgradability and stability.
>    2. The Authentication code fall apart in every Service and it's hard to
>    manage.
>    3. The authentication process happens on most of requests.But the call
>    chain is too long and the performance is not good.
>
> *PROPOSAL:*
> Add an Authentication Handler in Gateway G.
> There will be a configuration file in Gateway G which present that whether
> an API of an MicroService access any access-controlled resource.
>
>  For example:
> /shop/good/{id}/inventory_increase   resource:inventory.
>
> This means the url accesses the "inventory" resource.
> Authentication Handler  will call the Authentication Server AS with
> authentication token and the demanded resource to check if the current
> token has the permission to access such resource.
>
> The proposal approach can better all the 3 problems mentioned in the
> Background section.
>
> --
> Best Wishes & Regards
> ———————————————
> Alec Zheng