Управление большими базами данных пользователей для единого входа

Question

Как бы вы внедрили систему, преследующую следующие цели:

• Управлять аутентификацией, авторизация длясотни тысяч из существующие пользователи в настоящее время тесно интегрировано с приложением стороннего поставщика (мы хотим выделить этих пользователей во что-то, чем мы управляем, и заставить наши приложения работать против этого, плюс наши сторонние поставщики работают против этого).
• Управляйте информацией профиля, связанной с этими пользователями.
• Должен быть обеспечен доступ из любого количества веб-приложений практически на любой платформе (Windows, *nix, PHP, ASP/C#, Python/Django и т. д.).

Вот несколько примеров реализаций:

• Сервер LDAP/AD для управления всем.Используйте пользовательскую схему для всех данных профиля.Все может аутентифицироваться по LDAP/AD, и мы можем хранить все виды списков ACL и данные профилей в специальной схеме.
• Используйте LDAP/AD только для аутентификации, привязывайте пользователей LDAP к наиболее надежному серверу профилей/авторизации, используя какую-либо традиционную базу данных (MSSQL/PostgreSQL/MySQL) или базу данных на основе документов (CouchDB, SimpleDB и т. д.).Используйте LDAP для авторизации, а затем обратитесь к базе данных для более сложных вещей.
• Используйте для всего традиционную базу данных (реляционную или документальную).

Есть ли среди этих троих лучшие?Существуют ли другие решения, которые соответствуют вышеизложенным целям и которые легче реализовать?

** Добавлю, что почти все приложения, которые будут аутентифицироваться по пользовательской базе данных, будут под нашим контролем.Единственными аутсайдерами будут приложения, из которых мы удаляем текущую базу данных пользователей, и, возможно, еще 1 или 2 других.Нет ничего более широкого, чем потребность в сервере openID.

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

Answer 1

Существует разница между аутентификацией и авторизацией/профилированием, поэтому не обязательно объединять их в одном инструменте.Ваше второе решение с использованием LDAP для аутентификации и БД для авторизации кажется более надежным, поскольку данные LDAP контролируются пользователем, а БД будет контролироваться администратором.Структура и сложность последнего, скорее всего, со временем изменятся, но аутентификация — это всего лишь аутентификация.Разделение этих функций окажется более управляемым.

Answer 2

Если у вас есть существующая инфраструктура ActiveDirectory, это будет лучшим вариантом.Это будет особенно выгодно компаниям, у которых уже настроены серверы Windows для аутентификации.Если это так, то я склоняюсь к вашему первому пункту в «примерах реализации».

В противном случае это будет борьба между вариантами AD и LDAP с открытым исходным кодом.

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

Удачи!

Answer 3

Используйте LDAP/AD только для аутентификации, привязывайте пользователей LDAP к наиболее надежному серверу профилей/авторизации, используя какую-либо традиционную базу данных (MSSQL/PostgreSQL/MySQL) или базу данных на основе документов (CouchDB, SimpleDB и т. д.).Используйте LDAP для авторизации, а затем обратитесь к базе данных для более сложных вещей.

Answer 4

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

Answer 5

Вы всегда можете реализовать свои собственные OpenID сервер.уже есть Библиотека Python для OpenID так что это должно быть довольно легко.

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

Редактировать: Я нашел реализация протокола сервера OpenID в Django.

Редактировать2: Существует очевидное преимущество внедрения OpenID для ваших пользователей.Они смогут войти в StackOverflow под своими логинами :-)