Форумы портала PHP.SU :: Версия для печати :: Единый сервер авторизации

1. Vinyl - 25 Декабря, 2012 - 10:29:40 - перейти к сообщению

Всем доброго времени и с наступающими.
Предо мной стоит задача сделать единый сервер авторизации для нескольких сайтов. Помогите, пожалуйста, с алгоритмом.
Я прекрепил две картинки, на них схематично изображены процесс самой авторизации из формы и процесс проверки движком, залогинен юзер или нет. О сессиях, естественно, речи быть не может, поэтому авторизация только на куках + для пущей безопасности, при авторизации в ячейку текущего пользователя записывается юзер-агент и IP, которые проверяются при каждом запросе к сайту.

Во-первых, какие есть недостатки у такого алгоритма?
Я вижу два: с выкл. куками работать не будет и нагрузка может быть существенной, потому что сайтов будет 10/20/30/.../неизвестно сколько.

Во-вторых, каким образом при проверке пользователя (рис. 2, п. 2) отправлять запрос к серверу БД? Сокеты?

Спасибо.

2. Vinyl - 25 Декабря, 2012 - 10:31:07 - перейти к сообщению

3. EuGen - 25 Декабря, 2012 - 10:34:42 - перейти к сообщению

SAML, OpenID
?

4. Vinyl - 25 Декабря, 2012 - 10:42:54 - перейти к сообщению

EuGen, OpenID мне не нравится тем, что за вводом логина следует переадресация на другой ресурс (пусть даже и мой), где требуется подтверждение от пользователя. Это не приемлемо. А про SAML сейчас бегло почитал - если честно, вообще ничего не понял, как и что работает. Поищу ещё информацию. Спасибо.

5. EuGen - 25 Декабря, 2012 - 10:56:28 - перейти к сообщению

Полезным будет еще почитать про Web SSO (desc.)

6. Zuldek - 25 Декабря, 2012 - 11:47:00 - перейти к сообщению

Не знаю о каком проекте идет речь, + отказ от сессий тоже не понятен при наличии кук.
Есть один базовый класс пасспорта со всеми методами проверки пользователя, проверки уровня прав, авторизации и т.д. Данные в бд, при авторизации пользователь остается в текущем проекте. Все проекты - дочерние сайты, разделы единого портала наследуют этот класс. К нему же прикручена авторизация с Openid.
Иное, если речь не идет о каком-нибудь интернет-банке считаю неоправданным. Разнести задачи авторизации по разным железкам не представляется сложной задачей( если дело в нагрузке).

7. Vinyl - 25 Декабря, 2012 - 11:52:39 - перейти к сообщению

EuGen, видимо, не дорос ещё мой гений до таких вещей А чё я? Я ничё!

Я них%)на понять не могу, как и что работает. Почитаю конечно, но не уверен, что вникну. Но все равно спасибо

8. Vinyl - 25 Декабря, 2012 - 17:56:23 - перейти к сообщению

А как насчет OAuth 2? Кто что хорошего/плохого скажет?

Zuldek пишет:

Иное, если речь не идет о каком-нибудь интернет-банке считаю неоправданным.

Почему так категорично? Вы считаете, никто не в силах сделать что-то лучше (безопаснее/удобнее/быстрее/...), чем тот же OpenID?

9. Vinyl - 26 Декабря, 2012 - 08:35:11 - перейти к сообщению

Много читал - это все не то (если я правильно понял). Из статьи Котерова об OAuth:

Цитата:

OAuth — протокол для авторизованного доступа к стороннему API. OAuth позволяет скрипту Consumer-а получить ограниченный API-доступ к данным стороннего Service Provider-а, если User дает добро. Т.е. это средство для доступа к API

Мне не нужно, чтобы User давал добро.

Попробую объяснить. Предположим, есть у меня сервер https://server.com, который выступает в роли единого сервера авторизации для нескольких сервисов. Количество и адреса этих сервисов мне известны. Допустим, их три: http://site1.com, http://site2.com и http://site3.com. При заходе на https://server.com нас редиректит на (допустим) http://site1.com, т.к. https://server.com используется только для авторизации.

Авторизация:
Заходим на любой из трех сервисов, видим форму авторизации, вводим логин-пароль, отправляем форму на https://server.com, там проверяются данные из формы, если все верно - формируется токен, записывается токен, юзер-агент и IP в таблицу к юзеру, ставится кука вида

PHP:
скопировать код в буфер обмена

setcookie ("token", $token,time()+3600, "/", "server.com", 1);

затем браузер получает заголовок "Location:x", где x - страница, с которой пришли.

Aутентификация:
Происходит при каждой загрузке страницы любого из сервисов http://site(n).com.
Если есть кука с токеном для домена https://server.com, отправляем её значение серверу (допустим, через сокет, в зашифрованном виде) вместе с IP и юзер-агентом. Сервер расшифровывает полученные данные, ищет таблицу с таким токеном, если нашел - проверяет IP+U-A, если все хорошо - возвращает то, что требуется (id, разрешения, имя, фамилия, и т.д.).

Преимущество такого подхода в том, что авторизовавшись на http://site1.com, пользователю не нужно будет подтверждать что-то на http://site2.com, он уже там авторизован. Ему не нужно нажимать кнопки "Войти через http://site1.com", он авторизован на всех сервисах, известных серверу https://server.com. И база данных с пользователями одна.

Чем такой подход хуже OpenID или OAuth (кроме безопасности)? Просьба отвечать конструктивно, а не "Да никто так не делает", "Зачем изобретать велосипед?"или "Это же контакт с яндексом юзают, лучше быть не может!". Спасибо!