У нас существуют несколько проектов и готовятся новые, в каждом проекте есть абсолютно одинаковая часть - авторизация пользователей. Для простоты возьмем веб-проекты, в каждом из них существует процесс регистрация-авторизация-вход. Для этих целей в каждом проекте есть таблица users, которая, собсно, хранит одни и те же поля: name, pass, email, act_code, registered_at. Зачастую каждый проект требует в этой таблице нечто большее, например, дату рождения, пол, второе мыло, какие-нибудь вопросы, да что угодно. Это, так сказать, вступление.

Решено было вынести авторизацию в отдельный проект, для чего сделать отдельную БД, в которой создать три таблицы: users, projects и user_history, вторая - справочник проектов, в третьей - история логинов пользователей с ключом (user_id, project_id). Собственно, авторизатор должен содержать так же и форму для авторизации.
Цель: один раз логин - доступ ко всем проектам.

Теперь, в теории, для проектов авторизация выглядит так:


Подключить библиотеку авторизатора;
Проверить состояние пользователя;
Если не авторизирован - отправить в авторизатор;
Иначе начать работу;


Все бы ничего и вроде бы удобно, но появилось несколько проблем. В проектах не используются прямые вызовы SQL, только всевозможные обертки. Типичный пример - отображение профиля пользователя. Для этого нужно знать его никнейм и мыло, что бы показать. Но эта информация хранится в БД авторизатора, как и ID пользователя. Теоретически, не проблема дать доступ на чтение таблицы для всех проектов, но это все вручную, как-то не интересно. К тому же, при создании новых проектов нужно будет вбивать название БД и таблицы в foreign key, что тоже не есть гуд (например, constraint fk_some_key foreign key user_id referenced aa.users(id)).
Так же есть вариант для каждого проекта дублировать информацию в локальных таблицах, но тогда на кого возложить обязанности по синхронизации БД авторизатора и проекта, если регистрация/авторизация/напоминание находятся в авторизаторе? Должен ли сам проект заботится об этом или авторизатор должен уметь создавать информацию в проектах?
Так же, в случае с веб-проектами, есть вариант передачи информации из авторизатора в проект внутри сессии, но тогда возникает вопрос, как эту информацию запихнуть в стандартный объект обёртки, ведь в локальной таблице таких полей нет.

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

Ёшдля хранения описания в том числе и пользователей придумали LDAP, а для ввода пароля один раз и аутентификации в разных местах придумали kerberos.
может быть это то что Вам нужно ?

LDAP не хотелось бы. Я, правда, не совсем понимаю, в чем разница в контексте хранения между БД и LDAP, если все равно ограничивать доступ в правах вручную? Как данные разграничить по приложениям? Хотя, скорей всего, я просто мало знаю про LDAP.
Про kerberos, если можно, чуть подробнее ;)

KachalovSOAP
Это вешать сервер, а в проекты вставлять клиентов. Для мелких проектов это накладно, пока остановились на варианте с библиотеками.

saturosА база пользователей едина? А где хранится? Если едина и хранится на сервере, то там и делать всю авторизацию. А дело авторизатора - считать входные данные - отправить на сервак - получить коды возврата и разрешить приложению запуститься/отказать ему в этом.
Эээ, немного не понял вопроса/предложения. Сервер один, БД несколько, на каждый проект своя.
Одним кодом сыт не будешь, суть то не в этом.

[quot mayton]Почитайте про Oracle Internet Directory.[/quote]
Спасибо.
Для нас пока слишком громоздко ;-) Да и душа лежит к OpenSource и простым легким решениям.

Kachalov khizhaster
KachalovSOAP
Это вешать сервер, а в проекты вставлять клиентов. Для мелких проектов это накладно, пока остановились на варианте с библиотеками.
- на каком языке пишете?
В данный момент превалируют небольшие проекты, perl, php, python, а так же парочка c++.

mayton khizhasterДля нас пока слишком громоздко ;-) Да и душа лежит к OpenSource и простым легким решениям.
Насколько я разобрался, OID - это LDAP сервер.

хм-хм, значит таки изучать LDAP. Спасибочки.
mayton
И если у вас организация - в домене, то вы его так или иначе используете. В любом случае, другие third-party решения по авторизации будут иметь изъян. Какой.. я пока не знаю. Может быть с безопасностью будет не всё в порядке.
Сеть без виндов вообщем то. Есть несколько, но они не учавствуют в проектах. Линуха да макоси, кол-во машин не большое, потому домен тут не к месту ;)
Эээ, я правильно понял, что вы хотели сказать, что любое решение, отличное от LDAP, будут уязвленными?

Kachalov
- тогда тем более SOAP :) как не привязанная к конкретному языку технология и для работы с которой имеются библиотеки на всех вышеперечисленных языках
Спасибо еще раз ;) Пойдем думать. На самом деле, изначально не хотелось городить сервисы разные, но таки учтём и обдумаем.

По поводу SOAP вот возникли некоторые неувязки. Для работы с БД используются обертки, прямых запросов нет. То есть, объект отражает таблицу. Выглядело раньше примерно так. Допустим, есть проект "Медали", где есть пользователи и их медали.
В БД записаны внешние ключи.
И в коде проекта в описании классов указываются связи
В RoR еще проще с этим.
Проблема в вот в этих связках medal->user->name, medal->user->born_at . Так как мы основную информацию (login, pass, email) выносим в другую БД и таблицу, например auth.users, то в проекте, в таблице users этой информации уже нет.
И здесь появляются другие проблемы. Если дублировать информацию, то кто будет следить за синхронизацией? В случае с SOAP как интегрировать информацию от сервиса в объект User, например, но так, что бы унифицировано и беспроблемно для других проектов, что бы не изобретать велосипед интеграции каждый раз.
Есть вариант во внешних ключах ссылаться на базу авторизатора, например references auth.users(id) , но тогда опять же дополнительную прийдется хранить в отдельной таблице и внешние ключи связывать с удаленной, не совсем ясно и, по моему, накручено слишком :( К тому же, прийдется пользователю БД для текущего проекта давать доступ на чтение в базе auth для таблицы users, что бы выборки проходили нормально. А это проблема учета пользователей, не хотелось бы вручную ее решать.

mayton
Не совсем. LDAP - это промышленное решение. И это всего-лишь протокол, на котором разговаривают рабочая станция и контроллер домена в момент авторизации. И если вы реализуете (правильно) авторизацию через него, к вам не будет претензий по безопасности. Или по крайней их можно будет легко отвергнуть.
Любое другое кустарное решение, вам придётся отстаивать, доказывая его защищённость.
Ага, вашу мысль я понял. Но домена у нас нет и не будет :)
Как я тут уже вижу, LDAP - хранилище, а авторизация - kerberos, например, и иже с ним. Да и как-то много пока нам "промышленных" решений. Спасибо за идею, положим для рассмотрения на будущее.