пт, 1 янв. 2021 г. в 22:47, Vladislav Shabanov <vlad.shaba...@gmail.com>:
> Добрый день!
>
> Хочу посоветоваться.
> Есть сервер, где зона «для сотрудников» закрыта двумя слоями авторизации:
> auth_basic
> + проверка на уровне приложения, с куками, сессиями и прочим.
>
> Отказываться от auth_basic не хочется:
>
> - В коде приложения запросто могут быть ошибки. Забыли, например,
> завернуть какую-нибудь функцию приложения в декоратор и получили дырку в
> защите.
> - Сессионную куку могут угнать. XSS, «мутные» плагины для браузеров и
> т. д.
> - Есть «интимная» статика, которую проверять через auth_request не
> хочется, т.к. замедляет.
>
> Проблема в том, что большинство браузеров неудобно работают с basic_auth:
> Сафари под iPhone спрашивает пароль каждые несколько часов и даже не
> заморачивается, чтобы его запомнить. FireFox после рестарта показывает
> модальный диалог со вводом пароля в одном из окон и блокирует все остальные
> окна с тем же сайтом. Неудобно, короче.
>
> Настроил клиентские сертификаты. Есть сотни мануалов, ничего интересного.
> Но вот раздача сертификатов сотрудникам и установка их в браузеры – дело
> муторное. У каждого браузера свои тараканы, сложно объяснить сотруднику по
> телефону, как поставить сертификат в его браузер и т. д. А если сертификат
> устареет или придётся его отозвать, совсем беда.
>
> Поэтому решил сделать вот какую логику:
>
> - Если браузер предъявил сертификат, то *auth_basic* не требуем.
> - Если не предъявил, то пусть вводит логин+пароль через *auth_basic*.
> - Проверка доступа на уровне приложения никуда не девается, работаем
> по старому.
>
>
тут есть подводные камни как минимум с сафари.
браузер предъявил или браузер не предъявил на транспортном уровне работает
таким образом
1) в серверном SSL Hello выставляется флаг "хочу сертификат"
(вы можете намекнуть клиенту, на каких именно УЦ вы хотели бы видеть
сертификат, либо "*ssl_verify_client* optional_no_ca;", если вы готовы
принимать сертификат любого УЦ)
2) нормальный браузер реагирует так, если он видит, что у него нет
клиентских сертификатов на требуемом УЦ, он не пытается спросить у
пользователя, и отправляет запрос без сертификата
3) сафари будет требовать пользователя сертификат в любом случае
далее на стороне nginx можно настроить обработчик 496 ошибки, мы с таким
игрались, туда попадет трафик без клиентских сертов (и там вы сможете
реализовать нужную вам логику)
> Я не нашёл способа, как настроить конфиг nginx, чтобы эту логику
> реализовать. Конструкции с
>
> if $ssl_client_verify == "SUCCESS" {}
>
> несовместимы с auth_basic.
>
error_page 496 .....
>
> Пока придумал только одно: отпатчил *ngx_http_auth_basic_module.c*,
> сделал в нём директиву
>
> *auth_basic_skip_if_client_cert* *on/off*
>
> по которой проверка пароля выключается, если предъявлен валидный
> клиентский сертификат.
>
> Вопросы:
>
> 1. Может быть, кто-то решал аналогичную задачу? Чтоб и два слоя защиты
> для страховки и удобство в повседневной работе?
>
>
кроме описанной вами трудностей с доставкой и установкой клиентских сертов
еще есть неприятное поведение сафари
>
> 1. Существует ли решение без патча ngx_http_auth_basic_module.c?
> 2. Интересен ли кому-нибудь этот патч? Может, на моём велосипеде ещё
> кто-нибудь хочет покататься? :)
>
>
как-то сейчас oauth более в тренде
>
> С уважением,
> Владислав
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
