25.9. Securing Interfaces

25.9.1. Hot Rod Interface Security

25.9.1.1. Publish Hot Rod Endpoints as a Public Interface

Red Hat JBoss Data Grid's Hot Rod server operates as a management interface as a default. To extend its operations to a public interface, alter the value of the interface parameter in the socket-binding element from management to public as follows:
<socket-binding name="hotrod" interface="public" port="11222" />

25.9.1.2. Encryption of communication between Hot Rod Server and Hot Rod client

Hot Rod can be encrypted using TLS/SSL, and has the option to require certificate-based client authentication.
Use the following procedure to secure the Hot Rod connector using SSL.

Procedure 25.3. Secure Hot Rod Using SSL/TLS

  1. Generate a Keystore

    Create a Java Keystore using the keytool application distributed with the JDK and add your certificate to it. The certificate can be either self signed, or obtained from a trusted CA depending on your security policy.
  2. Place the Keystore in the Configuration Directory

    Put the keystore in the ~/JDG_HOME/standalone/configuration directory with the standalone-hotrod-ssl.xml file from the ~/JDG_HOME/docs/examples/configs directory.
  3. Declare an SSL Server Identity

    Declare an SSL server identity within a security realm in the management section of the configuration file. The SSL server identity must specify the path to a keystore and its secret key.
    <server-identities>
      <ssl protocol="...">
        <keystore path="..." relative-to="..." keystore-password="${VAULT::VAULT_BLOCK::ATTRIBUTE_NAME::ENCRYPTED_VALUE}" />
      </ssl>
      <secret value="..." />
    </server-identities>
  4. Add the Security Element

    Add the security element to the Hot Rod connector as follows:
    <hotrod-connector socket-binding="hotrod" cache-container="local">
        <encryption ssl="true" security-realm="ApplicationRealm" require-ssl-client-auth="false" />
    </hotrod-connector>
    1. Server Authentication of Certificate

      If you require the server to perform authentication of the client certificate, create a truststore that contains the valid client certificates and set the require-ssl-client-auth attribute to true.
  5. Start the Server

    Start the server using the following:
    bin/standalone.sh -c standalone-hotrod-ssl.xml
    This will start a server with a Hot Rod endpoint on port 11222. This endpoint will only accept SSL connections.

Important

To prevent plain text passwords from appearing in configurations or source codes, plain text passwords should be changed to Vault passwords. For more information about how to set up Vault passwords, see the Red Hat Enterprise Application Platform Security Guide.

25.9.1.3. Securing Hot Rod to LDAP Server using SSL

When connecting to an LDAP server with SSL enabled it may be necessary to specify a trust store or key store containing the appropriate certificates.
Section 25.9.1.2, “Encryption of communication between Hot Rod Server and Hot Rod client” describes how to set up SSL for Hot Rod client-server communication. This can be used, for example, for secure Hot Rod client authentication with PLAIN username/password. When the username/password is checked against credentials in LDAP, a secure connection from the Hot Rod server to the LDAP server is also required. To enable connection from the Hot Rod server to LDAP via SSL, a security realm must be defined as follows:

Example 25.12. Hot Rod Client Authentication to LDAP Server

<management>  
        <security-realms>  
            <security-realm name="LdapSSLRealm">  
                <authentication>  
                    <truststore  path="ldap.truststore" relative-to="jboss.server.config.dir" keystore-password=${VAULT::VAULT_BLOCK::ATTRIBUTE_NAME::ENCRYPTED_VALUE} />  
                </authentication>  
            </security-realm>  
        </security-realms>  
        <outbound-connections>  
            <ldap name="LocalLdap" url="ldaps://localhost:10389" search-dn="uid=wildfly,dc=simple,dc=wildfly,dc=org" search-credential="secret" security-realm="LdapSSLRealm" />  
        </outbound-connections>  
    </management>

Important

To prevent plain text passwords from appearing in configurations or source codes, plain text passwords should be changed to Vault passwords. For more information about how to set up Vault passwords, see the Red Hat Enterprise Application Platform Security Guide.

25.9.1.4. User Authentication over Hot Rod Using SASL

User authentication over Hot Rod can be implemented using the following Simple Authentication and Security Layer (SASL) mechanisms:
  • PLAIN is the least secure mechanism because credentials are transported in plain text format. However, it is also the simplest mechanism to implement. This mechanism can be used in conjunction with encryption (SSL) for additional security.
  • DIGEST-MD5 is a mechanism than hashes the credentials before transporting them. As a result, it is more secure than the PLAIN mechanism.
  • GSSAPI is a mechanism that uses Kerberos tickets. As a result, it requires a correctly configured Kerberos Domain Controller (for example, Microsoft Active Directory).
  • EXTERNAL is a mechanism that obtains the required credentials from the underlying transport (for example, from a X.509 client certificate) and therefore requires client certificate encryption to work correctly.
25.9.1.4.1. Configure Hot Rod Authentication (GSSAPI/Kerberos)
Use the following steps to set up Hot Rod Authentication using the SASL GSSAPI/Kerberos mechanism:

Procedure 25.4. Configure SASL GSSAPI/Kerberos Authentication - Server-side Configuration

  1. Define a Kerberos security login module using the security domain subsystem:
    <system-properties>
        <property name="java.security.krb5.conf" value="/tmp/infinispan/krb5.conf"/>
        <property name="java.security.krb5.debug" value="true"/>
        <property name="jboss.security.disable.secdomain.option" value="true"/>
    </system-properties>
    
    <security-domain name="infinispan-server" cache-type="default">
        <authentication>
            <login-module code="Kerberos" flag="required">
                <module-option name="debug" value="true"/>
                <module-option name="storeKey" value="true"/>
                <module-option name="refreshKrb5Config" value="true"/>
                <module-option name="useKeyTab" value="true"/>
                <module-option name="doNotPrompt" value="true"/>
                <module-option name="keyTab" value="/tmp/infinispan/infinispan.keytab"/>
                <module-option name="principal" value="HOTROD/localhost@INFINISPAN.ORG"/>
            </login-module>
        </authentication>
    </security-domain>
  2. Ensure that the cache-container has authorization roles defined, and these roles are applied in the cache's authorization block as seen in Section 25.5, “Configuring Red Hat JBoss Data Grid for Authorization”.
  3. Configure a Hot Rod connector as follows:
    <hotrod-connector socket-binding="hotrod" 
    		  cache-container="default">
    	<authentication security-realm="ApplicationRealm">
    		<sasl server-name="node0" 
    		      mechanisms="{mechanism_name}" 
    		      qop="{qop_name}" 
    		      strength="{value}">
    			<policy>
    				<no-anonymous value="true" />
    			</policy>
    			<property name="com.sun.security.sasl.digest.utf8">true</property>
    		</sasl>
      </authentication>
    </hotrod-connector>
    • The server-name attribute specifies the name that the server declares to incoming clients. The client configuration must also contain the same server name value.
    • The server-context-name attribute specifies the name of the login context used to retrieve a server subject for certain SASL mechanisms (for example, GSSAPI).
    • The mechanisms attribute specifies the authentication mechanism in use. See Section 25.9.1.4, “User Authentication over Hot Rod Using SASL” for a list of supported mechanisms.
    • The qop attribute specifies the SASL quality of protection value for the configuration. Supported values for this attribute are auth (authentication), auth-int (authentication and integrity, meaning that messages are verified against checksums to detect tampering), and auth-conf (authentication, integrity, and confidentiality, meaning that messages are also encrypted). Multiple values can be specified, for example, auth-int auth-conf. The ordering implies preference, so the first value which matches both the client and server's preference is chosen.
    • The strength attribute specifies the SASL cipher strength. Valid values are low, medium, and high.
    • The no-anonymous element within the policy element specifies whether mechanisms that accept anonymous login are permitted. Set this value to false to permit and true to deny.
  4. Perform the Client-Side configuration on each client. As the Hot Rod client is configured programmatically information on this configuration is found in the JBoss Data Grid Developer Guide.
25.9.1.4.2. Configure Hot Rod Authentication (MD5)
Use the following steps to set up Hot Rod Authentication using the SASL using the MD5 mechanism:

Procedure 25.5. Configure Hot Rod Authentication (MD5)

  1. Set up the Hot Rod Connector configuration by adding the sasl element to the authentication element (for details on the authentication element, see Section 25.8.4, “Configuring Security Realms Declaratively”) as follows:
    <hotrod-connector socket-binding="hotrod" 
                                cache-container="default">
        <authentication security-realm="ApplicationRealm">
            <sasl server-name="myhotrodserver" 
                     mechanisms="DIGEST-MD5" 
                     qop="auth" />
        </authentication>
    </hotrod-connector>
    • The server-name attribute specifies the name that the server declares to incoming clients. The client configuration must also contain the same server name value.
    • The mechanisms attribute specifies the authentication mechanism in use. See Section 25.9.1.4, “User Authentication over Hot Rod Using SASL” for a list of supported mechanisms.
    • The qop attribute specifies the SASL quality of production value for the configuration. Supported values for this attribute are auth, auth-int, and auth-conf.
  2. Configure each client to be connected to the Hot Rod connector. As this step is performed programmatically instructions are found in JBoss Data Grid's Developer Guide.
25.9.1.4.3. Configure Hot Rod Using LDAP/Active Directory
Use the following to configure authentication over Hot Rod using LDAP or Microsoft Active Directory:
<security-realms>
	<security-realm name="ApplicationRealm">
		<authentication>
			<ldap connection="ldap_connection" 
			      recursive="true" 
			      base-dn="cn=users,dc=infinispan,dc=org">
				<username-filter attribute="cn" />
			</ldap>
		</authentication>
	</security-realm>
</security-realms>
<outbound-connections>
	<ldap name="ldap_connection" 
	      url="ldap://my_ldap_server" 
	      search-dn="CN=test,CN=Users,DC=infinispan,DC=org" 
	      search-credential="Test_password"/>
</outbound-connections>
The following are some details about the elements and parameters used in this configuration:
  • The security-realm element's name parameter specifies the security realm to reference to use when establishing the connection.
  • The authentication element contains the authentication details.
  • The ldap element specifies how LDAP searches are used to authenticate a user. First, a connection to LDAP is established and a search is conducted using the supplied user name to identify the distinguished name of the user. A subsequent connection to the server is established using the password supplied by the user. If the second connection succeeds, the authentication is a success.
    • The connection parameter specifies the name of the connection to use to connect to LDAP.
    • The (optional) recursive parameter specifies whether the filter is executed recursively. The default value for this parameter is false.
    • The base-dn parameter specifies the distinguished name of the context to use to begin the search from.
    • The (optional) user-dn parameter specifies which attribute to read for the user's distinguished name after the user is located. The default value for this parameter is dn.
  • The outbound-connections element specifies the name of the connection used to connect to the LDAP. directory.
  • The ldap element specifies the properties of the outgoing LDAP connection.
    • The name parameter specifies the unique name used to reference this connection.
    • The url parameter specifies the URL used to establish the LDAP connection.
    • The search-dn parameter specifies the distinguished name of the user to authenticate and to perform the searches.
    • The search-credential parameter specifies the password required to connect to LDAP as the search-dn.
    • The (optional) initial-context-factory parameter allows the overriding of the initial context factory. the default value of this parameter is com.sun.jndi.ldap.LdapCtxFactory.
25.9.1.4.4. Configure Hot Rod Authentication (X.509)
The X.509 certificate can be installed at the node, and be made available to other nodes for authentication purposes for inbound and outbound SSL connections. This is enabled using the <server-identities/> element of a security realm definition, which defines how a server appears to external applications. This element can be used to configure a password to be used when establishing a remote connection, as well as the loading of an X.509 key.
The following example shows how to install an X.509 certificate on the node.
<security-realm name="ApplicationRealm">
  <server-identities>
    <ssl protocol="...">
      <keystore path="..." relative-to="..." keystore-password="..." alias="..." key-password="..." />
    </ssl>
  </server-identities>

  [... authentication/authorization ...]

 </security-realms>
In the provided example, the SSL element contains the <keystore/> element, which is used to define how to load the key from the file-based keystore. The following parameters ave available for this element.

Table 25.4. <server-identities/> Options

Parameter Mandatory/Optional Description
path Mandatory This is the path to the keystore, this can be an absolute path or relative to the next attribute.
relative-to Optional The name of a service representing a path the keystore is relative to.
keystore-password Mandatory The password required to open the keystore.
alias Optional The alias of the entry to use from the keystore - for a keystore with multiple entries in practice the first usable entry is used but this should not be relied on and the alias should be set to guarantee which entry is used.
key-password Optional The password to load the key entry, if omitted the keystore-password will be used instead.

Note

If the following error occurs, specify a key-password as well as an alias to ensure only one key is loaded.
UnrecoverableKeyException: Cannot recover key

25.9.2. REST Interface Security

25.9.2.1. Publish REST Endpoints as a Public Interface

Red Hat JBoss Data Grid's REST server operates as a management interface by default. To extend its operations to a public interface, alter the value of the interface parameter in the socket-binding element from management to public as follows:
<socket-binding name="http" 
		interface="public" 
		port="8080"/>

25.9.2.2. Enable Security for the REST Endpoint

Use the following procedure to enable security for the REST endpoint in Red Hat JBoss Data Grid.

Note

The REST endpoint supports any of the JBoss Enterprise Application Platform security subsystem providers.

Procedure 25.6. Enable Security for the REST Endpoint

To enable security for JBoss Data Grid when using the REST interface, make the following changes to standalone.xml:
  1. Specify Security Parameters

    Ensure that the rest endpoint specifies a valid value for the authentication. An example configuration is below::
    <subsystem xmlns="urn:infinispan:server:endpoint:8.1">
        <rest-connector socket-binding="rest" cache-container="security">
            <authentication security-realm="ApplicationRealm" auth-method="BASIC"/>
        </rest-connector>
    </subsystem>
  2. Check Security Domain Declaration

    Ensure that the security subsystem contains the corresponding security-domain declaration. For details about setting up security-domain declarations, see the JBoss Enterprise Application Platform 7 documentation.
  3. Add an Application User

    Run the relevant script and enter the configuration settings to add an application user.
    1. Run the adduser.sh script (located in $JDG_HOME/bin).
      • On a Windows system, run the adduser.bat file (located in $JDG_HOME/bin) instead.
    2. When prompted about the type of user to add, select Application User (application-users.properties) by entering b.
    3. Accept the default value for realm (ApplicationRealm) by pressing the return key.
    4. Specify a username and password.
    5. When prompted for a group, enter REST.
    6. Ensure the username and application realm information is correct when prompted and enter "yes" to continue.
  4. Verify the Created Application User

    Ensure that the created application user is correctly configured.
    1. Check the configuration listed in the application-users.properties file (located in $JDG_HOME/standalone/configuration/). The following is an example of what the correct configuration looks like in this file:
      user1=2dc3eacfed8cf95a4a31159167b936fc
    2. Check the configuration listed in the application-roles.properties file (located in $JDG_HOME/standalone/configuration/). The following is an example of what the correct configuration looks like in this file:
      user1=REST
  5. Test the Server

    Start the server and enter the following link in a browser window to access the REST endpoint:
    http://localhost:8080/rest/namedCache

    Note

    If testing using a GET request, a 405 response code is expected and indicates that the server was successfully authenticated.

25.9.3. Memcached Interface Security

25.9.3.1. Publish Memcached Endpoints as a Public Interface

Red Hat JBoss Data Grid's memcached server operates as a management interface by default. It is possible to extend the memcached operations to a public interface, but there is no additional security available for this interface. If security is a concern then it is recommended to keep this interface on an isolated, internal network, or to use either the REST or Hot Rod interfaces.
To configure the memcached interface as a public interface, alter the value of the interface parameter in the socket-binding element from management to public as follows:
<socket-binding name="memcached" 
		interface="public" 
		port="11211" />