Причины хранения данных пользователей в LDAP вместо RDBMS

Ответ 1

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

Хорошая служба LDAP требует хороших знаний о конфигурации, а не создания простой схемы в реляционной базе данных. SQL DB по-прежнему довольно интероперабельный вариант, и поддержка LDAP не такая доминирующая, как раньше. LDAP раньше был единственным вариантом, но многие приложения (например, Apache) и операционные системы (например, Linux PAM) могут аутентифицироваться в SQL DB, подобно MySQL, так же легко, как и серверы LDAP, поскольку все это обрабатывается драйверами, абстрагирующими интерфейс.

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

Это не то, что современные СУБД не масштабируют его только потому, что LDAP (как правило) еще лучше, потому что он каскадирует репликацию через разные уровни; в частности, при условии, что у вас типичная настройка базы данных аутентификации, где она в основном доступна только для чтения с относительно небольшим количеством операций записи, поэтому вам нужно только одностороннюю репликацию со всеми сообщениями, исходящими из одного источника правды.

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

То, что кто-то уже сделал о том, что передняя часть LDAP на РСУБД очень хорошая. Несколько компаний, в том числе Oracle (которые, конечно же, заинтересованы в РСУБД), имеют продукты, которые специально это делают. Если вам не нужны накладные расходы на управление службой LDAP или если вы просто хотите управлять всеми своими пользователями в БД, вы можете создавать представления/объединения, но подумайте, что вам может понадобиться служба LDAP позже, чем хорошая опция, OpenLDAP также поддерживает конец оболочки, который может принимать данные из любого источника, включая RDBMS; Я использовал его с MySQL, и он работает хорошо, хотя может быть немного затруднительно настроить первый раз, если вам нужно поддерживать определенную схему LDAP.

В общем, LDAP - это замечательно, но это особенно важно для взаимодействия и экстремальной масштабируемости. Если у вас ограниченные ресурсы для управления и поддержки, это может не стоить хлопот поддержки, но если вы планируете такие сервисы, как UNIX, размещенная POP/IMAP/SMTP или другая сторонняя интеграция программного обеспечения, то это, безусловно, стоит делать (и может даже быть вашим единственным жизнеспособным вариантом).

О, и, наконец, будьте осторожны с тем, какой сервер LDAP вы используете, если решите его реализовать! Они не все созданы равными, и различия между ними (с точки зрения производительности и простоты управления и конфигурации) могут быть довольно резкими.

OpenLDAP - довольно безопасная ставка, хорошо масштабируется и довольно проста в использовании. Некоторые приложения работают лучше всего/поставляются с определенными конфигурационными файлами для определенного LDAP-сервера (например, большое количество программного обеспечения на Solaris предполагает, что вы используете сервер каталога Sun ONE), который вы, возможно, не хотели бы использовать, либо потому, что он не работает также, или свиньи для настройки, не поддерживается и т.д.

Ответ 2

"L" в LDAP означает "Легкий". Одна из целей LDAP - относительно простая в использовании и реализации. Если все, что вам нужно сделать, это хранить информацию о пользователях, вам не нужна полная гибкость (и потенциальная головная боль) для доступа к вашим данным через SQL. Ограниченный интерфейс, представленный LDAP, должен быть проще. Это важно, если вы хотите, чтобы LDAP был реализован и поддерживался всеми, включая поставщика os и всех ваших поставщиков приложений.

PS: Если бы вы захотели, вы всегда могли бы реализовать сервер LDAP, сохраняя всю информацию в РСУБД и предоставляя ему интерфейс LDAP:)

PPS: LDAP - это протокол, например HTTP. RDBMS - это приложение, которое обычно рассматривается как средство, реализующее SQL, между прочим. Поэтому для сравнения яблок с яблоками вам лучше было бы противопоставить LDAP с SQL или HTTP.

Ответ 3

Корпорация Майкрософт создала статью статью TechNet, посвященную продукту Active Directory Application Mode (ADAM), и в ней есть раздел, в котором сравниваются различия между каталогами и Базы данных. Следующие данные берутся непосредственно с сайта.

Каталоги

• Оптимизирован для операций поиска и чтения.
• Объектно-ориентированный иерархический дизайн данных. Объекты данных в каталоге представляют такие объекты, как пользователи, компьютеры и общие ресурсы. Эти объекты данных могут быть организованы иерархически в контейнерах.
• Не использует схемы.
• Предназначен для репликации и распределенного управления.
• Точная защита, вплоть до уровня объектов и атрибутов.
• Свободная согласованность данных между партнерами по репликации.

Базы данных

• Оптимизирован для операций записи.
• Реляционные данные. Данные организованы в таблицы строк и столбцов. Данные из одной таблицы могут быть связаны с данными в другой таблице.
• Использует стандартизованные расширяемые схемы.
• Предназначен для централизованного хранения и администрирования данных.
• Меньшая точность безопасности, вплоть до уровня строк и столбцов.
• Transactional - гарантированная согласованность данных. Ссылочная целостность в реляционных таблицах и concurrency с блокировкой файлов и записей.

Ответ 4

Это действительно не исключает RDBMS как бэкэнд. См., Например, подробную информацию о sql backend для slapd или посмотрите полный список backends.

Ответ 5

Interoperability.

Каталоги LDAP имеют стандартную схему для представления пользователя, поэтому общие поля, такие как имя, фамилия и адрес электронной почты, будут последовательноменоваться в разных реализациях каталогов. Это не относится к РСУБД.

LDAP определяет как протокол связи, так и язык запросов. Сравните это с SQL, который является только языком запросов, и каждая RDBMS реализует собственный протокол связи.

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

Ответ 6

Одна из веских причин заключается в предоставлении единого знака для многих приложений (которые используют LDAP).