Выбор сервера аутентификации

radius?

Тред не читай@сразу отвечай

openid?

Подписанные куки?

почему не читай? читай и все равно советуй )

Как вариант, по крайней мере работать с ним из скрипта удобнее.
Но не лишним он будет, если он работает в полной изоляции, и к нему обращается только один сервер?

И во вторых, логины содержат спецсимволы и могут быть не только на английском, это допустимо?

Ок. :)

Мне нужно решение:
Сервер с веб интерфейсом <-> сервер аутентификации

А не клиент - сервер.

Самое главное — ты можешь вообще не держать сервер авторизации. Ибо их держат и без тебя. И забота о сохранности паролей пользователей становится вообще не твоей проблемой. У веб-сервиса никаких паролей не будет, ломай-не ломай.

Это веб-морда из той категории, где пароли прятать надо, не то что доверять левым серверам при идентификации пользователя.

Ничто не мешает задать список доступных логинов.

Ну тогда будет openid сервер отдельно, веб-морда отдельно. Там же по идее можно указать, каких провайдеров слушать, а каких - нет.

Хотя я, конечно, вообще не специалист.

Вопрос в том, что я хочу сервер с парольной базой изолировать полностью.
Т.е юзер проходит аутентификацию стандартным образом (там SSL), а уже веб-интерфейс проводит её обмениваясь данными с изолированным сервером.

Потенциальный взломщик не должен знать, что на сервере с веб мордой нет паролей.

И мне надо выбрать, в чем хранить пароли и обрабатывать запросы с фронтенда.
В принципе OpenID это интересный вариант даже в моем случае, а я о нем даже не подумал :)

Может я тебя не правильно понимаю.
Но мне нужно сервер аутентификации для бекенда.

OpenID отлично подходит для форумов, блогов, чатов и прочих сервисов где безопасность данных не стоит на первом месте.
А у меня в данном случае идет работа с деньгами (пусть и не большими), и доверять какому либо стороннему серверу я не могу.

kerberos

вынос аутентификации на изолированный сервер

как ни странно, единственный вариант = керберос. Других просто нет :) есть только один общепризнанный и работающий протокол сетевой аутентификации.

только судя по всему вам не совсем это нужно - вам нужен унифицированный механизм работы с базой пользователей. Так эта..ldap :)

Только судя по всему вам не совсем это нужно - вам нужен унифицированный механизм работы с базой пользователей. Так эта..ldap :)

Вероятно это так, потому и задал вопрос тут.
Изолированный сервер это пока просто другая виртуалка (XEN), поэтому мне не нужна фишка Kerberos о которой написано в описании в wiki (оба пользователя через сервер подтверждают личности друг друга).

Мне в принципе все равно что использовать, хоть:
https://192.168.200.2/api.login.php
Но это будет велосипед, а хотелось бы узнать, как делают у людей.

есть только один общепризнанный и работающий протокол сетевой аутентификации.

RADIUS тогда что?

RADIUS тогда что?

для каких целей точнее->для учёта объёма услуг оказанных конкретной персоне (предложение в приоритетном порядке значений, то есть главное там __учёт__ __объём__ __услуги__)

у вас две темы подряд связанные с модернизацией инфраструктуры сети, и судя по всему вы мечетесь в попытках побороть следствия и впопыхах незная с какого бока взяться.

во первых - отдохните :) потом (и только потом) констатируйте текущее положение дел и формулируйте задачу.

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

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

Нет, не буду врать, в данном случае две темы никак не связаны.
В первом случае (с jabber) просто нужно помочь знакомым, и всю сеть я переделывать не буду.
У них уволился админ, и просто я один из немногих людей, кому они могут доверить доступы.

Я (к счастью наверное) обычный веб-мастер, и перенастройку целого офиса в 60 машин просто не потяну. :)
А данный тред касается моего личного проекта, который давно пора «перетрясти».

И во вторых, логины содержат спецсимволы и могут быть не только на английском, это допустимо?

В OpenID логин - это URL (http://server.com/user/vasya) и пользователь подтверждает что он владеет этой страницей. Скорее всего тебе не нужен OpenID.

Тебе нужно проверить, что пользователь, передавший логин и пароль, передал правильные данные. Для этого, ты можешь даже на этом же сервере хранить базу логинов и Ъ хешей паролей. Взломщик получит лишь логины и сможет заняться подбором легких паролей.

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

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

Керберосы разные для твоей задачи избыточны (т.е. ты запаришься разбираться как их настроить, и, скорее всего, у тебя заработает тот вариант, когда всем можно все, т.е. никакой защищенности от кражи базы логинов-паролей не будет).

В OpenID есть расширение sreg, которое позволяет передавать дополнительную информация о пользователе, в том числе и nickname, но логином будет URL.

Подробнее про поля в sreg тут https://openid.net/specs/openid-simple-registration-extension-1_0.html#respon...