Re: Single Sign On with Nginx

[Daniel Podolsky <onokonem@xxxxxxxxx>]

2010/2/25 Mikhail Fursov <mike.fursov@xxxxxxxxx>:
> Попробую описать задание, но для начала очень советую посмотреть на опции
> mod_auth_form, тк я вижу задачу "со своей колокольни" и запросто могу не
> знать о более глобальных вещах.
Не, не хочу :) Не на этом этапе...

> Сервер должен перенаправлять все запросы для неаутентифицированных сессий на
> эту форму и отслеживать все сабмиты этой формы. Как только поля формы
> содержат правильные поля см пункт 3.
Неаутентифицированные - это какие? Которые для начала в нашей форме не
аутентифицировались, или те, для которых бекенд вернул 401? Второе -
проще.

> 2) Должна быть указан URL страницы на которую переходить при ошибке
> аутентификации. Тут важно передать странице с ошибкой полную информацию об
> аутентификации - логин, пароль, тип ошибки (если возможно). В Apache этого
> нет, поэтому когда происходит ошибка аутентификации и пользователя требуют
> заново ввести пароль совсем непонятно по какой причине: его аккаунт
> заблокирован, задан неправильный пароль etc. Это очень неудобно.
Как мы проводим аутентификацию? Лезем в базу/ldap? Или у нас есть
специальный бекенд, на который мы можем спроксировать запрос, выставив
заголовок "Authorization: Basic ..."? Второе СИЛЬНО проще.

> В куке содержится кодировнный хеш который позволяет серверу сопоставить имя
> и пароль пользователя с хранимыми сервером внутри (в памяти) данными.
> Возможно что кука может содержать и сам логин и пароль в закодированном
> виде. Тут вариантов много и в этом и есть отличие разных реализация для
> Апача. Не уверен какое тут решение будет лучше.
Чем меньше мы у себя информации храним - тем лучше. Я предпочитаю
куки, если надо - шифрованные.

Да, и как именно мы модифицируем запрос?

> Каждый раз когда пользователь обращается к ресурсу по заданному location
> нужно на фронт-энд сервере проверять наличие SSO куки и либо пропускать
> запрос пользователя либо нет. При этом важно учесть следующее: можно либо
> для каждого запроса проверять пользователя на валидность, либо верить первой
> аутентификации в течение всей сессии. В апаче эта опция называется
> AuthFormSitePassphrase.
Эээ... Бекенды никакой дополнительной аутентификации не делают?
Интересный ход. На сложность задачи это не сильно влияет, но я бы так
не делал.

> Хотелось бы чтобы front-end сервер имел возможность выполнять
> custom script передавая ему параметры о пользователя для каждого запроса.
> Тогда можно будет логировать активность с front-end
Выполнять что-либо из nginx - та еще радость. Этого не будет точно.
Будет лог-файл на фронтенде.

> Б) Насильное завершение сессии. Хотелось бы иметь возможность насильно
> завершить сессию пользователя из приложения A, когда он аквтивен в
> приложении B. Это можно сделать, например, приняв результат работы скрипта
> описанного в пункте A, либо через его возвращаемое значение либо предоставив
> для скрипту API)
Будет URL, на который надо будет сделать запрос, передав пользователя
в качестве параметра.

Вот тут уже пора задать вопрос - как это все должно масштабироваться?
Один воркер? Много воркеров, один сервер? Много серверов?

Сколько пользователей? Сотни, тысячи, десятки тысяч, миллионы?

> ! Вообще если дать возможность модифицировать параметры изначального запроса
> при помощи вызова пользовательской подпрограммы на фрон-энд сервере передав
Нет, вызовов не будет. То есть - они будут, но бесполезные, потому что
ни в базу, и на другой сервер они ходить не смогут. То есть - смогут,
но лучше бы им этого не делать, чтобы nginx не блокировать.

> После этого остается
> только написать оптимизированное ядро для самой тяжелой и общей для всех
> сценарием операции - аутентификации по правилам SSO.
Как раз эта задача не кажется мне тяжелой. Я как раз сделал для себя
нечто подобное.

Сложно - это получить запрос, прогуляться на сторону за доп.
информацией, и продолжить в соответствии с полученным.
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru