---
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)).

![](req-graph.png)

Примерное содержимое [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) на базе этого же модуля.