Your license for Duende IdentityServer only permits 1 number of issuers

[d-manford]

Which version of Duende IdentityServer are you using?

Identity Version 6 (latest version) Starter Edition

Which version of .NET are you using?
N/A

Describe the bug

We have a public app gateway (reverse-proxy) using 1 hostname/FQDN for login attempts (e.g. login.domainname.com) and the private hostname/FQDN on the identity server on the backend (e.g. login.cloutplatform.com). Logins are proxied to the front-end gateway using the public name and terminated there. The gateway then establishes the backend connection to the Identity server using the cloud platform hostname/FQDN.

We receive the below log message after login.

Your license for Duende IdentityServer only permits 1 number of issuers. You have processed requests for 2. The issuers used were: ["https://login.domainname.com/identity","https://login.cloudplatform.net/identity"]. This might be due to your server being accessed via different URLs or a direct IP and/or you have reverse proxy or a gateway involved. This suggests a network infrastructure configuration problem, or you are deliberately hosting multiple URLs and require an upgraded license.

To Reproduce

Steps to reproduce the behavior.

Expected behavior

A clear and concise description of what you expected to happen.

Log output/exception with stacktrace

data

Additional context

We believe we have removed all references to the private/FQDN of our cloud platform and are only now using the public hostname/FQDN on the app gateway. However, we are still concerned that if there is code out there that may present the private URL. As a result, we are concerned we may receive the error again or that our installation may become non-functional. We are hesitant to release into production without assurances that this will not cause any problems. Can you confirm or advise on how to proceed or offer assurance there won't be any issues?

Thank you,

[d-manford]

Hello,
Do we have any updates here? We have a pending deadline for a release and would like to get confirmation on the above.
Thank you

[leastprivilege]

["https://login.domainname.com/identity","https://login.cloudplatform.net/identity"]
We believe we have removed all references to the private/FQDN of our cloud platform and are only now using the public hostname/FQDN

This warning message means that you have indeed clients that use both domain names to access the OIDC provider. Since the hostname has a special meaning in the OIDC protocol, this is not recommended and may lead to further problems down the line.

You can get rid of the warning by setting a static issuer name in the options, but this will not get rid of the root cause.

[d-manford]

Hello,

Thank you for the reply. In the interest of clarity, let me ask a follow up question. We are trying to be precise as we have a pending production deployment and do not want to experience unknown problems afterwards.

Our existing architecture for Identity login is the following:

• Application Gateway/Reverse Proxy server accepts inbound requests for login to Public Endpoint (https:// login.publicdomainname.com).
• TLS Traffic is terminated there. App Gateway/Reverse Proxy server then establishes TLS connection with the Backend Application (Identity App server) with Destination backend URL (https://login.privatecloudplatform.net)
• While the above request is being processed the Request Header for “X-Forwarded-Host” value is rewritten to the variable {var_host} so that the Destination Backend Application receives the same Host Header as the initial public endpoint request.

Do you see anything about this architecture that might cause issues or is not supported under the Duende Server? Are you familiar with other customers doing something similar? We are trying to ensure we have not left anything to chance or in an unsupported configuration for Duende. Can you further advise if this goes against best practice or is or isn’t recommended?

Thank you!

[leastprivilege]

Do you see anything about this architecture that might cause issues or is not supported under the Duende Server?

No - this is pretty idiomatic.

Still something seems to access the login server directly (meaning not using the proxy and thus no forwarded headers) using the internal host name. That's what the log message indicates.

[lorddev]

You can get rid of the warning by setting a static issuer name in the options, but this will not get rid of the root cause.

@leastprivilege Like this?

"IdentityServerOptions": {
   "IssuerUri": "https://www.example.org"
}

I tried this and it didn't work. Is there a special syntax in Startup to get it to read from config?

[brockallen]

You will have to configure the options manually: https://docs.duendesoftware.com/identityserver/v6/reference/options/

[lorddev]

You will have to configure the options manually: https://docs.duendesoftware.com/identityserver/v6/reference/options/

This seems to have solved it, for me at least.

[AndersAbel]

@d-manford Is this issue solved for you too? Can we close it?

[jesslilly]

I am getting the same error message in my logs, but I do not have a reverse proxy set up. The names of the web servers and the Identity Server are the names listed:

2024-01-22 15:29:21.3244|ERROR|Duende.License|Your license for Duende IdentityServer only permits 1 number of issuers. You have processed requests for 3. The issuers used were: https://web02.company.org/, https://account.company.org/, https://web03.company.org/

We have been using Identity Server for many years, and I have not seen this until recently. We did upgrade to v 6 over a year ago. Also we have been porting our applications to use IdentityModel.AspNetCore instead of home-grown code to get a token for API access.

[AndersAbel]

@jesslilly Is your IdentityServer listening on three different hos names? In that case you need a license that permits multiple issuers.

[jesslilly]

No, just one @AndersAbel

[AndersAbel]

@jesslilly The logs indicate that your IdentityServer has processed requests on all three host names.

if that is not intentional, you might want to review your infrastructure level setup to ensure that IdentityServer is only responding to one host name.