I am initiating this document to collect feedbacks on a possible new set of CLI commands.

CONTEXT

We have JIRA EAP7-702 that is asking for high level operations for elytron. In order to bootstrap this feature, I am thinking at a concrete use-case that seems very common: enabling https on both management and application level.

Security command

For now I am thinking that elytron should be hidden from command name. I would name the command "security" that can be seen as too vague, but is very extensible. All security management actions would be grouped under the security command.

CLI commands to enable SSL

Although the http part (or native interface) is not elytron related, making a single command that group both elytron and management interfaces (or undertow server) configuration seems to make sense.

Based on the elytron documentation (https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildFlyElytronSecurity-ConfigureSSL%2FTLS) in which we can see the required steps, I have sketched 2 security actions to address on-way configuration: enable-ssl-management and enable-ssl-http-server

These actions would hide part of the complexity (eg: naming and creating new elytron resources) and properly sequence operations. They have a limited set of required options, full power being offered by optional options with some default values. Completion should be very useful there.

These commands allow to enable SSL in 3 way:

• Relying on the new operations exposed by elytron to generate key pairs. Operations are defined in Analysis and Design document
  
• Using an the key-store-name of an already added key-store
• Using a key-store file (so not already added to the model).

enable-ssl-management action

security enable-ssl-management ( [--interactive] |

                                   [--key-store-path=<key-store path>]

                                   [--key-store-password=<password>]

                                   [--key-store-path-relative-to=<system

                                   property>] [--key-store-type=<type>]

                                   [--new-key-store-name=<key-store name>] |

                                   [--key-store-name=<key-store name>] )

                                   [--management-interface=<management

                                   interface>]

                                   [--http-secure-socket-binding=<socket

                                   binding>]

                                   [--new-key-manager-name=<key-manager name>]

                                   [--new-ssl-context-name=<ssl-context name>]

                                   [--no-reload] ( [--trust-store-name=<name>]

                                   | [--trusted-certificate-path=<certificate

                                   path>] [--no-trusted-certificate-validation]

                                   [--trust-store-file-name=<file name>]

                                   [--trust-store-file-password=<password>] )

Minimal set of options to enable https for the management http-interface would be:

security enable-ssl-management --interactice

In this case, CLI prompts the user for a possible key-store file name, DN, password, alias, validity, Mutual (client certificate, trust-store file name, password, validate certificate) once these pieces of information are collected, the server keystore (RSA, key-size 1024), the certificate (in pem format) files and optional the trust-store files are generated in the server configuration directory. In case an elytron key-store resource already references the same file in the same location, the command is aborted and the user is suggested to change the file name or use the --key-store-name option to reuse the existing key-store.

key-store, key-manager, ssl-context are generated and the http-interface is secured. NB: this command is to be used in interactive mode only, it expects user input.

Minimal set of options to enable https for the management http-interface using an already added key-store and have the standalone server to reload would be:

security enable-ssl-management --key-store-name=<ksname>

Minimal set of options to enable https for the management http-interface using key-store file and have the standalone server to reload would be:

security enable-ssl-management --key-store-path=<path to keystore> --key-store-password=<password>

disable-ssl-management action

Remove the SSL Context (and possibly http-secure-socket-binding) from the selected management interface. NB: Some special logic is to be added to this CLI command in order to be able to reconnect after the https connection has been removed.

security disable-ssl-management [--management-interface=<interface>] [--no-reload]

enable-ssl-http-server action

security enable-ssl-http-server ( [--interactive] |

                                    [--key-store-path=<key-store path>]

                                    [--key-store-password=<password>]

                                    [--key-store-path-relative-to=<system

                                    property>] [--key-store-type=<type>]

                                    [--new-key-store-name=<key-store name>] |

                                    [--key-store-name=<key-store name>] )

                                    [--new-key-manager-name=<key-manager name>]

                                    [--new-ssl-context-name=<ssl-context name>]

                                    [--no-override-security-realm]

                                    [--no-reload] ( [--trust-store-name=<name>]

                                    | [--trusted-certificate-path=<certificate

                                    path>]

                                    [--no-trusted-certificate-validation]

                                    [--trust-store-file-name=<file name>]

                                    [--trust-store-file-password=<password>] )

                                    [--server-name=<server name>]

Minimal set of options to enable https for the default server:

security enable-ssl-http-server --interactive

The behaviour is similar to the management command.

Minimal set of options to enable https for the default server:

security enable-ssl-http-server --key-store-name=name

Minimal set of options to enable https for the default server using key-store file and have the standalone server to reload would be:

security enable-ssl-http-server --key-store-path=<path to keystore> --key-store-password=<password>

http-server-disable-ssl action

Remove the SSL Context from the selected server.

security http-server-disable-ssl [--server-name=<server name>] [--no-reload]

Options

--interactive=To start a wizard that prompts the user to get all required pieces of information.

--key-store-name=The name of a keystore. If --key-store-path is present, then the keystore name mustn't exist, it will be created by the command. If not set, --key-store-path must be present and the name of the keystore will be computed based on the keystore file name.

--key-store-path=The path to a keystore, must be used if the provided keystore doesn't exist.

--key-store-type=Type of key-store, by default is JKS.

--key-store-path-relative-to=Only available if keystone-path is used.

--key-store-password=The keystore password, must be set if a --key-store-path has been set.

--new-key-store-name=If not set, Computed on the fly, and displayed to the user at the end of the execution.

--new-key-manager-name=If not set, Computed on the fly, and displayed to the user at the end of the execution.

--new-ssl-context-name=If not set, Computed on the fly, and displayed to the user at the end of the execution.

--management-interface=If not set, If a single exists use this one, otherwise abort.

--http-secure-socket-binding=If not set and --management-interface is http-interface use management-https, if it doesn't exist or management-interface is not http, abort.

--server-name=If not set, if only one server configured, use this one

--no-override-security-realm, if not in use security-realm is erased, if used, the command would fail if the https-listener is configured to use legacy.

--no-reload if not in use, reload the server

Two way authentication:

--trusted-certificate-path=Absolute path to client certificate to import. Optional, can't be used with --trust-store-name

--trust-store-file-name=The name of the generated trust-store file. By default it is generated.

--trust-store-file-password=The password of the generated trust-store file. By default it is generated.

--no-trusted-certificate-validation By default the certificate is validated, and the operation aborts if the validation fails. Use this option to disable validation.

--trust-store-name=The name of the trust-store that contains the client certificate. Optional, can't be used with --trusted-certificate-path

Implementation

The DMR operations would be put in a batch in order to avoid side effects in case of error. Any error encountered while building-up the batch would abort the command (eg: invalid key-store type, already-exiting key-store, ...)

CLI commands to manage key-store

At the light of WFCORE-3305, it appears that key-store resource management could deserve their own commands. Having to rely on JDK keytool is not ideal and breaks the ability to do a complete setup using management operations only. If we go at defining security actions that are similar to keytool actions, we could re-use keytool naming. Re-using the JDK keytool options and values naming would make people already familiar with the options. keytool suffers for a lack of completion, with CLI we can drive user to set valid alg, length and paths.

Only 2 keystore related commands are described in this documents, other commands defined in this Analysis and Design document could be treated similarly. All key-store related commands could be prefixed by ssl-key-store-

ssl-keystore-genkeypair action

Generates a private/public keys pair, similar to what keytool is generating. In addition creates (or re-use) a key-store elytron resource.

security ssl-keystore-genkeypair --alias=localhost --keyalg=RSA --keysize=1024 --validity=365 --key-store=keystore.jks --dname="CN=localhost" --keypass=secret --storepass=secret [--relative-to=jboss.server.config.dir] [--key-store-name=keystore] [--start-date=<date>] [--sigalg=<signature all name>] [--extensions=[{critical=<true,false>, name=<extensionName>,value=<extensionValue>}...]]

--relative-to and --key-store-name would be wildfly specific, If no keystore name is provided, and no key-store resource exists, we could reuse the name of the keystore file.

This command would persist the keystore content (calling the store method).

--extensions requires an advanced completer to allow user to build-up a list (we should reuse simplified DMR syntax there). extension names should be proposed by completer. Completion of values could be partly offered although some values are not bounded. A link from the command help to the specification of extension would be required.

ssl-keystore-add-existing-file action

For users still using the JDK keytool (or having an existing keystore), we could add a command to create a key-store from an existing file.

security ssl-keystore-add-existing-file --key-store-path=<path to keystore> --key-store-password=<password> [--key-store-name=<name>] [--key-store-path-relative-to=<dir variable>] [--key-store-type=JKS]

Default options

We can identify default values for some options:

--key-store-type=JKS

--key-store-name=Computed on the fly, and displayed to the user at the end of the execution. Thanks to completion, name will be proposed in commands requiring a key-store name.

--relative-to=if not in use, consider the path absolute

Other security commands

Ideas for security actions are welcome.

• ssl-enable-two-way-management
• ssl-enable-two-way-https-server
• ...