Allow for OIDC Issuer URL to mismatch the one served by its metadata

[faust64]

Current Behavior

Hello,

As we're investigating Dependency Track, I did setup a test instance.
We are running in OpenShift, which has its own users/groups, while integrated with our corporate OIDC provider. Deploying applications to OpenShift, I need to integrate with its users.
I managed to get something working, using Dex, which implements OIDC, while integrating with OpenShift.

Works great, if I configure my OIDC_ISSUER / alpine.oidc.issuer pointing to the public FQDN exposing my Dex instance in OpenShift.

However, I know I could get this to work, with other applications (namely ArgoCD) ... Configuring application to query my Dex instance, connecting to the Service, in OpenShift SDN (without requiring the connections to leave/re-enter my cluster).
Yet when I attempted to configure Dependency Track components querying my internal Service name, during login, I would see something like this in apiserver logs:

ERROR [OidcConfigurationResolver] Failed to fetch OIDC configuration from issuer "https://my-internal-endpoint.svc:5556"
com.nimbusds.oauth2.sdk.GeneralException: The returned issuer doesn't match the expected: https://my-external-endpoint

Reading about #2574 (comment)
I understand that Dependency Track does require configuration issuer URL to match the one served from metadata.
I'm not sure this has to be mandatory.
Surely, in OpenShift/Kubernetes context, when two pods are running in the same namespaces, it's better not to have their communications exiting SDN to re-enter.

It works great when I open those flows, allowing Dependency Track to connect towards the loadbalancers serving Ingresses on behalf of my namespace. However those loadbalancers grant access to several namespaces just like mine, in my tenant.
As we're considering integrating Dependency Track to our own CI, it would make it an easier sale, not having to request that flow.
Still we're very please with what we see. Great work!

Proposed Behavior

When API server connects to OIDC issuer, it could do so through some internal domain name.

One way may be to translate FQDN/port from discovered metadata, trusting instead the OIDC_ISSUER configuration we know of.
Or we could provide with additional internal endpoints -- in addition to the main issuer URL, you probably need to know about the token_endpoint & userinfo_endpoint? Anything else?

End-user will still query public endpoints as it connects to Dex/OIDC endpoints.
Only Dependency Track components should prefer private connectivity when possible/available.

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested

[nscuro]

The Quarkus framework allows users to explicitly configure the expected issuer:

We could follow this approach. So in your case, you could configure it to be either https://my-internal-endpoint.svc:5556 or any to resolve the current limitation. WDYT?

[faust64]

I guess so? But that's only the issuer
Wouldn't you need to know of private endpoints such as userinfo or token?

The user connecting from outside SDN should be redirected to the public authorization endpoint, as served by /.well-known/openid-configuration. Which would be valid for anything querying Dex through our Ingresses.
Communications in between Pods in same namespace should rather use private endpoints.

Maybe quarkus.oidc.token-path and quarkus.oidc.user-info-path would be relevant as well? You're not using introspection, device authorization, ... Or anything else, right?

Trying out in doubt, setting QUARKUS_OIDC_TOKEN_ISSUER on my side, still no luck, same

2025-02-02 15:27:02,967 ERROR [OidcConfigurationResolver] Failed to fetch OIDC configuration from issuer https://dependency-track-dex.my-ci.svc:5556 [requestId=8142cf91-9859-448a-b9bc-45d32d273966]
com.nimbusds.oauth2.sdk.GeneralException: The returned issuer doesn't match the expected: https://dependency-track-dex.example.com
        at alpine.server.auth.OidcConfigurationResolver.resolve(OidcConfigurationResolver.java:108)

But I guess those env vars are not usable in this context?