---
title: nginx auth_request (2/3): Многофакторная авторизация, NFA
tags: nginx, software, devel, репост
---
- [Вводная](/articles/2017/05/16/nginx-authreq-1/)
- [Многофакторная авторизация, NFA](/articles/2017/05/17/nginx-authreq-2/)
- [WAF, Web-Application firewall](/articles/2017/05/18/nginx-authreq-3/)
В этой статье рассмотрим, как *в принципе* делается кастомный портал с авторизацией на базе `nginx_authreq`.
Вся авторизация держится на предположении, что юзеру известен некий секрет, недоступный другим.
Правда если его украсть или скопировать - система не может распознать обмана.
---
N-факторная авторизация - это попытка убрать этот недостаток, путём использования нескольких "секретов" одновеременно.
Украсть N разных секретов в N раз сложнее (если только юзер не ССЗБ, хранящий всё в одном месте).
В быту, под "N-факторной авторизацией" чаще все понимают пару *логин/пароль*, *смс/email/токен* и возможно что-то ещё, например заход строго с определённоой сети.
В качестве второго компонента, СМС встречается чаще, поскольку привязывает авторизацию к обладанию физической вещью (телефон с определённой симкой), скопировать которую проблематично (но не невозможно).
Однако, давайте ближе к практике. Вот у нас есть некий сайт, с собственной системой авторизации, к которому нужно дополнительно ограничить доступ.
Например, мы - онлайн банк, предоставляем доступ к операциям со счётом.
Схема авторизации может выглядеть следующим образом:
- запросить логин/пароль
- при совпадении пары выше - выслать дополнительный код (действующий ограниченное время) по смс на предварительно указанный номер.
- запросить высланный код
- при совпадении кода - пустить на сайт, иначе - ошибка
Эта схема может применяться только в том случае, если мы можем влиять на все этапы процесса авторизации.
Если же такой возможности нет - "многофакторная" авторизация превращается в "многоступенчатую".
Например, мы - хостер, предоставляем доступ к ipkvm. На саму железку мы влиять не можем, её прошивку писали не мы.
В этом случае, схема авторизации будет такой:
- запросить логин/пароль хостера
- при совпадении пары выше - выслать дополнительный код (действующий ограниченное время) по смс на предварительно указанный номер.
- запросить высланный код
- при совпадении кода - пустить на вторую стадию авторизации (самого ipkvm'а)
Сделать так, чтобы гипотетический ipkvm понимал данные с "первого этапа" не всегда представляется возможным,
вследствие частой практики фундаментального огораживания своих девайсов среди производителей.
Давайте ещё ближе к практике. Как это будет выглядеть на уровне конфигов и кода?
Конфиг nginx из предыдущей статьи:
location / {
auth_request /check;
proxy_pass http://site.example.com;
}
location = /check {
internal;
proxy_pass http://127.0.0.1:3000/check;
proxy_pass_request_body off; # <- важно
proxy_set_header Content-Length "0"; # <- важно
proxy_set_header X-Original-URI $request_uri;
}
Обработчик `http://127.0.0.1:3000/check`:
sub check {
<...>
if ($self->session('user')) {
# авторизованный юзер
$self->res->code(200);
$self->render(text => 'OK');
}
eval {
# неизвестный юзер
$self->res->code(403); # default deny
my $user = $self->req->param('user');
my $pass = $self->req->param('pass');
my $code = $self->req->param('code');
if ($code and $user) {
# формой отправлен предполагаемый логин и код из sms
my $test = $self->app->redis->get("$user:code");
unless ($test) {
# мы не посылали кода этому юзеру в последнее время, пнх
$self->render('pages/stage1', msg => 'invalid session');
} elsif ($code eq $test) {
# указан правильный код
$self->app->redis->del("$user:code");
$self->session(user => $user); # см блок выше, до eval {}
$self->render(text => 'OK');
} else {
# указан неправильный код, откатываемся на 1ю стадию
$self->app->redis->del("$user:code");
$self->render('pages/stage1', msg => 'wrong code');
}
} elsif ($user and $pass) {
# формой отправлен логин/пароль для проверки
if (check_user_credentials($user, $pass)) {
# юзер существует и пароль верен
my $phone = get_user_phone($user);
if ($phone) {
# для указанного юзера задан телефон
$code = generate_auth_code();
$self->app->redis->set("$user:code" => $code);
$self->app->redis->expire("$user:code" => 60); # код будет верен в течении минуты
send_sms($phone, "your auth code is: $code");
$self->render('pages/stage2', msg => 'code sent to your phone');
} else {
$self->render('pages/stage1', msg => 'no configured phone number for this user');
}
} else {
$self->render('pages/stage1', msg => 'no such user / wrong password');
}
} else {
# данных нет, показываем стандартную форму логина
$self->render('pages/stage1');
}
} or do {
$self->res->code(500);
self->render('pages/error', msg => 'internal error');
};
}
В пример выше используется Mojolicious + redis, но с равным успехом может использоваться CGI, а в качестве хранилища - sqlite, bdb, dbm, memcached или просто обычные файлы.
На самом деле, это - нерабочий пример. Почему? Потому что особенности™ работы `auth_req`.
На самом деле nginx полностью игнорирует тело ответа от этого модуля и вместо него выдаёт свою стандартную страницу ошибки.
Значения имеют только коды возврата, модуль обрабатытвает всего 3 случая: 200, 401 и *всё остальное.
Мы даже не можем манипулировать состоянием через cookie, поскольку этот заголовок тоже не копируется в ответ.
Только WWW-Authenticate и только при коде ответа 401.
Следовательно, мы должны переписать пример выше так, чтобы использовались только коды статуса.
Здесь нам поможет следующее шаманство:
- выносим из `sub check {}` в новый обработчик всё, кроме первого блока.
- в конце оставляем `$self->res->code(403); $self->render(text => 'auth');`
- в nginx `location /auth` переопределяем коды 401,403 на путь к новому обрабобтчику
- добавляем ещё один блок `location` уже для второго обработчика
Второй блок нужен для того, чтобы `/auth`: а) не попала под действие `/check`, б) ему надо передавать данные через POST.
Конфиг и код примут следующий вид:
# Новый блок в nginx
location = /auth {
internal;
proxy_pass http://127.0.0.1:3000/auth;
# proxy_pass_request_body off; # <- важно
# proxy_set_header Content-Length "0"; # <- важно
proxy_set_header X-Original-URI $request_uri;
}
# то что осталось от первоначального обработчика
sub check {
<...>
if ($self->session('user')) {
# авторизованный юзер
$self->res->code(200);
$self->render(text => 'OK');
}
$self->res->code(403);
$self->render(text => 'auth');
}
# всё остальное перехало сюда:
sub auth {
<...>
}
Граф вызовов в случае успешной авторизации с первого раза ([исходник](req-graph.msc)).
Примерное содержимое [pages/stage1](stage1.txt), [pages/stage2](stage2.txt).
Любителям подключать тонну css и js на заметку: это всё придётся либо встраивать в страничку, либо мутить ТРЕТИЙ блок `location` в nginx, чтобы оно опять не попало под действие `/check`.
Впрочем, можно сразу "провалить" всю машинерию на уровень ниже, например под `/auth`. Т.е. так:
* /check -> /auth/check (описывается специальной локацией с точным соотвествием)
* /auth -> /auth/login (описывается общей локацией для /auth, т.е. всё что не /auth/login -- пересылать туда-то через `proxy_pass`)
Ну и на закуску - что даёт патч, приведённый в первой части, применительно к данной конфигурации. Удобство!
Уходит необходимость в `error_page`, появляется возможность собрать логику в одном месте, и разруливать различные остояния не кодами статуса, а сразу редиректами.
Плюс к тому же появляется возможность передать если не куку, то какой-то параметр через url (хак с `error_page` опять же такого не может).
В данном примере использования, нас спасает то, что состояний по сути всего 2: известный пользователь (пропускаем) и неизвестный пользователь (перенаправляем на логин).
3х доступных кодов ответа, из которых один (401й) использовате нежелательно из-за побочных эффектов (лезет браузерная форма с паролем)
как раз хватает на 2 основных состояния (варианты "неизвестного пользователя" дополнительно разруливаются в обработчике /auth).
Теперь представьте, что основных состояний хотя бы 5-6 (известный юзер, неизвестный с кукой, неизвестный без куки, подозрительный, заблокирован временно, заблокирован постоянно).
Шаманство с `error_page` здесь уже не прокатит, тупо не хватит различаемых модулем кодов.
В следующей части - построение кастомного WAF (Web Application Firewall) на базе этого же модуля.