Является ли база данных MySQL жизнеспособной альтернативой LDAP?

Это широкая тема без простого ответа, так как зависит от множества факторов.

Некоторые преимущества (открытого)LDAP как пользовательской базы данных:

• LDAP имеет встроенную древовидную структуру, которая может упростить структурирование крупных организаций. Также проще иметь поле данных для записи, которая на самом деле представляет собой список вещей (например, "пользователь является членом этих групп"), а затем делать это в базах данных SQL (примечание: оба варианта абсолютно возможны в SQL, только более сложные),
• Проще использовать LDAP в качестве центральной пользовательской базы данных для нескольких систем. Это не такая большая проблема для таких вещей, как Mail или FTP, которые также могут использовать Linux PAM в качестве источника аутентификации, или для домашних систем, которыми вы управляете, но особенно если вы добавляете сторонние веб-приложения, вы часто в конечном итоге получаете в каждой системе свои собственная база данных пользователей с несовместимыми схемами, которые не могут обмениваться данными. В этом случае вы часто можете, по крайней мере, синхронизироваться с LDAP и / или выполнять его аутентификацию.
• Классы объектов LDAP для записей позволяют легко использовать одну и ту же базу данных для множества различных систем с различными требованиями - просто добавьте класс объекта в запись и получите целую кучу специфических для класса полей, которых нет в других записях и которые могли бы Для каждой записи в SQL должно быть много пустых полей.
• LDAP может быть системой аутентификации черного ящика. Это означает, что у вас может быть приложение, которое только отправляет имя пользователя и пароль в LDAP и спрашивает "Является ли эта комбинация действительной?" и получите ответ Да / Нет. С SQL приложению действительно нужно прочитать базу данных и выполнить саму проверку.

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

Можете ли вы использовать базу данных MySQL в качестве общего источника учетных записей пользователей? Да, безусловно. Я установил такую ​​систему, и она отлично работает с несколькими приложениями.

Итак, каковы недостатки использования базы данных MySQL вместо LDAP?

а) Вам необходимо адаптировать все приложения для использования вашей базы данных.

Обычно адаптировать приложение не так много. Часто вы можете просто решить эту проблему, создав представление, которое адаптирует имена столбцов. Иногда вам может понадобиться добавить немного кода для обслуживания другого формата хэширования паролей или создать плагин аутентификации.

Тем не менее, вам нужно будет сделать это для каждого приложения. И когда завтра вас попросят установить новое веб-приложение (например, кто-то решит добавить блог Wordpress), вам нужно будет еще раз изучить приложение и посмотреть, как его адаптировать.

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

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

Конечно, сама адаптация, вы можете сделать это, только если это ваша собственная разработка или с открытым исходным кодом. Забудьте о том, чтобы заставить Microsoft Windows поддерживать такую ​​пользовательскую схему!

б) централизация безопасности

Использование центрального сервера аутентификации имеет несколько преимуществ:

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

Во-вторых, центральная лесозаготовка. Выполнение аутентификации для одного сервиса позволяет вам иметь один журнал аутентификации, а не разделять его на несколько мест.

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

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

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

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

Я рекомендую сохранить ваш текущий сервер LDAP и создать, если необходимо, интерфейс для выполнения наиболее распространенных действий на нем (существует несколько внешних интерфейсов LDAP, может, один из них будет соответствовать потребностям вашей ИТ-группы?).

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

Я просто хотел добавить что-то, что (пока) не указано в других ответах: сравнение LDAP и SQL сравнивает яблоки и апельсины, поскольку они находятся на разных уровнях в стеке.

• LDAP = поддерживает службы каталогов по IP
• SQL = общее управление базой данных, которое, конечно, может включать управление пользователями

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

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

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

Я бы порекомендовал сначала взглянуть на ваши другие ИТ-приложения, чтобы увидеть, насколько они связаны со службой LDAP для служб входа и авторизации, а затем решить, насколько просто или болезненно было бы перейти на пользовательское решение для базы данных SQL.