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

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

  • Управление аутентификацией, авторизация для сотен тысяч существующих пользователей, которые в настоящее время тесно интегрированы с приложением стороннего поставщика (мы хотим выделить этих пользователей в то, что мы управляем и делаем наши приложения работают против этого, плюс наши сторонние поставщики работают против этого).
  • Управлять информацией профиля, связанной с этими пользователями
  • Должен быть доступен доступ из любого количества веб-приложений практически на любой платформе (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 лет и знают свои логины, пароли и т. Д.


authentication django authorization active-directory ldap
person Community    schedule 16.09.2008    source источник

Ответы (5)


arrow_upward
4
arrow_downward

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

person dacracot    schedule 16.09.2008

arrow_upward
2
arrow_downward

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

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

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

Удачи!

person Jon Limjap    schedule 16.09.2008
comment
Текущая база данных пользователей + профили хранятся в нашей традиционной базе данных сторонних поставщиков (* SQL). У нас очень ограниченная возможность интегрироваться в эту базу данных, и мы предпочли бы иметь полный контроль над ней. Мы хотели бы освободить этих пользователей, а затем заставить сторонних разработчиков работать с новым db / ldap. - person ; 17.09.2008
comment
Что хорошо в LDAP, так это то, что другие сторонние продукты для предприятий должны иметь возможность подключаться к нему для управления пользователями. - person jason saldo; 17.09.2008
comment
Я думаю, что LDAP, вероятно, необходим для переноса аутентификации в этом проекте, но как насчет хранения информации профиля? Запихнуть это тоже в LDAP? Перебрать в другой магазин? - person ; 17.09.2008
comment
Зависит от информации профиля. Если информация профиля относится к конкретному приложению, я думаю, вам следует сохранить ее вместе с вашим приложением. Если это то, что будет использоваться в разных приложениях, LDAP должен учитывать эту информацию, IMHO. - person Jon Limjap; 17.09.2008

arrow_upward
0
arrow_downward

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

person jason saldo    schedule 16.09.2008
comment
Я выбираю это как безопасный ответ, так как я не уверен, насколько гибкими могут быть изменения схемы LDAP в производственной среде. Однако я чувствую себя очень комфортно, используя его для пользовательского магазина, изменяя базу данных по мере добавления функций. - person jason saldo; 17.09.2008

arrow_upward
0
arrow_downward

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

person Sklivvz    schedule 16.09.2008

arrow_upward
-1
arrow_downward

Вы всегда можете реализовать свой собственный сервер OpenID. Уже существует библиотека Python для OpenID, поэтому это должно быть довольно просто.

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

Изменить: я нашел реализацию протокола сервера OpenID в Django.

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

person zuber    schedule 16.09.2008
comment
Я должен добавить, что почти все приложения, которые будут аутентифицироваться по базе данных пользователей, будут под нашим контролем. Нет ничего более широкого, чем нужен сервер openID. Также важно знать, что многие из этих пользователей имеют эти учетные записи в течение 5-8 лет и знают свои логины и пароли. - person ; 17.09.2008