JWT Pre-flight check

[hrishikesh-nalawade]

Is your feature request related to a problem? Please describe.
When the API Mediation Layer starts up, it attempts to reach the z/OSMF JWK endpoint to determine JWT support. If z/OSMF is unreachable, its certificate is untrusted by Zowe's truststore, or JWT support is not enabled, the API Layer fails at runtime with opaque errors that are difficult to diagnose, such as SSL handshake failures, connection timeouts, or silent authentication fallbacks. Operators have no way to verify the z/OSMF JWT configuration is correct before starting Zowe, leading to frustrating trial-and-error debugging cycles during installation and configuration.

Describe the solution you'd like
Utility which will ideally triggered through a "zwe validate .." command. Inside api-layer there would be a standalone pre-flight check utility (packaged as a self-contained JAR) that validates the z/OSMF JWK endpoint connectivity before/after Zowe services start.

[balhar-jakub]

I am in favor of this but important part of this solution should be linked to the certificate checker utility that is already part of this repository.

Can we maybe expand it rather than adding something new and additional?

[1000TurquoisePogs]

That decision is up to your squad of course but I'll say that it'd be very nice to have this behavior in some jar by code freeze so that we can improve the verification of 3.5.0
Perhaps go with something now reorganize it for 3.6.0?

What I've done with the other checks, my opinion, is to have each binary be for 1 distinct purpose. This way, when a check fails, it is hard to blame a bug in the check itself. If we had one big binary that did everything, it would become its own source of errors. I also think having tiny programs that check just 1 thing allows the open source world to pick up our code and use it however they want which is nice.

[balhar-jakub]

I agree, with you Sean and I think that all the code can be reused and just directly packaged in the certificate validator. Also due to some of the issues we found very recently we would like to propose a two week delay to the release on the TSC call tomorrow.

I am not against having tiny programs, but I would argue Java is then probably not the best language to do so with the overhead on top of it. Nevertheless I am not going to stand in the way for this solution

[1000TurquoisePogs]

@balhar-jakub some thought hey why not do this in curl, but... then you can't really get to keyrings. I agree java is a bit heavy to just connect to a URL but it's going to give us a very 'realistic' view of what zowe would see when it starts up due to having all the java TLS-isms that APIML would later have. In the future for example, this and/or certificate-analyser could run with the same TLS level/ciphers that apiml is told to use, to be even more accurate.