Настройка единого входа SAML в Elastic Stack

Elastic Stack поддерживает профили SAML 2.0 SSO веб-браузера и однократного выхода и может интегрироваться с любым провайдером идентификации (IdP), поддерживающим как минимум профиль SAML 2.0 SSO веб-браузера. Он был протестирован с рядом популярных реализаций IdP, таких как Microsoft Active Directory Federation Services (ADFS), Azure Active Directory (AAD) и Okta.

Это руководство предполагает, что у вас уже есть существующий IdP и вы хотите добавить Kibana в качестве провайдера сервисов.

Elastic Stack использует стандартный документ метаданных SAML в формате XML, определяющий возможности и характеристики вашего IdP. Вы должны иметь возможность загрузить или сгенерировать такой документ в интерфейсе администрирования вашего IdP.

Загрузите документ метаданных IdP и сохраните его в каталоге config на каждом узле Elasticsearch. Для целей этого руководства мы предположим, что вы сохраняете его как config/saml/idp-metadata.xml.

IdP будет присвоен идентификатор (EntityID в терминологии SAML), который чаще всего выражается в форме Унифицированного идентификатора ресурса (URI). Интерфейс администрирования может сообщить вам об этом, или вам может потребоваться прочитать документ метаданных, чтобы найти его - ищите атрибут entityID в элементе EntityDescriptor.

Большинство IdP предоставят соответствующий файл метаданных со всеми необходимыми для Elastic Stack функциями и потребуют только шаги по настройке, описанные ниже. Для полноты, минимальные требования Elastic Stack к метаданным IdP:

Elastic Stack требует, чтобы все сообщения от IdP были подписаны. Для аутентификационных <Response> сообщений подпись может быть применена либо к самому ответу, либо к отдельным утверждениям. Для <LogoutRequest> сообщений само сообщение должно быть подписано, а подпись должна быть предоставлена в качестве параметра URL, как требуется для связи HTTP-Redirect.

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

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

Это пример простого сопоставления ролей, которое предоставляет роль example_role любому пользователю, который аутентифицируется в области saml1:

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

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

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

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

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

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

Если ваш IdP имеет возможность предоставлять группы или роли поставщикам услуг, то вы должны сопоставить этот атрибут SAML с настройкой attributes.groups в области Elasticsearch, а затем использовать его в сопоставлении ролей, как показано в примере ниже.

Это сопоставление предоставляет роль Elasticsearch finance_data для всех пользователей, которые аутентифицируются через область saml1 с группой finance-team.

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

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

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

Если ваши пользователи также существуют в хранилище, к которому Elasticsearch может получить прямой доступ (например, в каталоге LDAP), то вы можете использовать области авторизации вместо сопоставлений ролей.

В этом случае выполните следующие шаги: 1. В области SAML назначьте атрибут SAML в качестве идентификатора пользователя для поиска, настроив настройку attributes.principal. 2. Создайте новую область, которая может искать пользователей в вашем локальном хранилище (например, область ldap). 3. В области SAML установите authorization_realms в имя области, созданной на шаге 2.

По умолчанию у пользователей, аутентифицирующихся по SAML, есть дополнительные поля метаданных.

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

Для аутентификации по SAML в Kibana требуется несколько дополнительных настроек помимо стандартной конфигурации безопасности Kibana. Подробную информацию об доступных параметрах конфигурации вы найдете в документации по безопасности Kibana.

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

Аутентификация по SAML в Kibana зависит от следующих параметров таймаутов в kibana.yml:

Возможно, вам нужно будет изменить эти таймауты в соответствии с вашими требованиями безопасности.

Три дополнительных параметра, необходимые для поддержки SAML, показаны ниже:

xpack.security.authc.providers:
  saml.saml1:
    order: 0
    realm: "saml1"

Значения конфигурации, используемые в примере выше:

xpack.security.authc.providers:
  saml.saml1:
    order: 0
    realm: "saml1"
  basic.basic1:
    order: 1

xpack.security.authc.realms.saml.saml_finance:
  order: 2
  idp.metadata.path: saml/idp-metadata.xml
  idp.entity_id: "https://sso.example.com/"
  sp.entity_id:  "https://kibana.finance.example.com/"
  sp.acs: "https://kibana.finance.example.com/api/security/saml/callback"
  sp.logout: "https://kibana.finance.example.com/logout"
  attributes.principal: "urn:oid:0.9.2342.19200300.100.1.1"
  attributes.groups: "urn:oid:1.3.6.1.4.1.5923.1.5.1."
xpack.security.authc.realms.saml.saml_sales:
  order: 3
  idp.metadata.path: saml/idp-metadata.xml
  idp.entity_id: "https://sso.example.com/"
  sp.entity_id:  "https://kibana.sales.example.com/"
  sp.acs: "https://kibana.sales.example.com/api/security/saml/callback"
  sp.logout: "https://kibana.sales.example.com/logout"
  attributes.principal: "urn:oid:0.9.2342.19200300.100.1.1"
  attributes.groups: "urn:oid:1.3.6.1.4.1.5923.1.5.1."
xpack.security.authc.realms.saml.saml_eng:
  order: 4
  idp.metadata.path: saml/idp-external.xml
  idp.entity_id: "https://engineering.sso.example.net/"
  sp.entity_id:  "https://kibana.engineering.example.com/"
  sp.acs: "https://kibana.engineering.example.com/api/security/saml/callback"
  sp.logout: "https://kibana.engineering.example.com/logout"
  attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"

Спецификация SAML 2.0 предоставляет множество вариантов и гибкости разработчикам, что, в свою очередь, добавляет сложности и количество доступных параметров конфигурации как для поставщика услуг (Elastic Stack), так и для поставщика удостоверений. Кроме того, различные домены безопасности имеют разные требования к безопасности, которые требуют специфической конфигурации. Были предприняты сознательные усилия, чтобы скрыть эту сложность с помощью разумных значений по умолчанию и подробной документации выше, но в случае возникновения проблем при настройке домена SAML, вы можете ознакомиться с нашей документацией по устранению неполадок SAML, которая содержит рекомендации и решения распространенных проблем.

Домен SAML в Elasticsearch разработан для того, чтобы пользователи могли аутентифицироваться в Kibana, и поэтому большая часть руководства выше предполагает, что используется Kibana. В этом разделе описывается, как пользовательское веб-приложение может использовать соответствующие REST-API SAML для аутентификации пользователей в Elasticsearch с помощью SAML.

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

resp = client.security.put_role(
    name="saml-service-role",
    cluster=[
        "manage_saml",
        "manage_token"
    ],
)
print(resp)

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

POST /_security/role/saml-service-role
{
  "cluster" : ["manage_saml", "manage_token"]
}

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

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

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

resp = client.security.saml_authenticate(
    content="PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMD.....",
    ids=[],
)
print(resp)

const response = await client.security.samlAuthenticate({
  content:
    "PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMD.....",
  ids: [],
});
console.log(response);

POST /_security/saml/authenticate
{
  "content" : "PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMD.....",
  "ids" : []
}