Глава 6. Аутентификация – Книга рецептов NGINX

Задача

Вам требуется сделать безопасным ваше приложение или содержимое посредством базовой аутентификации HTTP.

Решение

Создайте некий файл с приводимым ниже форматом, в котором пароль зашифрован или хэширован в одном из допустимых
форматов:

# comment
name1:password1
name2:password2:comment
name3:password3
 	   

Значением имени пользователя является самое первое поле, в качетсве пароля выступает второе поле, а разделителем
является двоеточие. Существует необязательный третий параметр, который вы можете применять в качестве комментария для
каждого пользователя. NGINX способен понимать несколько различных форматов для паролей, причём один из них состоит в том
зашифрован ли пароль при помощи функции C crypt(). Эта функция выставляется в
командной строке через соотвествующую команду openssl passwdю Когда установлен
openssl, вы можете создавать строки зашифрованных паролей с использованием такой
команды:

$ openssl passwd MyPassword1234
 	   

Её выводом будет некая трока, которую NGINX способен применять в вашем файле паролей.

Для включения базовой аутентификации в рамках своей конфигурации NGINX применяйте имеющиеся директивы
auth_basic и auth_basic_user_file:

location / {
    auth_basic "Private site";
    auth_basic_user_file conf.d/passwd;
}
 	   

Вы можете применять директивы auth_basic в контекстах HTTP, server, location.
Эта директива auth_basic получает некий строковый параметр, который отображается
в базовом всплывающем окне аутентификации при появлении пользователя без аутентификации. Значение
auth_basic_user_file определяет путь к надлежащему файлу пользователей.

Обсуждение

Вы можете вырабатывать пароли базовой аутентификации несколькими способами в ряде различных форматов с отличающимися
степенями безопасности. Для выработки паролей также может применяться и команда
htpasswd из Apache. И команда openssl, и команда
htpasswd способны вырабатывать пароли с применением алгоритма apr1,
который также способен понимать и NGINX. Этот пароль также может быть в формате Соли SHA-1, который применяется в LDAP (Lightweight Directory Access Protocol) и Dovecot. NGINX поддерживает
дополнительные форматы и алгоритмы хэширования; однако многие из них рассматриваются как не безопасные, так как они запросто
могут быть побеждены силовой атакой в лоб.

Вы можете применять базовую аутентификацию для защиты своего содержимого всего хоста NGINX целиком, определённых
виртуальных серверов или даже конкретных блоков location. Базовая аутентификация на заменяет аутентификацию пользователя
для веб- приложения, но она способствует поддержанию безопасности частной информации.

Под своим капотом базовая аутентификация выполняется путём возврата самим сервером некого кода HTTP 401 unauthorized
с заголовком отклика WWW-Authenticate. Этот заголовок будет иметь некое значение
Basic realm="your string". Такой отклик вызывает у браузера
приглашение на ввод имени пользователя и пароля. Значения имени пользователя соединяются при помощи разделителя двоеточием,
после этого кодируются в base64 и затем отправляются в неком заголовке запроса с названием
Authorization. Этот заголовок запроса Authorization
определит Basic и зашифрованную строку user:password.
Сам сервер расшифровывает полученный заголовок и проверяет его по предоставленному файлу
auth_basic_user_file. По той причине, что строки имени пользователя и пароля шифруются
лишь base64, рекомендуется для базовой аутентификации использовать HTTPS.

Задача

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

Решение

Для осуществления запросов к внешней службе аутентификации на предмет проверки подлинности перед обслуживанием
полученного запроса воспользуйтесь модулем http_auth_request_module:

location /private/ {
    auth_request /auth;
    auth_request_set $auth_status $upstream_status;
}

location = /auth {
    internal;
    proxy_pass http://auth-server;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
}
 	   

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

Обсуждение

Обсуждаемый http_auth_request_module делает возможной аутентификацию всех
обрабатываемых вашим сервером NGINX запросов. Этот модуль выполняет некий подзапрос прежде чем обслуживать первоисточник
для выяснения того имеет ли этот запрос доступ к запрашиваемому ресурсу. Весь первоначальный запрос целиком выставляется
в посредник (прокси) в location такого подзапроса. Имеющийся location аутентификации действует как типичный посредник для
получаемого подзапроса и отправляет сам первоначальный запрос, включая полученное тело первоначального запроса и заголовки.
Получаемое значение кода состояния HTTP данного подзапроса является тем, что определяет будет ли предоставлен доступ или
нет. Если этот подзапрос возвращает некий код состояния HTTP 200, данный процесс аутентификации успешен и сам запрос
выполняется. Если же наш подзапрос возвращает HTTP 401 или 403, это же значение будет возвращено в сам первоначальный
запрос.

Когда ваша служба аутентификации не запрашивает поступившее тело запроса, вы можете откинуть такое тело запроса
с помощью отражённой в примере директивыproxy_pass_request_body. Такая практика
снизит размер и время запроса аутентификации. Так как само тело отклика отбрасывается, его заголовок
Content-Length должен быть снабжён пустой строкой. Если ваша служба аутентификации
нуждается в знании того URI, который запрашивается данным запросом, вы пожелаете помещать это значение в неком
индивидуальном заголовке который будет проверять и подтверждать ваша служба аутентификации. Если имеются некие
моменты, которые вы бы хотели оставлять в своём подзапросе к службе аутентификации, например заголовки отклика или прочая
информация, вы можете воспользоваться директивой auth_request_set для создания
новых переменных из данных отклика.

Задача

Для применения в NGINX Plus вам требуется веб ключ JSON.

Решение

NGINX Plus применяется определённый в соответствующем RFC стандарте формат значения JWK (JSON Web Key). Этот стандарт
допускает внутри такого файла JWK некий массив объектов ключей.

Ниже приводится некий образец того как может выглядеть подобный файл ключей:

{"keys":
  [
    {
        "kty":"oct",
        "kid":"0001",
        "k":"OctetSequenceKeyValue"
    },
    {
        "kty":"EC",
        "kid":"0002"
        "crv":"P-256",
        "x": "XCoordinateValue",
        "y": "YCoordinateValue",
        "d": "PrivateExponent",
        "use": "sig"
    },
    {
        "kty":"RSA",
        "kid":"0003"
        "n": "Modulus",
        "e": "Exponent",
        "d": "PrivateExponent"
    }
  ]
}
 	   

Приведённый файл JWK демонстрирует определённое дерево изначальных типов ключей, упомянутых в самом стандарте
RFC. Описание формата этих ключей также является частью указанного стандарта RFC. Значением атрибута
kty тип ключа. Данный файл отображает три типа ключей: Последовательность
октетов (oct, Octet Sequence), координаты Эллиптической кривой
(EC, EllipticCurve) и значение типа RSA.
Значением атрибута kid является идентификатор ключа. Для получения дополнительных
сведений относительно этих стандартов обращайтесь к соответствующей документации RFC.

Обсуждение

Для генерации необходимого веб ключа JSON существует множество доступных во многих разнообразных языках
программирования библиотек. Рекомендуется создать некую службу ключа, которая выступает центом авторизации JWK для
создания и ротации ваших JWK через систематические интервалы. Для дополнительной безопасности рекомендуется делать ваши
JWK настолько же безопасными, как и ваши сертификаты SSL/ TLS. Обезопасьте свой файл ключей соответствующими полномочиями
пользователя и группы. Наилучшей практикой будет удержание их в оперативной памяти. Вы можете делать это создавая некую
файловую систему в памяти, подобную ramfs. Ротация ключей через систематические интервалы также важно; в качестве варианта
вы можете создать некую службу ключей, которая создаёт общедоступные и частные ключи и предлагает их имеющимся
приложениям и NGINX через некий API.

Также ознакомьтесь

RFC standardization documentation of JSON Web Key

Задача

Вы желаете разгрузить для NGINX Plus удостоверения аутентификации OpenID Connect.

Решение

Для безопасности location или server, а также указания директиве auth_jwt
применять в качестве маркера (token) $cookie_auth_token для удостоверения применяйте
модуль JWT, который поставляется совместно с NGINX Plus:

location /private/ {
    auth_jwt "Google Oauth" token=$cookie_auth_token;
    auth_jwt_key_file /etc/nginx/google_certs.jwk;
}
 	   

Данная конфигурация направляет NGINX Plus защищать свой путь URI /private/
при помощи удостоверения через JWT. Google OAuth 2.0 OpenID Connect применяет значение ключа
auth_token вместо установленного по умолчанию однонаправленного маркера.
Таким образом вы должны указать NGINX о необходимости поиска значения данного маркера (token) в данном куки вместо
использования установленного по умолчанию в самом NGINX Plus location. Местоположение
auth_jwt_key_file настраивается на некий произвольный путь, что является неким
этапом, который мы обсуждаем в рецепте
Получение значения веб ключей JSON из Google.

Обсуждение

Данная конфигурация демонстрирует как вы можете выполнять удостоверение Google OAuth 2.0 OpenID Connect JSON Web
Token через NGINX Plus. Обсуждаемый модуль аутентификации JWT NGINX Plus для HTTP способен выполнять удостоверение
любого JWT, который следует указаниям спецификации RFC for JSON Web Signature, что незамедлительно делает возможными
любые полномочия SSO которые применяют JSON Web Tokens для удостоверения на уровне NGINX Plus. Сам протокол OpenID 1.0
является неким уровнем поверх протокола аутентификации OAuth 2.0, который добавляет идентификацию, позволяя такое применение
JWT для доказательства необходимой идентификации определённого пользователя отправляя соответствующий запрос.
Имея подпись конкретного маркера NGINX Plus способен удостоверить что такой маркер не был изменён так как он был подписан.
Тем самым Google применяет некий асинхронный метод подписи и позволяет распространять общедоступные JWK отслеживая их
частные ключи безопасности JWK.

NGINX Plus способен также контролировать для OpenID Connect 1.0 Поток кода авторизации, включая NGINX Plus в качестве
ретранслятора для OpenID Connect. Такая возможность делает возможной интеграцию с большей частью поставщиков идентификации,
включая CA Single Sign On (ранее SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin и Ping Identity. Для получения
дополнительных сведений о реализации NGINX Plus в качестве ретранслятора аутентификации OpenID Connect обратитесь к
NGINX Inc OpenID Connect GitHub Repository

Также ознакомьтесь

Detailed NGINX Blog on OpenID Connect

OpenID Connect