Single Sign On with Nginx

Пт Фев 26 00:41:05 MSK 2010

Спасибо, по большей части ситуация понятна. С nginx я до этого не работал,
поэтому не было общего представления на что нацелен этот сервер. Думал что
он прямой конкурент апачу во всем + есть еще активное коммунити. В апаче же
баги просто игнорируют последний год. Те патчи что слали еще год назад до
сих пор не в альфе 2.3

Выходит в nginx просто так не получить требуемый функционал с четко
выделеннным куском кода который можно расширять для своих нужд. А  эти самые
нужды меняются со временем, что будет через месяц даже сказать трудно - что
закажут то и будет.

В апаче mod_perl даже не знаю стоит ли смотреть - вроде и без него уже есть
почти то что надо (mod_auth_form), но его функционал очень ограничен. Писать
с нуля аналог - плохо тк не профессионал в мод-писательстве. Нужно же чтобы
этот модуль правильно работал в стеке с остальными (mod_proxy, mod_auth..,
mod_crypto, mod_session ...)

Форкать и доразвивать существующее для своих нужд - видно только это и
остается.
Вообще если честно удивлен что для такой необходимой штуки для сложных
порталов как SSO ни у одного из серверов сейчас нет стабильного стандартного
решения...

2010/2/26 Daniel Podolsky <onokonem на gmail.com>

> > Это именно те для которых нет "отметки" об аутентификации со стороны
> > front-end. Почему: бэкэндов (приложений) может быть много - может
> оказаться
> > трудно заставить их возвращать одно и то же по одинаковым правилам.
> AFAIR, заголовок "Authorization: Basic ..." должен обрабатываться
> всегда по одинаковым правилам. Если бекенды хотят именно basic auth -
> мы можем положиться на то, что в случае отказа в доступе они вернут
> 401.
>
> > В Апаче это сделано так, что можно прикрутить любой имеющийся
> authprovider и
> > использовать его. Думаю это намного быстрее (например обращение в ldap
> или
> > локальный файл) чем проксировать запрос особенно в случае если нужно
> > проверять аутентификацию для каждого запроса. Если я правильно понимаю то
> > при отсутствии keepalive загрузка одной страницы может привести к 10-кам
> > запросов.
> AFAIK, authprovider-ов в nginx сегодня ровно один - basic из файла.
> Написать новый - это я сейчас не готов.
>
> И - нет, Вы понимаете неправильно. Нет разницы - проксировать запрос,
> или ходить в ldap. Только для хождения в ldap в nginx нет средств.
> Почему это важно - я объясню ниже.
>
> >> Да, и как именно мы модифицируем запрос?
> > Тут не понял о каком запросе идет речь?
> Правильно ли я понимаю, что все, что нам надо сделать - это добавить в
> запрос, проксируемый на бекенд, заголовок basic аутентификации? Или
> еще что-то надо в нем поменять?
>
> > Бекэнды это темные лошадки - им дается заполненный basic header и что они
> > делают по нему это исключительно их дело. Главное при проходе через
> > front-end иметь опцию - аутентификация при каждом запросе (например
> запрос в
> > LDAP по имеющимся login/password) или доверие к уже имеющемуся куку и
> > передача login/pass из куки бэкендам без дополнительной валидации.
> Я подумал еще раз, и понял, что не будет ldap-а - нет смысла
> втаскивать в nginx функциональность, которая уже прекрасно работает в
> апаче.
>
> Режимов проверки пароля будет два - plain/bdb файл и http. http
> означает, что за спиной у nginx стоит апач, которому nginx отправляет
> запрос, снабдив его basic auth info. По тому, ответил апач 200 или 401
> мы и определяем, правильные ли имя-пароль. А как там апач пароль
> проверяет - его дело.
>
> Да, это означает усложнение настройки. Но как сделать по-другому, не
> превращая nginx в апача - я не знаю. А апач у нас уже есть, вполне
> годный.
>
> Режим ревалидации каждого запроса - можно сделать, но работать все
> будет со скоростью бекенда. Так что непонятно - надо ли оно.
>
> > Может ли логгер иметь доступ ко всем полям запроса? Тогда же можно в
> > качестве кастомного логгера написать что угодно - например класть в базу
> > данных структурированную инфу.
> > Особенно хорошо если этот логгер будет уметь работать асинхронно - не
> > тормозя поток в котором идет HTTP запрос.
> Не-не-не. Только локальный файл. Поля запроса вытащим, это не проблема.
>
> > Думаю тут и не нужно передавать имя пользователя. Имя пользователя уже в
> > сессии (в куке)
> Годидзе. Если один из бекендов вернул 401 - заставляем пользователя
> перелогиниться. Только на более, чем один фронтенд это масштабируется
> плохо.
>
> > Думаю насколько можно больше :) Ограничения сами вылезут из деталей - я
> их
> > пока не знаю.
> Ок. Тогда я не парюсь и пользуюсь shared mem.
>
> > Не вижу смысла тут ставить какие-то ограничения - пусть все будет на
> совести
> > того кто эти вызовы добавит. В базовой же версии действительно никуда
> ходить
> > не надо - нужно только имея текущее состояние что-то добавить - например
> > Basic Header
> А я не вижу смысла добавлять бесполезное API. А оно будет бесполезное
> - см. ниже.
>
> >> Сложно - это получить запрос, прогуляться на сторону за доп.
> >> информацией, и продолжить в соответствии с полученным.
> > На самом деле не понимаю почему это сложно если существуют модули типа
> > mod_rewrite? Они же изменяют тела запросов меняя в них гиперлинки?
> Сложно - не запрос менять, а на сторону ходить. Если мы получили
> управление из nginx - мы должны как можно скорее вернуть его обратно,
> потому что, пока мы его не вернем - обработка всех остальных запросов
> стоит. А даже простое создание ТСР-соединения - занимает существенное
> время.
>
> Я вот что подумал. Есть же Апач с его mod_perl.  Если нужна валидация
> каждого запроса, и вызов стронних процедур - надо на нем и делать.
> Технически это возможно и на nginx, но - будет работать так же, или
> хуже. Скорее - хуже...
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://nginx.org/mailman/listinfo/nginx-ru
>

-- 
Mikhail Fursov
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20100226/91f8bc7b/attachment-0001.html>