ПРОЕКТЫ 


  АРХИВ 


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



Если рассматривать все очень глубоко и детально - я с Вами согласен задача сложная. Но есть одно но: не для всех, но для очень большого количества случаев задача решается очень просто.

Пример: Пусть мы хотим объединить несколько различных сервисов под шапкой одного сайта: wiki, svnviewer, какая-то собственная логика и при этом хотим чтобы пользователь ввел логин только 1 раз.

Front-end SSO может закрыть доступ ко всем этим ресурсам пока не введен логин и пароль (проверка через LDAP/SQL) . После этого доступ открывается и во внутренние запросы добавляется BASIC header с логином и паролем. Конечно и wiki и svnviewer и наше самописное решение могут дополнительно  авторизировать пользователя разобрав Basic поля используя те же LDAP или SQL или access lists, но, если при этом все хорошо - пользователь введя пароль только 1 раз получит доступ ко всем ресурсам. Logout может делаться также через ссылку на front-end ресурс который просто "забудет" пользователя (удалит куку) и перестанет его пускать на защищенные ресурсы.

Я попробую описать требования и особые моменты в ответе на письмо Данилы Подольского ниже.

2010/2/24 Sergej Kandyla <sk.paix@xxxxxxxxx>
Mikhail Fursov wrote:
Вижу по этой ссылке только то, как настроить Basic, но не SSO.

Basic же подразумевается только внутри приватной сети, для передачи логина и пароля внутренним серверам проксирующимся через фронт-сервер. Логин же и пароль получать на фронт-сервере нужно не при помощи basic, а, например, при помощи html формы.

Именно это позволяет mod_auth_form из Апача. (И все бы хорошо c этим mod_auth_form  если бы в нем не было кучи багов или хотя бы на эти баги кто-нибудь реагировал).

есть еще некий  mod_auth_tkt для апача.
http://www.openfusion.com.au/labs/mod_auth_tkt/

но если брать в более глобальном плане, то вы хотите от nginx слишком много.
SSO подразумевает собой гораздо больше, и для того чтобы оно успешно работало, соотвествующий бекенд (динамика)
должен понимать как логиниться на SSO сервер, и что делать дальше с пользователями.
Практически все бекенды со сложной логикой имеют разделение прав, пользователей и т.д. и вот в этих бекендах
и происходит аутентификация, и соотвественно бекенды должны понимать SSO.

Например, у вас есть Jira, для которой вы хотите SSO (У Atlassian в качестве SSO солюшина предлагается crowd),
сколько вы не бейтесь с идеями sso на фронтенде,  атентификация то пользователей происходит на бекенде...

Конечно если у вас на проксируемом сервере   100 сайтов васи пупкина, то в качестве SSO солюшина подойдет и BASIC  аутентификация.

Ну и второй момент, что в сложных структурах, где нужен SSO, на одной машине не может и не должно быть все централизированно.
Это сводит на нет всю идею SSO на фронтенде.

Вы вообще определитесь для чего вам нужен SSO.
Практика показывает, что в большинстве случаев всем хватает централизированного LDAP, что работает красиво и прозрачно.




2010/2/24 SaveFrom.net <savefrom@xxxxxxxxx <mailto:savefrom@xxxxxxxxx>>


   http://sysoev.ru/nginx/docs/http/ngx_http_auth_basic_module.html
   =/

   23 февраля 2010 г. 22:32 пользователь Mikhail Fursov
   <mike.fursov@xxxxxxxxx <mailto:mike.fursov@xxxxxxxxx>> написал:


       Привет всем!

       Скажите пожалуйста, возможно ли при помощи модулей/расширений
       Nginx организовать единую аутентификацию для внутренней
       подсети по типу mod_auth_form который войдет в Apache 2.4 ?

       Изнутри это может работать примерно так:

       1) пользователь вводит пароль на странице фронт-енд сервера

       2) после этого серсер его пускает его на "внутренние" ресурсы
       добавляя при этом Basic auth header во все внутренние HTTP
       запросы.

       Заранее спасибо за ответы.




_______________________________________________
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.