Multi-tenancy: Tenant-specific audiences, issuers and discovery-endpoints #46
Replies: 3 comments
-
|
While continuing to search for an answer to question 3, I stumbled across DiscoveryResponseGenerator and IDiscoveryResponseGenerator. With a custom implementation of However, I can't find anything about this extension point in the official documentation. Since one of our project-requirements is to only use public APIs, I am unsure. How can I recognize which interfaces/types are public interfaces of the product? |
Beta Was this translation helpful? Give feedback.
-
|
I think that all of these issues have a common solution: Use the Asp.Net Core forwarded headers middleware to make the IdentityServer processing aware of the original request URL. The easiest way to validate that the forwarded headers are correctly setup is to check the discovery document that the issuer and endpoint URLs use the externally visible host name. Please see https://docs.duendesoftware.com/identityserver/v7/deployment/proxies/ for more information and a link to Microsoft's docs. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you @AndersAbel for the link. The section in the manual seems to describe the solution to my problem. I would like to leave this request open until I have validated the proposed solution in the next few days. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
IdentityServer version
7
.NET version
9
Description
Context: We want to modernize our authorization infrastructure and want to use Duende IdentityServer and its multiple-issuers-on-a-single-deployment-feature.
Customers of our multi-tenancy-capable product access it via individual domains (tenant.example.com). Each customer also gets a "virtual" authorization server, accessible via tenant.auth.example.com. However, all virtual authorization server will map to a single IdentityServer instance.
Due to our infrastructure, the initially used hostname is transferred via the forwarded-header to downstream-systems (like the IdentityServer).
Audiences in our case correspond to the complete URL, for example https://tenant.example.com/myapi.
This context raises three questions for me that I could not find answers to in the documentation and the support forums:
Since each tenant is accessible under an individual host (from the client's perspective), the clients will request tokens for tenant-specific audiences. Is the ICustomTokenRequestValidator the designated extension point for this or is there a simpler approach?
Each tenant will have its own issuer. This information cannot be taken from the host information of the HTTP request but must be taken from the forwarded header. Is the ICustomTokenRequestValidator the designated extension point for this or is there a simpler approach?
There is a similar challenge with the discovery endpoint as in question 2. The host cannot be used as information for the creation. A header must be used. What is the best extension point to accomplish this?
Reproduction steps
No response
Expected behavior
No response
Logs
No response
Additional context
No response
Beta Was this translation helpful? Give feedback.
All reactions