In terms of very quick fixes, I would use a HTTP transformation rule (in Lua on ISVA 10.0.4) to replace the jwks endpoint response on the /sps/jwks endpoint with kids that you just hardcode for each of the known keys that you are dealing with.
If you need help to get started with such a rule, I'm happy to oblige, but it would be early next week before I could get engaged.
If you want to do something immediately, here's a sample Lua HTTP transformation rule that replaces entire content for a request - tweak as you see fit.
--[[
A simple transformation that acts as JWKS endpoint
Activated in Reverse Proxy config with:
================
[http-transformations]
test_jwks = jwks.lua
[http-transformations:test_jwks]
request-match = request:GET /path/to/jwks *
=============
--]]
HTTPResponse.setHeader("content-type", "application/json")
HTTPResponse.setStatusCode(200)
HTTPResponse.setStatusMsg("OK")
HTTPResponse.setBody([[ {
"keys": [
{
"kty": "EC",
"kid": "OR5xHLDjTbwxAtPAm3XtbCH-rnB-YKecLyzudZrdUm0",
"use": "sig",
"alg": "ES256",
"x": "XGyC1rR-KXGnjrvo3ZEOu9zsuQIBnms390M3TFdA2fA",
"y": "UzBoxWLr18EeVSWLI178SKug139tDr5vmRMhl26h4HI",
"crv": "P-256",
"x5c": [
"MIIDVTCCAT2gAwIBAgIJAKiWRVc805iEMA0GCSqGSIb3DQEBCwUAMDExCzAJBgNVBAYTAlVTMQ0wCwYDVQQKDAROSVNUMRMwEQYDVQQDDApVSUNDUm9vdENBMB4XDTE5MDgwNzIwMjgwM1oXDTQ2MTIyMjIwMjgwM1owXDELMAkGA1UEBhMCVVMxDTALBgNVBAoMBE5JU1QxIjAgBgNVBAsMGUF1dGhlbnRpY2F0b3IgQXR0ZXN0YXRpb24xGjAYBgNVBAMMEVVJQ0NQQUNLRUQtU0lHTkVSMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEXGyC1rR+KXGnjrvo3ZEOu9zsuQIBnms390M3TFdA2fBTMGjFYuvXwR5VJYsjXvxIq6DXf20Ovm+ZEyGXbqHgcqMQMA4wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAgEAtsJl2cVtuRJqwm0SXhP2vGU3An79GxT1appa9JKLWz7iv5zOVWowKvbEnB6sqjNPZ1p65yEi5UmRNnkE6m6IFSRijz5eeWOHQ0ceQN4BhH9veE4Xe3WiOaahTTJX+hqj+5ByMhgw0dZ6+1iEu20BE0zKAA+VSrpA5O+LPOBDNjCfVzLI566ykNqe2mShm+UGNDYkTxVJmFXY9qyy/zLazynroE6qnIt03UutzifAnNNnBKqk9gK9C6cosDHeyvRGy9um1P21EC85yEZvN8wngzNmc8TJwnkXYHP4METHbjR9bmQP60e19a7so9sz7P5MhkFJ/JOURkbWh6qmzIGQhoNpGw6OQnAxHvkPiw9HuDEfjzIFX1LQi74uMIEG7juCIt2u56dXG7T0NM8MfVlupDJzi4AnwI+NuONrKtC5iK6HHSrRxCQ8QiPTemlymPhC/XMJW70PqDiH7cEmCbsDKg9cTN8mWCNNyb1/WkcfrP2zq+jm1Lp8Viam5kHsd66X9VP/44Aj5G6TGJU7ZitBB/hHqz0jznuZU+fRuGf2taQdCP/DXps/VngXrcvs4sRS3aid0KO5eLkUP8e11r909DMTvV/CsqghqXpS13oUbTs8cD12y93EftSbw6OKR30xcV1PScCOY/CSnCuSQFlgrXW1OotzmWQUKKKUB9Egzb8="
],
"x5t": "WybMktKyOZqrEBOqWSECYn0fd5g",
"x5t#S256": "OR5xHLDjTbwxAtPAm3XtbCH-rnB-YKecLyzudZrdUm0"
}
]
} ]])
Control.responseGenerated(true)
------------------------------
Shane Weeden
IBM
------------------------------
Original Message:
Sent: Thu August 04, 2022 06:18 AM
From: André Leruitte
Subject: JWT KID is different between the STS transfo and the JWKS endpoint
I have made additional tests on non-upgraded ISVA appliances that show this is indeed a bug introduced by one of the latest firmwares.
v10.0.1 does not behave as I described above : in v10.0.1 the KID inside the JWT is the same that the one exposed by the /sps/jwks endpoint.
A case has been opened, but I'm afraid it will take weeks/months for L3 to supply a working fix. If anyone can think of a workaround in the meantime, it would save us.
------------------------------
André Leruitte
Original Message:
Sent: Thu August 04, 2022 05:35 AM
From: André Leruitte
Subject: JWT KID is different between the STS transfo and the JWKS endpoint
Hi everybody,
I have a question related to Leo Farrell's blog post : ISAM and JWKS
You are running into the following issue : the certificates listed by /sps/jwks do not have the same kid that the one used by the STS transformation to create the JWT.
Both the STS transfo and the JWKS are pointing to the same truststore (rt_profile), but on the STS side the label of the certificate is used as kid (server) and on the JWKS side we have a random kid for the same certificate (4lNI7UMGiAtShBopB9gF7cEsFIBSeewL69AYpVe3pSo).
The applications consuming the JWT are not able to validate the JWT as they are unable to find the JWT KID in the JWKS.
Do you have any idea how we could solve this ?
It could be a bug related to the latest firmware (10.0.4) and maybe we should open a case...
Thanks for you inputs
------------------------------
André Leruitte
------------------------------