Route based on Client Side Certificates

[3GDXC]

Please consider validation of client side certificates for cluster/routes as a enhanced security/authorisation mechanisms prior to offloading ssl/routing request to target/destination

[Tratcher]

As in validating the client cert as it's received from the client? You should already be able to do that with the existing server APIs, or with the client cert auth provider.

https://microsoft.github.io/reverse-proxy/articles/authn-authz.html https://docs.microsoft.com/en-us/aspnet/core/security/authentication/certauth?view=aspnetcore-3.1

[3GDXC]

@Tratcher thanks for the quick response; I'm not sure if I fully understand how that is achieved with the reverse-proxy.

use case: I have multiple services which require to be secured with client side certificates (different per-service/client) prior to routing the request I'd like the reverse proxy to valid client certificate and/or confirm the certificate-chain as part of the route selection

i.e.
service-1 with client-cert-1 routes to cluster a service-1 with client-cert-2 routes to cluster b

[Tratcher]

Start with this: https://docs.microsoft.com/en-us/aspnet/core/security/authentication/certauth?view=aspnetcore-3.1 You add two two client cert auth handlers, certauth1 and certauth2 with their own config.

Then you add two authorization policies, authpolicy1 or authpolicy2, that require the user be authenticated with certauth1 or certauth2 respectively. Then you specify those auth policy names on your route definitions. https://microsoft.github.io/reverse-proxy/articles/authn-authz.html

[karelz]

Triage: Looks like answered, closing. If there are ore concerns, or we missed anything, feel free to reopen. BTW: It is ASP.NET feature, not YARP feature.

[3GDXC]

@Tratcher @karelz I'm not quite sure I've explained my use case clearly; I wish to validate client certificate at the reverse proxy and have the proxy block or route differently based on the configuration and client certificate detected; for example

I have a load-balanced group for a service where

1. client with no certificate can use endpoint 1 - 4
2. client with certificates 'A' can use endpoints 5-8 (endpoints with more resources)
3. client with certificate 'B' can use endpoints 5-10 (addition resource at busy times)

hope this better describes the use case for routing based on the client certificate

[Tratcher]

Thanks, that description makes more sense. Support for that would have to be wired directly into routing like we're adding for headers: https://github.com/microsoft/reverse-proxy/pull/448. It could be done by us or via the extensibility proposed in https://github.com/microsoft/reverse-proxy/pull/328.

Note optional client certificates are problematic in TLS, you probably need to use a different host name or port for that route anyways. See https://docs.microsoft.com/en-us/aspnet/core/security/authentication/certauth?view=aspnetcore-3.1#optional-client-certificates.

[Tratcher]

Hmm, I guess you could also do this with a custom affinity provider, it might be easier. https://microsoft.github.io/reverse-proxy/articles/session-affinity.html

[karelz]

Triage: We want to wait for more requests and feedback how useful this may be ...

[samsp-msft]

This feels like something that claims should be used for. I don't know if we want to start going to the level of having claims on individual destinations, but the scenario above of changing the destination list based on the cert would be possible as middleware filtering the destination list. I think this gets into the problem of filtering destinations based on metadata attached to them, which becomes a bigger theme.