Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 6. Securing Data Grid Servers

Protect Data Grid servers against network attacks and unauthorized access.

6.1. Cache Authorization
Copia collegamento

Data Grid can restrict access to data by authorizing requests to perform cache operations.

Data Grid maps identities, or Principals of type java.security.Principal, to security roles in your configuration. For example, a Principal named reader maps to a security role named reader.

Data Grid lets you assign permissions to the various roles to authorize cache operations. For example, Cache.get() requires read permission while Cache.put() requires write permission.

In this case, iff a client with the reader role attempts to write an entry, Data Grid denies the request and throws a security exception. However, if a client with the writer role sends a write request, Data Grid validates authorization and issues the client with a token for subsequent operations.

6.1.1. Cache Authorization Configuration
Copia collegamento

Data Grid configuration for cache authorization is as follows: 

<infinispan>
   <cache-container default-cache="secured" name="secured">
      <security>
         <authorization>
1 

            <identity-role-mapper />
2 

            <role name="admin" permissions="ALL" />
3 

            <role name="reader" permissions="READ" />
            <role name="writer" permissions="WRITE" />
            <role name="supervisor" permissions="READ WRITE EXEC"/>
         </authorization>
      </security>
      <local-cache name="secured">
         <security>
            <authorization roles="admin reader writer supervisor" />
4 

         </security>
      </local-cache>
   </cache-container>

</infinispan>
Copy to Clipboard Toggle word wrap
1
configures cache authorization for the cache container.
2
specifies an implementation of PrincipalRoleMapper that converts Principal names to roles.
3
names roles and assigns permissions that control access to data.
4
defines the authorized roles for the cache.

Reference

6.2. Defining Data Grid Server Security Realms
Copia collegamento

Security realms provide identity, encryption, authentication, and authorization information to Data Grid server endpoints.

6.2.1. Property Realms
Copia collegamento

Property realms use property files to define users and groups.

users.properties maps usernames to passwords in plain-text format. Passwords can also be pre-digested if you use the DIGEST-MD5 SASL mechanism or Digest HTTP mechanism. 

myuser=a_password
user2=another_password
Copy to Clipboard Toggle word wrap

groups.properties maps users to roles. 

supervisor=myuser,user2
reader=myuser
writer=myuser
Copy to Clipboard Toggle word wrap

Property realm configuration

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <properties-realm groups-attribute="Roles">
1 

            <user-properties path="users.properties"
2 

                             relative-to="infinispan.server.config.path"
3 

                             plain-text="true"/>
4 

            <group-properties path="groups.properties"
5 

                              relative-to="infinispan.server.config.path"/>
         </properties-realm>
      </security-realm>
   </security-realms>
</security>
Copy to Clipboard Toggle word wrap

1
Defines groups as roles for Data Grid server authorization.
2
Specifies the users.properties file.
3
Specifies that the file is relative to the $ISPN_HOME/server/conf directory.
4
Specifies that the passwords in users.properties are in plain-text format.
5
Specifies the groups.properties file.

Supported authentication mechanisms

Property realms support the following authentication mechanisms:

  • SASL: PLAIN, DIGEST-*, and SCRAM-*
  • HTTP (REST): Basic and Digest

6.2.1.1. Adding Users to Property Realms
Copia collegamento

Data Grid server provides a user-tool script that lets you easily add new user/role mappings to properties files.

Procedure

  1. Navigate to your $ISPN_HOME directory.
  2. Run the user-tool script in the bin folder.

For example, create a new user named "myuser" with a password of "qwer1234!" that belongs to the "supervisor", "reader", and "writer" groups:

Linux
$ bin/user-tool.sh -u myuser -p "qwer1234!" -g supervisor,reader,writer
Copy to Clipboard Toggle word wrap
Microsoft Windows
$ bin\user-tool.bat -u myuser -p "qwer1234!" -g supervisor,reader,writer
Copy to Clipboard Toggle word wrap

6.2.2. LDAP Realms
Copia collegamento

LDAP realms connect to LDAP servers, such as OpenLDAP, Red Hat Directory Server, Apache Directory Server, or Microsoft Active Directory, to authenticate users and obtain membership information.

Note

LDAP servers can have different entry layouts, depending on the type of server and deployment. For this reason, LDAP realm configuration is complex. It is beyond the scope of this document to provide examples for all possibile configurations.

LDAP realm configuration

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
        <ldap-realm name="ldap"
1 

                    url="ldap://my-ldap-server:10389"
2 

                    principal="uid=admin,ou=People,dc=infinispan,dc=org"
3 

                    credential="strongPassword"
                    connection-timeout="3000" read-timeout="30000"
4 

                    connection-pooling="true" referral-mode="ignore"
                    page-size="30"
                    direct-verification="true">
5 

            <identity-mapping rdn-identifier="uid"
6 

                              search-dn="ou=People,dc=infinispan,dc=org">
7 

               <attribute-mapping>
8 

                  <attribute from="cn"
                             to="Roles"
                             filter="(&amp;(objectClass=groupOfNames)(member={1}))"
                             filter-dn="ou=Roles,dc=infinispan,dc=org"/>
               </attribute-mapping>
            </identity-mapping>
         </ldap-realm>
      </security-realm>
   </security-realms>
</security>
Copy to Clipboard Toggle word wrap

1
Names the LDAP realm.
2
Specifies the LDAP server connection URL.
3
Specifies a principal and credentials to connect to the LDAP server.
Important

The principal for LDAP connections must have necessary privileges to perform LDAP queries and access specific attributes.

4
Optionally tunes LDAP server connections by specifying connection timeouts and so on.
5
Verifies user credentials. Data Grid attempts to connect to the LDAP server using the configured credentials. Alternatively, you can use the user-password-mapper element that specifies a password.
6
Maps LDAP entries to identities. The rdn-identifier specifies an LDAP attribute that finds the user entry based on a provided identifier, which is typically a username; for example, the uid or sAMAccountName attribute.
7
Defines a starting context that limits searches to the LDAP subtree that contains the user entries.
8
Retrieves all the groups of which the user is a member. There are typically two ways in which membership information is stored:
  • Under group entries that usually have class groupOfNames in the member attribute. In this case, you can use an attribute filter as in the preceding example configuration. This filter searches for entries that match the supplied filter, which locates groups with a member attribute equal to the user’s DN. The filter then extracts the group entry’s CN as specified by from, and adds it to the user’s Roles.

  • In the user entry in the memberOf attribute. In this case you should use an attribute reference such as the following:

    <attribute-reference reference="memberOf" from="cn" to="Roles" />

    This reference gets all memberOf attributes from the user’s entry, extracts the CN as specified by from, and adds them to the user’s Roles.

Supported authentication mechanisms

LDAP realms support the following authentication mechanisms directly:

  • SASL: PLAIN, DIGEST-*, and SCRAM-*
  • HTTP (REST): Basic and Digest

6.2.2.1. LDAP Realm Principal Rewriting
Copia collegamento

Some SASL authentication mechanisms, such as GSSAPI, GS2-KRB5 and Negotiate, supply a username that needs to be cleaned up before you can use it to search LDAP servers. 

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <ldap-realm name="ldap"
                     url="ldap://${org.infinispan.test.host.address}:10389"
                     principal="uid=admin,ou=People,dc=infinispan,dc=org"
                     credential="strongPassword">
            <name-rewriter>
1 

               <regex-principal-transformer name="domain-remover"
                                            pattern="(.*)@INFINISPAN\.ORG"
                                            replacement="$1"/>
            </name-rewriter>
            <identity-mapping rdn-identifier="uid"
                              search-dn="ou=People,dc=infinispan,dc=org">
               <attribute-mapping>
                  <attribute from="cn" to="Roles"
                             filter="(&amp;(objectClass=groupOfNames)(member={1}))"
                             filter-dn="ou=Roles,dc=infinispan,dc=org" />
               </attribute-mapping>
               <user-password-mapper from="userPassword" />
            </identity-mapping>
         </ldap-realm>
      </security-realm>
   </security-realms>
</security>
Copy to Clipboard Toggle word wrap
1
Defines a rewriter that extracts the username from the principal using a regular expression.

6.2.3. Trust Store Realms
Copia collegamento

Trust store realms use keystores that contain the public certificates of all clients that are allowed to connect to Data Grid server. 

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <server-identities>
            <ssl>
               <keystore path="server.p12"
1 

                         relative-to="infinispan.server.config.path"
2 

                         keystore-password="secret"
3 

                         alias="server"/>
4 

            </ssl>
         </server-identities>
         <truststore-realm path="trust.p12"
5 

                           relative-to="infinispan.server.config.path"
                           keystore-password="secret"/>
      </security-realm>
   </security-realms>
</security>
Copy to Clipboard Toggle word wrap
1
Provides an SSL server identity with a keystore that contains server certificates.
2
Specifies that the file is relative to the $ISPN_HOME/server/conf directory.
3
Specifies a keystore password.
4
Specifies a keystore alias.
5
Provides a keystore that contains public certificates of all clients.

Supported authentication mechanisms

Trust store realms work with client-certificate authentication mechanisms:

  • SASL: EXTERNAL
  • HTTP (REST): CLIENT_CERT

6.2.4. Token Realms
Copia collegamento

Token realms use external services to validate tokens and require providers that are compatible with RFC-7662 (OAuth2 Token Introspection), such as Red Hat SSO. 

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <token-realm name="token"
                      auth-server-url="https://oauth-server/auth/">
1 

            <oauth2-introspection
                    introspection-url="https://oauth-server/auth/realms/infinispan/protocol/openid-connect/token/introspect"
2 

                    client-id="infinispan-server"
3 

                    client-secret="1fdca4ec-c416-47e0-867a-3d471af7050f"/>
4 

         </token-realm>
      </security-realm>
   </security-realms>
</security>
Copy to Clipboard Toggle word wrap
1
Specifies the URL of the authentication server.
2
Specifies the URL of the token introspection endpoint.
3
Names the client identifier for Data Grid server.
4
Specifies the client secret for Data Grid server.

Supported authentication mechanisms

Token realms support the following authentication mechanisms:

  • SASL: OAUTHBEARER
  • HTTP (REST): Bearer

6.3. Creating Data Grid Server Identities
Copia collegamento

Server identities are defined within security realms and enable Data Grid servers to prove their identity to clients.

6.3.1. Setting Up SSL Identities
Copia collegamento

SSL identities use keystores that contain either a certificate or chain of certificates.

Note

If security realms contain SSL identities, Data Grid servers automatically enable encryption for the endpoints that use those security realms.

Procedure

  1. Create a keystore for Data Grid server.

    Important

    Data Grid server supports the following keystore formats: JKS, JCEKS, PKCS12, BKS, BCFKS and UBER.

    In production environments, server certificates should be signed by a trusted Certificate Authority, either Root or Intermediate CA.

  2. Add the keystore to the $ISPN_HOME/server/conf directory.
  3. Add a server-identities definition to the Data Grid server security realm.
  4. Specify the name of the keystore along with the password and alias.

6.3.1.1. SSL Identity Configuration
Copia collegamento

The following example configures an SSL identity for Data Grid server: 

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <server-identities>
1 

            <ssl>
2 

               <keystore path="server.p12"
3 

                         relative-to="infinispan.server.config.path"
4 

                         keystore-password="secret"
5 

                         alias="server"/>
6 

            </ssl>
         </server-identities>
      </security-realm>
   </security-realms>
</security>
Copy to Clipboard Toggle word wrap
1
Defines identities for Data Grid server.
2
Configures an SSL identity for Data Grid server.
3
Names a keystore that contains Data Grid server SSL certificates.
4
Specifies that the keystore is relative to the server/conf directory in $ISPN_HOME.
5
Specifies a keystore password.
6
Specifies a keystore alias.

6.3.1.2. Automatically Generating Keystores
Copia collegamento

Configure Data Grid servers to automatically generate keystores at startup.

Important

Automatically generated keystores:

  • Should not be used in production environments.
  • Are generated whenever necessary; for example, while obtaining the first connection from a client.
  • Contain certificates that you can use directly in Hot Rod clients.

Procedure

  1. Include the generate-self-signed-certificate-host attribute for the keystore element in the server configuration.
  2. Specify a hostname for the server certificate as the value.

SSL server identity with a generated keystore

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <server-identities>
            <ssl>
               <keystore path="server.p12"
                         relative-to="infinispan.server.config.path"
                         keystore-password="secret"
                         alias="server"
                         generate-self-signed-certificate-host="localhost"/>
1 

            </ssl>
         </server-identities>
      </security-realm>
   </security-realms>
</security>
Copy to Clipboard Toggle word wrap

1
generates a keystore using localhost

6.3.1.3. Tuning SSL Protocols and Cipher Suites
Copia collegamento

You can configure the SSL engine, via the Data Grid server SSL identity, to use specific protocols and ciphers.

Important

You must ensure that you set the correct ciphers for the protocol features you want to use; for example HTTP/2 ALPN.

Procedure

  1. Add the engine element to your Data Grid server SSL identity.
  2. Configure the SSL engine with the enabled-protocols and enabled-ciphersuites attributes.

SSL engine configuration

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1
          https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <server-identities>
            <ssl>
               <keystore path="server.p12"
                         relative-to="infinispan.server.config.path"
                         keystore-password="secret" alias="server"/>
               <engine enabled-protocols="TLSv1.2 TLSv1.1"
1 

                       enabled-ciphersuites="SSL_RSA_WITH_AES_128_GCM_SHA256
2 

                       SSL_RSA_WITH_AES_128_CBC_SHA256"/>
            </ssl>
         </server-identities>
      </security-realm>
   </security-realms>
</security>
Copy to Clipboard Toggle word wrap

1
Configures the SSL engine to use TLS v1 and v2 protocols.
2
Configures the SSL engine to use the specified cipher suites.

6.3.2. Setting Up Kerberos Identities
Copia collegamento

Kerberos identities use keytab files that contain service principal names and encrypted keys, derived from Kerberos passwords.

Note

keytab files can contain both user and service account principals. However, Data Grid servers use service account principals only. As a result, Data Grid servers can provide identity to clients and allow clients to authenticate with Kerberos servers.

In most cases, you create unique principals for the Hot Rod and REST connectors. For example, you have a "datagrid" server in the "INFINISPAN.ORG" domain. In this case you should create the following service principals:

  • hotrod/datagrid@INFINISPAN.ORG identifies the Hot Rod service.
  • HTTP/datagrid@INFINISPAN.ORG identifies the REST service.

Procedure

  1. Create keytab files for the Hot Rod and REST services.

    Linux
    $ ktutil
ktutil:  addent -password -p datagrid@INFINISPAN.ORG -k 1 -e aes256-cts
Password for datagrid@INFINISPAN.ORG: [enter your password]
ktutil:  wkt http.keytab
ktutil:  quit
    Copy to Clipboard Toggle word wrap
    Microsoft Windows
    $ ktpass -princ HTTP/datagrid@INFINISPAN.ORG -pass * -mapuser INFINISPAN\USER_NAME
$ ktab -k http.keytab -a HTTP/datagrid@INFINISPAN.ORG
    Copy to Clipboard Toggle word wrap
  2. Copy the keytab files to the $ISPN_HOME/server/conf directory.
  3. Add a server-identities definition to the Data Grid server security realm.
  4. Specify the location of keytab files that provide service principals to Hot Rod and REST connectors.
  5. Name the Kerberos service principals.

6.3.2.1. Kerberos Identity Configuration
Copia collegamento

The following example configures Kerberos identities for Data Grid server: 

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <server-identities>
1 

            <kerberos keytab-path="hotrod.keytab"
2 

                      principal="hotrod/datagrid@INFINISPAN.ORG"
3 

                      required="true"/>
4 

            <kerberos keytab-path="http.keytab"
5 

                      principal="HTTP/localhost@INFINISPAN.ORG"
6 

                      required="true"/>
         </server-identities>
      </security-realm>
   </security-realms>
</security>
Copy to Clipboard Toggle word wrap
1
Defines identities for Data Grid server.
2
Specifies a keytab file that provides a Kerberos identity for the Hot Rod connector.
3
Names the Kerberos service principal for the Hot Rod connector.
4
Specifies that the keytab file must exist when Data Grid server starts.
5
Specifies a keytab file that provides a Kerberos identity for the REST connector.
6
Names the Kerberos service principal for the REST connector.

6.4. Configuring Endpoint Authentication Mechanisms
Copia collegamento

Configure Hot Rod and REST connectors with SASL authentication mechanisms to authenticate with clients.

6.4.1. Setting Up Hot Rod Authentication
Copia collegamento

Configure Hot Rod connectors to authenticate with clients to Data Grid server security realms using specific SASL authentication mechanisms .

Procedure

  1. Add an authentication definition to the Hot Rod connector configuration.
  2. Specify which Data Grid security realm the Hot Rod connector uses for authentication.
  3. Specify the SASL authentication mechanisms for the Hot Rod endpoint to use.
  4. Configure SASL authentication properties as appropriate.

6.4.1.1. Hot Rod Authentication Configuration
Copia collegamento

Hot Rod connector with SCRAM, DIGEST, and PLAIN authentication

<endpoints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="urn:infinispan:server:10.1
           https://infinispan.org/schemas/infinispan-server-10.1.xsd"
           xmlns="urn:infinispan:server:10.1"
           socket-binding="default" security-realm="default">
1 

   <hotrod-connector name="hotrod">
      <authentication>
         <sasl mechanisms="SCRAM-SHA-512 SCRAM-SHA-384 SCRAM-SHA-256
2 

                           SCRAM-SHA-1 DIGEST-SHA-512 DIGEST-SHA-384
                           DIGEST-SHA-256 DIGEST-SHA DIGEST-MD5 PLAIN"
               server-name="infinispan"
3 

               qop="auth"/>
4 

      </authentication>
   </hotrod-connector>
</endpoints>
Copy to Clipboard Toggle word wrap

1
enables authentication against the security realm named "default".
2
specifies SASL mechanisms to use for authentication.
3
defines the name that Data Grid servers declare to clients. The server name should match the client configuration.
4
enables auth QoP.

Hot Rod connector with Kerberos authentication

<endpoints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
           xmlns="urn:infinispan:server:10.1"
           socket-binding="default" security-realm="default">
   <hotrod-connector name="hotrod">
      <authentication>
         <sasl mechanisms="GSSAPI GS2-KRB5"
1 

               server-name="datagrid"
2 

               server-principal="hotrod/datagrid@INFINISPAN.ORG"/>
3 

      </authentication>
   </hotrod-connector>
</endpoints>
Copy to Clipboard Toggle word wrap

1
Enables the GSSAPI and GS2-KRB5 mechanisms for Kerberos authentication.
2
Defines the Data Grid server name, which is equivalent to the Kerberos service name.
3
Specifies the Kerberos identity for the server.

6.4.1.2. Hot Rod Endpoint Authentication Mechanisms
Copia collegamento

Data Grid supports the following SASL authentications mechanisms with the Hot Rod connector:

Expand
Authentication mechanismDescriptionRelated details

PLAIN

Uses credentials in plain-text format. You should use PLAIN authentication with encrypted connections only.

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.

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.

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.

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.

Similar to the SPNEGO HTTP mechanism.

EXTERNAL

Uses client certificates.

Similar to the CLIENT_CERT HTTP mechanism.

OAUTHBEARER

Uses OAuth tokens and requires a token-realm configuration.

Similar to the BEARER_TOKEN HTTP mechanism.

6.4.1.3. SASL Quality of Protection (QoP)
Copia collegamento

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

Expand
QoP settingDescription

auth

Authentication only.

auth-int

Authentication with integrity protection.

auth-conf

Authentication with integrity and privacy protection.

6.4.1.4. SASL Policies
Copia collegamento

SASL policies let you control which authentication mechanisms Hot Rod connectors can use.

Expand
PolicyDescriptionDefault 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

Tip

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

Hot Rod connector with SASL policy configuration

<hotrod-connector socket-binding="hotrod" cache-container="default">
   <authentication security-realm="ApplicationRealm">
      <sasl server-name="myhotrodserver"
            mechanisms="PLAIN DIGEST-MD5 GSSAPI EXTERNAL"
1 

            qop="auth">
         <policy>
2 

            <no-active value="true" />
            <no-anonymous value="true" />
            <no-plain-text value="true" />
         </policy>
      </sasl>
   </authentication>
</hotrod-connector>
Copy to Clipboard Toggle word wrap

1
Specifies multiple SASL authentication mechanisms for the Hot Rod connector.
2
Defines policies for SASL mechanisms.

As a result of the preceding configuration, the Hot Rod connector uses the GSSAPI mechanism because it is the only mechanism that complies with all policies.

6.4.2. Setting Up REST Authentication
Copia collegamento

Configure REST connectors to authenticate with clients to Data Grid server security realms using specific SASL authentication mechanisms .

Procedure

  1. Add an authentication definition to the REST connector configuration.
  2. Specify which Data Grid security realm the REST connector uses for authentication.
  3. Specify the SASL authentication mechanisms for the REST endpoint to use.
  4. Configure SASL authentication properties as appropriate.

6.4.2.1. REST Authentication Configuration
Copia collegamento

REST connector with BASIC and DIGEST authentication

<endpoints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
           xmlns="urn:infinispan:server:10.1"
           socket-binding="default" security-realm="default">
1 

   <rest-connector name="rest">
      <authentication mechanisms="DIGEST BASIC"/>
2 

   </rest-connector>
</endpoints>
Copy to Clipboard Toggle word wrap

1
Enables authentication against the security realm named "default".
2
Specifies SASL mechanisms to use for authentication

REST connector with Kerberos authentication

<endpoints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
           xmlns="urn:infinispan:server:10.1"
           socket-binding="default" security-realm="default">
   <rest-connector name="rest">
      <authentication mechanisms="SPNEGO"
1 

                      server-principal="HTTP/localhost@INFINISPAN.ORG"/>
2 

   </rest-connector>
</endpoints>
Copy to Clipboard Toggle word wrap

1
Enables the SPENGO mechanism for Kerberos authentication.
2
Specifies the Kerberos identity for the server.

6.4.2.2. REST Endpoint Authentication Mechanisms
Copia collegamento

Data Grid supports the following authentications mechanisms with the REST connector:

Expand
Authentication mechanismDescriptionRelated details

BASIC

Uses credentials in plain-text format. You should use BASIC authentication with encrypted connections only.

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.

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.

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.

Corresponds to the Bearer HTTP authentication scheme and is similar to OAUTHBEARER SASL mechanism.

CLIENT_CERT

Uses client certificates.

Similar to the EXTERNAL SASL mechanism.

Torna in cima
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2025 Red Hat