Support for Client certificates for downstream routes

[millusdk]

New Feature

Extend the definition of downstream routs to support specifying a client certificate that is the used to call the service.

Motivation for New Feature

We are looking at using Ocelot as the API gateway for a new project. The problem is that the downstream services require that the usage of client certificates to authenticate (they contain PII). This feature would enable this setup.

[raman-m]

Hi Emil!
Thanks for your interest in Ocelot!

Hire me at Netcompany and I will help you! 😉

[raman-m]

@millusdk commented on Sep 12

New Feature

Extend the definition of downstream routs to support specifying a client certificate that is the used to call the service.

Truly speaking, I cannot understand, what feature are you requesting for?
Did you mean https certificates (HTTP Secure)?
There are thousands of user scenarios to do that. It depends on exact hosting environment you use for downstream services.
Could you describe your hosting environment please?

And,
What protocol do you use to deploy your downstream services and define Ocelot routes: HTTPS RESTful, WebSockets, SignalR, gRPC?

[millusdk]

@raman-m commented on Sep 14

Hi raman-m,

I may not have been clear enough in my description, my bad.
We have a bunch of downstream services that require callers present a client certificate for TLS authentication.
The services are all RESTful.

I have tried to implement it in https://github.com/millusdk/Ocelot, and I am more than willing to submit a PR for it against Ocelot, as we would prefer to base the gateway in our clients solution on the officially released version of Ocelot rather than try to maintain a fork with it added, however I will only do so if there is interest from the maintainers of Ocelot, as I don't want to put an unwanted burden on you, and I can't guarantee that I will have time to maintain the addition in the long term. I am of course willing to do the work that is needed for you to accept a potential PR, such that the quality of the added code is up to the usual standard and style of Ocelot.

Best regards,
Emil

[raman-m]

@millusdk commented on Sep 14:

We have a bunch of downstream services that require callers present a client certificate for TLS authentication. The services are all RESTful.

Great! We are discussing the case of https scheme.
I'm curious on your future PR. I welcome any PRs for well-discussed issues.
But I still don't understand your problem with certificates.
Ocelot is not responsible for HTTPS certificates because certificate is validated by built-in .NET class which is HttpClient.

We need to clear up the user case...
Are we discussing self-signed SSL certificates or hosting provider certificates?

For hosting provider certificates if it is valid, the HttpClient class validates it without problem.
For self-signed certificates you have to deploy the certificate into hosting environment for each downstream web servers!!!

For example, HttpClient class generates exception if self-signed certificate public key is not installed at Ocelot machine, and/or this certificate private key is not installed on downstream server.
To fix this problem Ocelot has special route property: DangerousAcceptAnyServerCertificateValidator
Please, apply this property for each route in case of having self-signed SSL certificate!
And let me know your testing results plz!

---

For WebSockets protocol (ws and wss scheme) we have open PR #1377

• #1375 #1237 #925 #920 Fix DownstreamRoute DangerousAcceptAnyServerCertificateValidator #1377

[millusdk]

@raman-m commented on Sep 15, 11:20 AM

Yep we are talking about the https scheme.

The problem is not the downstream services providing a certificate to Ocelot, all the downstream services use normal https certificates signed by a public CA, and as such they will be accepted by Ocelot without any issues.

The situation we would like to solve is enabling Ocelot to present a certificate on its own as part of the TLS handshake, thus providing Mutual authentication.

[raman-m]

@millusdk commented on Sep 15, 11:40 AM:

The problem is not the downstream services providing a certificate to Ocelot, all the downstream services use normal https certificates signed by a public CA, and as such they will be accepted by Ocelot without any issues.

Perfect! It seems there is no bug/issue at all. It will be feature request...

---

The situation we would like to solve is enabling Ocelot to present a certificate on its own as part of the TLS handshake, thus providing Mutual authentication.

It is a risky way... It will be custom protocol implementation and incorporation to Ocelot core.
Ocelot team didn't create such milestones. To be fair, we have a lot of other work with well-known protocols like WebSockets, SignalR, gRPC... We have the tons of open issues for standard protocols like http and https (RESTful).

Ocelot is not responsible for TLS handshake of HTTPS, it is the function of HttpClient which provides SSL authentication.
Such kind of breaking protocols to get full control on TCP/UDP connection authentication is outside of API gateway goals.
Ocelot is request content routing tool, not proxying/networking tool which controls everything for client's connection.

I still wonder, why do you want to embed custom protocols with custom authentication to Ocelot core? What is a benefit?
Cannot you just override authentication middleware?

Could you share links to networking & gateway products on the market which already have similar features please?
Traefik, Nginx ???

Anyway, you need to write full description please.
Take a time, rethink, and write description please!

[millusdk]

Hi raman-m,

Using client certificates to do mutual authentication between systems is very prevalent in Denmark, so much that we have a central CA that is able to issue client certificates specifically for this.

Most (all?) web servers are able to accept/require that the client presents a certificate as part of the TLS handshake.
You say that this is a function of the HttpClient, and that is correct, for .NET it is possible to specify these on the HttpClientHandler used by the HttpClient. The HttpClient being used by Ocelot is created by Ocelot itself in the HttpClientBuilder class.

I have made an example implementation of this that can be seen in HttpClientBuilder#L82 or HttpClientBuilder#L113 in my fork of the Ocelot code.

I can see that Nginx is able to use client certificates to authenticate itself against the services that it proxies, as can be seen here Securing HTTP Traffic to Upstream Servers, and it is also supported in Yarp Configuring the http client

Best regards,
Emil

[raman-m]

@millusdk commented on Sep 15, 12:38 PM:

Using client certificates to do mutual authentication between systems is very prevalent in Denmark, so much that we have a central CA that is able to issue client certificates specifically for this.

🆗 It seems I understand your feature request now... Do you believe Ocelot cannot be legally used on Danish market because of laws? Wow! LoL! 🤣
Sorry, cookies containers are forbidden or another things? As far as I know EU regulates IT security across all territory of EU countries aka GDPR regulation.

Anyway, once again, Hire me at Netcompany, and we will do a lot of interesting features. You can be a referrer.
Share my profiles to company HR plz! 😉

---

Most (all?) web servers are able to accept/require that the client presents a certificate as part of the TLS handshake.
You say that this is a function of the HttpClient, and that is correct, for .NET it is possible to specify these on the HttpClientHandler used by the HttpClient. The HttpClient being used by Ocelot is created by Ocelot itself in the HttpClientBuilder class.

Great! Yeah, Ocelot has no this feature now. Also, I am not expert in TLS-connections, but definitely should get more knowledges.
It will be excellent feature if delivered to Ocelot code base!

---

I have made an example implementation of this that can be seen in HttpClientBuilder#L82 or HttpClientBuilder#L113 in my fork of the Ocelot code.

Are you going to create PR(s) in coming future? Without a PR I cannot see changes and review the solution and/or contribute with you together.

---

I can see that Nginx is able to use client certificates to authenticate itself against the services that it proxies, as can be seen here Securing HTTP Traffic to Upstream Servers, and it is also supported in Yarp Configuring the http client

Agreed! Other products have this feature. Yeap, now it is time to implement it in Ocelot.

---

it is also supported in Yarp → Configuring the http client

My heart is broken now! 💔 😢 😭
Happy Friday! 😞

[hooyao]

🆗 It seems I understand your feature request now... Do you believe Ocelot cannot be legally used on Danish market because of laws? Wow! LoL! 🤣
Sorry, cookies containers are forbidden or another things? As far as I know EU regulates IT security across all territory of EU countries aka GDPR regulation.

I'm from Microsoft and exploring a reliable api gateway built upon dotnet core. I need to implement authentication with Microsoft proprietary libraries. MTLS support is the must-have feature for us. So, I guess I have to go back to implement everything on yarp.

[raman-m]

@hooyao commented on Aug 20, 2024

Dear Hu,
I value the visits and evaluations of our repository by Microsoft engineers. At present, I am unsure if any application developed with the Ocelot package is contemplating a migration to a different gateway product.

Would you be able to help us by contributing to the repository through the submission of a PR?

---

I need to implement authentication with Microsoft proprietary libraries.

What libs are you talking about?