Data Grid 安全指南

Red Hat Data Grid 8.5

启用并配置 Data Grid 安全性

Red Hat Customer Content Services

法律通告

摘要

保护您的数据网格部署不受网络入侵者的影响。限制授权用户的数据访问。

Red Hat Data Grid

Data Grid 是一个高性能分布式内存数据存储。

无架构数据结构: 将不同对象存储为键值对的灵活性。
基于网格的数据存储: 旨在在集群中分发和复制数据。
弹性扩展: 动态调整节点数量，以便在不中断服务的情况下满足需求。
数据互操作性: 从不同端点在网格中存储、检索和查询数据。

Data Grid 文档

红帽客户门户网站中提供了 Data Grid 的文档。

Data Grid 下载

访问红帽客户门户上的 Data Grid 软件下载。

注意

您必须有一个红帽帐户才能访问和下载数据中心软件。

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始：master、slave、黑名单和白名单。由于此项工作十分艰巨，这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息。

第 1 章使用基于角色的访问控制进行安全授权

基于角色的访问控制(RBAC)功能使用不同的权限级别来限制用户与网格交互。

注意

有关创建用户并配置特定于远程或嵌入式缓存的授权的详情，请参考：

1.1. Data Grid 用户角色和权限

Data Grid 包括多个角色，为用户提供访问缓存和数据网格资源的权限。

角色	权限	描述
`admin`	ALL	具有所有权限的超级用户，包括控制缓存管理器生命周期。
`deployer`	ALL_READ、ALL_WRITE、LISTEN、EXEC、MONITOR、CREATE	除了 `应用程序` 权限外，还可创建和删除 Data Grid 资源。
`application`	ALL_READ, ALL_WRITE, LISTEN, EXEC, MONITOR	除 `观察者` 权限外，还具有对 Data Grid 资源的读写访问权限。也可以侦听事件并执行服务器任务和脚本。
`observer`	ALL_READ, MONITOR	除了监控权限外，还具有对 Data Grid `资源` 的读取访问权限。
`monitor`	MONITOR	可以通过 JMX 和 `指标端点` 查看统计信息。

其他资源

1.1.1. 权限

用户角色是具有不同访问级别的权限集。

表 1.1. 缓存管理器权限
权限	功能	描述
配置	`defineConfiguration`	定义新的缓存配置。
LISTEN	`addListener`	针对缓存管理器注册监听程序。
生命周期	`stop`	停止缓存管理器。
CREATE	`createCache`, `removeCache`	创建和删除容器资源，如缓存、计数器、模式和脚本。
MONITOR	`getStats`	允许访问 JMX 统计信息和 `指标端点`。
ALL	-	包括所有缓存管理器权限。

表 1.2. 缓存权限
权限	功能	描述
READ	`Get`，`包含`	从缓存检索条目。
写	放置 , `put IfAbsent`,`replace`,`remove`,`eviction`	写入、替换、删除、驱除缓存中的数据。
EXEC	`distexec`,`stream`	允许针对缓存执行代码。
LISTEN	`addListener`	针对缓存注册监听程序。
BULK_READ	`keySet`,`values`,`entrySet`,`query`	执行批量检索操作。
BULK_WRITE	`清除`,`putAll`	执行批量写入操作。
生命周期	`启动`,`stop`	启动和停止缓存。
ADMIN	`getVersion`,`addInterceptor*`, `removeInterceptor`,`getInterceptorChain`,`getEvictionManager`,`getComponentRegistry`,`getDistributionManager`,`getAuthorizationManager`,`evict`,`getRpcManager`,`getCacheConfiguration`,`getCacheManager`, `getInvocationContextContainer`,`setAvailability`,`getDataContainer`,`getStats`,`getXAResource`	允许访问底层组件和内部结构。
MONITOR	`getStats`	允许访问 JMX 统计信息和 `指标端点`。
ALL	-	包括所有缓存权限。
ALL_READ	-	组合了 READ 和 BULK_READ 权限。
ALL_WRITE	-	组合 WRITE 和 BULK_WRITE 权限。

其他资源

Data Grid Security API

1.1.2. 角色和权限映射器

Data Grid 将用户实施为主体的集合。主体代表单独的用户身份，如用户名或用户所属的组。在内部，它们使用 javax.security.auth.Subject 类实现。

要启用授权，主体必须映射到角色名称，然后扩展到一组权限。

Data Grid 包括 PrincipalRoleMapper API，用于将安全主体与角色关联，以及用于将角色与特定权限关联的 RolePermissionMapper API。

Data Grid 提供以下角色和权限映射程序实现：

集群角色映射器: 在集群 registry 中存储角色映射的主体。
集群权限映射器: 在集群 registry 中存储权限映射的角色。允许您动态修改用户角色和权限。
身份角色映射器: 使用主体名称作为角色名称。主体名称的类型或格式取决于源。例如，在 LDAP 目录中，主体名称可以是可辨识名称(DN)。
通用名称角色映射器: 使用 Common Name (CN)作为角色名称。您可以将此角色映射程序与 LDAP 目录或包含可辨识名称(DN)的客户端证书一起使用；例如 cn=managers,ou=people,dc=example,dc=com 映射到 managers 角色。

注意

默认情况下，principal-to-role 映射仅应用于代表组的主体。通过将 authorization.group-only-mapping 配置属性设置为 false，可以将 Data Grid 配置为也为用户主体执行映射。

1.1.2.1. 在 Data Grid 中将用户映射到角色和权限

考虑从 LDAP 服务器检索的以下用户，作为 DN 的集合：

CN=myapplication,OU=applications,DC=mycompany
CN=dataprocessors,OU=groups,DC=mycompany
CN=finance,OU=groups,DC=mycompany

使用 通用名称角色映射器 时，用户将映射到以下角色：

dataprocessors
finance

Data Grid 具有以下角色定义：

dataprocessors: ALL_WRITE ALL_READ
finance: LISTEN

用户应具有以下权限：

ALL_WRITE ALL_READ LISTEN

其他资源

1.1.3. 配置角色映射器

默认情况下，Data Grid 启用集群角色映射程序和集群权限映射程序。要将不同的实现用于角色映射，您必须配置角色映射程序。

流程

打开 Data Grid 配置以进行编辑。
在 Cache Manager 配置中，将角色映射器声明为安全授权的一部分。
保存对配置的更改。

使用嵌入式缓存，您可以使用 principalRoleMapper （） 和 rolePermissionMapper （） 方法以编程方式配置角色和权限映射器。

角色映射器配置

XML

<cache-container>
  <security>
    <authorization>
      <common-name-role-mapper />
    </authorization>
  </security>
</cache-container>

JSON

{
  "infinispan" : {
    "cache-container" : {
      "security" : {
        "authorization" : {
          "common-name-role-mapper": {}
        }
      }
    }
  }
}

YAML

infinispan:
  cacheContainer:
    security:
      authorization:
        commonNameRoleMapper: ~

其他资源

Data Grid 配置架构参考

1.1.4. 配置集群角色和权限映射程序

集群角色映射程序在主体和角色之间维护动态映射。集群权限映射程序维护一组动态的角色定义。在这两种情况下，映射都存储在集群注册表中，可以使用 CLI 或 REST API 在运行时操作。

先决条件

具有 Data Grid 的 ADMIN 权限。
启动 Data Grid CLI。
连接到正在运行的 Data Grid 集群。

1.1.4.1. 创建新角色

创建新角色并设置权限。

流程

使用用户角色 create 命令创建角色，例如：

user roles create --permissions=ALL_READ,ALL_WRITE simple

验证

使用用户角色 ls 命令，列出您向用户授予的角色。

user roles ls
["observer","application","admin","monitor","simple","deployer"]

描述 使用用户角色的角色 describe 命令。

user roles describe simple
{
  "name" : "simple",
  "permissions" : [ "ALL_READ","ALL_WRITE" ]
}

1.1.4.2. 授予用户角色

为用户分配角色，并授予他们执行缓存操作并与 Data Grid 资源交互的权限。

提示

如果要为多个用户分配同一角色并集中维护其权限，请将角色授予组而不是用户。

先决条件

具有 Data Grid 的 ADMIN 权限。
创建 Data Grid 用户。

流程

创建与 Data Grid 的 CLI 连接。
使用 用户角色 grant 命令为用户分配角色，例如：
```
user roles grant --roles=deployer katie
```

验证

使用用户角色 ls 命令，列出您向用户授予的角色。

user roles ls katie
["deployer"]

1.1.4.3. 集群角色映射程序名称重写器

默认情况下，映射是使用主体名称和角色之间的严格字符串等效性来执行。在执行查找前，可以将集群角色映射器配置为应用到主体名称的转换。

流程

打开 Data Grid 配置以进行编辑。
为集群角色映射器指定一个名称 rewriter，作为 Cache Manager 配置中的安全授权的一部分。
保存对配置的更改。

主体名称可能具有不同的表单，具体取决于安全域类型：

属性和令牌域可能会返回简单字符串
信任和 LDAP 域可能会返回 X.500 风格的可分辨名称
Kerberos 域可以返回 user@domain风格名称

使用以下转换器之一，名称可以规范化为通用形式：

1.1.4.3.1. case Principal Transformer

XML

<cache-container>
   <security>
      <authorization>
         <cluster-role-mapper>
            <name-rewriter>
               <case-principal-transformer uppercase="false"/>
            </name-rewriter>
         </cluster-role-mapper>
      </authorization>
   </security>
</cache-container>

JSON

{
  "cache-container": {
    "security": {
      "authorization": {
        "cluster-role-mapper": {
          "name-rewriter": {
            "case-principal-transformer": {}
          }
        }
      }
    }
  }
}

YAML

cacheContainer:
  security:
    authorization:
      clusterRoleMapper:
        nameRewriter:
          casePrincipalTransformer:
            uppercase: false

1.1.4.3.2. regex Principal Transformer

XML

<cache-container>
   <security>
      <authorization>
         <cluster-role-mapper>
            <name-rewriter>
               <regex-principal-transformer pattern="cn=([^,]+),.*" replacement="$1"/>
            </name-rewriter>
         </cluster-role-mapper>
      </authorization>
   </security>
</cache-container>

JSON

{
  "cache-container": {
    "security": {
      "authorization": {
        "cluster-role-mapper": {
          "name-rewriter": {
            "regex-principal-transformer": {
              "pattern": "cn=([^,]+),.*",
              "replacement": "$1"
            }
          }
        }
      }
    }
  }
}

YAML

cacheContainer:
  security:
    authorization:
      clusterRoleMapper:
        nameRewriter:
          regexPrincipalTransformer:
            pattern: "cn=([^,]+),.*"
            replacement: "$1"

其他资源

Data Grid 配置架构参考

1.2. 使用安全授权配置缓存

为缓存添加安全授权来强制实施基于角色的访问控制(RBAC)。这要求 Data Grid 用户拥有足够级别权限来执行缓存操作的角色。

先决条件

创建 Data Grid 用户，并使用角色授予他们，或者将它们分配到组。

流程

打开 Data Grid 配置以进行编辑。
在配置中添加 security 部分。
指定用户必须使用 authorization 元素执行缓存操作的角色。
您可以隐式添加缓存管理器中定义的所有角色，或者明确定义角色的子集。
保存对配置的更改。

隐式角色配置

以下配置会隐式添加缓存管理器中定义的每个角色：

XML

<distributed-cache>
  <security>
    <authorization/>
  </security>
</distributed-cache>

JSON

{
  "distributed-cache": {
    "security": {
      "authorization": {
        "enabled": true
      }
    }
  }
}

YAML

distributedCache:
  security:
    authorization:
      enabled: true

显式角色配置

以下配置明确添加缓存管理器中定义的角色子集。在这种情况下，Data Grid 拒绝任何没有配置角色的用户的缓存操作。

XML

<distributed-cache>
  <security>
    <authorization roles="admin supervisor"/>
  </security>
</distributed-cache>

JSON

{
  "distributed-cache": {
    "security": {
      "authorization": {
        "enabled": true,
        "roles": ["admin","supervisor"]
      }
    }
  }
}

YAML

distributedCache:
  security:
    authorization:
      enabled: true
      roles: ["admin","supervisor"]

第 2 章安全域

安全域将 Data Grid 服务器部署与您的环境中的网络协议和基础架构集成，以控制用户身份并验证用户身份。

2.1. 创建安全域

向 Data Grid 服务器配置添加安全域，以控制对部署的访问。您可以在配置中添加一个或多个安全域。

注意

当您向配置添加安全域时，Data Grid 服务器会自动为 Hot Rod 和 REST 端点启用匹配的身份验证机制。

先决条件

根据需要，为您的 Data Grid 服务器配置添加套接字绑定。
创建密钥存储或具有 PEM 文件，以使用 TLS/SSL 加密配置安全域。
网格服务器也可以在启动时生成密钥存储。
置备安全域配置依赖的资源或服务。
例如，如果您添加令牌域，则需要置备 OAuth 服务。

此流程演示了如何配置多个属性域。开始之前，您需要创建属性文件，以使用命令行界面(CLI)添加用户并分配权限。使用 user create 命令，如下所示：

user create <username> -p <changeme> -g <role> \
     --users-file=application-users.properties \
     --groups-file=application-groups.properties

user create <username> -p <changeme> -g <role> \
     --users-file=management-users.properties \
     --groups-file=management-groups.properties

提示

运行 user create --help 获取示例和更多信息。

注意

使用 CLI 向属性域添加凭证只会在您连接的服务器实例上创建用户。您必须在属性域中手动将凭证同步到集群中的每个节点。

流程

打开 Data Grid Server 配置以进行编辑。
使用安全配置中的 security -realms 元素，使其包含多个安全域。
添加一个带有 security-realm 元素的安全域，并为它赋予 name 属性的唯一名称。
要遵循示例，请创建一个名为 application-realm 的安全域，另一个名为 management-realm。
为 Data Grid 服务器提供 TLS/SSL 识别，并提供 server-identities 元素，并根据需要配置密钥存储。
通过添加以下元素或字段来指定安全域的类型：
- properties-realm
- ldap-realm
- token-realm
- truststore-realm
指定您根据需要配置的安全域类型的属性。
要遵循示例，请使用 user- properties 和 group-properties 元素或字段上的 path 属性指定您使用 CLI 创建的 dcproperties 文件。
如果您在配置中添加多种不同类型的安全域，请包含 distributed-realm 元素或字段，以便 Data Grid 服务器使用域并相互组合。
配置 Data Grid 服务器端点，以使用带有 security-realm 属性的安全域。
保存对配置的更改。

多个属性域

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="application-realm">
        <properties-realm groups-attribute="Roles">
          <user-properties path="application-users.properties"/>
          <group-properties path="application-groups.properties"/>
        </properties-realm>
      </security-realm>
      <security-realm name="management-realm">
        <properties-realm groups-attribute="Roles">
          <user-properties path="management-users.properties"/>
          <group-properties path="management-groups.properties"/>
        </properties-realm>
      </security-realm>
    </security-realms>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "management-realm",
        "properties-realm": {
          "groups-attribute": "Roles",
          "user-properties": {
            "digest-realm-name": "management-realm",
            "path": "management-users.properties"
          },
          "group-properties": {
            "path": "management-groups.properties"
          }
        }
      }, {
        "name": "application-realm",
        "properties-realm": {
          "groups-attribute": "Roles",
          "user-properties": {
            "digest-realm-name": "application-realm",
            "path": "application-users.properties"
          },
          "group-properties": {
            "path": "application-groups.properties"
          }
        }
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "management-realm"
        propertiesRealm:
          groupsAttribute: "Roles"
          userProperties:
            digestRealmName: "management-realm"
            path: "management-users.properties"
          groupProperties:
            path: "management-groups.properties"
      - name: "application-realm"
        propertiesRealm:
          groupsAttribute: "Roles"
          userProperties:
            digestRealmName: "application-realm"
            path: "application-users.properties"
          groupProperties:
            path: "application-groups.properties"

2.2. 设置 Kerberos 身份

在 Data Grid Server 配置中为安全域添加 Kerberos 身份，以使用包含服务主体名称和加密密钥的 keytab 文件，从 Kerberos 密码衍生。

先决条件

有 Kerberos 服务帐户主体。

注意

keytab 文件可以包含用户和服务帐户主体。但是，Data Grid 服务器只使用服务帐户主体，这意味着它可以向客户端提供身份，并允许客户端与 Kerberos 服务器进行身份验证。

在大多数情况下，您可以为 Hot Rod 和 REST 端点创建唯一的主体。例如，如果您在 "INFINISPAN.ORG" 域中有一个"datagrid"服务器，您应该创建以下服务主体：

HotRod/datagrid@INFINISPAN.ORG 标识 Hot Rod 服务。
http/datagrid@INFINISPAN.ORG 标识 REST 服务。

流程

为 Hot Rod 和 REST 服务创建 keytab 文件。

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

Microsoft Windows

ktpass -princ HTTP/datagrid@INFINISPAN.ORG -pass * -mapuser INFINISPAN\USER_NAME
ktab -k http.keytab -a HTTP/datagrid@INFINISPAN.ORG

将 keytab 文件复制到 Data Grid Server 安装的 server/conf 目录中。
打开 Data Grid Server 配置以进行编辑。
在 Data Grid 服务器安全域中添加 server-identities 定义。
指定为 Hot Rod 和 REST 连接器提供服务主体的 keytab 文件的位置。
将 Kerberos 服务主体命名为。
保存对配置的更改。

Kerberos 身份配置

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="kerberos-realm">
        <server-identities>
          <!-- Specifies a keytab file that provides a Kerberos identity. -->
          <!-- Names the Kerberos service principal for the Hot Rod endpoint. -->
          <!-- The required="true" attribute specifies that the keytab file must be present when the server starts. -->
          <kerberos keytab-path="hotrod.keytab"
                    principal="hotrod/datagrid@INFINISPAN.ORG"
                    required="true"/>
          <!-- Specifies a keytab file and names the Kerberos service principal for the REST endpoint. -->
          <kerberos keytab-path="http.keytab"
                    principal="HTTP/localhost@INFINISPAN.ORG"
                    required="true"/>
        </server-identities>
      </security-realm>
    </security-realms>
  </security>
  <endpoints>
    <endpoint socket-binding="default"
              security-realm="kerberos-realm">
     <hotrod-connector>
        <authentication>
           <sasl server-name="datagrid"
                 server-principal="hotrod/datagrid@INFINISPAN.ORG"/>
        </authentication>
     </hotrod-connector>
     <rest-connector>
       <authentication server-principal="HTTP/localhost@INFINISPAN.ORG"/>
     </rest-connector>
   </endpoint>
  </endpoints>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "kerberos-realm",
        "server-identities": [{
          "kerberos": {
            "principal": "hotrod/datagrid@INFINISPAN.ORG",
            "keytab-path": "hotrod.keytab",
            "required": true
          },
          "kerberos": {
            "principal": "HTTP/localhost@INFINISPAN.ORG",
            "keytab-path": "http.keytab",
            "required": true
          }
        }]
      }]
    },
    "endpoints": {
      "endpoint": {
        "socket-binding": "default",
        "security-realm": "kerberos-realm",
        "hotrod-connector": {
          "authentication": {
            "security-realm": "kerberos-realm",
            "sasl": {
              "server-name": "datagrid",
              "server-principal": "hotrod/datagrid@INFINISPAN.ORG"
            }
          }
        },
        "rest-connector": {
          "authentication": {
            "server-principal": "HTTP/localhost@INFINISPAN.ORG"
          }
        }
      }
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "kerberos-realm"
        serverIdentities:
          - kerberos:
              principal: "hotrod/datagrid@INFINISPAN.ORG"
              keytabPath: "hotrod.keytab"
              required: "true"
          - kerberos:
              principal: "HTTP/localhost@INFINISPAN.ORG"
              keytabPath: "http.keytab"
              required: "true"
  endpoints:
    endpoint:
      socketBinding: "default"
      securityRealm: "kerberos-realm"
      hotrodConnector:
        authentication:
          sasl:
            serverName: "datagrid"
            serverPrincipal: "hotrod/datagrid@INFINISPAN.ORG"
      restConnector:
        authentication:
          securityRealm: "kerberos-realm"
          serverPrincipal" : "HTTP/localhost@INFINISPAN.ORG"

2.3. 属性域

属性域使用属性文件来定义用户和组。

users.properties 包含 Data Grid 用户凭证。可以使用 DIGEST-MD5 和 DIGEST 身份验证机制预先摘要密码。
groups.properties 将用户与角色和权限相关联。

users.properties

myuser=a_password
user2=another_password

groups.properties

myuser=supervisor,reader,writer
user2=supervisor

属性域配置

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="default">
        <!-- groups-attribute configures the "groups.properties" file to contain security authorization roles. -->
        <properties-realm groups-attribute="Roles">
          <user-properties path="users.properties"
                           relative-to="infinispan.server.config.path"
                           plain-text="true"/>
          <group-properties path="groups.properties"
                            relative-to="infinispan.server.config.path"/>
        </properties-realm>
      </security-realm>
    </security-realms>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "default",
        "properties-realm": {
          "groups-attribute": "Roles",
          "user-properties": {
            "digest-realm-name": "default",
            "path": "users.properties",
            "relative-to": "infinispan.server.config.path",
            "plain-text": true
          },
          "group-properties": {
            "path": "groups.properties",
            "relative-to": "infinispan.server.config.path"
          }
        }
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "default"
        propertiesRealm:
          # groupsAttribute configures the "groups.properties" file
          # to contain security authorization roles.
          groupsAttribute: "Roles"
          userProperties:
            digestRealmName: "default"
            path: "users.properties"
            relative-to: 'infinispan.server.config.path'
            plainText: "true"
          groupProperties:
            path: "groups.properties"
            relative-to: 'infinispan.server.config.path'

2.3.1. 属性 realm 文件结构

用户属性文件的结构如下：

users.properties 结构

#$REALM_NAME=default$
#$ALGORITHM=encrypted$
#Wed Jul 31 08:32:08 CEST 2024
admin=algorithm-1\:hash-1;algorithm-2\:hash-2;...

前三行是特殊的注释，用于定义域的名称($REALM_NAME)、密码是否 以明文 格式存储($ALGORITHM)，以及最近更新的时间戳。

用户凭据以传统键/值格式存储：键对应于用户名，值则对应于密码。加密的密码以分号分隔的算法/哈希对形式表示，使用以 Base64 编码的哈希来表示。

凭据使用域名加密。更改 realm 的名称需要重新加密所有密码。使用 Data Grid CLI 为文件输入正确的安全域名称。

2.4. LDAP 域

LDAP 域连接到 LDAP 服务器，如 OpenLDAP、红帽目录服务器、Apache 目录服务器或 Microsoft Active Directory，以验证用户并获取成员资格信息。

注意

根据服务器和部署的类型，LDAP 服务器可以有不同的条目布局。本文档超出了本文档的范围，为所有可能的配置提供示例。

2.4.1. LDAP 连接属性

指定 LDAP 域配置中的 LDAP 连接属性。

需要以下属性：

url	指定 LDAP 服务器的 URL。URL 的格式应为 `ldap://hostname:port` 或 `ldaps://hostname:port` 用于使用 TLS 的安全连接。
主体	在 LDAp 服务器中指定有效用户的可分辨名称(DN)。DN 在 LDAP 目录结构中唯一标识用户。
credential	对应于与上述主体关联的密码。

重要

LDAP 连接的主体必须具有必要的特权，才能执行 LDAP 查询和访问特定属性。

提示

启用 连接池可显著提高 LDAP 服务器身份验证的性能。连接池机制由 JDK 提供。如需更多信息，请参阅连接池配置和 Java Tutorials：池。

2.4.2. LDAP 域用户验证方法

在 LDAP 域中配置用户验证方法。

LDAP 域可以通过两种方式验证用户：

散列化密码比较

通过比较存储在用户密码属性中的散列密码（通常为 userPassword）

直接验证

使用提供的凭证对 LDAP 服务器进行身份验证

直接验证是与 Active Directory 搭配使用的唯一方法，因为禁止访问 password 属性。

重要

您不能使用通过 direct-verification 属性执行哈希的端点身份验证机制，因为此方法需要以明文形式提供密码。因此，您必须将 BASIC 身份验证机制与 REST 端点一起使用，并将 PLAIN 与 Hot Rod 端点一起使用，才能与 Active Directory Server 集成。更安全的替代方案是使用 Kerberos，它允许 SPNEGO、GSSAPI 和 GS2-KRB5 身份验证机制。

LDAP 域搜索目录以查找与经过身份验证的用户对应的条目。rdn-identifier 属性指定一个 LDAP 属性，它根据提供的标识符查找用户条目，通常是用户名；例如，uid 或 sAMAccountName 属性。向配置中添加 search-recursive="true" 以递归搜索目录。默认情况下，搜索用户条目使用 (rdn_identifier={0}) 过滤器。您可以使用 filter-name 属性指定不同的过滤器。

2.4.3. 将用户条目映射到其关联的组

在 LDAP 域配置中，指定 attribute-mapping 元素以检索和关联用户所属的所有组。

成员资格信息通常以两种方式存储：

在组条目下，通常具有 member 属性中的 class groupOfNames 或 groupOfUniqueNames。这是除 Active Directory 以外的大多数 LDAP 安装中的默认行为。在这种情况下，您可以使用属性过滤器。此过滤器搜索与提供的过滤器匹配的条目，该条目会找到与用户 DN 相等的 member 属性的组。然后，过滤器 提取 由指定的组条目的 CN，并将其添加到用户的 Role 中。
在 memberOf 属性的用户条目中。这通常是 Active Directory 的情况。在这种情况下，您应该使用如下属性引用：
<attribute-reference reference="memberOf" from="cn" to="Roles" />
此引用从用户条目获取所有 memberOf 属性，按照从指定 的方式 提取 CN，并将它们添加到用户的组中(角色是 用于映射组的内部名称)。

2.4.4. LDAP 域配置参考

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="ldap-realm">
        <!-- Specifies connection properties. -->
        <ldap-realm url="ldap://my-ldap-server:10389"
                    principal="uid=admin,ou=People,dc=infinispan,dc=org"
                    credential="strongPassword"
                    connection-timeout="3000"
                    read-timeout="30000"
                    connection-pooling="true"
                    referral-mode="ignore"
                    page-size="30"
                    direct-verification="true">
          <!-- Defines how principals are mapped to LDAP entries. -->
          <identity-mapping rdn-identifier="uid"
                            search-dn="ou=People,dc=infinispan,dc=org"
                            search-recursive="false">
            <!-- Retrieves all the groups of which the user is a member. -->
            <attribute-mapping>
              <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>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "ldap-realm",
        "ldap-realm": {
          "url": "ldap://my-ldap-server:10389",
          "principal": "uid=admin,ou=People,dc=infinispan,dc=org",
          "credential": "strongPassword",
          "connection-timeout": "3000",
          "read-timeout": "30000",
          "connection-pooling": "true",
          "referral-mode": "ignore",
          "page-size": "30",
          "direct-verification": "true",
          "identity-mapping": {
            "rdn-identifier": "uid",
            "search-dn": "ou=People,dc=infinispan,dc=org",
            "search-recursive": "false",
            "attribute-mapping": [{
              "from": "cn",
              "to": "Roles",
              "filter": "(&(objectClass=groupOfNames)(member={1}))",
              "filter-dn": "ou=Roles,dc=infinispan,dc=org"
            }]
          }
        }
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: ldap-realm
        ldapRealm:
          url: 'ldap://my-ldap-server:10389'
          principal: 'uid=admin,ou=People,dc=infinispan,dc=org'
          credential: strongPassword
          connectionTimeout: '3000'
          readTimeout: '30000'
          connectionPooling: true
          referralMode: ignore
          pageSize: '30'
          directVerification: true
          identityMapping:
            rdnIdentifier: uid
            searchDn: 'ou=People,dc=infinispan,dc=org'
            searchRecursive: false
            attributeMapping:
              - filter: '(&(objectClass=groupOfNames)(member={1}))'
                filterDn: 'ou=Roles,dc=infinispan,dc=org'
                from: cn
                to: Roles

2.4.4.1. LDAP 域主体重写

SASL 身份验证机制获取的主体，如 GSSAPI、GS2-KRB5 和 Negotiate 通常包括域名，例如 myuser@INFINISPAN.ORG。在 LDAP 查询中使用这些主体前，需要转换它们以确保其兼容性。这个过程被称为重写。

网格包括以下转换器：

case-principal-transformer	将主体重写为所有大写或所有小写。例如，`MyUser` 将以大写模式和 `myuser` 模式重写为 `MYUSER`。
common-name-principal-transformer	以 LDAP Distinguished Name 格式重写主体（由 RFC 4514定义）。它提取 `CN` (commonName)类型的第一个属性。例如，`DN=CN=myuser,OU=myorg,DC=mydomain` 将重写为 `myuser`。
regex-principal-transformer	使用带有捕获组的正则表达式重写主体，例如，用于提取任何子字符串。

2.4.4.2. LDAP 主体重写配置参考

问题单主体转换器

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="ldap-realm">
        <ldap-realm url="ldap://${org.infinispan.test.host.address}:10389"
                    principal="uid=admin,ou=People,dc=infinispan,dc=org"
                    credential="strongPassword">
          <name-rewriter>
            <!-- Defines a rewriter that transforms usernames to lowercase -->
            <case-principal-transformer uppercase="false"/>
          </name-rewriter>
          <!-- further configuration omitted -->
        </ldap-realm>
      </security-realm>
    </security-realms>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "ldap-realm",
        "ldap-realm": {
          "principal": "uid=admin,ou=People,dc=infinispan,dc=org",
          "url": "ldap://${org.infinispan.test.host.address}:10389",
          "credential": "strongPassword",
          "name-rewriter": {
            "case-principal-transformer": {
              "uppercase": false
            }
          }
        }
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "ldap-realm"
        ldapRealm:
          principal: "uid=admin,ou=People,dc=infinispan,dc=org"
          url: "ldap://${org.infinispan.test.host.address}:10389"
          credential: "strongPassword"
          nameRewriter:
            casePrincipalTransformer:
              uppercase: false
          # further configuration omitted

通用名称主体转换器

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="ldap-realm">
        <ldap-realm url="ldap://${org.infinispan.test.host.address}:10389"
                    principal="uid=admin,ou=People,dc=infinispan,dc=org"
                    credential="strongPassword">
          <name-rewriter>
            <!-- Defines a rewriter that obtains the first CN from a DN -->
            <common-name-principal-transformer />
          </name-rewriter>
          <!-- further configuration omitted -->
        </ldap-realm>
      </security-realm>
    </security-realms>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "ldap-realm",
        "ldap-realm": {
          "principal": "uid=admin,ou=People,dc=infinispan,dc=org",
          "url": "ldap://${org.infinispan.test.host.address}:10389",
          "credential": "strongPassword",
          "name-rewriter": {
            "common-name-principal-transformer": {}
          }
        }
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "ldap-realm"
        ldapRealm:
          principal: "uid=admin,ou=People,dc=infinispan,dc=org"
          url: "ldap://${org.infinispan.test.host.address}:10389"
          credential: "strongPassword"
          nameRewriter:
            commonNamePrincipalTransformer: ~
          # further configuration omitted

正则表达式主体转换器

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="ldap-realm">
        <ldap-realm url="ldap://${org.infinispan.test.host.address}:10389"
                    principal="uid=admin,ou=People,dc=infinispan,dc=org"
                    credential="strongPassword">
          <name-rewriter>
            <!-- Defines a rewriter that extracts the username from the principal using a regular expression. -->
            <regex-principal-transformer pattern="(.*)@INFINISPAN\.ORG"
                                         replacement="$1"/>
          </name-rewriter>
          <!-- further configuration omitted -->
        </ldap-realm>
      </security-realm>
    </security-realms>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "ldap-realm",
        "ldap-realm": {
          "principal": "uid=admin,ou=People,dc=infinispan,dc=org",
          "url": "ldap://${org.infinispan.test.host.address}:10389",
          "credential": "strongPassword",
          "name-rewriter": {
            "regex-principal-transformer": {
              "pattern": "(.*)@INFINISPAN\\.ORG",
              "replacement": "$1"
            }
          }
        }
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "ldap-realm"
        ldapRealm:
          principal: "uid=admin,ou=People,dc=infinispan,dc=org"
          url: "ldap://${org.infinispan.test.host.address}:10389"
          credential: "strongPassword"
          nameRewriter:
            regexPrincipalTransformer:
              pattern: (.*)@INFINISPAN\.ORG
              replacement: "$1"
          # further configuration omitted

2.4.4.3. 使用 Data Grid 的 LDAP 用户和组映射过程

本例演示了加载和内部将 LDAP 用户和组映射到 Data Grid 主题的过程。以下是 LDIF (LDAP 数据交换格式)文件，它描述了多个 LDAP 条目：

LDIF

# Users

dn: uid=root,ou=People,dc=infinispan,dc=org
objectclass: top
objectclass: uidObject
objectclass: person
uid: root
cn: root
sn: root
userPassword: strongPassword

# Groups

dn: cn=admin,ou=Roles,dc=infinispan,dc=org
objectClass: top
objectClass: groupOfNames
cn: admin
description: the Infinispan admin group
member: uid=root,ou=People,dc=infinispan,dc=org

dn: cn=monitor,ou=Roles,dc=infinispan,dc=org
objectClass: top
objectClass: groupOfNames
cn: monitor
description: the Infinispan monitor group
member: uid=root,ou=People,dc=infinispan,dc=org

root 用户是 admin 和 monitor 组的成员。

当使用密码 strongPassword 验证用户 root 的请求时，会在其中一个端点上执行以下操作：

使用所选主体转换器（可选）重写用户名。
realm 在 ou=People,dc=infinispan,dc=org 树中搜索，其 uid 属性等于 root，并查找 DN uid=root,ou=People,dc=infinispan,dc=org 的条目，这将成为用户主体。
realm 在 u=Roles,dc=infinispan,dc=org 树中搜索包含 member 属性中的 uid=root,ou=People,dc=infinispan,dc=org 的条目。在这种情况下，它找到两个条目： cn=admin,ou=Roles,dc=infinispan,dc=org 和 cn=monitor,ou=Roles,dc=infinispan,dc=org。从这些条目中，它会提取作为组主体的 cn 属性。

因此，生成的主题将类似如下：

NamePrincipal: uid=root,ou=People,dc=infinispan,dc=org
RolePrincipal: admin
RolePrincipal: monitor

此时，全局授权映射程序应用于上述主题，将主体转换为角色。然后，角色会扩展到一组权限，这些权限会根据请求的缓存和操作进行验证。

2.5. 令牌域

令牌域使用外部服务来验证令牌，并且需要与 RFC-7662 (OAuth2 Token Introspection)兼容的提供程序，如 Red Hat SSO。

令牌域配置

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="token-realm">
        <!-- Specifies the URL of the authentication server. -->
        <token-realm name="token"
                     auth-server-url="https://oauth-server/auth/">
          <!-- Specifies the URL of the token introspection endpoint. -->
          <oauth2-introspection introspection-url="https://oauth-server/auth/realms/infinispan/protocol/openid-connect/token/introspect"
                                client-id="infinispan-server"
                                client-secret="1fdca4ec-c416-47e0-867a-3d471af7050f"/>
        </token-realm>
      </security-realm>
    </security-realms>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "token-realm",
        "token-realm": {
          "auth-server-url": "https://oauth-server/auth/",
          "oauth2-introspection": {
            "client-id": "infinispan-server",
            "client-secret": "1fdca4ec-c416-47e0-867a-3d471af7050f",
            "introspection-url": "https://oauth-server/auth/realms/infinispan/protocol/openid-connect/token/introspect"
          }
        }
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: token-realm
        tokenRealm:
          authServerUrl: 'https://oauth-server/auth/'
          oauth2Introspection:
            clientId: infinispan-server
            clientSecret: '1fdca4ec-c416-47e0-867a-3d471af7050f'
            introspectionUrl: 'https://oauth-server/auth/realms/infinispan/protocol/openid-connect/token/introspect'

2.6. 信任存储域

信任存储域使用证书或证书链，在 Data Grid 服务器和客户端身份协商连接时验证 Data Grid 服务器和客户端身份。

keystores: 包含为客户端提供 Data Grid 服务器身份的服务器证书。如果您使用服务器证书配置密钥存储，Data Grid 服务器使用行业标准 SSL/TLS 协议加密流量。
信任存储: 包含客户端到 Data Grid 服务器的证书或证书链。客户端信任存储是可选的，并允许 Data Grid 服务器执行客户端证书身份验证。

客户端证书身份验证

如果您希望 Data Grid 服务器验证或验证客户端证书，您必须将 require-ssl-client-auth="true" 属性添加到端点配置。

信任存储域配置

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="trust-store-realm">
        <server-identities>
          <ssl>
            <!-- Provides an SSL/TLS identity with a keystore that contains server certificates. -->
            <keystore path="server.p12"
                      relative-to="infinispan.server.config.path"
                      keystore-password="secret"
                      alias="server"/>
            <!-- Configures a trust store that contains client certificates or part of a certificate chain. -->
            <truststore path="trust.p12"
                        relative-to="infinispan.server.config.path"
                        password="secret"/>
          </ssl>
        </server-identities>
        <!-- Authenticates client certificates against the trust store. If you configure this, the trust store must contain the public certificates for all clients. -->
        <truststore-realm/>
      </security-realm>
    </security-realms>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "trust-store-realm",
        "server-identities": {
          "ssl": {
            "keystore": {
              "path": "server.p12",
              "relative-to": "infinispan.server.config.path",
              "keystore-password": "secret",
              "alias": "server"
            },
            "truststore": {
              "path": "trust.p12",
              "relative-to": "infinispan.server.config.path",
              "password": "secret"
            }
          }
        },
        "truststore-realm": {}
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "trust-store-realm"
        serverIdentities:
          ssl:
            keystore:
              path: "server.p12"
              relative-to: "infinispan.server.config.path"
              keystore-password: "secret"
              alias: "server"
            truststore:
              path: "trust.p12"
              relative-to: "infinispan.server.config.path"
              password: "secret"
        truststoreRealm: ~

2.7. 分布式安全域

分布式域组合多种不同类型的安全域。当用户尝试访问 Hot Rod 或 REST 端点时，Data Grid 服务器依次使用每个安全域，直到找到可以执行身份验证的用户为止。

分布式域配置

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="distributed-realm">
        <ldap-realm url="ldap://my-ldap-server:10389"
                    principal="uid=admin,ou=People,dc=infinispan,dc=org"
                    credential="strongPassword">
          <identity-mapping rdn-identifier="uid"
                            search-dn="ou=People,dc=infinispan,dc=org"
                            search-recursive="false">
            <attribute-mapping>
              <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>
        <properties-realm groups-attribute="Roles">
          <user-properties path="users.properties"
                           relative-to="infinispan.server.config.path"/>
          <group-properties path="groups.properties"
                            relative-to="infinispan.server.config.path"/>
        </properties-realm>
        <distributed-realm/>
      </security-realm>
    </security-realms>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "distributed-realm",
        "ldap-realm": {
          "principal": "uid=admin,ou=People,dc=infinispan,dc=org",
          "url": "ldap://my-ldap-server:10389",
          "credential": "strongPassword",
          "identity-mapping": {
            "rdn-identifier": "uid",
            "search-dn": "ou=People,dc=infinispan,dc=org",
            "search-recursive": false,
            "attribute-mapping": {
              "attribute": {
                "filter": "(&(objectClass=groupOfNames)(member={1}))",
                "filter-dn": "ou=Roles,dc=infinispan,dc=org",
                "from": "cn",
                "to": "Roles"
              }
            }
          }
        },
        "properties-realm": {
          "groups-attribute": "Roles",
          "user-properties": {
            "digest-realm-name": "distributed-realm",
            "path": "users.properties"
          },
          "group-properties": {
            "path": "groups.properties"
          }
        },
        "distributed-realm": {}
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "distributed-realm"
        ldapRealm:
          principal: "uid=admin,ou=People,dc=infinispan,dc=org"
          url: "ldap://my-ldap-server:10389"
          credential: "strongPassword"
          identityMapping:
            rdnIdentifier: "uid"
            searchDn: "ou=People,dc=infinispan,dc=org"
            searchRecursive: "false"
            attributeMapping:
              attribute:
                filter: "(&(objectClass=groupOfNames)(member={1}))"
                filterDn: "ou=Roles,dc=infinispan,dc=org"
                from: "cn"
                to: "Roles"
        propertiesRealm:
          groupsAttribute: "Roles"
          userProperties:
            digestRealmName: "distributed-realm"
            path: "users.properties"
          groupProperties:
            path: "groups.properties"
        distributedRealm: ~

2.8. 聚合安全域

聚合域组合多个域：用于身份验证步骤的第一个域，另一个用于加载授权步骤的身份。例如，这可用于通过客户端证书验证用户身份，并从属性或 LDAP 域检索身份。

聚合域配置

XML

<server xmlns="urn:infinispan:server:15.0">
   <security>
      <security-realms>
         <security-realm name="default" default-realm="aggregate">
            <server-identities>
               <ssl>
                  <keystore path="server.pfx" password="secret" alias="server"/>
                  <truststore path="trust.pfx" password="secret"/>
               </ssl>
            </server-identities>
            <properties-realm name="properties" groups-attribute="Roles">
               <user-properties path="users.properties" relative-to="infinispan.server.config.path"/>
               <group-properties path="groups.properties" relative-to="infinispan.server.config.path"/>
            </properties-realm>
            <truststore-realm name="trust"/>
            <aggregate-realm authentication-realm="trust" authorization-realms="properties">
               <name-rewriter>
                  <common-name-principal-transformer/>
               </name-rewriter>
            </aggregate-realm>
         </security-realm>
      </security-realms>
   </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [
        {
          "name": "aggregate-realm",
          "default-realm": "aggregate",
          "server-identities": {
            "ssl": {
              "keystore": {
                "path": "server.p12",
                "relative-to": "infinispan.server.config.path",
                "keystore-password": "secret",
                "alias": "server"
              },
              "truststore": {
                "path": "trust.p12",
                "relative-to": "infinispan.server.config.path",
                "password": "secret"
              }
            }
          },
          "properties-realm": {
            "name": "properties",
            "groups-attribute": "Roles",
            "user-properties": {
              "digest-realm-name": "distributed-realm",
              "path": "users.properties"
            },
            "group-properties": {
              "path": "groups.properties"
            }
          },
          "truststore-realm": {
            "name": "trust"
          },
          "aggregate-realm": {
            "authentication-realm": "trust",
            "authorization-realms": ["properties"],
            "name-rewriter": {
              "common-name-principal-transformer": {}
            }
          }
        }
      ]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "aggregate-realm"
        defaultRealm: "aggregate"
        serverIdentities:
          ssl:
            keystore:
              path: "server.p12"
              relative-to: "infinispan.server.config.path"
              keystore-password: "secret"
              alias: "server"
            truststore:
              path: "trust.p12"
              relative-to: "infinispan.server.config.path"
              password: "secret"
        truststoreRealm:
          name: "trust"
        propertiesRealm:
          name: "properties"
          groupsAttribute: "Roles"
          userProperties:
            digestRealmName: "distributed-realm"
            path: "users.properties"
          groupProperties:
            path: "groups.properties"
        aggregateRealm:
          authenticationRealm: "trust"
          authorizationRealms:
            - "properties"
          nameRewriter:
            common-name-principal-transformer: ~

2.8.1. name rewriters

主体名称可能具有不同的表单，具体取决于安全域类型：

属性和令牌域可能会返回简单字符串
信任和 LDAP 域可能会返回 X.500 风格的可分辨名称
Kerberos 域可以返回 user@domain风格名称

在使用聚合域时使用以下转换器之一时，名称必须规范化为通用形式。

2.8.1.1. case Principal Transformer

case-principal-transformer 将名称转换为所有大写字母或所有小写字母。

XML

<aggregate-realm authentication-realm="trust" authorization-realms="properties">
   <name-rewriter>
      <case-principal-transformer uppercase="false"/>
   </name-rewriter>
</aggregate-realm>

JSON

{
  "aggregate-realm": {
    "authentication-realm": "trust",
    "authorization-realms": [
      "properties"
    ],
    "name-rewriter": {
      "case-principal-transformer": {
        "uppercase": "false"
      }
    }
  }
}

YAML

aggregateRealm:
  authenticationRealm: "trust"
  authorizationRealms:
    - "properties"
  nameRewriter:
    casePrincipalTransformer:
      uppercase: false

2.8.1.2. 通用名称 Principal Transformer

common-name-principal-transformer 从 LDAP 或证书使用的 DN 中提取第一个 CN 元素。例如，假设一个主体，格式为 CN=app1,CN=serviceA,OU=applications,DC=infinispan,DC=org，以下配置将提取 app1 作为主体。

XML

<aggregate-realm authentication-realm="trust" authorization-realms="properties">
   <name-rewriter>
      <common-name-principal-transformer/>
   </name-rewriter>
</aggregate-realm>

JSON

{
  "aggregate-realm": {
    "authentication-realm": "trust",
    "authorization-realms": [
      "properties"
    ],
    "name-rewriter": {
      "common-name-principal-transformer": {}
    }
  }
}

YAML

aggregateRealm:
  authenticationRealm: "trust"
  authorizationRealms:
    - "properties"
  nameRewriter:
    commonNamePrincipalTransformer: ~

2.8.1.3. regex Principal Transformer

regex-principal-transformer 可以使用正则表达式执行 find 和 replace。这个示例演示了如何从 user@domain.com 标识符中提取本地部分。

XML

<aggregate-realm authentication-realm="trust" authorization-realms="properties">
   <name-rewriter>
      <regex-principal-transformer pattern="([^@]+)@.*" replacement="$1" replace-all="false"/>
   </name-rewriter>
</aggregate-realm>

JSON

{
  "aggregate-realm": {
    "authentication-realm": "trust",
    "authorization-realms": [
      "properties"
    ],
    "name-rewriter": {
      "regex-principal-transformer": {
        "pattern" : "([^@]+)@.*",
        "replacement": "$1",
        "replace-all": false
      }
    }
  }
}

YAML

aggregateRealm:
  authenticationRealm: "trust"
  authorizationRealms:
    - "properties"
  nameRewriter:
    regexPrincipalTransformer:
      pattern: "([^@]+)@.*"
      replacement: "$1"
      replaceAll: false

2.9. 安全域缓存

安全域实施缓存，以避免重复检索通常更改的数据。默认

realm 缓存域配置

XML

<server xmlns="urn:infinispan:server:15.0">
    <security>
        <security-realms>
            <security-realm name="default" cache-max-size="1024" cache-lifespan="120000">
            </security-realm>
        </security-realms>
    </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "default",
        "cache-max-size": 1024,
        "cache-lifespan": 120000
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "default"
        cache-max-size: 1024
        cache-lifespan: 120000

2.9.1. 清空域缓存

使用 CLI 刷新整个集群中的安全域缓存。

[node-1@mycluster//containers/default]> server aclcache flush

第 3 章端点身份验证机制

Data Grid 服务器可以为 Hot Rod 和 REST 端点使用自定义 SASL 和 HTTP 身份验证机制。

3.1. Data Grid 服务器身份验证

身份验证限制用户访问端点，以及 Data Grid 控制台和命令行界面(CLI)。

Data Grid 服务器包括一个"默认"安全域，用于强制实施用户身份验证。默认身份验证使用属性 realm，其用户凭证存储在 server/conf/users.properties 文件中。Data Grid 服务器还默认启用安全授权，因此您必须为用户授予存储在 server/conf/groups.properties 文件中的权限。

提示

通过命令行接口(CLI)使用 user create 命令来添加用户并分配权限。运行 user create --help 获取示例和更多信息。

3.2. 配置 Data Grid 服务器身份验证机制

您可以明确配置 Hot Rod 和 REST 端点，以使用特定的身份验证机制。只有在需要显式覆盖安全域的默认机制时，才需要配置验证机制。

注意

配置中的每个 endpoint 部分都必须包含 hotrod-connector 和 rest-connector 元素或字段。例如，如果您明确声明了 hotrod-connector，还必须声明 rest-connector，即使它没有配置身份验证机制。

先决条件

根据需要，将安全域添加到您的 Data Grid 服务器配置。

流程

打开 Data Grid Server 配置以进行编辑。
添加 endpoint 元素或字段，并指定它与 security-realm 属性一起使用的安全域。
添加 hotrod-connector 元素或字段来配置 Hot Rod 端点。
1. 添加 authentication 元素或字段。
2. 为 Hot Rod 端点指定 SASL 身份验证机制，以用于 sasl 机制 属性。
3. 如果适用，使用 qop 属性指定保护设置的 SASL 质量。
4. 如有必要，使用 server-name 属性指定 Data Grid 服务器身份。
添加 rest-connector 元素或字段来配置 REST 端点。
1. 添加 authentication 元素或字段。
2. 为 REST 端点指定用于 mechanism 属性的 HTTP 身份验证机制。
保存对配置的更改。

身份验证机制配置

以下配置指定了用于身份验证的 Hot Rod 端点的 SASL 机制：

XML

<server xmlns="urn:infinispan:server:15.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. 禁用身份验证

在本地开发环境或隔离网络中，您可以将 Data Grid 配置为允许未经身份验证的客户端请求。当您禁用用户身份验证时，您还应在 Data Grid 安全配置中禁用授权。

流程

打开 Data Grid Server 配置以进行编辑。
从 endpoint 元素或字段中删除 security-realm 属性。
从 cache-container 的安全配置和每个缓存配置中删除任何 授权 元素。
保存对配置的更改。

XML

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

JSON

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

YAML

server:
  endpoints:
    endpoint:
      socketBinding: "default"

3.3. Data Grid 服务器身份验证机制

Data Grid 服务器使用与您的安全域配置匹配的验证机制自动配置端点。例如，如果您添加 Kerberos 安全域，则 Data Grid 服务器为 Hot Rod 端点启用 GSSAPI 和 GS2-KRB5 身份验证机制。

重要

目前，您不能将轻量级目录访问协议(LDAP)协议与 DIGEST 或 SCRAM 身份验证机制一起使用，因为这些机制需要访问特定的散列密码。

热 Rod 端点

当您的配置包含对应的安全域时，Data Grid 服务器为 Hot Rod 端点启用以下 SASL 身份验证机制：

安全域	SASL 身份验证机制
属性域和 LDAP 域	`SCRAM`，`摘要`
令牌域	`OAUTHBEARER`
信任域	`EXTERNAL`
Kerberos 身份	`GSSAPI`, `GS2-KRB5`
SSL/TLS 身份	`PLAIN`

REST 端点

当您的配置包含对应的安全域时，Data Grid 服务器为 REST 端点启用以下 HTTP 身份验证机制：

安全域	HTTP 身份验证机制
属性域和 LDAP 域	`摘要`
令牌域	`BEARER_TOKEN`
信任域	`CLIENT_CERT`
Kerberos 身份	`SPNEGO`
SSL/TLS 身份	`BASIC`

memcached 端点

当您的配置包含对应的安全域时，Data Grid 服务器为 Memcached 二进制协议端点启用以下 SASL 身份验证机制：

安全域	SASL 身份验证机制
属性域和 LDAP 域	`SCRAM`，`摘要`
令牌域	`OAUTHBEARER`
信任域	`EXTERNAL`
Kerberos 身份	`GSSAPI, GS2-KRB5`
SSL/TLS 身份	`PLAIN`

Data Grid 服务器仅在 Memcached 文本协议端点上启用身份验证，只有支持基于密码的身份验证的安全域：

安全域	Memcached 文本身份验证
属性域和 LDAP 域	是
令牌域	否
信任域	否
Kerberos 身份	否
SSL/TLS 身份	否

RESP 端点

Data Grid 服务器仅在支持基于密码的身份验证的安全域中启用 RESP 端点身份验证：

安全域	RESP 身份验证
属性域和 LDAP 域	是
令牌域	否
信任域	否
Kerberos 身份	否
SSL/TLS 身份	否

3.3.1. SASL 身份验证机制

Data Grid 服务器支持使用 Hot Rod 和 Memcached 二进制协议端点的以下 SASL 验证机制：

身份验证机制	描述	安全域类型	相关详情
`PLAIN`	以纯文本格式使用凭据。您应该只在加密连接中使用 `PLAIN` 身份验证。	属性域和 LDAP 域	与 `BASIC` HTTP 机制类似。
`DIGESTJPEG`	使用哈希算法和非ce 值。热 Rod 连接器支持 `DIGEST-MD` 5、`DIGEST-SHA` -256、`DIGEST-SHA-256`、`DIGEST-SHA-384` 和 `DIGEST-SHA-512` 哈希算法，以强度顺序。	属性域和 LDAP 域	与 `Digest` HTTP 机制类似。
`SCRAM-*`	除了哈希算法和非ce 值外，还使用 salt 值。热 Rod 连接器支持 `SCRAM-SHA`、`SCRAM-SHA-256`、`SCRAM-SHA-384` 和 `SCRAM-SHA-512` 哈希算法（按强度排序）。	属性域和 LDAP 域	与 `Digest` HTTP 机制类似。
`GSSAPI`	使用 Kerberos 票据并需要一个 Kerberos 域控制器。您必须在 realm 配置中添加对应的 `kerberos` 服务器身份。在大多数情况下，您还指定一个 `ldap-realm` 来提供用户成员资格信息。	Kerberos realm	与 `SPNEGO` HTTP 机制类似。
`GS2-KRB5`	使用 Kerberos 票据并需要一个 Kerberos 域控制器。您必须在 realm 配置中添加对应的 `kerberos` 服务器身份。在大多数情况下，您还指定一个 `ldap-realm` 来提供用户成员资格信息。	Kerberos realm	与 `SPNEGO` HTTP 机制类似。
`EXTERNAL`	使用客户端证书。	信任存储域	与 `CLIENT_CERT` HTTP 机制类似。
`OAUTHBEARER`	使用 OAuth 令牌并需要一个 `token-realm` 配置。	令牌域	与EARER `_TOKEN` HTTP 机制类似。

3.3.2. SASL 质量保护(QoP)

如果 SASL 机制支持完整性和隐私保护(QoP)设置，您可以使用 qop 属性将它们添加到 Hot Rod 和 Memcached 端点配置中。

QoP 设置	描述
`auth`	仅进行身份验证。
`auth-int`	使用完整性保护进行身份验证。
`auth-conf`	通过完整性和隐私保护进行身份验证。

3.3.3. SASL 策略

SASL 策略提供对 Hot Rod 和 Memcached 身份验证机制的精细控制。

提示

Data Grid 缓存授权根据角色和权限限制对缓存的访问。配置缓存授权，然后设置 &lt ;no-anonymous value=false /& gt; 以允许匿名登录，并将访问逻辑委派给缓存授权。

policy	描述	默认值
`forward-secrecy`	仅使用支持会话间转发保密的 SASL 机制。这意味着，破坏一个会话不会自动提供破坏未来会话的信息。	false
`pass-credentials`	仅使用需要客户端凭证的 SASL 机制。	false
`no-plain-text`	不要使用容易受到简单普通被动攻击的 SASL 机制。	false
`no-active`	不要使用容易被活跃、非字典攻击的 SASL 机制。	false
`no-dictionary`	不要使用容易受到被动字典攻击的 SASL 机制。	false
`no-anonymous`	不要使用接受匿名登录的 SASL 机制。	true

SASL 策略配置

在以下配置中，Hot Rod 端点使用 GSSAPI 机制进行身份验证，因为它是唯一符合所有 SASL 策略的机制：

XML

<server xmlns="urn:infinispan:server:15.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 身份验证机制

Data Grid 服务器支持带有 REST 端点的以下 HTTP 身份验证机制：

身份验证机制	描述	安全域类型	相关详情
`BASIC`	以纯文本格式使用凭据。您应该只使用带有加密连接的 `BASIC` 身份验证。	属性域和 LDAP 域	对应于 `基本` HTTP 验证方案，类似于 `PLAIN` SASL 机制。
`摘要`	使用哈希算法和非ce 值。REST 连接器支持 `SHA-512`、`SHA-256` 和 `MD5` 哈希算法。	属性域和 LDAP 域	对应于 `Digest` HTTP 验证方案，类似于 `DIGESTGPU` SASL 机制。
`SPNEGO`	使用 Kerberos 票据并需要一个 Kerberos 域控制器。您必须在 realm 配置中添加对应的 `kerberos` 服务器身份。在大多数情况下，您还指定一个 `ldap-realm` 来提供用户成员资格信息。	Kerberos realm	对应于 `Negotiate` HTTP 验证方案，类似于 `GSSAPI` 和 `GS2-KRB5` SASL 机制。
`BEARER_TOKEN`	使用 OAuth 令牌并需要一个 `token-realm` 配置。	令牌域	对应于 `Bearer` HTTP 身份验证方案，类似于 `OAUTHBEARER` SASL 机制。
`CLIENT_CERT`	使用客户端证书。	信任存储域	与 `EXTERNAL` SASL 机制类似。

第 4 章配置 TLS/SSL 加密

您可以通过配置包含 Data Grid 公钥的密钥存储来保护使用 SSL/TLS 加密的数据网格服务器连接。如果需要 mutual TLS，您还可以配置客户端证书身份验证。

4.1. 配置 Data Grid 服务器密钥存储

将密钥存储添加到 Data Grid 服务器，并将它配置为提供验证客户端身份的 SSL/TLS 证书。如果安全域包含 TLS/SSL 身份，它会加密到使用该安全域的 Data Grid 服务器端点的任何连接。

先决条件

为 Data Grid 服务器创建一个包含证书或证书链的密钥存储。

Data Grid 服务器支持以下密钥存储格式：JKS、JCEKS、PKCS12/PFX 和 PEM。如果存在 Bouncy Castle 库，则也支持 BKS、BCFKS 和 UBER。

证书应包含类型为 dNSName 和/或 iPAddress 的 subjectAltName 扩展，以便客户端可以根据 RFC 2818 规格定义的规则正确执行主机名验证。如果使用不包括此类扩展的证书启动，服务器将发出警告。

重要

在生产环境中，服务器证书应由受信任的证书颁发机构( Root 或 Intermediate CA)签名。

提示

如果以下两者都包含，您可以使用 PEM 文件作为密钥存储：

PKCS1/ 或 PKCS""8 格式的私钥。
一个或多个证书。

您还应该使用空密码配置 PEM 文件密钥存储(password="")。

流程

打开 Data Grid Server 配置以进行编辑。
将包含 Data Grid 服务器的 SSL/TLS 身份的密钥存储添加到 $RHDG_HOME/server/conf 目录中。
在 Data Grid Server 安全域中添加 server-identities 定义。
使用 path 属性指定密钥存储文件名。
使用 keystore-password 和 alias 属性提供密钥存储密码和证书别名。
保存对配置的更改。

后续步骤

使用信任存储配置客户端，以便它们能够验证 Data Grid 服务器的 SSL/TLS 身份。

密钥存储配置

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="default">
        <server-identities>
          <ssl>
            <!-- Adds a keystore that contains server certificates that provide SSL/TLS identities to clients. -->
            <keystore path="server.p12"
                      relative-to="infinispan.server.config.path"
                      password="secret"
                      alias="my-server"/>
          </ssl>
        </server-identities>
      </security-realm>
    </security-realms>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "default",
        "server-identities": {
          "ssl": {
            "keystore": {
              "alias": "my-server",
              "path": "server.p12",
              "password": "secret"
            }
          }
        }
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "default"
        serverIdentities:
          ssl:
            keystore:
              alias: "my-server"
              path: "server.p12"
              password: "secret"

4.1.1. SSL/TLS 证书轮转

SSL/TLS 证书具有过期日期，之后它们已不再有效。续订证书的过程也称为"轮转"。网格监控密钥存储文件是否有变化，并在不需要服务器或客户端重启的情况下自动重新载入它们。

注意

要在证书轮转过程中确保无缝操作，请使用由证书颁发机构(CA)签名的证书，并使用 CA 证书配置服务器和客户端信任存储。使用自签名证书将导致临时握手失败，直到所有客户端和服务器都已更新。

其他资源

配置 Hot Rod 客户端加密

4.1.2. 生成 Data Grid 服务器密钥存储

配置 Data Grid 服务器，以在启动时自动生成密钥存储。

重要

自动生成的密钥存储：

不应该在生产环境中使用。
在需要时会生成；例如，从客户端获取第一个连接时。
包含您可以在 Hot Rod 客户端中直接使用的证书。

流程

打开 Data Grid Server 配置以进行编辑。
在服务器配置中包含 keystore 元素的 generate-self-signed-certificate-host 属性。
指定服务器证书的主机名作为值。
保存对配置的更改。

生成的密钥存储配置

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="generated-keystore">
        <server-identities>
          <ssl>
            <!-- Generates a keystore that includes a self-signed certificate with the specified hostname. -->
            <keystore path="server.p12"
                      relative-to="infinispan.server.config.path"
                      password="secret"
                      alias="server"
                      generate-self-signed-certificate-host="localhost"/>
          </ssl>
        </server-identities>
      </security-realm>
    </security-realms>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "generated-keystore",
        "server-identities": {
          "ssl": {
            "keystore": {
              "alias": "server",
              "generate-self-signed-certificate-host": "localhost",
              "path": "server.p12",
              "password": "secret"
            }
          }
        }
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "generated-keystore"
        serverIdentities:
          ssl:
            keystore:
              alias: "server"
              generateSelfSignedCertificateHost: "localhost"
              path: "server.p12"
              password: "secret"

4.1.3. 配置 TLS 版本和密码套件

当使用 SSL/TLS 加密来保护部署时，您可以将 Data Grid 服务器配置为使用 TLS 协议的特定版本以及协议中的特定加密套件。

流程

打开 Data Grid Server 配置以进行编辑。
将 engine 元素添加到 Data Grid 服务器的 SSL 配置中。
将 Data Grid 配置为使用带有 enabled-protocols 属性的一个或多个 TLS 版本。
默认情况下，Data Grid 服务器支持 TLS 版本 1.2 和 1.3。如果适当，您可以设置 TLSv1.3 仅来限制客户端连接的安全协议。网格不推荐启用 TLSv1.1，因为它是支持有限且提供弱安全性的旧协议。您不应该启用任何早于 1.1 的 TLS 版本。
警告
如果您修改了 Data Grid 服务器的 SSL 引擎 配置，则必须使用 enabled-protocols 属性显式配置 TLS 版本。省略 enabled-protocols 属性允许任何 TLS 版本。
```
<engine enabled-protocols="TLSv1.3 TLSv1.2" />
```
将 Data Grid 配置为使用带有 enabled-ciphersuites 属性(TLSv1.2 和 below)和 enabled-ciphersuites-tls13 属性（用于 TLSv1.3）的一个或多个密码套件。
您必须确保设置了支持您计划使用的任何协议功能的密码套件；例如 HTTP/2 ALPN。
保存对配置的更改。

SSL 引擎配置

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="default">
        <server-identities>
          <ssl>
            <keystore path="server.p12"
                      relative-to="infinispan.server.config.path"
                      password="secret"
                      alias="server"/>
            <!-- Configures Data Grid Server to use specific TLS versions and cipher suites. -->
            <engine enabled-protocols="TLSv1.3 TLSv1.2"
                    enabled-ciphersuites="TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA256"
                    enabled-ciphersuites-tls13="TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"/>
          </ssl>
        </server-identities>
      </security-realm>
    </security-realms>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "default",
        "server-identities": {
          "ssl": {
            "keystore": {
              "alias": "server",
              "path": "server.p12",
              "password": "secret"
            },
            "engine": {
              "enabled-protocols": ["TLSv1.3"],
              "enabled-ciphersuites": "TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA256",
              "enabled-ciphersuites-tls13": "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
            }
          }
        }
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "default"
        serverIdentities:
          ssl:
            keystore:
              alias: "server"
              path: "server.p12"
              password: "secret"
            engine:
              enabledProtocols:
                - "TLSv1.3"
              enabledCiphersuites: "TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256"
              enabledCiphersuitesTls13: "TLS_AES_256_GCM_SHA384"

4.2. 在具有 FIPS 140-2 兼容加密的系统中配置 Data Grid 服务器

FIPS (Federal Information Processing Standards)是美国联邦计算机系统的标准和准则。虽然 FIPS 由美国联邦政府开发，但许多在私有部门的自愿使用这些标准。

FIPS 140-2 定义加密模块的安全要求。您可以使用替代 JDK 安全供应商，将 Data Grid 服务器配置为使用遵循 FIPS 140-2 规格的加密密码。

其他资源

4.2.1. 配置 PKCS11 加密供应商

您可以使用 SunPKCS11-NSS-FIPS 供应商指定 PKCS11 密钥存储来配置 PKCS11 加密供应商。

先决条件

为 FIPS 模式配置您的系统。您可以通过在 Data Grid 命令行界面(CLI)中发出 fips-mode-setup --check 命令检查您的系统是否启用了 FIPS 模式。
使用 certutil 工具初始化系统范围 NSS 数据库。
使用配置为启用 SunPKCS11 提供程序的 java.security 文件安装 JDK。这个供应商指向 NSS 数据库和 SSL 供应商。
在 NSS 数据库中安装证书。

流程

打开 Data Grid Server 配置以进行编辑。
在 Data Grid Server 安全域中添加 server-identities 定义。
使用 SunPKCS11-NSS-FIPS 供应商指定 PKCS11 密钥存储。
保存对配置的更改。

密钥存储配置

XML

<server xmlns="urn:infinispan:server:15.0">
   <security>
      <security-realms>
         <security-realm name="default">
            <server-identities>
               <ssl>
                  <!-- Adds a keystore that reads certificates from the NSS database. -->
                  <keystore provider="SunPKCS11-NSS-FIPS" type="PKCS11"/>
               </ssl>
            </server-identities>
         </security-realm>
      </security-realms>
   </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "default",
        "server-identities": {
          "ssl": {
            "keystore": {
              "provider": "SunPKCS11-NSS-FIPS",
              "type": "PKCS11"
            }
          }
        }
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "default"
        serverIdentities:
          ssl:
            keystore:
              provider: "SunPKCS11-NSS-FIPS"
              type: "PKCS11"

4.2.2. 配置 Bouncy Castle FIPS 加密供应商

您可以在 Data Grid 服务器的配置中配置 Bouncy Castle FIPS (Federal Information Processing Standards)加密供应商。

先决条件

为 FIPS 模式配置您的系统。您可以通过在 Data Grid 命令行界面(CLI)中发出 fips-mode-setup --check 命令检查您的系统是否启用了 FIPS 模式。
以 BCFKS 格式创建包含证书的密钥存储。

流程

下载 Bouncy Castle FIPS JAR 文件，并将该文件添加到 Data Grid Server 安装的 server/lib 目录中。

要安装 Bouncy Castle，请发出 install 命令：

[disconnected]> install org.bouncycastle:bc-fips:1.0.2.3

打开 Data Grid Server 配置以进行编辑。
在 Data Grid Server 安全域中添加 server-identities 定义。
使用 BCFIPS 提供程序指定 BCFKS 密钥存储。
保存对配置的更改。

密钥存储配置

XML

<server xmlns="urn:infinispan:server:15.0">
   <security>
      <security-realms>
         <security-realm name="default">
            <server-identities>
               <ssl>
                  <!-- Adds a keystore that reads certificates from the BCFKS keystore. -->
                  <keystore path="server.bcfks" password="secret" alias="server" provider="BCFIPS" type="BCFKS"/>
               </ssl>
            </server-identities>
         </security-realm>
      </security-realms>
   </security>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "default",
        "server-identities": {
          "ssl": {
            "keystore": {
              "path": "server.bcfks",
              "password": "secret",
              "alias": "server",
              "provider": "BCFIPS",
              "type": "BCFKS"
            }
          }
        }
      }]
    }
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "default"
        serverIdentities:
          ssl:
            keystore:
              path: "server.bcfks"
              password: "secret"
              alias: "server"
              provider: "BCFIPS"
              type: "BCFKS"

4.3. 配置客户端证书身份验证

将 Data Grid 服务器配置为使用 mutual TLS 来保护客户端连接。

您可以通过两种方式将 Data Grid 配置为以两种方式从信任存储中验证证书的客户端身份：

需要仅包含签名证书的信任存储，通常是证书颁发机构(CA)。任何提供 CA 签名的证书的客户端都可以连接到 Data Grid。
除了签名证书外，还需要包含所有客户端证书的信任存储。只有提供信任存储中存在的签名证书的客户端才能连接到 Data Grid。

提示

另外，您还可以提供信任存储，您可以使用共享系统证书。

先决条件

创建包含 CA 证书或所有公共证书的客户端信任存储。
为 Data Grid 服务器创建一个密钥存储，并配置 SSL/TLS 身份。

注意

PEM 文件可以用作信任存储，只要它们包含一个或多个证书。这些信任存储应该配置空密码： password=""。

流程

打开 Data Grid Server 配置以进行编辑。
将 require-ssl-client-auth="true" 参数添加到您的 端点 配置中。
将客户端信任存储添加到 $RHDG_HOME/server/conf 目录中。
在 Data Grid Server 安全域配置中，指定 truststore 元素 的路径 和密码 属性。
如果您希望 Data Grid 服务器验证每个客户端证书，请将 < truststore-realm /> 元素添加到安全域中。
保存对配置的更改。

后续步骤

如果使用安全角色和权限控制访问权限，请在 Data Grid 服务器配置中设置授权。
将客户端配置为与 Data Grid 服务器协商 SSL/TLS 连接。

客户端证书身份验证配置

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="trust-store-realm">
        <server-identities>
          <ssl>
            <!-- Provides an SSL/TLS identity with a keystore that
                 contains server certificates. -->
            <keystore path="server.p12"
                      relative-to="infinispan.server.config.path"
                      keystore-password="secret"
                      alias="server"/>
            <!-- Configures a trust store that contains client certificates
                 or part of a certificate chain. -->
            <truststore path="trust.p12"
                        relative-to="infinispan.server.config.path"
                        password="secret"/>
          </ssl>
        </server-identities>
        <!-- Authenticates client certificates against the trust store. If you configure this, the trust store must contain the public certificates for all clients. -->
        <truststore-realm/>
      </security-realm>
    </security-realms>
  </security>
  <endpoints>
    <endpoint socket-binding="default"
              security-realm="trust-store-realm"
              require-ssl-client-auth="true">
      <hotrod-connector>
        <authentication>
          <sasl mechanisms="EXTERNAL"
                server-name="infinispan"
                qop="auth"/>
        </authentication>
      </hotrod-connector>
      <rest-connector>
        <authentication mechanisms="CLIENT_CERT"/>
      </rest-connector>
    </endpoint>
  </endpoints>
</server>

JSON

{
  "server": {
    "security": {
      "security-realms": [{
        "name": "trust-store-realm",
        "server-identities": {
          "ssl": {
            "keystore": {
              "path": "server.p12",
              "relative-to": "infinispan.server.config.path",
              "keystore-password": "secret",
              "alias": "server"
            },
            "truststore": {
              "path": "trust.p12",
              "relative-to": "infinispan.server.config.path",
              "password": "secret"
            }
          }
        },
        "truststore-realm": {}
      }]
    },
    "endpoints": [{
      "socket-binding": "default",
      "security-realm": "trust-store-realm",
      "require-ssl-client-auth": "true",
      "connectors": {
        "hotrod": {
          "hotrod-connector": {
            "authentication": {
              "sasl": {
                "mechanisms": "EXTERNAL",
                "server-name": "infinispan",
                "qop": "auth"
              }
            }
          },
          "rest": {
            "rest-connector": {
              "authentication": {
                "mechanisms": "CLIENT_CERT"
              }
            }
          }
        }
      }
    }]
  }
}

YAML

server:
  security:
    securityRealms:
      - name: "trust-store-realm"
        serverIdentities:
          ssl:
            keystore:
              path: "server.p12"
              relative-to: "infinispan.server.config.path"
              keystore-password: "secret"
              alias: "server"
            truststore:
              path: "trust.p12"
              relative-to: "infinispan.server.config.path"
              password: "secret"
        truststoreRealm: ~
  endpoints:
    socketBinding: "default"
    securityRealm: "trust-store-realm"
    requireSslClientAuth: "true"
    connectors:
      - hotrod:
          hotrodConnector:
            authentication:
              sasl:
                mechanisms: "EXTERNAL"
                serverName: "infinispan"
                qop: "auth"
      - rest:
          restConnector:
            authentication:
              mechanisms: "CLIENT_CERT"

其他资源

配置 Hot Rod 客户端加密
使用共享系统证书 (Red Hat Enterprise Linux 7 安全指南)

4.4. 使用客户端证书配置授权

启用客户端证书身份验证意味着您不需要在客户端配置中指定 Data Grid 用户凭证，这意味着您必须将角色与客户端证书中的通用名称(CN)字段关联。

先决条件

为客户端提供包含其公共证书的 Java 密钥存储或证书链的一部分，通常是公共 CA 证书。
配置 Data Grid 服务器，以执行客户端证书身份验证。

流程

打开 Data Grid Server 配置以进行编辑。
在安全授权配置中启用 common-name-role-mapper。
从客户端证书分配具有适当权限的角色的通用名称(CN)。
保存对配置的更改。

注意

Data Grid 通过提取证书主体来创建客户端的身份。当前会忽略证书中存在的任何其他主题备用名称(SAN)。因此，以下 authorization.group-only-mapping 属性必须设置为 false。

客户端证书授权配置

XML

<infinispan>
  <cache-container name="certificate-authentication" statistics="true">
    <security>
      <authorization group-only-mapping="false">
        <!-- Declare a role mapper that associates the common name (CN) field in client certificate trust stores with authorization roles. -->
        <common-name-role-mapper/>
        <!-- In this example, if a client certificate contains `CN=Client1` then clients with matching certificates get ALL permissions. -->
        <role name="Client1" permissions="ALL"/>
      </authorization>
    </security>
  </cache-container>
</infinispan>

JSON

{
  "infinispan": {
    "cache-container": {
      "name": "certificate-authentication",
      "security": {
        "authorization": {
          "group-only-mapping": false,
          "common-name-role-mapper": null,
          "roles": {
            "Client1": {
              "role": {
                "permissions": "ALL"
              }
            }
          }
        }
      }
    }
  }
}

YAML

infinispan:
  cacheContainer:
    name: "certificate-authentication"
    security:
      authorization:
        groupOnlyMapping: false
        commonNameRoleMapper: ~
        roles:
          Client1:
            role:
              permissions:
                - "ALL"

第 5 章在密钥存储中存储 Data Grid 服务器凭证

外部服务需要凭证才能使用 Data Grid 服务器进行身份验证。为了保护敏感文本字符串，如密码，请将它们添加到凭据密钥存储中，而不是直接在 Data Grid 服务器配置文件中。

然后，您可以将 Data Grid 服务器配置为解密密码，以与数据库或 LDAP 目录等服务建立连接。

重要

$RHDG_HOME/server/conf 中的纯文本密码是未加密的。任何对主机文件系统具有读取访问权限的用户帐户都可以查看纯文本密码。

虽然凭据密钥存储是受密码保护的存储密码，但对主机文件系统具有写入访问权限的任何用户帐户都可以被密钥存储本身篡改。

要完全保护 Data Grid 服务器凭证，您应该只向可以配置和运行 Data Grid Server 的用户帐户授予读写访问权限。

5.1. 设置凭据密钥存储

创建密钥存储来加密 Data Grid 服务器访问的凭据。

凭据密钥存储至少包含一个与加密密码关联的别名。创建密钥存储后，您可以在连接配置中指定别名，如数据库连接池。然后，当服务尝试身份验证时，Data Grid 服务器从密钥存储中解密该别名的密码。

您可以根据需要创建任意数量的凭证存储，其别名数量相同。

注意

作为安全最佳实践，密钥存储应只由运行 Data Grid Server 进程的用户读取。

流程

在 $RHDG_HOME 中打开一个终端。
创建密钥存储，并使用 credentials 命令向其添加凭据。
提示
默认情况下，密钥存储是 PKCS12 类型的。运行 帮助凭据 以获取有关更改密钥存储默认值的详细信息。
以下示例演示了如何创建密钥存储，其中包含密码"changeme"的别名"dbpassword"。在创建密钥存储时，您也指定使用 -p 参数访问密钥存储的密码。
Linux
```
bin/cli.sh credentials add dbpassword -c changeme -p "secret1234!"
```
Microsoft Windows
```
bin\cli.bat credentials add dbpassword -c changeme -p "secret1234!"
```

检查别名是否已添加到密钥存储。

bin/cli.sh credentials ls -p "secret1234!"
dbpassword

打开 Data Grid Server 配置以进行编辑。
配置 Data Grid，以使用凭据密钥存储。
1. 在安全 配置中添加 credential-stores 部分。
2. 指定凭据密钥存储的名称和位置。
3. 指定使用 明文-text-credential 配置访问凭据密钥存储的密码。
  注意
  除了将凭据密钥存储的明文密码添加到 Data Grid Server 配置中，而是使用外部命令或屏蔽的密码来获得额外的安全性。
  您还可以在一个凭证存储中使用密码作为另一个凭证存储的 master 密码。
在 Data Grid 服务器用来与外部系统（如数据源或 LDAP 服务器）连接的配置中引用凭据密钥存储。
1. 添加 credentials-reference 部分。
2. 使用 store 属性指定凭据密钥存储的名称。
3. 使用 alias 属性指定密码别名。
  提示
  credential-reference 配置中的属性是可选的。
  只有在您有多个密钥存储时才需要 存储。
  只有密钥存储包含多个密码别名时才需要 alias。
保存对配置的更改。

5.2. 保护凭据密钥存储的密码

Data Grid 服务器需要密码才能访问凭据密钥存储。您可以以明文形式将该密码添加到 Data Grid Server 配置中，或者作为添加的安全层，您可以使用外部命令作为密码，或者您可以屏蔽密码。

先决条件

为 Data Grid 服务器设置凭据密钥存储。

流程

执行以下操作之一：

使用 credentials mask 命令模糊密码，例如：
```
bin/cli.sh credentials mask -i 100 -s pepper99 "secret1234!"
```
屏蔽的密码使用 Based Encryption (PBE)，且必须在 Data Grid Server 配置中采用以下格式： <MASKED_VALUE;SALT;ITERATION>。
使用提供密码作为标准输出的外部命令。
外部命令可以是任何使用 java.lang. Runtime"exec (java.lang.String) 的可执行文件，如 shell 脚本或二进制。
如果命令需要参数，以空格分隔的字符串列表形式提供。

5.3. 凭证密钥存储配置

您可以将凭据密钥存储添加到 Data Grid Server 配置中，并使用明文密码、屏蔽密码或提供密码的外部命令。

带有明文密码的凭证密钥存储

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <credential-stores>
      <credential-store name="credentials" path="credentials.pfx">
        <clear-text-credential clear-text="secret1234!"/>
      </credential-store>
    </credential-stores>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "credential-stores": [{
        "name": "credentials",
        "path": "credentials.pfx",
        "clear-text-credential": {
          "clear-text": "secret1234!"
        }
      }]
    }
  }
}

YAML

server:
  security:
    credentialStores:
      - name: credentials
        path: credentials.pfx
        clearTextCredential:
          clearText: "secret1234!"

带有屏蔽密码的凭证密钥存储

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <credential-stores>
      <credential-store name="credentials"
                        path="credentials.pfx">
        <masked-credential masked="1oTMDZ5JQj6DVepJviXMnX;pepper99;100"/>
      </credential-store>
    </credential-stores>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "credential-stores": [{
        "name": "credentials",
        "path": "credentials.pfx",
        "masked-credential": {
          "masked": "1oTMDZ5JQj6DVepJviXMnX;pepper99;100"
        }
      }]
    }
  }
}

YAML

server:
  security:
    credentialStores:
      - name: credentials
        path: credentials.pfx
        maskedCredential:
          masked: "1oTMDZ5JQj6DVepJviXMnX;pepper99;100"

外部命令密码

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <credential-stores>
      <credential-store name="credentials"
                        path="credentials.pfx">
        <command-credential command="/path/to/executable.sh arg1 arg2"/>
      </credential-store>
    </credential-stores>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "credential-stores": [{
        "name": "credentials",
        "path": "credentials.pfx",
        "command-credential": {
          "command": "/path/to/executable.sh arg1 arg2"
        }
      }]
    }
  }
}

YAML

server:
  security:
    credentialStores:
      - name: credentials
        path: credentials.pfx
        commandCredential:
          command: "/path/to/executable.sh arg1 arg2"

5.4. 凭证密钥存储引用

将凭据密钥存储添加到 Data Grid 服务器后，您可以在连接配置中引用它们。

数据源连接

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <credential-stores>
      <credential-store name="credentials"
                        path="credentials.pfx">
        <clear-text-credential clear-text="secret1234!"/>
      </credential-store>
    </credential-stores>
  </security>
  <data-sources>
    <data-source name="postgres"
                 jndi-name="jdbc/postgres">
      <!-- Specifies the database username in the connection factory. -->
      <connection-factory driver="org.postgresql.Driver"
                          username="dbuser"
                          url="${org.infinispan.server.test.postgres.jdbcUrl}">
        <!-- Specifies the credential keystore that contains an encrypted password and the alias for it. -->
        <credential-reference store="credentials"
                              alias="dbpassword"/>
      </connection-factory>
      <connection-pool max-size="10"
                       min-size="1"
                       background-validation="1000"
                       idle-removal="1"
                       initial-size="1"
                       leak-detection="10000"/>
    </data-source>
  </data-sources>
</server>

JSON

{
  "server": {
    "security": {
      "credential-stores": [{
        "name": "credentials",
        "path": "credentials.pfx",
        "clear-text-credential": {
          "clear-text": "secret1234!"
        }
      }],
      "data-sources": [{
        "name": "postgres",
        "jndi-name": "jdbc/postgres",
        "connection-factory": {
          "driver": "org.postgresql.Driver",
          "username": "dbuser",
          "url": "${org.infinispan.server.test.postgres.jdbcUrl}",
          "credential-reference": {
            "store": "credentials",
            "alias": "dbpassword"
          }
        }
      }]
    }
  }
}

YAML

server:
  security:
    credentialStores:
      - name: credentials
        path: credentials.pfx
        clearTextCredential:
          clearText: "secret1234!"
  dataSources:
    - name: postgres
      jndiName: jdbc/postgres
      connectionFactory:
        driver: org.postgresql.Driver
        username: dbuser
        url: '${org.infinispan.server.test.postgres.jdbcUrl}'
        credentialReference:
          store: credentials
          alias: dbpassword

LDAP 连接

XML

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <credential-stores>
      <credential-store name="credentials"
                        path="credentials.pfx">
        <clear-text-credential clear-text="secret1234!"/>
      </credential-store>
    </credential-stores>
    <security-realms>
      <security-realm name="default">
        <!-- Specifies the LDAP principal in the connection factory. -->
        <ldap-realm name="ldap"
                    url="ldap://my-ldap-server:10389"
                    principal="uid=admin,ou=People,dc=infinispan,dc=org">
          <!-- Specifies the credential keystore that contains an encrypted password and the alias for it. -->
          <credential-reference store="credentials"
                                alias="ldappassword"/>
        </ldap-realm>
      </security-realm>
    </security-realms>
  </security>
</server>

JSON

{
  "server": {
    "security": {
      "credential-stores": [{
        "name": "credentials",
        "path": "credentials.pfx",
        "clear-text-credential": {
          "clear-text": "secret1234!"
        }
      }],
      "security-realms": [{
        "name": "default",
        "ldap-realm": {
          "name": "ldap",
          "url": "ldap://my-ldap-server:10389",
          "principal": "uid=admin,ou=People,dc=infinispan,dc=org",
          "credential-reference": {
            "store": "credentials",
            "alias": "ldappassword"
          }
        }
      }]
    }
  }
}

YAML

server:
  security:
    credentialStores:
      - name: credentials
        path: credentials.pfx
        clearTextCredential:
          clearText: "secret1234!"
    securityRealms:
      - name: "default"
        ldapRealm:
          name: ldap
          url: 'ldap://my-ldap-server:10389'
          principal: 'uid=admin,ou=People,dc=infinispan,dc=org'
          credentialReference:
            store: credentials
            alias: ldappassword

第 6 章加密集群传输

保护集群传输，以便节点与加密消息通信。您还可以配置 Data Grid 集群来执行证书身份验证，以便只有具有有效身份的节点才能加入。

6.1. 使用 TLS 身份保护集群传输

为 Data Grid 服务器安全域添加 SSL/TLS 身份，并使用它们来保护集群传输。Data Grid Server 集群中的节点随后交换 SSL/TLS 证书以加密 JGroups 消息，包括 RELAY 消息（如果您配置跨站点复制）。

先决条件

安装 Data Grid Server 集群。

流程

创建一个 TLS 密钥存储，其中包含单个证书来标识 Data Grid 服务器。
如果 PEM 文件包含 PKCS"" 或 PKCS""8 格式的私钥，则可使用证书，并且具有空密码： password=""。
注意
如果密钥存储中的证书没有由公共证书颁发机构(CA)签名，那么您还必须创建一个包含签名证书或公钥的信任存储。
将密钥存储添加到 $RHDG_HOME/server/conf 目录中。

将密钥存储添加到 Data Grid Server 配置中的新安全域。

重要

您应该创建专用的密钥存储和安全域，以便 Data Grid 服务器端点不使用与集群传输相同的安全域。

<server xmlns="urn:infinispan:server:15.0">
  <security>
    <security-realms>
      <security-realm name="cluster-transport">
        <server-identities>
          <ssl>
            <!-- Adds a keystore that contains a certificate that provides SSL/TLS identity to encrypt cluster transport. -->
            <keystore path="server.pfx"
                      relative-to="infinispan.server.config.path"
                      password="secret"
                      alias="server"/>
          </ssl>
        </server-identities>
      </security-realm>
    </security-realms>
  </security>
</server>

使用 server:security-realm 属性指定安全域的名称，将集群传输配置为使用安全域。

<infinispan>
  <cache-container>
    <transport server:security-realm="cluster-transport"/>
  </cache-container>
</infinispan>

验证

当您启动 Data Grid Server 时，以下日志消息表示集群使用安全域进行集群传输：

[org.infinispan.SERVER] ISPN080060: SSL Transport using realm <security_realm_name>

6.2. JGroups 加密协议

要保护集群流量，您可以配置 Data Grid 节点，以使用 secret 密钥加密 JGroups 消息有效负载。

Data Grid 节点可以从以下方法获取 secret 密钥：

协调器节点(symmetric 加密)。
共享密钥存储(symmetric encryption)。

从协调器节点检索 secret 密钥

您可以通过在 Data Grid 配置中的 JGroups 堆栈中添加 ASYM_ENCRYPT 协议来配置非对称加密。这允许 Data Grid 集群生成和分发 secret 密钥。

重要

在使用非对称加密时，您还应提供密钥存储，以便节点能够执行证书身份验证并安全地交换机密密钥。这可保护集群不受中间人(MitM)攻击的影响。

非对称加密保护集群流量，如下所示：

Data Grid 集群中的第一个节点(coordinator 节点)会生成一个 secret 密钥。
加入节点使用协调器执行证书身份验证，以互相验证身份。
加入的节点从 coordinator 节点请求 secret 密钥。该请求包含加入节点的公钥。
协调器节点使用公钥加密 secret 密钥，并将其返回到加入节点。
加入节点解密并安装 secret 密钥。
节点加入集群，使用 secret 密钥加密并解密信息。

从共享密钥存储检索 secret 密钥

您可以通过在 Data Grid 配置中的 JGroups 堆栈中添加 SYM_ENCRYPT 协议来配置对称加密。这允许 Data Grid 集群从您提供的密钥存储获取 secret 密钥。

节点在启动时从 Data Grid 类路径上的密钥存储安装 secret 密钥。
节点加入集群，使用 secret 密钥加密和解密消息。

非对称和对称加密的比较

带有证书身份验证的 ASYM_ENCRYPT 提供了额外的加密层，与 SYM_ENCRYPT 相比。您提供密钥存储来为 secret 密钥加密对协调节点的请求。Data Grid 会自动生成该 secret 密钥并处理集群流量，同时允许您指定何时生成 secret 密钥。例如，您可以配置集群以在节点离开时生成新的 secret 密钥。这样可确保节点无法绕过证书身份验证，并使用旧密钥加入。

另一方面，SYM_ENCRYPT 比 ASYM_ENCRYPT 快，因为节点不需要与集群协调器交换密钥。SYM_ENCRYPT 是没有配置在集群成员资格更改时自动生成新 secret 密钥的潜在缺陷。用户负责生成和分发节点用于加密集群流量的 secret 密钥。

6.3. 使用非对称加密保护集群传输

配置 Data Grid 集群，以生成和分发加密 JGroups 消息的 secret 密钥。

流程

使用证书链创建密钥存储，使 Data Grid 能够验证节点身份。
将密钥存储放在集群中每个节点的 classpath 上。
对于 Data Grid Server，您要将密钥存储放在 $RHDG_HOME 目录中。

将 SSL_KEY_EXCHANGE 和 ASYM_ENCRYPT 协议添加到 Data Grid 配置中的 JGroups 堆栈，如下例所示：

<infinispan>
  <jgroups>
    <!-- Creates a secure JGroups stack named "encrypt-tcp" that extends the default TCP stack. -->
    <stack name="encrypt-tcp" extends="tcp">
      <!-- Adds a keystore that nodes use to perform certificate authentication. -->
      <!-- Uses the stack.combine and stack.position attributes to insert SSL_KEY_EXCHANGE into the default TCP stack after VERIFY_SUSPECT2. -->
      <SSL_KEY_EXCHANGE keystore_name="mykeystore.jks"
                        keystore_password="changeit"
                        stack.combine="INSERT_AFTER"
                        stack.position="VERIFY_SUSPECT2"/>
      <!-- Configures ASYM_ENCRYPT -->
      <!-- Uses the stack.combine and stack.position attributes to insert ASYM_ENCRYPT into the default TCP stack before pbcast.NAKACK2. -->
      <!-- The use_external_key_exchange = "true" attribute configures nodes to use the `SSL_KEY_EXCHANGE` protocol for certificate authentication. -->
      <ASYM_ENCRYPT asym_keylength="2048"
                    asym_algorithm="RSA"
                    change_key_on_coord_leave = "false"
                    change_key_on_leave = "false"
                    use_external_key_exchange = "true"
                    stack.combine="INSERT_BEFORE"
                    stack.position="pbcast.NAKACK2"/>
    </stack>
  </jgroups>
  <cache-container name="default" statistics="true">
    <!-- Configures the cluster to use the JGroups stack. -->
    <transport cluster="${infinispan.cluster.name}"
               stack="encrypt-tcp"
               node-name="${infinispan.node.name:}"/>
  </cache-container>
</infinispan>

验证

当您启动 Data Grid 集群时，以下日志消息表示集群使用 secure JGroups 堆栈：

[org.infinispan.CLUSTER] ISPN000078: Starting JGroups channel cluster with stack <encrypted_stack_name>

只有在它们使用 ASYM_ENCRYPT 且可以从协调器节点获取 secret 密钥时，数据网格节点才能加入集群。否则，以下信息会写入 Data Grid 日志：

[org.jgroups.protocols.ASYM_ENCRYPT] <hostname>: received message without encrypt header from <hostname>; dropping it

其他资源

6.4. 使用对称加密保护集群传输

配置 Data Grid 集群，以使用您提供的密钥存储中的 secret 密钥加密 JGroups 消息。

流程

创建包含 secret 密钥的密钥存储。
将密钥存储放在集群中每个节点的 classpath 上。
对于 Data Grid Server，您要将密钥存储放在 $RHDG_HOME 目录中。
将 SYM_ENCRYPT 协议添加到 Data Grid 配置中的 JGroups 堆栈。

<infinispan>
  <jgroups>
    <!-- Creates a secure JGroups stack named "encrypt-tcp" that extends the default TCP stack. -->
    <stack name="encrypt-tcp" extends="tcp">
      <!-- Adds a keystore from which nodes obtain secret keys. -->
      <!-- Uses the stack.combine and stack.position attributes to insert SYM_ENCRYPT into the default TCP stack after VERIFY_SUSPECT2. -->
      <SYM_ENCRYPT keystore_name="myKeystore.p12"
                   keystore_type="PKCS12"
                   store_password="changeit"
                   key_password="changeit"
                   alias="myKey"
                   stack.combine="INSERT_AFTER"
                   stack.position="VERIFY_SUSPECT2"/>
    </stack>
  </jgroups>
  <cache-container name="default" statistics="true">
    <!-- Configures the cluster to use the JGroups stack. -->
    <transport cluster="${infinispan.cluster.name}"
               stack="encrypt-tcp"
               node-name="${infinispan.node.name:}"/>
  </cache-container>
</infinispan>

验证

当您启动 Data Grid 集群时，以下日志消息表示集群使用 secure JGroups 堆栈：

[org.infinispan.CLUSTER] ISPN000078: Starting JGroups channel cluster with stack <encrypted_stack_name>

只有在使用 SYM_ENCRYPT 且可以从共享密钥存储获取 secret 密钥时，数据网格节点才能加入集群。否则，以下信息会写入 Data Grid 日志：

[org.jgroups.protocols.SYM_ENCRYPT] <hostname>: received message without encrypt header from <hostname>; dropping it

其他资源

第 7 章 Data Grid 端口和协议

由于 Data Grid 在网络上分发数据，并可建立外部客户端请求的连接，您应该了解 Data Grid 用来处理网络流量的端口和协议。

如果将 Data Grid 作为远程服务器运行，则可能需要通过防火墙允许远程客户端。同样，您应该调整 Data Grid 节点用于集群通信的端口，以防止冲突或网络问题。

7.1. Data Grid 服务器端口和协议

Data Grid 服务器提供网络端点，允许客户端访问不同的协议。

端口	协议	描述
`11222`	TCP	热 Rod 和 REST
`11221`	TCP	Memcached （默认禁用）

单个端口

Data Grid 服务器通过单个 TCP 端口 11222 公开多个协议。使用单一端口处理多个协议可简化配置并降低部署 Data Grid 集群时的管理复杂性。使用单个端口还通过最大程度减少网络上的攻击面来增强安全性。

Data Grid 服务器以不同的方式通过单一端口处理来自客户端的 HTTP/1.1、HTTP/2 和 Hot Rod 协议请求。

HTTP/1.1 升级标头

客户端请求可以包含 HTTP/1.1 升级 标头字段，用来与 Data Grid Server 启动 HTTP/1.1 连接。然后，客户端应用程序可以发送 Upgrade: protocol 标头字段，其中 protocol 是服务器端点。

应用程序层协议协商(ALPN)/传输层安全(TLS)

客户端请求包括 Data Grid Server 端点的 Server Name Indication (SNI)映射，以便通过 TLS 连接协商协议。

自动 Hot Rod 检测

包括 Hot Rod 标头的客户端请求会自动路由到 Hot Rod 端点。

7.1.1. 为 Data Grid 流量配置网络防火墙

调整防火墙规则，以允许 Data Grid 服务器和客户端应用程序之间的流量。

流程

例如，在 Red Hat Enterprise Linux (RHEL)工作站中，您可以使用 firewalld 来允许到端口 11222 的流量，如下所示：

# firewall-cmd --add-port=11222/tcp --permanent
success
# firewall-cmd --list-ports | grep 11222
11222/tcp

要配置在网络上应用的防火墙规则，您可以使用 nftables 工具。

参考

7.2. 集群流量的 TCP 和 UDP 端口

Data Grid 对集群传输信息使用以下端口：

默认端口	协议	描述
`7800`	TCP/UDP	JGroups 集群绑定端口
`46655`	UDP	JGroups 多播

跨站点复制

Data Grid 为 JGroups RELAY2 协议使用以下端口：

7900: 对于在 OpenShift 上运行的 Data Grid 集群。
7800: 如果将 UDP 用于节点间的流量，使用 TCP 作为集群之间的流量。
7801: 如果将 TCP 用于节点和 TCP 间的流量，用于集群之间的流量。

法律通告

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Data Grid 安全指南

启用并配置 Data Grid 安全性

Red Hat Data Grid

Data Grid 文档

Data Grid 下载

使开源包含更多

第 1 章 使用基于角色的访问控制进行安全授权

1.1. Data Grid 用户角色和权限

1.1.1. 权限

1.1.2. 角色和权限映射器

1.1.2.1. 在 Data Grid 中将用户映射到角色和权限

1.1.3. 配置角色映射器

角色映射器配置

1.1.4. 配置集群角色和权限映射程序

1.1.4.1. 创建新角色

1.1.4.2. 授予用户角色

1.1.4.3. 集群角色映射程序名称重写器

1.1.4.3.1. case Principal Transformer

1.1.4.3.2. regex Principal Transformer

1.2. 使用安全授权配置缓存

隐式角色配置

显式角色配置

第 2 章 安全域

2.1. 创建安全域

多个属性域

2.2. 设置 Kerberos 身份

Kerberos 身份配置

2.3. 属性域

属性域配置

2.3.1. 属性 realm 文件结构

2.4. LDAP 域

2.4.1. LDAP 连接属性

2.4.2. LDAP 域用户验证方法

2.4.3. 将用户条目映射到其关联的组

2.4.4. LDAP 域配置参考

2.4.4.1. LDAP 域主体重写

2.4.4.2. LDAP 主体重写配置参考

问题单主体转换器

通用名称主体转换器

正则表达式主体转换器

2.4.4.3. 使用 Data Grid 的 LDAP 用户和组映射过程

2.5. 令牌域

令牌域配置

2.6. 信任存储域

信任存储域配置

2.7. 分布式安全域

分布式域配置

2.8. 聚合安全域

聚合域配置

2.8.1. name rewriters

2.8.1.1. case Principal Transformer

2.8.1.2. 通用名称 Principal Transformer

2.8.1.3. regex Principal Transformer

2.9. 安全域缓存

realm 缓存域配置

2.9.1. 清空域缓存

第 3 章 端点身份验证机制

3.1. Data Grid 服务器身份验证

3.2. 配置 Data Grid 服务器身份验证机制

身份验证机制配置

3.2.1. 禁用身份验证

3.3. Data Grid 服务器身份验证机制

3.3.1. SASL 身份验证机制

3.3.2. SASL 质量保护(QoP)

3.3.3. SASL 策略

SASL 策略配置

3.3.4. HTTP 身份验证机制

第 4 章 配置 TLS/SSL 加密

4.1. 配置 Data Grid 服务器密钥存储

密钥存储配置

4.1.1. SSL/TLS 证书轮转

4.1.2. 生成 Data Grid 服务器密钥存储

生成的密钥存储配置

4.1.3. 配置 TLS 版本和密码套件

SSL 引擎配置

4.2. 在具有 FIPS 140-2 兼容加密的系统中配置 Data Grid 服务器

4.2.1. 配置 PKCS11 加密供应商

密钥存储配置

4.2.2. 配置 Bouncy Castle FIPS 加密供应商

密钥存储配置

第 1 章使用基于角色的访问控制进行安全授权

第 2 章安全域

第 3 章端点身份验证机制

第 4 章配置 TLS/SSL 加密

第 5 章在密钥存储中存储 Data Grid 服务器凭证

第 6 章加密集群传输