25.9. Securing Interfaces
25.9.1. Hot Rod Interface Security
25.9.1.1. Publish Hot Rod Endpoints as a Public Interface
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
Procedure 25.3. Secure Hot Rod Using SSL/TLS
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.Place the Keystore in the Configuration Directory
Put the keystore in the~/JDG_HOME/standalone/configuration
directory with thestandalone-hotrod-ssl.xml
file from the~/JDG_HOME/docs/examples/configs
directory.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>
See Section 25.9.1.4.4, “Configure Hot Rod Authentication (X.509)” for details about these parameters.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>
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 therequire-ssl-client-auth
attribute totrue
.
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
25.9.1.3. Securing Hot Rod to LDAP Server using SSL
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
25.9.1.4. User Authentication over Hot Rod Using SASL
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 thePLAIN
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 aX.509
client certificate) and therefore requires client certificate encryption to work correctly.
25.9.1.4.1. Configure Hot Rod Authentication (GSSAPI/Kerberos)
Procedure 25.4. Configure SASL GSSAPI/Kerberos Authentication - Server-side Configuration
- 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>
- 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”.
- 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 areauth
(authentication),auth-int
(authentication and integrity, meaning that messages are verified against checksums to detect tampering), andauth-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 arelow
,medium
, andhigh
. - The
no-anonymous
element within thepolicy
element specifies whether mechanisms that accept anonymous login are permitted. Set this value tofalse
to permit andtrue
to deny.
- 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)
Procedure 25.5. Configure Hot Rod Authentication (MD5)
- Set up the Hot Rod Connector configuration by adding the
sasl
element to theauthentication
element (for details on theauthentication
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 areauth
,auth-int
, andauth-conf
.
- 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
<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
security-realm
element'sname
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 isfalse
. - 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 isdn
.
- 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 thesearch-dn
. - The (optional)
initial-context-factory
parameter allows the overriding of the initial context factory. the default value of this parameter iscom.sun.jndi.ldap.LdapCtxFactory
.
25.9.1.4.4. Configure Hot Rod Authentication (X.509)
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.
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>
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
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
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
Note
Procedure 25.6. Enable Security for the REST Endpoint
standalone.xml
:
Specify Security Parameters
Ensure that the rest endpoint specifies a valid value for theauthentication
. 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>
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.Add an Application User
Run the relevant script and enter the configuration settings to add an application user.- 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.
- When prompted about the type of user to add, select
Application User (application-users.properties)
by enteringb
. - Accept the default value for realm (
ApplicationRealm
) by pressing the return key. - Specify a username and password.
- When prompted for a group, enter
REST
. - Ensure the username and application realm information is correct when prompted and enter "yes" to continue.
Verify the Created Application User
Ensure that the created application user is correctly configured.- 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
- 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
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, a405
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
interface
parameter in the socket-binding
element from management
to public
as follows:
<socket-binding name="memcached" interface="public" port="11211" />