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 郑志鹏 <aleczhen...@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
