JWT 认证
ECE ECK Elastic Cloud Hosted Self Managed
可以配置 Elasticsearch 以信任从外部服务颁发的 JSON Web 令牌 (JWT)，将其作为身份验证的持有者令牌。
当使用 JWT realm 进行 Elasticsearch 身份验证时，需要区分连接到 Elasticsearch 的客户端和代表其运行请求的用户。 JWT 验证用户身份，并且单独的凭据验证客户端身份。
JWT realm 支持两种令牌类型，id_token（默认）和 access_token
id_token：应用程序使用身份验证流程（例如 OpenID Connect (OIDC)）对用户进行身份验证和识别，然后使用符合 OIDC ID 令牌规范的 JSON Web 令牌 (JWT) 代表经过身份验证的用户访问 Elasticsearch。 此选项适用于使用 Elastic Stack 8.2+ 的部署。access_token：应用程序使用其自身身份（编码为 JWT）访问 Elasticsearch，例如，应用程序使用 OAuth2 客户端凭据流向中央身份平台进行身份验证，然后使用生成的基于 JWT 的访问令牌连接到 Elasticsearch。 此选项适用于使用 Elastic Stack 8.7+ 的部署。
单个 JWT realm 只能使用一种令牌类型。 要处理两种令牌类型，您必须至少配置两个 JWT realm。 您应该根据用例仔细选择令牌类型，因为它会影响执行验证的方式。
JWT realm 根据其配置的令牌类型验证传入的 JWT。 两种类型的 JSON Web 令牌 (JWT) 必须包含以下 5 条信息。 虽然基于 OIDC 规范的 ID 令牌对于哪些声明应提供这些信息有严格的规则，但访问令牌允许某些声明是可配置的。
声明
| 信息 | ID 令牌 | 访问令牌 |
|---|---|---|
| 颁发者 | iss |
iss |
| 主题 | sub |
默认为 sub，但如果 sub 不存在，则可以回退到另一个声明 |
| 受众 | aud |
默认为 aud，但如果 aud 不存在，则可以回退到另一个声明 |
| 颁发时间 | iat |
iat |
| 到期时间 | exp |
exp |
此外，如果存在 nbf 和 auth_time 声明，Elasticsearch 还会验证 ID 令牌的这些声明。 但对于访问令牌，这些声明将被忽略。
总的来说，访问令牌类型具有更宽松的验证规则，并且适合更通用的 JWT，包括自签名令牌。
Elasticsearch 中的 JWT 身份验证源自 OIDC 用户工作流，其中不同的令牌可以由 OIDC 提供程序 (OP) 颁发，包括 ID 令牌。 来自 OIDC 提供程序的 ID 令牌是定义明确的 JSON Web 令牌 (JWT)，应始终与 id_token 令牌类型的 JWT realm 兼容。 ID 令牌的主题声明表示最终用户。 这意味着 ID 令牌通常会有许多允许的主题。 因此，id_token 令牌类型的 JWT realm *不* 强制执行 allowed_subjects（或 allowed_subject_patterns）验证。
由于 JWT 是在 Elasticsearch 外部获得的，因此您可以定义自定义工作流程，而不是使用 OIDC 工作流程。 但是，JWT 格式仍然必须是 JSON Web Signature (JWS)。 JWS 标头和 JWS 签名使用 OIDC ID 令牌验证规则进行验证。
Elasticsearch 支持单独的 OpenID Connect realm。 对于 Elasticsearch 可以充当 OIDC RP 的任何用例，建议使用它。 OIDC realm 是在 Kibana 中启用 OIDC 身份验证的唯一支持方式。
使用 JWT realm 进行身份验证的用户可以选择使用 run_as 功能模拟另一个用户。 请参阅 将 run_as 权限应用于 JWT realm 用户。
获取访问令牌的常见方法是使用 OAuth2 客户端凭据流。 此流的典型用法是让应用程序为其自身获取凭据。 这是 access_token 令牌类型的设计目的。 很有可能此应用程序还为其最终用户获取 ID 令牌。 为了防止最终用户 ID 令牌用于向为应用程序配置的 JWT realm 进行身份验证，我们强制要求当 JWT realm 具有令牌类型 access_token 时，必须进行 allowed_subjects 或 allowed_subject_patterns 验证。
并非每个访问令牌都格式化为 JSON Web 令牌 (JWT)。 为了使其与 JWT realm 兼容，它必须至少使用 JWT 格式并满足上表中的相关要求。
要使用 JWT 身份验证，请在 elasticsearch.yml 文件中创建 realm，以便在 Elasticsearch 身份验证链中配置它。
JWT realm 有一些强制设置，以及 JWT realm 设置 中描述的可选设置。
默认情况下，为 JWT realm 启用客户端身份验证。 禁用客户端身份验证是可能的，但不强烈建议这样做。
- 使用您首选的令牌类型配置 realm
以下示例包含最常见的设置，这些设置并非适用于所有用例
xpack.security.authc.realms.jwt.jwt1:
order: 3
token_type: id_token
client_authentication.type: shared_secret
allowed_issuer: "https://issuer.example.com/jwt/"
allowed_audiences: [ "8fb85eba-979c-496c-8ae2-a57fde3f12d0" ]
allowed_signature_algorithms: [RS256,HS256]
pkc_jwkset_path: jwt/jwkset.json
claims.principal: sub
order- 指定 realm
order的值为3，表示在验证用户身份时检查配置的 realm 的顺序。 realm 按升序顺序进行检查，其中首先检查具有最低 order 值的 realm。 token_type- 指示 realm 将传入的 JWT 视为 ID 令牌 (
id_token) 并进行验证。 client_authentication.type- 将客户端身份验证类型指定为
shared_secret，这意味着客户端使用 HTTP 请求标头进行身份验证，该标头必须与预配置的密钥值匹配。 客户端必须在每个请求中使用ES-Client-Authentication标头并使用SharedSecret方案提供此共享密钥。 标头值必须与 realm 的client_authentication.shared_secret大小写敏感匹配。 allowed_issuer- 为您的 JWT 颁发者设置可验证的标识符。 此值通常是 URL、UUID 或其他区分大小写的字符串值。
allowed_audiences- 指定 realm 将允许的 JWT 受众列表。 这些值通常是 URL、UUID 或其他区分大小写的字符串值。
allowed_signature_algorithms- 指示 Elasticsearch 应使用
RS256或HS256签名算法来验证来自 JWT 颁发者的 JWT 的签名。 pkc_jwkset_path- 具有 JWT Realm 用于验证令牌签名的公钥材料的 JSON Web Key Set (JWKS) 的文件名或 URL。 如果值不是以
https开头，则将其视为文件名。 文件名相对于 Elasticsearch 配置目录解析。 如果提供了 URL，则它必须以https://开头（不支持http://）。 Elasticsearch 会自动缓存 JWK 集，并会在签名验证失败时尝试刷新 JWK 集，因为这可能表明 JWT 提供程序已轮换签名密钥。 claims.principal-
包含用户主体（用户名）的 JWT 声明的名称。
以下是配置 JWT realm 以处理访问令牌的示例片段
xpack.security.authc.realms.jwt.jwt2:
order: 4
token_type: access_token
client_authentication.type: shared_secret
allowed_issuer: "https://issuer.example.com/jwt/"
allowed_subjects: [ "123456-compute@admin.example.com" ]
allowed_subject_patterns: [ "wild*@developer?.example.com", "/[a-z]+<1-10>\\@dev\\.example\\.com/"]
allowed_audiences: [ "elasticsearch" ]
required_claims:
token_use: access
version: ["1.0", "2.0"]
allowed_signature_algorithms: [RS256,HS256]
pkc_jwkset_path: "https://idp-42.example.com/.well-known/configuration"
fallback_claims.sub: client_id
fallback_claims.aud: scope
claims.principal: sub
token_type- 指示 realm 将传入的 JWT 视为访问令牌 (
access_token) 并进行验证。 allowed_subjects- 指定 realm 将允许的 JWT 主题列表。 这些值通常是 URL、UUID 或其他区分大小写的字符串值。
allowed_subject_patterns- 类似于
allowed_subjects，但它接受一个 Lucene 正则表达式 和通配符的列表，用于允许的 JWT 主题。通配符使用*和?特殊字符（用\转义）分别表示“任意字符串”和“任意单个字符”，例如 "a?*" 匹配 "a1" 和 "abwhatever"，但不匹配 "a"、"abc" 或 "abc" (在 Java 字符串中，\本身必须用另一个\转义)。 Lucene 正则表达式 必须用/括起来，例如 "/https?://[^/]+/?/" 匹配任何没有路径组件的 http 或 https URL（匹配 "https://elastic.ac.cn/" 但不匹配 "https://elastic.ac.cn/guide"）。
当 token_type 为 access_token 时，必须指定 allowed_subjects 或 allowed_subject_patterns 设置中的至少一个（且不能为空）。
当同时指定 allowed_subjects 和 allowed_subject_patterns 设置时，如果传入的 JWT 的 sub 声明与这两个列表中的任何一个匹配，则会被接受。
required_claims- 指定一个键/值对列表，用于对 JWT 执行额外的验证。这些值可以是字符串或字符串数组。
fallback_claims.sub- 如果
sub声明不存在，则用于提取主题信息的 JWT 声明的名称。此设置仅在token_type为access_token时可用。备用方案应用于使用sub声明的任何地方。在上面的代码片段中，这意味着如果sub不存在，claims.principal也会回退到client_id。 fallback_claims.aud- 如果
aud声明不存在，则用于提取受众信息的 JWT 声明的名称。此设置仅在token_type为access_token时可用。备用方案应用于使用aud声明的任何地方。
添加安全设置 到 Elasticsearch 密钥库
用于
client_authentication.type的shared_secret值(
xpack.security.authc.realms.jwt.jwt1.client_authentication.shared_secret1)用于
allowed_signature_algorithms的 HMAC 密钥(
xpack.security.authc.realms.jwt.jwt1.hmac_jwkset)此设置可以是 JWKS 的路径，JWKS 是一组 JSON 编码的密钥的资源。将内容加载到 Elasticsearch 密钥库后，可以删除该文件。
首选使用 JWKS。但是，您可以使用 xpack.security.authc.realms.jwt.jwt1.hmac_key 以字符串格式添加 HMAC 密钥。此格式与 HMAC UTF-8 密钥兼容，但仅支持没有属性的单个密钥。一次只能使用一种 HMAC 格式（hmac_jwkset 或 hmac_key）。
JWT 可以解析为三个部分
- Header（头部）
- 提供有关如何验证令牌的信息。
- 声明
- Payload（载荷）
- 包含有关调用用户或应用程序的数据。
- Signature（签名）
Header: {"typ":"JWT","alg":"HS256"}
Claims: {"aud":"aud8","sub":"security_test_user","iss":"iss8","exp":4070908800,"iat":946684800}
Signature: UnnFmsoFKfNmKMsVoDQmKI_3-j95PCaKdgqqau3jPMY
用于验证令牌的数据。
此示例说明了 JWT 的部分解码。有效期为 2000 年至 2099 年（含），由发布时间 (iat) 和到期时间 (exp) 定义。JWT 的有效期通常短于 100 年，例如 1-2 小时或 1-7 天，而不是整个人的一生。
此示例中的签名是确定性的，因为头部、声明和 HMAC 密钥是固定的。JWT 通常具有 nonce 声明，以使签名不确定。支持的 JWT 编码是 JSON Web Signature (JWS)，并且 JWS Header 和 Signature 使用 OpenID Connect ID Token 验证规则进行验证。可以通过 JWT realm 设置 自定义一些验证。
头部声明指示令牌类型和用于签名令牌的算法。- alg
（必需，字符串）指示用于签名令牌的算法，例如HS256。该算法必须位于 realm 的允许列表中。- typ
（可选，字符串）指示令牌类型，必须为 JWT。
JWT 载荷声明
以下声明通过 OIDC ID 令牌规则的子集进行验证。
Elasticsearch 不验证 nonce 声明，但自定义 JWT 颁发者可以添加随机 nonce 声明，以将熵引入签名。
iss- 您可以通过设置
allowed_clock_skew来放宽对任何基于时间的声明的验证。此值设置在验证 JWT 时相对于其身份验证时间 (auth_time)、创建时间 (iat)、不早于时间 (nbf) 和到期时间 (exp) 允许的最大时钟偏差。 sub- iss
aud- （必需，字符串）表示创建 ID 令牌的颁发者。该值必须与
allowed_issuer设置中的值完全匹配（区分大小写）。 exp- sub
iat- （必需*，字符串）指示 ID 令牌是为谁创建的。如果 JWT realm 的类型为
id_token，则此声明是强制性的。默认情况下，类型为id_token的 JWT realm 接受所有主题。类型为 access_token 的 JWT realm 必须指定allowed_subjects设置，并且主题值必须与 allowed_subjects 设置中的任何 CSV 值完全匹配（区分大小写）。类型为 access_token 的 JWT realm 可以指定一个备用声明，该声明将在sub声明不存在时使用。 aud- （必需*，字符串）指示 ID 令牌的目标受众，表示为逗号分隔值 (CSV)。其中一个值必须与
allowed_audiences设置中的任何 CSV 值完全匹配（区分大小写）。如果 JWT realm 的类型为id_token，则此声明是强制性的。类型为access_token的 JWT realm 可以指定一个备用声明，该声明将在aud声明不存在时使用。 exp- （必需，整数）ID 令牌的到期时间，以自 epoch 以来的 UTC 秒数表示。
（必需，整数）ID 令牌的颁发时间，以自 epoch 以来的 UTC 秒数表示。
nbf- （可选，整数）指示 JWT 必须不被接受的时间之前的时间，以自 epoch 以来的 UTC 秒数表示。此声明是可选的。如果存在，类型为
id_token的 JWT realm 将验证它，而类型为access_token的 JWT realm 将忽略它。 auth_time- （可选，整数）用户向 JWT 颁发者进行身份验证的时间，以自 epoch 以来的 UTC 秒数表示。此声明是可选的。如果存在，类型为
id_token的 JWT realm 将验证它，而类型为access_token的 JWT realm 将忽略它。 用于使用 JWT 声明的 Elasticsearch 设置- Elasticsearch 将 JWT 声明用于以下设置。
principal- （必需，字符串）包含用户的主体（用户名）。该值可以使用 realm 设置
claims.principal进行配置。您可以使用claim_patterns.principal配置一个可选的正则表达式来提取子字符串。 groups- （可选，JSON 数组）包含用户的组成员身份。该值可以使用 realm 设置
claims.groups进行配置。您可以使用 realm 设置claim_patterns.groups配置一个可选的正则表达式来提取子字符串值。
name
- （可选，字符串）包含一个人类可读的标识符，用于标识令牌的主题。该值可以使用 realm 设置
claims.name进行配置。您可以使用 realm 设置claim_patterns.name配置一个可选的正则表达式来提取子字符串值。 - （可选，字符串）包含要与用户关联的电子邮件地址。该值可以使用 realm 设置
claims.mail进行配置。您可以使用 realm 设置claim_patterns.mail配置一个可选的正则表达式来提取子字符串值。
dn
claims.dn 进行配置。您可以使用 realm 设置 claim_patterns.dn 配置一个可选的正则表达式来提取子字符串值。
您可以通过以下方式将 LDAP 组映射到角色
使用 Kibana 中的角色映射页面。
PUT /_security/role_mapping/jwt1_users?refresh=true <1> {
"roles" : [ "user" ],
"rules" : { "all" : [
{ "field": { "realm.name": "jwt1" } },
{ "field": { "username": "principalname1" } },
{ "field": { "dn": "CN=Principal Name 1,DC=example.com" } },
{ "field": { "groups": "group1" } },
{ "field": { "metadata.jwt_claim_other": "other1" } }
] },
"enabled": true
}
- 使用 角色映射 API。
- 通过 将授权委派给另一个 realm。
- 有关更多信息，请参阅 将用户和组映射到角色。
- 重要提示
您无法使用 role_mapping.yml 文件在 JWT realm 中映射角色。
nbf- 您可以使用 创建或更新角色映射 API 来定义角色映射，这些映射确定应根据用户的用户名、组或其他元数据将哪些角色分配给每个用户。
groups- 映射名称。
auth_time- 要映射到的 Elastic Stack 角色。
指定要映射自的 JWT 角色的规则。realm.name可以是任何仅包含字母数字字符、下划线和连字符的字符串。
如果在 JWT realm 中使用此 API，则以下声明可用于角色映射
以下示例展示了如何在 elasticsearch.yml 文件中定义从 JWT realm 到多个其他 realm 的委托授权。一个名为 jwt2 的 JWT realm 将授权委托给多个 realm。
xpack.security.authc.realms.jwt.jwt2.authorization_realms: file1,native1,ldap1,ad1
然后，您可以使用 创建或更新角色映射 API 将角色映射到授权 realm。以下示例将 native1 realm 中的角色映射到 principalname1 JWT principal。
PUT /_security/role_mapping/native1_users?refresh=true {
"roles" : [ "user" ],
"rules" : { "all" : [
{ "field": { "realm.name": "native1" } },
{ "field": { "username": "principalname1" } }
] },
"enabled": true
}
如果 realm jwt2 成功使用 principal principalname1 的 JWT 验证客户端，并将授权委托给列出的 realm 之一（例如 native1），那么该 realm 可以查找 Elasticsearch 用户的的值。通过此定义的角色映射，该 realm 还可以查找链接到 realm native1 的此角色映射规则。
Elasticsearch 可以通过角色映射或委托授权来检索 JWT 用户的角色。无论您选择哪种选项，您都可以将 run_as 权限 应用于角色，以便用户可以提交经过身份验证的请求以“以另一个用户身份运行”。要以另一个用户身份提交请求，请在您的请求中包含 es-security-runas-user 标头。运行的请求就像它们是由该用户发出的，并且 Elasticsearch 使用他们的角色。
例如，假设有一个用户名为 user123_runas 的用户。以下请求创建一个名为 jwt_role1 的用户角色，该角色指定一个具有 user123_runas 用户名的 run_as 用户。任何具有 jwt_role1 角色的用户都可以以指定的 run_as 用户身份发出请求。
POST /_security/role/jwt_role1?refresh=true {
"cluster": ["manage"],
"indices": [ { "names": [ "*" ], "privileges": ["read"] } ],
"run_as": [ "user123_runas" ],
"metadata" : { "version" : 1 }
}
然后，您可以将该角色映射到特定 realm 中的用户。以下请求将 jwt_role1 角色映射到 jwt2 JWT realm 中用户名为 user2 的用户。这意味着 Elasticsearch 将使用 jwt2 realm 来验证名为 user2 的用户。因为 user2 具有一个角色（jwt_role1 角色），其中包括 run_as 权限，所以 Elasticsearch 会检索 user123_runas 用户的角色映射，并使用该用户的角色来提交请求。
POST /_security/role_mapping/jwt_user1?refresh=true {
"roles": [ "jwt_role1"],
"rules" : { "all" : [
{ "field": { "realm.name": "jwt2" } },
{ "field": { "username": "user2" } }
] },
"enabled": true,
"metadata" : { "version" : 1 }
}
映射角色后，您可以使用 JWT 对 Elasticsearch 进行 身份验证调用 并包含 ES-Client-Authentication 标头
curl -s -X GET -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdWQiOlsiZXMwMSIsImVzMDIiLCJlczAzIl0sInN1YiI6InVzZXIyIiwiaXNzIjoibXktaXNzdWVyIiwiZXhwIjo0MDcwOTA4ODAwLCJpYXQiOjk0NjY4NDgwMCwiZW1haWwiOiJ1c2VyMkBzb21ldGhpbmcuZXhhbXBsZS5jb20ifQ.UgO_9w--EoRyUKcWM5xh9SimTfMzl1aVu6ZBsRWhxQA" -H "ES-Client-Authentication: sharedsecret test-secret" https://localhost:9200/_security/_authenticate
响应包括提交请求的用户 (user2)，包括您映射到此用户在 JWT realm 中的 jwt_role1 角色
{"username":"user2","roles":["jwt_role1"],"full_name":null,"email":"user2@something.example.com",
"metadata":{"jwt_claim_email":"user2@something.example.com","jwt_claim_aud":["es01","es02","es03"],
"jwt_claim_sub":"user2","jwt_claim_iss":"my-issuer"},"enabled":true,"authentication_realm":
{"name":"jwt2","type":"jwt"},"lookup_realm":{"name":"jwt2","type":"jwt"},"authentication_type":"realm"}
%
如果您想将请求指定为 run_as 用户，请包含带有您想要以其身份提交请求的用户名 es-security-runas-user 标头。以下请求使用 user123_runas 用户
curl -s -X GET -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdWQiOlsiZXMwMSIsImVzMDIiLCJlczAzIl0sInN1YiI6InVzZXIyIiwiaXNzIjoibXktaXNzdWVyIiwiZXhwIjo0MDcwOTA4ODAwLCJpYXQiOjk0NjY4NDgwMCwiZW1haWwiOiJ1c2VyMkBzb21ldGhpbmcuZXhhbXBsZS5jb20ifQ.UgO_9w--EoRyUKcWM5xh9SimTfMzl1aVu6ZBsRWhxQA" -H "ES-Client-Authentication: sharedsecret test-secret" -H "es-security-runas-user: user123_runas" https://localhost:9200/_security/_authenticate
在响应中，您将看到 user123_runas 用户提交了请求，并且 Elasticsearch 使用了 jwt_role1 角色
{"username":"user123_runas","roles":["jwt_role1"],"full_name":null,"email":null,"metadata":{},
"enabled":true,"authentication_realm":{"name":"jwt2","type":"jwt"},"lookup_realm":{"name":"native",
"type":"native"},"authentication_type":"realm"}%
JWT 身份验证支持使用 PKC（公钥密码学）或 HMAC 算法进行签名验证。
PKC JSON Web Token Key Sets (JWKS) 可以包含公共 RSA 和 EC 密钥。HMAC JWKS 或 HMAC UTF-8 JWK 包含密钥。JWT 颁发者通常更频繁地轮换 PKC JWKS（例如，每天一次），因为 RSA 和 EC 公钥的设计比 HMAC 等密钥更易于分发。
JWT realm 在启动时加载 PKC JWKS 和 HMAC JWKS 或 HMAC UTF-8 JWK。JWT realm 还可以在运行时重新加载 PKC JWKS 内容；重新加载由签名验证失败触发。
目前不支持 HMAC JWKS 或 HMAC UTF-8 JWK 重新加载。
加载失败、解析错误和配置错误会阻止节点启动（和重新启动）。但是，运行时 PKC 重新加载错误和恢复会得到妥善处理。
在签名失败可以触发 PKC JWKS 重新加载之前，将检查所有其他 JWT realm 验证。如果多个 JWT 身份验证签名失败与单个 Elasticsearch 节点同时发生，则会合并重新加载以减少外部发送的重新加载。
如果 JWT 签名失败触发，则无法合并单独的重新加载请求
- 不同 Elasticsearch 节点中的 PKC JWKS 重新加载
- 同一 Elasticsearch 节点在不同时间的 PKC JWKS 重新加载
claims.dn 进行配置。您可以使用 realm 设置 claim_patterns.dn 配置一个可选的正则表达式来提取子字符串值。
强烈建议启用客户端身份验证 (client_authentication.type)。只有受信任的客户端应用程序和 realm 特定的 JWT 用户才能触发 PKC 重新加载尝试。此外，建议配置以下 JWT 安全设置
allowed_audiencesallowed_clock_skewallowed_issuerallowed_signature_algorithms
以下设置为 JWT 颁发者、Elasticsearch 和 Elasticsearch 的客户端。示例 HMAC 密钥采用与 HMAC 兼容的 OIDC 格式。密钥字节是 UNICODE 字符的 UTF-8 编码。
claims.dn 进行配置。您可以使用 realm 设置 claim_patterns.dn 配置一个可选的正则表达式来提取子字符串值。
HMAC UTF-8 密钥需要比 HMAC 随机字节密钥更长才能达到相同的密钥强度。
以下值适用于定制的 JWT 颁发者。
Issuer: iss8
Audiences: aud8
Algorithms: HS256
HMAC UTF-8: hmac-oidc-key-string-for-hs256-algorithm
要定义 JWT realm，请将以下 realm 设置添加到 elasticsearch.yml。
xpack.security.authc.realms.jwt.jwt8.order: 8
xpack.security.authc.realms.jwt.jwt8.allowed_issuer: iss8
xpack.security.authc.realms.jwt.jwt8.allowed_audiences: [aud8]
xpack.security.authc.realms.jwt.jwt8.allowed_signature_algorithms: [HS256]
xpack.security.authc.realms.jwt.jwt8.claims.principal: sub
xpack.security.authc.realms.jwt.jwt8.client_authentication.type: shared_secret
- 在 Elastic Cloud 中，realm 顺序从
2开始。0和1在 Elastic Cloud 的 realm 链中保留。
定义 realm 设置后，使用 elasticsearch-keystore 工具将以下安全设置添加到 Elasticsearch 密钥库。在 Elastic Cloud 中，您可以在部署的 Security 下定义 Elasticsearch 密钥库的设置。
xpack.security.authc.realms.jwt.jwt8.hmac_key: hmac-oidc-key-string-for-hs256-algorithm
xpack.security.authc.realms.jwt.jwt8.client_authentication.shared_secret: client-shared-secret-string
以下请求为用户 principalname1 在 jwt8 realm 中创建 Elasticsearch 的角色映射
PUT /_security/role_mapping/jwt8_users?refresh=true {
"roles" : [ "user" ],
"rules" : { "all" : [
{ "field": { "realm.name": "jwt8" } },
{ "field": { "username": "principalname1" } }
] },
"enabled": true
}
以下标头设置适用于 Elasticsearch 客户端。
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJpc3M4IiwiYXVkIjoiYXVkOCIsInN1YiI6InNlY3VyaXR5X3Rlc3RfdXNlciIsImV4cCI6NDA3MDkwODgwMCwiaWF0Ijo5NDY2ODQ4MDB9.UnnFmsoFKfNmKMsVoDQmKI_3-j95PCaKdgqqau3jPMY
ES-Client-Authentication: SharedSecret client-shared-secret-string
您可以在 curl 请求中使用此标头来对 Elasticsearch 进行身份验证调用。不记名令牌和客户端授权令牌都必须指定为带有 -H 选项的单独标头
curl -s -X GET -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJpc3M4IiwiYXVkIjoiYXVkOCIsInN1YiI6InNlY3VyaXR5X3Rlc3RfdXNlciIsImV4cCI6NDA3MDkwODgwMCwiaWF0Ijo5NDY2ODQ4MDB9.UnnFmsoFKfNmKMsVoDQmKI_3-j95PCaKdgqqau3jPMY" -H "ES-Client-Authentication: SharedSecret client-shared-secret-string" https://localhost:9200/_security/_authenticate
如果您在 JWT realm 中使用了角色映射，则响应包括用户的 username、他们的 roles、关于用户的元数据以及关于 JWT realm 本身的详细信息。
{"username":"user2","roles":["jwt_role1"],"full_name":null,"email":"user2@something.example.com",
"metadata":{"jwt_claim_email":"user2@something.example.com","jwt_claim_aud":["es01","es02","es03"],
"jwt_claim_sub":"user2","jwt_claim_iss":"my-issuer"},"enabled":true,"authentication_realm":
{"name":"jwt2","type":"jwt"},"lookup_realm":{"name":"jwt2","type":"jwt"},"authentication_type":"realm"}