2010/2/25 Daniel Podolsky
<onokonem@xxxxxxxxx>
> Сервер должен перенаправлять все запросы для неаутентифицированных сессий на
> эту форму и отслеживать все сабмиты этой формы. Как только поля формы
> содержат правильные поля см пункт 3.
Неаутентифицированные - это какие? Которые для начала в нашей форме не
аутентифицировались, или те, для которых бекенд вернул 401? Второе -
проще.
Это именно те для которых нет "отметки" об аутентификации со стороны front-end. Почему: бэкэндов (приложений) может быть много - может оказаться трудно заставить их возвращать одно и то же по одинаковым правилам.
> 2) Должен быть указан URL страницы на которую переходить при ошибке
> аутентификации. Тут важно передать странице с ошибкой полную информацию об
> аутентификации - логин, пароль, тип ошибки (если возможно). В Apache этого
> нет, поэтому когда происходит ошибка аутентификации и пользователя требуют
> заново ввести пароль совсем непонятно по какой причине: его аккаунт
> заблокирован, задан неправильный пароль etc. Это очень неудобно.
Как мы проводим аутентификацию? Лезем в базу/ldap? Или у нас есть
специальный бекенд, на который мы можем спроксировать запрос, выставив
заголовок "Authorization: Basic ..."? Второе СИЛЬНО проще.
В Апаче это сделано так, что можно прикрутить любой имеющийся authprovider и использовать его. Думаю это намного быстрее (например обращение в ldap или локальный файл) чем проксировать запрос особенно в случае если нужно проверять аутентификацию для каждого запроса. Если я правильно понимаю то при отсутствии keepalive загрузка одной страницы может привести к 10-кам запросов.
То есть деталями аутентификации лучше заниматься модулям аутентификации, а роль модуля SSO только связать все необходимое в 1 целое.
> В куке содержится кодировнный хеш который позволяет серверу сопоставить имя
> и пароль пользователя с хранимыми сервером внутри (в памяти) данными.
> Возможно что кука может содержать и сам логин и пароль в закодированном
> виде. Тут вариантов много и в этом и есть отличие разных реализация для
> Апача. Не уверен какое тут решение будет лучше.
Чем меньше мы у себя информации храним - тем лучше. Я предпочитаю
куки, если надо - шифрованные.
Да, и как именно мы модифицируем запрос?
Тут не понял о каком запросе идет речь?
> Каждый раз когда пользователь обращается к ресурсу по заданному location
> нужно на фронт-энд сервере проверять наличие SSO куки и либо пропускать
> запрос пользователя либо нет. При этом важно учесть следующее: можно либо
> для каждого запроса проверять пользователя на валидность, либо верить первой
> аутентификации в течение всей сессии. В апаче эта опция называется
> AuthFormSitePassphrase.
Эээ... Бекенды никакой дополнительной аутентификации не делают?
Интересный ход. На сложность задачи это не сильно влияет, но я бы так
не делал.
Бекэнды это темные лошадки - им дается заполненный basic header и что они делают по нему это исключительно их дело. Главное при проходе через front-end иметь опцию - аутентификация при каждом запросе (например запрос в LDAP по имеющимся login/password) или доверие к уже имеющемуся куку и передача login/pass из куки бэкендам без дополнительной валидации.
> Хотелось бы чтобы front-end сервер имел возможность выполнять
> custom script передавая ему параметры о пользователя для каждого запроса.
> Тогда можно будет логировать активность с front-end
Выполнять что-либо из nginx - та еще радость. Этого не будет точно.
Будет лог-файл на фронтенде.
Может ли логгер иметь доступ ко всем полям запроса? Тогда же можно в качестве кастомного логгера написать что угодно - например класть в базу данных структурированную инфу.
Особенно хорошо если этот логгер будет уметь работать асинхронно - не тормозя поток в котором идет HTTP запрос.
> Б) Насильное завершение сессии. Хотелось бы иметь возможность насильно
> завершить сессию пользователя из приложения A, когда он аквтивен в
> приложении B. Это можно сделать, например, приняв результат работы скрипта
> описанного в пункте A, либо через его возвращаемое значение либо предоставив
> для скрипту API)
Будет URL, на который надо будет сделать запрос, передав пользователя
в качестве параметра.
Думаю тут и не нужно передавать имя пользователя. Имя пользователя уже в
сессии (в куке)
Вот тут уже пора задать вопрос - как это все должно масштабироваться?
Один воркер? Много воркеров, один сервер? Много серверов?
Сколько пользователей? Сотни, тысячи, десятки тысяч, миллионы?
Думаю насколько можно больше :) Ограничения сами вылезут из деталей - я их пока не знаю.
> ! Вообще если дать возможность модифицировать параметры изначального запроса
> при помощи вызова пользовательской подпрограммы на фрон-энд сервере передав
Нет, вызовов не будет. То есть - они будут, но бесполезные, потому что
ни в базу, и на другой сервер они ходить не смогут. То есть - смогут,
но лучше бы им этого не делать, чтобы nginx не блокировать.
Не вижу смысла тут ставить какие-то ограничения - пусть все будет на совести того кто эти вызовы добавит. В базовой же версии действительно никуда ходить не надо - нужно только имея текущее состояние что-то добавить - например Basic Header
> После этого остается
> только написать оптимизированное ядро для самой тяжелой и общей для всех
> сценарием операции - аутентификации по правилам SSO.
Как раз эта задача не кажется мне тяжелой. Я как раз сделал для себя
нечто подобное.
Сложно - это получить запрос, прогуляться на сторону за доп.
информацией, и продолжить в соответствии с полученным.
На самом деле не понимаю почему это сложно если существуют модули типа mod_rewrite? Они же изменяют тела запросов меняя в них гиперлинки?
--
