Аутентификация JWT

Данные заголовка указывают тип токена и алгоритм, используемый для его подписи.

Токены содержат несколько данных, которые предоставляют информацию о пользователе, выпустившем токен, и о самом токене. В зависимости от типа токена, эта информация может быть представлена разными данными.

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

resp = client.security.put_role_mapping(
    name="jwt1_users",
    refresh=True,
    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,
)
print(resp)

const response = await client.security.putRoleMapping({
  name: "jwt1_users",
  refresh: "true",
  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,
});
console.log(response);

PUT /_security/role_mapping/jwt1_users?refresh=true
{
  "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 в домене JWT, доступны следующие утверждения для сопоставления ролей:

Если вы делегируете авторизацию другим доменам из домена JWT, доступно только утверждение principal для поиска ролей. При делегировании назначения и поиска ролей в другой домен из домена JWT утверждения для dn, groups, mail, metadata и name не используются для значений пользователя Elasticsearch. Только утверждение JWT principal передаётся делегированным доменам авторизации. Домены, которым делегирована авторизация (а не домен JWT), несут ответственность за заполнение всех значений пользователя Elasticsearch.

Следующий пример демонстрирует, как определить делегированную авторизацию в файле elasticsearch.yml для нескольких других доменов из домена JWT. Домен JWT с именем jwt2 делегирует авторизацию нескольким доменам:

xpack.security.authc.realms.jwt.jwt2.authorization_realms: file1,native1,ldap1,ad1

Затем вы можете использовать API создания или обновления сопоставлений ролей для сопоставления ролей с доменной авторизацией. Следующий пример сопоставляет роли в домене native1 для принципала JWT principalname1.

resp = client.security.put_role_mapping(
    name="native1_users",
    refresh=True,
    roles=[
        "user"
    ],
    rules={
        "all": [
            {
                "field": {
                    "realm.name": "native1"
                }
            },
            {
                "field": {
                    "username": "principalname1"
                }
            }
        ]
    },
    enabled=True,
)
print(resp)

const response = await client.security.putRoleMapping({
  name: "native1_users",
  refresh: "true",
  roles: ["user"],
  rules: {
    all: [
      {
        field: {
          "realm.name": "native1",
        },
      },
      {
        field: {
          username: "principalname1",
        },
      },
    ],
  },
  enabled: true,
});
console.log(response);

PUT /_security/role_mapping/native1_users?refresh=true
{
  "roles" : [ "user" ],
  "rules" : { "all" : [
      { "field": { "realm.name": "native1" } },
      { "field": { "username": "principalname1" } }
  ] },
  "enabled": true
}

Если домен jwt2 успешно аутентифицирует клиента с JWT для принципала principalname1 и делегирует авторизацию одному из указанных доменов (например, native1), то этот домен может найти значения пользователя Elasticsearch. С этим определённым сопоставлением ролей домен также может найти правило сопоставления ролей, связанное с доменом native1.

Elasticsearch может получать роли для пользователя JWT через сопоставление ролей или делегированную авторизацию. Независимо от выбранного варианта, вы можете применить привилегию run_as к роли, чтобы пользователь мог отправлять аутентифицированные запросы для выполнения действий от имени другого пользователя. Чтобы отправить запросы от имени другого пользователя, включите заголовок es-security-runas-user в свои запросы. Запросы выполняются так, как если бы они были выпущены этим пользователем, и Elasticsearch использует их роли.

Например, предположим, что есть пользователь с именем пользователя user123_runas. Следующий запрос создаёт роль пользователя с именем jwt_role1, которая определяет пользователя run_as с именем пользователя user123_runas. Любой пользователь с ролью jwt_role1 может отправлять запросы от имени указанного пользователя run_as.

resp = client.security.put_role(
    name="jwt_role1",
    refresh=True,
    cluster=[
        "manage"
    ],
    indices=[
        {
            "names": [
                "*"
            ],
            "privileges": [
                "read"
            ]
        }
    ],
    run_as=[
        "user123_runas"
    ],
    metadata={
        "version": 1
    },
)
print(resp)

const response = await client.security.putRole({
  name: "jwt_role1",
  refresh: "true",
  cluster: ["manage"],
  indices: [
    {
      names: ["*"],
      privileges: ["read"],
    },
  ],
  run_as: ["user123_runas"],
  metadata: {
    version: 1,
  },
});
console.log(response);

POST /_security/role/jwt_role1?refresh=true
{
  "cluster": ["manage"],
  "indices": [ { "names": [ "*" ], "privileges": ["read"] } ],
  "run_as": [ "user123_runas" ],
  "metadata" : { "version" : 1 }
}

Затем вы можете сопоставить эту роль с пользователем в определённом домене. Следующий запрос сопоставляет роль jwt_role1 с пользователем с именем пользователя user2 в домене JWT jwt2. Это означает, что Elasticsearch будет использовать домен jwt2 для аутентификации пользователя с именем user2. Поскольку у user2 есть роль (роль jwt_role1), которая включает привилегию run_as, Elasticsearch получает сопоставления ролей для пользователя user123_runas и использует роли этого пользователя для отправки запросов.

resp = client.security.put_role_mapping(
    name="jwt_user1",
    refresh=True,
    roles=[
        "jwt_role1"
    ],
    rules={
        "all": [
            {
                "field": {
                    "realm.name": "jwt2"
                }
            },
            {
                "field": {
                    "username": "user2"
                }
            }
        ]
    },
    enabled=True,
    metadata={
        "version": 1
    },
)
print(resp)

const response = await client.security.putRoleMapping({
  name: "jwt_user1",
  refresh: "true",
  roles: ["jwt_role1"],
  rules: {
    all: [
      {
        field: {
          "realm.name": "jwt2",
        },
      },
      {
        field: {
          username: "user2",
        },
      },
    ],
  },
  enabled: true,
  metadata: {
    version: 1,
  },
});
console.log(response);

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

После сопоставления ролей вы можете выполнить аутентифицированный вызов Elasticsearch с использованием JWT и включить заголовок 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_role1, которую вы сопоставили с этим пользователем в домене JWT:

{"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 (JWKS) могут содержать публичные ключи RSA и EC. HMAC JWKS или HMAC UTF-8 JWK содержат секретные ключи. Издатели JWT обычно чаще обновляют PKC JWKS (например, ежедневно), потому что публичные ключи RSA и EC предназначены для более лёгкого распространения, чем секретные ключи, такие как HMAC.

Домены JWT загружают PKC JWKS и HMAC JWKS или HMAC UTF-8 JWK при запуске. Домены JWT также могут перезагружать содержимое PKC JWKS во время выполнения; перезагрузка инициируется ошибками проверки подписи.

Ошибки загрузки, ошибки разбора и ошибки конфигурации препятствуют запуску (и перезапуску) узла. Однако ошибки и восстановления PKC во время выполнения обрабатываются без проблем.

Все другие проверки домена JWT проверяются до того, как ошибка подписи может инициировать перезагрузку PKC JWKS. Если несколько ошибок подписи JWT происходят одновременно на одном узле Elasticsearch, перезагрузки объединяются для уменьшения количества перезагрузок, отправляемых внешнему интерфейсу.

Отдельные запросы на перезагрузку не могут быть объединены, если ошибки подписи JWT инициируют:

Следующие значения предназначены для настраиваемого JWT-эмитента.

Issuer:     iss8
Audiences:  aud8
Algorithms: HS256
HMAC UTF-8: hmac-oidc-key-string-for-hs256-algorithm

Чтобы определить домен JWT, добавьте следующие настройки домена в 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

После определения настроек домена используйте инструмент elasticsearch-keystore, чтобы добавить следующие безопасные настройки в хранилище ключей Elasticsearch. В Elastic Cloud вы определяете настройки для хранилища ключей 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

Следующий запрос создает сопоставления ролей для Elasticsearch в домене jwt8 для пользователя principalname1:

resp = client.security.put_role_mapping(
    name="jwt8_users",
    refresh=True,
    roles=[
        "user"
    ],
    rules={
        "all": [
            {
                "field": {
                    "realm.name": "jwt8"
                }
            },
            {
                "field": {
                    "username": "principalname1"
                }
            }
        ]
    },
    enabled=True,
)
print(resp)

const response = await client.security.putRoleMapping({
  name: "jwt8_users",
  refresh: "true",
  roles: ["user"],
  rules: {
    all: [
      {
        field: {
          "realm.name": "jwt8",
        },
      },
      {
        field: {
          username: "principalname1",
        },
      },
    ],
  },
  enabled: true,
});
console.log(response);

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, ответ включает роль пользователя, их username, метаданные о пользователе и подробности о самом домене JWT.

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