Тут не в технике проблема. Проблема в людях.<br>Пример: разработчики (некий аутсорс) выпустили новый релиз веб-приложения, передали нашим тестировщикам. Тестировщики быстренько согласовали с админами тест-бекенда, залили апдейт, погоняли тесты, потом уже спокойненько согласовали план работ на внедрение в бой и в течение какого-то времени все это безобразие внедряется в бой, с балансировщиками, фронтендами, файерволами, айпиэсами и т.п. <br>
Так вот, если мы внедрим аутентификацию на фронтенде и жестко всех заставим работать через него, то в цепочку согласований-настроек войдет еще одно подразделение, чего хотелось бы избежать. <br><br><div class="gmail_quote">
5 сентября 2009 г. 20:36 пользователь Sergey Shepelev <span dir="ltr"><<a href="mailto:temotor@gmail.com">temotor@gmail.com</a>></span> написал:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Бекендом редиректите неавторизованных на фронтенд.<br>
<br>
2009/9/5 Бондарец Иван <<a href="mailto:bondarets@gmail.com">bondarets@gmail.com</a>>:<br>
<div><div></div><div class="h5">> Понятно, спасибо.<br>
> Я тоже предлагал аутентифицировать на фронтэнде, но некоторые категории<br>
> пользователей (админы, технологи, тестировщики-функциональщики, etc.)<br>
> зачастую ходят напрямую на backend, вот их-то запросы тоже нужно шифровать и<br>
> аутентифицировать (не все, а только обращения к приложениям с критичными с<br>
> точки зрения ИБ данным). Видимо придется вносить акцесс-лист на backend'е,<br>
> чтобы кроме фронтэнда никто не мог запрашивать, а всех этих товарищей<br>
> заставлять работать через фронтэнд. Но эта задачка может изрядно затянуться<br>
> в реализации, это ж нарушение священной мантры "работает - не трогай!",<br>
> будет много несогласных. К тому же сопровождение фронтэндов и бакэндов -<br>
> разные люди в разных отделах, т.е. при каждом изменении тетировщикам<br>
> придется согласовывать работы еще и на фронтэндах до начала функционального<br>
> тестирования, что однозначно внесет задержку в и так не быстрый процесс...<br>
> Всё же хочу еще раз уточнить - моя задачка не реализуема в принципе или не<br>
> реализуема средствами nginx? Может кому-то известны программы/железки,<br>
> которые умеют выполнять такую задачку?<br>
><br>
> 5 сентября 2009 г. 17:06 пользователь Igor Sysoev <<a href="mailto:is@rambler-co.ru">is@rambler-co.ru</a>><br>
> написал:<br>
>><br>
>> On Sat, Sep 05, 2009 at 04:17:32PM +0400, Igor Sysoev wrote:<br>
>><br>
>> > On Sat, Sep 05, 2009 at 01:36:22PM +0400, Бондарец Иван wrote:<br>
>> ><br>
>> > > Добрый день!<br>
>> > > Есть стандартная схема:<br>
>> > > Интернет -> nginx --> backend (Apache либо WebSphere)<br>
>> > > nginx сейчас терминирует на себе ssl и проксирует на backend.<br>
>> > > Возникла задачка аутентифицировать пользователей на некоторых разделах<br>
>> > > сайта<br>
>> > > на backend'e при помощи сертификатов. Можно ли настроить nginx на<br>
>> > > такой<br>
>> > > режим работы? В моем понимании, на backend'е нужно поднять ssl (с<br>
>> > > более<br>
>> > > слабым ключом, например) и настроить авторизацию по сертификатам, это<br>
>> > > я<br>
>> > > сделал:<br>
>> > > SSLEngine on<br>
>> > > SSLCipherSuite<br>
>> > ><br>
>> > > ALL:!ADH:!DH:!EDH:!KRB5:!IDEA:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br>
>> > > SSLCertificateFile /etc/apache2/ssl.crt/apache.crt<br>
>> > > SSLCertificateKeyFile /etc/apache2/ssl.key/apache.key<br>
>> > > SSLProtocol +SSLv3 +TLSv1<br>
>> > > SSLVerifyClient require<br>
>> > > SSLCACertificateFile /path/to/ca.crt<br>
>> > ><br>
>> > > Далее в конфиге nginx пишу:<br>
>> > > server {<br>
>> > > listen 443;<br>
>> > > server_name test1;<br>
>> > > ssl on;<br>
>> > > ssl_certificate /etc/apache2/ssl.crt/apache.crt;<br>
>> > > ssl_certificate_key /etc/apache2/ssl.key/apache.key;<br>
>> > ><br>
>> > > ssl_session_timeout 5m;<br>
>> > ><br>
>> > > ssl_protocols SSLv2 SSLv3 TLSv1;<br>
>> > > ssl_ciphers<br>
>> > ><br>
>> > > ALL:!ADH:!DH:!EDH:!KRB5:!IDEA:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL;<br>
>> > > ssl_prefer_server_ciphers on;<br>
>> > > location / {<br>
>> > > proxy_pass <a href="https://1.2.3.4:443" target="_blank">https://1.2.3.4:443</a>;<br>
>> > > }<br>
>> > ><br>
>> > > }<br>
>> > ><br>
>> > > Проверяю аутентификацию при обращении непосредственно к backend'у - на<br>
>> > > IE6,7,8 и Safari 4.0.2 работает, на FF 3.5.2, Opera 10, Chrome - не<br>
>> > > работает, пишет что-то вроде этого:<br>
>> > > SSL-узлу не удалось договориться о приемлемом наборе параметров<br>
>> > > безопасности.<br>
>> > > (Код ошибки: ssl_error_handshake_failure_alert)<br>
>> > ><br>
>> > > Пробую через nginx, соответственно тоже не работает, в логе nginx<br>
>> > > пишет:<br>
>> > > [error] 14221#0: *106 SSL_do_handshake() failed (SSL:<br>
>> > > error:14094410:SSL<br>
>> > > routines:SSL3_READ_BYTES:sslv3 alert handshake failure) while SSL<br>
>> > > handshaking to upstream<br>
>> > ><br>
>> > > Как это поправить? И вообще реализуема ли задачка, описанная в начале?<br>
>> > > Т.е.<br>
>> > > аутентификация пользователей именно на backend'е?<br>
>> ><br>
>> > В таком виде - нет, потому что nginx не передаёт клиентский сертификат<br>
>> > в proxy_pass.<br>
>><br>
>> А кроме того, это технически невозможно, потому что, даже передав<br>
>> клиентский сертификат, nginx не сможет его подтвердить, не имея<br>
>> клиентского приватного ключа.<br>
>><br>
>> > Можно аутентифицировать на nginx'е, а результат проверки<br>
>> > и прочие ssl-параметры передавать бэкенду без https:<br>
>> ><br>
>> > server {<br>
>> > ssl_verify_client optional;<br>
>> ><br>
>> ><br>
>> > <a href="http://sysoev.ru/nginx/docs/http/ngx_http_ssl_module.html#ssl_verify_client" target="_blank">http://sysoev.ru/nginx/docs/http/ngx_http_ssl_module.html#ssl_verify_client</a><br>
>> > <a href="http://sysoev.ru/nginx/docs/http/ngx_http_ssl_module.html#variables" target="_blank">http://sysoev.ru/nginx/docs/http/ngx_http_ssl_module.html#variables</a><br>
>><br>
>><br>
>> --<br>
>> Игорь Сысоев<br>
>> <a href="http://sysoev.ru" target="_blank">http://sysoev.ru</a><br>
>><br>
><br>
><br>
</div></div></blockquote></div><br>