使用 OpenID Connect 配置 Elastic Stack 的单点登录

OpenID Connect 提供程序 (OP) 是 OpenID Connect 中的实体，负责对用户进行身份验证，并授予带有身份验证和用户信息（供依赖方使用）的必要令牌。

为了让 Elastic Stack 能够使用您的 OpenID Connect 提供程序进行身份验证，需要在 OP 和 RP 之间建立信任关系。在 OpenID Connect 提供程序中，这意味着将 RP 注册为客户端。OpenID Connect 定义了一个动态客户端注册协议，但这通常是针对实时客户端注册，而不是跨安全域单点登录的信任建立过程。所有 OP 还允许通过用户界面或（较少情况下）通过使用元数据文档手动注册 RP 作为客户端。

注册 Elastic Stack RP 的过程因 OP 而异，遵循提供商的相关文档是谨慎的。您通常需要为注册提供的 RP 信息如下

在注册过程结束时，OP 将为 RP（Elastic Stack）分配一个客户端标识符和一个客户端密钥以供使用。记下这两个值，因为它们将在 Elasticsearch 配置中使用。

以下是启用 Elasticsearch 中使用 OpenID Connect 进行身份验证所需的配置步骤摘要

xpack.security.authc.token.enabled: true

xpack.security.authc.realms.oidc.oidc1:
  order: 2
  rp.client_id: "the_client_id"
  rp.response_type: code
  rp.redirect_uri: "https://kibana.example.org:5601/api/security/oidc/callback"
  op.issuer: "https://op.example.org"
  op.authorization_endpoint: "https://op.example.org/oauth2/v1/authorize"
  op.token_endpoint: "https://op.example.org/oauth2/v1/token"
  op.jwkset_path: oidc/jwkset.json
  op.userinfo_endpoint: "https://op.example.org/oauth2/v1/userinfo"
  op.endsession_endpoint: "https://op.example.org/oauth2/v1/logout"
  rp.post_logout_redirect_uri: "https://kibana.example.org:5601/security/logged_out"
  claims.principal: sub
  claims.groups: "http://example.info/claims/groups"

bin/elasticsearch-keystore add xpack.security.authc.realms.oidc.oidc1.rp.client_secret

xpack.security.authc.realms.oidc.oidc1:
  order: 2
  rp.client_id: "the_client_id"
  rp.response_type: code
  rp.redirect_uri: "https://kibana.example.org:5601/api/security/oidc/callback"
  op.authorization_endpoint: "https://op.example.org/oauth2/v1/authorize"
  op.token_endpoint: "https://op.example.org/oauth2/v1/token"
  op.userinfo_endpoint: "https://op.example.org/oauth2/v1/userinfo"
  op.endsession_endpoint: "https://op.example.org/oauth2/v1/logout"
  op.issuer: "https://op.example.org"
  op.jwkset_path: oidc/jwkset.json
  claims.principal: email_verified
  claim_patterns.principal: "^([^@]+)@staff\\.example\\.com$"

xpack.security.authc.realms.oidc.oidc1:
  order: 1
  ...
  ssl.certificate_authorities: ["/oidc/company-ca.pem"]

当用户使用 OpenID Connect 进行身份验证时，他们会被识别为 Elastic Stack 用户，但这不会自动授予他们执行任何操作或访问任何数据的权限。

除非为您的 OpenID Connect 用户分配角色，否则他们将无法执行任何操作。这可以通过 添加角色映射 API 或使用授权 realm 来完成。

这是一个简单的角色映射示例，该映射将 example_role 角色授予针对 oidc1 OpenID Connect realm 进行身份验证的任何用户

resp = client.security.put_role_mapping(
    name="oidc-example",
    roles=[
        "example_role"
    ],
    enabled=True,
    rules={
        "field": {
            "realm.name": "oidc1"
        }
    },
)
print(resp)

const response = await client.security.putRoleMapping({
  name: "oidc-example",
  roles: ["example_role"],
  enabled: true,
  rules: {
    field: {
      "realm.name": "oidc1",
    },
  },
});
console.log(response);

PUT /_security/role_mapping/oidc-example
{
  "roles": [ "example_role" ], 
  "enabled": true,
  "rules": {
    "field": { "realm.name": "oidc1" }
  }
}

通过 realm 配置映射的用户属性用于处理角色映射规则，这些规则确定授予用户的角色。

提供给角色映射的用户字段派生自 OpenID Connect 声明，如下所示

有关更多信息，请参阅将用户和组映射到角色和角色映射。

如果您的 OP 能够通过使用 OpenID 声明向 RP 提供组或角色，那么您应该将此声明映射到 Elasticsearch realm 中的 claims.groups 设置（请参阅 将声明映射到用户属性），然后在角色映射中按以下示例使用它。

此映射将 Elasticsearch 的 finance_data 角色授予通过 oidc1 realm 进行身份验证且具有 finance-team 组成员身份的任何用户。

resp = client.security.put_role_mapping(
    name="oidc-finance",
    roles=[
        "finance_data"
    ],
    enabled=True,
    rules={
        "all": [
            {
                "field": {
                    "realm.name": "oidc1"
                }
            },
            {
                "field": {
                    "groups": "finance-team"
                }
            }
        ]
    },
)
print(resp)

const response = await client.security.putRoleMapping({
  name: "oidc-finance",
  roles: ["finance_data"],
  enabled: true,
  rules: {
    all: [
      {
        field: {
          "realm.name": "oidc1",
        },
      },
      {
        field: {
          groups: "finance-team",
        },
      },
    ],
  },
});
console.log(response);

PUT /_security/role_mapping/oidc-finance
{
  "roles": [ "finance_data" ],
  "enabled": true,
  "rules": { "all": [
        { "field": { "realm.name": "oidc1" } },
        { "field": { "groups": "finance-team" } }
  ] }
}

如果您的用户也存在于 Elasticsearch 可以直接访问的存储库中（例如 LDAP 目录），则可以使用授权 realm 而不是角色映射。

在这种情况下，请执行以下步骤

默认情况下，通过 OpenID Connect 进行身份验证的用户将有一些额外的元数据字段。这些字段将包括身份验证响应中提供的每个 OpenID 声明（无论它是否映射到 Elasticsearch 用户属性）。例如，在元数据字段 oidc(claim_name) 中，“claim_name” 是该声明在 ID 令牌或用户信息响应中包含的名称。请注意，这些将包括所有与身份验证事件相关的 ID 令牌声明，而不是用户本身。

可以通过在 oidc realm 中添加 populate_user_metadata: false 作为设置来禁用此行为。

Kibana 中的 OpenID Connect 身份验证除了标准的 Kibana 安全配置之外，还需要少量其他设置。Kibana 安全文档提供了您可以应用的可用配置选项的详细信息。

特别是，由于您的 Elasticsearch 节点已配置为在 HTTP 接口上使用 TLS，因此您必须配置 Kibana 以使用 https URL 连接到 Elasticsearch，并且您可能需要配置 elasticsearch.ssl.certificateAuthorities 以信任 Elasticsearch 已配置为使用的证书。

Kibana 中的 OpenID Connect 身份验证受 kibana.yml 中的以下超时设置约束

您可能需要根据您的安全要求调整这些超时。

以下显示了支持 OpenID Connect 所需的三个附加设置

xpack.security.authc.providers:
  oidc.oidc1:
    order: 0
    realm: "oidc1"

上面示例中使用的配置值是

xpack.security.authc.providers:
  oidc.oidc1:
    order: 0
    realm: "oidc1"
  basic.basic1:
    order: 1

这将允许尚未通过 OpenID Connect 进行身份验证的用户使用 Kibana 登录表单登录。

OpenID Connect realm 旨在允许用户对 Kibana 进行身份验证，因此，以上指南的大部分内容都假设使用了 Kibana。本节介绍自定义 Web 应用程序如何使用相关的 OpenID Connect REST API，以便使用 OpenID Connect 对用户进行 Elasticsearch 身份验证。

诸如 OpenID Connect 和 SAML 之类的单点登录 realm 利用 Elasticsearch 中的令牌服务，并且原则上将 SAML 或 OpenID Connect 身份验证响应交换为 Elasticsearch 访问令牌和刷新令牌。访问令牌用作后续对 Elasticsearch 的调用的凭据。刷新令牌允许用户在当前令牌过期后获取新的 Elasticsearch 访问令牌。

resp = client.security.put_role(
    name="facilitator-role",
    cluster=[
        "manage_oidc",
        "manage_token"
    ],
)
print(resp)

const response = await client.security.putRole({
  name: "facilitator-role",
  cluster: ["manage_oidc", "manage_token"],
});
console.log(response);

POST /_security/role/facilitator-role
{
  "cluster" : ["manage_oidc", "manage_token"]
}

resp = client.security.put_user(
    username="facilitator",
    password="<somePasswordHere>",
    roles=[
        "facilitator-role"
    ],
)
print(resp)

const response = await client.security.putUser({
  username: "facilitator",
  password: "<somePasswordHere>",
  roles: ["facilitator-role"],
});
console.log(response);

POST /_security/user/facilitator
{
  "password" : "<somePasswordHere>",
  "roles"    : [ "facilitator-role"]
}