Eshoponcontainers: Multiple authorization authority with Ocelot

[NicolasREY69330]

Hi,

First I'm very impressed by your work and I would like to thank you for that, I spent many hours reading your code and learning Microservices architecture reading your eBooks.

I had the exact same question that your answered here ie : why microservices are authenticated as well as the gateway

Well here is my global question :
I would like to know what is the best pratice considering that one or more microservices behind the same gateway may have differents authorities.

Here is an example :
Under the same gateway (all routes authorized by Identity server and a B2B database), I have three microservices .

• Microservice A
• Microservice B
• Microservice C (B2B specific)

Under another gateway (all routes authorized by Identity server and a B2C database) , I have exatly the same A and B common microservices plus D as specific .

• Microservice A
• Microservice B
• Microservice D (B2C specific)

Both gateway/microservices should return the same data, regardless of authority, but for authentication we have to deal with 2 dabatase : a B2B based users and a B2C based users.

Should we set the authority on each microservices as well as on each ocelot routes (as you precognized in the cited above issue) or should we remove the authority from the microservice, and handle the bearer by a middleware to get claims and apply specific rules ?
Is it even possible that the same microservice (let's say A) used two differents authorities based on identity server (ie : B2B database and B2C database) ?

This solution sounds strange to me and I think to a third and simplest approach:

Under the same gateway (authorized by Identity server and a B2B/B2C database (same authority)), I have a four microservices .

• Microservice A (same authority)
• Microservice B (same authority)
• Microservice C (B2B claims specific and same authority)
• Microservice D (B2C claims specific same authority)

So to conclude : is it a good practice to split B2B and B2C users into two identity server authority or to share the same autority (B2B and B2C users) ?

[ValDY69]

Hi,

+1 i had exactly the same question !

in my company we want to implement the gateway pattern but we have a problem : we want to split users into differents identity server ( filtered by user's type ).

So we think about each gateway are authorize by only one identity server (that represent a type of user)

but the problem is that we want to share the access of same microservices into differents gateway.

in your eShopOnContainers the microservice are authorized (only one identity server) but in my scenario it is not possible because i have many identity server...

@CESARDELATORRE , do you have any architectural solution to maintain two or more identity server into microservice pattern behind many gateways ?

Regards

[mvelosop]

Hi @NicolasREY69330, @ValDY69,

This is a very interesting question! 👍.

As far as I understand in Ocelot's authentication documentation it's possible to add several authentication services, as long as they have different schemes.

However, I haven't had to tackle these scenarios and they are outside the scope of eShopOnContainers, so you should probably be better requesting some consultancy from the creator of Ocelot.

Hope this helps.

[mvelosop]

I asked a friend that has plenty of experience with Ocelot and Identity (@hbiarge) about this issue.

For this case he considers that having two separate identity providers (B2B and B2C) is definitely the way to go.

It's also possible to use two identity providers for one microservice although setting it up can get a bit tricky. But you could also use no auth for those microservices since they are behind the gateway (perhaps inside an orchestrator).

So you might explore those ways.

Even though this is outside the scope of eShopOnContainers, I'll leave the issue open for a couple of days, because it's a very interesting topic and perhaps you might get to contact someone to delve into this if you need.

Hope this helps.

[NicolasREY69330]

Hi,

that sounds great to me that you achieve to the same conclusion as me : the microservices could use no auth as the Gateway already does the trick.

The only trouble I see using this method is I can't use [Authorize] and policies into my microservices, and I need to unparse my bearer token from a middleware in order to get my claims if I need to apply some rules (ie : return specific DTO from an Action)

According to you, what is the best way to handle this problem ?
Thank you

[mvelosop]

@NicolasREY69330, @hbiarge also mentioned you can tweak the middleware in the microservices to accept either one of the two tokens for authentication, as long as they use different schemes.

May be he could give a bit more detail here.

[NicolasREY69330]

@mvelosop @hbiarge : yes it could be great to have a sample 👍

[hbiarge]

@NicolasREY69330 from my point of view, the best option is the second scenario you describe in your question.

Two IdentityServers (two different authorities), one from the B2B users and the other for the B2C users. It's important to separate different logical users from the authentication perspective.

Two BFF with Ocelot, each one authenticated with the respective IdentityServer.

Micro-services C and D are not a problem, because each one is authenticated only with one IdentityServer.

For Micro-services A and B (should support authentication with Identity Server B2C and B2B) we can register two different JwtBearer authentication handlers (or the IdentityServer version). This will do the trick. This way those Micro-services know the public key for tokens emitted from both IdentityServers so you can use the Authorize attribute without problem. In order to make this work, you should authenticate with both schemes in each request, so you should use the __AuthenticationSchemes__ property in the Authorize attribute or in a default Policy.

For me this is the best approach, because you have the token and all the user information in the Micro-service in order to take authorization decisions.

Hope this helps!

[mvelosop]

Thanks @hbiarge,

I guess getting all details is more like an assignment, but this should be enough to get started!

[NicolasREY69330]

Thanks @mvelosop and @hbiarge, I just wonder if you have any links on using two auth scheme in best practice way within the same application ?

[hbiarge]

@NicolasREY69330 in this repo I have some authorization samples, including one with two active schemes. https://github.com/hbiarge/Authorization-Workshop.

• Schema registration in Test startup: https://github.com/hbiarge/Authorization-Workshop/blob/master/src/Authorization-Workshop/test/Products.Api.IntegrationTests/TestStartup.cs
• Policies definition: https://github.com/hbiarge/Authorization-Workshop/blob/master/src/Authorization-Workshop/src/Products.Api/Authorization/Policies.cs
• Sample controller: https://github.com/hbiarge/Authorization-Workshop/blob/master/src/Authorization-Workshop/src/Products.Api/Controllers/S05SchemasController.cs
• Integration test: https://github.com/hbiarge/Authorization-Workshop/blob/master/src/Authorization-Workshop/test/Products.Api.IntegrationTests/Specs/S05SchemasControllerTests.cs

[NicolasREY69330]

Thank you so much @hbiarge I'll have a check !!

[mvelosop]

Great @hbiarge, thank you so much 😊

Will close this issue now, but feel free to comment, will reopen if needed.