Host OIDC configuration for non-default issuer

[Shurgentum]

What feature do you want to see added?

When a jenkins endpoint is publicly unavailable, it creates a need to host the jwks and openid-configuration files separately. Unfortunately, this approach is difficult/impossible to automate and avoid manual file uploads.

There is a more practical approach - so that with a non-default Issuer, you can configure a proxy or Load Balancer with a different domain name and filter traffic using the url path.

Proposal

Add a checkbox when creating OpenID Credentials, upon activation of which Jenkins will host files on its own, even with non-default Issuer.

Upstream changes

No response

[dee-kryvenko]

It's always been a common understanding that Jenkins typically has two endpoints, one main UI for the users and another public but restricted to things like /github-webhook, /buildStatus and so on. Historically all plugins, from github, bitbucket, build status etc etc - all supported this concept. Even official helm chart has two ingress for that reason. This plugin should really stick to that common wisdom...

[tedandrew]

Hi everyone,

I've tried to extend the plugin to serve OIDC configuration files locally from Jenkins even for non-default issuers. I discovered that the current design (which only serves OIDC config for the default issuer) appears to be intentionally structured this way to prevent potential conflicts.

The challenge arises when multiple credentials exist within the same Jenkins instance:

• Credentials using the default issuer (e.g., https://jenkins.your-domain.com)
• Credentials using non-default issuers (e.g., https://ext-jenkins.your-domain.com)

Since both would need to be served from the same /oidc path, this creates a routing conflict.

@jglick , as a core contributor to this plugin, could you provide guidance on the best approach to implement this functionality while maintaining backwards compatibility? A potential solution I see is to implement path-based routing for different issuers.

Thank you!

Edit: In my use case Jenkins is behind an ALB, I'm thinking maybe I can access the original host header from the request. But this might not be reliable for everyone since headers might differ between proxies.

[jglick]

Well the simplest would be

diff --git src/main/java/io/jenkins/plugins/oidc_provider/Keys.java src/main/java/io/jenkins/plugins/oidc_provider/Keys.java
index 68125cb..16cf0ff 100644
--- src/main/java/io/jenkins/plugins/oidc_provider/Keys.java
+++ src/main/java/io/jenkins/plugins/oidc_provider/Keys.java
@@ -69,10 +69,6 @@ import org.kohsuke.stapler.StaplerRequest;
                     // compare https://github.com/jenkinsci/blueocean-plugin/blob/1f92e1624287e7588fc89aa5ce4e4147dd00f3d7/blueocean-jwt/src/main/java/io/jenkins/blueocean/auth/jwt/SigningPublicKey.java#L45-L52
                     JSONArray keys = new JSONArray();
                     for (IdTokenCredentials creds : i.credentials()) {
-                        if (creds.getIssuer() != null) {
-                            LOGGER.fine(() -> "declining to serve key for " + creds.getId() + " since it would be served from " + creds.getIssuer());
-                            continue;
-                        }
                         keys.element(key(creds));
                     }
                     return new JSONObject().accumulate("keys", keys);
@@ -120,8 +116,8 @@ import org.kohsuke.stapler.StaplerRequest;
                         LOGGER.warning(() -> i + " was expected to have URI " + uri);
                         return null;
                     }
-                    if (i.credentials().stream().noneMatch(c -> c.getIssuer() == null)) {
-                        LOGGER.fine(() -> "found " + i + " but has no credentials with default issuer; not advertising existence of a folder");
+                    if (i.credentials().stream().noneMatch(c -> true)) {
+                        LOGGER.fine(() -> "found " + i + " but has no credentials; not advertising existence of a folder");
                         return null;
                     }
                     LOGGER.fine(() -> "found " + i);

plus adjusting

oidc-provider-plugin/src/test/java/io/jenkins/plugins/oidc_provider/KeysTest.java

Lines 80 to 86 in 251184c

	assertEquals(1, keys.size());
	JSONObject key = keys.getJSONObject(0);
	assertEquals("global", key.getString("kid"));
	assertEquals("RSA", key.getString("kty"));
	assertEquals("AQAB", key.getString("e"));
	assertEquals("RS256", key.getString("alg"));
	assertEquals("sig", key.getString("use"));

and

oidc-provider-plugin/src/main/resources/io/jenkins/plugins/oidc_provider/IdTokenCredentials/help-issuer.html

Lines 3 to 4 in 251184c

	If specified, you must be prepared to serve <code>.well-known/openid-configuration</code> and <code>jwks</code>
	from that location as <code>application/json</code> documents.

to match. I am trying to remember from #8 if there is any security risk to doing that but I cannot think of any.

In general you may still need to have a script to copy two JSON files to an external static HTTP server, in case the Jenkins controller is physically isolated inside some environment with no inbound Internet access. This change would be helpful for that case since you could use curl / wget inside the VPN to obtain the public key from Jenkins as a more scriptable version of

oidc-provider-plugin/src/main/java/io/jenkins/plugins/oidc_provider/IdTokenCredentials.java

Lines 285 to 291 in 251184c

	"Serve <code>" + Util.xmlEscape(issuer) + Keys.WELL_KNOWN_OPENID_CONFIGURATION +
	"</code> with <a href=\"" + base + "/wellKnownOpenidConfiguration?issuer=" + Util.escape(issuer) +
	"\" target=\"_blank\" rel=\"noopener noreferrer\">this content</a> and <code>" +
	Util.xmlEscape(issuer) + Keys.JWKS + "</code> with <a href=\"" +
	base + "/jwks?id=" + Util.escape(id) + "&issuer=" + Util.escape(issuer) +
	"\" target=\"_blank\" rel=\"noopener noreferrer\">this content</a> (both as <code>application/json</code>)." +
	"<br>Note that the JWKS document will need to be updated if you resave these credentials.");

as well as for the proposed scenario where I guess you have one load balancer exposing all paths inside the VPN and another load balancer exposing only selected path prefixes externally.

[saper]

The only big difference in the deployment of the external keys is that the access to

https://jenkins/oidc/jwks

is unauthenticated and the access to

https://jenkins/manage/descriptorByName.io.jenkins.plugins.oidc_provider.IdTokenStringCredeentials/jwks?id=credential_id&issuer=https://issuer

required authentication.

The internal issuer's metadata document at https://jenkins/.well-known/openid-configuration clearly specifies the issuer as the local machine. If we publish the whole bunch together, not all jwks out there will be working for that particular issuer which creates inconsistency between the metadata and the jwk set.

This alone, should, hopefully, prevent that the tokens issued for the external OIDC issuer to be successfully verified by something that fetches https://jenkins/.well-known/openid-configuration only

But there are JWT validators that separately ask you to give a trusted jwk set. If something gets misconfigured somewhere this can lead to a situation where a token issued for the external OIDC only will be trusted by something that is supposed to trust internal publisher only, just because a jwkset containing everything known to this Jenkins instance will be exported.

This is important only for those who issue a disjoint set of credentials for https://jenkins and https://external.oidc.something and do not want to mix them up just for the deployment ease....

What we could do for the deployment ease is to make sure that the manage/descriptorByName.io.jenkins.plugins.oidc_provider.IdTokenStringCredeentials/jwks links remain stable.