Задний план: У меня есть набор серверов на базе Linux (скажем, несколько десятков), которые размещены в разных местах. Некоторые серверы являются отдельными спутниками, в то время как другие размещаются вместе в одних и тех же центрах обработки данных. Некоторые из них являются физическими аппаратными серверами, а другие - виртуальными частными серверами. Серверы предоставляют такие услуги, как электронная почта, хостинг веб-приложений, базы данных и серверные части некоторых пользовательских приложений. Сами серверы уже имеют инструменты для управления оборудованием, а также управление на уровне операционной системы (учетные записи администратора, управление виртуальным сервером и т. Д.).
Проблема: До сих пор для аутентификации различных служб на уровне приложений использовался ряд решений. Иногда это означало, что пароли учетных записей приходилось хранить в нескольких местах. Лучшим решением было бы иметь система аутентификации из одного источника с централизованным управлением это позволит каждой службе аутентифицировать пользователя из одного экземпляра своей учетной записи и позволит работать с одним элементом данных вместо того, чтобы выяснять, какие местоположения необходимо обновить при создании, изменении и удалении учетной записи. Учетные данные могут быть реплицированы для обеспечения избыточности. (Обратите внимание, что цель здесь отличается от единой регистрации: вы должны аутентифицироваться отдельно для каждого приложения, но ваши учетные данные хранятся в одном месте. См. этот вопрос.)
Несколько предыдущих вопросов предполагали LDAP, а также говорили о Kerberos. Этот вопрос спрашивает о безопасности LDAP и просит сравнить LDAP и Kerberos. Kerberos - это хорошо, но возможность единого входа в этом случае не требуется, поэтому настройка Kerberos может оказаться излишней и вызвать ненужную административную нагрузку. Этот вопрос расширяет область действия, включая сетевые устройства, и фокус больше на уровне ОС, чем на уровне приложений. В моем случае нужна только аутентификация на уровне приложения. Это также означает, что существует большее разнообразие типов протоколов аутентификации, которые должны поддерживаться; PAM недостаточно. Этот вопрос запрашивает альтернативы LDAP, но в любом случае ответы указывают на LDAP по уважительным причинам. NIS - еще одно предлагаемое решение, но оно действительно не подходит в данном случае, потому что оно решает просто распределение парольной (и другой) информации, а не методы хранения, управления и аутентификации. В заключение, этот вопрос кажется очень похожим, но на самом деле основное внимание уделяется аутентификации VPN. (Есть еще аналогичный вопрос Вот, но не было достаточно точным, чтобы соответствовать ServerFault.)
LDAP - один из источников аутентификации, которые я использую в настоящее время. Однако не все приложения могут использовать LDAP. Некоторым нужен интерфейс на основе HTTP, в то время как другие лучше всего работают с интерфейсом SQL. Например, необходимо запустить поставщика OpenID, а часть настраиваемого программного обеспечения, которое мне нужно запустить для пользователей, можно настроить только для аутентификации через ODBC.
Другое предложение - FreeIPA http://freeipa.org/, но он также имеет дополнительную нагрузку на Kerberos и больше похож на решение для уровня ОС. Он находится в разработке в течение некоторого времени, но я не совсем уверен, что он достаточно зрелый, и он также может иметь слишком много ненужных функций, но все еще не предоставляет те, которые мне действительно нужны.
Я бы хотел отделить место хранения данных аутентификации (имена пользователей и пароли) из служба аутентификации. Я бы использовал одно четко определенное и безопасное место для хранения данных и несколько служб аутентификации, которые используют место хранения для аутентификации с использованием различных протоколов / интерфейсов. По крайней мере, необходимы интерфейс LDAP и SQL, и провайдер OpenID также занимает первое место в списке. Я думаю, что LDAP - хороший кандидат в качестве хранилища, но я открыт и для других вариантов. Желательно, чтобы это было бесплатное программное обеспечение с открытым исходным кодом.
Вопрос: Какое программное обеспечение следует выбрать для хранения учетных данных аутентификации и как предоставить различные интерфейсы для аутентификации с использованием этих учетных данных?
Какие у вас есть рекомендации?
Если вы используете LDAP в качестве резервного хранилища учетных данных, тогда:
pam_ldap для аутентификации на системном уровне.PAM, так что он действует как мост к LDAP.Кажется, это покрывает все ваши требования (если нет, приведите конкретные примеры). Для OpenID существует ряд решений, некоторые из которых (например, Atlassian Толпа) может аутентифицироваться по LDAP и другим, которые могут использовать базовую аутентификацию HTTP (что означает, что вы будете охвачены модулями LDAP для Apache).
Между прочим, преимущество Kerberos заключается не только в единой регистрации. Другое преимущество состоит в том, что при правильном использовании ваш пароль никогда не пересекает сеть. Это означает, что взломанный сервер не может собирать пароли. Это большое преимущество, но действительно полезно только в том случае, если (а) люди могут приобретать токены Kerberos со своей локальной конечной точки, и (б) все ваши приложения поддерживают аутентификацию Kerberos или GSSAPI. В неоднородной среде редко удается удовлетворить оба критерия.