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

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

6 голосов
/ 17 сентября 2008

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

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

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

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

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

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

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

Ответы [ 5 ]

3 голосов
/ 17 сентября 2008

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

2 голосов
/ 17 сентября 2008

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

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

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

Гудлак!

0 голосов
/ 17 сентября 2008

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

0 голосов
/ 17 сентября 2008

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

0 голосов
/ 17 сентября 2008

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

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

Редактировать: Я обнаружил реализацию протокола сервера OpenID в Django .

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

...