Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

Chapter 2. Securing the Server and Its Interfaces

2.1. Building Blocks

2.1.1. Interfaces and Socket Bindings

JBoss EAP 6 utilizes its host’s interfaces (e.g. inet-address, nic, etc) and ports for communication for both its web applications as well as its management interfaces. These interfaces and ports are defined and configured through the interfaces and socket-binding-groups settings in the JBoss EAP 6 configuration files (e.g. standalone.xml, domain.xml, host.xml, etc). For more information on how to define and configure interfaces and socket-binding-groups, consult the Interfaces and Socket Binding Groups sections of the Red Hat JBoss Enterprise Application Platform 6 Administration and Configuration Guide.

Example Interfaces

<interfaces>
  <interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
  </interface>
  <interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
  </interface>
  <interface name="unsecure">
    <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
  </interface>
</interfaces>

Example Socket Binding Group

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
  <socket-binding name="management-native" interface="management" port="${jboss.management.native.port:9999}"/>
  <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
  <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9443}"/>
  <socket-binding name="ajp" port="8009"/>
  <socket-binding name="http" port="8080"/>
  <socket-binding name="https" port="8443"/>
  <socket-binding name="remoting" port="4447"/>
  <socket-binding name="txn-recovery-environment" port="4712"/>
  <socket-binding name="txn-status-manager" port="4713"/>
  <outbound-socket-binding name="mail-smtp">
    <remote-destination host="localhost" port="25"/>
  </outbound-socket-binding>
</socket-binding-group>

2.1.2. Security Realms

JBoss EAP 6 uses security realms to define authentication and authorization mechanisms (e.g. local, LDAP, properties, etc) which can then be used by the management interfaces. For more background information on security realms, consult the Security Realms section of the Red Hat JBoss Enterprise Application Platform 6 Security Architecture guide.

Example Security Realms

<security-realms>
  <security-realm name="ManagementRealm">
    <authentication>
      <local default-user="$local" skip-group-loading="true"/>
      <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
    </authentication>
    <authorization map-groups-to-roles="false">
      <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
    </authorization>
  </security-realm>
  <security-realm name="ApplicationRealm">
    <authentication>
      <local default-user="$local" allowed-users="*" skip-group-loading="true"/>
      <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
    </authentication>
    <authorization>
      <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
    </authorization>
  </security-realm>
</security-realms>

Note

In addition to updating the existing security realms, JBoss EAP 6 also allows for new security realms to be created and used. New security realms may be created via the Management Console as well as invoking the following command from the Management CLI: /core-service=management/security-realm=NEW-REALM-NAME:add()

2.1.3. Using Security Realms and Socket Bindings for Securing the Management Interfaces

JBoss EAP 6 defines two distinct management interfaces:

  • http-interface
  • native-interface

These interfaces are defined in the <management-interfaces> section of the JBoss EAP 6 configuration: 

<management-interfaces>
  <native-interface security-realm="ManagementRealm">
    <socket-binding native="management-native"/>
  </native-interface>
  <http-interface security-realm="ManagementRealm">
    <socket-binding http="management-http"/>
  </http-interface>
</management-interfaces>

Notice that each interface specifies a security-realm and socket-binding. Updating the configuration for the specified security realm and socket binding allows for the management interfaces to be secured in different ways. In addition to being able to secure each of these interfaces via security realms and socket bindings, both of these interfaces also may be completely disabled, and users of these interfaces may be configured to have various roles and access rights. There are also a few topics in this guide, such as security auditing, secure passwords and JMX that overlap with other subsystems within JBoss EAP 6, but still relate to securing JBoss EAP 6.

2.2. How to Secure the Management Interfaces

The following sections show how to perform various operations related to securing the JBoss EAP 6 management interfaces and related subsystems.

Note

The below CLI commands were done assuming a standalone instance of JBoss EAP 6. For more details on using the CLI with JBoss EAP 6 domains, please consult The Management CLI section of the Red Hat JBoss Enterprise Application Platform 6 Administration and Guide.

2.2.1. Configuring the Networking and Ports Used by Red Hat JBoss Enterprise Application Platform 6

Depending on the configuration of the host, JBoss EAP 6 may be configured to use various network interfaces and ports. This allows JBoss EAP 6 to work with different host, networking, and firewall requirements. For more information on the Networking and Ports used by JBoss EAP 6 as well as how to configure those settings, please see the Network and Port Configuration section of the Red Hat JBoss Enterprise Application Platform 6 Administration and Configuration guide.

2.2.2. Configure the Management Console for HTTPS

Configuring the JBoss EAP 6 management console for communication only via HTTPS provides increased security. All network traffic between the client (web browser) and management console is encrypted, which reduces the risk of security attacks such as a man-in-the-middle attack.

In this procedure unencrypted communication with the JBoss EAP 6 standalone instance or domain is disabled. This procedure applies to both standalone and domain mode configurations. For domain mode, prefix the Management CLI commands with the name of the host, for example: /host=master.

To configure the Management Console for HTTPS, the following steps are required:

  1. Create a Keystore to Secure the Management Console
  2. Ensure the Management Console Binds to HTTPS
  3. Optional: Custom socket-binding Group
  4. Create a New Security Realm
  5. Configure Management Interface to Use the New Security Realm
  6. Configure the Management Console to Use the Keystore
  7. Restart the Red Hat JBoss Enterprise Application Platform 6 Instance

2.2.2.1. 1. Create a Keystore to Secure the Management Console

Note

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

Use the following to generate a keystore, replacing the example values for the parameters (e.g. 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.2.2.2. 2. Ensure the Management Console Binds to HTTPS

Standalone Mode

Ensure the management console binds to HTTPS for its interface by adding the management-https configuration and removing the management-http configuration.

Use the following CLI commands to bind the Management Console 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)
Note

At this point the JBoss EAP 6 log may display the following error message: JBAS015103: A secure port has been specified for the HTTP interface but no SSL configuration in the realm. This is to be expected because the SSL configuration is not yet completed.

Domain Mode

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 Console to HTTPS: 

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

At this point the JBoss EAP 6 log may display the following error message: JBAS015103: A secure port has been specified for the HTTP interface but no SSL configuration in the realm. This is to be expected because the SSL configuration is not yet completed.

2.2.2.3. 3. Optional: Custom socket-binding Group

If a custom socket-binding group is being used, ensure the management-https binding is defined (it is present by default, bound to port 9443). Edit the master configuration file (e.g. standalone.xml) to match the following:

Example XML

<socket-binding-group name="standard-sockets" default-interface="public"
    port-offset="${jboss.socket.binding.port-offset:0}">
  <socket-binding name="management-native" interface="management"
    port="${jboss.management.native.port:9999}"/>
  <socket-binding name="management-http" interface="management"
    port="${jboss.management.http.port:9990}"/>
  <socket-binding name="management-https" interface="management"
    port="${jboss.management.https.port:9443}"/>
...

2.2.2.4. 4. Create a New Security Realm

In this example, the new security realm using HTTPS (ManagementRealmHTTPS) will use a properties file named https-mgmt-users.properties located in the EAP_HOME/standalone/configuration/ directory for storing usernames and passwords. Usernames and passwords will be added to the file later, but for now, simply create an empty file named https-mgmt-users.properties and save it to that location. The below example shows using the touch command from the terminal, but other mechanisms (such as using a text editor) could be used as well:

Example using the touch command from the terminal 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)

Now that the new properties file and realm have been created, users have to be added to that property file for use by the realm. This is accomplished via the add-user script available in the EAP_HOME/bin/ directory. When running the add-user, both the properties file and realm need to be specified using the -up and -r options respectively. From there, the add-user script will interactively prompt 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 property files to store usernames and passwords, it is recommended that each realm use a distinct properties file that is not shared with another realm.

2.2.2.5. 5. Configure Management Interface to Use the New Security Realm

CLI Command for Using a New Security Realm

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

2.2.2.6. 6. Configure the Management Console to Use the Keystore

Use the below CLI command to configure the management console 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)

reload
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)

2.2.2.7. 7. Restart the Red Hat JBoss Enterprise Application Platform 6 Instance

On restarting the server the log should contain the following, just before the text which states the number of services that are started. The management console is now listening on port 9443, which confirms that the procedure was successful. 

14:53:14,720 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015962: Http management interface listening on https://127.0.0.1:9443/management
14:53:14,721 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015952: Admin console listening on https://127.0.0.1:9443

2.2.3. Setting up Distinct HTTP and HTTPS Management Interfaces

The Management Interface can listen on distinct interfaces for HTTP and HTTPS connections. One scenario for this is to listen for encrypted traffic on an external network, and use unencrypted traffic on an internal network.

The secure-interface attribute specifies the network interface on which the host’s socket for HTTPS management communication should be opened, if a different interface should be used from that specified by the interface attribute. If it is not specified then the interface specified by the interface attribute is used.

Important

The secure-interface attribute has no effect if the secure-port attribute is not set.

Note that when the server listens for HTTP and HTTPS traffic on the same interface, HTTPS requests received by the HTTP listener are automatically redirected to the HTTPS port. When distinct interfaces are used for HTTP and HTTPS traffic, no redirection is performed when an HTTPS request is received by the HTTP listener.

Here is an example EAP_HOME/domain/configuration/host.xml configuration that sets the secure-interface attribute to listen for HTTPS traffic on a distinct interface from HTTP traffic:

Example XML

<host name="master" xmlns="urn:jboss:domain:3.0">
    <management>
        <security-realms>
            <security-realm name="ManagementRealm">
                <authentication>
                    <local default-user="$local" />
                    <properties path="mgmt-users.properties"
                      relative-to="jboss.domain.config.dir"/>
                </authentication>
            </security-realm>
        </security-realms>
        <management-interfaces>
            <native-interface security-realm="ManagementRealm">
                <socket interface="management"
                  port="${jboss.management.native.port:9999}"/>
            </native-interface>
            <http-interface security-realm="ManagementRealm">
                <socket interface="management"
                  port="${jboss.management.http.port:9990}"
                  secure-port="${jboss.management.https.port:9943}"
                  secure-interface="secure-management"/>
            </http-interface>
        </management-interfaces>
    </management>
    <domain-controller>
        <local/>
        <!-- Alternative remote domain controller configuration with a host and port -->
        <!-- <remote host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/> -->
    </domain-controller>
    <interfaces>
        <interface name="management">
            <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
        </interface>
        <interface name="secure-management">
            <inet-address value="${jboss.bind.address:10.10.64.1}"/>
        </interface>
    </interfaces>
</host>

2.2.4. Disabling the HTTP Interfaces

In certain scenarios, such as managed domain or certain production deployments, administrators may wish to disable access to the management interfaces via HTTP or remove the HTTP management interface entirely.

The following may be used to read the current configuration of the HTTP interface:

CLI Command for Reading the Current HTTP Interface Configuration

/core-service=management/management-interface=http-interface/:read-resource( \
recursive=true, proxies=false, include-runtime=false, include-defaults=true)

Result

{
    "outcome" => "success",
    "result" => {
        "console-enabled" => true,
        "interface" => "management",
        "port" => expression "${jboss.management.http.port:9990}",
        "secure-port" => undefined,
        "security-realm" => "ManagementRealm"
    }
}

To remove the HTTP interface entirely:

CLI Command for Removing the HTTP Interface Entirely

/core-service=management/management-interface=http-interface/:remove

Once the HTTP interface has been removed, it can be enabled again by re-creating it:

CLI Command for Re-Creating the HTTP Interface:

/core-service=management/management-interface=http-interface:add( \
console-enabled=true, interface=management, \
port="${jboss.management.http.port:9990}", \
security-realm=ManagementRealm)

Disabling Just the Management Console

Other clients, such as JBoss Operations Network, also operate using the HTTP interface for managing JBoss EAP 6. In order to continue using these services, just the web-based Management Console itself may be disabled. This is accomplished by setting the console-enabled attribute to false:

CLI Command for Disabling the Web-Based Management Console

/core-service=management/management-interface=http-interface/:write-attribute( \
name=console-enabled,value=false)

2.2.5. Setting up 2-Way SSL/TLS for the Management Interfaces

2-way SSL/TLS authentication, also known as client authentication, authenticates both the client and the server using SSL/TLS certificates. This differs from the Configure the Management Console for HTTPS section in that both the client and server each have a certificate. This provides assurance that not only is the server who it says it is, but the client is also who it says it is.

In this section the following conventions are used:

HOST1
The JBoss server hostname. For example; jboss.redhat.com
HOST2
A suitable name for the client. For example: myclient. Note this is not necessarily an actual hostname.
CA_HOST1
The DN (distinguished name) to use for the HOST1 certificate. For example cn=jboss,dc=redhat,dc=com.
CA_HOST2
The DN (distinguished name) to use for the HOST2 certificate. For example cn=myclient,dc=redhat,dc=com.

To setup the 2-way SSL/TLS for the Management Interfaces, the following steps are required:

  1. Generate the stores
  2. Export the certificates
  3. Import the certificates into the opposing trust stores
  4. Define a CertificateRealm
  5. Change the security-realm of the native-interface to the new Certificate Realm
  6. Add the SSL configuration for the CLI
Prerequisites

If a password vault is used to store the keystore and truststore passwords (recommended), the password vault should already be created. For more information on the password vault, please see the Password Vault section as well as the Password Vault System section of the Red Hat JBoss Enterprise Application Platform 6 Security Architecture guide.

1. Generate the stores:

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 trust stores:

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 installation (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 native-interface to the new Certificate Realm.

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

6. Add the SSL configuration for the CLI,

Add the SSL configuration for the CLI, which uses EAP_HOME/bin/jboss-cli.xml as a settings file. The passwords for the truststore and keystore can be stored in one of two ways:

  • Password Vault (Recommended)
  • Plain Text

6A. To store the keystore and truststore passwords in a password vault:

Edit EAP_HOME/bin/jboss-cli.xml and add the SSL/TLS configuration (using the appropriate values for the variables). Also add the vault configuration, replacing each value with those of the vault being used.

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>

6B. 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>

2.2.6. Setting up an SSL/TLS Connector

In addition to supporting HTTPS and 2-way SSL/TLS for the management interfaces, JBoss EAP 6 also enables SSL/TLS connectors to be setup for use by security domains.

Important

As a prerequisite, an SSL/TLS Encryption Key and Certificate should be created and place in an accessible directory. Additionally, relavant information (e.g. keystore aliases and passwords, desired cypher suites, etc) should also be accessable. For examples on generating SSL/TLS Keys and Certificates, please see the first two steps in the Setting up 2-Way SSL/TLS for the Management Interfaces section. For more information about the the SSL/TLS connector (including cypher suites) please see the SSL Connector Reference section.

Add a HTTPS connector in the web subsystem

Create a secure connector, named HTTPS, which uses the https scheme, the https socket binding (which defaults to 8443), and is set to be secure. 

/subsystem=web/connector=HTTPS/:add(socket-binding=https,scheme=https, \
protocol=HTTP/1.1,secure=true)

Configure the SSL certificate, substituting the correct values for the example ones. This example assumes that the keystore is copied to the server configuration directory, which is EAP_HOME/standalone/configuration/ for a standalone JBoss EAP 6 instance. 

/subsystem=web/connector=HTTPS/ssl=configuration:add( \
name=https,certificate-key-file="${jboss.server.config.dir}/keystore.jks", \
password=SECRET, key-alias=KEY_ALIAS, cipher-suite=CIPHERS)

Set the protocol to TLSv1. 

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=protocol,value=TLSv1)

Deploy an application.

Important

The JBoss EAP 6 instance must be restarted for these changes to take effect.

2.2.7. SSL Connector Reference

JBoss Web connectors may include the following SSL configuration attributes.

2.2.7.1. name

The display name of the SSL connector. Attribute name is read-only.

2.2.7.2. verify-client

The possible values of verify-client differ, based upon whether the HTTP/HTTPS connector is used, or the native APR connector is used.

HTTP/HTTPS Connector
Possible values are true, false, or want. Set to true to require a valid certificate chain from the client before accepting a connection. Set to want if to want the SSL stack to request a client Certificate, but not fail if one is not presented. Set to false (the default) to not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=verify-client,value=want)

Native APR Connector
Possible values are optional, require, optionalNoCA, and none (or any other string, which will have the same effect as none). These values determine whether a certification is optional, required, optional without a Certificate Authority, or not required at all. The default is none, meaning the client will not have the opportunity to submit a certificate.

Example CLI

/subsystem=web/connector=APR/ssl=configuration/:write-attribute( \
name=verify-client,value=require)

2.2.7.3. verify-depth

The maximum number of intermediate certificate issuers checked before deciding that the clients do not have a valid certificate. The default value is 10.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=verify-depth,value=10)

2.2.7.4. certificate-key-file

The full file path and file name of the keystore file where the signed server certificate is stored. With JSSE encryption, this certificate file will be the only one, while OpenSSL uses several files. The default value is the .keystore file in the home directory of the user running JBoss EAP 6. If the keystoreType does not use a file, set the parameter to an empty string.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=certificate-key-file, \
value=../domain/configuration/server.keystore)

2.2.7.5. certificate-file

If OpenSSL encryption is used, set the value of this parameter to the path to the file containing the server certificate.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=certificate-file,value=server.crt)

2.2.7.6. password

The password for both the truststore and keystore. In the following example, replace PASSWORD with the actual password.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=password,value=PASSWORD)

2.2.7.7. protocol

The version of the SSL protocol to use. Supported values depend on the underlying SSL implementation (whether JSSE or OpenSSL). Refer to the Java SSE Documentation.

A comma separated combination of protocols can also be specified. For example, TLSv1, TLSv1.1,TLSv1.2.

Warning

Red Hat recommends that SSL is explicitly disabled in favor of TLSv1.1 or TLSv1.2 in all affected packages.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=protocol,value=ALL)

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=protocol,value="TLSv1, TLSv1.1,TLSv1.2")

2.2.7.8. cipher-suite

A list of the encryption ciphers which are allowed. For JSSE syntax, it must be a comma-separated list. For OpenSSL syntax, it must be a colon-separated list. Ensure that only one syntax is used.

The default is HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5.

The example only lists two possible ciphers, but real-world examples will likely use more.

Important

Using weak ciphers is a significant security risk. See http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295 for NIST recommendations on cipher suites.

For a list of available OpenSSL ciphers, see https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-STRINGS. Note that the following are not supported:

  • @SECLEVEL
  • SUITEB128
  • SUITEB128ONLY
  • SUITEB192

For a list of the standard JSSE ciphers, see http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#Cipher.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=cipher-suite, \
value="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA")

2.2.7.9. key-alias

The alias used to for the server certificate in the keystore. In the following example, replace KEY_ALIAS with the certificate’s alias.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=key-alias,value=KEY_ALIAS)

2.2.7.10. truststore-type

The type of the truststore. Various types of truststores are available, including PKCS12 and Java’s standard JKS.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=truststore-type,value=jks)

2.2.7.11. keystore-type

The type of the keystore, Various types of keystores are available, including PKCS12 and Java’s standard JKS.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=keystore-type,value=jks)

2.2.7.12. ca-certificate-file

The file containing the CA certificates. This is the truststoreFile, in the case of JSSE, and uses the same password as the keystore. The ca-certificate-file file is used to validate client certificates.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=ca-certificate-file,value=ca.crt)

2.2.7.13. ca-certificate-password

The Certificate password for the ca-certificate-file. In the following example, replace the MASKED_PASSWORD with the masked password.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=ca-certificate-password, value=MASKED_PASSWORD)

2.2.7.14. ca-revocation-url

A file or URL which contains the revocation list. It refers to the crlFile for JSSE or the SSLCARevocationFile for SSL.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=ca-revocation-url,value=ca.crl)

2.2.7.15. session-cache-size

The size of the SSLSession cache. This attribute applies only to JSSE connectors. The default is 0, which specifies an unlimited cache size.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=session-cache-size,value=100)

2.2.7.16. session-timeout

The number of seconds before a cached SSLSession expires. This attribute applies only to JSSE connectors. The default is 86400 seconds, which is 24 hours.

Example CLI

/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute( \
name=session-timeout,value=43200)

2.2.8. Disabling Remote Access to JMX

Remote access to the JMX subsystem allows for JDK and application management operations to be triggered remotely. To disable remote access to JMX in JBoss EAP 6, one of the following two things must be done:

  1. Remove the remoting connector in the JMX subsystem
  2. Remove the entire JMX subsystem

Removing the remoting connector

/subsystem=jmx/remoting-connector=jmx/:remove

Removing the entire JMX subsytem

/subsystem=jmx/:remove

For more information on JMX, please see the JMX section of the Red Hat JBoss Enterprise Application Platform 6 Security Architecture guide

2.2.9. Using JAAS for Securing the Management Interfaces

JAAS is a declarative security API used by JBoss EAP 6 to manage security. For more details and background regarding JAAS and declarative security, see the Declarative Security and JAAS section of the Red Hat JBoss Enterprise Application Platform 6 Security Architecture guide.

Note

When JBoss EAP 6 instances are configured to run in ADMIN_ONLY mode, using JAAS to secure the management interfaces is not supported. For more information on ADMIN_ONLY mode, please see section Reference of Switches and Arguments to pass at Server Runtime of the Administration and Configuration Guide.

To use JAAS to authenticate to the management interfaces, the following steps must be performed:

  1. Create a security domain
  2. Create a security realm with JAAS authentication
  3. Update the Management Interfaces to use new security realm
  4. Optional - Assign group membership

1. Creating 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

To 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 Management Interfaces to use new security realm

To update the http-interface to use the new realm: 

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

To update the native-interface to use the new realm: 

/core-service=management/management-interface=native-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).

To configure the assign-groups attribute: 

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

2.2.10. Silent Authentication

The default installation of JBoss EAP 6 contains a method of silent authentication for a local Management CLI user. This allows the local user the ability to access the Management CLI without username or password authentication. This functionality is enabled as a convenience, and to assist local users running Management CLI scripts without requiring authentication. It is considered a useful feature given that access to the local configuration typically also gives the user the ability to add their own user details or otherwise disable security checks.

The convenience of silent authentication for local users can be disabled where greater security control is required. This can be achieved by removing the local element within the security-realm section of the configuration file. This applies to both the standalone instances as well as domains.

Important

The removal of the local element should only be done if the impact on the JBoss EAP 6 instance and its configuration is fully understood.

To remove silent authentication from a realm: 

/core-service=management/security-realm=REALM_NAME/authentication=local:remove

2.3. Security Auditing

Security auditing refers to triggering events, such as writing to a log, in response to an event that happens within the security subsystem or the management interfaces. Auditing mechanisms are configured as part of a security domain or management interface.

Auditing uses provider modules. Both included provider modules as well as custom implementations may be used.

2.3.1. Configure Security Auditing for the Management Interfaces

For more information on configuring auditing for the management interfaces, refer to the Management Interface Audit Logging section of the Red Hat JBoss Enterprise Application Platform 6 Administration and Configuration Guide.

2.3.2. Configure Security Auditing for Security Domains

To configure security auditing settings for a security domain, the following steps must be performed from the management console:

  1. Open the security domain’s detailed view.
  2. Navigate to the Auditing subsystem configuration.
  3. Add a provider module.
  4. Verify the module is working
  5. Optional: Add, edit, or remove module options.

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.
  • Expand the Security menu and select Security Domains.
  • Click View for the security domain to edit.

2. Navigate to the Auditing subsystem configuration.

Select the Audit tab at the top 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.

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 6 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.