Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 3. Endpoint authentication mechanisms
Data Grid Server can use custom SASL and HTTP authentication mechanisms for Hot Rod and REST endpoints.
3.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.
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.
3.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.
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 thesecurity-realm
attribute. Add a
hotrod-connector
element or field to configure the Hot Rod endpoint.-
Add an
authentication
element or field. -
Specify SASL authentication mechanisms for the Hot Rod endpoint to use with the
sasl mechanisms
attribute. -
If applicable, specify SASL quality of protection settings with the
qop
attribute. -
Specify the Data Grid Server identity with the
server-name
attribute if necessary.
-
Add an
Add a
rest-connector
element or field to configure the REST endpoint.-
Add an
authentication
element or field. -
Specify HTTP authentication mechanisms for the REST endpoint to use with the
mechanisms
attribute.
-
Add an
- 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"
3.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 theendpoints
element or field. -
Remove any
authorization
elements from thesecurity
configuration for thecache-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"
3.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.
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 |
3.3.1. SASL authentication mechanisms
Data Grid Server supports the following SASL authentications mechanisms with Hot Rod endpoints:
Authentication mechanism | Description | Security realm type | Related details |
---|---|---|---|
|
Uses credentials in plain-text format. You should use | Property realms and LDAP realms |
Similar to the |
|
Uses hashing algorithms and nonce values. Hot Rod connectors support | Property realms and LDAP realms |
Similar to the |
|
Uses salt values in addition to hashing algorithms and nonce values. Hot Rod connectors support | Property realms and LDAP realms |
Similar to the |
|
Uses Kerberos tickets and requires a Kerberos Domain Controller. You must add a corresponding | Kerberos realms |
Similar to the |
|
Uses Kerberos tickets and requires a Kerberos Domain Controller. You must add a corresponding | Kerberos realms |
Similar to the |
| Uses client certificates. | Trust store realms |
Similar to the |
|
Uses OAuth tokens and requires a | Token realms |
Similar to the |
3.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 endpoint configuration with the qop
attribute.
QoP setting | Description |
---|---|
| Authentication only. |
| Authentication with integrity protection. |
| Authentication with integrity and privacy protection. |
3.3.3. SASL policies
SASL policies provide fine-grain control over Hot Rod authentication mechanisms.
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 |
---|---|---|
| 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 |
| Use only SASL mechanisms that require client credentials. | false |
| Do not use SASL mechanisms that are susceptible to simple plain passive attacks. | false |
| Do not use SASL mechanisms that are susceptible to active, non-dictionary, attacks. | false |
| Do not use SASL mechanisms that are susceptible to passive dictionary attacks. | false |
| 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: ~
3.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 |
---|---|---|---|
|
Uses credentials in plain-text format. You should use | Property realms and LDAP realms |
Corresponds to the |
|
Uses hashing algorithms and nonce values. REST connectors support | Property realms and LDAP realms |
Corresponds to the |
|
Uses Kerberos tickets and requires a Kerberos Domain Controller. You must add a corresponding | Kerberos realms |
Corresponds to the |
|
Uses OAuth tokens and requires a | Token realms |
Corresponds to the |
| Uses client certificates. | Trust store realms |
Similar to the |