When deploying behind a reverse proxy, can a service avoid using the issued URLS?

[a-vishar]

I'm deploying IS4 along with a client application in Kubernetes. As with most K8s deployments, the internal services communicate via http, and internal service names.

When the client application calls the authority (http://identityserver.publicdomain.com/identity/.well-known/openid-configuration), the first call to the http succeeds thanks to a URL rewrite rule which maps "identityserver.publicdomain.com" to "identityserver-internal-service". When the client application retrieves the config, it appears to make subsequent calls to the https endpoint defined .well-known/openid-configuration. Is there some way to prevent the local service using the public URLs defined in .well-known/openid-configuration?

Relevant Client Setup:
.AddOpenIdConnect(OpenIdConnectDefaults.AuthenticationScheme, options => { options.Authority = "http://identityserver.publicdomain.com/identity"; options.RequireHttpsMetadata = false; });

Relevant Server Setup:
services.AddIdentityServer (options => { options.PublicOrigin = "https://identityserver.publicdomain.com"; options.IssuerUri = "https://identityserver.publicdomain.com"; })

Is there support for the user to visit the https endpoint "https://identityserver.publicdomain.com" and the internal services to visit the http endpoint "http://identityserver-internal-service"?

[leastprivilege]

As with most K8s deployments

This has been discussed many times already. This is not how OpenID Connect works. The DNS name is the identity of the OIDC provider.

[a-vishar]

@leastprivilege - I read (I thought) all of the "issues" relating to this subject and was unable to find the information I was looking for, that is likely my fault, please feel free to link me to a relevant issue and I will continue reading :)

It seems as though you are saying that the client application must use the publicly accessible URL that the user will ultimately use, is that correct?

[leastprivilege]

yes - all parties must use the same DNS name.

[a-vishar]

Thank you for the clarification!

[a-vishar]

@leastprivilege - Thinking about this a little more, the URL rewrite works the same as the DNS being the same. The primary issue is that I would like the internal service to use HTTP, and public users to use HTTPS, is this a supported scenario?

[leastprivilege]

that would still result in a different issuer URI.

Have you tried setting the issuer name manually?

[a-vishar]

I did try setting it manually.

When Authority=https & IssuerUri=http, the client application attempts to get openid-configuration via https.

When Authority=http & IssuerUri=https, the user is redirected to the authorize endpoint via http.

[brockallen]

All set, can we close?

[a-vishar]

If you're closing saying not supported, sure :) No resolution was reached, which I'm happy enough with, just want to ensure we're documenting it properly for others who face the same issue!

[Farzad-Jalali]

I got the same problem
@a-vishar , @brockallen - is there any working solution for it?

[leastprivilege]

So this is still open. Was there a conclusion? Besides you have to use a correct DNS setup?

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.