Using a single oathkeeper in front of multiple Hydra deployments (multi-tentant)

ORY Oathkeeper
#1

Hi,

We’re trying to figure out a proper deployment model for Hydra in a multi-tent scenario.

We’ve reached the conclusion that in order to have true multi-tenancy support on the oauth/oidc side (with Hydra), we need to deploy a single Hydra instance per tenant and distribute the oauth client registrations between these Hydra instances (possibly using https://github.com/ory/hydra-maester).

We’re now looking into how oathkeeper fits into this and it seems like all the urls you configure in oathkeeper, for example the token and instrospection urls for the oauth2_introspection authenticator must be absolute, which would mean (afaics) that we’d have to run a oathkeeper per tenant as well. Am I understanding that correctly?

If so, would you consider a PR that would allow relative urls for such config and logic to prepend the domain of the current requestUrl to it?

And what about a PR to force the iss claim in a JWT token to match the current requestUrl, as adding the urls of each tenant in the trusted_issuers config is not really scalable/manageable

TIA,

Paul

#2

With recent releases of oathkeeper, you can configure every “handler” (e.g. oauth2_introspection) globally and per route. This means you could have different introspection endpoints per route.

Hope this helps!

#3

So you’re suggesting that instead of using wildcard match urls (https://<.*>.example/com/…, to have one route definition shared by all tenants for a specific route on our api), to create a route per tenant for each specific route in our api?

Not sure if that is scalable… Say our api needs approx. 100 individual routes. With a 1000 tenants, that would already be 100k routes configured in oathkeeper. 10k tenants: 1mln routes in oathkeeper.

Does oathkeeper scale like that?

#4

You can always shard this when you hit scalability issues, it’s just a practical solution to your problem. I’m assuming you don’t have to deal with 10.000 tenants yet.

#5

While we’re not at 10k tenants yet, we’re growing fast :slight_smile:

I guess we could setup a sharding infrastructure, but I wonder if there aren’t other options

I now realize that the approach I suggested before won’t work, as the introspection url is an internal url, while the (api) request that oathkeeper is handling is an external request.

So, I was wondering if maybe oathkeeper is already sending the host/x-forwarded-host header of the original request with call to the introspection endpoint, but I don’t think it is.

Found some (related/sorta) similar cases (https://github.com/ory/oathkeeper/issues/95, https://github.com/ory/oathkeeper/issues/249 for example) and this MR from a few days ago:
https://github.com/ory/oathkeeper/pull/302/commits/a042a1d3fda95af14a894ea9642c3abd0d12ee7c

I was wondering if you’d accept a PR that adds config options that makes oathkeeper forward certain headers from the inflight (api) request to the introspection request

#6

Yeah, I think that’s definitely something that would be accepted. Maybe something like forward_host or something similar.

#7

Cool, will create a case on the oathkeeper repo for further discussion and start working on a PR