Use existing keyrings during setup

[1000TurquoisePogs]

Many users do not want Zowe to create a keyring. They just want to use their own keyring.
This is possible and the requirements are documented at https://docs.zowe.org/stable/user-guide/configure-certificates#zowe-certificate-requirements but zowe does not provide clear documentation or intuition on how to make use of such keyrings.

Proposal 1:

Change example-zowe.yaml to add a 6th "certificate setup scenario"

It should look like this:

zowe:
  setup:
    certificate:
      type: JCERACFKS
      keyring:
        name: ZoweKeyring
        label: localhost
        create: false

This yaml is similar to the 3rd scenario (create keyring & certificate), but create: false will be used to tell it not to create.

The result of this config should be that no JCL is executed, no system change occurs.
At maximum, validation could be performed to see if the keyring chosen is actually valid for zowe use.

But the point of this yaml would be that upon running zwe init certificate, the only thing it would do is convert from the setup.certificate structure to the certificate structure.

Proposal 2:

Just completely comment out the whole zowe.setup.certificate section and make clear that users should go right down to the zowe.certificate area in which they'll find

zowe:
  certificate:
    keystore:
      type: JCERACFKS
      file: "safkeyring://${{zowe.setup.security.users.zowe}}/ZoweKeyring"
      alias: localhost
      password: password
    truststore:
      type: ${{ zowe.certificate.keystore.type }}
      file: ${{ zowe.certificate.keystore.file }}
      password: ${{ zowe.certificate.keystore.password }}

In other words, users need only alter the alias & end of file portions to get running.
defaults.yaml could have complicated defaulting to hide away the truststore section entirely I suppose.

[JoeNemo]

I like proposal 1 for it's stability over changes Zowe, administrators, and ZOS environment. The default should probably be false.

[balhar-jakub]

I would prefer the option 2 and specifically because based on what I see the typical use case is that the certificates are prepared by security team upfront and therefore the option to use existing certificates seems to me as default.

If we remove by default the certificate from setup section, it will remove the duplicity.

[skurnevich]

We can technically support both options, but we need to define something as default behavior anyway.
“Scenario 6” as a default one looks good to me, in the zowe.setup.certificate we will have all the information about the keyring and certificate and create: false flag. 
Then zwe init certificate could validate if all values are there and generate zowe.certificate section with provided information.

That could be a first step, but it does not solve the issue that Jakub mentioned above. We have a configuration duplicity and customers are confused about why there are two sections dedicated to certificates, sometimes mixing them up. Also, the scenarios are adding about 160 lines to the configuration, while having limited usability as many customers will not use Zowe to generate certificates at all.

To avoid duplicity we need to remove one of sections. Jakub is proposing to remove all the scenarios completely, it can work, we’ll just need to adjust the zwe init command behavior in case of a missing zowe.setup.certificate. That will make the configuration much simpler, but as Joe mentioned, that will be a massive and sudden change in configuration and we already not having it in v3. Also it will make it much harder in case customer still wants to create a separate keyring for zowe and connect existing certificate there (Scenarios 4, 5)

But we can go the other way around: If we are planning to have “Scenario 6” with details of existing certificates configuration sufficient to generate zowe.certificate section, why can’t we remove zowe.certificate from the default yaml configuration? Then we can decrease the number of scenarios in example yaml to 2-3, or even eventually move all of them to the documentation and keep only default “Scenario 6” there. In that case zowe.setup.certificate will organically become what is zowe.certificate now: a definition of the existing certificate configuration, just with extended capacity of keyring and certificate creation, if necessary.

This plan includes some logic updates behind the command, but If we are planning to rewrite zwe init certificate to js anyway we can add this logic there, including the certificate validation capabilities, like if the keyring and certificate exist and if a zowe user has access to it etc (which then will be reused by ZEN)