ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Single Sign On with Nginx



Попробую описать задание, но для начала очень советую посмотреть на опции mod_auth_form, тк я вижу задачу "со своей колокольни" и запросто могу не знать о более глобальных вещах.

Итак, задача:

Реализовать опцию аутентификации для ресурсов расположенных по указанному под-url (location) которая позволяет делать следующее:

1) Требовать аутентификации для доступа к ресурсам расположенным по этому location при помощи формы.

Для этого должна указаться открытая страница на которой расположена форма с аутентификацией и имена полей для login/password.

Сервер должен перенаправлять все запросы для неаутентифицированных сессий на эту форму и отслеживать все сабмиты этой формы. Как только поля формы содержат правильные поля см пункт 3.
 
Если поля заполнены неправильными данными (неправильный пароль) см пункт 2.

2) Должна быть указан URL страницы на которую переходить при ошибке аутентификации. Тут важно передать странице с ошибкой полную информацию об аутентификации - логин, пароль, тип ошибки (если возможно). В Apache этого нет, поэтому когда происходит ошибка аутентификации и пользователя требуют заново ввести пароль совсем непонятно по какой причине: его аккаунт заблокирован, задан неправильный пароль etc. Это очень неудобно.

3) Если пользователь ввел правильные логин и пароль фронт-энд сервер позволяет пользователю доступиться до внутренних ресурсов текущего location при этом модифицируя его http request. Сам сервер запоминает то, что пользователь успешно аутентифицирован добавляя куку в сессию пользователя. Возможно что тут можно использовать что-то еще - я просто не специалист.

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

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

После того как у пользователя истечет время сессии - запросить его ввести логин и пароль заново.

4) Логаут: иметь определенный в config URL перейдя по которому пользовательская cookie будет удалена и сессия закончена


Еще важные пункты которых не хватает в Apache:

А) Трекинг активной сессии. Действительно если пользователь ходит по части сайта которая обслуживается одним engine (например svnviewer на php) а я хочу узнать активен ли пользователь в данный момент из другого приложения (Java) то единственный шанс это сделать - модифицировать код php приложения и записывать лог в базу. Если таких приложений много - нужно будет делать много патчей. Хотелось бы чтобы front-end сервер имел возможность выполнять custom script передавая ему параметры о пользователя для каждого запроса. Тогда можно будет логировать активность с front-end

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

! Вообще если дать возможность модифицировать параметры изначального запроса при помощи вызова пользовательской подпрограммы на фрон-энд сервере передав этой подпрограмме некоторый API для доступа к пользовательским данным и модификации их - то можно большую часть всего этого функционала свести к возможности вызова этого самого скрипта + набору sample утилит которые реализуют часто используемые паттерны. Как думате? После этого остается только написать оптимизированное ядро для самой тяжелой и общей для всех сценарием операции - аутентификации по правилам SSO.



Михаил.



2010/2/24 Daniel Podolsky <onokonem@xxxxxxxxx>
> А есть пример как это делается?
Нет, примера нету. Но мне интересно. Так что могу написать. С вас тех.
задание и документация к готовому модулю. Который будет, естественно,
опенсорс.
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru



--
Mikhail Fursov
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.