IBM Security Verify

 View Only
  • 1.  JWT KID is different between the STS transfo and the JWKS endpoint

    IBM Champion
    Posted Thu August 04, 2022 05:36 AM
    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
    ------------------------------


  • 2.  RE: JWT KID is different between the STS transfo and the JWKS endpoint

    IBM Champion
    Posted Thu August 04, 2022 06:18 AM
    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
    ------------------------------



  • 3.  RE: JWT KID is different between the STS transfo and the JWKS endpoint

    Posted Fri August 05, 2022 02:05 AM

    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
    ------------------------------



  • 4.  RE: JWT KID is different between the STS transfo and the JWKS endpoint

    Posted Fri August 05, 2022 02:11 AM
    Hi André,

    1.
    You could control the specified kid value used by the STS, e.g. in the STS mapping rule:
    stsuu.addContextAttribute(new Attribute("signing.kid", "urn:ibm:JWT:header:claim", "mykid"));

    2.
    If the endpoint /sps/jwks doesn't present the kid as expected, use another endpoint.
    Place your signing cert into the webseal default keystore and active it via:
    [local-apps]
    jwks = jwks
    So you could access now: https://<webseal>/jwks, which you could tell your applications to use a new JWKS endpoint.
    You might even use a transformation rule to switch from federation /sps/jwks towards webseal /jwks.

    Frank


    ------------------------------
    Frank Thurau
    ------------------------------



  • 5.  RE: JWT KID is different between the STS transfo and the JWKS endpoint

    IBM Champion
    Posted Mon August 08, 2022 05:09 AM
    Hello Frank and Shane,

    Thank you both for your tips. I think all the workarounds sugeested by you can indeed mitigate the issue while waiting for a definitive fix.

    I particularly like the first solution suggested by Frank (forcing the kid value in the STS mapping rule) as it seems the most easy to implement in our situation.
    We are going to test it quickly.


    Regards

    ------------------------------
    André Leruitte
    ------------------------------