Identity Server: Multi Tenancy Support for Model Context Protocol

[whatisthejava]

Hi, we currently have a single issuer and use the acr_values to manage multi tenancy within our environment. we pass it first to the auth endpoint and then to the token endpoint. This has worked well for us, but looking to implement MCP most AI agents do not support anything except basic OIDC so the additional claims whiule possible to pass to the auth token, not one agent is supporting passing them to the token endpoint.

One of our ideas is to extend ID server to have a discovery endpoint per tenant which we could then use for MCP. We are an enterprise customer and it says IDSrv supports multi tenancy but apart from some discussions I cant find any documentation on how to enable this.

Is there documentation that can be shared if i request via the correct person/email

Thanks

[josephdecock]

Hi, thanks for getting in touch.

Using IdentityServer in MCP is something we have our eye on. MCP mandates the use of RFC 8414 for discovery, which is basically the IETF/OAuth version of OpenId Connect discovery. The difference between the two is really just in the path to the endpoint:

OIDC Discovery: https://example.com/optional-subpath/.well-known/openid-configuration
RFC 8414: https://example.com/.well-known/oauth-authorization-server/optional-subpath

The intent of the specs is that the two documents be identical, just at different paths. Note that an optional subpath comes before .well-known in OIDC but as a suffix in 8414. This can be a bit inconvenient, especially with the way that I typically see IdentityServer hosted with path-based issuers. The better news is that you don't have to use paths to distinguish multiple issuers - you can instead use different domains or subdomains per tenant. If you can arrange to have multiple domains' traffic handled by your identity server host, the domain used by the incoming request will determine the issuer.

What our documentation is referring to when we say that multi-tenancy is an enterprise feature is that you can use an unlimited number of issuers out of a single deployment. Multiple issuers can be achieved either through domains or paths.

We're working on an implementation of 8414 that should land in IdentityServer 7.4. In the meantime, since the OIDC and 8414 discovery docs are meant to have the same content, you can add some of your own middleware to route requests for the 8414 path to the existing oidc disco path. If you have a path based tenant structure, then your custom middleware would need to parse that part of the path out of the incoming request and then tell IdentityServer what that path was by setting the PathBase on the request.

[whatisthejava]

Hi thanks for the answer, Im restricted on what i cna do because of the architecture. What I am hoping to do is

host x number of discovery endpoints in the following pattern

example.com/{tenant1}/.well-known/openid-configuration
(This would contain example.com/{tenant1}/connect/token ...
example.com/{tenant2}/.well-known/openid-configuration
(This would contain example.com/{tenant2}/connect/token ...
example.com/{tenant3}/.well-known/openid-configuration
(This would contain example.com/{tenant3}/connect/token ...

I can get the path manipulation to work to only allow valid tenants but what I cant do is work out how to have Identity generate the different discovery endpoints

Is this supported ?
or does MT always return the same discovery configuration regardless of hosted path ?

[josephdecock]

Yeah, you can absolutely do this.

IdentityServer infers the name of the issuer based on the incoming request's PathBase. That's used to set the URLs in discovery, the issuer claim in tokens, etc.

You do have to arrange your aspnet pipeline so that requests with a path are understood by IdentityServer: it's going to look at the request and match protocol paths from the root and, again, use whatever is in the PathBase to set the issuer etc.

This is exactly how the aspnet pipeline works when you call Map or UsePathBaseMiddleware in the pipeline - those both strip off the configured path and set the requests PathBase based on their configuration.

Now that might be inconvenient if you have many tenants, because the built in constructs work with a single path at a time. You might want to add some custom middleware that will match multiple valid tenant paths. I'm not aware of a built in middleware that does that, but it would be straightforward to write something custom.

There are also some third party open source projects related to multitenancy in aspnet more generally, notably finbuckle. While we don't support third party projects, I have seen it used successfully with IdentityServer in the past and you may want to take a look at it.

Also, this behavior can be overridden by configuring a static issuer in IdentityServer's options. You'll want to be sure not to set that.