Can you configure pinniped (on VKS) with F5 OIDC?

[mickeybyte]

Hi, we have a vSphere Kubernetes Supervisor (vSphere 8.0.3) on which we are trying to set up the use of an external identity provider.
We have an F5 BIG-IP environment running, where we created an OIDC server and configured the Supervisor as an OIDC Client. We entered the server, client ID, client secret, and certificate in the configuration page of the external identity provider page in vCenter.
The pinniped gets configured, but the oidcidentityprovider goes into ERROR with the following message:

failed to perform OIDC discovery against "https://auth-adm.lab.domain.com/f5-oauth2/v1/jwks":  oidc: failed to decode provider discovery object: expected Content-Type = application/json, got "text/html; charset=utf-8": invalid character '<' looking for beginning of value  

We tried running curl -ILkv https://auth-adm.lab.domain.com/f5-oauth2/v1/jwks from several places, including the supervisor nodes, and we don't see any redirects happening, and it gives us an application/json content type back, which seems to be correct
We tried running the curl command from inside the Pinniped pod but that was impossible because there is no shell or curl available in the pods. We were able to run it inside the VMware cert-manager pod on the supervisor, and we got the same, correct result as from anywhere else (correct json response):

root@supervisor-node [ ~ ]# kubectl exec -ti cert-manager-bccc6dc66-qfz6k -n vmware-system-cert-manager -- curl -vk https://auth-adm.lab.domain.com/f5-oauth2/v1/jwks
* Host auth-adm.lab.domain.com:443 was resolved.
* IPv6: (none)
* IPv4: 10.12.13.11
*   Trying 10.12.13.11:443...
* Connected to auth-adm.lab.srb.europa.eu (10.12.13.11) port 443
* ALPN: curl offers http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / prime256v1 / rsaEncryption
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: C=Country; O=Org; OU=it; CN=auth-adm.lab.domain.com
*  start date: Aug 22 08:53:35 2025 GMT
*  expire date: Aug 21 08:53:35 2030 GMT
*  issuer: DC=com; DC=domain; CN=SUB-CA
*  SSL certificate verify result: self-signed certificate in certificate chain (19), continuing anyway.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
> GET /f5-oauth2/v1/jwks HTTP/1.1
> Host: auth-adm.lab.domain.com
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Content-Length: 577
< Content-Type: application/json; charset=UTF-8
< Cache-Control: no-store
< Pragma: no-cache
< Connection: Close
<
{
  "keys":[
  {
    "kty":"RSA",
    "use":"sig",
    "alg":"RS256",
    "kid":"jwk_default",
    "n":"***redacted***",
    "e":"***redacted***",
    "x5t":"***redacted***",
    "x5t#S256":"***redacted***"
  }
  ]
}
* Closing connection

We also tried setting up Okta as an external identity provider, and that one works fine. It seems to be an issue related to F5.

Has anyone been able to configure an F5 as an external identity provider in VKS? Or does anyone know how we can further troubleshoot what goes wrong?

Many thanks!
Michiel.

[cfryanr]

You are using the wrong issuer URL. The URL that you used is the issuer's JWKS endpoint, not the issuer's URL. For an OIDC issuer URL, you should be able to append /.well-known/openid-configuration to the end of the URL and then curl that. For example, https://accounts.google.com is an OIDC issuer, and you can curl https://accounts.google.com/.well-known/openid-configuration to get its discovery response.

[mickeybyte]

Correct! In the meantime we figured it out with the networking team. The URL was incorrectly setup on the F5 side indeed and they made the necessary adjustments. Everything is working fine now.