Single Sign On with Nginx

[Mikhail Fursov]

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

Пример: Пусть мы хотим объединить несколько различных сервисов под шапкой
одного сайта: 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 на gmail.com>

> 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 на gmail.com <mailto:savefrom на gmail.com>>
>>
>>
>>    http://sysoev.ru/nginx/docs/http/ngx_http_auth_basic_module.html
>>    =/
>>
>>    23 февраля 2010 г. 22:32 пользователь Mikhail Fursov
>>    <mike.fursov на gmail.com <mailto:mike.fursov на gmail.com>> написал:
>>
>>
>>        Привет всем!
>>
>>        Скажите пожалуйста, возможно ли при помощи модулей/расширений
>>        Nginx организовать единую аутентификацию для внутренней
>>        подсети по типу mod_auth_form который войдет в Apache 2.4 ?
>>
>>        Изнутри это может работать примерно так:
>>
>>        1) пользователь вводит пароль на странице фронт-енд сервера
>>
>>        2) после этого серсер его пускает его на "внутренние" ресурсы
>>        добавляя при этом Basic auth header во все внутренние HTTP
>>        запросы.
>>
>>        Заранее спасибо за ответы.
>>
>>
>>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://nginx.org/mailman/listinfo/nginx-ru
>



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