"Encode Json Web Token" assertion does not recognize key changes ?

[Michael Mueller]

Dear Team.

We encountered, that when changing/updating a key that is in use in the "Encode Json Web Token"  assertion for signing, the token is signed using the old key.
Is there any setting we can use, to enforce the usage of the updated key, similar to system.properties:

com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion.refreshOnKeyChanges=true

for the http routing assertion?

In general, we are looking for the capabaility to do key changes, without the necessity to restart the gateway.

Are there additional assertions that are affected ?

Thank you

KInd regards

...Michael

[Raju Gurram]

@Michael Mueller

Key usage of HTTP Routing is for caller's identity during mTLS. Because of which, HTTP Routing caches the prepared SSL context for reuse purposes. This cache will be invalidated for key updates.

Whereas, Encode Json Web Token doesn't cache the keys for signing the tokens. It always picks up the key from keystore. Having said that, there shouldn't be a problem. 

 

[Michael Mueller]

Thanks, Raju.

I will do some more testing to find evidence, why our services have failed after changing the key.

[Michael Mueller]

Hi @Raju Gurram

I did some further testing.

First I was using just a usual key reference for signing in the "Encode Json Web Token" assertion, by selecting the key from the dropdown:

Then I updated the specified key, with a new p12 and new certchain by graphman.

My test api, creating a jwt token, was using the new key without the necessity to restart the gateway. 

Great stuff, that matches your statement.

I then changed my "encode" assertion to use the default ssl key:

After double checking the token creation and its signing via jwt.io, I updated the default ssl key&cert by graphman.

In this scenario, after the graphman import, the generated token is still signed by the old ssl key!

I think, that way I reproduced the initial issue.

Gateway version is v11.1.3

Please check

Thanks

...Michael

[Raju Gurram]

Yes, keys that are marked for special purposes (in this Default SSL) are cached. Key changes suppose to invalidate the cache, if not, issues may occur.

You may log a defect for this. Otherwise, it is recommended NOT to use keys marked for special purposes other than the intended purposes.

There are reasons for not considering these type of special cases. However, please report this via support for tracking purposes.

Thanks. 

[Michael Mueller]

Thank you.

We were not aware of this recommendation. 

I'll open a support ticket.