Настройка единого входа с помощью OpenID Connect в Elastic Stack

Провайдер OpenID Connect (OP) — это сущность в OpenID Connect, которая отвечает за аутентификацию пользователя и предоставление необходимых токенов с информацией об аутентификации и пользователе для использования Relying Parties.

Для того, чтобы Elastic Stack мог использовать ваш провайдер OpenID Connect для аутентификации, необходимо установить доверительные отношения между OP и RP. В провайдере OpenID Connect это означает регистрацию RP в качестве клиента. OpenID Connect определяет протокол динамической регистрации клиентов, но он обычно ориентирован на регистрацию клиентов в реальном времени, а не на процесс установления доверия для единого входа через разные домены безопасности. Все OP также позволят ручную регистрацию RP как клиента, через пользовательский интерфейс или (реже) через использование метаданных.

Процесс регистрации Elastic Stack RP будет отличаться от OP к OP, и целесообразно следовать соответствующей документации провайдера. Информация о RP, которую обычно нужно предоставить для регистрации, следующая:

По завершении процесса регистрации OP назначит идентификатор клиента и секрет клиента для RP (Elastic Stack) для использования. Обратите внимание на эти два значения, так как они будут использоваться в конфигурации Elasticsearch.

Когда пользователь проходит аутентификацию с помощью OpenID Connect, он идентифицируется Elastic Stack, но это не автоматически предоставляет ему доступ к выполнению каких-либо действий или к доступу к данным.

Ваши пользователи OpenID Connect не смогут ничего сделать, пока им не будут назначены роли. Это можно сделать с помощью API добавления сопоставления ролей или с помощью области авторизации.

Вот пример простого сопоставления ролей, которое назначает роль example_role любому пользователю, который проходит аутентификацию в области OpenID Connect oidc1:

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" }
  }
}

Свойства пользователя, сопоставленные с помощью конфигурации области, используются для обработки правил сопоставления ролей, и эти правила определяют, какие роли получает пользователь.

Поля пользователя, предоставленные для сопоставления ролей, выводятся из утверждений OpenID Connect следующим образом:

Для получения дополнительной информации см. Сопоставление пользователей и групп с ролями и Сопоставления ролей.

Если ваш OP имеет возможность предоставлять группы или роли RP с помощью утверждения OpenID, то вы должны сопоставить это утверждение с параметром claims.groups в области Elasticsearch (см. Сопоставление утверждений с свойствами пользователя), а затем использовать его в сопоставлении ролей в соответствии с примером ниже.

Это сопоставление назначает роль Elasticsearch finance_data всем пользователям, которые проходят аутентификацию через область oidc1 с членством в группе 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), вы можете использовать области авторизации вместо сопоставлений ролей.

В этом случае выполните следующие шаги:

По умолчанию у пользователей, проходящих аутентификацию через OpenID Connect, будут некоторые дополнительные поля метаданных. Эти поля будут включать все утверждения OpenID, предоставленные в ответе об аутентификации (независимо от того, сопоставлены ли они со свойством пользователя Elasticsearch). Например, в поле метаданных oidc(claim_name), «claim_name» — это имя утверждения, как оно содержалось в токене идентификации или в ответе User Info. Обратите внимание, что сюда будут включены все утверждения токена идентификации, относящиеся к событию аутентификации, а не к самому пользователю.

Это поведение можно отключить, добавив populate_user_metadata: false как настройку в области oidc.

Для аутентификации OpenID Connect в Kibana требуется небольшое количество дополнительных настроек помимо стандартной конфигурации безопасности Kibana. Документация по безопасности Kibana содержит подробную информацию о доступных вариантах конфигурации, которые вы можете применить.

В частности, поскольку ваши узлы Elasticsearch настроены на использование TLS на HTTP-интерфейсе, вам необходимо настроить Kibana на использование https URL для подключения к Elasticsearch, и вам может потребоваться настроить elasticsearch.ssl.certificateAuthorities на доверие сертификатам, которые были настроены для использования Elasticsearch.

Аутентификация OpenID Connect в Kibana подчиняется следующим настройкам таймаутов в 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 предназначена для аутентификации пользователей в Kibana, поэтому большинство разделов руководства предполагают использование Kibana. Этот раздел описывает, как пользовательское веб-приложение может использовать соответствующие REST API OpenID Connect для аутентификации пользователей в Elasticsearch с помощью OpenID Connect.

Сферы единого входа, такие как OpenID Connect и SAML, используют службу токенов в 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"]
}