How can I make IS4 work when deployed to a local K8s cluster alongside another service?

0
votes

I have IS4 deployed to a K8s cluster. On the same cluster I have a WebApp which the User is calling in to.

User (Goes to) -> WebApp (Redirects when not authed)-> IS4.

The issue I'm having is that when I set options.Authority on the WebApp to the external FQDN, then the WebApp fails to find the discovery document. When I set options.Authority to the internal service name, then the User is redirected to an authorize endpoint they cannot access.

I have tried configuring all of these in IS4: Authority, PublicOrigin & IssuerUri.

While AKS gives me the ability to resolve the external DNS and through some sort of magic it routes correctly, I'm unable to develop locally due to this resolution issue.

The options I can think of are:

  1. Update K8s to force pods to do a "full" DNS lookup.
  2. Update IS4 to have the servers communicate using one set of URLs and the users communicate using another.

I cannot find much on either of these subjects, so advice would be welcome.

Ideally, I'd like the K8s services to communicate using the internal service names, and when a user needs to authenticate, they are directed to the publicly available address.

1
nginxkubernetesidentityserver4
PublicOrigin should do what you want. When you set Authority to the external FQDN what error are you getting when accessing the discovery document? – Richard
@Richard - The issue using the FQDN is that when Service A cannot access IS4 via the FQDN. It resolves to 127.0.0.1 when I use the FQDN, which then doesn't route to the correct service. – Stevey

1 Answers

1
votes

It turns out that having an internal service name isn't allowed ("all parties must use the same DNS name"): https://github.com/IdentityServer/IdentityServer4/issues/3568#event-2588006001