Chapter 4. Endpoint authentication mechanisms

Data Grid Server can use custom SASL and HTTP authentication mechanisms for Hot Rod and REST endpoints.

4.1. Data Grid Server authentication

Authentication restricts user access to endpoints as well as the Data Grid Console and Command Line Interface (CLI).

Data Grid Server includes a "default" security realm that enforces user authentication. Default authentication uses a property realm with user credentials stored in the server/conf/users.properties file. Data Grid Server also enables security authorization by default so you must assign users with permissions stored in the server/conf/groups.properties file.

Tip

Use the user create command with the Command Line Interface (CLI) to add users and assign permissions. Run user create --help for examples and more information.

4.2. Configuring Data Grid Server authentication mechanisms

You can explicitly configure Hot Rod and REST endpoints to use specific authentication mechanisms. Configuring authentication mechanisms is required only if you need to explicitly override the default mechanisms for a security realm.

Note

Each endpoint section in your configuration must include hotrod-connector and rest-connector elements or fields. For example, if you explicitly declare a hotrod-connector you must also declare a rest-connector even if it does not configure an authentication mechanism.

Prerequisites

Add security realms to your Data Grid Server configuration as required.

Procedure

Open your Data Grid Server configuration for editing.
Add an endpoint element or field and specify the security realm that it uses with the security-realm attribute.
Add a hotrod-connector element or field to configure the Hot Rod endpoint.
1. Add an authentication element or field.
2. Specify SASL authentication mechanisms for the Hot Rod endpoint to use with the sasl mechanisms attribute.
3. If applicable, specify SASL quality of protection settings with the qop attribute.
4. Specify the Data Grid Server identity with the server-name attribute if necessary.
Add a rest-connector element or field to configure the REST endpoint.
1. Add an authentication element or field.
2. Specify HTTP authentication mechanisms for the REST endpoint to use with the mechanisms attribute.
Save the changes to your configuration.

Authentication mechanism configuration

The following configuration specifies SASL mechanisms for the Hot Rod endpoint to use for authentication:

XML

<server xmlns="urn:infinispan:server:14.0">
  <endpoints>
    <endpoint socket-binding="default"
              security-realm="my-realm">
      <hotrod-connector>
        <authentication>
           <sasl mechanisms="SCRAM-SHA-512 SCRAM-SHA-384 SCRAM-SHA-256
                             SCRAM-SHA-1 DIGEST-SHA-512 DIGEST-SHA-384
                             DIGEST-SHA-256 DIGEST-SHA DIGEST-MD5 PLAIN"
                 server-name="infinispan"
                 qop="auth"/>
        </authentication>
      </hotrod-connector>
      <rest-connector>
        <authentication mechanisms="DIGEST BASIC"/>
      </rest-connector>
    </endpoint>
  </endpoints>
</server>

JSON

{
  "server": {
    "endpoints": {
      "endpoint": {
        "socket-binding": "default",
        "security-realm": "my-realm",
        "hotrod-connector": {
          "authentication": {
            "security-realm": "default",
            "sasl": {
              "server-name": "infinispan",
              "mechanisms": ["SCRAM-SHA-512", "SCRAM-SHA-384", "SCRAM-SHA-256", "SCRAM-SHA-1", "DIGEST-SHA-512", "DIGEST-SHA-384", "DIGEST-SHA-256", "DIGEST-SHA", "DIGEST-MD5", "PLAIN"],
              "qop": ["auth"]
            }
          }
        },
        "rest-connector": {
          "authentication": {
            "mechanisms": ["DIGEST", "BASIC"],
            "security-realm": "default"
          }
        }
      }
    }
  }
}

YAML

server:
  endpoints:
    endpoint:
      socketBinding: "default"
      securityRealm: "my-realm"
      hotrodConnector:
        authentication:
          securityRealm: "default"
          sasl:
            serverName: "infinispan"
            mechanisms:
              - "SCRAM-SHA-512"
              - "SCRAM-SHA-384"
              - "SCRAM-SHA-256"
              - "SCRAM-SHA-1"
              - "DIGEST-SHA-512"
              - "DIGEST-SHA-384"
              - "DIGEST-SHA-256"
              - "DIGEST-SHA"
              - "DIGEST-MD5"
              - "PLAIN"
            qop:
              - "auth"
      restConnector:
        authentication:
          mechanisms:
            - "DIGEST"
            - "BASIC"
          securityRealm: "default"

4.2.1. Disabling authentication

In local development environments or on isolated networks you can configure Data Grid to allow unauthenticated client requests. When you disable user authentication you should also disable authorization in your Data Grid security configuration.

Procedure

Open your Data Grid Server configuration for editing.
Remove the security-realm attribute from the endpoints element or field.
Remove any authorization elements from the security configuration for the cache-container and each cache configuration.
Save the changes to your configuration.

XML

<server xmlns="urn:infinispan:server:14.0">
  <endpoints socket-binding="default"/>
</server>

JSON

{
  "server": {
    "endpoints": {
      "endpoint": {
        "socket-binding": "default"
      }
    }
  }
}

YAML

server:
  endpoints:
    endpoint:
      socketBinding: "default"

4.3. Data Grid Server authentication mechanisms

Data Grid Server automatically configures endpoints with authentication mechanisms that match your security realm configuration. For example, if you add a Kerberos security realm then Data Grid Server enables the GSSAPI and GS2-KRB5 authentication mechanisms for the Hot Rod endpoint.

Important

Currently, you cannot use the Lightweight Directory Access Protocol (LDAP) protocol with the DIGEST or SCRAM authentication mechanisms, because these mechanisms require access to specific hashed passwords.

Hot Rod endpoints

Data Grid Server enables the following SASL authentication mechanisms for Hot Rod endpoints when your configuration includes the corresponding security realm:

Security realm	SASL authentication mechanism
Property realms and LDAP realms	`SCRAM`, `DIGEST`
Token realms	`OAUTHBEARER`
Trust realms	`EXTERNAL`
Kerberos identities	`GSSAPI`, `GS2-KRB5`
SSL/TLS identities	`PLAIN`

REST endpoints

Data Grid Server enables the following HTTP authentication mechanisms for REST endpoints when your configuration includes the corresponding security realm:

Security realm	HTTP authentication mechanism
Property realms and LDAP realms	`DIGEST`
Token realms	`BEARER_TOKEN`
Trust realms	`CLIENT_CERT`
Kerberos identities	`SPNEGO`
SSL/TLS identities	`BASIC`

Memcached endpoints

Data Grid Server enables the following SASL authentication mechanisms for Memcached binary protocol endpoints when your configuration includes the corresponding security realm:

Security realm	SASL authentication mechanism
Property realms and LDAP realms	`SCRAM`, `DIGEST`
Token realms	`OAUTHBEARER`
Trust realms	`EXTERNAL`
Kerberos identities	`GSSAPI, GS2-KRB5`
SSL/TLS identities	`PLAIN`

Data Grid Server enables authentication on Memcached text protocol endpoints only with security realms which support password-based authentication:

Security realm	Memcached text authentication
Property realms and LDAP realms	Yes
Token realms	No
Trust realms	No
Kerberos identities	No
SSL/TLS identities	No

RESP endpoints

Data Grid Server enables authentication on RESP endpoints only with security realms which support password-based authentication:

Security realm	RESP authentication
Property realms and LDAP realms	Yes
Token realms	No
Trust realms	No
Kerberos identities	No
SSL/TLS identities	No

4.3.1. SASL authentication mechanisms

Data Grid Server supports the following SASL authentications mechanisms with Hot Rod and Memcached binary protocol endpoints:

Authentication mechanism	Description	Security realm type	Related details
`PLAIN`	Uses credentials in plain-text format. You should use `PLAIN` authentication with encrypted connections only.	Property realms and LDAP realms	Similar to the `BASIC` HTTP mechanism.
`DIGEST-*`	Uses hashing algorithms and nonce values. Hot Rod connectors support `DIGEST-MD5`, `DIGEST-SHA`, `DIGEST-SHA-256`, `DIGEST-SHA-384`, and `DIGEST-SHA-512` hashing algorithms, in order of strength.	Property realms and LDAP realms	Similar to the `Digest` HTTP mechanism.
`SCRAM-*`	Uses salt values in addition to hashing algorithms and nonce values. Hot Rod connectors support `SCRAM-SHA`, `SCRAM-SHA-256`, `SCRAM-SHA-384`, and `SCRAM-SHA-512` hashing algorithms, in order of strength.	Property realms and LDAP realms	Similar to the `Digest` HTTP mechanism.
`GSSAPI`	Uses Kerberos tickets and requires a Kerberos Domain Controller. You must add a corresponding `kerberos` server identity in the realm configuration. In most cases, you also specify an `ldap-realm` to provide user membership information.	Kerberos realms	Similar to the `SPNEGO` HTTP mechanism.
`GS2-KRB5`	Uses Kerberos tickets and requires a Kerberos Domain Controller. You must add a corresponding `kerberos` server identity in the realm configuration. In most cases, you also specify an `ldap-realm` to provide user membership information.	Kerberos realms	Similar to the `SPNEGO` HTTP mechanism.
`EXTERNAL`	Uses client certificates.	Trust store realms	Similar to the `CLIENT_CERT` HTTP mechanism.
`OAUTHBEARER`	Uses OAuth tokens and requires a `token-realm` configuration.	Token realms	Similar to the `BEARER_TOKEN` HTTP mechanism.

4.3.2. SASL quality of protection (QoP)

If SASL mechanisms support integrity and privacy protection (QoP) settings, you can add them to your Hot Rod and Memcached endpoint configuration with the qop attribute.

QoP setting	Description
`auth`	Authentication only.
`auth-int`	Authentication with integrity protection.
`auth-conf`	Authentication with integrity and privacy protection.

4.3.3. SASL policies

SASL policies provide fine-grain control over Hot Rod and Memcached authentication mechanisms.

Tip

Data Grid cache authorization restricts access to caches based on roles and permissions. Configure cache authorization and then set <no-anonymous value=false /> to allow anonymous login and delegate access logic to cache authorization.

Policy	Description	Default value
`forward-secrecy`	Use only SASL mechanisms that support forward secrecy between sessions. This means that breaking into one session does not automatically provide information for breaking into future sessions.	false
`pass-credentials`	Use only SASL mechanisms that require client credentials.	false
`no-plain-text`	Do not use SASL mechanisms that are susceptible to simple plain passive attacks.	false
`no-active`	Do not use SASL mechanisms that are susceptible to active, non-dictionary, attacks.	false
`no-dictionary`	Do not use SASL mechanisms that are susceptible to passive dictionary attacks.	false
`no-anonymous`	Do not use SASL mechanisms that accept anonymous logins.	true

SASL policy configuration

In the following configuration the Hot Rod endpoint uses the GSSAPI mechanism for authentication because it is the only mechanism that complies with all SASL policies:

XML

<server xmlns="urn:infinispan:server:14.0">
  <endpoints>
    <endpoint socket-binding="default"
              security-realm="default">
      <hotrod-connector>
        <authentication>
          <sasl mechanisms="PLAIN DIGEST-MD5 GSSAPI EXTERNAL"
                server-name="infinispan"
                qop="auth"
                policy="no-active no-plain-text"/>
        </authentication>
      </hotrod-connector>
      <rest-connector/>
    </endpoint>
  </endpoints>
</server>

JSON

{
  "server": {
    "endpoints" : {
      "endpoint" : {
        "socket-binding" : "default",
        "security-realm" : "default",
        "hotrod-connector" : {
          "authentication" : {
            "sasl" : {
              "server-name" : "infinispan",
              "mechanisms" : [ "PLAIN","DIGEST-MD5","GSSAPI","EXTERNAL" ],
              "qop" : [ "auth" ],
              "policy" : [ "no-active","no-plain-text" ]
            }
          }
        },
        "rest-connector" : ""
      }
    }
  }
}

YAML

server:
  endpoints:
    endpoint:
      socketBinding: "default"
      securityRealm: "default"
      hotrodConnector:
        authentication:
          sasl:
            serverName: "infinispan"
            mechanisms:
              - "PLAIN"
              - "DIGEST-MD5"
              - "GSSAPI"
              - "EXTERNAL"
            qop:
              - "auth"
            policy:
              - "no-active"
              - "no-plain-text"
      restConnector: ~

4.3.4. HTTP authentication mechanisms

Data Grid Server supports the following HTTP authentication mechanisms with REST endpoints:

Authentication mechanism	Description	Security realm type	Related details
`BASIC`	Uses credentials in plain-text format. You should use `BASIC` authentication with encrypted connections only.	Property realms and LDAP realms	Corresponds to the `Basic` HTTP authentication scheme and is similar to the `PLAIN` SASL mechanism.
`DIGEST`	Uses hashing algorithms and nonce values. REST connectors support `SHA-512`, `SHA-256` and `MD5` hashing algorithms.	Property realms and LDAP realms	Corresponds to the `Digest` HTTP authentication scheme and is similar to `DIGEST-*` SASL mechanisms.
`SPNEGO`	Uses Kerberos tickets and requires a Kerberos Domain Controller. You must add a corresponding `kerberos` server identity in the realm configuration. In most cases, you also specify an `ldap-realm` to provide user membership information.	Kerberos realms	Corresponds to the `Negotiate` HTTP authentication scheme and is similar to the `GSSAPI` and `GS2-KRB5` SASL mechanisms.
`BEARER_TOKEN`	Uses OAuth tokens and requires a `token-realm` configuration.	Token realms	Corresponds to the `Bearer` HTTP authentication scheme and is similar to `OAUTHBEARER` SASL mechanism.
`CLIENT_CERT`	Uses client certificates.	Trust store realms	Similar to the `EXTERNAL` SASL mechanism.

Chapter 4. Endpoint authentication mechanisms

4.1. Data Grid Server authentication

4.2. Configuring Data Grid Server authentication mechanisms

Authentication mechanism configuration

4.2.1. Disabling authentication

4.3. Data Grid Server authentication mechanisms

4.3.1. SASL authentication mechanisms

4.3.2. SASL quality of protection (QoP)

4.3.3. SASL policies

SASL policy configuration

4.3.4. HTTP authentication mechanisms

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links