Single Sign On with Nginx

Чт Фев 25 21:49:14 MSK 2010

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

> > Сервер должен перенаправлять все запросы для неаутентифицированных сессий
> на
> > эту форму и отслеживать все сабмиты этой формы. Как только поля формы
> > содержат правильные поля см пункт 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? Они же изменяют тела запросов меняя в них гиперлинки?

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