<div class="gmail_quote">2010/2/25 Daniel Podolsky <span dir="ltr"><<a href="mailto:onokonem@gmail.com">onokonem@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> Сервер должен перенаправлять все запросы для неаутентифицированных сессий на<br>
> эту форму и отслеживать все сабмиты этой формы. Как только поля формы<br>
> содержат правильные поля см пункт 3.<br>
</div><br>Неаутентифицированные - это какие? Которые для начала в нашей форме не<br>
аутентифицировались, или те, для которых бекенд вернул 401? Второе -<br>
проще.<br></blockquote><div><br>Это именно те для которых нет "отметки" об аутентификации со стороны front-end. Почему: бэкэндов (приложений) может быть много - может оказаться трудно заставить их возвращать одно и то же по одинаковым правилам. <br>
</div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> 2) Должен быть указан URL страницы на которую переходить при ошибке<br>
> аутентификации. Тут важно передать странице с ошибкой полную информацию об<br>
> аутентификации - логин, пароль, тип ошибки (если возможно). В Apache этого<br>
> нет, поэтому когда происходит ошибка аутентификации и пользователя требуют<br>
> заново ввести пароль совсем непонятно по какой причине: его аккаунт<br>
> заблокирован, задан неправильный пароль etc. Это очень неудобно.<br>
</div>Как мы проводим аутентификацию? Лезем в базу/ldap? Или у нас есть<br>
специальный бекенд, на который мы можем спроксировать запрос, выставив<br>
заголовок "Authorization: Basic ..."? Второе СИЛЬНО проще.<br>
<div class="im"><br></div></blockquote><div>В Апаче это сделано так, что можно прикрутить любой имеющийся authprovider и использовать его. Думаю это намного быстрее (например обращение в ldap или локальный файл) чем проксировать запрос особенно в случае если нужно проверять аутентификацию для каждого запроса. Если я правильно понимаю то при отсутствии keepalive загрузка одной страницы может привести к 10-кам запросов. <br>
<br>То есть деталями аутентификации лучше заниматься модулям аутентификации, а роль модуля SSO только связать все необходимое в 1 целое.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> В куке содержится кодировнный хеш который позволяет серверу сопоставить имя<br>
> и пароль пользователя с хранимыми сервером внутри (в памяти) данными.<br>
> Возможно что кука может содержать и сам логин и пароль в закодированном<br>
> виде. Тут вариантов много и в этом и есть отличие разных реализация для<br>
> Апача. Не уверен какое тут решение будет лучше.<br>
</div>Чем меньше мы у себя информации храним - тем лучше. Я предпочитаю<br>
куки, если надо - шифрованные.<br>
<br>
Да, и как именно мы модифицируем запрос?<br></blockquote><div><br>Тут не понял о каком запросе идет речь? <br></div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> Каждый раз когда пользователь обращается к ресурсу по заданному location<br>
> нужно на фронт-энд сервере проверять наличие SSO куки и либо пропускать<br>
> запрос пользователя либо нет. При этом важно учесть следующее: можно либо<br>
> для каждого запроса проверять пользователя на валидность, либо верить первой<br>
> аутентификации в течение всей сессии. В апаче эта опция называется<br>
> AuthFormSitePassphrase.<br>
</div>Эээ... Бекенды никакой дополнительной аутентификации не делают?<br>
Интересный ход. На сложность задачи это не сильно влияет, но я бы так<br>
не делал.<br></blockquote><div><br>Бекэнды это темные лошадки - им дается заполненный basic header и что они делают по нему это исключительно их дело. Главное при проходе через front-end иметь опцию - аутентификация при каждом запросе (например запрос в LDAP по имеющимся login/password) или доверие к уже имеющемуся куку и передача login/pass из куки бэкендам без дополнительной валидации.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> Хотелось бы чтобы front-end сервер имел возможность выполнять<br>
> custom script передавая ему параметры о пользователя для каждого запроса.<br>
> Тогда можно будет логировать активность с front-end<br>
</div>Выполнять что-либо из nginx - та еще радость. Этого не будет точно.<br>
Будет лог-файл на фронтенде.<br></blockquote><div><br>Может ли логгер иметь доступ ко всем полям запроса? Тогда же можно в качестве кастомного логгера написать что угодно - например класть в базу данных структурированную инфу.<br>
Особенно хорошо если этот логгер будет уметь работать асинхронно - не тормозя поток в котором идет HTTP запрос.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> Б) Насильное завершение сессии. Хотелось бы иметь возможность насильно<br>
> завершить сессию пользователя из приложения A, когда он аквтивен в<br>
> приложении B. Это можно сделать, например, приняв результат работы скрипта<br>
> описанного в пункте A, либо через его возвращаемое значение либо предоставив<br>
> для скрипту API)<br>
</div>Будет URL, на который надо будет сделать запрос, передав пользователя<br>
в качестве параметра.<br>
<br></blockquote><div>Думаю тут и не нужно передавать имя пользователя. Имя пользователя уже в
сессии (в куке)<br><br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Вот тут уже пора задать вопрос - как это все должно масштабироваться?<br>
Один воркер? Много воркеров, один сервер? Много серверов?<br>
<br>
Сколько пользователей? Сотни, тысячи, десятки тысяч, миллионы?<br>
<div class="im"><br></div></blockquote><div>Думаю насколько можно больше :) Ограничения сами вылезут из деталей - я их пока не знаю. <br></div><div><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> ! Вообще если дать возможность модифицировать параметры изначального запроса<br>
> при помощи вызова пользовательской подпрограммы на фрон-энд сервере передав<br>
</div>Нет, вызовов не будет. То есть - они будут, но бесполезные, потому что<br>
ни в базу, и на другой сервер они ходить не смогут. То есть - смогут,<br>
но лучше бы им этого не делать, чтобы nginx не блокировать.<br>
<br></blockquote><div><br>Не вижу смысла тут ставить какие-то ограничения - пусть все будет на совести того кто эти вызовы добавит. В базовой же версии действительно никуда ходить не надо - нужно только имея текущее состояние что-то добавить - например Basic Header<br>
</div><div><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> После этого остается<br>
> только написать оптимизированное ядро для самой тяжелой и общей для всех<br>
> сценарием операции - аутентификации по правилам SSO.<br>
</div>Как раз эта задача не кажется мне тяжелой. Я как раз сделал для себя<br>
нечто подобное.<br>
<br>
Сложно - это получить запрос, прогуляться на сторону за доп.<br>
информацией, и продолжить в соответствии с полученным.<br></blockquote><div><br>На самом деле не понимаю почему это сложно если существуют модули типа mod_rewrite? Они же изменяют тела запросов меняя в них гиперлинки?<br>
<br></div><div> -- <br></div></div>Mikhail Fursov<br>