1. Create a keystore to secure the management interfaces.

   Note

   This keystore must be in JKS format as the management interfaces are not compatible with keystores in JCEKS format.

   Use the following to generate a keystore, replacing the example values for the parameters, for example alias, keypass, keystore, storepass and dname, with the correct values for the environment.

   Note

   The parameter validity specifies for how many days the key is valid. A value of 730 equals two years.

   Using the keytool command to generate a keystore from the terminal

   $ keytool -genkeypair -alias appserver -storetype jks -keyalg RSA -keysize 2048 -keypass password1 -keystore EAP_HOME/standalone/configuration/identity.jks -storepass password1 -dname "CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US" -validity 730 -v

2. Ensure the management interfaces bind to HTTPS.

   1. Running a Standalone Server.

      To ensure the management interfaces bind to HTTPS, you must add the management-https configuration and remove the management-http configuration.

      Use the following CLI commands to bind the management interfaces to HTTPS:

      /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
      
      /core-service=management/management-interface=http-interface:undefine-attribute(name=socket-binding)

   2. Running a Managed Domain

      Change the socket element within the management-interface section by adding secure-port and removing port configuration.

      Use the following commands to bind the management interfaces to HTTPS:

      /host=master/core-service=management/management-interface=http-interface:write-attribute(name=secure-port,value=9993)
      
      /host=master/core-service=management/management-interface=http-interface:undefine-attribute(name=port)

3. Optional: Use custom socket-binding-group. If you want to use a custom socket-binding-group, you must ensure the management-https binding is defined, which by default is bound to port 9993. You can verify this by reviewing the socket-binding-group section of the server’s configuration file or by using the management CLI:

   Example Reading the socket-binding-group Configuration Using the Management CLI

   /socket-binding-group=standard-sockets/socket-binding=management-https:read-resource(recursive=true)
   
   {
       "outcome" => "success",
       "result" => {
           "client-mappings" => undefined,
           "fixed-port" => false,
           "interface" => "management",
           "multicast-address" => undefined,
           "multicast-port" => undefined,
           "name" => "management-https",
           "port" => expression "${jboss.management.https.port:9993}"
       }
   }

4. Create a new security realm. In this example, the new security realm using HTTPS, ManagementRealmHTTPS, uses a properties file named https-mgmt-users.properties located in the EAP_HOME/standalone/configuration/ directory for storing usernames and passwords. Usernames and passwords can be added to the file later, but for now, you need to create an empty file named https-mgmt-users.properties and save it to that location. The below example shows using the touch command, but you may also use other mechanisms, such as a text editor.

   Example using the touch command to create an empty file

   $ touch EAP_HOME/standalone/configuration/https-mgmt-users.properties

   Next, enter the following CLI commands to create a new security realm named ManagementRealmHTTPS:

   /core-service=management/security-realm=ManagementRealmHTTPS:add
   
   /core-service=management/security-realm=ManagementRealmHTTPS/authentication=properties:add(path=https-mgmt-users.properties,relative-to=jboss.server.config.dir)

   At this point, you have created a new security realm and configured it to use a properties file for authentication. You must now add users to that properties file using the add-user script, which is available in the EAP_HOME/bin/ directory. When running the add-user script, you must specify both the properties file and the security realm using the -up and -r options respectively. From there, the add-user script will interactively prompt you for the username and password information to store in the https-mgmt-users.properties file.

   $ EAP_HOME/bin/add-user.sh -up EAP_HOME/standalone/configuration/https-mgmt-users.properties -r ManagementRealmHTTPS
   ...
   Enter the details of the new user to add.
   Using realm 'ManagementRealmHTTPS' as specified on the command line.
   ...
   Username : httpUser
   Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file.
    - The password must not be one of the following restricted values {root, admin, administrator}
    - The password must contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
    - The password must be different from the username
   ...
   Password :
   Re-enter Password :
   About to add user 'httpUser' for realm 'ManagementRealmHTTPS'
   ...
   Is this correct yes/no? yes
   ..
   Added user 'httpUser' to file 'EAP_HOME/configuration/https-mgmt-users.properties'
   ...
   Is this new user going to be used for one AS process to connect to another AS process?
   e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
   yes/no? no

   Important

   When configuring security realms that use properties files to store usernames and passwords, it is recommended that each realm use a distinct properties file that is not shared with another realm.

5. Configure the management interfaces to use the new security realm.

   /core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=ManagementRealmHTTPS)

6. Configure the management interfaces to use the keystore.

   Use the below CLI command to configure the management interfaces to use the keystore. For the parameters file, password and alias their values must be copied from the first step.

   CLI Command for Adding a Keystore to a Security Realm

   /core-service=management/security-realm=ManagementRealmHTTPS/server-identity=ssl:add(keystore-path=identity.jks,keystore-relative-to=jboss.server.config.dir,keystore-password=password1, alias=appserver)

   Note

   To update the keystore password, use the following CLI command:

   /core-service=management/security-realm=ManagementRealmHTTPS/server-identity=ssl:write-attribute(name=keystore-password,value=newpassword)

   At this point, you need to reload the server’s configuration:

   reload

   After reloading the server configuration, the log should contain the following, just before the text which states the number of services that are started:

   13:50:54,160 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0061: Http management interface listening on https://127.0.0.1:9993/management
   13:50:54,162 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0052: Admin console listening on https://127.0.0.1:9993

   The management interfaces are now listening on port 9993, which confirms that the procedure was successful.

   Important

   At this point, the CLI will disconnect and will be unable to reconnect since the port bindings have changed. Proceed to the next step to update the jboss-cli.xml to allow the CLI to reconnect.

7. Update the jboss-cli.xml.

   If using the management CLI to perform management actions, the following changes must to be made to the EAP_HOME/bin/jboss-cli.xml file:

   • Update the value of <default-protocol> to https-remoting.
   • In <default-controller>, update the value of <protocol> to https-remoting.

   • In <default-controller>, update the value of <port> to 9993.

     Example jboss-cli.xml

     <jboss-cli xmlns="urn:jboss:cli:2.0">
         <default-protocol use-legacy-override="true">https-remoting</default-protocol>
         <!-- The default controller to connect to when 'connect' command is executed w/o arguments -->
         <default-controller>
             <protocol>https-remoting</protocol>
             <host>localhost</host>
             <port>9993</port>
         </default-controller>
     ...

     The next time you connect to the management interface using the management CLI, you must accept the server certificate and authenticate against the ManagementRealmHTTPS security realm:

     Example Accepting Server Certificate and Authenticating

     $ ./jboss-cli.sh -c
     Unable to connect due to unrecognised server certificate
     Subject    - CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US
     Issuer     - CN=appserver, OU=Sales, O=Systems Inc, L=Raleigh, ST=NC, C=US
     Valid From - Tue Jun 28 13:38:48 CDT 2016
     Valid To   - Thu Jun 28 13:38:48 CDT 2018
     MD5 : 76:f4:81:8b:7e:c3:be:6d:ee:63:c1:7a:b7:b8:f0:fb
     SHA1 : ea:e3:f1:eb:53:90:69:d0:c9:69:4a:5a:a3:20:8f:76:c1:e6:66:b6
     
     Accept certificate? [N]o, [T]emporarily, [P]ermenantly : p
     Authenticating against security realm: ManagementRealmHTTPS
     Username: httpUser
     Password:
     [standalone@localhost:9993 /]

1. Generate the keystores.

   $ keytool -genkeypair -alias HOST1_alias -keyalg RSA -keysize 1024 -validity 365 -keystore HOST1.keystore.jks -dname "CA_HOST1" -keypass secret -storepass secret
   
   $ keytool -genkeypair -alias HOST2_alias -keyalg RSA -keysize 1024 -validity 365 -keystore HOST2.keystore.jks -dname "CA_HOST2" -keypass secret -storepass secret

2. Export the certificates.

   $ keytool -exportcert  -keystore HOST1.keystore.jks -alias HOST1_alias -keypass secret -storepass secret -file HOST1.cer
   
   $ keytool -exportcert  -keystore HOST2.keystore.jks -alias HOST2_alias -keypass secret -storepass secret -file HOST2.cer

3. Import the certificates into the opposing truststores.

   $ keytool -importcert -keystore HOST1.truststore.jks -storepass secret -alias HOST2_alias -trustcacerts -file HOST2.cer
   
   $ keytool -importcert -keystore HOST2.truststore.jks -storepass secret -alias HOST1_alias -trustcacerts -file HOST1.cer

4. Define a CertificateRealm.

   Define a CertificateRealm in the configuration for the server (host.xml or standalone.xml) and point the interface to it. This can be done using the following commands:

   /core-service=management/security-realm=CertificateRealm:add()
   
   /core-service=management/security-realm=CertificateRealm/server-identity=ssl:add(keystore-path=/path/to/HOST1.keystore.jks, keystore-password=secret,alias=HOST1_alias)
   
   /core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-path=/path/to/HOST1.truststore.jks,keystore-password=secret)

5. Change the security-realm of the http-interface to the new CertificateRealm.

   /core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=CertificateRealm)

6. Add the SSL/TLS configuration for the CLI.

   Important

   In addition to adding the two-way SSL/TLS, the management interface should also be configured to bind to HTTPS.

   Add the SSL/TLS configuration for the CLI, which uses EAP_HOME/bin/jboss-cli.xml as a settings file.

   To store the keystore and truststore passwords in plain text, edit EAP_HOME/bin/jboss-cli.xml and add the SSL/TLS configuration using the appropriate values for the variables:

   Example jboss-cli.xml XML

   <ssl>
     <alias>HOST2_alias</alias>
     <key-store>/path/to/HOST2.keystore.jks</key-store>
     <key-store-password>secret</key-store-password>
     <trust-store>/path/to/HOST2.truststore.jks</trust-store>
     <trust-store-password>secret</trust-store-password>
     <modify-trust-store>true</modify-trust-store>
   </ssl>

   To use the keystore and truststore passwords stored in a password vault, you need to add the vault configuration and appropriate vault values to EAP_HOME/bin/jboss-cli.xml:

   Example jboss-cli.xml XML

   <ssl>
     <vault>
       <vault-option name="KEYSTORE_URL" value="path-to/vault/vault.keystore"/>
       <vault-option name="KEYSTORE_PASSWORD" value="MASK-5WNXs8oEbrs"/>
       <vault-option name="KEYSTORE_ALIAS" value="vault"/>
       <vault-option name="SALT" value="12345678"/>
       <vault-option name="ITERATION_COUNT" value="50"/>
       <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/>
     </vault>
     <alias>HOST2_alias</alias>
     <key-store>/path/to/HOST2.keystore.jks</key-store>
     <key-store-password>VAULT::VB::cli_pass::1</key-store-password>
     <key-password>VAULT::VB::cli_pass::1</key-password>
     <trust-store>/path/to/HOST2.truststore.jks</trust-store>
     <trust-store-password>VAULT::VB::cli_pass::1</trust-store-password>
     <modify-trust-store>true</modify-trust-store>
   </ssl>

1. Add and configure an HTTPS security realm first. Once the HTTPS security realm has been configured, configure an https-listener in the undertow subsystem that references the security realm:

   batch
   
   /core-service=management/security-realm=HTTPSRealm/:add
   
   /core-service=management/security-realm=HTTPSRealm/server-identity= \
   ssl:add(keystore-path=identity.jks, \
   keystore-relative-to=jboss.server.config.dir, \
   keystore-password=password1, alias=appserver)
   
   /subsystem=undertow/server=default-server/https-listener=https:add( \
   socket-binding=https, security-realm=HTTPSRealm)
   
   run-batch

   Warning

   Red Hat recommends that SSLv2, SSLv3, and TLSv1.0 be explicitly disabled in favor of TLSv1.1 or TLSv1.2 in all affected packages.

2. Reload the server for the changes to take effect.

   reload

1. Generate the stores for both the client and server
2. Export the certificates for both the client and server
3. Import the certificates into the opposing truststores
4. Define a security realm, for example CertificateRealm, on the server that uses the server’s keystore and truststore
5. Update the undertow subsystem to use the security realm and require client verification

1. Create an SSL/TLS security realm on the master domain controller.

   You need to create an SSL/TLS security realm on the master domain controller configured to use your NSS database as a PKCS11 provider.

   Example Security Realm

   <security-realm name="HTTPSRealm">
       <server-identities>
           <ssl>
               <engine enabled-protocols="TLSv1.1"/>
               <keystore provider="PKCS11" keystore-password="strongP@ssword1"/>
           </ssl>
       </server-identities>
       <authentication>
           <local default-user="\$local"/>
           <properties path="https-users.properties" relative-to="jboss.domain.config.dir"/>
       </authentication>
   </security-realm>

2. Create an SSL/TLS security realm on each host controller.

   You need to create a security realm with an SSL/TLS truststore for authentication.

   Example Security Realm

   <security-realm name="HTTPSRealm">
     <authentication>
       <truststore provider="PKCS11" keystore-password="strongP@ssword1"/>
     </authentication>
   </security-realm>

   Note

   You need to repeat this process on each host.

3. Secure the native interface on the master domain controller.

   You need to ensure that the native interface on the master domain controller is secured with the security realm you just created.

   Example Native Interface

   <management-interfaces>
     ...
     <native-interface security-realm="HTTPSRealm">
       <socket interface="management" port="${jboss.management.native.port:9999}"/>
      </native-interface>
   </management-interfaces>

4. Use the SSL/TLS realm on each host controller to connect to the master domain controller.

   You need to update the security realm used for connecting to the master domain controller. This change must be done directly in the host controller’s configuration file, for example host.xml or host-slave.xml, while the server is not running.

   Example Host Controller Configuration File

   <domain-controller>
     <remote security-realm="HTTPSRealm">
       <discovery-options>
         <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}"/>
       </discovery-options>
     </remote>
   </domain-controller>

5. Update how each server connects back to its host controller.

   You also need to update how each server connects back to its host controller.

   Example Server Configuration

   <server name="my-server" group="my-server-group">
     <ssl ssl-protocol="TLS" trust-manager-algorithm="SunX509" truststore-type="PKCS11" truststore-password="strongP@ssword1"/>
   </server>

6. Configure two-way SSL/TLS in a managed domain.

   To enable two-way SSL/TLS, add a truststore authentication method to the SSL/TLS security realm for the master domain controller, execute the following management CLI commands:

   /host=master/core-service=management/security-realm=HTTPSRealm/authentication=truststore:add(keystore-provider="PKCS11",keystore-password="strongP@ssword1")
   
   reload --host=master

   You also need to update each host controller’s security realm to have an SSL server identity, execute the following management CLI commands:

   /host=host1/core-service=management/security-realm=HTTPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="strongP@ssword1",enabled-protocols=["TLSv1.1"])
   
   reload --host=host1

   Important

   You also need to ensure that each host’s certificate is imported into the domain controller’s truststore.

1. Create a security domain.

   In this example, a security domain is created with the UserRoles login module, but other login modules may be used as well:

   /subsystem=security/security-domain=UsersLMDomain:add(cache-type=default)
   
   /subsystem=security/security-domain=UsersLMDomain/authentication=classic:add
   
   /subsystem=security/security-domain=UsersLMDomain/authentication=classic/login-module=UsersRoles:add(code=UsersRoles, flag=required,module-options=[("usersProperties"=>"users.properties"),("rolesProperties"=>"roles.properties")])

2. Create a security realm with JAAS authentication.

   /core-service=management/security-realm=SecurityDomainAuthnRealm:add
   
   /core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:add(name=UsersLMDomain)

3. Update the http-interface management interface to use new security realm.

   /core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=SecurityDomainAuthnRealm)

4. Optional: Assign group membership.

   The attribute assign-groups determines whether loaded user membership information from the security domain is used for group assignment in the security realm. When set to true, this group assignment is used for Role-Based Access Control (RBAC).

   /core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:write-attribute(name=assign-groups,value=true)

1. Open the security domain’s detailed view.

   • Click Configuration at the top of the screen.
   • In a managed domain, select a profile to modify from the Profile selection box at the top left.
   • Click on Subsystems, then Security.
   • Click on the security domain to edit and click View.

2. Navigate to the Auditing configuration.

   Click on Audit at the left side of the screen.

   The configuration area is divided into two areas: Provider Modules and Details. The provider module is the basic unit of configuration. A security domain can include several provider modules each of which can include attributes and options.

3. Add a provider module.

   Click Add and fill in the Code section with the classname of the provider module. Also fill in the Name section with the desired name.

4. Verify the module is working.

   The goal of an audit module is to provide a way to monitor the events in the security subsystem. This monitoring can be done by means of writing to a log file, email notifications, or any other measurable auditing mechanism.

   For example, JBoss EAP includes the org.jboss.security.audit.providers.LogAuditProvider module by default. If enabled following the steps above , this audit module writes security notifications to a audit.log file in the log subfolder within the EAP_HOME directory.

   To verify if the steps above have worked in the context of the org.jboss.security.audit.providers.LogAuditProvider, perform an action that is likely to trigger a notification and then check the audit log file.

5. Optional: Add, edit, or remove module options.

   To add options to your module, click its entry in the Modules list, and select the Module Options tab in the Details section of the page. Click Add, and provide the key and value for the option.

   To edit an option that already exists, click Remove to remove it, and click Add to add it again with the correct options.

To add a user via the adduser script:

1. Run the add-user.sh or add-user.bat command.
2. Choose whether to add a Management User or Application User.
3. Choose the realm the user will be added to. By default, the only available realms are ManagementRealm and ApplicationRealm. If a custom realm has been added, its name can be manually entered instead.
4. Type the desired username, password, and optional roles when prompted. The changes are written to each of the properties files for the security realm.

1. Launch the Password Vault command interactively.

   Launch the operating system’s command line interface and run EAP_HOME/bin/vault.sh (on Red Hat Enterprise Linux and similar operating systems) or EAP_HOME\bin\vault.bat (on Microsoft Windows Server). Start a new interactive session by typing 0 (zero).

2. Complete the prompted parameters.

   Follow the prompts to input the required parameters. These values must match those provided when the Password Vault was created.

   Note

   The keystore password must be given in plaintext form, not masked form.

3. Complete the prompted parameters about the sensitive string.

   Enter 0 (zero) to start storing the sensitive string. Follow the prompts to input the required parameters.

4. Make note of the information about the masked string.

   A message prints to standard output, showing the vault block, attribute name, masked string, and advice about using the string in the configuration. Make note of this information in a secure location. An extract of sample output is as follows:

   Vault Block:ds_Example1
   Attribute Name:password
   Configuration should be done as follows:
   VAULT::ds_Example1::password::1

5. Exit the interactive console.

   Type 2 (two) to exit the interactive console.